- Oracle Database 12c Backup and Recovery Survival Guide
- Francisco Munoz Alvarez Aman Sharma
- 257字
- 2021-04-02 10:19:59
Repairing NOLOGGING changes on physical and logical standby databases
After a NOLOGGING operation on the primary is detected, it is recommended to create a backup immediately if you want to recover from this operation in the future. However, there are additional steps required if you have an existing physical or logical standby database. Executing these steps is crucial if you want to preserve the data integrity of your standby databases.
For a physical standby database, Data Guard's Redo Apply process will process the invalidation redo and mark the corresponding data blocks as corrupted. Follow these steps to reinstate the relevant datafiles:
- Stop Redo Apply (
RECOVER MANAGED STANDBY DATABASE CANCEL). - Take the corresponding datafile(s) offline (
ALTER DATABASE DATAFILE <datafile_name> OFFLINE DROP;). - Start Redo Apply (
RECOVER MANAGED STANDBY DATABASE DISCONNECT). - Copy the appropriate backup of affected datafiles over from the primary database (for example, use
RMANto backup datafiles and copy them). - Stop Redo Apply (
RECOVER MANAGED STANDBY DATABASE CANCEL). - Make the corresponding datafiles online (
ALTER DATABASE DATAFILE <datafile_name> ONLINE;). - Start Redo Apply (
RECOVER MANAGED STANDBY DATABASE DISCONNECT).
For a logical standby database, Data Guard's SQL Apply process skips over the invalidation redo completely, thus the subsequent corresponding table or index will not be updated. However, future reference to missing data will result in ORA-1403 (no data found). In order to resynchronize the table with the primary table, you need to re-create it from the primary database. Follow the steps described in Oracle Data Guard Concepts and Administration 12c Release 1 Section 11.5.5. Basically, you will be using the DBMS_LOGSTDBY.INSTANTIATE_TABLE procedure.