Zrekonstruuj rezerwową bazę danych w stanie gotowości

Po niedawnej przerwie w dostawie prądu w naszej witrynie DR odkryłem, że stan wstrzymania przestał stosować dzienniki. Najwyraźniej w zarchiwizowanych dziennikach ponawiania była transakcja, która spowodowała powiększenie pliku danych, ale dysk w miejscu gotowości nie miał wystarczającej ilości miejsca na dysku, aby umożliwić zakończenie tej transakcji. Tak więc zarządzanie odzyskiwaniem zakończyło się w trybie gotowości, tak jak powinno.

Zwykle przechowujemy zarchiwizowane logi przeróbek przez 7 dni. Niestety, zanim odkryłem tę sytuację, minęło 15 dni i zarchiwizowanych dzienników przeróbek „brakowało”. Bez zarchiwizowanych logów przeróbek do zastosowania, jedynym rozwiązaniem było odbudowanie bazy danych od zera. Ta baza danych ma rozmiar około 7 TB, więc odbudowa od zera nie jest trywialną sprawą.

Podstawowa to 3-węzłowa baza danych RAC 11.2.0.2 działająca w systemie Linux. Rezerwa to dwuwęzłowa baza danych RAC, oczywiście te same wersje Oracle i OS.

Oto, jak udało nam się odbudować tryb gotowości:

1. Ustawiliśmy główny w trybie gorącej kopii zapasowej i wykonaliśmy migawkę bazy danych na dysku.
2. Zrzut został skopiowany na nośnik zewnętrzny. Uwaga:wysyłka przez sieć WAN była zbyt czasochłonna.
3. Zewnętrzne media zostały ręcznie przeniesione na stronę DR.
4. LOG_ARCHIVE_DEST_STATE_n dla trybu gotowości został ustawiony na DEFER.
5. Rezerwowa baza danych została usunięta z konfiguracji DG Broker:   REMOVE DATABASE Standby ZACHOWAJ MIEJSCA DOCELOWE;
6. Punkty montowania rezerwowej bazy danych zostały usunięte. W końcu baza danych była w tym momencie zasadniczo bezużyteczna.
7. Utworzono nowe punkty montowania, a migawka została zapisana na dysku w witrynie DR.
8. Po zakończeniu przesyłania plików (około 5 dni) poleciliśmy naszemu magazynowi zaktualizować migawkę w witrynie DR o bardziej aktualną migawkę. Zostało to wykonane przez sieć WAN, ponieważ wysłano tylko zmiany, która była znacznie, znacznie mniejsza niż baza danych.
9. Utworzono plik kontrolny stanu gotowości:   ZMIEŃ BAZĘ DANYCH UTWÓRZ PLIK KONTROLNY STANDBY JAKO „/katalog/ścieżka”;
10. Aby uprościć sprawę, chcieliśmy korzystać z trybu gotowości z jedną instancją, dopóki nie uruchomimy go. Stworzyliśmy więc plik PFILE z zapasowego modułu RAC SPFILE, a następnie użyliśmy edytora tekstu do zmodyfikowania pliku parametrów w celu usunięcia wszelkich parametrów uwzględniających RAC. Usunęliśmy CLUSTER_DATABASE, ustawiliśmy specyficzny dla instancji parametr UNDO_TABLESPACE, który będzie używany dla wszystkich instancji „*.”, usunęliśmy parametry THREAD itd. Nasza normalna rezerwowa baza danych ma dwie instancje, STANDBY1 i STANDBY2. W węźle 1 umieściliśmy plik p w $ORACLE_HOME/dbs/initstandby.ora zamiast initstandby1.ora, aby baza danych pojedynczej instancji mogła znaleźć swój plik parametrów. Zrobiliśmy coś podobnego dla pliku haseł.
11. Skopiowaliśmy plik kontrolny trybu gotowości z kroku 9 do plików kontrolnych w migawce bazy danych.
12. Po umieszczeniu plików pfile i pswd dla pojedynczej bazy danych, wykonaliśmy MONTAŻ STARTUP.
13. Stworzyliśmy wszelkie potrzebne nam dzienniki przeróbek w trybie gotowości. W naszym przypadku serwer podstawowy ma również dzienniki ponownego wykonywania w trybie gotowości, aby ułatwić operacje przełączania, a dzienniki ponownego wykonywania w trybie gotowości z serwera podstawowego nie były częścią migawki. Musieliśmy więc usunąć SRL, które nie odbyły podróży.
14. W podstawowym, ustaw LOG_ARCHIVE_DEST_STATE_n na ENABLE.
15. W podstawowych przypadkach wykonano ALTER SYSTEM SWITCH LOGFILE;
16. Zweryfikowano w dziennikach alertów serwera podstawowego i rezerwowego, czy rezerwowy odbierał logi, tj. zweryfikowano, czy transport dzienników działa.
17. Włączono zarządzany tryb gotowości:ALTER ODZYSKIWANIE BAZY DANYCH ODŁĄCZANIE ZARZĄDZANEJ BAZY DANYCH W TRYBIE GOTOWOŚCI OD SESJI;
18. Zweryfikowano w dzienniku alertów trybu gotowości, że dzienniki były stosowane, tj. zweryfikowane zastosowanie teraz działa.

W tym momencie mieliśmy już uruchomioną rezerwową bazę danych. Utworzyliśmy prostą tabelę w podstawowej i wstawiliśmy do niej jeden wiersz danych, ponownie wykonaliśmy przełączniki dziennika, a następnie otworzyliśmy tryb gotowości w trybie TYLKO DO ODCZYTU, aby sprawdzić, czy transakcja została odtworzona w trybie gotowości tak, jak powinna. Gdy uznamy, że zapasowa baza danych działa, musimy uczynić z niej bazę danych RAC. Cóż, wszystko jest już na miejscu, aby była to baza danych RAC, ponieważ kiedyś była. Aby zakończyć zadanie, po prostu zamknęliśmy rezerwową bazę danych pojedynczej instancji (SHUTDOWN ABORT) w SQL*Plus, a następnie użyliśmy srvctl do uruchomienia rezerwowej bazy danych jako bazy danych RAC:

srvctl start database -d standby -o mount

Jedyne, co pozostało w tym momencie, to dodanie trybu gotowości z powrotem do konfiguracji DG Broker (w DGMGRL):   Tryb gotowości ADD DATABASE

Kiedy to się po raz pierwszy wydarzyło, byłem zdenerwowany, jak to będzie wyglądać tak duża baza danych. Żadna z powyższych operacji nie jest zależna od rozmiaru, z wyjątkiem kopiowania plików na iz nośnika. Ale wszystko poszło dobrze.

Aby upewnić się, że nie spotkamy się z taką sytuacją w przyszłości, dodaliśmy alerty do naszej kontroli sieci Oracle Enterprise Manager. Otrzymam teraz alert OSTRZEŻENIE, gdy wysyłka dziennika lub zastosowanie dziennika nastąpi o 12 godzin, a alert KRYTYCZNY, gdy opóźnienie nastąpi o 24 godziny. Powinno to dać nam dużo czasu na naprawienie wszelkich problemów, zanim zarchiwizowane dzienniki przeróbek zostaną automatycznie usunięte po 7 dniach, lub przynajmniej na zmianę procesu, aby przechowywać więcej dni zarchiwizowanych dzienników przeróbek, dopóki nie naprawimy sytuacji.