Oracle Data Guard of step by step install

基础介绍

  • Oracle Data Guard是Oracle的数据守护卫士,配置Standby备用数据库角色,通过持续获取Primary主数据的重做日志,提供灾难恢复的功能;
  • Primary:组成Data Guard的主库角色,负责主业务的角色;
  • Standby:组成Data Guard的备库角色,负责接收主库的重做日志,在必要情况下可以切换到Primary角色,接管主业务;
  • Redo Log(重做日志):是数据库的事务日志,记录了所有对数据库的修改操作。它用于确保数据的持久性和一致性,能够在数据库发生故障时,通过重放日志来恢复数据;
  • Archive log:Archive Log 是 Redo Log 的归档版本。当 Redo Log 文件写满后,系统会将其内容复制到 Archive Log 中,以便长期保存和用于数据恢复。Archive Log 是对 Redo Log 的持久化存储,确保在发生灾难性故障时能够恢复数据库到最后一次归档的状态
  • Applied(应用):Standby重做日志的Applied是指Standby数据库已经应用了主数据库的重做日志中的数据。Applied是Standby数据库恢复和数据同步的关键步骤。
    • Standby重做日志的Applied状态可以通过SELECT SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG;检查;
  • DB_UNIQUE_NAME:DB_UNIQUE_NAME是Oracle数据库的一个属性,用于唯一标识一个数据库实例,在Oracle Data Guard中,DB_UNIQUE_NAME用于区分Primary库和Standby库;

Physical Standby部署

前置准备

Hostname 角色 Unique_name IP地址
primarynode Primary PLASMA 192.168.0.142
standbynode Standby PLASBY 192.168.0.143

Primary角色准备

  • 配置服务器环境
# 创建目录
mkdir -p /plasma/oracle/admin/{PLASMA,PLASBY}/adump
mkdir -p /plasma/oradata/backup

# 修改Primary和Standby的主机名并添加进/etc/hosts
hostnamectl set-hostname primarynode
# 修改 /etc/hosts
# 增加行:
# 192.168.0.142 primarynode
# 192.168.0.143 standbynode

# 创建sshkey实现pimarynode与standbynode相互免密访问
# 可以一直按回车确认
ssh-keygen -t rsa -b 2048

# 拷贝公钥至目标主机
ssh-copy-id oracle@standbynode
  • 通过测试计算机名primarynode和standbynode,确认互通;

  • 登入sysdba角色进行操作sqlplus / as sysdba

-- 检查重做日志配置配置状态
select group#, status from v$log;
-- 应保证有一个Current的状态的日志
-- GROUP# STATUS
--     1 INACTIVE
--     2 CURRENT
--     3 UNUSED
-- 通过切换日志来触发日志应用
-- 切换日志
alter system switch logfile;

-- 开启强制记录日志
-- alter database force logging;

-- 检查数据库存档模式应为Archive Mode(存档模式)
archive log list;

-- 确认数据库日志模式若为No Archive Mode(非存档模式),需要执行:
-- 先关闭数据库,切换存档模式需要在Mount模式下进行
shutdown immediate
-- 启动至挂载模式
startup mount
-- 修改数据库为存档模式
alter database archiveLog;
-- 重新启动数据库
alter database open;

-- 检查数据库DB_UNIQUE_NAME,这个很*关键*
select db_unique_name from v$database;
-- 可通过修改init<SID>.ora文件来修改DB_UNIQUE_NAME,或者使用语句;如果需要修改生产库,需要注意应该先做备份;
-- ALTER DATABASE UNIQUE_NAME = 'PLASMA';
  • 配置$ORACLE_HOME/network/dbs/tnsname.ora
PLASMA =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS =
        (PROTOCOL = TCP)(HOST = primarynode)(PORT = 1521)
      )
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = PLASMA)
    )
  )

PLASBY =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS =
        (PROTOCOL = TCP)(HOST = standbynode)(PORT = 1521)
      )
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = PLASMA)
    )
  )
  • 配置$ORACLE_HOME/network/admin/listener.ora
SID_LIST_LISTENER=
  (SID_LIST=
      (SID_DESC=
         (GLOBAL_DBNAME=PLASMA)
         (SID_NAME=PLASMA)
	      # 按实际ORACLE_HOME路径配置
         (ORACLE_HOME=/opt/oracle/app/19c)
	      # 该参数指定了在监听器启动时可以预生成的最大专用服务器进程的数量。这些预生成的进程可以在接收到客户端连接请求时立即使用,从而减少连接延迟;
          # (PRESPAWN_MAX=20)
          # 该参数用于指定监听器在启动时预生成的服务器进程的列表。通过预生成进程,可以减少客户端连接时的延迟,提高数据库的响应速度;
          # PROTOCOL:指定使用的协议(如 TCP)。
          # POOL_SIZE:定义预生成的服务器进程的数量。
          # TIMEOUT:指定在没有连接请求时,预生成进程的超时时间。
          # (PRESPAWN_LIST=
          #   (PRESPAWN_DESC=(PROTOCOL=tcp)(POOL_SIZE=2)(TIMEOUT=1))
         )
      )
  )


LISTENER =
 (ADDRESS_LIST=
        (ADDRESS=(PROTOCOL=tcp)(HOST=primarynode)(PORT=1521)) 
        # 用于配置 IPC(Inter-Process Communication)协议的方式,通常用于数据库与外部过程(如 PL/SQL 外部过程)之间的通信
        # (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)

Standby角色准备

  • 配置服务器环境
# 创建adump目录
mkdir -p /plasma/oracle/admin/{PLASMA,PLASBY}/adump
# 修改Primary和Standby的主机名并添加进/etc/hosts
hostnamectl set-hostname standbynode
# 修改 /etc/hosts
# 增加行:
# 192.168.0.142 primarynode
# 192.168.0.143 standbynode

# 创建sshkey实现pimarynode与standbynode相互免密访问
# 可以一直按回车确认
ssh-keygen -t rsa -b 2048

# 拷贝公钥至目标主机
ssh-copy-id oracle@primarynode
  • 通过测试计算机名primarynode和standbynode,确认互通;

  • 本文档部署的Standby是无实例配置模式,如果安装的数据库中安装了实例,需要先删除实例

# 使用dbca删除Standby实例,本文档使用无实例配置
dbca -silent -deleteDatabase -sourceDB PLASMA

环境准备

配置Primary

-- 备份当前pfile和spfile
create pfile='?/dbs/initPLASMA.ora_2024-11-26' from spfile;

-- 修改DG_CONFIG,PLASMA和PLASBY不要求顺序
alter system set log_archive_config='DG_CONFIG=(PLASMA,PLASBY)' scope=both;
  • 每个目的地必须指定location或service属性,用来指定redo传输服务输出redo数据到本地磁盘目录或者远程数据库目的地;
  • 配置第一个log_archive_dest,这里配置的是本地的数据库(即Primary库)的本地归档日志路径信息;
  • SERIVCE: 用于指定备用数据库的TNSNAMES描述符,Oralce 会将重做日志传送到这个TNSNAMES指定的备库;
  • log_archive_dest_1 ~~ log_archive_dest_10目的地能包括location属性或者service属性,log_archive_dest_11 ~~ log_archive_dest_31目的地只能包括service属性;
  • 使用USE_DB_RECOVERY_FILE_DEST常量可以指定数据库恢复文件的存储位置;
  • LOCATION还可配置路径,用于存放生成的重做日志;
    • 指定+DATA指向 Oracle ASM(Automatic Storage Management)磁盘组的路径;
    • 指定USE_DB_RECOVERY_FILE_DEST指向RECOVERY_FILE_DEST的路径;
    • 执行语句查看当前配置的RECOVERY_FILE_DEST路径SHOW PARAMETER RECOVERY_FILE_DEST;,可通过修改变量修改路径
      alter system set USE_DB_RECOVERY_FILE_DEST = '/plasma/oracle/fast_recovery_area' scope=spfile;;
-- 配置第一个log_archive_dest
-- 业务配置至oradata目录下arch
-- Primary和Standby指定的路径应该一致
alter system set log_archive_dest_1='LOCATION=/plasma/oradata/arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=PLASMA' scope=both;

  • 配置第二个log_archive_dest,这里配置的是远端数据库(即Standby库)的信息
  • Service配置的是远端的服务名,服务名在tnsname.ora中配置
  • 日志传输服务:
    1. ARCH(归档进程)适合于对实时性要求不高的场景,提供灵活的归档策略和简单的配置。
    2. LGWR(日志写入进程)适合于需要实时数据同步和高可用性的环境,能够提供更好的性能和数据保护,但配置和管理相对复杂。
  • 传输模式(log_archive_dest_11 ~~ log_archive_dest_31不支持sync属性):
    1. 同步传输模式(SYNC)在主数据库在提交事务之前,必须等待备用数据库确认已成功接收并写入重做日志。这种模式确保了零数据丢失,但可能会增加事务提交的延迟。
    2. 异步传输模式(ASYNC)主数据库在提交事务时不需要等待备用数据库的确认。事务可以在重做日志传输到备用数据库之前就被提交,这样可以提高性能,但可能会导致在主库故障时丢失最近的事务。
  • VALID_FOR定义何时使用(角色相关)LOG_ARCHIVE_DEST_n参数以及应该在哪类重做日志文件上运行
  • redo_log_type关键字表明该目的地产生归档的redo日志类型,可用日志文件类型:
    1. online_logfile:目的地只归档联机redo日志
    2. standby_logfile:目的地只归档standbyredo日志
    3. all_logfiles:目的地既归档联机redo日志,也归档standby redo日志
  • database_role表明该目的地产生归档的数据库角色,可用的角色类型:
    1. primary_role:只有数据库是主,该目的地才会产生归档
    2. standby_role:只有数据库是备,该目的地才会产生归档
    3. all_role:当数据库不论是主还是备,该目的地都会产生归档
  • DB_UNIQUE_NAME,标示唯一的路径,如果使用了次参数通常也设置LOG_ARCHIVE_CONFIG=DG_CONFIG()两者要匹配,还必须和参数文件里一致,使用此参数主要是为了明确主库和备库使用那个路径;
  • AFFIRM和NOAFFIRM,控制日志传输服务是异步还是同步写日志数据到磁盘,当sync属性被指定时,默认是AFFIRM,当async属性被指定,默认是NOAFFIRM,不需要专门设置:
    1. AFFIRM:在日志写进程进行之前,所以的归档日志和备库日志必须同步写完;
    2. NOFFIRM:在主库的日志写进程不等所有磁盘IO完成;
  • NET_TIMEOUT网络超时设置,NET_TIMEOUT指定LGWR进程等待LNS进程的最大时间数,单位为秒(缺省30),如果超出该值,则主库放弃备库,继续执行主库上的事务;
  • 指定LGWR后台进程等待Redo传输目的地确认收到Redo数据的秒数,如果确认没有在NET_TIMEOUT秒内收到,一个错误被记录,同时到该目的地的Redo传输会话被中断,指定该参数必须指定SYNC属性;
  • DELAY,用来指示备库目标的日志应用进程在DELAY属性设置的时间(秒)后应用重做数据;
  • OMPRESSION,用于设置是否在将REDO数据传输到REDO传输目的地之前进行压缩,参数为ENABLE或者DISABLE,必须购买该选件的license之后才能使用该特性;
  • ALTERNATE,当原归档目的地失败后,可以使用后补的,但是如果REOPEN参数的值不为0的话,ALTERNATE将不可用;
  • dataguard中LOG_ARCHIVE_DEST_n配置如下:
    • 最大保护模式模式是保证零数据丢失,LOG_ARCHIVE_DEST_n配置为LGWR SYNC AFFIRM
    • 最大可用性模式是零数据丢失,LOG_ARCHIVE_DEST_n配置为LGWR SYNC AFFIRM
    • 最大性能模式是保证最小数据丢失,通常为几秒 LGWR ASYNC 或 ARCH 可以不选择,但推荐设置 AFFIRM 或 NOAFFIRM
-- 配置第二个log_archive_dest
alter system set log_archive_dest_2='service=PLASBY LGWR SYNC valid_for=(online_logfiles,primary_role) db_unique_name=PLASBY' scope=both;

-- 启用日志路径
alter system set log_archive_dest_state_1 = ENABLE;
alter system set log_archive_dest_state_2 = ENABLE;

-- 修改fal(Far Archival Log)
-- FAL_SERVER是远程归档日志传输服务器的名称,指向远端库
-- FAL_CLIENT是本地数据库的名称,指向当前库
-- Standby的配置应为相反
alter system set fal_client='PLASMA' scope=spfile;
alter system set fal_server='PLASBY' scope=spfile;

-- 设置standby自动文件管理
alter system set standby_file_management=auto scope=spfile;

-- 保存当前spfile至pfile
create pfile='?/dbs/initPLASMA.ora' from spfile;

-- 检查LOG_ARCHIVE_DEST是否出现报错
-- VALID则表示正常访问备份目标
SELECT DEST_NAME, STATUS, ERROR FROM V$ARCHIVE_DEST where STATUS != ('INACTIVE');
  • 将pfile、orapw、tnsname拷贝至standbynode
# 拷贝密码文件至standby
scp $ORACLE_HOME/dbs/orapwPLASMA standbynode:$ORACLE_HOME/dbs/orapwPLASBY

scp $ORACLE_HOME/dbs/initPLASMA.ora standbynode:$ORACLE_HOME/dbs/initPLASBY

scp $ORACLE_HOME/network/admin/tnsnames.ora standbynode:$ORACLE_HOME/network/admin/

scp $ORACLE_HOME/network/admin/listener.ora standbynode:$ORACLE_HOME/network/admin/

配置Standby

  • STANDBY修改listener.ora
sed -i -e '/SID_NAME=/s/PLASMA/PLASBY/' -e '/HOST=/s/primarynode/standbynode/'  $ORACLE_HOME/network/admin/listener.ora
  • 修改STANDBY启动参数
startup nomount pfile='?/dbs/initPLASBY'

-- 修改数据库名
alter system set db_unique_name=PLASBY scope=spfile;

-- 检查db_unique_name
show parameter db_unique_name

-- 指定Standby的log_archive_dest存储路径1,这里使用USE_DB_RECOVERY_FILE_DEST
-- LOCATION还可配置+DATA或指向其他路径,用于存放生成的重做日志
-- Primary和Standby指定的路径应该一致
alter system set log_archive_dest_1 =  'LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=PLASBY' scope=both;

-- 配置第二个log_archive_dest,这里配置的是远端数据库(即Standby库)的信息
-- Service配置的是远端的服务名,服务名在tnsname.ora中配置
alter system set log_archive_dest_2='service=PLASMA async valid_for=(online_logfiles,primary_role) db_unique_name=PLASMA' scope=both;

-- Standby库配置的log_archive_dest_1和log_archive_dest_2应与Primary相反

-- 修改fal(Far Archival Log)
-- FAL_SERVER是远程归档日志传输服务器的名称,指向远端库
-- FAL_CLIENT是本地数据库的名称,指向当前库
-- Standby的配置应为相反
alter system set fal_client='PLASBY' scope=spfile;
alter system set fal_server='PLASMA' scope=spfile;

-- 重新基于spfile生成pfile
create pfile from spfile;

-- 检查LOG_ARCHIVE_DEST是否出现报错
-- VALID则表示正常访问备份目标
SELECT DEST_NAME, STATUS, ERROR FROM V$ARCHIVE_DEST where STATUS != ('INACTIVE');
  • 测试TNS联通情况可以测试:

    • 从Standby测试Primary:tnsping PLASMA
    • 从Primary测试Standby:tnsping PLASBY

初始化standby

Primary生成初始备份

  • 启动rmanrman target /检查归档日志(非必要步骤)
-- 交叉检查归档日志,使用 CROSSCHECK 命令来验证归档日志的状态。此命令会更新 RMAN 的控制文件,标记缺失的归档日志为过期;
crosscheck archivelog all;

-- 删除过期的归档日志记录: 如果交叉检查后发现某些归档日志已经过期,可以使用以下命令删除这些过期的记录
delete expired archivelog all;

-- 恢复归档日志:如果您有归档日志的备份,可以尝试恢复这些日志。确保在恢复之前,数据库处于适当的状态(如挂载状态)
-- restore archivelog all

-- 设置在备份到磁盘时使用压缩备份集
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;

-- 設置在所有备用数据库上应用的日志可以被删除
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
  • 返回bash执行数据库备份生成


# 生成定时备份脚本
cat > /plasma/oracle/bakcup.rman <<EOF
RUN {
   -- 分配通道
   ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
  
   -- 删除过期备份
   DELETE EXPIRED BACKUP;
   
   -- 强制当前日志归档
   SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';

   -- 备份整个数据库
   BACKUP DATABASE FORMAT '/plasma/oradata/backup/datafile_%T-%U.bak';

   -- 备份归档日志
   BACKUP ARCHIVELOG ALL FORMAT '/plasma/oradata/backup/archlog_%T-%U.bak';

   -- 备份当前控制文件
   BACKUP CURRENT CONTROLFILE FORMAT '/plasma/oradata/backup/ctrl_%T-%U.bak';

   -- 释放通道
   RELEASE CHANNEL c1;
}
EOF

# 执行一次备份
rman target / @/plasma/oracle/bakcup.rman
  • 拷贝/plasma/oradata/backup/至standbynode相应路径
scp -r /plasma/oradata/backup standbynode:/plasma/oradata/

standby执行备份恢复

  • 启动rmanrman target /
-- 检查实例是否在nomount状态
select status from v$instance;

-- 非MOUNTED需要重启
shutdown immediate

-- 启动至NOMOUNTED状态
startup nomount;

-- 恢复control文件,找到ctrl*.bak文件
restore standby controlfile from '/plasma/oradata/backup/ctrl_20241126.bak';

-- 挂载实例
alter database mount;

 -- 注册备份文件
catalog start with '/opt/oradata/backup';
 
-- 通过读取备份,恢复数据库
restore database;
 
-- 恢复归档日志
restore archivelog all;

-- 完成备库的恢复

检查配置情况

  • sqlplussqlplus / as sysdba
-- 检查LOG_ARCHIVE_DEST配置
-- log_archive_dest_1、log_archive_dest_2应配置正确
-- log_archive_dest_state_1、log_archive_dest_state_2应为Enable
show parameter LOG_ARCHIVE_DEST;

-- 检查DB_UNIQUE_NAME,主备库应不相同
show parameter db_unique_name;

-- 检查主备数据库的 DGID(Data Guard ID),正常情况下应为一致
SELECT DB_UNIQUE_NAME, DBID FROM V$DATABASE;

-- 确保控制文件和数据文件都处于一致状态,可以使用以下命令查看当前的数据文件和控制文件的状态
SELECT * FROM V$CONTROLFILE;

-- 检查ARCHIVE_LOG_DEST的日志接收情况
COL TARGET FORMAT A12
COL DEST_NAME FORMAT A20;
COL ERROR FORMAT A24;
SELECT DEST_ID, TARGET, DEST_NAME, STATUS, ERROR FROM V$ARCHIVE_DEST WHERE STATUS != 'INACTIVE';

-- 检查standby的进程运行情况
select process,status,thread#,sequence# from v$managed_standby;

-- 1. 检查Primary角色
	-- DATABASE_ROLE:PRIMARY
	-- OPEN_MODE: READ WRITE
-- 2. 检查Standby角色
	-- DATABASE_ROLE:PHYSICAL STANDBY
	-- OPEN_MODE: MOUNTED
-- SWITCHOVER_STATUS状态:
	-- SESSION ACTIVE:表示当前有会话正在使用数据库,无法进行切换。
	-- TO PRIMARY:表示数据库可以切换到主库角色。
	-- TO STANDBY:表示数据库可以切换到备用库角色。
	-- RECOVERY NEEDED:表示数据库需要进行恢复,通常在切换后备用库的状态。
	-- NOT ALLOWED:表示当前状态不允许进行切换,可能是由于某些条件未满足。
	
-- 正常情况下,PRIMARY的SWITCHOVER_STATUS应为TO STANDBY
-- STANDBY的SWITCHOVER_STATUS应为NOT ALLOWED
SELECT NAME,DATABASE_ROLE, OPEN_MODE,SWITCHOVER_STATUS FROM V$DATABASE;

-- 检查应用日志情况
-- applied = 'NO'则为存在重做日志未被应用
select ssequence,applied from (select sequence# sequence,applied from v$archived_log order by sequence# desc) where rownum <=10;

-- 当RSWITCHOVER_STATUS状态为ECOVERY NEEDED时,执行介质恢复
alter database recover managed standby database using current logfile disconnect from session;

主从角色互换流程

切换前检查

-- 确认当前主备库角色和状态
-- Primary库状态:
-- DATABASE_ROLE:PRIMARY
-- OPEN_MODE:READ WRITE
-- SWITCHOVER_STATUS:TO STANDBY

-- Standby库状态:
-- DATABASE_ROLE:PHYSICAL STANDBY
-- OPEN_MODE:MOUNTED
-- SWITCHOVER_STATUS:NOT ALLOWED
SELECT NAME,DATABASE_ROLE, OPEN_MODE,SWITCHOVER_STATUS FROM V$DATABASE;

-- 检查未应用日志
SELECT SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG where APPLIED = 'NO';

select sequence#,applied from v$archived_log order by 1 desc;

-- 切换前在STANDBY中执行一遍介质恢复
-- 此命令用于启动在备用数据库上的日志应用过程(Redo Apply),以保持备用数据库与主数据库的同步。它是用于数据保护和恢复的操作
-- 会话处理:DISCONNECT FROM SESSION 选项允许该命令在后台运行,控制权立即返回到命令提示符,而不需要等待恢复过程完成
alter database recover managed standby database using current logfile disconnect from session;

-- 手动取消standby同步,非常规切换的情况下执行
-- alter database recover managed standby database cancel;

primarynode(原PRIMARY库,为容易区分以主机名表示)执行

  • 将primarynode原来的PRIMARY角色转换为STANDBY角色
  • 检查PRIMARY的SWITCHOVER_STATUS状态为TO STANDBY时,可以切换至STANDBY角色
-- TO STANDBY
-- primarynode操作将角色由primary切换至standby
alter database commit to switchover to standby;
-- 切换后数据库将是unmounted状态
startup mount;

-- 检查当前DATABASE_ROLE角色是否已变更为PHYSICAL STANDBY
SELECT NAME,DATABASE_ROLE, OPEN_MODE,SWITCHOVER_STATUS FROM V$DATABASE;



standbynode(原STANDBY库,为容易区分以主机名表示)执行

  • 将standbynode原来的STANDBY角色转换为PRIMARY角色
  • 在pimarynode执行角色转换后,原standbynode检查SWITCHOVER_STATUS值,应由原来的NOT ALLOWED变更为TO PRIMARY
-- 检查standbynode的角色
-- SWITCHOVER_STATUS显示为TO PRIMARY
SELECT NAME,DATABASE_ROLE, OPEN_MODE,SWITCHOVER_STATUS FROM V$DATABASE;

-- standby操作将角色由standby切换至primary
alter database commit to switchover to primary;

-- 打开数据库
alter database open

-- 分别检查Primary和Standby角色是否已经互换
SELECT NAME,DATABASE_ROLE, OPEN_MODE,SWITCHOVER_STATUS FROM V$DATABASE;

-- SWITCHOVER_STATUS为RECOVERY NEEDED时,执行
alter database recover managed standby database using current logfile disconnect from session;

灾难故障转移

  • 当Primary灾难发生且无法短期内恢复时,可以将Standby强制将角色切换为Primary;
  • 手动应用接收到的在线重做日志alter database recover managed standby database using current logfile disconnect from session;
  • 尝试切换为Primary角色alter database commit to switchover to primary with session shutdown;
  • 追踪日志tail -f $ORACLE_BASE/diag/rdbms/plasby/PLASBY/trace/alert_PLASBY.log可以跟踪执行情况;
  • 切换一直未能生效,或看到日志有Switchover: Media recovery is still active的情况,可以另起sqlplus session执行取消standby同步,执行alter database recover managed standby database cancel;
  • 可以尝试使用以下命令完成恢复,然后再进行切换ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
  • 尝试执行切换ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
  • 这时如果提示数据库已更改,则可以检查数据库的角色SELECT NAME,DATABASE_ROLE, OPEN_MODE,SWITCHOVER_STATUS FROM V$DATABASE;是否已经提升为PRIMARY,如果OPEN_MODE为MOUNTED时,则需要启动数据库alter database open;
  • 检查数据库是否有未应用的归档日志。可以使用语句查询SELECT SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
  • 新备库启动恢复alter database recover managed standby database disconnect from session;
  • 查看归档序列是否一致archive log list;
  • 当前时间与预计下次产生归档的时间的间隔
select 'standby gap is: ' || to_char(apply_lag) || ' minute at ' || to_char(sysdate, 'yyyy-mm-dd hh24:mi')||' DATABASE: testdb' as warn_message
from (select round((sysdate - MAX(G.NEXT_TIME))*1440) as apply_lag
      from v$archived_log G
	  where G.applied = 'YES');
  • apply lag(备库应用延迟),transport lag(日志传输延迟)select NAME,VALUE from v$dataguard_stats where regexp_like(name,'lag');

故障修复

日常巡检SELECT name, database_role, switchover_status FROM v$database;,SWITCHOVER_STATUS是当前的灾备的切换状态,对应报错处理

Primary报FAILED DESTINATION

  • Primary访问不到Standby库,检查Primary与Standby库之间是否正常互通,使用tnsping互相测试;
  • Standby如果意外重启后,重新挂载数据库后需要检查联机归档日志是否被应用,执行alter database recover managed standby database using current logfile disconnect from session;进行一次手工执行;

Primary报RESOLVABLE GAP

  • Primary尝试对日志进行归档,ALTER SYSTEM ARCHIVE LOG CURRENT;,同时检查Standby日志文件$ORACLE_BASE/diag/rdbms/plasby/PLASBY/trace/alert_PLASBY.log是否正在进行通信;
  • 间隔一段时间后重新检查