Databases Reference
In-Depth Information
How it works...
In step 2, we query the
V$SYSTEM_EVENT
dynamic performance view to inspect
problems related to redo logs. In the following screenshot, we can see the results
obtained on a test database:
The important events to be observed are log file sync and log file parallel write. Often, a
high value for the latter statistic is not evidence of a problem. It indicates a wait in
LGWR
activity, but doesn't specify whether waits affect user processes or not.
The log file sync statistic is more reliable. The symptoms of I/O issues, related to slow
disks on which redo log files are written, are highlighted by a high value for log file sync
statistic. Often a high value for the log file parallel write is confirmed by a high value for
this parameter. In these situations, you need to solve the issue—the high waits—related
to redo log file writes.
In step 3, we query the
V$LOGFILE
to know the redo log files in our database and some
information on their status. We can see the results obtained in the following screenshot:
We can see that there are three redo log groups in the database, with only one member
each. In a production database, you need at least two members for each group, and,
according to the transaction load on the database, more redo log groups could be required.
