After my post Quick Oracle Dataguard check script I have some considerations to add:
to check the gap of applied log stream by MRP0 process it’s sufficient to replace this query in the perl script I posted:
|
1 2 |
select SEQUENCE#, BLOCK# from v\$managed_standby where process='RFS' and client_process='LGWR' |
with this new one:
|
1 2 |
select SEQUENCE#, BLOCK# from v\$managed_standby where process='MRP0' |
To check this you have to meet the following condition: You should have real-time apply enabled (and possibly NODELAY clause specified in your recover statement). Check it with this query:
|
1 |
SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS; |
It should be “MANAGED REAL TIME APPLY”.
If not using realtime apply your MRP0 process will wait until you have a new archive, so even if you have redo transport mode set to LGWR you’ll wait for standby log completion. Your gap of applied redo stream will be at least one sequence#.
With transport mode set to LGWR and real-time apply the output of the perl script is similar to this one:
|
1 2 3 4 |
# ./checkDataGuard.sh PROD : 1230 20631 STANDBY: 1230 20613 18 blocks gap |
The whole gap between your primary and standby database should be LOW.
Latest posts by Ludovico (see all)
- New views in Oracle Data Guard 23c - January 3, 2024
- New in Data Guard 21c and 23c: Automatic preparation of the primary - December 22, 2023
- Does FLASHBACK QUERY work across incarnations or after a Data Guard failover? - December 13, 2023