Odtwarzanie po awarii plików bazy danych

Transkrypt

1 Odtwarzanie po awarii plików bazy danych Odtwarzanie po awarii plików bazy danych (dysków) Odtwarzanie po awarii dysków oznacza, że któryś z plików bazy danych został uszkodzony. W zależności od tego, który plik uległ awarii inna jest procedura odtwarzania. W większości przypadków udaje się odtworzyć stan bazy dokładnie sprzed awarii, ale bywają i takie sytuacje, że nawet tryb Archivelog oraz istnienie backupu nie pozwala na pełne odtworzenie danych bez ich utraty. Oto kilka sytuacji i procedur odtwarzania po awarii. Utrata pliku zwykłej przestrzeni tabel (czyli nie SYSTEM i UNDO) W przypadku awarii pojedynczego pliku w przestrzeni tabel wystarczy uszkodzony plik przełączyć w tryb offline i rozpocząć odtwarzanie z backupu. 1. Przełączenie utraconego pliku (np. nr 5) w tryb OFFLINE a. sqlplus / as sysdba b. ALTER DATABASE DATAFILE 5 OFFLINE; 2. Przejście do RMAN-a i uruchomienie procedury odtwarzania utraconego pliku bądź przestrzeni tabel: a. rman target / b. RESTORE DATAFILE 5; c. RECOVER DATAFILE 5; 3. Przełączenie odtworzonego pliku nr 5 w tryb ONLINE a. sqlplus / as sysdba b. ALTER DATABASE DATAFILE 5 ONLINE; W przypadku utraty wszystkich plików przestrzeni tabel należy odtworzyć całą przestrzeń 1. Przełączenie przestrzeni tabel np. USERS w tryb OFFLINE a. sqlplus / as sysdba b. ALTER TABLESPACE USERS OFFLINE TEMPORARY; 2. Przejście do RMAN-a i uruchomienie procedury odtwarzania przestrzeni tabel a. rman target / b. RESTORE TABLESPACE USERS; c. RECOVER TABLESPACE USERS; 3. Przełączenie przestrzeni tabel USERS w tryb ONLINE a. sqlplus / as sysdba b. ALTER TABLESPACE USERS ONLINE; Strona: 1 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 11

2 Procedura jest bardzo prosta, a co najważniejsze baza danych cały czas pracuje normalnie z wyjątkiem utraconego pliku bądź jednej tylko przestrzeni tabel. Również odtwarzanie jest szybkie i nie ingeruje w pracę pozostałych przestrzeni tabel. Utrata przestrzeni tabel SYSTEM W przypadku utraty plików przestrzeni tabel SYSTEM baza przestanie poprawnie funkcjonować ponieważ instancja cały czas potrzebuje dostawać się do obiektów w tej przestrzeni. W momencie utraty pliku w przestrzeni tabel SYSTEM instancja prawdopodobnie przestanie wykonywać normalne polecenia należy wtedy przeprowadzić następującą procedurę: 1. Zamknąć bazę w jedyny możliwy sposób a. SHUTDOWN ABORT; 2. Otworzyć w trybie MOUNT a. STARTUP MOUNT; 3. Wejść do RMAN-a i odtworzyć przestrzeń tabel SYSTEM a. RESTORE TABLESPACE SYSTEM; b. RECOVER TABLESPACE SYSTEM; 4. Otworzyć bazę danych a. ALTER DATABASE OPEN; Różnica między odtwarzaniem zwykłej przestrzeni tabel, a przestrzeni SYSTEM jest taka, że w tym drugim przypadku baza musi zostać zamknięta. Na czas odtwarzanie użytkownicy nie mogą korzystać z danych. Utrata jednego pliku kontrolnego W przypadku utraty pojedynczego pliku kontrolnego baza (w momencie kiedy się zorientuje, że pliku brakuje) zatrzymuje instancje natychmiastowo. Jeśli baza pracuje z użyciem kilku kopii pliku kontrolnego taka awaria jest bardzo prosta do naprawienia. Wystarczy skopiować istniejący plik kontrolny w miejsce utraconego. 1. Po utracie jednego z plików kontrolnych możemy spodziewać się następujących komunikatów w alert logu: /u01/app/oracle/diag/rdbms/orcl/orcl/trace/alert_orcl.log a. ORA-00227: corrupt block detected in control file: (block 1, # blocks 1) b. ORA-00202: control file: '/u01/app/oracle/oradata/orcl/control01.ctl' 2. Instancja może jeszcze przez chwilę pracować, ale w momecie kiedy będzie chciała zapisać jakieś zmiany do wszystkich plików kontrolnych zostanie samoczynnie zatrzymana np: a. ORA-00202: control file: '/u01/app/oracle/oradata/orcl/control01.ctl' b. LGWR (ospid: 14614): terminating the instance due to error 227 c. Instance terminated by LGWR, pid = Strona: 2 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 11

3 3. Administrator po stwierdzeniu awarii jednego z kilku plików kontrolnych musi zamknąć bazę jeśli się jeszcze sama nie zamknęła a. SHUTDOWN ABORT; 4. Skopiować istniejący plik kontrolny w miejsce brakującego a. cp control03.ctl control01.ctl 5. Uruchomić normalnie bazę danych a. STARTUP; Tak więc utrata jednego pliku kontrolnego w przypadku posiadania kilku kopii nie stanowi dla administratora problemu z wyjątkiem krótkiej przerwy w działaniu instancji bazy danych. Utrata wszystkich plików kontrolnych Utrata wszystkich plików kontrolnych jest już większym problemem ponieważ trzeba przywrócić plik kontrolny z autobackup-u jeśli takowy istnieje. 1. Zamknąć baze jeśli jeszcze pracuje a. SHUTDOWN ABORT; 2. Otworzyć RMAN-a a. rman target / 3. Uruchomić bazę w trybie NOMOUNT a. STARTUP NOMOUNT; 4. Przywrócić pliki kontrolne z autobackupu a. RESTORE CONTROLFILE FROM AUTOBACKUP; 5. Przełączyć bazę w tryb MOUNT a. ALTER DATABASE MOUNT; 6. Rozpocząć odtwarzanie bazy danych a. RECOVER DATABASE; 7. Otworzyć bazę z klauzulą RESETLOGS a. ALTER DATABASE OPEN RESETLOGS; Opcja RESETLOGS jest używana do wyzerowania plików redo logów i najczęściej stosuje się ją w przypadku niepełnego odtwarzania bazy danych. W tym przypadku odtwarzanie jest pełne, ale otwarcie bazy po utracie wszystkich plików kontrolnych wymaga tej klauzuli do stworzenia tzw. nowej inkarnacji instancji bazy danych. Utrata pojedynczego pliku redo logów w grupie z co najmniej 2 plikami redo Do poprawnej pracy bazy danych wymagane jest posiadanie co najmniej dwóch (2) grup redo logów. W każdej grupie musi istnieć co najmniej jeden plik logów choć Oracle zaleca, aby występowały dwa rozlokowane na różnych dyskach i różnych kontrolerach dyskowych. Utrata jednego pliku z grupy, która posiada dwa lub więcej w tej samej grupie nie jest krytyczne i nie wymaga zatrzymywania bazy. Strona: 3 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 11

4 1. Jeśli baza utraci jeden z kilku plików w tej samej grupie redo to w alert logu otrzymamy komunikat np: a. ORA-00321: log 1 of thread 1, cannot update log file header b. ORA-00312: online log 1 thread 1: '/u01/app/oracle/oradata/orcl/redo01.log' 2. Należy sprawdzić czy utracony plik należy do grupy CURRENT, a więc aktywnej grupy redo do której pisze baza danych, a jeśli nie to czy został zarchiwizowany: a. SELECT GROUP#, STATUS, ARCHIVED FROM V$LOG; GROUP# STATUS ARC ACTIVE YES 2 CURRENT NO 3 ACTIVE YES 3. Grupa pierwsza (1) ma status ACTIVE co oznacza, że posiada jeszcze informacje wymagane do odtwarzania bazy danych w przypadku awarii instancji. Pliki z tej grupy zostały jednak już zarchiwizowane. Należy zaczekać, aż status zmieni się na INACTIVE. Można to przyspieszyć wykonując CHECKPOINT: a. ALTER SYSTEM CHECKPOINT; 4. Następnie jeśli już grupa pierwsza (1) jest w stanie INACTIVE to można wydać polecenie na odtworzenie (utworzenie od nowa) plików redo grupy pierwszej (1) a. ALTER DATABASE CLEAR LOGFILE GROUP 1; Jeśli zaś utracony plik redo należy do grupy CURRENT to należy wymusić przełączenie logów do kolejnej grupy poleceniem ALTER SYSTEM SWITCH LOGFILE; Następnie kontynuować procedurę od punktu 3 powyżej. Po tych operacjach, utracony pojedynczy pliki redo z grupy pierwszej (1) został stworzony na nowo, a baza dalej może działać bez utraty danych i przerw. Utrata całej grupy redo logów (wszystkich plików z tej samej grupy) Jest to najtrudniejsza do rozwiązania sytuacja ponieważ możliwe scenariusze mogą również przewidywać utratę danych i brak możliwości pełnego odtworzenia bazy danych (incomplete recovery). Należy tutaj rozpatrzeć 4 scenariusze: 1. Utracona grupa redo nie jest CURRENT i została zarchiwizowana 2. Utracona grupa redo nie jest CURRENT i nie została zarchiwizowana 3. Utracona grupa jest CURRENT, ale baza została wcześniej czysto zamknięta Strona: 4 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 11

5 4. Utracona grupa jest CURRENT, ale baza pracuje lub nie została czysto zamknięta. Oto procedury odtwarzania w każdym z 4 scenariuszy: 1. W przypadku gdy utracona grupa nie jest CURRENT i została zarchiwizowana to nie ma dużego problemu. Wystarczy bazę zamknąć i uruchomić w trybie MOUNT, a następnie wyzerować utraconą grupę: a. SHUTDOWN IMMEDIATE; b. STARTUP MOUNT; c. ALTER DATABASE CLEAR LOGFILE GROUP 1; d. ALTER DATABASE OPEN; 2. W przypadku jeśli utracona grupa redo nie jest CURRENT, ale nie została zarchiwizowana. W tym przypadku baza będzie pracować normalnie, ale w alert logu otrzymamy informację że proces archiwizacyjny nie może wykonać archiwizacji. Należy taką grupę wyzerować i wykonać ponownie pełny backup bazy: a. ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 1; b. rman targer / c. BACKUP DATABASE; 3. W przypadku gdy awarii uległy pliki grupy redo po czystym zamknięciu bazy też nie ma wielkiego problemu. Wystarczy otworzyć bazę w trybie MOUNT, utworzyć ponownie brakującą grupę redo logów i wykonać pełny backup bazy poleceniami: a. STARTUP MOUNT; b. ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 1; c. ALTER DATABASE OPEN; d. rman target / e. BACKUP DATABASE; 4. W przypadku utraty grupy redo CURRENT w ciągle otwartej bazie, instancja przestanie normalnie pracować. Jest to najtrudniejszy przypadek do odtworzenia i tylko do niepełnego odtworzenia jako, że pewne dane w utraconych redo logach bezpowrotnie giną. Należy w tym przypadku przywrócić całą bazę z backupu i dokonać niekompletnego odtworzenia (incomplete recovery) RMAN rman target / STARTUP NOMOUNT; SQLPLUS RESTORE CONTROLFILE FROM AUTOBACKUP; ALTER DATABASE MOUNT; Strona: 5 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 11

6 RESTORE DATABASE; SELECT MAX(SEQUENCE#) SEQ# FROM V$ARCHIVED_LOG WHERE RESETLOGS_ID = (SELECT MAX(RESETLOGS_ID) FROM V$ARCHIVED_LOG); Znaleziony numer sekwencji SEQ# podstawić do kolejnego polecenia RMAN powiększony o 1 RECOVER DATABASE UNTIL SEQUENCE SEQ#+1; ALTER DATABASE OPEN RESETLOGS; Powyższa procedura odtwarza stan bazy do ostatniego dostępnego archived loga ponieważ aktualne redo logi zostały utracone. Utrata przestrzeni tabel UNDO Procedura odtworzenia poprawnego stanu bazy po utracie plików z przestrzeni tabel UNDO nie należy do prostych i jest zmienna w zależności od wielu czynników. Awarii może ulec nie cały plik, a tylko jego część w związku z tym tracimy dostęp tylko do kilku rollback segmentów aktualnie używanych przez bazę. Najczęściej nie łączy się to z utratą zatwierdzonych danych, lecz z utratą danych w niezatwierdzonych transakcjach. Ze względów na dość skomplikowaną procedurę i wiele czynników wpływających na jej przebieg nie da się jej jednoznacznie w tym skrypcie opisać. Zainteresowane osoby odsyłam do dokumentacji Oracle, notatek wsparcia technicznego i publikacji w internecie: Notatka wsparcia technicznego Oracle nr (dostępna dla posiadaczy licencji bazy danych oraz wsparcia tech.) 4. Blog: and-ora-30025/ Przygotowanie do ćwiczeń Do ćwiczeń będzie potrzebny plik o nazwie corrupt który należy ściągnąć ze strony moodle.porozum.pl Można go znaleźć w materiałach dodatkowych. Po zapisaniu na dysk lokalny należy przenieść go do maszyny wirtualnej zgodnie z instrukcją zawartą w dokumencie o nazwie: Instrukcja VBox i SQLPLUS. Skrypt corrupt służy do uszkadzania i usuwania plików i będzie wykorzystywany do psucia bazy danych w celu późniejszego jej odtworzenia. Strona: 6 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 11

7 Skrypt corrupt należy skopiować do katalogu $ORACLE_HOME/bin, aby był dostępny na ścieżce $PATH cp /mnt/corrupt $ORACLE_HOME/bin Oto przykładowe wywołanie skryptu: cd /u01/app/oracle/oradata/orcl corrupt system01.dbf corrupt control01.ctl Powyższe instrukcje najpierw psują plik system01.dbf czyli przestrzeń tabel SYSTEM, a następnie plik kontrolny control01.ctl. Proszę nie wykonywać powyższych instrukcji przed wykonaniem pełnego backupu bazy danych. Strona: 7 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 11

8 Ćwiczenia Kopie bezpieczeństwa i odtwarzanie w bazie Oracle 11g Ćwiczenie nr 1 Odtwarzanie po awarii zwykłych przestrzeni tabel 1. Popsuć plik danych przestrzeni tabel USERS dostarczonym skryptem o nazwie corrupt 2. Sprawdzić w alert logu czy baza zanotowała utratę jednego z plików 3. Za pomocą RMAN-a odtworzyć utracony plik i ponownie przywrócić przestrzeń tabel do normalnego użytkowania czyli do stanu ONLINE Ćwiczenie nr 2 Odtwarzanie po awarii przestrzeni tabel SYSTEM 1. Popsuć plik przestrzeni tabel SYSTEM 2. Sprawdzić w alert logu czy baza zanotowała utratę jednego z plików 3. Spróbować zamknąć bazę danych 4. Za pomocą RMAN-a odtworzyć utracony plik i ponownie przywrócić przestrzeń tabel SYSTEM. Otworzyć bazę danych. Ćwiczenie nr 3 Odtwarzanie po awarii jednego pliku kontrolnego 1. Popsuć jeden plik kontrolny 2. Spróbować wykonać CHECKPOINT 3. Spróbować zamknąć bazę danych 4. Odtworzyć utracony plik kontrolny z pozostałych istniejących 5. Otworzyć bazę danych Ćwiczenie nr 4 Odtwarzanie po awarii wszystkich plików kontrolnych 1. Popsuć wszystkie pliki kontrolne 2. Spróbować zamknąć bazę danych 3. Odtworzyć pliki kontrolne z backupu 4. Otworzyć bazę danych Ćwiczenie nr 5 Odtwarzanie po awarii jednego członka grupy redo logów 1. Popsuć jeden plik należący do aktualnie używanej (CURRENT) grupy redo logów jeśli grupa zawiera co najmniej dwóch członków. Jeśli nie zawiera dwóch członków to dodać drugiego członka grupy redo ( to zadanie powinno być wykonane w ćwiczeniu 1 podpunkt 3). 2. Nie zamykając bazy danych odtworzyć utraconego członka grupy redo. Przywrócić normalną prace bazy Ćwiczenie nr 6 Odtwarzanie po awarii całej aktualnie używanej (CURRENT) grupy redo logów 1. Popsuć wszystkie pliki wchodzące w skład aktualnie używanej grupy redo logów 2. Zamknąć bazę danych 3. Odtworzyć bazę po awarii grupy redo. 4. Otworzyć bazę danych. Strona: 8 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 11

9 Ćwiczenie dodatkowe Odtwarzanie po awarii przestrzeni tabel UNDO 1. W trakcie działania bazy danych popsuć plik przestrzeni tabel UNDO 2. Spróbować odtworzyć bazę danych i ją otworzyć korzystając z odnośnika nr 4 zawartego w rozdziale dotyczącym odtwarzania przestrzeni UNDO. 3. W razie problemów z odtworzeniem, przywrócić pliki kopii zapasowej wykonanej wcześniej Strona: 9 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 11

10 Odpowiedzi Kopie bezpieczeństwa i odtwarzanie w bazie Oracle 11g Ćwiczenie nr 1 1. Popsuć plik danych przestrzeni tabel USERS dostarczonym skryptem o nazwie corrupt a. cd /u01/app/oracle/oradata/orcl b. corrupt users01.dbf 2. Baza może od razu nie odnotować utraty pliku. Czasami trzeba wykonać kilka operacji, żeby zmusić baze do odczytu danych z właśnie usuniętego pliku np. zrzucić do plików bufor buffer_cache i spróbować odczytać coś z tabeli w utraconym pliku: a. ALTER SYSTEM FLUSH BUFFER_CACHE; b. SELECT * FROM U1.T1; 3. Za pomocą RMAN-a odtworzyć utracony plik i ponownie przywrócić przestrzeń tabel do normalnego użytkowania czyli do statnu ONLINE a. SQL> ALTER DATABASE DATAFILE 4 OFFLINE; b. RMAN> RESTORE DATAFILE 4; c. RMAN> RECOVER DATAFILE 4; d. SQL> ALTER DATABASE DATAFILE 4 ONLINE; Ćwiczenie nr 6 1. Popsuć plik przestrzeni tabel SYSTEM e. cd /u01/app/oracle/oradata/orcl a. corrupt system01.dbf 2. Sprawdzić w alert logu czy baza zanotowała utratę jednego z plików f. ALTER SYSTEM FLUSH BUFFER_CACHE; a. SELECT * FROM OUTLN.OL$; 3. Spróbować zamknąć bazę danych a. SHUTDOWN IMMEDIATE; b. SHUTDOWN ABORT; 4. Za pomocą RMAN-a odtworzyć utracony plik i ponownie przywrócić przestrzeń tabel SYSTEM. Otworzyć baze danych. a. RMAN> STARTUP MOUNT; b. RMAN> RESTORE TABLESPACE SYSTEM; c. RMAN> RECOVER TABLESPACE SYSTEM; d. RMAN> ALTER DATABASE OPEN; Ćwiczenie nr 7 1. Popsuć jeden plik kontrolny a. cd /u01/app/oracle/oradata/orcl b. corrupt control01.ctl 2. Spróbowac wykonać CHECKPOINT a. ALTER SYSTEM CHECKPOINT; Strona: 10 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 11

11 3. Spróbować zamknąć bazę danych a. Jeśli baza sama nie zakończyła swojego działania po błędzie związanym z operacją CHECKPOINT należy ją zamknąć natychmiastowo b. SHUTDOWN ABORT; 4. Odtworzyć utracony plik kontrolny z pozostałych istniejących a. cp control03.ctl control01.ctl 5. Otworzyć bazę danych a. STARTUP; Ćwiczenie nr 8 1. Popsuć wszystkie pliki kontrolne a. cd /u01/app/oracle/oradata/orcl b. corrupt control01.ctl c. corrupt control03.ctl d. cd /u01/app/oracle/flash_recovery_area/orcl e. corrupt control02.ctl 2. Spróbować zamknąć bazę danych a. Shutdown immediate; b. shutdown abort; 3. Odtworzyć pliki kontrolne z backupu a. RMAN> STARTUP NOMOUNT; b. RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP; c. RMAN> ALTER DATABASE MOUNT; d. RMAN> RECOVER DATABASE; 4. Otworzyć bazę danych a. RMAN> ALTER DATABASE OPEN RESETLOGS; Ćwiczenie nr 9 1. Popsuć jeden plik należący do aktualnie używanej (CURRENT) grupy redo logów jeśli grupa zawiera co najmniej dwóch członków. Jeśli nie zawiera dwóch członków to dodać drugiego członka grupy redo (zadanie powinno być wykonane w ćwiczeniu 1 podpunkt 3). a. SET LINE 2000 b. SELECT LOG.GROUP#, F.MEMBER, LOG.STATUS FROM V$LOG LOG, V$LOGFILE F WHERE LOG.GROUP#=F.GROUP# AND LOG.STATUS='CURRENT'; c. cd /u01/app/oracle/oradata/orcl d. corrupt redo01.log 2. Nie zamykając bazy danych odtworzyć utraconego członka grupy redo. Przywrócić normalną prace bazy a. Baza może się od razu nie zorientować że utraciła jednego członka w grupie redo. Wykonanie przełączenia do drugiej grupy na pewno spowoduje wygenerowanie błędu w alert logu. W podpunkcie f zakładam, że uszkodzoną grupą redo jest grupa 1. Na ćwiczeniu może się okazać, że jest to inna grupa np. 2 lub 3. b. ALTER SYSTEM SWITCH LOGFILE; c. SELECT GROUP#, STATUS, ARCHIVED FROM V$LOG; Strona: 11 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 11

12 d. ALTER SYSTEM CHECKPOINT; e. SELECT GROUP#, STATUS, ARCHIVED FROM V$LOG; f. ALTER DATABASE CLEAR LOGFILE GROUP 1; Ćwiczenie nr Popsuć wszystkie pliki wchodzące w skład aktualnie używanej grupy redo logów a. SELECT GROUP#, STATUS, ARCHIVED FROM V$LOG WHERE STATUS='CURRENT'; b. cd /u01/app/oracle/oradata/orcl c. corrupt redo01.log d. corrupt redo01-1.log 2. Zamknąć bazę danych a. SHUTDOWN ABORT; 3. Odtworzyć bazę po awarii grupy redo. a. RMAN> STARTUP NOMOUNT; b. RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP; c. RMAN> ALTER DATABASE MOUNT; d. RMAN> RESTORE DATABASE; e. SQL> SELECT MAX(SEQUENCE#) SEQ# FROM V$ARCHIVED_LOG WHERE RESETLOGS_ID = (SELECT MAX(RESETLOGS_ID) FROM V$ARCHIVED_LOG); f. RMAN> RECOVER DATABASE UNTIL SEQUENCE SEQ#+1; g. RMAN> ALTER DATABASE OPEN RESETLOGS; Strona: 12 Administracja bazą Oracle 11g Studia Podyplomowe SGGW Laboratorium nr 11