Oracle Active Data Guard is a Physical Standby Option available with Enterprise Edition. Thanks to Active Data Guard, we do not leave Data Guard idle. It contains many features like below. It licensed. Active Data Guard provides automatic block repair feature. With this feature, a DML operation on the Primary side can be seen instantly on the Standby side.
- Real-Time query,
- We can get Fast Incremental Backup on physical standby database,
- Can fix automatic block corruption,
- Far SYNC feature we can use
If a block is found to be corrupt as a result of a query run in the primary database, the corrupted block is automatically repaired by taking it from the Physical Standby Database, which is the Active Data Guard.
If a block is found to be corrupt as a result of a query run in Physical Standby, the corrupted block is taken from the Primary Database and automatically repaired.
If the Physical Standby database is not Active Data Guard then this is done manually.
If a single block will be repaired;
| RECOVER DATAFILE 6 BLOCK 3; |
If more than one Block in more than one Datafile will be repaired;
| RECOVER DATAFILE 2 BLOCK 43,79 DATAFILE 6 BLOCK 183; |
When these commands are executed, Oracle searches the block that is corrupt from the following;
- Physical Standby Database
- Flashback Logs
- Full veya Level 0 incremental Backup
If you do not want to search for uncorrupted block from Standby Database, use the following command;
| RECOVER BLOCK … EXCLUDE STANDBY |
How To Enable Active Data Guard?
We can switch the physical standby database in mount mode to the active data guard as follows.
Step1: Check standby database recovery mode.
| SQL> select status from gv$instance; STATUS ------------ MOUNTED MOUNTED |
Step2: Stop Recovery.
| SQL> alter database recover managed standby database cancel; Database altered. |
Step3: Enable Active Data Guard.
| SQL> alter database open read only; Database altered. |
Step4: Check Database Role.
| SQL> select OPEN_MODE, DATABASE_ROLE from v$database; OPEN_MODE DATABASE_ROLE -------------------- ---------------- READ ONLY PHYSICAL STANDBY |
Step5: Start Recovery.
| SQL> alter database recover managed standby database using current logfile disconnect; Database altered. |
Step6: Check Database Role After Recovery.
| SQL> select OPEN_MODE, DATABASE_ROLE from v$database; OPEN_MODE DATABASE_ROLE -------------------- ---------------- READ ONLY WITH APPLY PHYSICAL STANDBY |
Step7: Try to login from third party clients (TOAD, SQL Developer).
Step8: Check database status.
| SQL> select status from gv$instance; STATUS ------------ OPEN MOUNTED |
Step9: Perform he same operations in the other Node and check the database role.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | SQL> alter database recover managed standby database cancel; Database altered. SQL> alter database open read only; Database altered. SQL> alter database recover managed standby database using current logfile disconnect; Database altered. SQL> select OPEN_MODE, DATABASE_ROLE from v$database; OPEN_MODE DATABASE_ROLE -------------------- ---------------- READ ONLY WITH APPLY PHYSICAL STANDBY SQL> select status from gv$instance; STATUS ------------ OPEN OPEN |
How To Disable Active Data Guard?
Step1: Shutdown Instances on the standby side and open them in Mount mode.
| SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount; ORACLE instance started. Total System Global Area 6480490496 bytes Fixed Size 2265384 bytes Variable Size 1241517784 bytes Database Buffers 5217714176 bytes Redo Buffers 18993152 bytes Database mounted. |
Step2: Enable Real Time Apply. I recommend you read the article named “What is Real Time Apply in Dataguard”
| SQL> alter database recover managed standby database using current logfile disconnect; Database altered. |
Step3: Check the instance status and the role of Databases.
| SQL> select status from gv$instance; STATUS ------------ MOUNTED MOUNTED SQL> select OPEN_MODE, DATABASE_ROLE from v$database; OPEN_MODE DATABASE_ROLE -------------------- ---------------- MOUNTED PHYSICAL STANDBY |
Step4: On the primary side, Log Switch operation is performed separately from both Node.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | SQL> alter system switch logfile; System altered. SQL> SELECT MAX(SEQUENCE#), THREAD# FROM V$ARCHIVED_LOG GROUP BY THREAD#; MAX(SEQUENCE#) THREAD# -------------- ---------- 77 1 40 2 SQL> alter system switch logfile; System altered. SQL> SELECT MAX(SEQUENCE#), THREAD# FROM V$ARCHIVED_LOG GROUP BY THREAD#; MAX(SEQUENCE#) THREAD# -------------- ---------- 77 1 42 2 |
Step5: Check whether Redo-Transport is coming to standby side.
| SQL> SELECT MAX(SEQUENCE#), THREAD# FROM V$ARCHIVED_LOG GROUP BY THREAD#; MAX(SEQUENCE#) THREAD# -------------- ---------- 77 1 42 2 |
Step6: By checking the LAG status, check whether the redos transported are applied or not.
| SQL> column name format a22 SQL> column value format a15 SQL> column value format a30 SQL> column datum_time format a20 SQL> column time_computed format a20 SQL> set linesize 9000 SQL> SQL> select * from v$dataguard_stats; NAME VALUE UNIT TIME_COMPUTED DATUM_TIME ---------------------- ------------------------------ ------------------------------ -------------------- -------------------- transport lag +00 00:00:00 day(2) to second(0) interval 01/03/2017 21:57:43 01/03/2017 21:57:42 apply lag +00 00:00:00 day(2) to second(0) interval 01/03/2017 21:57:43 01/03/2017 21:57:42 apply finish time +00 00:00:00.000 day(2) to second(3) interval 01/03/2017 21:57:43 estimated startup time 33 second 01/03/2017 21:57:43 |
Comments
Post a Comment