ORACLE 11G Data Guard role conversion, 11 gguard

ORACLE 11G Data Guard role conversion, 11 gguard


1. ORACLE login uard Role Switching
DataGuard is now the mainstream disaster tolerance solution. Due to its strong adaptability to the network, it can adopt synchronous real-time transmission mode and asynchronous delay transmission mode, it can even become a remote disaster recovery solution. Regardless of the purpose, the DG will inevitably require role conversion, namely switching the standby database to the primary database. role conversion can be divided into switchover and failover.



2. similarities and differences between the two methods
1) switchover is the conversion from the primary database to the standby database and from the standby database to the primary database.
2) After failover, standby is converted to primary database for enabling
3) different application scenarios: Switchover is used for scheduled Switchover, usually for normal tasks such as system upgrades and data migration. Failover is used for unexpected emergencies, for example, abnormal power loss and natural disasters.
4) different degrees of data loss: Switchover will not lose data, and Failover usually means that some data is lost.
5) different solutions: After Switchover, the crash uard environment will not be damaged, and any system with the Primary and Standby roles will exist. However, after Failover, the deployment uard environment will be damaged and must be rebuilt.



3. Perform the switchover operation on primary
Switchover preparation. Note that if you want to switch the role's standby to maximum protection mode, you need to switch it to maximum performance mode first,
First, check whether the switch operation is supported. log on to the primary database and query the switchover_status column of the v $ database table.
SQL> select switchover_status from v $ database;


SWITCHOVER_STATUS
--------------------
TO STANDBY


SQL>
If the column value is "to standby", it indicates that the primary database supports switching TO the standby role. Otherwise, you need TO re-check the Data Guard configuration, for example, check whether the parameter values such as LOG_ARCHIVE_DEST_n are correct and valid.


3.1. Start switchover -- primary.
First, convert the primary role to the standby role and use the following statements:
Alter database commit to switchover to physical standby;
SQL> alter database commit to switchover to physical standby;


Database altered.


SQL>


3.2 restart to mount
SQL> shutdown immediate
ORA-01507: database not mounted


ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.


Total System Global Area 3373858816 bytes
Fixed Size 2218032 bytes
Variable Size1845495760 bytes
Database Buffers1509949440 bytes
Redo Buffers 16195584 bytes
Database mounted.
SQL>


3.3. Check the current status.
SQL> select switchover_status from v $ database;


SWITCHOVER_STATUS
--------------------
TO PRIMARY


SQL>
Switchover_status is to primary.
SQL> select open_mode, database_role from v $ database;


OPEN_MODE DATABASE_ROLE
------------------------------------
MOUNTED PHYSICAL STANDBY


SQL>
Database_role is PHYSICAL standby (physical standby ).
Conversion successful.


4. Perform the switchover operation on the standby database to be converted

4.1 check whether switchover switching is supported
SQL> select switchover_status from v $ database;


SWITCHOVER_STATUS
--------------------
TO PRIMARY


SQL>
In this case, the value of the switchover_status column of the standby database should be "TO_PRIMARY". If not, check the settings in the initialization parameter file and prompt you to change the value compared to the initialization parameter of the original primary database.


4.2. Convert to primary and use the following statement to convert standby to the primary role:
Alter database commit to switchover to primary;
SQL> alter database commit to switchover to primary;


Database altered.


SQL>
Note: The physical standby to be converted can be in mount or open read only mode, but not open read write mode.


4.3. After the conversion is completed, open the new primary database.
Alter database open;
Note: If the database is in open read-only mode, shutdown and start up directly.
View database mode:
SELECT open_mode, database_role FROM v $ database;
SQL> SELECT open_mode, database_role FROM v $ database;


OPEN_MODE DATABASE_ROLE
------------------------------------
READ WRITE PRIMARY


SQL>


5. Verify the new primary and the new standby operation.
Go to the new primary
SQL> show parameter db_unique


NAME TYPEVALUE
-----------------------------------------------------------------------------
Db_unique_name stringpdunq_dg
SQL>
SQL>
SQL> select max (sequence #) from v $ archived_log;


MAX (SEQUENCE #)
--------------
369


SQL>


SQL> alter system switch logfile;
System altered.


SQL>


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


MAX (SEQUENCE #)
--------------
370


SQL>


Go to the new standby database and check
SQL> select max (sequence #) from v $ archived_log;


MAX (SEQUENCE #)
--------------
368


SQL>


The redo log is not sent to the new standby. Check the alert log of the new primary. the following error is returned:
Mon Feb 09 16:55:35 2015
Error 12154 removed ed logging on to the standby
Errors in file/oracle/app/oracle/diag/rdbms/pdunq_dg/powerdes/trace/powerdes_arc2_23808.trc:
ORA-12154: TNS: cocould not resolve the connect identifier specified
PING [ARC2]: Heartbeat failed to connect to standby 'pdunq _ dg '. Error is 12154.
Mon Feb 09 16:56:35 2015
Error 12154 removed ed logging on to the standby
Errors in file/oracle/app/oracle/diag/rdbms/pdunq_dg/powerdes/trace/powerdes_arc2_23808.trc:
ORA-12154: TNS: cocould not resolve the connect identifier specified
PING [ARC2]: Heartbeat failed to connect to standby 'pdunq _ dg '. Error is 12154.



6. troubleshooting
This error is reported because the original primary and standby db_unique_name are different. Therefore, after switchover, the original archive parameter db_unique_name must be consistent with the new standby, that is, it must be pdunq:
Check the parameters of show parameter log_archive_dest_2:
SQL> show parameter log_archive_dest_2;


NAME TYPEVALUE
-----------------------------------------------------------------------------
Log_archive_dest_2 stringSERVICE = pdunq_dg lgwr sync af
Firm VALID_FOR = (ONLINE_LOGFILE
S, PRIMARY_ROLE) DB_UNIQUE_NAME
= Pdunq
Log_archive_dest_20 string
Log_archive_dest_21 string
Log_archive_dest_22 string
Log_archive_dest_23 string
Log_archive_dest_24 string
Log_archive_dest_25 string
Log_archive_dest_26 string


NAME TYPEVALUE
-----------------------------------------------------------------------------
Log_archive_dest_27 string
Log_archive_dest_28 string
Log_archive_dest_29 string
SQL>
-- Modify the log_archive_dest_2 Parameter
Alter system set log_archive_dest_2 = 'service = pdunq_dg lgwr sync affrem VALID_FOR = (ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME = pdunq ';
Alter system set log_archive_dest_state_2 = enable;
Alter system switch logfile;
SQL> alter system set log_archive_dest_2 = 'service = pdunq_dg lgwr sync affrem VALID_FOR = (ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME = pdunq ';


System altered.


SQL> alter system set log_archive_dest_state_2 = enable;


System altered.


SQL> alter system switch logfile;


System altered.


SQL>
Use select max (sequence #) from v $ archived_log to check records in the new primary and standby databases.
SQL> select max (sequence #) from v $ archived_log;


MAX (SEQUENCE #)
--------------
373


SQL>
So far, switchover has been successfully completed.




7. Convert the failover physical standby to the primary database

7.1 check whether the archive file is continuously operated on standby
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


SQL>
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
Yes, you must ensure that all generated archive files exist on the standby server. Otherwise, an error may be reported during conversion due to inconsistent data.
After the file is copied, use the following command to add it to the data dictionary:
Alter database register physical logfile 'filespec1 ';


7.2 check whether the archive file is complete
Run the following statements in primary/standby:
SQL> select distinct thread #, max (sequence #) over (partition by thread #) a from v $ archived_log;


THREAD #
--------------------
1 375


SQL>
This statement obtains the maximum number of files archived by each thread in the current database. If the maximum number of primary and standby is different, you must
Copy the archive file corresponding to the serial number to the standby server to be converted. However, since it is a failover, it is possible that the primary database
It cannot be opened or even accessed.


7.3 start failover and execute it on standby.
Execute the following statement: alter database recover managed standby database finish force;
SQL> alter database recover managed standby database finish force;


Database altered.

SQL>
The FORCE keyword stops the RFS process of the current activity so that the failover can be executed immediately.
The remaining steps are very similar to General switchover.


7.4 switch the physical standby role to primary
SQL> alter database commit to switchover to primary;


Database altered.


SQL>


7.5 Start a new primary database.
If the current database has been mounted, open it directly. If the database is in read-only mode, shutdown immediate first and then start up directly.
First, check the db mode. Command: select open_mode, database_role from v $ database;
SQL> select open_mode, database_role from v $ database;


OPEN_MODE DATABASE_ROLE
------------------------------------
MOUNTED PRIMARY


SQL>


Is mount, so open is required
SQL> alter database open;


Database altered.


SQL>
Check the current data mode of the new primary again:
SQL> select open_mode, database_role from v $ database;


OPEN_MODE DATABASE_ROLE
------------------------------------
READ WRITE PRIMARY


SQL>

Role conversion is completed. The rest is the remedy (for the original primary database). Because 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, transform it into a new standbyServer. The specific operation methods can be divided into two categories: 2. Reconstruction 2. Backup recovery.

Bytes ----------------------------------------------------------------------------------------------------------------
<All Rights Reserved. This document can be reprinted, but the source address must be indicated by link. Otherwise, we will be held legally responsible.>
Original blog address: http://blog.itpub.net/26230597/viewspace-1432708/
Original Author: Huang Shan (mchdba)
Bytes ----------------------------------------------------------------------------------------------------------------