I have 2 servers: Primary (ABCUAT) and Standby (ABCUAT1) configured as Active-Standby DataGuard by previous DBA.
When I took over the system, I think DataGuard was not in sync, but I could not confirm that because the Archive Log List gives me the same log sequence on both server.
Questions:
- If DataGuard is not in sync, why does the Archive log list show the same sequence number in both server? I thought if the sequence number were the same, it meant the log have been applied to the standby database.
- How to resume DataGuard if not in sync? The gap seem to be huge according to max(sequence#).
-
I tried to delete some old archive log files with
RMAN> delete noprompt expired archivelog all;
but got in response:specification does not match any archived log in the repository,
but physically in the directory there are 50GB of files dated year 2018.
Findings:
SYS@ABCUAT>archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 190144
Next log sequence to archive 190146
Current log sequence 190146
Standby server :
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 190144
Next log sequence to archive 0
Current log sequence 190146
Primary:
SYS@ABCuat>select max(sequence#) from v$log_history
MAX(SEQUENCE) 190251
Standby server :
SQL> select max(sequence) from v$log_history
MAX(SEQUENCE#) 7421
DataGuard configuration:
DGMGRL> show configuration;
Configuration - dg_config
Protection Mode: MaxAvailability
Databases:
ABCUAT - Primary database
Warning: ORA-16629: database reports a different protection level from the protection mode
ABCUAT1 - Physical standby database (disabled)
Fast-Start Failover: DISABLED
Configuration Status:
WARNING
DGMGRL> show database ABCUAT1
Database - ABCUAT1
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: (unknown)
Apply Lag: (unknown)
Apply Rate: (unknown)
Real Time Query: OFF
Instance(s):
O ABCUAT1
Best Answer
resetlogs_change#
too.The standby database was disabled in the broker configuration. Enable it in
dgmgrl
:enable database ABCUAT1;
If you are in luck and the standby has all the necessary logs, it will start processing them and it will eventually catch up to the primary. You should see a decreasing transport/apply lag value instead of
unknown
. If it is unable to do so, newer errors will be shown.At this point you may have everything on the standby site which just needs processing. Or you could also have an archive gap when the standby is unable to continue due to missing logs, which you can resolve by restoring the missing logs or rolling forward the standby with an incremental backup or rebuilding the standby. Or the standby could be in a totally different state, like a snapshot standby, without the broker being aware of it.