Data Guard Physical Standby Switchover

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 详解Data Guard Physical Standby Switchover相关内容。

Data Guard Physical Standby Switchover

一、确保主库相关参数文件,设置正确
如下为主数据库相关参数
DB_NAME=pridb
DB_UNIQUE_NAME=pridb
LOG_ARCHIVE_CONFIG='DG_CONFIG=(pridb,stdb)'
CONTROL_FILES='/arch1/chicago/control1.ctl', '/arch2/chicago/control2.ct'
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/chicago/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=pridb'
LOG_ARCHIVE_DEST_2='SERVICE=boston ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=stdb'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc

同时在主数据库上增加了额外的备用角色初始化参数。当主数据库过渡到备用数据库时,这些参数将生效
AL_SERVER=stdb
DB_FILE_NAME_CONVERT='stdb','pridb'
LOG_FILE_NAME_CONVERT=
STANDBY_FILE_MANAGEMENT=AUTO

二、检查物理备用数据库是是可用的

   创建物理备用数据库并设置重做传输服务后,您可能需要验证数据库修改是否已经成功地从主数据库传输到备用数据库,要看到在备用数据库上接收重做数据,您应该首先识别备用数据库上现有的归档重做日志文件,在主库手动做一次日志和归档切换,然后再次检查备用数据库。下面的步骤展示了如何执行这些任务。
  1、 识别现有的归档重做日志文件。在备用数据库上,查询V $ ARCHIVED_LOG视图,以识别归档重做日志中的现有文件 ,例如:

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
2、在主数据库上,手动做一次日志切换
SQL> ALTER SYSTEM SWITCH LOGFILE;
3、在备用数据库上,查询V $ ARCHIVED_LOG视图,以验证已接收到的重做数据并归档到备用数据库
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

4、验证所接收的重做已应用
SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

三、切换前检查
1、在备库验证恢复进程是运行的,下面的查询在备用验证管理恢复正在运行
SQL> SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS
如果恢复检查没有运行或开启实时应用,restart managed recovery with
real-time apply enabled
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT

2、确保参数LOG_ARCHIVE_MAX_PROCESSES的值是4或更高在主库和备库,注意不要把它设置得太高,因为附加的归档程序可以增加关闭数据库的时间
3、备库切换成主库之前,最好将备库的Online Redo Log Files做一次cleare,尽管在做SWITCHOVER TO PRIMARY 的时候,备库上会自动做一次clear,但是Oracle还是建议手动clear一次。
在目标物理备用运行以下查询,以确定在线重做日志是否未被cleard
SQL> SELECT DISTINCT L.GROUP# FROM V$LOG L, V$LOGFILE LF
WHERE L.GROUP# = LF.GROUP#
AND L.STATUS NOT IN (‘UNUSED’, ‘CLEARING’,’CLEARING_CURRENT’);

如果上面的查询返回行,在备库停止日志应用,为每个组#返回和重新启动Redo应用程序发出以下语句

SQL> ALTER DATABASE CLEAR LOGFILE GROUP ;

4、确认备库没有GAP
在物理备用数据库执行以下查询,以确定物理备用数据库是否有GAP
SQL> SELECT * FROM V$ARCHIVE_GAP;
5、确认主备库的tempfile和datafile状态是online

三、执行Switchover操作
1、在主库查询JOB的状态
SQL> SELECT * FROM DBA_JOBS_RUNNING;

   Note: Job candidates to be disabled among others: oracle text sync and optimizer, RMAN backups, application  garbage collectors, application background agents

将个运行job停止
SQL> ALTER SYSTEM SET job_queue_processes=0 SCOPE=BOTH SID=’*’;
SQL> EXECUTE DBMS_SCHEDULER.DISABLE( );
2、打开准备库的trace

    如果出现任何问题,可以提供诊断信息。打开跟踪并不会对切换时间产生任何明显的影响,但确实需要空间来执行跟踪输出。捕获主服务器和目标物理备用数据库的当前值

SQL> SHOW PARAMETER log_archive_trace

SQL> ALTER SYSTEM SET log_archive_trace=8191;
trace文件路径通过BACKGROUND_DUMP_DEST可知:
SQL> SHOW PARAMETER background_dump_dest

3、创建保证的恢复点(可选)
那么您可以在主数据库和备用数据库中创建一个有保证的恢复点,保证可以切换回退
方法:
在备库
停止日志应用
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> CREATE RESTORE POINT SWITCHOVER_START_GRP GUARANTEE FLASHBACK DATABASE;

开启日志应用
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

在主库
SQL> CREATE RESTORE POINT SWITCHOVER_START_GRP GUARANTEE FLASHBACK DATABASE;

4、查询确认主库可以切换到备库
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
TO STANDBY

如果返回为TO STANDBY 或 SESSIONS ACTIVE可以切换在切换命令上需要使用WITH SESSION SHUTDOWN,如果没有返回这些值,则不可能进行切换

注:如果主库是Rac,关闭其他实例,只留一个实例

5、开始切换
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY WITH SESSION SHUTDOWN;

摘自官方文档:If an ORA-16139 error is encountered, as long as V$DATABASE.DATABASE_ROLE=’PHYSICAL STANDBY’, then you can proceed. A common case where this can occur is when there are a large number of data files. Once managed recovery is started on the new standby, the database will recover. If the role was not changed then you need to cancel the switchover and review the alert logs and trace files further.

在备库:
确认验证可以切换到主库
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
TO PRIMARY

摘自官方文档:A value of TO PRIMARY or SESSIONS ACTIVE indicates that the standby database is ready to be switched to the primary role. If neither of these values is returned, verify that redo apply is active and that redo transport is configured and working properly. Continue to query this column until the value returned is either TO PRIMARY or SESSIONS ACTIVE

切换到主库

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

Open the new 主库
SQL> ALTER DATABASE OPEN.

如果新的备用数据库(前主数据库)在切换到备用数据库后没有关闭,则将它带到mount状态并开始管理恢复。这可以与新的主开放并行进行
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

四、

SQL> ALTER SYSTEM SET job_queue_processes= scope=both sid=’*’
启用任何禁用的作业。
SQL> EXECUTE DBMS_SCHEDULER.ENABLE();

在创建保证恢复点的所有数据库上,删除任何有保证的恢复点

SQL> DROP RESTORE POINT SWITCHOVER_START_GRP;

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
7月前
3.4 Using DBCA to Create a Data Guard Standby
3.4 Using DBCA to Create a Data Guard Standby
43 1
|
SQL Oracle 网络协议
rman duplicate standby active
rman 搭建dataguard.
339 0
|
SQL 关系型数据库 对象存储
Database Recovery in GitLab – Implementing Database Disaster Tolerance & High Availability
How can we restore accidentally deleted database in GitLab? How can we implement database backup, recovery, disaster tolerance, and high availability?
2178 0
|
数据库 网络协议 数据库管理
Data Guard 和DGMGRL
db_unique_name_DGB.db_domain: service name db_unique_name_DGMGRL.db_domain:  在每个配置了broker的数据库上面都存在一个服务器进程进行 broker的管理操作,这个服务器进程就是Data Guard broker monitor(DMON),而这个DMON所用到的所有配置信息都会保留在一个配置文件中。
1055 0
|
Oracle 关系型数据库 数据库
DGMGR-TO PHYSICAL STANDBY Failed (ORA12514 )解决方法
TO  PHYSICAL STANDBY  Failed  (ORA-12514: )解决方法:   ==========DG 环境:   DGMGRL> SHOW CONFIGURATION;   Configuration - DRSolution     Protection ...
1422 0