物理Data Guard的日常维护

228次阅读

共计 1894 个字符，预计需要花费 5 分钟才能阅读完成。

物理 Data Guard 的日常维护

关闭顺序

1. 首先关闭primary 数据库

[Oracle@Master admin]$ sqlplus / as sysdba
SQL> shutdown immediate

2. 关闭 standby 数据库

[oracle@Salve ~]$ 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 是唯一的选择