Strojenie,administracja itp. Cz. 2

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.
1
Narzędzia dostarczane z Oracle
SQL*Plus
Menadżer serwerów
SQL*DBA/
SQL*Loader
Import
Export
SQL*Net
Kategorie awarii
•
•
•
•
•
-
awaria nośnika
awaria instancji
awaria procesu użytkownika
błąd użytkownika
błąd polecenia
2
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.
3
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ą).
4
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
zapasowych serwerów bazy danych
środowiska
jest to kopia bazy głównej, która działa w trybie odtwarzania
wykorzystując archiwa rejestrów bazy głównej.
5
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 tworzenia kopii zapasowych
„Na zimno” (Cold Backup):
Zamyka bazę danych, kopiuje wszystkie pliki i zarchiwizowane
dzienniki komend.
Zalety:
Możliwość przywrócenia do punktu awarii
Wady:
Trzeba zamknąć bazę, co uniemożliwia dostęp
„Na gorąco” (Hot Backup):
Oznacza przestrzeń tabel do utworzenia kopii, kopiuje pliki i odznacza przestrzeń
tabel.(pętla)
Możliwość przywrócenia do punktu awarii - baza danych zostaje
Zalety: przywrócona do działania
Trudniejsza obsługa skryptów, uaktywnia więcej opcji cofania
Wady: co pochłania więcej przestrzeni i zasobów
Export:
Zapewnia logiczną kopię danych.
Może przywrócić tabelę na raz zamiast całej bazy danych. Dobry
Zalety:
jako uzupełnienie dwóch pozostałych metod.
Brak możliwości przywrócenia do punktu awarii; wszystkie
Wady: :
dane od ostatniego eksportu zostaną utracone.
6
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
Baza danych : SPÓJNA
NIE SPÓJNA
Tablespace Status: Tablespace Status:
READ ONLY
READ/WRITE
SPÓJNA
Tablespace Status:
READ ONLY
AWARIA
BACKUP
RECOVERY
7
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.
8
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.
9
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
dba_tablespaces;
from
10
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.
11
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 <number>|<name>
recover [automatic] datafile <number>|<name>
Równoważne
alter database recover .....
(dalsza składnia pozostaje bez zmian)
12
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.
13
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.
14
Tworzenie kopii przy otwartej
bazie danych - wymagania
– Ustawienie trybu
ARCHIVELOG.
pracy
bazy
danych
na
– 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
15
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
V$BACKUP
OPIS
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.
16
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<SID>.ora.
Plik śladu może być edytowany i wykorzystywany po
ponownego utworzenia bazy danych.
Archiwizacja przestrzeni tylko-doodczytu:
• 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
17
Odzyskiwanie danych z backupu online
1.
2.
3.
4.
Zamknięcie bazy danych.
Odtworzenie utraconych danych z kopii bezpieczeństwa.
Uruchomienie bazy danych.
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ń.
18
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];
19
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
sekwencyjnych:
danych
z
zerowaniem
numerów
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;
20
Odtwarzanie do określonego SCN
Sequence Control Number
1.
2.
Zatrzymanie bazy danych.
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ń).
Uruchomienie bazy danych w trybie MOUNT
3.
startup mount
4.
Odtworzenie bazy danych do przerwania:
recover [automatic] [from ‘sciezka_log’] database
until change nrSCN
[using backup controlfile];
5.
Otwarcie bazy
sekwencyjnych:
danych
z
zerowaniem
numerów
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.
21
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
uruchomienia pojawia się komunikat ORA-1194,
jej
– 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<SID>.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.
22
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.rdo’size 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.rdo’size 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.
23
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<SID>.ora lub config<SID>.ora w celu
zaktualizowania parametru CONTROL_FILES tak, aby wskazywał
nowe położenie pliku sterującego.
24
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........
3. 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,
datafile‘C:\BAZA\SYSTEM.DBF’,
‘C:\BAZA\DANE1.DBF’, ‘C:\BAZA\DANE2.DBF’,
‘C:\BAZA\TEMP.DBF’, ‘C:\BAZA\RBS.DBF’
character set WE8ISO8859p1;
25
Tworzenie nowego pliku kontrolnego
reuse
powoduje nadpisanie istniejących plików kontrolnych,
database
określa nazwę bazy danych,
noresetlogs
umożliwia otwarcie bazy danych bez zerowania
numerów sekwencyjnych, natomiast słowo kluczowe
resetlogs wymusza otwarcie bazy danych z
zerowaniem numerów sekwencyjnych,
archivelog
oznacza 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.
Odzyskiwanie w przypadku
uszkodzenia plików REDO*.LOG
Po uszkodzeniu plików dziennika powtórzeń
(czynności dostępne tylko dla sysdba)
1. Uruchomić instancję.
startup mount
2. Odzyskać bazę do miejsca pojawienia się błędu
recover database until cancel
3. Zresetowanie plików dziennika powtórzeń.
alter database open resetlogs;
4. Otwarcie bazy danych
alter database open
26
Stan odtwarzania - słownik danych
TABELA / PERSPEKTYWA
OPIS
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.
27
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;
28
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
współpracujących z pamięcią masową.
narzędzi
RMAN - zyski
Dzięki zastosowaniu RMANa, zwiększa się znacznie
szybkość wykonywania kopii bezpieczeństwa,
dzięki
– automatycznemu
zrównolegleniu
archiwizacji i odtwarzania ;
procesów
– 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;
29
Pusty
Str. 124
30