User manual HP POLYSERVE SOFTWARE

[. . . ] Combining Oracle-provided monitoring tools with these operatingsystem tools is usually sufficient in SMP environments hosting single, or very few, database instances. With the advent of Real Application Clusters (RAC) and powerful Intel-based clustered servers, DBAs need I/O performance monitoring tools that are more "cluster-aware. " With RAC, it is common to find large numbers of clustered nodes hosting several different databases, each with several different instances running on the various nodes--all sharing the Storage Area Network. The thought of monitoring I/O performance of a many-database, many-instance, many-node clustered environment is rightfully troublesome. Indeed, equipped with only Oracle Enterprise Manager, Statspack, and GV$ tables and aided by node-local I/O stats, today's DBAs are lacking for information. [. . . ] The MxODM I/O Monitoring feature relies on the proper configuration of the $MXODM_DBNAME1 environment variable. To provide accurate database-level statistics, this variable needs to be set in the environment of all processes accessing the database, including SQL*Plus processes prior to starting a database instance and processes that connect through Net Services listener processes. If the $MXODM_DBNAME environment variable is not set, MxODM presumes that the database name is a component of the ORACLE_SID environment variable. For example, if the values of ORACLE_SID in the matrix are "PROD1" and PROD2" and MXODM_DBNAME is NULL clusterwide, summary I/O statistics for both instances will be reportable via the default database name "PROD. " If Instance names in the matrix do not follow the typical convention of DBNAMEn, where n is the logical node number in the cluster, this default scheme will not be correct for database-wide I/O monitoring. In this case, the $MXODM_DBNAME variable must be set. 1. MxODM I/O statistics are collected regardless of environment variable settings. It is crucial, however, that these variables be set for proper attribution of statistics to the various reporting categories (node-level, instance-level, database-level, and so on). Advanced I/O Monitoring 5 Environment variables are passed through the lsnrctl process to the listener daemons. Hence, before starting a listener for the PROD database on a given node, set the $ORACLE_SID and $MXODM_DBNAME environment variables. The following example depicts a session starting a listener process that will accept a connect request to access the PROD database through the PROD1 instance. All activity by server processes begat of this listener will be accounted for accordingly. Note that this requirement insists that specific listeners be configured to service connects to each database on a given node. Instances started with the srvctl command need to use the built-in method for passing environment variables. That is, if a database Instance is not started with sqlplus (where MXODM_DBNAME is set in the environment), and instead srvctl is used, the MXODM_DBNAME environment variable can be passed to the Instance background processes using the -t option of the srvctl command. For instance, the following example will cause MXODM_DBNAME to be set to "PROD" in any Instance accessing the PROD database. As such, this is a central point for setting the environment for all nodes in the cluster. $ srvctl setenv database -d PROD -t MXODM_DBNAME=PROD You may also want to set the MxODM enviroment variable MXODM_APPNAME. This environment variable offers additional monitoring functionality. It must be passed to Oracle processes in the same manner as $MXODM_DBNAME. $MXODM_APPNAME is essentially a free-form variable. An example of its use would be to facilitate the monitoring of a specific application module as opposed to all of the activity within a database. For instance, prior to executing a program that performs General Ledger activity, $MXODM_APPNAME could be set to GL, while $MXODM_DBNAME might be FIN. Other sessions accessing the FIN database using an Accounts Payable program might set $MXODM_APPNAME to AP. As such, monitoring I/O with the -D option set to FIN will report the aggregate activity of all processes acessing FIN, but using mxodmstat with the -A option set to GL will report the portion of FIN activity that is specific to the processes that have MXODM_APPNAME set to GL. Advanced I/O Monitoring 6 MxODM I/O Monitoring: Practical Examples This section offers several practical examples of the powerful I/O monitoring capability of the mxodmstat(8) command. The examples use a question and answer format, where the answer includes an mxodmstat(8) command and its output. The system used for these examples was a six-node, dual-processor, Intel-based cluster with PolyServe Matrix Server 2. 1 and Oracle9i Real Application Clusters version 9. 2. 0. 4. There were two main databases on the cluster: · BENCH. [. . . ] Nodes 5 and 6 have much more memory and are configured for most of the large DSS and reporting activity. How can I monitor to ensure that the very heavy I/O workload intended to run on nodes 5 and 6 is not impacting I/O service times on the OLTP nodes?Once again, the -I option should be used. Figure 5 depicts a perfect example of this usage. [. . . ]