The failover of physical standby

Reference and: "Think Twice" this book

The failover of physical standby

Note Some points:

After 1 failover, the original primary database is no longer part of the data guard configuration by default.

2 in most cases, other logical/physical standby databases are not directly involved in the failover process, so these databases do not require any action.

3 in some cases, after the new primary database configuration, all the other standby databases will need to be recreated.

In addition, if the standby of the role to be converted is in the maximum protection or maximum availability mode, the archive log should be continuous, in which case you can proceed directly from step 3rd, otherwise you are advised to follow the procedure from 1th Step to begin execution.

In general, failover means that the primary database is paralyzed, at least not, so this type of switching basically does not need to do what the database primary. So if the following steps refer to primary and standby execution, it is only recommended that if primary can still be used, then execute it, even if it can use you do not, it does not matter, does not affect the standby database switch:)

1. Check whether the archive file is continuous

Query the V$archive_gap view of the standby database to be converted to confirm that the archive is connected:

Sql>select thread#, low_sequence#,high_sequence# from V$archive_gap;

No rows selected

If a record is returned, copy the corresponding archive to the standby server to be converted according to the listed record number. This step is important to ensure that all the generated archives are already present on the standby server, or the data inconsistency may cause the conversion times to be wrong. After the file is copied, add it to the data dictionary with the following command:

Registration: Gap File:

sql> ALTER DATABASE REGISTER physical LOGFILE ' filespec1 ';

2, check the integrity of the archive file

Execute the following statements in Primary/standby, respectively:

This statement obtains the maximum number of archived files for each thread in the current database, and if the primary is not the same as the standby maximum sequence number, the archive file that corresponds to the extra ordinal must be copied to the standby server to be converted. However, since it is failover, it is possible that the primary database cannot be opened at this time, or even inaccessible.

3. Start failover execute the following statement

15:30:42 Scott@felix SQL>CONN/ASSYSDBA

Connected.

15:30:51 sys@felix sql>alter database recover Managedstandby database finishforce;

Database altered.

The FORCE keyword will stop the currently active RFS process so that the failover can be executed immediately.

15:30:58 Sys@felix sql>select swtichover_status from V$database;

Select Swtichover_status from V$database

*

ERROR at line 1:

ORA-00904: "Swtichover_status": Invalid identifier

 

15:31:21 sys@felix sql>select status from V$instance;

 

STATUS

------------------------

Mounted

we can find that the repository has been changed from open to Mount State;

 

15:42:07 Sys@felix sql>alter Database open;

Database altered.

15:42:18 Sys@felix sql>

the rest of the steps are very similar to the front switchover.

4, switch physical standby role for primary

15:42:18 Sys@felix sql>ALTER DATABASE commit to switchover to primary;

Database altered.

15:45:18 Sys@felix sql>select switchover_status from V$database;

Switchover_status

----------------------------------------

Not allowed

15:45:38 Sys@felix sql>select open_mode from V$database;

Open_mode

----------------------------------------

Mounted

15:48:16 Sys@felix sql>alter Database open;

Database altered.

15:48:36 Sys@felix sql>select open_mode from V$database;

Open_mode

----------------------------------------

READ WRITE

now that the primary database is no longer part of the data guard configuration, all we need to do is try to see if we can restore the original primary database and transform it into a new standby server.