Strojenie,administracja itp. Cz. 2 Adam Pelikant

Środowisko pracy bazy danych Podczas instalacji bazy można określić środowisko pracy: Online Transaction Processing (OLTP) To baza danych utworzona z przeznaczeniem do przetwarzania bardzo dużej ilości transakcji przez dużą ilość użytkowników pracujących równolegle. Następuje intensywny odczyt, zapis i kasowanie danych w bazie. Użytkownicy muszą mieć szybki dostęp do danych. Cechy: wysoka przepustowość i dostępność bazy danych. Decision Support System (DSS) Baza danych w środowisku DSS musi przetwarzać wiele zapytań, od prostych do bardzo złożonych, sortujących rekordy z wielu obiektów. Taka baza danych jest raczej statyczna, a zapytania najczęściej wydawane są w intencji nie modyfikacji ale uzyskania informacji. Cechy: szybki czas odpowiedzi. Hybrid Jest to połączenie środowiska OLTP oraz DSS.

Kategorie awarii - awaria nośnika - awaria instancji - awaria procesu użytkownika - błąd użytkownika - błąd polecenia

Kategorie awarii Awaria instancji (instance failure) jest najczęściej wynikiem powstania wewnętrznego wyjątku Oracle, błędu w systemie operacyjnym lub awarii bazy danych związanej z oprogramowaniem. Diagnozę o awarii systemu można postawić wtedy, gdy przestaje działać proces Oracle (PMON, SMON, DBWR, LGWR), a baza danych nie została normalnie zamknięta. Awarie instancji mogą prowadzić do uszkodzenia bazy danych, ale z natury nie powoduję one zniszczeń. Często zwykłe ponowne uruchomienie bazy danych pozwala na dalsze wykonywanie działań. Awaria nośnika (media failure) jest bardziej groźna. Objawia się zwykle przez niezdolność bazy danych do odczytania poprzednio zapisanych informacji. Główne przyczyny awarii nośników to: uszkodzenie napędu dysków, niepoprawne bloki na dysku, skasowanie plików danych, uszkodzenie systemu plików. Awaria nośnika prawie zawsze powoduje w bazie danych uszkodzenie, które musi być naprawione, zanim baza będzie mogła powrócić do normalnego działania. System Oracle8 udostępnia wiele metod odzyskiwania utraconych danych.

Kategorie awarii Awaria procesu użytkownika – ten typ awarii zwykle nie wymaga żadnych działań ze strony administratora bazy danych, gdyż objawia się niezamierzonym przerwaniem połączenia użytkownika z bazą danych. Awaria procesu użytkownika obsługiwana jest przez proces drugoplanowy PMON. Błąd użytkownika (user error) – awarie wywołane błędami użytkownika zwykle wymagają działań DBA mających na celu odtworzenie danych. Przyczyny: przypadkowe usunięcie tabeli, usunięcie istotnych danych, itp. Błąd polecenia (statement error) występuje, kiedy zaistnieje błąd logiczny w rozkazie programu. Błąd użytkownika sygnalizowany jest przez serwer Oracle odpowiednim komunikatem o błędzie. Polecenie SQL, które spowodowało błąd, jest automatycznie wycofywane, a sterowanie jest przekazywane do aplikacji użytkownika.

Metody tworzenia kopii bezpieczeństwa i odtwarzania danych Kopie bezpieczeństwa tworzone na zimno (cold backup, offline backup) oraz odtwarzanie Tworzenie kopii bezpieczeństwa na gorąco (hot backup, online backup) oraz odtwarzanie Tworzenie kopii bezpieczeństwa i odtwarzanie za pomocą programu Recovery Manager Tworzenie logicznej kopii bezpieczeństwa (logical backup) oraz odtwarzanie Przyrostowe tworzenie kopii bezpieczeństwa Zapasowe bazy danych (standby database)

Metody tworzenia kopii Kopie bezpieczeństwa tworzone na zimno (cold backup, offline backup) oraz odtwarzanie wykonane są przy zamkniętej instancji bazy danych Oracle, następnie kopiowane są wszystkie istotne pliki bazy (pliki danych, pliki sterujące, dzienniki powtórzeń, archiwa dzienników powtórzeń, pliki init.ora i config.ora). Tworzenie kopii bezpieczeństwa na gorąco (hot backup, online backup) oraz odtwarzanie wykonanie kopii bezpieczeństwa podczas ciągłej pracy bazy. Jest niezbędnym elementem działań 24-godzinnych przez 7 dni w tygodniu. Polega na skopiowaniu gorącej kopii pliku sterującego, plików danych, archiwizowanych plików dziennika powtórzeń, plików init.ora i config.ora (jeżeli istnieją).

Metody tworzenia kopii Tworzenie kopii bezpieczeństwa i odtwarzanie za pomocą programu Oracle Recovery Manager wygodne narzędzie, posiadające własny język skryptów, służące do uproszczenia odtwarzania bazy danych w trzech przypadkach: odtwarzanie po utracie lub zniszczeniu plików danych, zastępowanie utraconych lub zniszczonych plików sterujących, dokonywanie kompletnego odtwarzania kopii bezpieczeństwa bazy danych. Tworzenie logicznej kopii bezpieczeństwa (logical backup) oraz odtwarzanie polega na kopiowaniu danych do pliku za pomocą narzędzia Export; można je wykonać przy działającej bazie danych. Takie wykonanie kopii bezpieczeństwa służy głównie do dokonywania napraw po utracie danych z powodu usunięcia tabel, skasowania wierszy, itp.

Metody tworzenia kopii Przyrostowe tworzenie kopii bezpieczeństwa polega na eksportowaniu tylko tych tabel, które zmieniły się od ostatniego pełnego lub przyrostowego eksportu. W przypadku Recovery Managera backup logiczny polega na zabezpieczeniu zmienionych bloków bazodanowych od ostatniego pełnego zabezpieczenia. Oracle9i Data Guard - konfiguracja środowiska zapasowych serwerów bazy danych jest to kopia bazy głównej, która działa w trybie odtwarzania wykorzystując archiwa rejestrów bazy głównej.

Sugerowane przestrzenie tabel SYSTEM: archiwizacja i odtwarzanie są bardziej złożone, jeżeli dane systemowe i użytkowników przechowywane są w jednej przestrzeni tabel; TEMP: ta przestrzeń, zarezerwowana na obiekty tymczasowe, może być powtórnie stworzona jeśli ulegnie zniszczeniu, nie musi być odtwarzana; RBS: (przeznaczona dla segmentów wycofania) archiwizacja i odtwarzanie przestrzeni zawierającej aktywne segmenty wycofania jest trudna przy działającej bazie danych; READONLY: (przestrzeń tylko do odczytu, np. archiwum) czas archiwizacji tej przestrzeni może być zredukowany; wystarczy wykonać jej kopię w czasie przełączania w tryb read-only; USERS: (przestrzeń zarezerwowana dla danych użytkowników) w celu redukcji czasu odtwarzania, przestrzeń ta powinna być archiwizowana znacznie częściej. INDX: (przestrzeń tabel przeznaczona dla indeksów) powinna być stworzona osobna przestrzeń tabel zawierająca segmenty indeksów. Takie przestrzenie często można powtórnie stworzyć zamiast odtwarzać (usunąć i założyć).

Metody wykonywania kopii bezpieczeństwa z poziomu SO backup przy zamkniętej bazie danych: –bez archiwizacji dziennika powtórzeń (consistent), do odtwarzania bazy danych do punktu sporządzenia ostatniej kopii bezpieczeństwa –z archiwizacją dziennika powtórzeń (backup zimny); do odtwarzania bazy danych do punktu wystąpienia ostatniej awarii backup przy otwartej bazie danych (backup gorący) gdy wyłączenie bazy jest niemożliwe

Odtwarzanie przestrzeni tabel – tryb READ ONLY Tablespace Status: READ/WRITE Tablespace Status: READ ONLY AWARIA BACKUPRECOVERY Tablespace Status: READ ONLY Baza danych : SPÓJNANIE SPÓJNASPÓJNA

BACKUP zamkniętej bazy danych Pliki bazy danych niezbędne do skopiowania: –pliki danych –pliki kontrolne –pliki parametrów –pliki dziennika powtórzeń –archiwa plików dziennika powtórzeń (jeżeli istnieją) –plik haseł –pliki konfiguracyjne Net8 Nie jest konieczne włączanie do backupu plików dziennika powtórzeń, jednak gdy to zrobimy upraszcza się proces odtwarzania.

BACKUP zamkniętej bazy danych Zalety –Szybkość i prostota koncepcyjna. –Wymagana mała liczba poleceń. –Możliwość wykonania backupu za pomocą skryptu - automatyzacja archiwizacji. –Spójność plików. –Prostota odtwarzania. Wady –Konieczność zamknięcia bazy danych a tym samym zaakceptowanie jej niedostępności. –Konieczność ponownego załadowania pamięci cache po restarcie bazy danych.

Backup dla trybu NOARCHIVELOG Żadna informacja historyczna nie jest zapisywana do plików dziennika powtórzeń (tryb domyślny). Metoda sporządzania backupów: tylko z poziomu systemu operacyjnego przy wyłączonej bazie danych (offline). odtwarzanie możliwe jest tylko do chwili wykonania ostatniego pełnego backupu

Odtwarzanie bazy danych w trybie NOARCHIVELOG Tryb NOARCHIVELOG jest domyślnym trybem pracy bazy danych, ale należy stosować go tylko w uzasadnionych przypadkach. Procedury odtworzenia bazy danych w trybie NOARCHIVELOG: –zastąpienie aktualnych plików bazy danych pełną kopią archiwalną; –zastąpienie uszkodzonej przestrzeni tabel.

Wczytanie pełnej kopii archiwalnej 1.Zamknięcie bazy danych poleceniem shutdown lub shutdown abort. 2.Wgranie wszystkich plików bazy danych z ostatniej kopii bezpieczeństwa na ich właściwe miejsca. 3.Otwarcie bazy danych poleceniem startup.

Zastąpienie zniszczonej przestrzeni tabel nową przestrzenią 1.Wyłączenie uszkodzonego pliku Jeżeli baza danych pracuje w trybie NOARCHIVELOG, plik można wyłączyć jedynie stosując polecenie z klauzulą offline drop. alter database datafile C:\BAZA\DANE2.DBF offline drop; Po wykonaniu tego polecenia, w widoku V$DATAFILE plik DANE2.DBF będzie posiadał status offline. 2.Otwarcie bazy danych alter database open; Wyświetlenie informacji o przestrzeniach tabel: select tablespace_name, status, contents from dba_tablespaces;

Zastąpienie zniszczonej przestrzeni tabel nową przestrzenią cd. 3.Usunięcie przestrzeni tabel DANE z zawartością Dane, które pozostały tylko w jednym pliku.dbf nie są spójne, więc jedynym wyjściem jest usunięcie przestrzeni tabel DANE ze związanymi z nią plikami danymi: drop tablespace DANE including contents; 4.Usunięcie w SO plików uszkodzonej przestrzeni tabel. 5.Utworzenie nowej przestrzeni tabel Utworzenie nowej przestrzeni tabel DANE o początkowym rozmiarze 5 MB: create tablespace DANE datafile C:\BAZA\DANE2.DBF size 5M;

Backup dla trybu ARCHIVELOG Najbardziej aktualne dane w bazie są możliwe do odtworzenia instancji, a archiwalne kopie plików dziennika pozwalają na odtworzenie bazy w przypadku awarii nośnika. WYMAGANIA: Konfiguracja procesu drugoplanowego ARCH, ustawienie trybu ARCHIVELOG, zapewnienie wystarczającej ilości wolnego miejsca na dysku. ZALETY: –większa ochrona przed utratą danych, –możliwość wykonania backupu podczas pracy bazy danych, –możliwość odtworzenia bazy danych do specyficznego miejsca w czasie.

Odtwarzanie pełne bazy danych w trybie ARCHIVELOG Zalety –można odtwarzać jedynie uszkodzone pliki; –nie są tracone żadne zatwierdzone dane; –odtwarzanie może być wykonane przy otwartej bazie danych (oprócz przestrzeni tabel SYSTEM i przestrzeni z aktywnymi segmentami wycofania); Wady –trzeba posiadać wszystkie archiwalne pliki dziennika powtórzeń od ostatniego backupu do czasu wystąpienia awarii.

Polecenie RECOVER Polecenie RECOVER służy do odtwarzania bazy danych po awarii. recover [automatic] database recover [automatic] tablespace | recover [automatic] datafile | Równoważne alter database recover..... (dalsza składnia pozostaje bez zmian)

Metody odtwarzania bazy danych - ARCHIVELOG wyłączenie nadpisywanych plików na czas odtwarzania; –alter tablespace..... Offline –alter database datafile..... offline wczytanie z kopii bezpieczeństwa uszkodzonych plików danych; zamontowanie lub otwarcie bazy danych; odtworzenie bazy danych za pomocą polecenie recover.

Metody odtwarzania bazy danych - typy 1.Odtwarzanie zamkniętej bazy danych baza nie musi być dostępna przez 24 godziny na dobę 7 dni w tygodniu, odzyskiwane pliki należą do przestrzeni SYSTEM lub zawierają segmenty wycofania, odtworzenia wymaga cała baza danych lub jej główne pliki danych. 2.Odtwarzanie otwartej bazy danych, otwartej w chwili wystąpienia awarii gdy zostaje uszkodzony plik danych lub wystąpi awaria nośnika, lecz baza nie musi zostać zamknięta, gdy baza musi być dostępna przez 24 godziny na dobę 7 dni w tygodniu, kiedy odzyskiwane pliki nie należą do przestrzeni SYSTEM i nie zawierają aktywnych segmentów wycofania.

Metody odtwarzania bazy danych - typy 3.Odtwarzanie otwartej bazy danych poprzedzone jej otwarciem awaria nośnika lub systemu spowoduje jego zamknięcie, baza musi być dostępna przez 24 godziny na dobę 7 dni w tygodniu, odzyskiwane pliki nie należą do przestrzeni SYSTEM i nie zawierają aktywnych segmentów wycofania. 4.Odtwarzanie pliku danych nie mającego kopii archiwalnej gdy awaria nośnika lub błąd użytkownika spowodują utratę nigdy nie archiwizowanego pliku danych, gdy dysponujemy wszystkimi archiwalnymi plikami dziennika powtórzeń, od czasu utworzenia ostatniej kopii bezpieczeństwa do chwili obecnej, gdy odtwarzany plik nie należy do przestrzeni SYSTEM i nie zawiera aktywnych segmentów wycofania.

Tworzenie kopii przy otwartej bazie danych (hot backup) Zalety –ciągła dostępność bazy danych, –możliwość wyboru obszaru kopiowania, –możliwość odtworzenia do określonego punktu w czasie. Wady –wymóg większego doświadczenia ze strony DBA, –większa podatność na błędy operatora.

Tworzenie kopii przy otwartej bazie danych - wymagania –Ustawienie trybu pracy bazy danych na ARCHIVELOG. –Uruchomienie procesu ARCH. Backup online należy wykonywać przy możliwie najmniejszym obciążeniu bazy danych operacjami modyfikującymi.

Archiwizacja otwartej bazy danych –Przełączenie odpowiedniego obszaru tabel w tryb tworzenia kopii bezpieczeństwa. alter tablespace nazwa_obszaru_tabel begin backup; –Wykonanie kopii plików danych wchodzących w skład przestrzeni tablic. Copy c:\users\disk1\user01.ora e:\users\backup\user01.ora –Wyłączenie obszaru tabel z trybu tworzenia backupu. alter tablespace nazwa_obszaru_tabel end backup; Ww. kroki należy powtórzyć dla każdego obszaru tabel, dla którego planowane jest wykonanie kopii bezpieczeństwa. Włączając w to przestrzeń SYSTEM, przestrzenie tymczasowe, przestrzenie z segmentami wycofania, itd

Archiwizacja otwartej bazy danych Aby zminimalizować archiwizacji otwartej bazy danych wpływ na wydajność należy: –tworzyć kopie bezpieczeństwa przy najniższym natężeniu operacji DML dotyczących tego obszaru, –minimalizować czas pomiędzy krokiem 1 a 3, –zadbać o to, aby obszar tabel nie pozostawał w trybie tworzenia kopii bezpieczeństwa przez długi czas po niepowodzeniu procesu kopiowania

Archiwizacja otwartej bazy danych TABELA / PERSPEKTYWA OPIS V$BACKUP Perspektywa ta jest pomocna przy określaniu, które pliki są w trybie archiwizacji. Po wydaniu polecenia alter tablespace … begin backup ich status zmienia się na ACTIVE. Kolumna STATUS przyjmuje wartość NOT ACTIVE po zakończeniu archiwizacji V$DATAFILE_HEADER Po wydaniu polecenia alter tablespace … begin backup wartość kolumny FUZZY dla plików danej przestrzeni zmienia się na YES, co oznacza, że mogą wystąpić ROZMYTE odczyty z powodu archiwizacji online. Kolumna FUZZY zmienia wartość na NULL po wydaniu polecenia kończącego backup.

Archiwizacja pliku kontrolnego Tworzenie kopii binarnej pliku kontrolnego: alter database backup controlfile to nazwa_pliku; Polecenie to należy wydać w czasie, gdy baza danych pracuje w trybie MOUNT lub OPEN. Uwaga: dodatkowo, po zarchiwizowaniu pliku kontrolnego należy zarchiwizować również pliki danych. Tworzenie pliku śladu: alter database backup controlfile to trace; Utworzony plik będzie nosił nazwę oraxxx.trc (gdzie xxx oznacza numer pliku generowany przez instancję) i zostanie utworzony w katalogu wskazywanym przez parametr USER_DUMP_DEST w pliku init.ora. Plik śladu może być edytowany i wykorzystywany po ponownego utworzenia bazy danych.

Archiwizacja przestrzeni tylko-do- odczytu: Zmiana statusu przestrzeni tabel z read write na read only. Wykonanie kopii bezpieczeństwa za pomocą narzędzi systemu operacyjnego. Ewentualna zmiana statusu przestrzeni tabel z read only na read write

Odzyskiwanie danych z backupu online 1.Zamknięcie bazy danych. 2.Odtworzenie utraconych danych z kopii bezpieczeństwa. 3.Uruchomienie bazy danych. 4.Uzyskanie niezbędnych informacji o plikach dziennika powtórzeń. select x.group#, member, sequence#, first_change# from V$LOG x, V$LOGFILE y where x.group#=y.group#; 5.Odtworzenie plików danych przy użyciu archiwizowanych i bezpośrednich rejestrów dziennika powtórzeń. recover datafile pelna_sciezka_dostepu_do_pliku_danych; Podczas odtwarzania należy potwierdzać każdy plik dziennika aż do otrzymania komunikatu Media Recovery Complete 6.Otwarcie bazy danych. alter database open

Odtwarzanie niepełne TYPY –Odtwarzanie do określonego momentu w czasie (time-based). –Odtwarzanie do przerwania (cancel-based). –Odtwarzanie do określonego SCN (SCN-based). Stosuje się gdy –użytkownik usunął przypadkowo dane, –uszkodzeniu uległ plik danych i niektóre zarchiwizowane pliki dziennika powtórzeń.

Odtwarzanie niepełne Odtwarzanie niepełne przywraca zawartość bazy danych do stanu, w którym znajdowała się w danym momencie w przeszłości. Dlatego przed przystąpieniem do aplikowania zapisów ze zarchiwizowanych plików dziennika powtórzeń należy wgrać z ostatniej kopii bezpieczeństwa wszystkie pliki danych (jeśli plik kontrolny nie uległ zniszczeniu, nie należy go wgrywać). W wyniku odtwarzania niepełnego informacje synchronizujące bazę danych są niespójne – w pliku kontrolnym zapisany jest inny numer SCN punktu kontrolnego niż w nagłówkach plików danych. W celu zrównania tych numerów, bezpośrednio po odtworzeniu bazy danych, należy wyzerować numery sekwencyjne w nagłówkach wszystkich plików danych i odpowiadające im numery sekwencyjne w pliku kontrolnym. : alter database open resetlogs; Po odtworzeniu bazy danych i wyzerowaniu numerów sekwencyjnych należy sporządzić nową kopię bezpieczeństwa całej bazy danych. Wyzerowanie numerów sekwencyjnych powoduje, że: po otwarciu bazy danych pliki dziennika powtórzeń będą otrzymywały numery sekwencyjne począwszy od 1; poprzednio zarchiwizowane pliki dziennika powtórzeń staną się nieprzydatne do odtwarzania bazy.

Odtwarzanie – składnia polecenia RECOVER recover [automatic] [from sciezka_log] database until time YYYY-MM-DD:HH24:MI:SS [using backup controlfile];

Odtwarzanie do określonego punktu w czasie 1.Zatrzymanie bazy danych. 2.Wgranie wszystkich plików danych z ostatniej kopii bezpieczeństwa na ich właściwe miejsca (nie należy wgrywać plików kontrolnych, jeśli nie uległy one uszkodzeniu i plików dziennika powtórzeń). 3.Uruchomienie bazy danych w trybie MOUNT startup mount 4.Odtworzenie bazy danych do stanu określonego czasem: recover database until time YYYY-MM-DD:HH24:MI:SS; 5.Otwarcie bazy danych z zerowaniem numerów sekwencyjnych: alter database open resetlogs;

Odtwarzanie do przerwania 1.Zatrzymanie bazy danych. 2.Wgranie wszystkich plików danych z ostatniej kopii bezpieczeństwa na ich właściwe miejsca (nie należy wgrywać plików kontrolnych, jeśli nie uległy one uszkodzeniu i plików dziennika powtórzeń). 3.Uruchomienie bazy danych w trybie MOUNT startup mount 4.Odtworzenie bazy danych do przerwania: recover database until cancel; 5.Otwarcie bazy danych z zerowaniem numerów sekwencyjnych: alter database open resetlogs;

Odtwarzanie do określonego SCN Sequence Control Number 1.Zatrzymanie bazy danych. 2.Wgranie wszystkich plików danych z ostatniej kopii bezpieczeństwa na ich właściwe miejsca (nie należy wgrywać plików kontrolnych, jeśli nie uległy one uszkodzeniu i plików dziennika powtórzeń). 3.Uruchomienie bazy danych w trybie MOUNT startup mount 4.Odtworzenie bazy danych do przerwania: recover [automatic] [from sciezka_log ] database until change nrSCN [using backup controlfile]; 5. Otwarcie bazy danych z zerowaniem numerów sekwencyjnych: alter database open resetlogs;

Utrata bieżącego pliku dziennika powtórzeń Jeśli jeden z plików dziennika powtórzeń zostanie utracony lub uszkodzony, to prawdopodobnie nie będzie możliwe odtworzenie bazy do momentu wystąpienia awarii. Jeśli jednak poniższe punkty zostaną spełnione, to żadne dane nie zostaną utracone: –stracone pliki dziennika nie były bieżące, –pliki te zostały zarchiwizowane, –pliki dziennika powtórzeń są zwielokrotnione.

Utrata bieżącego pliku dziennika powtórzeń O utracie lub zniszczeniu plików dziennika powtórzeń może świadczyć kilka objawów: –baza danych uległa awarii, a przy próbie jej uruchomienia pojawia się komunikat ORA-1194, –podczas odtwarzania nośnika za pomocą polecenia: recover database using backup controlfile until cancel; pojawia się komunikat ORA-314, ORA-312 i ORA-376.

Odtwarzanie w przypadku nieskopiowania dziennika powtórzeń 1.Zamknąć bazę danych. 2.Wykonać pełną kopię bezpieczeństwa. 3.Dokonać następujących zmian w pliku init.ora: dodać następujące linie: _allow_resetlogs_corruption=true 4.Wykonać operację startup mount. 5.Dokonać niepełnego odtworzenia bazy danych: recover database until cancel; 6.Na prośbę o podanie pliku wpisać CANCEL. 7.Zresetować rejestry i otworzyć bazę danych: recover database open resetlogs; 8.Odbudować bazę danych dokonując pełnego eksportu, a następnie importując ją jako nową bazę danych.

Utrata bieżącego pliku dziennika powtórzeń 1.Określ katalog, w którym utracony plik był poprzednio umieszczony: select * from V$LOGFILE; 2.Grupa 1 nie może zostać usunięta, gdyż Oracle wymaga istnienia przynajmniej dwóch. Polecenie alter database drop logfile group 1, kiedy są tylko dwie grupy zwróci błąd. Dlatego należy stworzyć dodatkową tymczasową grupę: alter database add logfile group 3 /disk1/data/log3a.rdosize 150k; 3.Uszkodzoną grupę można już usunąć: alter database drop logfile group 1;

Utrata bieżącego pliku dziennika powtórzeń 4.A następnie powtórnie utworzyć: alter database add logfile group 1 /disk1/data/log1a.rdosize 150k; 5.Można teraz usunąć tymczasowo utworzoną grupę 3: alter database drop logfile group 3; 6.A następnie usunąć z dysku niepotrzebny plik (z poziomu systemu operacyjnego): rm /disk1/data/log3a.rdo 7.Po tych krokach można otworzyć bazę: alter database open; 8.Należy zwielokrotnić wszystkie pliki dziennika powtórzeń, co zredukuje możliwość wystąpienia podobnej awarii.

Utrata bieżącego pliku dziennika powtórzeń Uwaga: Jeżeli obie grupy są takich samych rozmiarów, to kroki 2-7 można zastąpić dwoma prostymi poleceniami: !cp /disk1/data/log2a.rdo /disk1/data/log1a.rdo alter database clear logfile /disk1/data/log1a.rdo ;

Odzyskiwanie utraconego pliku kontrolnego Jeżeli istnieją inne kopie pliku sterującego, można ich użyć w celu doprowadzenia bazy danych do stanu działania. –Zamknąć instancję, jeśli ciągle działa. –Znaleźć przyczynę utraty pliku kontrolnego (czy jest to problem sprzętowy). –Jeśli problem nie jest związany ze sprzętem, należy zrobić dobrą kopię bezpieczeństwa pliku sterującego i umieścić ją tam, gdzie znajdował się plik, a następnie uruchomić bazę danych. –Jeśli problem dotyczy sprzętu, należy zrobić odpowiednią kopię bezpieczeństwa i umieścić ją w bezpiecznym miejscu. –Dokonać edycji pliku init.ora lub config.ora w celu zaktualizowania parametru CONTROL_FILES tak, aby wskazywał nowe położenie pliku sterującego.

Tworzenie nowego pliku kontrolnego Po uszkodzeniu pliku kontrolnego (nie ma żadnej jego kopii) istnieje możliwość utworzenia jego nowego odpowiednika 1.Uruchomić instancję. startup nomount 2.Utworzyć plik kontrolny za pomocą polecenia create controlfile Archiwizacja plików dziennika powtórzeń. alter system archive log all; 4.Otwarcie bazy danych

Tworzenie nowego pliku kontrolnego create controlfile reuse database BAZA noresetlogs archivelog maxlogfiles 32 maxlogmembers 2 maxdatafiles 20 maxinstances 16 maxloghistory 1600 logfile group 1 C:\BAZA\REDO1.ORA size 500k, group 2 C:\BAZA\REDO2.ORA size 500k, group 3 C:\BAZA\REDO3.ORA size 500k, group 4 C:\BAZA\REDO4.ORA size 500k, datafileC:\BAZA\SYSTEM.DBF, C:\BAZA\DANE1.DBF, C:\BAZA\DANE2.DBF, C:\BAZA\TEMP.DBF, C:\BAZA\RBS.DBF character set WE8ISO8859p1;

Tworzenie nowego pliku kontrolnego reusepowoduje nadpisanie istniejących plików kontrolnych, databaseokreśla nazwę bazy danych, noresetlogsumożliwia otwarcie bazy danych bez zerowania numerów sekwencyjnych, natomiast słowo kluczowe resetlogs wymusza otwarcie bazy danych z zerowaniem numerów sekwencyjnych, archivelogoznacza tryb pracy bazy danych Jeżeli w poleceniu create controlfile wyspecyfikowano słowo kluczowe resetlogs, wówczas należy sporządzić pełną kopię archiwalną bazy danych. Jeżeli dodatkowo wgrano kopie bezpieczeństwa plików danych lub wcześniej zamknięto bazę danych w trybie ABORT, wówczas przed otwarciem baza musi zostać odtworzona.

Stan odtwarzania - słownik danych TABELA / PERSPEKTYWAOPIS V$RECOVERY_STATUS zawiera informacje o odtwarzaniu dla całej bazy danych. V$RECOVERY_FILE_STATUS zawiera informacje o odtwarzaniu dotyczące poszczególnych plików danych.

Cechy backupu z poziomu SO: Pozytywne –brak potrzeby zakupu dodatkowego oprogramowania; –prostota koncepcyjna; –szybkość wykonywania kopii bezpieczeństwa; –możliwość integracji z zarządcami mediów. Negatywne –brak pełnej automatyki działań; –uwarunkowania sprzętowe.

RMAN – pojęcia RMAN – narzędzie do wykonywania backupów; Baza TARGET – baza produkcyjna; Baza CATALOG – repozytorium RMANa; Media Managers – moduł do obsługi mediów; Save set – pojedyncze zabezpieczenie na kliencie

RMAN nie powinien być traktowany jako narzędzie zastępujące Server Managera czy SQL*Plus; jedyny sposób sporządzania kopii bezpieczeństwa; katalog odtwarzania; Enterprise Backup Utility; narzędzie archiwizujące dla NT;

RMAN - właściwości Możliwość przechowywania skryptów w bazie danych. Możliwość wykonywania backupów przyrostowych na poziomie bloków. Ekstrakcja nieużywanych bloków. Możliwość zdefiniowania limitów dla każdego backupu. Możliwość automatycznego uruchamiania. Detekcja uszkodzonych bloków podczas archiwizacji i odtwarzania. Wzrost szybkości działania. Możliwość stosowania dodatkowych narzędzi współpracujących z pamięcią masową.

RMAN - zyski Dzięki zastosowaniu RMANa, zwiększa się znacznie szybkość wykonywania kopii bezpieczeństwa, dzięki –automatycznemu zrównolegleniu procesów archiwizacji i odtwarzania ; –podczas backupów online nie generuje się żadnych dodatkowych informacji redo; –możliwości ograniczenia liczby odczytów na plik (na sekundę) w celu zmniejszenia obciążenia środowisk OLTP;

Pusty

Str. 124