 |
|
Monitoring the Data Guard Log apply service
Oracle Database Tips by Donald BurlesonDecember 9, 2015
|
Monitoring Data Guard Log Apply Services
The v$logstdby and v$logstdby_stats views
provide comprehensive data about the various processes involved in
the SQL Apply operations. As mentioned earlier in the "Data Guard
Architecture" chapter, the SQL Apply operation is facilitated by
LogMiner technology.
The v$logstdby view can be queried to find the
state of the individual process of LogMiner. The following simple
query on v$logstdby will give sufficient information needed to analyze
any problem with the log apply service:
Oracle Data Guard
Monitoring Log Apply Services
Select
PID,
TYPE,
STATUS
From
V$LOGSTDBY
Order by
HIGH_SCN;
The following is a sample output, from the
above query showing the status of the log apply service:
PID TYPE STATUS
------ -------- -------------------------------------
1479 ANALYZER ORA-16116: no work available
1475 BUILDER ORA-16127: stalled waiting for additional
transactions to be applied
1477 PREPARER ORA-16116: no work available
1471 COORDINATOR ORA-16116: no work available
1473 READER ORA-16127: stalled waiting for additional
transactions to be applied
1481 APPLIER ORA-16116: no work available
Monitoring Log Apply Services
The v$logstdby_stats view contains the
performance statistics on the log apply service. The records from
this view will be cleared when the log apply service is not running.
The following query can be used for performance monitoring purposes:
Select
NAME,
VALUE
From
V$LOGSTDBY_STATS;
The output from the v$logstdby_stats view is as
follows:
NAME VALUE
----- ---------
number of preparers 1
number of appliers
1
maximum SGA for LCR cache 2
parallel servers in use
5
maximum events recorded 100
transaction consistency FULL
record skip errors
Y
record skip DDL
Y
record applied DDL
Y
NAME VALUE
----- ---------
coordinator state
APPLYING
transactions ready
2
transactions applied
2
coordinator uptime
4
preparer memory alloc waits
2
builder memory alloc waits
2346
attempts to handle low memory
2346
successful low memory recovery
1
pageout avoided
0
pageout avoided by rollback
0
pageouts
0
memory low watermark reached
0
recovery checkpoints not taken
0
recovery checkpoints taken
0
available work units
155
prepared work units
0
committed txns ready
0
un-committed txns ready
0
committed txns being applied
0
un-committed txns being applied
0
Monitoring Log Apply Services
Column
Thread format 99
Column Status_Code format a10
Select
l.FILE_NAME Archive_Log_Name,
l.THREAD# Thread,
e.STATUS_CODE Status_Code
From
DBA_LOGSTDBY_LOG l,
DBA_LOGSTDBY_EVENTS e
SEE
CODE DEPOT FOR FULL SCRIPT
|