Switch between the primary and standby databases of DG (physical standby database)

Switch between the master and slave databases of DG
I. Sequence of opening and closing databases

Database opening sequence	Start the slave database first, and then the master database (start listening and open alarm logs)
Database close sequence	First shut down the master database, then shut down the slave database

 

II. master/slave database switchover 1. Operation process overview Step 1: Start the slave database, listen, and alert; Step 2: Start the master database, listen, and alert; Step 3: query information of the master database (bj)

SQL>Selectname, dbid, database_role, protection_mode from v $ database;

Step 4: recover the slave database (sh)

SQL>Recovermanaged standby database disconnect from session;

Step 5: insert data to the slave database

SQL>Insert into scott. emp1 select * from scott. emp;

Error

Although the standby database is open, it is read-only.

Step 6: Check whether the logs of the master database (bj) and slave database (sh) are consistent

SQL>Selectmax (sequence #) from v $ archived_log where name is not null;

Or SQL>Selectmax (sequence #) from v $ archived_log;

Example:

Master Database:

Slave Database:

It indicates that the maximum serial number that has been archived is 34, indicating that logs are synchronized and can be switched between the master and slave databases.

Step 7: Check whether switchover is sufficient in the master database (bj)

SQL>Selectname, database_role, protection_mode, switchover_status from v $ database;

Switchover_status: "to standby" indicates that you agree TO switch.

Step 8: Check whether the slave database (sh) can be switched.

SQL>Selectname, database_role, protection_mode, switchover_status from v $ database;

Note: The standby database does NOT agree to take the initiative to cut the database into the master database. The not allowed status indicates that the database is normal.

Step 9: check sessions on the master database (bj)

SQL>Select username, sid from v $ session where username is notnull;

Check whether the user is still using the database. If the user is still using the database, he or she does not agree to the switch. Before the switch, make sure that no user is using the database.

Step 10: change the master database (bj) to the physical standby database (sh)

If no session exists, change the master database (bj) to the physical standby database (sh)

SQL>Alter databasecommit to switchover to physical standby;

If a session exists, close the session and change the master database (bj) to the physical standby database (sh)

SQL>Alter database commit to switchover to physical standby withsession shutdown;

Step 11: close or restart the master database (bj) to the mount status

SQL>Shutdown immediate;

SQL>Startup mount;

SQL>Selectswitchover_status from v $ database;

 

SWITCHOVER_STATUS

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

TO PRIMARY

 

Note: At this time, both databases should be in the standby database status.

Step 12: verify the slave database's switch status

SQL>SELECTSWITCHOVER_STATUS from v $ DATABASE;

 

SWITCHOVER_STATUS

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

TO_PRIMARY -- can be converted to the master database, which indicates the status of the slave database.

 

Step 13: convert the target physical standby database (sh) to the master database

SQL>Alter databasecommit to switchover to primary (withsession shutdown );

Step 14: The Slave Database (sh) is switched to the master database, and the physical slave database is started to open

If the physical standby database (bj) is not in read-only mode at the recent start, open the database directly and then proceed.

SQL>Select status fromv $ instance;

 

STATUS

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

MOUNTED

 

SQL>Alter database open;

SQL>Select switchover_statusfrom v $ database;

 

SWITCHOVER_STATUS

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

TO STANDBY

 

If the physical standby database (bj) is in read-only mode at a recent startup, shut down the database normally before starting the database.

SQL>Shutdown immediate;

SQL>STARTUP;

Step 15: enable the log application again on the new slave database (bj)

SQL>Alter databaserecover managed standby database disconnect from session;

Step 16: switch the log on the new master database (sh) and transmit the data to the slave database.

SQL>Alter system switchlogfile;

SQL>/

SQL>Select max (sequence #) from v $ archived_log;

 

MAX (SEQUENCE #)

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

56

SQL>Col name for a50;

SQL>Select NAME, SEQUENCE # from v $ archived_log;View Archived logs

Step 17: view the archive on the slave database (bj). If the two values are equal, the slave database can receive logs.

SQL>Select max (sequence #) from v $ archived_log;

MAX (SEQUENCE #)

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

56

SQL>Col name for a50;

SQL>Select NAME, SEQUENCE # from v $ archived_log;View Archived logs

 

2. Summarize the key points of master/slave database switchover

Hour Room Axis Bytes Bytes Bytes Bytes Bytes Bytes Bytes Bytes Bytes Bytes Bytes Bytes	Master Database	Slave Database
	Check whether switchover is allowed (consent should be displayed)
		Whether the standby database query can be switched (it should be displayed as disagree)
	Switch to physical standby database
	Switch to the mount status
		View the slave database switch status
		Convert to master database
		Switch to the mount status
	Start to open
		Start to open
	Enable Log Application
		Switch logs
		View the archive serial number
	View the archive serial number
	Query status: Slave Database	Query status: Master Database

 

 

 

**************************************** *******Statement************************************************ 

Original works, from "Deep Blue blog" blog, welcome to reprint, reprint please be sure to indicate the source (http://blog.csdn.net/huangyanlong ).

Please leave a message if the statement is incorrect. Thank you very much.

Reminder: click the folder to view the folder.

*****************************************************************************************************

Switch between the primary and standby databases of DG (physical standby database)