ORACLE DataGuard Logical Standby 详解之：管理逻辑Standby的相关视图

• Dataguard Logical Standby 系列文章:
• 一、逻辑Standby的准备工作
• 二、逻辑Standby创建时的操作步骤
• 三、管理逻辑Standby的相关视图
• 四、逻辑Standby数据库的自定义配置
• 五、修改逻辑Standby端数据
• 六、优化逻辑Standby数据同步性能
• 七、利用REDO数据到Standby数据库

本节内容

1．DBA_LOGSTDBY_EVENTS
可以把该视图看成逻辑Standby操作日志，因此如果产生了毛病，可以通过该视图查看近期逻辑Standby都做了些甚么。默许情况下，该视图只保存最近100条事件的记录（可以通过相关进程修改保存的记录条数）。
例如：
SQL> SELECT EVENT_TIME,STATUS,EVENT FROM DBA_LOGSTDBY_EVENTS
ORDER BY EVENT_TIMESTAMP;
EVENT_TIM STATUS EVENT
05-MAY⑴0 ORA⑴6111: log mining and apply setting up
05-MAY⑴0 ORA⑴6257: Switchover initiated stop apply success

2．DBA_LOGSTDBY_LOG
该视图用来记录当前的重做日志的利用情况，功能类似于物理Standby中的V$ARCHIVED_LOG。
多数情况下，你只需要关注SEQUENCE#、APPLIED等有限的几个列，即查看日志序号和会不会利用，固然该视图还可以提供更多信息，如利用的SCN、利用时间等，例如：
SQL> SELECT SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE#,
TIMESTAMP,APPLIED FROM DBA_LOGSTDBY_LOG;
SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# TIMESTAMP APPLIED

通常情况下，该查询只会返回几条记录，如果说你的数据库操作非常频���，可能记录数会稍多一些，但如果记录数非常多，那你就需要关注一下，是不是是出了甚么问题，难道SQL利用没有启动？

3．V$LOGSTDBY_STATS
该视图就是用来显示LogMiner的状态等相关信息，例如：
SQL> SELECT *FROM V$LOGSTDBY_STATS;
NAME VALUE
number of preparers 1
number of appliers 5
maximum SGA for LCR cache 30
parallel servers in use 9
maximum events recorded 100
preserve commit order TRUE
transaction consistency FULL
record skip errors Y
record skip DDL Y
record applied DDL N
record unsupported operations N

4．V$LOGSTDBY_PROCESS
该视图显示当前日志利用服务的相关信息。经常使用于诊断归档日志逻辑利用的性能问题（后面优化部份会触及），包括的信息也很广，包括：
身份信息：SID、SERIAL#、SPID。
SQL利用进程：COORDINATOR、READER、BUILDER、PREPARER、ANALYZER、或APPLIER。
进程当前的状态：见STATUS_CODE或STATUS列。
该进程当前操作REDO记录最大SCN：HIGH_SCN列。
例如：
SQL> SELECT SID,SERIAL#,SPID,TYPE,STATUS,HIGH_SCN FROM V$LOGSTDBY_PROCESS;
SID SERIAL# SPID TYPE STATUS
139 303 6831 COORDINATOR ORA⑴6116: no work available
153 292 6833 READER ORA⑴6240: Waiting for logfil
136 5 6835 BUILDER ORA⑴6116: no work available
137 5 6837 PREPARER ORA⑴6116: no work available
128 1 6841 ANALYZER ORA⑴6116: no work available
132 1 6843 APPLIER ORA⑴6116: no work available
133 2 6845 APPLIER ORA⑴6116: no work available
130 1 6847 APPLIER ORA⑴6116: no work available
129 1 6849 APPLIER ORA⑴6116: no work available
131 1 6851 APPLIER ORA⑴6116: no work available

5．V$LOGSTDBY_PROGRESS
该视图显示LOG利用服务当前进展状态，如当前利用到逻辑Standby的SCN及时间，SQL利用开始利用的SCN及时间，最后接收及利用的SCN和时间等。

例如，查看当前利用的SCN信息：
SQL> SELECT APPLIED_SCN, LATEST_SCN, MINING_SCN, RESTART_SCN FROM V$LOGSTDBY_PROGRESS;
APPLIED_SCN LATEST_SCN MINING_SCN RESTART_SCN
572164 572232 572166

6．V$LOGSTDBY_STATE
该视图显示SQL利用的大致状态，如Primary数据库的DBID，会不会实时利用，当前SQL利用的状态。需要注意的是该视图的STATE列，该列可能有下述的几种状态。利用日志的进程，也是这几种状态相互转换的进程。

1) INITIALIZING初始化状态。
履行ALTER DATABASE START LOGICAL STANDBY APPLY语句，启动SQL利用时，首先就会进入初始化状态，例如：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered.
SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;
SESSION_ID STATE
21 INITIALIZING
这个状态存在的时间非常短暂，多数情况下只有当ALTER DATABASE START LOGICAL STANDBY APPLY履行时查看V$LOGSTDBY_STATE视图，会看到初始化状态，一旦该命令履行完，状态就被切换为等待字典日志或利用中的状态了。

2) WAITING FOR DICTIONARY LOGS等待数据字典日志。
指第一次初始化时的状态，如刚从物理Standby转换成逻辑Standby，需要首先利用来自Primary端生成的数据字典，在等待Primary数据字典信息时，就会处于这一状态。例如：
SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;
SESSION_ID STATE
21 WAITING FOR DICTIONARY LOGS
这个进程也非常短暂。

3) LOADING DICTIONARY加载并分析。
当查询V$LOGSTDBY_STATE视图，显示以下状态时，说明处于加载数据字典的状态：
SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;
SESSION_ID STATE
21 LOADING DICTIONARY

对比较大型的数据库系统，加载数据字典需要一些时间。此时还可以查询V$lOGMNR_DICTIONARY_LOAD视图获得关于加载的更详细的信息，例如：

SQL>SELECT PERCENT_DONE, COMMAND FROM V$LOGMNR_DICTIONARY_LOAD
WHERE SESSION_ID =(SELECT SESSION_ID FROM V$LOGSTDBY_STATE);
APPLYING利用REDO数据。
SQL利用正在处理中，如果要查看当前的处理进度，可以通过V$LOGSTDBY_PROGRESS视图完成。

4) WAITING ON GAP中断等待状态。
SQL利用发掘并利用了所有可用的REDO数据，正等待新的日志文件，也有多是由于归档文件有中断酿成的。如果查询V$LOGSTDBY_STATE视图时发现处于这一状态，应当同时查询V$ARCHIVE_GAP视图，检查会不会有中断的归档。

5) IDLE空闲状态。
处于这一状态也有可能不是好现象，一方面多是逻辑Standby处理能力优秀，所有活都干完了；也多是Primary数据库发送日志或逻辑Standby日志出现了问题，致使SQL利用无活可干，因此处于空闲状态。
如果你发现你的逻辑Standby数据库长时间处于这一状态，建议查询DBA_LOGSTDBY_LOG视图，确认Primary端产生的日志文件能被逻辑Standby数据库正常接收。

6) SQL APPLY NOT ON。
如果你查询V$LOGSTDBY_STATE视图时发现提示这一状态，说明逻辑Standby数据库根本没启动SQL利用。