Monitoring Log Apply Services for Logical

Standby Databases
To monitor the status of archived redo logs and obtain information on log apply services
on a logical standby database, query the fixed views described in this section. You can
also monitor the standby database using Data Guard Manager.

See Also:

Appendix A, "Troubleshooting the Standby Database"

This section contains the following topics:

• Accessing the DBA_LOGSTDBY_EVENTS View

• Accessing the DBA_LOGSTDBY_LOG View
• Accessing the DBA_LOGSTDBY_PROGRESS View
• Accessing the V$LOGSTDBY Fixed View
• Accessing the V$LOGSTDBY_STATS Fixed View

6.6.1 Accessing the DBA_LOGSTDBY_EVENTS View

If log apply services should stop unexpectedly, the reason for the problem is shown in
this view.

Note:

Errors that cause SQL apply operations to stop are always recorded in
the events table (unless there is insufficient space in the system
tablespace). These events are always put into the ALERT.LOG file as
well, with the phrase 'LOGSTDBY event' included in the text. When
querying the view, select the columns in order by EVENT_TIME,
COMMIT_SCN, and CURRENT_SCN. This ordering ensures that a shutdown
failure appears last in the view.

The view also contains other information, such as which DDL statements were applied
and which were skipped. For example:

SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY HH24:MI:SS';

Session altered.

SQL> COLUMN STATUS FORMAT A60

SQL> SELECT EVENT_TIME, STATUS, EVENT FROM DBA_LOGSTDBY_EVENTS
2 ORDER BY EVENT_TIME, COMMIT_SCN;

EVENT_TIME STATUS
-----------------------------------------------------------------------
-------
EVENT

-----------------------------------------------------------------------
--------
23-JUL-02 18:20:12 ORA-16111: log mining and apply setting up
23-JUL-02 18:20:12 ORA-16128: User initiated shut down successfully
completed
23-JUL-02 18:20:12 ORA-16112: log mining and apply stopping
23-JUL-02 18:20:23 ORA-16111: log mining and apply setting up
23-JUL-02 18:55:12 ORA-16128: User initiated shut down successfully
completed
23-JUL-02 18:57:09 ORA-16111: log mining and apply setting up
23-JUL-02 20:21:47 ORA-16204: DDL successfully applied
create table mytable (one number, two varchar(30))
23-JUL-02 20:22:55 ORA-16205: DDL skipped due to skip setting create
database
link mydblink

8 rows selected.

This query shows that log apply services were started and stopped a few times. It also
shows what DDL was applied and skipped. If log apply services had stopped, the last
record in the query would have shown the cause of the problem.

6.6.2 Accessing the DBA_LOGSTDBY_LOG View

The DBA_LOGSTDBY_LOG view provides dynamic information about what is happening to

log apply services. This view is helpful when you are diagnosing performance problems
with log apply services applying archived redo logs to the logical standby database, and it
can be helpful for other problems.

For example:

SQL> SELECT FILE_NAME, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE#,

2> TIMESTAMP, DICT_BEGIN, DICT_END, THREAD# FROM DBA_LOGSTDBY_LOG
3> ORDER BY SEQUENCE#;

FILE_NAME SEQ# FIRST_CHANGE# NEXT_CHANGE# TIMESTAM BEG

END THR#
------------------------- ---- ------------- ------------ -------- ---
--- ----
/oracle/dbs/hq_nyc_2.log 2 101579 101588 11:02:58 NO
NO 1
/oracle/dbs/hq_nyc_3.log 3 101588 142065 11:02:02 NO
NO 1
/oracle/dbs/hq_nyc_4.log 4 142065 142307 11:02:10 NO
NO 1
/oracle/dbs/hq_nyc_5.log 5 142307 142739 11:02:48 YES
YES 1
/oracle/dbs/hq_nyc_6.log 6 142739 143973 12:02:10 NO
NO 1
/oracle/dbs/hq_nyc_7.log 7 143973 144042 01:02:11 NO
NO 1
/oracle/dbs/hq_nyc_8.log 8 144042 144051 01:02:01 NO
NO 1
/oracle/dbs/hq_nyc_9.log 9 144051 144054 01:02:16 NO
NO 1
/oracle/dbs/hq_nyc_10.log 10 144054 144057 01:02:21 NO
NO 1
/oracle/dbs/hq_nyc_11.log 11 144057 144060 01:02:26 NO
NO 1
/oracle/dbs/hq_nyc_12.log 12 144060 144089 01:02:30 NO
NO 1
/oracle/dbs/hq_nyc_13.log 13 144089 144147 01:02:41 NO
NO 1

The output from this query shows that a LogMiner dictionary build starts at log file
sequence number 5. The most recent archive log file is sequence number 13 and it was
received at the logical standby database at 01:02:41.

6.6.3 Accessing the DBA_LOGSTDBY_PROGRESS View

To quickly determine if all log file information was applied, issue the following query on
the logical standby database:

SQL> SELECT APPLIED_SCN, NEWEST_SCN FROM D BA_LOGSTDBY_PROGRESS;

APPLIED_SCN NEWEST_SCN
----------- ----------
211301 211357

If the APPLIED_SCN matches the NEWEST_SCN, then all available log information was
applied. To determine how much progress was made through the available logs, join the
DBA_LOGSTDBY_PROGRESS view with the DBA_LOGSTDBY_LOG view, as shown in the
following example:

SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY HH24:MI:SS';

Session altered.

SQL> SELECT L.SEQUENCE#, L.FIRST_TIME,

2 (CASE WHEN L.NEXT_CHANGE# < P.READ_SCN THEN 'YES'
3 WHEN L.FIRST_CHANGE# < P.APPLIED_SCN THEN 'CURRENT'
4 ELSE 'NO' END) APPLIED
5 FROM DBA_LOGSTDBY_LOG L, DBA_LOGSTDBY_PROGRESS P
6 ORDER BY SEQUENCE#;

SEQUENCE# FIRST_TIME APPLIED

---------- ------------------ -------
24 23-JUL-02 18:19:05 YES
25 23-JUL-02 18:19:48 YES
 26 23-JUL-02 18:19:51 YES
27 23-JUL-02 18:19:54 YES
28 23-JUL-02 18:19:59 YES
29 23-JUL-02 18:20:03 YES
30 23-JUL-02 18:20:13 YES
31 23-JUL-02 18:20:18 YES
32 23-JUL-02 18:20:21 YES
33 23-JUL-02 18:32:11 YES
34 23-JUL-02 18:32:19 CURRENT
35 23-JUL-02 19:13:20 CURRENT
36 23-JUL-02 19:13:43 CURRENT
37 23-JUL-02 19:13:46 CURRENT
38 23-JUL-02 19:13:50 CURRENT
39 23-JUL-02 19:13:54 CURRENT
40 23-JUL-02 19:14:01 CURRENT
41 23-JUL-02 19:15:11 NO
42 23-JUL-02 19:15:54 NO

19 rows selected.

In the previous query, the computed APPLIED column displays YES, CURRENT, NO. The
logs with YES were completely applied and those files are no longer needed by the logical
standby database. The logs with CURRENT contain information that is currently being
worked on. Because logical standby applies transactions, and because transactions span
logs, it is common for log apply services to be applying changes from multiple logs. For
logs with NO, information from those files is not being applied. Although it is possible
that the files might have been open and read.

6.6.4 Accessing the V$LOGSTDBY Fixed View

To inspect the process activity for SQL apply operations, query the V$LOGSTDBY fixed
view on the logical standby database. For example:

SQL> COLUMN STATUS FORMAT A50

SQL> COLUMN TYPE FORMAT A12
SQL> SELECT TYPE, HIGH_SCN, STATUS FROM V$LOGSTDBY;

TYPE HIGH_SCN STATUS

------------ ----------
--------------------------------------------------
COORDINATOR ORA-16117: processing
READER ORA-16127: stalled waiting for additional
transact
ions to be applied

BUILDER 191896 ORA-16116: no work available

PREPARER 191902 ORA-16117: processing
ANALYZER 191820 ORA-16120: dependencies being computed for
transac
tion at SCN 0x0000.0002ed4e
APPLIER 191209 ORA-16124: transaction 1 16 1598 is waiting on
ano
ther transaction

APPLIER 191205 ORA-16116: no work available

APPLIER 191206 ORA-16124: transaction 1 5 1603 is waiting on
anot
her transaction

APPLIER 191213 ORA-16117: processing

APPLIER 191212 ORA-16124: transaction 1 20 1601 is waiting on
ano
ther transaction

APPLIER 191216 ORA-16124: transaction 1 4 1602 is waiting on

anot
her transaction

11 rows selected.

The previous query displays one row for each process involved in reading and applying
redo logs. The different processes perform different functions as described by the TYPE
column. The HIGH_SCN column is a progress indicator. As long as it keeps changing, from
query to query, you know progress is being made. The STATUS column gives a text
description of activity.

6.6.5 Accessing the V$LOGSTDBY_STATS Fixed View

The V$LOGSTDBY_STATS fixed view provides a collection of state and statistical

information for log apply services. Most options have default values, and this view
displays what values are currently in use. It also provides statistical information that helps
indicate progress. Issue the following query to view database state information:

SQL> COLUMN NAME FORMAT A35

SQL> COLUMN VALUE FORMAT A35
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS
2> WHERE NAME LIKE 'coordinator%' or NAME LIKE 'transactions%';

NAME VALUE
----------------------------------- -----------------------------------
coordinator state APPLYING
transactions ready 7821
transactions applied 7802
coordinator uptime 73

This query shows how long SQL apply operations have been running and how many
transactions have been applied in that time. It also shows how many transactions are
available to be applied, indicating that more work is necessary.