Wpisy z tagiem: restore

Jak odtworzyć spfile - plik konfiguracyjny instancji bazy danych Oracle ?

Instancja bazy danych Oracle może współpracować z plikiem konfiguracyjnym w postaci tekstowej: pfile oraz w postaci binarnej: spfile. Tylko plik binarny - spfile może być automatycznie backup'owany przez RMAN'a. Scenariusze odtworzenia z automatycznego backup'u:

1. Jeśli straciliśmy całą bazę danych razem z binariami, a automatyczny backup pliku kontrolnego nie jest we FRA

Aby móc korzystać z RMAN'a musimy mieć działającą instancję Oracle. UWAGA: nie instancję bazy danych. Chodzi jedynie o procesy i struktury pamięci. Bez danych ani tego co pamiętamy o naszej wyjątkowej konfiguracji. Wystarczy uruchomienie instancji z podstawową konfiguracją i zmienną ORACLE_SID ustawioną na nazwę bazy danych jaką chcemy odtwarzać. Dzięki temu mamy dostęp do funkcjonalności RMAN'a. Innymi słowy startujemy instancję bez montowania bazy danych: 'startup nomount'. DYGRESJA: montowanie bazy danych to otwarcie pliku kontrolnego. A ten nie jest jeszcze dostępny.

Aby RMAN wiedział, spfile której instancji ma odtworzyć, należy najpierw ustawić wartość DBID w sesji rman'a komendą 'set DBID'. Dlatego warto pamiętać jakie DBID mają nasze bazy danych ;-) Następnie komendą 'restore spfile from autobackup' odtwarzamy spfile z najnowszej dostępnej kopii. DYGRESJA: ustawienie DBID potrzebne jest RMAN'owi aby znaleźć odpowiedni backup piece - plik z backup'em. O backup piece mowa w: . Informacje o backup'ach przechowywane są w pliku kontrolnym, a ten jest niedostępny. RMAN wykorzystuje, więc konwencję nazewniczą automatycznych backup'ów w celu znalezienia właściwego. Kluczowym fragmentem nazwy takiego pliku backup'u jest DBID.

1. Straciliśmy całą bazę danych, ale automatyczny backup pliku kontrolnego jest we FRA

Początek jak w punkcie #1 - trzeba uruchomić tymczasową instancję aby móc korzystać z funkcjonalności RMAN'a. Z jedną różnicą - w tymczasowym pliku konfiguracyjnym trzeba wskazać na FRA w którym znajdują się backup'y pliku kontrolnego.

Następnie wystarczy komenda 'restore spfile from autobackup' i RMAN znajdzie i odtworzy dla nas najświeższy spfile.

1. Straciliśmy całą baze danych i chcemy odtworzyć spfile z konkretnego backup piece

Co to backup piece: . Podobnie jak w punkcie #1 trzeba wystartować instancję Oracle. Podobnie trzeba ustawić DBID komendą 'set DBID'. Tym razem składnia komendy 'restore', jednak wskazuje konkretną nazwę pliku z backup'em. Nazwę backup piece. Np. restore spfile from '/ora_backup/C-1029394857-20201212-00';. Dostępne od wersji 10g.

1. Straciliśmy całą bazę danych, automatyczny backup pliku kontrolnego jest gdziekolwiek dostępny, ale używamy recovery catalog

Początek jak w punkcie #2. Różnica taka, że zamiast wskazywania FRA, w tymczasowym pliku konfiguracyjnym, musimy podłączyć się rman'em oprócz bazy target, również do recovery catalog. Dalej równie prosto: 'restore spfile from autobackup'.

1. Baza danych jest nieuszkodzona, a instancja działa i automatyczny backup pliku kontrolnego jest gdziekolwiek dostępny

Nie trzeba startować instancji bo działa. Plik kontrolny jest dostępny, więc RMAN wie gdzie znaleźć backup. Wtedy wystarczy komenda: restore spfile to pfile '/tmp from autobackup';. Należy pamiętać, że tak odtworzony plik konfiguracyjny jest w postaci tekstowej - inaczej jak spfile, który jest w binarnej.

Jeśli utracie uległa cała baza danych to następnym krokiem jest odtworzenie z backup'u pliku kontrolnego (control file). W nim zawarte są informacje o lokalizacji plików bazodanowych i ich kopiach w backup'ach.

Keywords: #database #oracle #rman #backup #restore #backend #rdbms #dba4dev #marcinbadtke

Jaka jest różnica pomiędzy restore, a recovery?

Każdy pewnie wie, że backup to zapisanie kopii plików bazy danych w innej lokalizacji. Ale gdybyś chciała/chciał pogłębić swoją wiedzę to zapraszam na wideo: o tym jak to robi Oracle.

Co to jest restore też pewnie jest jasne - odtworzenie plików bazy danych z kopii w innej lokalizacji.

Najwięcej niejasności budzi proces recovery. Tłumaczenie nazwy wprost na polski to 'powrót do zdrowia'. Wg mnie najtrafniej, w kontekście baz danych, sens oddaje słowo 'uspójnianie'.

Baza danych jest spójna wtedy gdy wszystkie pliki z których baza się składa mają ostatnią zmianę wykonaną w tym samym czasie. Spójny backup można wykonać jedynie wtedy kiedy baza danych jest wyłączona. Nazywa się to zimnym backup'em - cold backup.

Co to jest ta 'spójność' (consistency) bazy danych ? W przypadku bazy danych Oracle jest to zgodność SCN (System Change Number) zapisanego w pliku kontrolnym (control file) z SCN zapisanym w nagłówkach plików bazodanowych. Gdy wartości te są nieidentyczne instancja Oracle uznaje bazę danych za niespójną i nie otworzy jej do użytku.

Backup gorący - hot backup - z założenia jest niespójny. Wykonanie backup'u trwa. W tym czasie baza jest otwarta i wykonywane są w niej zmiany. W związku z tym każdy plik skopiowany do innej lokalizacji ma inny czas ostatniej zmiany. W efekcie, po odtworzeniu, nie daje to spójnego obrazu danych w bazie danych i baza nie nadaje się do użycia. Aby backup był użyteczny - bazę danych dało się otworzyć i korzystać z niej - trzeba ją uspójnić. Niezbędne do tego są pliki logu transakcyjnego - o którym mowa w: - powstałe w czasie wykonywania backup'u bazy danych. Informacje o zmianach zawarte w logu transakcyjnym pozwalają na naniesienie zatwierdzonych transakcji i wycofanie niezatwierdzonych dzięki czemu pliki bazy danych zostaną uspójnione na ten sam punkt w czasie. Wtedy nadają się do użycia i baza danych może zostać otwarta.

Podobnie sprawa wygląda w momencie padu bazy danych - pliki bazy danych mają różne stemple w związku z tym instancja uznaje dane w bazie za niespójne. Podczas startu instancji bazy danych po awarii, następuje uspójnienie plików przy wykorzystaniu informacji z plików logu transakcyjnego.

Wydanie, instancji bazy danych Oracle, komendy 'shutdown abort', w konsekwencjach, przypomina pad bazy. Instancja zostaje zamknięta bez uspójniania plików bazy danych.

Również naprawa pojedynczego pliku czy bloku bazodanowego wymaga jego odtworzenia z kopii zapasowej (restore). Aby następnie nadawał się do użycia przez bazę danych niezbędne jest przeprowadzenia na nim procesu uspójnienia (recovery). Czyli naniesienia na niego wszystkich zmian, które miały miejsce, od czasu wykonania kopii pliku czy bloku aż do chwili obecnej. Lub punktu w czasie innych plików bazy danych.

#database #oracle #mysql #postgresql #sqlserver #backup #restore #recovery #rdbms #dba4dev #marcinbadtke

Alternatywa dla Oracle Data Guard ?

Oracle Data Guard jest wyśmienitym produktem. Jako dojrzała i sprawdzona technologia replikacyjna jest godny zaufania i szeroko wykorzystywany do zabezpieczania produkcyjnych baz danych. Jest wliczony w cenę wersji Enterprise Edition na bazę produkcyjną. Niemniej wykorzystanie go do celów wysokiej dostępności ma większy sens gdy replikę utrzymujemy na maszynie i dyskach zbliżonych wydajnością do produkcyjnych. Dodatkowo umowa licencyjna limituje czas w którym możemy używać otwartej repliki do kilku dni, a automatyczna naprawa uszkodzonych bloków dostępna jest w dopiero w dodatkowo płatnej opcji Active Data Guard.

Co w momencie gdy chcemy zabezpieczyć bazę danych na poziomie zbliżonym do Data Guard, ale nie możemy go użyć ?

Warto wtedy rozważyć możliwość oferowaną przez RMAN - 'Incremental Merge' inaczej 'Incrementally Updated Backup'. Jest to kopia bazy danych na którą, okresowo, nanoszone są backup'y inkrementalne.

Przewagi nad zwykłym backup'em:

• nie jest to backup piece (o którym mówię w: ) tylko kopia plików bazy danych.
• obraz bazy danych uaktualniany jest przyrostowo z wybraną częstotliwością i retencją
• szybsze odtwarzanie i recovery bazy danych niż z backup'u
• szybsza duplikacja bazy danych bez obciążania produkcyjnego systemu i bez konieczności odtworzenia backup'u
• szybsze recovery pojedynczych bloków bazodanowych
• możliwość przełączenia na kopię (switch to copy)

Przewagi nad Data Guard:

• nie ma limitu czasowego używania kopii bazy danych. Trzeba jednak pamiętać, że bazę pierwotną trzeba odbudować, po przełączeniu na kopię. Warto, też aby dyski na których magazynowana jest kopia miały zbliżoną wydajność do produkcyjnych.
• możliwość przełączenia na kopię (switch to copy) nie tylko całej bazy danych, ale pojedynczych plików bazodanowych*

Aby zwiększyć szybkość wykonywania backup'ów inkrementalnych warto włączyć funkcję 'Block Change Tracking'. Czy jest włączona czy nie można sprawdzić komendą: SELECT status FROM v$block_change_tracking;

Z uwagi na to, że wykonując inkrementalny backup RMAN sprawdza tylko zmienione bloki bazodanowe, Oracle rekomenduje okresowe wykonanie komendy RMAN'a 'restore database validate'. Dzięki temu upewnimy się, że kopia bazy danych jest nieuszkodzona.

EDIT: tak teraz przyszło mi do głowy: a co jeśli by wykonywać backup 'Incremental Merge' na storage w chmurze ? A zasoby potrzebne do postawienia, na takiej kopii, Oracle kupić w razie potrzeby. Np. na środowisko testowe, deweloperskie czy raportowe. Jakie jest Twoje zdanie ?

W sumie dotyczy to również innych motorów - spójna kopia bazy danych tylko na storage w chmurze + postawienie instancji (czyli zapłacenie za zasoby) tylko w razie potrzeby.

#oracle #database #rman #backup #restore #recovery #dba4dev #marcinbadtke

RMAN - backup na taśmę czy do chmury - o czym warto pamiętać ?

Bazy danych są niesamowicie dobre w komunikowaniu się z dyskami. Co do tego nikt nie ma chyba wątpliwości :-) Gdy przychodzi jednak do wykonania backup'u na taśmę pojawia się problem. Jest wielu dostawców napędów taśmowych i wielu dostawców scentralizowanych systemów backup'owych. Utrzymanie możliwości obsługi wszystkich typów napędów byłoby kłopotliwe dla producentów baz danych. Różni producenci poradzili sobie na różne sposoby. Bazy danych MySQL i PostgreSQL cedują to zadanie na narzędzia systemu operacyjnego. Również baza danych Oracle, backup'owana klasyczną metodą, wymaga użycia narzędzi zewnętrznych aby zapisać backup na taśmach.

Sprawa wygląda zupełnie inaczej gdy użyty zostanie RMAN - Recovery MANager. Utworzenie bazy danych Oracle, z włączonym trybem ARCHIVELOG, pozwala na użycie produktu RMAN i natychmiastowe wykonywanie backup'u na dysk podczas normalnej pracy bazy danych. Aby RMAN mógł zapisywać backup bezpośrednio na taśmę niezbędne jest wskazanie instancji Oracle lokalizacji biblioteki pozwalającej na obsługę konkretnego napędu taśmowego. Na systemach Unix/Linux jest to link do biblioteki libobk.so utworzony w $ORACLE_HOME/lib. Na Windows umieszczenie biblioteki o nazwie orasbt.dll w systemowej ścieżce wyszukiwania - %PATH%. Biblioteki instalowane są razem z oprogramowaniem systemu backp'owego. Warto zwrócić uwagę aby użytkownik, na którym pracuje instancja bazy danych, miał prawo do wykonywania biblioteki. Dostępność tej biblioteki jest oczywiście, również niezbędna podczas odtwarzania backup'u.

Dla najprostszych rozwiązań taśmowych - jeden napęd podłączony bezpośrednio do hosta z instancją bazy danych (nie dotyczy RAC) - Oracle przygotował darmową wersję swojego produktu: Oracle Secure Backup Express. OSB w pełni integruje się z bazą danych, RMAN, Oracle Cloud, Exadata czy Oracle Enterprise Manager i Grid Control. A dzięki Oracle Secure Backup Cloud Module potrafi wykonać backup bezpośrednio do Amazon S3. Płatnymi rozwiązaniami firm trzecich są np. Veritas NetBackup (dawniej Symantec NetBackup) czy EMC NetWorker (dawniej Legato NetWorker).

Aby testować skrypty RMAN'a, nie mając dostępu do napędu taśmowego, Oracle udostępnia bibliotekę testową pozwalającą na symulowanie takowego napędu na dysku. Można jej użyć wykonując poniższy skrypt z poziomu rman'a podłączonego do bazy danych np. komendą 'rman target /':

run {
allocate channel t1 type 'sbt_tape' PARMS="SBT_LIBRARY=oracle.disksbt, ENV=(BACKUP_DIR=/ora_backup)";
backup database;
}

Katalog /ora_backup musi istnieć, a użytkownik na którym pracuje instancja bazy danych musi mieć do niego prawo zapisu. W logu rman'a będzie można zobaczyć wpis: "WARNING: Oracle Test Disk API".

Kanał, tworzony komendą 'allocate channel', jest nowym procesem (na Windows wątkiem) powstającym na hoście na którym pracuje instancja bazy danych. Proces ten przesyła strumień danych z plików bazodanowych do napędu taśmowego wykorzystując bibliotekę libobk.so (na Windows orasbt.dll). Oracle steruje biblioteką ustawiając zmienne środowiskowe dla procesu kanału opcją PARMS. W powyższym przykładzie w ten sposób został wskazany katalog, w którym ma być zapisany backup.

UWAGA: nie należy używać biblioteki testowej do wykonywania backup'ów produkcyjnych. Ma małą wydajność gdyż jest optymalizowana dla taśm, a nie dysków.

Do pełnego testowania wszystkich warstw oprogramowania potrzebnego do wykonania backup'u na taśmę służy narzędzie sbttest. Wywoływane jest z linii komend i dostępne tylko dla systemów Unix/Linux. Dokonuje zapisu na taśmę aby później ten zapis odczytać. Dzięki temu można sprawdzić czy RMAN oraz oprogramowanie klienta backup'u jest skonfigurowane poprawnie i czy nadane są odpowiednie uprawnienia. Dla systemu Windows istnieje narzędzie loadsbt.exe, ale o mniejszej funkcjonalności.

Podczas diagnozowania problemów z backupem na taśmę warto zwrócić uwagę na 2 błędy:
ORA-19511 - komunikat dla tego błędu nie pochodzi z Oracle tylko z oprogramowania obsługującego taśmy. Problemów nie należy, więc szukać po stronie Oracle.
ORA-27206 - komunikat Oracle dla tego błędu: 'requested file not found in media management catalog' wskazuje wyraźnie, że problemów należy szukać po stronie oprogramowania obsługującego taśmy.

Linki:
O architekturze RMAN -
O zaletach dostępu blokowego RMAN'a -
O tym jak działają kanały RMAN'a -
Oracle Secure Backup - https://www.oracle.com/database/technologies/high-availability/secure-backup.html
Veritas NetBackup - https://www.veritas.com/protection/netbackup
EMC NetWorker - https://www.delltechnologies.com/pl-pl/data-protection/data-protection-suite/networker-data-protection-software.htm

#database #oracle #programming #sql #plsql #backend #coding #development #rman #backup #restore #recovery #osb #networker #netbackup #mysql #postgresql #dba4dev #marcinbadtke

Termin #Oracle #database na dziś:

RMAN - Recovery MANager - narzędzie zintegrowane z instancją bazy danych Oracle służące do backup'u i odzyskania bazy danych Oracle. Mowa o tym w: .

Po utworzeniu bazy danych Oracle z włączonym trybem ARCHIVELOG RMAN jest gotowy do użycia. Aby wykonać pełny backup bazy danych wystarczą 2 komendy:
$> rman target /
RMAN> backup database;

Komendy do listowania backup'ów bazy danych:
$> rman target /
RMAN> list backup;

Chcesz wiedzieć więcej o #RMAN czy szerzej o #backup / #restore / #recovery ?

#sql #plsql #backend #dba4dev #marcinbadtke