Oracle DG 逻辑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-10 ORA-16111: log mining and apply setting up
05-MAY-10 ORA-16257: 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
---------- ------------- ------------ --------- --------
110 572160 572171 05-MAY-10 CURRENT
111 572171 572175 05-MAY-10 NO
通常情况下，该查询只会返回几条记录，如果说你的数据库操作非常频繁，可能记录数会稍多一些，但如果记录数非常多，那你就需要关注一下，是不是出了什么问题，难道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 operationsN
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 FROMV$LOGSTDBY_PROCESS;
SID SERIAL# SPID TYPE STATUS
---------- ---------- ------------ --------------- -----------------------------
139 303 6831 COORDINATOR ORA-16116: no work available
153 292 6833 READER ORA-16240: Waiting for logfil
136 5 6835 BUILDER ORA-16116: no work available
137 5 6837 PREPARER ORA-16116: no work available
128 1 6841 ANALYZER ORA-16116: no work available
132 1 6843 APPLIER ORA-16116: no work available
133 2 6845 APPLIER ORA-16116: no work available
130 1 6847 APPLIER ORA-16116: no work available
129 1 6849 APPLIER ORA-16116: no work available
131 1 6851 APPLIER ORA-16116: 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_SCNLATEST_SCNMINING_SCNRESTART_SCN
----------- ---------- ---------- -----------
572164 572232 572166
6.V$LOGSTDBY_STATE
该视图显示SQL应用的大致状态，如Primary数据库的DBID，是否实时应用，当前SQL应用的状态。需要注意的是该视图的STATE列，该列可能有下述的几种状态。应用日志的过程，也是这几种状态相互转换的过程。
（1） INITIALIZING初始化状态。
执行ALTER DATABASE START LOGICAL STANDBY APPLY语句，启动SQL应用时，首先就会进入初始化状态，例如：
SQL>>
Database> 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）> 处于这一状态也有可能不是好现象，一方面可能是逻辑Standby处理能力优秀，所有活都干完了；也可能是Primary数据库发送日志或逻辑Standby日志出现了问题，导致SQL应用无活可干，因此处于空闲状态。
如果你发现你的逻辑Standby数据库长期处于这一状态，建议查询DBA_LOGSTDBY_LOG视图，确认Primary端产生的日志文件能被逻辑Standby数据库正常接收。
（6）SQL APPLY NOT ON。
如果你查询V$LOGSTDBY_STATE视图时发现提示这一状态，说明逻辑Standby数据库根本没启动SQL应用。
oracle视频教程请关注:http://u.youku.com/user_video/id_UMzAzMjkxMjE2.html
页:
[1]