När jag nyligen arbetade med en standby-databas gick jag till DG Broker för att kontrollera status och fick detta:
DGMGRL> show configuration Configuration - resp_ress_config Protection Mode: MaxPerformance Databases: resp - Primary database ress - Physical standby database Error: ORA-16766: Redo Apply is stopped
Hmm ... mitt vänteläge tillämpar inte göra om. När jag försökte starta hanterad återställning fick jag följande i varningsloggen för vänteläge:
Tue Dec 31 09:52:10 2013 Managed Standby Recovery starting Real Time Apply Tue Dec 31 09:52:10 2013 MRP0: Background Media Recovery terminated with error 38868 Errors in file /u01/app/oracle/diag/rdbms/ress/ress2/trace/ress2_pr00_13905.trc: ORA-38868: warning: the control file may have incorrect data file structure Managed Standby Recovery not using Real Time Apply Slave exiting with ORA-38868 exception Errors in file /u01/app/oracle/diag/rdbms/ress/ress2/trace/ress2_pr00_13905.trc: ORA-38868: warning: the control file may have incorrect data file structure Recovery Slave PR00 previously exited with exception 38868 MRP0: Background Media Recovery process shutdown (ress2)
Så ORA-38868 säger till mig att jag har en dålig katalogstruktur. Min första tanke var att detta var relaterat till arbetet jag bloggade om igår. Men det arbetet var på den primära sidan. Jag tittade tillbaka på standbyvarningsloggen och hittade den första förekomsten av detta fel för cirka 2,5 månader sedan. Om detta vore ett produktionssystem skulle jag kunna ha stora problem med att låta det här problemet gå obemärkt förbi under den tidsperioden. Men jag har åtgärder på plats för att varna mig om mitt produktionsberedskap släpar efter det primära under en oacceptabel tid. Detta är bara ett testsystem som jag kan blåsa bort och börja om från början om jag behöver. Men vad kul skulle det vara? Låt oss se om vi kan åtgärda problemet.
Mitt första stopp var Metalink. Men jag fick noll träffar för ORA-38868-felet. När jag gjorde en webbsökning fick jag en relevant träff som erbjöd en lösning med att helt enkelt starta om instansen och starta om applicera om. Jag var skeptisk, men försökte den enkla lösningen. Det borde inte vara någon överraskning att en enkel omstart av instansen inte löste problemet. Felet talar om för mig att min kontrollfil har korruption i den. Att starta om instansen kommer inte att fixa korruption av kontrollfilen. Eftersom Metalink och Internet inte är till någon nytta antar jag att det är upp till mig att fixa detta. Om allt annat misslyckas släpper jag bara vänteläget och återskapar det.
Min första lösning är att gå tillbaka till den primära och skapa en standby-kontrollfil. Starta sedan standby med kontrollfilen för standby. Jag är säker på att en ny kontrollfil från den primära kommer att lösa problemet. Jag måste dock ansöka om 2,5 månaders redogörelse som jag inte längre har tillgänglig.
Jag har försökt undersöka att använda RMAN för att rulla fram ett standby-läge via en inkrementell backup. Men det här verkar hamna lågt på min prioriteringslista över saker att göra. Jag har ett kommande projekt där jag kommer att behöva veta hur man gör detta och det projektet är nu mindre än en månad kvar. Så det här verkar vara ett perfekt tillfälle att öva på den här tekniken för mitt kommande projekt och att fixa mitt nuvarande problem. Stegen för att göra detta finns i:
Metalink Note 836986.1 Steps to Perform for Rolling Forward a Standby Database Using RMAN Incremental Backups
Stegen i det här dokumentet rullade inte bara fram mitt vänteläge, utan återskapade också kontrollfilerna, vilket löste mitt problem.