well, oracle dataguard in general is rock solid (if configured well – but you will find a lot of guides in the internet how to do so)… but as always, sometimes something is not working as it should and the standby is out of sync afterwards (i.e. a network outage between the servers, and to avoid archiver stuck on the primary site you are forcing a delete of the archive logs).<\/p>\n
OK, the network is working again, so how to solve the gap? If only a few archivelogs are missing, my first choice would be a restore of the archivelogs from backup. But what if thousends of archivelogs are missing? restore them all from tape? Based on my experiences, this could be a very time consuming procedure, in worst case the tape drive is not fast enough to catch up with the primary. In this case you may consider rebuilding the standby (rman> duplicate database for standby from active database;) … have you ever tried to do this with a 50 TB database? The solution might be an incremental recovery! If you consider some peculiarities, it’s not so complicated…<\/p>\n
you cannot apply an incremental backup while the apply is running, so let’s stop it:<\/p>\n
\r\ndgmgrl \/\r\nedit database 'ORCLRB' set state='APPLY-OFF';\r\n<\/pre>\n\n
- evaluate what’s missing<\/li>\n<\/ol>\n
Then we have to figure out where our incremental backup shoud start… the easy way is to query the v$database view to get the current scn – but this only returns the information stored in the controlfile, sometimes the headers of the datafiles do have a lower scn and rman refuses to start the recovery. so the sql must be like this:<\/p>\n
\r\n# execute on standby!\r\nsqlplus \/ as sysdba\r\nset linesize 200\r\nSELECT 'BACKUP INCREMENTAL FROM SCN '||min(SCN)||' DATABASE FORMAT ''\/tmp\/recover_standby_%U'';' FROM (\r\n select current_scn SCN from V$DATABASE\r\n union all\r\n select min(checkpoint_change#) from v$datafile_header \r\n where file# not in (select file# from v$datafile where enabled = 'READ ONLY')\r\n);\r\n<\/pre>\n\n
- start backup<\/li>\n<\/ol>\n
well, just execute the output of the above sql on the primary database… and when it is finished, you also need a fresh standby controlfile:<\/p>\n
\r\n# execute on primary!\r\nsqlplus \/ as sysdba\r\nALTER DATABASE CREATE STANDBY CONTROLFILE AS '\/tmp\/stby.ctl';\r\n<\/pre>\n\n
- start recover<\/li>\n<\/ol>\n
First you have to make the backup availeble on the standby site… either mount as NFS device or copy the backup files via scp to the standby site. Then catalog the files and start recovery…<\/p>\n
\r\n# execute on standby!\r\nrman target \/\r\ncatalog start with '\/tmp\/recover_standby';\r\nrecover database noredo;\r\n<\/pre>\n\n
- restore controlfile<\/li>\n<\/ol>\n
now we have to “update” the controlfile… since this is not possible, we are doing a full restore.<\/p>\n
\r\n# execute on standby!\r\nrman target \/\r\nshutdown immediate;\r\nstartup nomount;\r\nrestore controlfile from '\/tmp\/stby.ctl';\r\nalter database mount;\r\nexit;\r\n<\/pre>\nif the structure of the database is not exactly the same as on the primary site, you have to populate the the new file and folder names:<\/p>\n
\r\nrman target \/\r\ncatalog start with '+U01\/ORCLRB\/DATAFILE';\r\nswitch database to copy;\r\n<\/pre>\n\n
- enable redo apply<\/li>\n<\/ol>\n
almost finished, now we only have to enable the dataguard process again…<\/p>\n
\r\ndgmgrl \/\r\nedit database 'ORCLRB' set state='APPLY-ON';\r\n<\/pre>\ndone… just check the alert.log if the standby is receiving and applying the last few archivelogs.<\/p>\n","protected":false},"excerpt":{"rendered":"
well, oracle dataguard in general is rock solid (if configured well – but you will find a lot of guides in the internet how to do so)… but as always, sometimes something is not working as it should and the … Continue reading