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-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
通常情况下,该查询只会返回几条记录,如果说你的数据库操作非常频���,可能记录数会稍多一些,但如果记录数非常多,那你就需要关注一下,是不是出了什么问题,难道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-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_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应用。