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.