Wpisy z tagiem: dba4dev

Dlaczego plik kontrolny bazy Oracle jest tak istotny ?

Umożliwia instancji pracę na bazie danych. Zawiera metadane o bazie danych. Czyli informacje o:

• plikach bazy danych
• backup'ach

Bez tego pliku instancja nie może:

• zamontować ani otworzyć bazy danych - nie wie gdzie znajdują się pliki bazodanowe
• odtworzyć backup'u - nie będzie wiedzieć gdzie są backup piece (mowa o nich w: )
• sprawdzić spójności bazy danych - nie wie jaki jest SCN (System Change Number) bazy danych i nie może go porównać z informacją w nagłówkach plików bazodanowych
• uspójnić bazy danych (wykonać recovery) - nie wie gdzie są archiwalne pliki logu transakcyjnego (więcej o logu transakcyjnym w: )

Nie działa też komenda 'list' RMAN'a - wyświetlane informacje o backup'ach pobiera z pliku kontrolnego.

Dla powyższych powodów plik kontrolny jest najbardziej chronionym plikiem Oracle. W czasie normalnej pracy instancji utrzymywanych jest kilka kopii pliku kontrolnego (konfigurowalne). Zazwyczaj na różnych dyskach czy w różnych katalogach.

Oracle dostarcza również mechanizmów pozwalających na utrzymanie jak najbardziej aktualnej kopii zapasowej pliku kontrolnego (backup). Służy do tego funkcjonalność RMAN'a. Pozwala na wykonywanie backup'ów automatycznych (autobackup) za każdym razem gdy zawartość pliku kontrolnego się zmienia aby odzwierciedlić strukturę bazy danych - ilość i stan plików - lub informacje o backup'ie zakończonym sukcesem. Kopia pliku kontrolnego jest dołączana, również do każdego backup'u pliku bazodanowego nr 1. Aby włączyć tę funkcjonalność należy wydać komendę RMAN'owi: 'CONFIGURE CONTROLFILE AUTOBACKUP ON'.

Podczas automatycznego backup'u pliku kontrolnego kopiowany do backup piece jest, również plik konfiguracyjny spfile. Jeśli takowego nasza instancja używa ;-)

Zasady odtwrzania kopii pliku kontrolnego z backup'u automatycznego są podobne do zasad obowiązujących podczas odtwarzania kopii pliku konfiguracyjnego - spfile. Pisałem o tym w: Jak odtworzyć spfile - plik... . W uproszczeniu: nie używając FRA, do przechowywania backup'u pliku kontrolnego, musimy znać DBID bazy danych. Nie musimy znać DBID używając recovery catalog i/lub FRA.

Zdarzają się sytuacje gdy kopia pliku kontrolnego nie zawiera wszystkich informacji o, potrzebnych do recovery, plikach archiwalnych logu transakcyjnego (archivelogach). Wtedy możemy zarejestrować brakujące pliki. Oczywiście jeśli są dostępne. Umożliwi to RMAN'owi ich odnalezienie i naniesienie na bazę danych. Dzięki czemu baza odzyska spójność i będzie mogła być otwarta przez instancję.

W przypadku ręcznego odtworzenia pliku kontrolnego komendą 'create control file' otrzymujemy plik bez żadnych informacji o backup'ach. Wtedy trzeba je zarejestrować komendą 'catalog'.

Keywords: #database #instance #oracledatabase #rdbms #sql #backend #dba4dev #marcinbadtke

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

Czym różni się backup fizyczny od logicznego ?

Fizyczny backup polega na skopiowaniu fizycznej struktury bazy danych. Czyli plików. Narzędzia wykonujące backup fizyczny kopiują plik po pliku. Wyjątkiem jest Oracle RMAN - Recovery MANager - kopiujący pliki bazy danych blok po bloku. O czym mowa w: .

Logiczny backup, natomiast, polega na skopiowaniu logicznej struktury bazy danych. Czyli schematów, tabel, danych. Narzędzie wykonujące backup logiczny kopiuje obiekty bazy danych, jeden po drugim, często przetwarzając je na komendy języka SQL. Tak działa np. Oracle expdp, narzędzie PostgreSQL - pg_dump, MySQL mysqldump czy SQL Server bcp.

Każdy backup gorący wymaga uspójnienia - recovery. W przypadku fizycznego backup'u instancja bazy danych wykorzystuje do tego log transakcyjny. O czy mowa w: Jaka jest różnica pomiędzy r... . Jak uspójnić gorący backup logiczny ? Nie da się. Trzeba od razu wykonać backup spójny. Wykorzystywane są do tego mechanizmy transakcyjności i MVCC.

Aby Oracle expdp wykonał spójny backup należy użyć parameteru FLASHBACK_SCN lub FLASHBACK_TIME. Przy czym FLASHBACK_TIME jest konwertowany na najbliższy SCN. Wartości tych parametrów mogą wskazywać na wcześniejszy punkt w czasie niż moment rozpoczęcia backup'u logicznego. Aby backup zakończył się sukcesem należy zapewnić odpowiednią ilość przestrzeni UNDO. Bez użycia parameterów FLASHBACK_SCN lub FLASHBACK_TIME expdp wykona backup spójny, ale tylko dla poszczególnych tabel. Dane w różnych tabelach nie będą spójne.

Dla odmiany PostgreSQL pg_dump zawsze wykonuje backup spójny. Wykorzystuje do tego pojedynczą transakcję i mechanizm MVCC.

Aby zapewnić spójność backup'u logicznego w MySQL należy użyć przełącznika --single-transaction. Zadziała dla InnoDB. Aby wykonać spójny backup danych nietransakcyjnych - np. MyISAM - należy zablokować całą bazę danych na czas backup'u.

Do czego przydają się backup'y logiczne ?

Są przenośne pomiędzy platformami i różnymi wersjami bazy danych. Dzięki nim możemy przenieść dane z AIX do Linux lub Windows. Lub z Oracle 12c do 10g. Lub do chmury.

Dodatkowym atutem jest weryfikacja spójności logicznej bazy danych. Posiadanie backup'u logicznego jest, również kolejnym zabezpieczeniem na wypadek utraty środowiska razem ze wszystkimi backup'ami.

#database #oracle #sql #plsql #backend #mysql #postgresql #sqlserver #dba4dev #marcinbadtke #expdp #backup #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