osmar (Available) (0) Contact Us Help

PowerVLast Login: April 18, 2023 1:06 PM COT Switch to Cloud Support

 
Dashboard Knowledge Service Requests Patches & Updates

Give Feedback...
Copyright (c) 2023, Oracle. All rights reserved. Oracle Confidential.

18c & 19c Physical Standby Switchover Best Practices using SQL*Plus (Doc ID 2485237.1) To Bottom

In this Document   Was this document helpful?  

Goal Yes
No
Solution    

  Prerequisites
  Document Details  
  Latest psu/bundle patches
  Setup/configuration verification
Type:
  Verify Initialization Parameters Status: HOWTO
Last Major PUBLISHED
  Understand and Test Fallback Options 17-Jun-2021
Update:
  Pre-Switchover Last 17-Apr-2023
Update: English
  Verify Redo/Archive log apply is good and there are no gaps
Language:
  Check the datafiles & Tempfiles status    

  Online and standby redo logfile configuration

  Related Products  
  Checking the alert logfiles    

  Check Archive log GAP & Redo Delay apply

  Information Centers  
  Switchover    

  Verify the switchover

  Document References  
  Switchover steps
Primary Note for Database
  Post Switchover Proactive Patch Program
[888.1]
References
   

  Recently Viewed  
APPLIES TO:    

Oracle Database - Enterprise Edition - Version 18.3.0.0.0 and later

Information in this document applies to any platform.

GOAL

 This Document explain about switchover steps for 18c and 19c

SOLUTION

Prerequisites

Latest psu/bundle patches

      Primary Note for Database Proactive Patch Program (Doc ID 888.1)

Setup/configuration verification

Primary & Standby should be running with same version of RDBMS

Verify the alert logfiles and make sure there are no errors
Run select on v$database_block_corruption & v$nonlogged_block from primary and standby and make sure there are no
corruptions
Make sure primary and physical standby configurations are good and there are no errors in redo transport and redo apply
    Verify the Physical Standby Database Is Performing Properly    

You can also optionally use the below queries to check the redo transport and apply status.

On Primary:

Check the remote redo log transport status and errors,  V$ARCHIVE_DEST.ERROR will show the details.

SQL> col DEST_NAME for a20

SQL> col DESTINATION for a25
SQL> col ERROR for a15
SQL> col ALTERNATE for a20
SQL> set lines 1000
 SQL> select DEST_NAME,DESTINATION,ERROR,ALTERNATE,TYPE,status,VALID_TYPE,VALID_ROLE from V$ARCHIVE_DEST
where STATUS <>'INACTIVE';

Check the last archivelog created at the primary.

SQL> select   thread#, max(sequence#) "Last Primary Seq Generated"  

              from     gv$archived_log val, gv$database vdb
              where    val.resetlogs_change# = vdb.resetlogs_change#
              group by thread# order by 1;

On Standby:

Using the below query, check the last received archivelog from primary database (RAC database result will be displayed for each
thread).

SQL> select   thread#, max(sequence#) "Last Standby Seq Received"  

              from     gv$archived_log val, gv$database vdb
              where    val.resetlogs_change# = vdb.resetlogs_change#
              group by thread# order by 1;

Check last archive log sequence applied at standby.

SQL> select    thread#, max(sequence#) "Last Standby Seq Applied"

              from     gv$archived_log val, gv$database vdb
              where    val.resetlogs_change# = vdb.resetlogs_change#
              and      val.applied in ('YES','IN-MEMORY')
              group by thread# order by 1;   

Verify Initialization Parameters

Below parameter should have configured correctly.

log_archive_config : should include primary and standby database (if multiple standby databases are existing, then all the
standby database details should be included)
fal_server              : remote server from where archivelog can be fetched
db_unique_name   : unique name under this configuration
log_archive_dest_n: for remote database to send archives

In idle primary & one standby configuration, primary should have configuration (log_archive_dest_n) to send archives to
standby with VALID_FOR clause (PRIMARY_ROLE,ONLINE_FILE) & standby will also have similar configuration.
Once switchover completes, new primary will have log_archive_dest_n configuration to send archive logs/redos to new
standby database.

Ensure 'compatible' parameter is set to same value at primary and standby.

If the datafiles and redo logfiles locations are different between primary and standby, then use db_file_name_convert &
log_file_name_convert    respectively.

Refer: Set Primary Database Initialization Parameters

Understand and Test Fallback Options

Check:  A.4 Problems Switching Over to a Physical Standby Database

 

Pre-Switchover
Ensure Prerequisites are completely verified. Along with Prerequisites, Follow the below guidance to have successful switchover.
These steps should be executed before real planned outage starts and ensure no issues.

Verify Redo/Archive log apply is good and there are no gaps

Run the below query in physical standby to check last archive log sequence received and applied from all the threads. This will
not include current sequence of primary database as the SQL is extracting details from v$archived_log.

SQL> select    thread#, max(sequence#) "Last Standby Seq Applied"

              from     gv$archived_log val, gv$database vdb
              where    val.resetlogs_change# = vdb.resetlogs_change#
               and      val.applied in ('YES','IN-MEMORY')
              group by thread# order by 1;

Check the MRP(Managed Recovery Process) process status (it should be started, running and applying the logs).

SQL> select * from gv$dataguard_process;

Commands to stop & start the managed recovery process.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  DISCONNECT;

If standby database recovery (MRP) started with delay OR if the standby always maintained with lag, then switchover will
consume time to apply the logs to be synchronised.
Before switchover, try to maintain minimal archive log apply lag, which will reduce the total switchover time window.

Verify the apply delay configurations

To reduce apply gap, if the gap is more.

1) Make zero archivelog transport lag Monitoring Redo Transport Services and apply all archivelogs

2) Standby can also be recovered using incremental backup taken from primary Restoring and Recovering Files Over the
Network

Check the datafiles & Tempfiles status

Expected all the datafiles should be online in primary and standby, incase if there are files in offline (OR) NOT in online status,
then restore the file and recover so standby database datafiles are same as primary database datafiles.

Check the file status and use the below command to make files online.

SQL> SELECT NAME FROM V$DATAFILE WHERE STATUS=’OFFLINE’;

SQL> ALTER DATABASE DATAFILE 'datafile-name' ONLINE;

For tempfiles:

SQL> select tf.name filename, bytes, ts.name tablespace    from v$tempfile tf, v$tablespace ts where
tf.ts#=ts.ts#;

Execute above SQL to get tempfile details. Add more tempfile if needed.

Data Guard Physical Standby - Managing temporary tablespace tempfiles (Doc ID 1514588.1)

Online and standby redo logfile configuration

 Online redo logfile (ORL):

set lines 150

col member for a50
select a.thread#,a.group#,a.bytes,a.blocksize,b.type,a.status,b.member from v$log a,v$logfile b where
a.group#=b.group#;

At primary when the above command executed, we may get a.status in (INACTIVE,ACTIVE,CURRENT).
Expected a.status  from Standby is UNUSED, CLEARING or CLEARING_CURRENT, if output has different result, then manually
clear redo logfiles.

For Standby redo logfile(SRL):

select s.thread#,s.group#,s.status,s.bytes,l.type,l.member from v$logfile l,v$standby_log s where

s.group#=l.group#;
Standby redo logfile status would be in UNASSIGNED OR ACTIVE.

Command to clear ORL group:

SQL> ALTER DATABASE CLEAR LOGFILE GROUP <ORL GROUP# >;

If ORL or SRL needs to be cleared in the standby, Managed recovery process has to be stopped.

During switchover ORLs will be cleared if ORLs were not cleared previously, but switchover will be consuming time to complete.
Switchover session will wait for 15 min to complete otherwise timeout will occur. if the switchover is terminated due to timeout,
then retry again until switchover is successful.

If database is configured to use OMF files for Redo logfile OR log_file_name_convert is set, then Online redo logfiles would get
cleared automatically with the managed recovery process is started.

Note: log_file_name_convert parameter is recommended to set in primary & standby even though SRL & ORL locations are
same at primary and standby.
If the file locations are same at primary and standby, then configure log_file_name_convert with same value as replacing
string.
Example:  log_file_name_convert='dummy','dummy'

To manage standby redo logfiles Refer: Managing Standby Redo Logs

Checking the alert logfiles

1) From primary database alert logfile:

    * Check for issue reported for redo transport
    * Ensure there is no password file issue
    * Ensure there are no TNS or connection issue

2) From Standby database alert logfile:

    * There are no error related to Managed recovery
    * Recovery is moving forward by applying the archive log / redo log
    * There are no TNS or connection issue
    * There are no I/O issue or corruption issue
    select * from v$database_block_corruption;  -- it should return no rows
    select * from v$nonlogged_block; -- it should return no rows

Check Archive log GAP & Redo Delay apply

You must configure the LOG_ARCHIVE_DEST_n and LOG_ARCHIVE_DEST_STATE_n parameters for each standby database.
When a switchover or failover occurs, all standby databases continues to receive redo logs / Archivelogs from the new primary
database.

Execute the below command in primary database.

Considering log_archive_dest_2 is configured for the redo shipping.

SQL> SELECT STATUS, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;

STATUS should be Valid

GAP_STATUS should be NO GAP

If different result is reported, then switchover should NOT be tried.

If the delay configured, stop the MRP process and start the MRP process without delay.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

If the delay is not removed, then switchover will take longer time.

Specifying a Time Delay for the Application of Archived Redo Log Files

Switchover
 o
While doing switchover, if standby connection needs to be maintained without disconnecting, then set the parameter
STANDBY_DB_PRESERVE_STATES to SESSION OR to ALL.

Verify the switchover

If the below command executes successfully, then "Database Altered" message should be returned (Execute the below SQL in
the primary).

SQL> ALTER DATABASE SWITCHOVER TO <standby db_unique_name> VERIFY;

In case of an error, fix an issue and then rerun switchover verify command.

Example: "ORA-16475: succeeded with warnings, check alert log for more details", in this case check the alert logfile and
then resolve all the errors/warnings

Switchover steps

If switchover verify is successful, then execute the command to switchover the database.

1) Execute in the current primary

SQL> ALTER DATABASE SWITCHOVER TO <standby db_unique_name>;

if the step 1 is successful, then follow step 2 open the new primary database in open mode.

2) Execute in new primary database

SQL> ALTER DATABASE OPEN;

3) Old primary (current/new standby) should be mounted OR opened depends on the case

If standby is Oracle Active data guard physical standby:

SQL> STARTUP;

If standby is NOT Oracle Active data guard physical standby:

SQL> STARTUP MOUNT;

4) Start redo apply in new standby

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Post Switchover
In primary:

Check, is the archivelogs are being transferred to the standby and getting applied?

SQL> alter system archive log current;

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#;

Incase remote archivelog destination 2 is set in primary (log_archive_dest_2 ), we can use the below query to check the
maximum sequence transferred and applied in the standby.

SQL>select max(sequence#)  from v$archived_log where applied='YES' and dest_id=2;

In standby:

Verify the archivelog availability and the application of the archivelog files.

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

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

Additionally, Alert logfiles can be viewes to confirm the archivelog transfer and archivelog apply in standby.

REFERENCES
NOTE:888.1 - Primary Note for Database Proactive Patch Program
Didn't find what you are looking for? Ask in Community...

Related
Products
Oracle Database Products > Oracle Database Suite > Oracle Database > Oracle Database - Enterprise Edition > Oracle Data Guard > Switchover

Translations
English Source Japanese 日本語

Back to Top
 
Copyright (c) 2023, Oracle. All rights reserved. Legal Notices and Terms of Use Privacy Statement