Failover of physical standby

Reference and: note the following points for the failover of physical standby: After 1 failover, the original primary database is no longer part of the replicuard 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 need to perform any operations. 3. Some Situations

Reference and: note the following points for the failover of physical standby: 1 after the 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 need to perform any operations. 3. Some Situations

Reference and: This book "thinking notes"

Failover of physical standby

Notes:

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 need to perform any operations.

3 in some cases, after the new primary database is configured, all other standby databases need to be created again.

In addition,If the standby of the role to be converted is in maximum protection or maximum availability mode, archive logs should exist continuously. In this case, you can directly execute the archive logs in step 1, otherwise, we recommend that you start from step 1.

Generally, failover means that the primary database is paralyzed and cannot be started at least. Therefore, this type of switchover basically does not require any operation on the primary database. Therefore, if primary and standby are mentioned in the following steps, it is recommended that you execute primary if it can be used again. Even if it can be used, it does not matter, does not affect standby database switching :)

1. Check whether the archive files are continuous

Query the V $ ARCHIVE_GAP view of the standby database to be converted and check whether the archive file 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 file to the standby server to be converted according to the listed record number. This step is very important. You must ensure that all generated archive files exist on the standby server. Otherwise, an error may occur when the data is inconsistent. After the file is copied, use the following command to add it to the data dictionary:

Registration: gap file:

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1 ';

2. Check whether the archive file is complete.

Run the following statements in primary/standby:

This statement obtains the maximum number of files archived by each thread in the current database. If the maximum number of files archived by primary is different from that of standby, you must copy the archive file corresponding to the number to be converted to the standby server. However, since it is a failover, it is possible that the primary database cannot be opened or even Accessed at this time.

3. Start failover and execute the following statements:

At 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 stops the RFS process of the current activity 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 standby database has changed from open to mount;

15:42:07 sys @ felix SQL> alter database open;

Database altered.

15:42:18 sys @ felix SQL>

The remaining steps are very similar to the previous switchover.

4. Switch the physical standby role to 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

In this case, the primary database is no longer part of the data guard configuration. We need to try to see if the original primary database can be restored and transformed into a new standby server.