Kiedy ostatnio pracowałem nad zapasową bazą danych, poszedłem do DG Broker, aby sprawdzić status i otrzymałem to:
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… mój tryb gotowości nie wykonuje ponawiania. Gdy próbowałem rozpocząć zarządzane odzyskiwanie, w dzienniku alertów trybu gotowości pojawiły się następujące informacje:
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)
Więc ORA-38868 mówi mi, że mam złą strukturę katalogów. Moja pierwsza myśl była taka, że ma to związek z pracą, o której wczoraj pisałem na blogu. Ale ta praca była po stronie pierwotnej. Spojrzałem wstecz na dziennik alertów stanu gotowości i znalazłem pierwsze wystąpienie tego błędu około 2,5 miesiąca temu. Gdyby to był system produkcyjny, mógłbym mieć duże kłopoty, aby ten problem pozostał niezauważony przez ten czas. Ale mam środki, które ostrzegają mnie, jeśli mój stan gotowości produkcyjnej opóźni się w stosunku do podstawowego przez niedopuszczalny okres. To tylko system testowy, który mogę zdmuchnąć i zacząć od zera, jeśli zajdzie taka potrzeba. Ale co by to było za zabawne? Zobaczmy, czy możemy rozwiązać problem.
Moim pierwszym przystankiem był Metalink. Ale dostałem zero trafień dla błędu ORA-38868. Podczas wyszukiwania w Internecie otrzymałem jeden trafny hit, który oferował rozwiązanie polegające na prostym ponownym uruchomieniu instancji i ponownym uruchomieniu aplikacji. Byłem sceptyczny, ale spróbowałem łatwego rozwiązania. Nie powinno dziwić, że proste ponowne uruchomienie instancji nie rozwiązało problemu. Błąd mówi mi, że mój plik kontrolny ma w sobie uszkodzenie. Ponowne uruchomienie instancji nie naprawi uszkodzenia pliku kontrolnego. Ponieważ Metalink i Internet są bezużyteczne, myślę, że to do mnie należy naprawienie tego. Jeśli wszystko inne zawiedzie, po prostu wyłączę stan gotowości i odtworzę go.
Moim pierwszym rozwiązaniem jest powrót do podstawowego i utworzenie zapasowego pliku kontrolnego. Następnie uruchom tryb gotowości za pomocą pliku kontrolnego trybu gotowości. Mam pewność, że nowy plik kontrolny z podstawowego pliku rozwiąże problem. Muszę jednak zastosować 2,5 miesiąca ponownego wykonania, którego już nie mam.
Próbowałem zbadać użycie RMAN do przewijania stanu gotowości za pomocą przyrostowej kopii zapasowej. Ale to wydaje się spadać na moją listę priorytetowych rzeczy do zrobienia. Mam nadchodzący projekt, w którym będę musiał wiedzieć, jak to zrobić, a do tego projektu pozostał niecały miesiąc. Wydaje się więc, że to idealny czas na przećwiczenie tej techniki w moim nadchodzącym projekcie i naprawienie mojego obecnego problemu. Aby to zrobić, wykonaj następujące czynności:
Metalink Note 836986.1 Steps to Perform for Rolling Forward a Standby Database Using RMAN Incremental Backups
Kroki opisane w tym dokumencie nie tylko przesunęły się do przodu w moim stanie gotowości, ale także odtworzyły pliki kontrolne, rozwiązując w ten sposób mój problem.
