物理Data Guard的日常维护
关闭顺序
1. 首先关闭primary数据库
$ sqlplus / as sysdba SQL> shutdown immediate
2. 关闭standby数据库
$ sqlplus / as sysdba --查看备库是否在应用日志进行恢复 SQL>select process, status from v$managed_standby; -- 取消日志应用 SQL> alter database recover managed standby database cancel; SQL> shutdown immediate
开启主库和备库
1.开启standby数据库
SQL> STARTUP MOUNT; SQL> alter database recover managed standby database disconnect from session;
2.开启主库
SQL> startup
备库 Read-Only Read-Only模式打开
---在备库停止日志传送 SQL> recover managed standby database cancel; 完成介质恢复。 ---备库 Read-only 模式打开 SQL> alter database open read only; 数据库已更改。 ---备库回到日志传送模式 SQL> recover managed standby database 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 67 CLOSING ARCH ARCH 69 CLOSING ARCH ARCH 0 CONNECTED ARCH ARCH 0 CONNECTED MRP0 N/A 71 WAIT_FOR_LOG RFS N/A 0 IDLE RFS LGWR 71 IDLE
PROCESS列显示进程信息
CLIENT_PROCESS列显示对应的主数据库中的进程
SEQUENCE#列显示归档redo的序列号
STATUS列显示的进程状态
从上可以看出主库开启了4个归档进程，使用lgwr同步传输方式与standby通信，已经接收完70的日志，正等待71。
察看备库是否和主库同步
备库查询，如果没有现明显的gap现象，则同步
SQL> select thread#, low_sequence#, high_sequence# from v$archive_gap; 未选定行
察看备库已经归档的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恢复
Standby数据库状态 Standby服务器操作 解决方案 没有应用resetlog之前的redo数据 自动应用新的redo数据 无须手工介入 应用了resetlog之后的redo数据，不过standby打开了flashback。 可以应用，不过需要dba手工介入 1. 手工flashback到应用之前2. 重启redo应用，以重新接收新的redo数据。 应用了resetlog之 后 的redo数据，而且没有flashback。 完全无法应用 重建物理standby是唯一的选择
：