12c Data guard Switchover Best Practices using SQLPLUS (Doc ID 1578787.1)

Posted 2021-03-23 Oracle&PostgreSQL

12c Data guard Switchover Best Practices using SQLPLUS (Doc ID 1578787.1)

APPLIES TO:

Oracle Database Backup Service - Version N/A and later
Oracle Database Exadata Cloud Machine - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Oracle Database Cloud Exadata Service - Version N/A and later
Oracle Database Cloud Schema Service - Version N/A and later
Information in this document applies to any platform.
***Checked for relevance on 27-Oct-2016***

GOAL

*** Reviewed for Relevance 16-Jul-2015 ***

This Document describes step by step method to perform switchover on Physical Standby Environment using SQLPLUS.

本文档分步介绍了使用SQLPLUS在Physical Standby Environment上执行切换的方法

SOLUTION

NOTE: In the images and/or the document content below, the user information and environment data used represents fictitious data from the Oracle sample schema(s), Public Documentation delivered with an Oracle database product or other training material. Any similarity to actual environments, actual persons, living or dead, is purely coincidental and not intended in any manner.

For the purposes of this document, the following fictitious environment is used as an example to describe the procedure:
出于本文档的目的，以以下虚拟环境为例来描述该过程：
Primary database: boston
Standby database: chicago

I. Pre-Switchover check  切换前检查

Verify that the target standby is ready for switchover.  验证目标备用数据库是否已准备好进行切换

NOTE : In CDB environment switchover happen at CDB level only.  注意：在CDB环境中，切换仅发生在CDB级别

Verify that the target standby is synchronous with primary and Redo shipping working fine from primary.  验证目标备用数据库是否与主数据库同步，并且 Redo 从主数据库正常工作

SQL>alter database switchover to <target standby db_unique_name> verify;

The above command will verify following things,  上面的命令将验证以下内容

a. Verifies that the release version is minimum 12.1  验证发行版本是否为最低12.1

b. Primary REDO shipping.

c. Standby MRP recovery running and its synchronous with primary, else it will through below error in SQLPROMPT and alert log as well.  Standby MRP recovery正在运行，并且与主MRP同步，否则它将通过SQLPROMPT以及警报日志报以下错误

For example,

SQL>alter database switchover to chicago verify;
ORA-16470: Redo Apply is not running on switchover target

------Primary alert log------

    SQL>alter database switchover to chicago verify;

    ORA-16470 signaled during: alter database switchover to chicago verify...

Checks ORL status on target standby.  检查目标备用数据库上的ORL状态

If it is dirty then it will though the warning messages like 

SQL> alter database switchover to chicago verify;
ERROR at line 1:
ORA-16475: succeeded with warnings, check alert log for more details

-----Primary Alert log-----------

SWITCHOVER VERIFY WARNING: switchover target has dirty online redo logfiles that require clearing.

It takes time to clear online redo logfiles. This may slow down switchover process.

What to do?  该怎么办？

Make sure log_file_name_convert set properly on target standby.  确保在目标备用数据库上正确设置了log_file_name_convert

SQL>show parameter log_file_name_convert;

NOTE:  If not set set the value for example if directory structure changing only in db_unique_name. for example,  注意：如果未设置，请设置该值，例如，如果目录结构仅在db_unique_name中不同。例如

Primary ORL location is /oradata/boston/<path>

Standby logfile location is /oradata/chicago/<logfiles>

Set the parameter like,

alter system set LOG_FILE_NAME_CONVERT=’boston’,’chicago’ scope=spfile;  

NOTE: Restart the standby and start the MRP. When you restart standby and start MRP then it clears all the ORLs at standby provided log_file_name_convert set properly.

注：重新启动备用数据库并启动MRP。重新启动备用数据库并启动MRP时，只要正确设置了log_file_name_convert，它将清除备用数据库上的所有ORL。

If Standby is synchronous with primary, we will get below messages,  如果Standby与primary同步，我们将获得以下消息

SQL> alter database switchover to chicago verify;
Database altered.

--------- Primary Alert log -------

SWITCHOVER VERIFY: Send VERIFY request to switchover target CHICAGO

SWITCHOVER VERIFY COMPLETE

Completed: alter database switchover to chicago verify

Verify Primary and Standby tempfiles match  验证主库和备库临时文件是否匹配

Tempfiles created after standby creation will not be propagated to standby. Check the TEMP files using below query and add new TEMP files at standby is required.

创建备用数据库后创建的临时文件不会传播到备用数据库。使用以下查询检查TEMP文件，并需要在待机状态下添加新的TEMP文件。

SQL> col name for a45
SQL>  select ts#,name,ts#,status  from v$tempfile;

NOTE : For multiple Standby environment make sure all the standby in SYNC with primary.  注意：对于多个备用环境，请确保所有备用数据库都与主数据库保持同步

Check if log_archive_Dest(remote redo transport) set on Standby side  检查 log_archive_Dest（远程redo传输）是否在 Standby设置

SWITCHOVER VERIFY command returns ORA-16475 when log_archive_dest_n is not set on Standby as follows.  当未在Standby上设置 log_archive_dest_n 时，SWITCHOVER VERIFY命令返回ORA-16475，如下所示

SQL> ALTER DATABASE SWITCHOVER TO chicago VERIFY;
ALTER DATABASE SWITCHOVER TO chicago VERIFY
*
ERROR at line 1:
ORA-16475: succeeded with warnings, check alert log for more details

In alert.log, following messages appear.  在alert.log中，出现以下消息

SWITCHOVER VERIFY: Send VERIFY request to switchover target chicago
SWITCHOVER VERIFY COMPLETE
SWITCHOVER VERIFY WARNING: switchover target has no standby database definedin LOG_ARCHIVE_DEST_n parameter. If the switchover target is converted to
a primary database, the new primary database will not be protected.ORA-16475 signalled during: ALTER DATABASE SWITCHOVER TO chicago VERIFY...

What to do?  set log_archive_dest_state_n on Standby.

If switchover_status(v$database) shows UNRESOLVABLE GAP in RAC/non RAC environment  如果switchover_status(v$database)在RAC/non RAC环境中显示UNRESOLVABLE GAP

1. Check if any closed thread exists and disable (if any)  检查是否存在任何关闭的thread并禁用（如果有）

SQL>SELECT thread#, instance, status FROM v$thread;

Disable the CLOSED thread using,  使用以下命令禁用CLOSED线程

SQL> ALTER DATABASE DISABLE THREAD <n>;

2. Check any LAD(log_archive_destination) pointing to invalid DESTINATION  检查任何指向无效DESTINATION的 LAD(log_archive_destination)

SQL> select status,DEST_ID,TYPE,ERROR,GAP_STATUS,SYNCHRONIZED,SYNCHRONIZATION_STATUS,RECOVERY_MODE from V$ARCHIVE_DEST_STATUS where STatus <> ‘INACTIVE‘;
SQL> show parameter log_Archive_dest

II SWITCHOVER

Enable tracing on both primary and standby to diagnose in case of any issue.  在主备数据库上都启用跟踪，以在出现任何问题时进行诊断

SQL>alter system set log_archive_trace=8191 sid=’*’;

Tail Alert Logs (optional) on all instances

@primary and standby,

SQL>show parameter background_dump_dest

$tail -600f background_dump_dest/alert*

* NOTE : In RAC environment no need to shutdown all instances apart from one instanc. Switchover(SQLPLUS) comand itself shutdown all the nodes.

* 注意：在RAC环境中，除了一个实例外，无需关闭所有实例。Switchover(SQLPLUS) 命令本身会关闭所有节点。

Switchover the standby database to a primary  将备用数据库切换到主数据库

Primary-Boston,

SQL>alter database switchover to chicago;

Database altered.

Sample output from primary (BOSTON) and standby (CHICAGO),  来自primary (BOSTON) and standby (CHICAGO)的样本输出

--------------Primary Alert log "alert_boston.log"--------------

Fri Aug 23 11:05:23 2013
ALTER SYSTEM SET log_archive_trace=8191 SCOPE=BOTH;
 alter database switchover to chicago
Fri Aug 23 11:05:43 2013
Starting switchover [Process ID: 3340]
Fri Aug 23 11:05:43 2013
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY [Process Id: 3340] (boston)
.
Fri Aug 23 11:05:44 2013
Active, synchronized Physical Standby switchover target has been identified
Preventing updates and queries at the Primary
Generating and shipping final logs to target standby
Switchover End-Of-Redo Log thread 1 sequence 11 has been fixed   <---------Sequence 11 is End-Of-Redo
Switchover: Primary highest seen SCN set to 0x0.0x229306
ARCH: Noswitch archival of thread 1, sequence 11
.
Switchover: Primary controlfile converted to standby controlfile succesfully.
Switchover: Complete - Database shutdown required
Sending request (convert to primary database) to switchover target CHICAGO
OCISessionBegin with PasswordVerifier succeeded
Switchover complete. Database shutdown required
USER (ospid: 3340): terminating the instance
Fri Aug 23 11:05:51 2013
Instance terminated by USER, pid = 3340
Completed:  alter database switchover to chicago

-------------------alert log "alert_chicago.log"------------------

Fri Aug 23 11:05:47 2013
SWITCHOVER: received request ‘ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY‘ from primary database.
Fri Aug 23 11:05:47 2013
ALTER DATABASE SWITCHOVER TO PRIMARY (chicago)
Maximum wait for role transition is 15 minutes.
.
Standby became primary SCN: 2265860
Switchover: Complete - Database mounted as primary
SWITCHOVER: completed request from primary database.

NOTE: At standby side we wait only for 15 minutes for the standby to synchronous with primary.  注意：在备用服务器端，我们仅等待15分钟，以便备用服务器与主服务器同步

Open the new primary database  打开新的主数据库

SQL>alter database open;

Restart the new standby  重新启动新的备库

SQL>shut abort
SQL>startup
SQL>alter database recover managed standby database disconnect;

The scenario worked, but after switchover completed, the Database Role in the OCR  is not changed automatically.  该方案有效，但是切换完成后，OCR中的数据库角色不会自动更改
We need use [srvctl modify database] to change Database Role in the OCR according to real database role.  我们需要使用 [srvctl Modify database] 根据实际数据库角色来更改OCR中的数据库角色。

for new primary:

#sqlplus / as sysdba
SQL> select DB_UNIQUE_NAME,DATABASE_ROLE from v$database;
DB_UNIQUE_NAME    DATABASE_ROLE
------------------------------
chicago        PRIMARY

#srvctl config database -db chicago
...
Database Role: PHYSICAL_STANDBY

#srvctl modify database -db chicago -role PRIMARY

 

for new standby:

#sqlplus / as sysdba
SQL> select DB_UNIQUE_NAME,DATABASE_ROLE from v$database;
DB_UNIQUE_NAME    DATABASE_ROLE
------------------------------
boston        PHYSICAL STANDBY

#srvctl config database -db boston
...
Database Role: PRIMARY

#srvctl modify database -db boston -role PHYSICAL_STANDBY

III. Post - Switchover Check  切换后检查

Set Trace to Prior Value  将跟踪设置为先前值

SQL>  alter system set log_archive_trace=0;
System altered.

Verify that the new primary shipping logs to standby and standby is applying. 

@primary,

SQL>alter system switch logfile;
SQL>select dest_id,error,status from v$archive_dest where dest_id=<your remote log_archive_dest_<n>>;
SQL>select max(sequence#),thread# from v$log_history group by thread#;
If remote log_Archive_destination is 2 i.e log_archive_dest_2.
SQL>select max(sequence#)  from v$archived_log where applied=‘YES‘ and dest_id=2;

 @standby,

SQL>select thread#,sequence#,process,status from gv$managed_standby;
SQL>select max(sequence#),thread# from v$archived_log group by thread#;

NOTE : For Oracle version 12.2 use v$dataguard_process instead of v$managed_standby which is deprecated in Oracle 12.2

注意：对于Oracle 12.2版，请使用v$dataguard_process代替在Oracle 12.2中已弃用的v$managed_standby

SQL> select name,role,instance,thread#,sequence#,action from gv$dataguard_process;