Przewodnik dla początkujących dotyczący monitorowania postępu przywracania / odzyskiwania bazy danych Oracle

  • Ronald Ferguson
  • 0
  • 1079
  • 305

W środowisku produkcyjnym często wykonuje się kopię zapasową i przywraca ją za pomocą RMAN. Dlatego ważne jest, aby znać Wskazówki i techniki monitorowania operacji przywracania / odzyskiwania i określić, czy rzeczywiście działa, działa wolno lub zawiesił się.

Ogólnie rzecz biorąc, przywracanie powinno trwać mniej więcej tyle samo, co tworzenie kopii zapasowej, jeśli nie dłużej. Dlatego jeśli tworzenie kopii zapasowej zajęło 10 godzin, przywrócenie na tym samym hoście zajmie co najmniej 10 godzin.

Innym dobrym wskaźnikiem jest określenie czasu trwania poprzednich operacji przywracania / odtwarzania. Monitoruj dzienniki i widoki oraz obserwuj tempo zmian. Operacje przywracania i odzyskiwania wymagają dość dużej ilości zasobów, dlatego ważne jest, aby zrozumieć, czy proces działa, czy zawiesił się.

Dziennik RMAN

Domyślnie wynik operacji RMAN jest zapisywany na standardowe wyjście. Nie ma domyślnego pliku dziennika. Będziesz musiał przechwycić wynik za pomocą opcji SPOOL TRACE lub przekierować standardowe wyjście do pliku.

Przykład sesji przywracania pliku danych:

RMAN> buforowanie śledzenia do res5.out RMAN> przywracanie pliku danych 5; RMAN> spool trace off
$ cat res5.out RMAN> przywróć plik danych 5; Rozpoczynanie odtwarzania 27 grudnia 2011 14:05:03 [1] przy użyciu pliku kontrolnego docelowej bazy danych zamiast przydzielonego kanału katalogu odzyskiwania: ORA_DISK_1 kanał ORA_DISK_1: sid = 143 devtype = DISK [2] kanał ORA_DISK_1: uruchamianie pliku danych do odtwarzania kopii zapasowej kanał ORA_DISK_1: określanie plik (i) danych do przywrócenia z zestawu kopii zapasowych przywracanie pliku danych 00005 do /opt/app/oracle/oradata/ORA102/example01.dbf [3] kanał ORA_DISK_1: odczyt z kopii zapasowej / opt / app / oracle / fra / ORA102 / backupset / 2011_12_27 / ​​o1_mf_nnndf_TAG20111227T122122_7hl7dm2n_.bkp [4] kanał ORA_DISK_1: przywrócone kawałek backup 1 szt uchwyt = / opt / app / oracle / fra / ORA102 / backupset / 2011_12_27 / ​​o1_mf_nnndf_TAG20111227T122122_7hl7dm2n_.bkp tag = TAG20111227T122122 kanał ORA_DISK_1: przywrócić pełną, czas, który upłynął: 00: 00:15 [5] Zakończono przywracanie 27 grudnia 2011 14:05:19 [6]

Z powyższego widać:

  1. data i godzina rozpoczęcia przywracania
  2. identyfikator sesji bazy danych w v $ session - 143
  3. numer pliku danych i nazwę, do której plik zostanie przywrócony
  4. nazwa kopii zapasowej i TAG
  5. czas potrzebny na przywrócenie tego pliku danych i używany kanał
  6. data i godzina zakończenia przywracania

Przykład sesji przywracania:

RMAN> odzyskaj plik danych 5; Rozpoczynanie odzyskiwania 27 grudnia 2011 14:05:55 przy użyciu kanału ORA_DISK_1 uruchamianie kanału odzyskiwania nośników ORA_DISK_1: uruchamianie dziennika archiwum przywracanie do domyślnego miejsca docelowego [1] kanał ORA_DISK_1: przywracanie dziennika archiwum [2] wątek dziennika archiwum = 1 sekwencja = 77… kanał ORA_DISK_1 : przywracanie dziennika archiwum wątek dziennika archiwum = 1 sekwencja = 89 kanał ORA_DISK_1: odczyt z fragmentu kopii zapasowej /opt/app/oracle/fra/ORA102/backupset/2011_12_27/o1_mf_annnn_TAG20111227T135926_7hlf4jrk_.bkp kanał ORA_DISK_1: przywrócono fragment / uchwyt opt ​​1 app / oracle / fra / ORA102 / backupset / 2011_12_27 / ​​o1_mf_annnn_TAG20111227T135926_7hlf4jrk_.bkp tag = TAG20111227T135926 kanał ORA_DISK_1: przywracanie ukończone, czas, który upłynął: 00: 01: 35… nazwa_pliku dziennika / nazwa_pliku: opteting archiwum archiwum /oracle/fra/ORA102/archivelog/2011_12_27/o1_mf_1_88_7hlfmkr4_.arc recid = 116 stamp = 770998049 wartość domyślna kanału: usuwanie dzienników archiwum [3] nazwa pliku dziennika archiwum = / opt / app / oracle / fra / ORA102 / archivelog / 2011_12_27 /o1_mf_1_89_7hlfmbd8_.arc rec id = 104 znaczek = 770998043 ukończono odzyskiwanie nośnika, czas, który upłynął: 00:00:01 [4] Zakończono odzyskiwanie 27 grudnia 2011 r. 14:07:32 [5]
  1. Archivelogs są przywracane do domyślnego miejsca docelowego archiwum. Przed przywróceniem należy upewnić się, że jest dostępne miejsce na przywrócenie tych dzienników archiwalnych.
  2. dzienniki archiwalne są przywracane z kopii zapasowej, jeśli nie znajdują się jeszcze na dysku.
  3. po zakończeniu odzyskiwania RMAN automatycznie usunie je z dysku.
  4. czas potrzebny na odzyskanie tego pliku danych.
  5. data i godzina zakończenia odzyskiwania.

Alert.log

Operacja przywracania

Tylko operacje odtwarzania RMAN są zapisywane w pliku alert.log. Sesje przywracania zarządzane przez użytkowników nie pojawią się w alert.log, ponieważ są wykonywane poza Oracle.

Nie przejmuj się, jeśli zobaczysz błędy korupcji w pliku alert.log podczas operacji RMAN RESTORE. Przed przywróceniem pliku danych RMAN sprawdzi, czy istnieje i poprawność. Jeśli plik jest już na dysku, ale jest nieprawidłowy lub uszkodzony, zgłaszamy to. Na przykład w niedzielę, 27 września 2015 r., 08:25:54, odnotowano uszkodzenie pliku danych 1043:

Zrzut szesnastkowy (plik 1043, blok 1) w pliku śledzenia /backup/claprd01/diag/rdbms/claprd01/CLAPRD01/trace/CLAPRD01_ora_14287316.trc Uszkodzony blok względny dba: 0x05000001 (plik 1043, blok 1) Zły nagłówek znaleziony podczas kcvxfh v8 Dane w złym bloku: typ: 0 format: 2 rdba: 0x05000001 ostatnia zmiana scn: 0x0000.00000000 sekwencja: 0x1 flg: 0x05 zapasowe1: 0x0 zapasowe2: 0x0 zapasowe3: 0x0 spójność wartości końcowej: 0x00000001 wartość kontrolna w nagłówku bloku: 0x4a7 obliczona suma kontrolna bloku: 0x0 Odczyt pliku danych „+ SYSFILES / epicaccess50.dbf” pod kątem uszkodzenia w rdba: 0x05000001 (plik 1043, blok 1) Odczyt (plik 1043, blok 1) znalazł te same uszkodzone dane (brak kontroli logicznej) Niedziela 27 września 08:25 : 54 2015

Później widzimy, że plik jest przywracany z prawidłowej kopii zapasowej i żadne dalsze uszkodzenia nie są zgłaszane w tym pliku danych:

Sun Sep 27 08:39:08 2015 Pełne przywracanie pliku danych 1043 + SYSFILES / epicaccess50.dbf zakończone. Upłynął czas: 1:27:39 punkt kontrolny to 90364602816 ostatni scn zwolnienia to 45006515743

Operacja odzyskiwania

Wszystkie sesje odtwarzania, zarówno zarządzane przez użytkownika, jak i RMAN, zostaną również zapisane w pliku alert.log. Oto przykład sesji odzyskiwania RMAN:

Wt. 27 grudnia 14:05:55 EST 2011 zmiana bazy danych odzyskanie listy plików danych wyczyszczenie wt. 27 grudnia 14:05:55 czasu wschodniego 2011 Ukończono: zmiana odzyskiwania bazy danych lista plików danych wyczyszczenie wtorek 27 grudnia 14:05:55 czasu EST 2011 zmiana bazy danych odzyskanie w razie potrzeby plik danych 5 Media Recovery Rozpocznij odzyskiwanie równoległe uruchomione z 2 procesami ORA-279 zasygnalizowane podczas: zmień odzyskiwanie bazy danych w razie potrzeby plik danych 5… wt. Grudnia 27 14:05:56 EST 2011 Element wejściowy kopii zapasowej / opt / app / oracle / fra / ORA102 / backupset / 2011_12_27 /o1_mf_annnn_TAG20111227T135926_7hlf4jrk_.bkp jest w formacie skompresowanym.Tue Dec 27 14:07:23 EST 2011 [1] Przywracanie archiwum zakończone. Upłynęło: 0:00:01 [2] Przywracanie archiwum zakończone. Upłynęło: 0: 00: 01… Wto 27 grudnia 14:07:31 EST 2011 zmiana bazy danych odzyskać logfile '/opt/app/oracle/fra/ORA102/archivelog/2011_12_27/o1_mf_1_77_7hlfmdc7_.arc'... wtorek 27 grudnia 14:07 : 31 EST 2011 Dziennik odzyskiwania nośników /opt/app/oracle/fra/ORA102/archivelog/2011_12_27/o1_mf_1_77_7hlfmdc7_.arc ORA-279 zasygnalizowany podczas: zmiany bazy danych odzyskaj plik dziennika '/ opt / app / oracle / fra / ORA102 / archivelog / 2011_12_27 /o1_mf_1_77_7hlfmdc7_.arc '[3]… wt. 27 grudnia 14:07:31 EST 2011 Dziennik odzyskiwania nośników /opt/app/oracle/fra/ORA102/archivelog/2011_12_27/o1_mf_1_87_7hlfmk96_.arc Wto Dec 27 14:07:31 EST 2011 Odzyskiwanie dziennika ponawiania online: Wątek 1 Grupa 1 Sekwencja 88 Czytanie pamięci 0 Pamięć nr 0: /opt/app/oracle/oradata/ORA102/redo01.log [4] Wt 27 grudnia 14:07:31 EST 2011 Odzyskiwanie ponownego wykonania online Dziennik: Wątek 1 Grupa 2 Sekwencja 89 Czytanie pamięci 0 Mem # 0: /opt/app/oracle/oradata/ORA102/redo02.log Wt 27 grudnia 14:07:31 EST 2011 Odzyskiwanie nośników zakończone (ORA102) [5]
  1. w rzeczywistości był to skompresowany element zapasowy. Te informacje są wyświetlane tylko w pliku alert.log, a nie w dzienniku odtwarzania RMAN.
  2. czas potrzebny na przywrócenie dziennika archiwalnego.
  3. ORA-279 ma charakter informacyjny - potwierdza archiwum wymagane do przywrócenia.
  4. W celu pełnego przywrócenia Oracle będzie również musiało zastosować powtórzenie z dzienników online.
  5. koniec powrotu do zdrowia.

Dziennik odzyskiwania zarządzany przez użytkownika

To jest przykład odzyskiwania zarządzanego przez użytkownika. Odzyskiwanie danych wykonujemy za pomocą SQL * Plus:

$ sqlplus SQL * Plus: wersja 10.2.0.5.0 - produkcja w środę, 28 grudnia, 09:59:41 2011 Copyright (c) 1982, 2010, Oracle. Wszelkie prawa zastrzeżone. Wpisz nazwę użytkownika: / as sysdba. Połączono z: Oracle Database 10g Enterprise Edition wersja 10.2.0.5.0 - 64-bitowa produkcja Z opcjami partycjonowania, eksploracji danych i rzeczywistego testowania aplikacji SQL> zmiana pliku danych bazy danych 5 offline; [1] Zmieniona baza danych. SQL> odzyskaj plik danych 5; [2] ORA-00279: zmiana 2989857 wygenerowana 12/27/2011 12:50:00 potrzebna dla wątku 1 ORA-00289: sugestia: /opt/app/oracle/fra/ORA102/archivelog/2011_12_28/o1_mf_1_79_7hnmjl2y_.arc ORA -00280: zmiana 2989857 dla wątku 1 jest w sekwencji nr 79 [3] Określ dziennik: = sugerowane | nazwa pliku | AUTO | ANULUJ ORA-00279: zmiana 2989860 wygenerowana 27/12/2011 12:50:01 wymagana dla wątku 1 ORA-00289: sugestia: /opt/app/oracle/fra/ORA102/archivelog/2011_12_28/o1_mf_1_80_7hnmjmbc_.arc ORA- 00280: zmiana 2989860 dla wątku 1 jest w sekwencji nr 80 ORA-00278: plik dziennika „/opt/app/oracle/fra/ORA102/archivelog/2011_12_28/o1_mf_1_79_7hnmjl2y_.arc” nie jest już potrzebny do tego odzyskiwania [4] Określ dziennik: = sugerowane | nazwa pliku | AUTO | ANULUJ auto [5] ORA-00279: zmiana 2989874 wygenerowana 12/27/2011 12:50:39 wymagana dla wątku 1 ORA-00289: sugestia: / opt / app / oracle / fra / ORA102 / archivelog / 2011_12_28 / o1_mf_1_81_7hnmjmkf_ .arc ORA-00280: zmiana 2989874 dla wątku 1 jest w kolejności # 81 ORA-00278: plik dziennika „/opt/app/oracle/fra/ORA102/archivelog/2011_12_28/o1_mf_1_80_7hnmjmbc_.arc” nie jest już potrzebny do tego odzyskiwania… ORA -00279: zmiana 2991001 wygenerowana 12/27/2011 12:58:00 potrzebna dla wątku 1 ORA-00289: sugestia: /opt/app/oracle/fra/ORA102/archivelog/2011_12_28/o1_mf_1_87_7hnmjoc7_.arc ORA-00280: zmiana 2991001 dla wątku 1 to sekwencja # 87 ORA-00278: plik dziennika „/opt/app/oracle/fra/ORA102/archivelog/2011_12_28/o1_mf_1_86_7hnmjkm0_.arc” nie jest już potrzebny do tego odzyskania Dziennik został zastosowany. Odzyskiwanie nośnika zakończone. [6] SQL> SQL> zmień plik danych bazy danych 5 online; [7] Zmieniona baza danych.
  1. przełącz plik danych do trybu offline, przygotowując się do przywrócenia z kopii zapasowej zarządzanej przez użytkownika
  2. po przywróceniu pliku danych z kopii zapasowej zarządzanej przez użytkownika odzyskaj go
  3. pierwszy archiwalny dziennik wymagany do odzyskania tego pliku
  4. wcisnęliśmy klawisz ENTER, prosząc Oracle o zastosowanie żądanego dziennika
  5. jeśli istnieje wiele archiwów do zastosowania i wszystkie znajdują się w katalogu archiwum, użyj opcji AUTO dla Oracle, aby zastosować pozostałe wymagane dzienniki archiwalne. W przeciwnym razie konieczne będzie ręczne określenie każdego żądanego dziennika archiwalnego lub naciśnięcie klawisza ENTER po wyświetleniu monitu o każdy dziennik archiwalny
  6. odzyskiwanie jest teraz zakończone
  7. umieść plik danych w trybie online, udostępniając go w ten sposób ponownie do użytku

Narzędzia systemu operacyjnego

Przywracany plik powinien powiększać się aż do osiągnięcia rzeczywistego rozmiaru. Sygnatura czasowa również powinna się zmieniać, ponieważ plik jest aktualizowany przez Oracle. Aby wyświetlić te informacje, użyj narzędzia systemu operacyjnego, takiego jak „ls -lt”.

$ ls -ltr [przywracana jest pełna ścieżka i nazwa pliku]

Na przykład:

$ ls -ltr /database/db251/asbs/BLOB_DOC_IMAGES_B12.dbf

Do monitorowania wykorzystania zasobów można również użyć narzędzi systemu operacyjnego, takich jak vmstat, sar i iostat. Czy sprzęt działa na pełnych obrotach? Gdzie jest wąskie gardło? Czy na hoście są wykonywane inne operacje intensywnie korzystające z operacji we / wy? W razie potrzeby zainstaluj narzędzie Oracle OSWatcher, aby uzyskać więcej informacji.

Uwaga: W systemie Unix, jeśli zadanie jest uruchamiane interaktywnie z terminala bez NOHUP lub CRON, upewnij się, że samo zadanie systemu Unix nadal działa. Czasami terminal może zakończyć pracę z powodu przekroczenia limitów czasu bezczynności i pozostawić zadanie jako osierocone. Jeśli operacja przywracania zajmie dużo czasu, powinieneś rozważyć użycie NOHUP lub CRON, aby uniknąć tego problemu.

Jeśli pliki są przywracane do ASM, powinieneś również mieć możliwość sprawdzenia ich istnienia w ASM. Pamiętaj jednak, że możesz go zobaczyć w ASM dopiero po całkowitym przywróceniu.

Widoki słownika danych

Wszystkie operacje RMAN będą miały odpowiednią sesję bazy danych. Dlatego możesz zapytać słownik danych, aby sprawdzić jego postęp.

1. Sesje RMAN

SQL> - Sesje RMAN ustawiają rozmiar linii 100 trimspool na COLUMN sid FORMAT 9999 COLUMN numer seryjny ALIAS SER # FORMAT 99999 COLUMN spid FORMAT 9999 COLUMN nazwa użytkownika FORMAT a10 COLUMN status FORMAT a2 COLUMN program FORMAT a32 COLUMN czas_ logowania formularz a15 COLUMN formularz działania moduł a30 a35 COLUMN proces z a14 SELECT s.sid, s.serial # "ser #", s.username, to_char (s.logon_time, 'DD-MM-RR hh24: mi') logon_time, s.osuser, s.process, p.spid, s.machine, substr (s.status, 1,1) status, s.program FROM v $ sesja s, v $ proces p WHERE upper (s.program) jak '% RMAN%' AND s.paddr = p.addr (+) ZAMÓWIENIE przez s.logon_time, s.sid /

2. Procent pracy wykonanej

Uruchom następujące zapytania co najmniej 3 razy w odstępach 5-minutowych, aby zobaczyć postęp / zmianę.

SQL> ustaw echo po sprzężeniu zwrotnym z formatem ścieżki kolumny a50 wyłącz nagłówek select sl.sofar, sl.totalwork, round (sl.sofar / sl.totalwork * 100,2) "% Complete" from v $ session_longops sl, v $ session s, v $ proces p, gdzie p.addr = s.paddr i sl.sid = s.sid i sl.serial # = s.serial # i opname LIKE 'RMAN%' i opname NOT LIKE '% agregate%' i totalwork ! = 0 i sofar <> totalwork;

3. Sesja oczekuje

Czy są jakieś sesje i na co one czekają? Uruchom następujące zapytania co najmniej 3 razy w odstępach 5-minutowych, aby zobaczyć postęp / zmianę.

set linesize 200 trimspool on col event form a25 col p1text form a15 col p1 form 999999 col p2text form a15 col p2 form 999999 col p3text form a10 kol p3 form 9999 kol czekano forma 9999 kol czekam form 9999 wybierz sid, zdarzenie, p1text, p1, p2text, p2, p3text, p3, wait_time wait, seconds_in_wait oczekiwanie z gv $ session_wait, gdzie zdarzenie inne niż 'SQL * Net%' i zdarzenie inne niż '% timer%' i zdarzenie inne niż 'rdbms%' i zdarzenie inne niż 'pipe % 'i wydarzenie inne niż' DIAG% 'i wydarzenie inne niż' Strumienie AQ% 'i wydarzenie inne niż' VKTM% 'i stan =' OCZEKIWANIE 'uporządkowane według sekund_in_wait /

4. Postęp odzyskiwania

Jaki jest postęp w odzyskiwaniu? V $ RECOVERY_PROGRESS jest wypełniane tylko wtedy, gdy trwa ODZYSKIWANIE. Operacja przywracania nie wypełni tego widoku. Więc jeśli uważasz, że proces odzyskiwania jest powolny - czy naprawdę jest na etapie odzyskiwania, czy nadal jest przywracany z kopii zapasowych RMAN?

Oto przykład postępu w odzyskiwaniu:

22:27:38 SQL> wybierz START_TIME, TYPE, ITEM, UNITS, SOFAR, TOTAL z v $ recovery_progress; START_TIME TYPE ITEM UNITS SOFAR RAZEM --------------------------- --------------- - ------------------------------ -------------------- ---- ---------- ---------- 12-lis-14 16:08:10 Średni wskaźnik odzyskiwania nośnika KB / s 29713 0 12-lis-14 16 : 08: 10 Odzyskiwanie nośnika Ponów zastosowane megabajty 660747 0 12-lis-14 16:08:10 Odzyskiwanie nośnika Ostatnio używane Ponów SCN + czas 0 0 12-lis-14 11:28:16 Punkt kontrolny odzyskiwania nośnika Czas na dziennik sekund 6 6 12-lis-14 11:28:16 Tryb gotowości odzyskiwania nośnika Zastosuj opóźnienie sekund 0 0

Współczynnik odzyskania ponownego wykonania zależy od wielu czynników:

1. PARALLEL_EXECUTION_MESSAGE_SIZE
Domyślna wartość tego parametru może nie być wystarczająco duża, dlatego rozważ zwiększenie jej maksymalnej wartości zależnej od systemu operacyjnego:

SQL> pokaż parametr PARALLEL_EXECUTION_MESSAGE_SIZE SQL> zmień zestaw systemowy parallel_execution_message_size = 65535 scope = spfile;

Ta zmiana parametru wymaga ponownego uruchomienia / ponownego podłączenia bazy danych.

2. natywne stawki we / wy na poziomie sprzętu - skonsultuj się z administratorem systemu / dostawcą sprzętu.

3. równoległość odtwarzania - zależna od systemu operacyjnego - Oracle uruchomi wymaganą liczbę równoległych procesów do wykonania tego zadania. Jeśli czujesz potrzebę ręcznego określenia tego, to polecenia są następujące:

SQL> RECOVER plik danych x, y, z równolegle (stopień 32);

LUB

SQL> odzyskać równolegle 32;

4. jeśli po dostrojeniu powyższego, szybkość ponownego stosowania nadal nie jest akceptowalna, możesz tymczasowo ustawić db_block_checking na false, aby spróbować zwiększyć wydajność odzyskiwania.

Dzienniki zarządzania mediami

W przypadku odtwarzania z taśmy potwierdź, że rzeczywiście jest to odtwarzanie z taśmy, a nie czekanie na obsługę żądania przez menedżera nośników. Czy taśma jest zajęta lub bezczynna? Poproś zespół wsparcia ds. Zarządzania mediami o potwierdzenie szybkości odczytywania danych z taśmy.




Jeszcze bez komentarzy

Zbiór przydatnych informacji o systemie operacyjnym Linux i nowych technologiach
Świeże artykuły, praktyczne wskazówki, szczegółowe recenzje i poradniki. Poczuj się jak w domu w świecie systemu operacyjnego Linux