维护Data Guard物理standby（原创）

DG日常维护
正确打开主库和备库
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE OPEN;
备库 :
SQL> STARTUP MOUNT;
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
DISCONNECT FROM SESSION;
正确关闭顺序
备库 :
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL>SHUTDOWN IMMEDIATE;
主库
SQL>SHUTDOWN IMMEDIATE;
备库 Read-Only Read-Only模式打开
当前主库正常 OPEN 状态 、 备库处于日志传送状态 .
在备库停止日志传送
SQL> recover managed standby database cancel;
备库 Read-only 模式打开
SQL> alter database open read only;
备库回到日志传送模式
SQL> recover managed standby database disconnect from session;
手工令备库应用归档日志
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
日志传送状态监控
备库察看 RFS(Remote File Service) 接收日志情况和 MRP 应用日志同步主库
况
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。
察看备库是否和主库同步
SQL> SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#,
APPLIED_SEQ# FROM V$ARCHIVE_DEST_STATUS;

select * from v$archive_gap;

注意：11g以后恢复归档日之后会自动注册到备库
察看备库已经归档的redo
SQL> SELECT REGISTRAR, CREATOR, THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# FROM V$ARCHIVED_LOG;
察看备库已经应用的 redo
SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE#
FROM V$LOG_HISTORY;
察看备库接收 , 应用redo数据过程 .
SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;
查看从库上的日志接收情况
SQL> select status,target,archiver,error,process from v$archive_dest;

primary数据库 open resetlogs时的 standby恢复

当 primary数据库被以resetlogs打开之后，dg提供了一些方案，能够让你快速的恢复物理standby ，当然这是有条件的，不可能所有的情况都可以快速恢复。 我们都知道alter database open resetlogs之后，数据库的scn被重置，也就是此时其redo数据也会从头开始。当物理standby接收到新的redo数据时，redo应用会 自动获取这部分redo数据。对于物理standby而言，只要数据库没有应用resetlogs之后 的redo数据，那么这个过程是不需要dba手工参与的。
下表进行了简单的总结

Standby数据库状态	Standby服务器操作	解决方案
没有应用resetlog之前的redo数据	自动应用新的redo数据	无须手工介入
应用了resetlog之后的redo数据，不过standby打开了flashback。	可以应用，不过需要dba手工介入	1. 手工flashback到应用之前 2. 重启redo应用，以重新接收新的redo数据。
应用了resetlog之 后 的redo数据，而且没有flashback。	完全无法应用	重建物理standby是唯一的选择

调整物理Standby端REDO数据应用频率

调整应用频率，说白了就是调整I/O读取能力，所以通常我们从以下几个方面着手：
1）设置RECOVER并行度
在介质恢复或REDO应用期间，都需要读取重做日志文件，默认都是串行恢复，我们可以在执行RECOVER的时候加上PARALLEL子句来指定并行度，提高读取和应用的性能，例如：
SQL> RECOVER STANDBY DATABASE PARALLEL 2 ;
提示: 建议PARALLEL的值为#CPUs×2。
注意: 该设置仅对当前环境有效，Oracle数据库重启之后，默认情况下并行度会恢复至初始值，如果DBA觉着每次执行很麻烦，要通过初始化参数PARALLEL_MAX_SERVERS来设置默认的并行度。
2) 加快REDO应用频繁
设置初始化参数DB_BLOCK_CHECKING=FALSE能够提高2倍左右的应用效率，该参数设置是否验证数据块的有效性，对于物理Standby 数据库，禁止验证基本上还是可以接受的（Primary数据库强烈建议将该参数值设置为TRUE，当然默认就是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能降低数据库文件并行读取，提高整个恢复时间。

参考至: http://junsansi.itpub.net/post/29894/457847
          http://blog.csdn.net/tianlesoftware/article/details/5557410
本文原创，转载请注明出处、作者
如有错误，欢迎指正
邮箱：[e-mail]