Data guard -- theoretical explanation (III)

1.Data Guard

The first chapter is the detailed reading – Portal

2 DG Services Detailed explanation – Redo Transport Services

The second chapter is the detailed reading – Portal

3 DG Services Detailed explanation – Apply Services

3.1 Apply Services

Apply service It can automatically apply the received redo data, So as to maintain the synchronization of the primary and standby databases . By default , Only when standby redo log After archiving ,apply services To go to apply This information .
If enabled real-time apply, apply services It's going to be direct apply current standby redo The data in , Come here with the data , Just directly apply, Instead of waiting for the archive to start apply.

• Redo Apply (physical standby databases only) ： Use media recovery To keep the main library and physical standby Synchronization of Library .
• SQL Apply (logical standby databases only)： Received from redo data Rebuild SQL sentence , And then in logical standby Execute these on the SQL Statement to achieve synchronization .

Standby Database On Apply Service The corresponding process ：

1. If it is physical standby database, Then it is by MRP(Managed Recovery
   Process) Process to be responsible Redo Apply journal .
2. If it is logical standby database, Then it is by LSP（Logical Standby
   Process） Process to be responsible SQL Apply.

3.2 Apply Services Configuration options

3.2.1 Use Real-Time Apply Realization redo data real time apply

(1) physical standby databases：

SQL>alter database recover managed standby database using current logfile disconnect from session;

(2)logical standby databases：

SQL>ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

3.2.2 Specify the backup archive delay apply

Set up Time Delay
We can do it in primary database and standby database Of LOG_ARCHIVE_DEST_n Parameter DELAY=minutes attribute . default DELAY=30 minute .

Cancel Time Delay
about physical standby database：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

about logical standby database：

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;

3.2.3 stop it Redo Apply

about physical standby database： Finally, never use ️finish, Otherwise DG It's over

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

about logical standby database：

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

3.3.3 monitor Primary, Physical, Snapshot Standby Databases Application

 Check the process status of the standby database 
select process,status from V$MANAGED_STANDBY;  
 Check whether there is eeror
select dest_name,status,error from V$ARCHIVE_DEST; 
 Check the log application of the primary database and the standby database 
select sequence#,applied from V$ARCHIVED_LOG; 

4 DG Services Detailed explanation – Role Transitions

4.1 Role Transitions

Switchover
Switchover Switching allows primary Switch with a standby database , And this switching has no data loss .

Failover
When the main database is unavailable or unresponsive , We can activate the standby database into primary state . Before the standby database is activated , If it is not the mode of maximum protection or maximum availability , Then there may be some data loss . If the main library has been started Flashback Database, You can flash the main library back to the previous state , In this way, the original primary database can continue to be used as a standby database .

4.1.1 Role Transition Preparatory work

1. Verify the configuration information of the primary and standby databases , Include initialization parameters , Archiving mode ,standby redo logs and online redo log.
2. Query in the main database V$ARCHIVE_DEST_STATUS View , Verify that the standby database does not redo Transmission error perhaps redo gap.
3. Ensure that the primary and standby databases Temp Table spaces are consistent .
4. remove standby On any delay apply redo Set up .
5. If it's going to be RAC Switch from the primary database to the physical standby database ,RAC Only one node can be reserved in the main library , Other nodes should be closed , stay switchover After that, start the closed node .
6. If the standby database is real-time apply The physical standby, And is read only Pattern , Before switching , It is recommended to start the standby database to mount state , instead of open state , This can achieve the fastest role switching , There is no need to clear the user's before switching session Connect .

If there are more than one standby, stay Role Transition How to choose ？
（1） standby The location of the database .
（2） standby database Performance of , such as CPU,I/O, Bandwidth, etc. .
（3） perform role transition Time required , It mainly depends on how many redo data need apply.
（4） Standby Type of database .

4.1.2 Switchover explain

DG Of switchover Operation points 2 A step ：

1. Switch the current primary database to the standby database
2. Switch the original / standby database to the primary database .

4.1.3 Failover explain

Failover matters needing attention ：

• If possible , Before activating the standby database , We should put as many of the main database redo data Transfer to the standby database , And Application . This can reduce data loss .
• maximum protection Mode cannot be Failover.

4.2 Physical Standby Of switchover

Verify whether the primary database can be switched to the standby database

Execute the following in the main database SQL Inquire about ：

SQL> select switchover_status,database_role,open_mode from v$database;

The result is TO STANDBY or SESSIONS ACTIVE Indicates that switching is possible ; When SESSION ACTIVE when , Standby database switching requires WITH SESSION SHUTDOWN;

Switch the primary library to the standby library

SQL> alter database commit to switchover to physical standby with session shutdown;

If you want to switch DUBUG

SQL> oradebug setmypid;
SQL> alter database commit to switchover to physical standby with session shutdown;
SQL> oradebug tracefile_name;

The original main library and start to mount state

SQL> select open_mode from v$database;
SQL> shutdown immediate;
SQL> startup mount;

Verify whether the original and standby databases can be switched to the primary database

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

The result is TO PRIMARY or SESSIONS ACTIVE Indicates that it can be switched to the main database ;

Switch the original / standby database to the primary database

SQL> alter database commit to switchover to primary with session shutdown;
SQL> select open_mode from v$database;

Open new master library

SQL> ALTER DATABASE OPEN;

In New Physics standby Start the REDO APPLY

SQL> alter database recover managed standby database disconnect from session;

verification

SQL> alter system switch logfile; 
SQL> select sequence#,applied from v$archived_log;

4.3 Physical Standby Of Failover

Generally do Failover The switching is caused by the failure of the main database , Problems arise , But as long as the main library can be started to mount state , So in 11g In this environment, you can archive and current online redo log Brush it on the spare warehouse , as long as Flush success ,Failover There will be no data loss . If it is 10g Environmental Science , You need to manually archive and redo Copy logs to the standby database , Manually register file information and apply

The original master database has not been sent Redo data Brush to standby warehouse

SQL> ALTER SYSTEM FLUSH REDO TO 'study_st';

Verify the archive information recently received by the standby database

SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

Confirm and solve GAP
Query in the backup database V$ARCHIVE_GAP, Confirm the existence of GAP, If there is a slave database copy To come over , Sign up for .

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

stop it Redo Apply.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

end Apply be-all Redo data
Execute the following in the standby database SQL, End all Apply：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

Verify whether the standby database can be switched to the primary database

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

Switch the standby database to the primary database
The implementation is as follows SQL Finish switching ：

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

Open new master library

SQL> ALTER DATABASE OPEN;

mandatory Failover
Start the main library to mount State and FLUSH REDO

SQL> shutdown immediate
SQL> startup mount;
SQL> alter system flush redo to 'dave_st';
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> alter database activate physical standby database;
Database altered.
SQL> alter database open;

That's all for today's article , Update later Data Guard ---- A detailed explanation of the theory ( Four ) and ADG The actual combat 11g and 19C