eG Monitoring
 

Measures reported by OraRacUnTbsTest

Every Oracle Database must have a method of maintaining information that is used to roll back, or undo, changes to the database. Such information consists of records of the actions of transactions, primarily before they are committed. These records are collectively referred to as undo.

Undo records are used to:

  • Roll back transactions when a ROLLBACK statement is issued
  • Recover the database
  • Provide read consistency
  • Analyze data as of an earlier point in time by using Oracle Flashback Query
  • Recover from logical corruptions using Oracle Flashback features

When a ROLLBACK statement is issued, undo records are used to undo changes that were made to the database by the uncommitted transaction. During database recovery, undo records are used to undo any uncommitted changes applied from the redo log to the datafiles. Undo records provide read consistency by maintaining the before image of the data for users who are accessing the data at the same time that another user is changing it.

Oracle provides a fully automated mechanism, referred to as automatic undo management, for managing undo information and space. In this management mode, you create an undo tablespace, and the server automatically manages undo segments and space among the various active sessions.

Each instance in the RAC system can only use one undo tablespace at a time. In other words, instances cannot share undo tablespaces. Each instance in the cluster, being an independent transaction-processing environment, maintains its own UNDO area for undo management. The RAC system allows the creation and use of several undo tablespaces. When the instance is started, it uses the first available undo tablespace. A second instance will use another undo tablespace. Thus, each instance in a RAC system will have exclusive access to a particular undo tablespace at a given time. The undo tablespace cannot be shared among the instances at the same time. Only once an undo tablespace is released by an instance, it can be assigned to another instance. However, all instances can read blocks from any or all undo tablespaces for the purpose of constructing read-consistency images. You need to closely observe how the sessions to each RAC instance use the undo tablespaces; this will enable you to proactively detect unusually high/long usage conditions. This test brings such anomalies to light. This test reports the number of sessions (per instance) accessing the undo tablespace and the duration of usage of these sessions, thus indicating excessive usage (if any) of the undo tablespace. The detailed diagnosis capability of the test turns the spotlight on those sessions that are the leading users of the undo tablespace, and provides pointers to the query executed by these sessions. With the help of this information you can identify inefficient queries and fine-tune them, so that potential processing delays and consequent instance slowdowns/crashes can be averted.

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
Average_duration Indicates the average time taken by the sessions to this instance, to execute queries on the undo tablespace. Seconds Ideally, the value of this measure should be low. An unusually high value for this measure could indicate that one/more sessions are using the undo tablespace for too long a time. Use the detailed diagnosis of this measure to identify the top sessions in terms of duration of usage of the undo tablespace, and determine the SQL ID of the query executed by each session on that tablespace. Inefficient queries can thus be isolated. Fine-tuning these queries will enable the optimal usage of the undo tablespace.

Query processing will also be delayed if the undo tablespace is improperly sized. If the undo tablespace has insufficient space, many transactions to the tablespace may terminate before completion, and many more transactions may even hang; this will result in a long line of long-running queries.

Also, since Oracle automatically tunes the undo retention period based on undo tablespace size and system activity, if the undo tablespace runs out of space, it will grossly affect the auto retention capability of Oracle, once again causing query failures. When available space for new transactions becomes short, the database begins to overwrite expired undo. If the undo tablespace has no space for new transactions after all expired undo is overwritten, the database may begin overwriting unexpired undo information. If any of this overwritten undo information is required for consistent read in a current long-running query, the query could fail with the snapshot too old error message.

Number_of_session Indicates the number of sessions to this instance that are utilizing the undo tablespace. Number This serves as a good indicator of the load on the undo tablespace.