Когато работех върху резервна база данни наскоро, отидох до DG Broker, за да проверя състоянието и получих това:
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
Хм... моят режим на готовност не прилага повторно изпълнение. Когато се опитах да стартирам управлявано възстановяване, получих следното в дневника за предупреждения в режим на готовност:
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)
Така че ORA-38868 ми казва, че имам лоша структура на директории. Първата ми мисъл беше, че това е свързано с работата, за която писах в блога вчера. Но тази работа беше на първо място. Погледнах назад към дневника за предупреждения в режим на готовност и открих първата поява на тази грешка преди около 2,5 месеца. Ако това беше производствена система, бих могъл да имам големи проблеми да оставя този проблем да остане незабелязан за този период от време. Но имам мерки, които да ме предупреждават, ако моят производствен режим на готовност изостава от първичния за неприемлив период от време. Това е само тестова система, която мога да издуха и да започна от нулата, ако имам нужда. Но какво забавление би било това? Нека видим дали можем да отстраним проблема.
Първата ми спирка беше Metalink. Но получих нула попадения за грешката ORA-38868. Когато правех търсене в мрежата, получих едно подходящо попадение, което предлага решение за просто рестартиране на екземпляра и рестартиране на прилагането на повторно изпълнение. Бях скептичен, но опитах лесното решение. Не трябва да е изненада, че простото рестартиране на инстанцията не отстрани проблема. Грешката ми казва, че моят контролен файл е повреден. Рестартирането на екземпляра няма да поправи повредата на контролния файл. Тъй като Metalink и интернет не са от полза, предполагам, че зависи от мен да поправя това. Ако всичко друго не успее, просто ще махна режима на готовност и ще го създам отново.
Първоначалното ми решение е да се върна към основния и да създам контролен файл в режим на готовност. След това стартирайте режима на готовност с контролния файл за режим на готовност. Имам увереност, че нов контролен файл от основния ще разреши проблема. Трябва обаче да прилагам 2,5 месеца повторно изпълнение, от които вече не разполагам.
Опитвах се да проуча използването на RMAN за преместване напред в режим на готовност чрез инкрементално архивиране. Но това изглежда е ниско в списъка ми с приоритетни неща, които трябва да направя. Имам предстоящ проект, в който ще трябва да знам как да направя това и този проект вече е по-малко от един месец. Така че това изглежда като идеалното време да практикувам тази техника за предстоящия си проект и да коригирам текущия си проблем. Стъпките за това са в:
Metalink Note 836986.1 Steps to Perform for Rolling Forward a Standby Database Using RMAN Incremental Backups
Стъпките в този документ не само преместиха моя режим на готовност, но и пресъздадоха контролните файлове, като по този начин решиха проблема ми.
