本文作者：
junsansi
转载网址：
http://www.5ienet.com/index.shtml
第二部分物理standby(4)高级管理 2008.1.13
世上没有永恒的主角，能够留住永恒的反是那些默默无闻的小角色，这一节出场的都是重量级选手，它们虽然不是主角，但他们比主角更重要(有时候)。
一、READONLY/WRITE模式打开物理STANDBY
前面提到关于物理standby 可以有效分担primary 数据库压力，提升资源利用，实际上说的就是这个。以readonly 或read write 模式打开物理standby，你可以转移一些查询任何啦，备份啦之类的操作到standby 数据库，以这种方式来分担一些primary 的压力。下面我们来演示一下，如何切换standby 数据库的打开模式，其实，非常简单。例如，以Read-only 模式打开物理standby：
这里要分两种情况：
1).standby 数据库处于shutdown 状态
直接startup 即可。
SQL> startup
ORACLE 例程已经启动。
......
2).standby 数据库处于redo 应用状态
首先取消redo 应用：
SQL> alter database recover managed standby database cancel;
数据库已更改。
然后再打开数据库
SQL> alter database open ;
数据库已更改。
提示：open 的时候不需要附加read only 子句，oracle 会根据控制文件判断是否是物理standby，从而自动启动到read only 模式，直接startup 也是同理。
3).如果想从open 状态再切换回redo 应用状态，并不需要shutdown，直接启用redo 应用即可，例如：
SQL> select status from v$instance;
STATUS
------------
OPEN
SQL> alter database recover managed standby database disconnect from session;
数据库已更改。
SQL> select status from v$instance;
STATUS
------------
MOUNTED
正如演示中我们所看到的，操作有一点点复杂，并且由于只读打开时就不能应用，虽然我们能够查询，但是查询的结果确是与primary 不同步的，这点大大降低了物理standby 做报表服务分担主库压力的可能性，对于这点呢，我们有两个解决方案：
1、改用逻辑standby，由于逻辑standby 是打开状态下的实时应用，因此数据同步应该是没啥问题了（只要primary 的数据类型和操作逻辑standby 都能被支持），当然逻辑standby 有逻辑standby 的问题，这个看完后面的逻辑standby 相关章节，您就明白了。
2、据称oracle11g 全面改良了物理standby，最突出的特点就是在read only 打开模式下，可以边接收边应用了（这下不用担心查询的数据不及时的问题了），您可以考虑升级您的数据库到最新版本，当然新版本也有新版本的问题，比如各种尚未暴露出来的bug，想想就担心是不是:)
所以你看，做技术其实并不困难，难的是做决择。这么引申过来看一看，老板们不容易啊，怪不得越大的领导脑袋上头发越少呢，为了保持我干净整洁浓密的发型，我我，我还是选择干技术吧~~~~
二、管理影响standby的primary数据库事件
为预防可能的错误，你必须知道primary 数据库的某些事件可能影响standby 数据库，并且了解如何处理。
某些情况下，primary 数据库的某些改动会自动通过redo 数据传播到standby 数据库，因此不需要在standby数据库做额外的操作，而某些情况，则需要你手工调整。
下列事件会由redo 传输服务及redo 应用自动处理，不需要dba 的干预，分别是：
● ALTER DATABASE ENABLE|DISABLE THREAD 语句(主要针对rac 环境，目前基本已废弃，因为ENABLE|DISABLE INSTANCE 子句完全能够实现类似功能)
● 修改表空间状态(例如read-write 到read-only，online 到offline)
● 创建修改删除表空间或数据文件(如果初始化参数STANDBY_FILE_MANAGEMENT 被设置为AUTO 的话，这点在前面第一章的时候提到过)
下列事情则需要dba 手工干预：
1、添加修改删除数据文件或表空间
前面提到了，初始化参数STANDBY_FILE_MANAGEMENT 可以控制是否自动将primary 数据库增加删除表空间、数据文件的改动继承到standby。
● 如果该参数值设置为auto，则自动创建。
● 如果设置为manual，则需要手工复制新创建的数据文件到standby 服务器。
不过需要注意一点， 如果数据文件是从其它数据库复制而来( 比如通过tts) ， 则不管STANDBY_FILE_MANAGEMENT 参数值如何设置，都必须同时复制到standby 数据库，并注意要修改standby 数据库的控制文件。
下面分别通过示例演示STANDBY_FILE_MANAGEMENT 参数值为AUTO/MANUAL 值时增加及删除
数据文件时的情形：
1).STANDBY_FILE_MANAGEMENT设置为AUTO，增加及删除表空间和数据文件
我们先来看看初始化参数的设置： ----standby 数据库操作
SQL> show parameter standby_file
NAME TYPE VALUE
----------------------------- ----------- ---------------
standby_file_management string AUTO
A).增加新的表空间--primary 数据库操作
SQL> create tablespace mytmp datafile 'e:\ora10g\oradata\jssweb\mytmp01.dbf' size 20m;
表空间已创建。
检查刚添加的数据文件
SQL> select name from v$datafile;
NAME
-----------------------------------------------
E:\ORA10G\ORADATA\JSSWEB\SYSTEM01.DBF
E:\ORA10G\ORADATA\JSSWEB\UNDOTBS01.DBF
E:\ORA10G\ORADATA\JSSWEB\SYSAUX01.DBF
E:\ORA10G\ORADATA\JSSWEB\USERS01.DBF
E:\ORA10G\ORADATA\JSSWEB\WEBTBS01.DBF
E:\ORA10G\ORADATA\JSSWEB\MYTMP01.DBF
已选择6 行。
切换日志
SQL> alter system switch logfile;
系统已更改。
B).验证standby 库--standby 数据库操作
SQL> select name from v$datafile;
NAME
----------------------------------------------------
E:\ORA10G\ORADATA\JSSPDG\SYSTEM01.DBF
E:\ORA10G\ORADATA\JSSPDG\UNDOTBS01.DBF
E:\ORA10G\ORADATA\JSSPDG\SYSAUX01.DBF
E:\ORA10G\ORADATA\JSSPDG\USERS01.DBF
E:\ORA10G\ORADATA\JSSPDG\WEBTBS01.DBF
E:\ORA10G\ORADATA\JSSPDG\MYTMP01.DBF
已选择6 行。
SQL> select name from v$tablespace;
NAME
------------------------------
SYSTEM
UNDOTBS1
SYSAUX
TEMP
USERS
WEBTBS
MYTMP
已选择7 行。
可以看到，表空间和数据文件已经自动创建，你是不是奇怪为什么数据文件路径自动变成了jsspdg，赫赫，因为我们设置了db_file_name_convert 嘛。
C).删除表空间--primary 数据库操作
SQL> drop tablespace mytmp including contents and datafiles;
表空间已删除。
SQL> select name from v$datafile;
NAME
--------------------------------------------------
E:\ORA10G\ORADATA\JSSWEB\SYSTEM01.DBF
E:\ORA10G\ORADATA\JSSWEB\UNDOTBS01.DBF
E:\ORA10G\ORADATA\JSSWEB\SYSAUX01.DBF
E:\ORA10G\ORADATA\JSSWEB\USERS01.DBF
E:\ORA10G\ORADATA\JSSWEB\WEBTBS01.DBF
SQL> alter system switch logfile;
系统已更改。
提示：使用including 子句删除表空间时，
D).验证standby 数据库--standby 数据库操作
SQL> select name from v$datafile;
NAME
--------------------------------------------------
E:\ORA10G\ORADATA\JSSPDG\SYSTEM01.DBF
E:\ORA10G\ORADATA\JSSPDG\UNDOTBS01.DBF
E:\ORA10G\ORADATA\JSSPDG\SYSAUX01.DBF
E:\ORA10G\ORADATA\JSSPDG\USERS01.DBF
E:\ORA10G\ORADATA\JSSPDG\WEBTBS01.DBF
SQL> select name from v$tablespace;
NAME
------------------------------
SYSTEM
UNDOTBS1
SYSAUX
TEMP
USERS
WEBTBS
已选择6 行。
得出结论，对于初始化参数STANDBY_FILE_MANAGMENT 设置为auto 的话，对于表空间和数据文件的操作完全无须dba 手工干预，primary 和standby 都能很好的处理。
2).STANDBY_FILE_MANAGEMENT设置为MANUAL，增加及删除表空间和数据文件
A).增加新的表空间--primary 数据库操作
SQL> create tablespace mytmp datafile 'e:\ora10g\oradata\jssweb\mytmp01.dbf' size 20m;
表空间已创建。
检查刚添加的数据文件
SQL> select name from v$datafile;
NAME
-----------------------------------------------
E:\ORA10G\ORADATA\JSSWEB\SYSTEM01.DBF
E:\ORA10G\ORADATA\JSSWEB\UNDOTBS01.DBF
E:\ORA10G\ORADATA\JSSWEB\SYSAUX01.DBF
E:\ORA10G\ORADATA\JSSWEB\USERS01.DBF
E:\ORA10G\ORADATA\JSSWEB\WEBTBS01.DBF
E:\ORA10G\ORADATA\JSSWEB\MYTMP01.DBF
已选择6 行。
切换日志
SQL> alter system switch logfile;
系统已更改。
B).验证standby 库--standby 数据库操作
SQL> select name from v$datafile;
NAME
----------------------------------------------------
E:\ORA10G\ORADATA\JSSPDG\SYSTEM01.DBF
E:\ORA10G\ORADATA\JSSPDG\UNDOTBS01.DBF
E:\ORA10G\ORADATA\JSSPDG\SYSAUX01.DBF
E:\ORA10G\ORADATA\JSSPDG\USERS01.DBF
E:\ORA10G\ORADATA\JSSPDG\WEBTBS01.DBF
E:\ORA10G\PRODUCT\10.2.0\DB_1\DATABASE\UNNAMED00006
已选择6 行。
SQL> select name from v$tablespace;
NAME
------------------------------
SYSTEM
UNDOTBS1
SYSAUX
TEMP
USERS
WEBTBS
MYTMP
已选择7 行。
可以看到，表空间已经自动创建，但是，数据文件却被起了个怪名字，手工修改其与primary
数据库保持一致，如下(注意执行命令之后手工复制数据文件到standby)：
SQL> alter database create datafile'E:\ORA10G\PRODUCT\10.2.0\DB_1\DATABASE\UNNAMED00006'
2 as 'E:\ora10g\oradata\jsspdg\mytmp01.dbf';
数据库已更改。
C).删除表空间--primary 数据库操作
SQL> drop tablespace mytmp including contents and datafiles;
表空间已删除。
SQL> select name from v$datafile;
NAME
--------------------------------------------------
E:\ORA10G\ORADATA\JSSWEB\SYSTEM01.DBF
E:\ORA10G\ORADATA\JSSWEB\UNDOTBS01.DBF
E:\ORA10G\ORADATA\JSSWEB\SYSAUX01.DBF
E:\ORA10G\ORADATA\JSSWEB\USERS01.DBF
E:\ORA10G\ORADATA\JSSWEB\WEBTBS01.DBF
SQL> alter system switch logfile;
系统已更改。
D).验证standby 数据库--standby 数据库操作
SQL> select name from v$datafile;
NAME
----------------------------------------------------
E:\ORA10G\ORADATA\JSSPDG\SYSTEM01.DBF
E:\ORA10G\ORADATA\JSSPDG\UNDOTBS01.DBF
E:\ORA10G\ORADATA\JSSPDG\SYSAUX01.DBF
E:\ORA10G\ORADATA\JSSPDG\USERS01.DBF
E:\ORA10G\ORADATA\JSSPDG\WEBTBS01.DBF
E:\ORA10G\PRODUCT\10.2.0\DB_1\DATABASE\UNNAMED00006
已选择6 行。
SQL> select name from v$tablespace;
NAME
------------------------------
SYSTEM
UNDOTBS1
SYSAUX
TEMP
USERS
WEBTBS
MYTMP
已选择7 行。
呀，数据还在啊。赶紧分析分析，查看alert_jsspdg.log 文件，发现如下(特别注意粗体)：
File #6 added to control file as 'UNNAMED00006' because
the parameter STANDBY_FILE_MANAGEMENT is set to MANUAL
The file should be manually created to continue.
Errors with log E:\ORA10G\ORADATA\JSSPDG\LOG1_753_641301252.ARC
MRPMRP0:BackgroundMediaRecoveryterminatedwitherror1274
Fri Jan 18 09:48:45 2008
这下明白了，为什么有个UNNAMED00006 的数据文件，也晓得为啥standby 数据库没能删除新加的表空间了吧，原来是后台的redo 应用被停掉了，重启redo 应用再来看看：
SQL> alter database recover managed standby database disconnect from session;
数据库已更改。
SQL> select name from v$datafile;
NAME
----------------------------------------------
E:\ORA10G\ORADATA\JSSPDG\SYSTEM01.DBF
E:\ORA10G\ORADATA\JSSPDG\UNDOTBS01.DBF
E:\ORA10G\ORADATA\JSSPDG\SYSAUX01.DBF
E:\ORA10G\ORADATA\JSSPDG\USERS01.DBF
E:\ORA10G\ORADATA\JSSPDG\WEBTBS01.DBF
注意，既使你在primary 数据库执行删除时加上了including 子句，在standby 数据库仍然只会将表空间和数据文件从数据字典中删除，你还需要手工删除表空间涉及的数据文件。
再次得出结论，初始化参数STANDBY_FILE_MANAGMENT 设置为manual 的话，对于表空间和数据文件的操作必须有dba 手工介入，你肯定会问，这太麻烦了，那我干脆配置dg 的时候直接把初始化参数设置为auto 不就好了嘛，en，你想的很好，不过三思需要提醒你地是，如果你的存储采用文件系统，那当然没有问题，但是如果采用了裸设备，你就必须将该参数设置为manual。
2、重命名数据文件
如果primary 数据库重命令了一个或多个数据文件，该项修改并不会自动传播到standby 数据库。因为此，如果你想让standby 和数据文件与primary 保持一致，那你也只能自己手工操作了。这会儿就算STANDBY_FILE_MANAGEMENT 也帮不上忙啦，不管它是auto 还是manual。下面通过示例做个演示：
A).将重命名的数据文件所在表空间offline --primary 数据库操作
SQL> alter tablespace webtbs offline;
表空间已更改。
B).手工将数据文件改名(操作系统) --primary 数据库操作
方式多样，不详述。
C).通过命令修改数据字典中的数据文件路径，并online 表空间--primary 数据库操作
SQL> alter tablespace webtbs rename datafile
2 'E:\ORA10G\ORADATA\JSSWEB\WEBTBS01.DBF' to
3 'E:\ORA10G\ORADATA\JSSWEB\TBSWEB01.DBF';
表空间已更改。
SQL> alter tablespace webtbs online;
表空间已更改。
D).暂停redo 应用，并shutdown --standby 数据库操作
SQL> alter database recover managed standby database cancel;
数据库已更改。
SQL> shutdown immediate
ORA-01109: 数据库未打开
......
E).手工将数据文件改名(操作系统) --standby 数据库操作
方式多样，不详述。
F).重启standby，修改数据文件路径(数据字典) --standby 数据库操作
SQL> startup mount
ORACLE 例程已经启动。
Total System Global Area 167772160 bytes
Fixed Size 1289484 bytes
Variable Size 150995700 bytes
Database Buffers 8388608 bytes
Redo Buffers 7098368 bytes
数据库装载完毕。
SQL> alter database rename file
2 'E:\ORA10G\ORADATA\JSSPDG\WEBTBS01.DBF' to
3 'E:\ORA10G\ORADATA\JSSPDG\TBSWEB01.DBF';
数据库已更改。
G).重新启动redo 应用。
SQL> alter database recover managed standby database disconnect from session;
数据库已更改。
H).切换日志--primary 数据库操作
SQL> alter system switch logfile;
系统已更改。
峻工~~~~
3、添加或删除OnlinOnlineredologs
数据库调优时极有可能会涉及到重置日志文件大小或增加删除日志组等操作，基本上这种操作不会传播到standby 数据库，也不会影响到standby 数据库的运行，但是如果你不注意其中的关系，造成的影响可能会很深远，比如，我们假设我们的一台primary 数据库拥有5 组online redo 文件，standby 数据库拥有2 组，当你执行switch over 之后，新的primary 执行归档的频率会比standby 高的多，因此，当你在primary 数据库增加或移除online redologs 时，一定记的手工同步一相standby 数据库中相关的设置。
这就是我们前面提到的standby redologs 与online redologs 之间的关系，即保证standby redologs 比onlineredologs 要至少多一组。
操作的过程很简单(总不会复杂过添加删除数据文件)，这里就不演示了，需要你注意的就是在standby做操作前务必将STANDBY_FILE_MANAGEMENT 设置为MANUAL。
三、对openresetlogs的primary数据库standby的恢复
当primary 数据库被以resetlogs 打开之后，dg 提供了一些方案，能够让你快速的恢复物理standby，当然这是有条件的，不可能所有的情况都可以快速恢复。我们都知道alter database open resetlogs 之后，数据库的scn被重置，也就是此时其redo 数据也会从头开始。当物理standby 接收到新的redo 数据时，redo 应用会自动获取这部分redo 数据。对于物理standby 而言，只要数据库没有应用resetlogs 之后的redo 数据，那么这个过程是不需要dba 手工参与的。
下表描述其它情况下如何同步standby 与primary 数据库。
|
Standby数据库状态
|
Standby服务器操作
|
解决方案
|
|
没有应用resetlog之前的redo数据
|
自动应用新的redo数据
|
无须手工介入
|
|
应用了resetlog之后的redo数据，不过standby打开了flashback。
|
可以应用，不过需要dba手工介入
|
1.手工flashback到应用之前
2.重启redo应用，以重新接收新的redo数据。
|
|
应用了resetlog之后的redo数据，而且没有flashback。
|
完全无法应用
|
重建物理standby是唯一的选择
|
很绕是吧，举个例子你就明白了：
假设primary 数据库当前生成的archive sequence#如下：...26,27,28，然后在28 的时候执行了resetlogs，又生成了新的1,2,3.....，那么standby 能够正常接收并应用26,27,28 及新产生的1,2,3....
如果primary 数据库在28 的时候发生数据出现故障，recover 到27，然后resetlogs，又生成了新的1,2,3.....这个时候(大家注意，招子放亮点)：如果standby 还没有应用28，刚刚应用到27，则standby 还可以继续接收新
的redo 数据1,2,3.....并应用。
如果此时不幸，standby 由于是实时应用，已经应用了28 的redo 数据，那么如果standby 打开了flashback，不幸中的万幸啊，这时候只需要dba 手工介绍先flashback 到27,然后再接收并应用新的1,2,3....
如果此时非常不幸，standby 由于是实时应用，已经应用了28 的redo 数据，并且standby 也没有打开flashback，那么，重建物理standby 是你唯一的选择。
这下大家都明白了吧，赶紧起立鼓掌感谢yangtingkun 大大的友情客串及形象示例，很通俗，很易懂:)。
四、监控primary/standby数据库
本节主要介绍一些监控dg 配置的方式，先给大家提供一个表格(描述不同事件的不同信息监控途径)：
|
primary数据库事件
|
primary监控途径
|
standby监控途径
|
|
带有enable|disable thread子句的alterdatabase命令
|
Alert.log
V$THREAD
|
Alert.log
|
|
当前数据库角色，保护模式，保护级别，switchover状态，failover快速启动信息等
|
V$DATABASE
|
V$DATABASE
|
|
Redo log切换
|
Alert.log
V$LOG
V$LOGFILE的status列
|
Alert.log
|
|
重建控制文件
|
Alert log
|
Alert log
|
|
手动执行恢复
|
Alert log
|
Alert log
|
|
表空间状态修改(read-write/read-only,online/offline)
|
DBA_TABLESPACES
Alert log
|
V$RECOVER_FILE
|
|
创建删除表空间或数据文件
|
DBA_DATA_FILES
Alert log
|
V$DATAFILE
Alert log
|
|
表空间或数据文件offline
|
V$RECOVER_FILE
Alert log
DBA_TABLESPACES
|
V$RECOVER_FILE
DBA_TABLESPACES
|
|
重命名数据文件
|
V$DATAFILE
Alert log
|
V$DATAFILE
Alert log
|
|
未被日志记录或不可恢复的操作
|
V$DATAFILE view
V$DATABASE view
|
Alert.log
|
|
恢复的进程
|
V$ARCHIVE_DEST_STATUS
Alert log
|
V$ARCHIVED_LOG
V$LOG_HISTORY
V$MANAGED_STANDBY
Alert log
|
|
Redo传输的状态和进度
|
V$ARCHIVE_DEST_STATUS
V$ARCHIVED_LOG
V$ARCHIVE_DEST
Alert log
|
V$ARCHIVED_LOG
Alert log
|
|
数据文件自动扩展
|
Alert log
|
Alert log
|
|
执行OPEN RESETLOGS或CLEAR UNARCHIVED LOGFILES
|
Alert log
|
Alert log
|
|
修改初始化参数
|
Alert log
|
Alert log
|
概括起来主要通过二个方面：
1、AlerAlertLog
一句话：一定要养成有事没事定期不定期随时查看alert.log 的好习惯同时特别注意alert 中的提示通常不经意间会发现它的提示能够让你的思路豁然开朗。
2、动态性能视图
先也是一句话：做为oracle 自己自觉主动维护的一批虚拟表它的作用非常明显通过它可以及时获得当前数据库状态及处理进度总之好处多多也需特别关注后面示例也会多处用到大家要擦亮双眼。
● 先来点与恢复进度相关的v$视图应用示例：
A).查看进程的活动状况---v$managed_standby
该视图就是专为显示standby 数据库相关进程的当前状态信息，例如：
SQL> select process,client_process,sequence#,status from v$managed_standby;
PROCESS CLIENT_P SEQUENCE# STATUS
--------- -------- ---------- ------------
ARCH ARCH 763 CLOSING
ARCH ARCH 762 CLOSING
MRP0 N/A 764 WAIT_FOR_LOG
RFS LGWR 764 IDLE
RFS N/A 0 IDLE
PROCESS：显示进程信息
CLIENT_PROCESS：显示对应的主数据库中的进程
SEQUENCE#：显示归档redo 的序列号
STATUS：显示的进程状态
通过上述查询可以得知primary 开了两个归档进程，使用lgwr 同步传输方式与standby 通信，已经接收完763 的日志，正等待764。
B).确认redo 应用进度---v$archive_dest_status
该视图显示归档文件路径配置信息及redo 的应用情况等，例如：
SQL> select dest_name,archived_thread#,archived_seq#,applied_thread#,applied_seq#,db_unique_name
2 from v$archive_dest_status where status='VALID';
DEST_NAME ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD#APPLIED_SEQ# DB_UNIQUE_
-------------------- ---------------- ------------- --------------- ------------ ----------
LOG_ARCHIVE_DEST_1 1 765 0 0 jsspdg
LOG_ARCHIVE_DEST_2 0 0 0 0 jssweb
STANDBY_ARCHIVE_DEST 1 764 1 764 NONE
C).检查归档文件路径及创建信息---v$archived_log
该视图查询standby 数据库归档文件的一些附加信息，比如文件创建时间啦，创建进程啦，归档序号啦，是否被应用啦之类，例如：
SQL> select name,creator,sequence#,applied,completion_time from v$archived_log;
NAME CREATOR SEQUENCE# APP COMPLETION_TIM
-------------------------------------------------- ------- ---------- --- --------------
E:\ORA10G\ORADATA\JSSPDG\LOG1_750_641301252.ARC ARCH 750 YES 18-1 月-08
E:\ORA10G\ORADATA\JSSPDG\LOG1_749_641301252.ARC ARCH 749 YES 18-1 月-08
E:\ORA10G\ORADATA\JSSPDG\LOG1_751_641301252.ARC ARCH 751 YES 18-1 月-08
E:\ORA10G\ORADATA\JSSPDG\LOG1_752_641301252.ARC ARCH 752 YES 18-1 月-08
E:\ORA10G\ORADATA\JSSPDG\LOG1_753_641301252.ARC ARCH 753 YES 18-1 月-08
E:\ORA10G\ORADATA\JSSPDG\LOG1_754_641301252.ARC ARCH 754 YES 18-1 月-08
D).查询归档历史---v$log_history
该视图查询standby 库中所有已被应用的归档文件信息(不论该归档文件是否还存在)，例如：
SQL> select first_time,first_change#,next_change#,sequence# from v$log_history;
FIRST_TIME FIRST_CHANGE# NEXT_CHANGE# SEQUENCE#
------------------- ------------- ------------ ----------
2008-01-03 12:00:51 499709 528572 18
2008-01-08 09:54:42 528572 539402 19
2008-01-08 22:00:06 539402 547161 20
2008-01-09 01:05:57 547161 560393 21
2008-01-09 10:13:53 560393 561070 22
●再来点与log应用相关的v$视图应用示例：
A).查询当前数据的基本信息---v$database 信息。
例如，查询数据库角色，保护模式，保护级别等：
SQL> selectdatabase_role,db_unique_name,open_mode,protection_mode,protection_level,switchover_status
2 from v$database;
DATABASE_ROLE DB_UNIQUE_NAME OPEN_MODE PROTECTION_MODE PROTECTION_LEVEL SWITCHOVER_STATUS
---------------- --------------- ---------- -------------------- -------------------- ------------------
PHYSICAL STANDBY jsspdg MOUNTED MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY SESSIONS ACTIVE
再比如，查询failover 后快速启动的信息
SQL> select fs_failover_status,fs_failover_current_target,fs_failover_threshold,
2 fs_failover_observer_present from v$database;
FS_FAILOVER_STATUS FS_FAILOVER_CURRENT_TARGET FS_FAILOVER_THRESHOLD FS_FAIL
--------------------- ------------------------------ --------------------- -------
DISABLED 0
B).检查应用模式(是否启用了实时应用)---v$archive_dest_status
查询v$archive_dest_status 视图，如果打开了实时应用，则recovery_mode 会显示为：MANAGEDREAL TIME APPLY，例如：
SQL> select recovery_mode from v$archive_dest_status where dest_id=2;
RECOVERY_MODE
-----------------------
MANAGED REAL TIME APPLY
C).Data guard 事件---v$dataguard_status
该视图显示那些被自动触发写入alert.log 或服务器trace 文件的事件。通常是在你不便访问到服务器查询alert.log 时，可以临时访问本视图查看一些与dataguard 相关的信息，例如：
SQL> select message from v$dataguard_status;
MESSAGE
----------------------------------------------------------------------------
ARC0:Archival started
ARC1:Archival started
ARC0: Becoming the 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH
ARC1: Becoming the heartbeat ARCH
Attempt to start background Managed Standby Recovery process
MRP0: Background Managed Standby Recovery process started
Managed Standby Recovery not using Real Time Apply
Media Recovery Waiting for thread 1 sequence 761
五、调整物理standbylog应用频率
调整应用频率说白了就是调整io 读取能力，所以通常我们可以从以下几个方面着手：
1、设置recover 并行度
在介质恢复或redo 应用期间，都需要读取重做日志文件，默认都是串行恢复，我们可以在执行recover的时候加上parallel 子句来指定并行度，提高读取和应用的性能，例如：
SQL> alter database recover managed standby database parallel 2 disconnect from session;
推荐parallel 的值是#CPUs*2;
2、加快redo 应用频繁
设置初始化参数DB_BLOCK_CHECKING=FALSE 能够提高2 倍左右的应用效率，该参数是验证数据块是否有效， 对于standby 禁止验证基本上还是可以接受的， 另外还有一个关联初始化参数DB_BLOCK_CHECKSUM，建议该参数在primary 和standby 都设置为true。
3、设置PARALLEL_EXECUTION_MESSAGE_SIZE
如果打开了并行恢复，适当提高初始化参数：PARALLEL_EXECUTION_MESSAGE_SIZE 的参数值，比如4096 也能提高大概20%左右的性能，不过需要注意增大这个参数的参数值可能会占用更多内存。
4、优化磁盘I/O
在恢复期间最大瓶颈就是I/O 读写，要缓解这个瓶颈，使用本地异步I/O 并设置初始化参数DISK_ASYNCH_IO=TRUE 会有所帮助。DISK_ASYNCH_IO 参数控制到数据文件的磁盘I/O 是否异步。某些情况下异步I/O 能降低数据库文件并行读取，提高整个恢复时间。
-The End-