维护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

本文原创，转载请注明出处、作者

如有错误，欢迎指正