Wpisy z tagiem: oracle

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

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

Jak wykryć uszkodzenia logiczne, bazy danych, przy pomocy RMAN'a ?

Wiedząc, że pojedyncza operacja zapisu, zainicjowana przez instancję bazy danych, przechodzi przez następujące warstwy:
file system->volume manager->device driver->host-bus adapter->storage controller
zanim finalnie dotrze do dysku, uświadamiamy sobie, że jest wiele miejsc w których blok bazodanowy może zostać uszkodzony. Producent baz danych Oracle twierdzi wręcz, że uszkodzenia bloków są nie do uniknięcia. Ale możemy uniknąć utraty danych spowodowanych awarią wynikającą z uszkodzenia.

Należy pamiętać, że jeden blok bazodanowy zajmuje wiele bloków w systemie plików. Uszkodzenia mogą, więc dotyczyć różnych fragmentów bloku bazodanowego.

Jak wspominałem w RMAN, podczas wykonywania backup'u, weryfikuje spójność fizyczną bloków bazodanowych. Gdy suma kontrolna bloku jest błędna, nagłówek uszkodzony lub niezgodny ze stopką albo blok bazodanowy zawiera same zera baza danych Oracle nie rozpoznaje bloku jako poprawnego. Niezależnie od pozostałej zawartości bloku. Backup zostaje przerwany z błędem 'media corruption'. Informacja o uszkodzonych blokach dostępna jest poprzez view: V$DATABASE_BLOCK_CORRUPTION.

Oprócz uszkodzenia fizycznego bloku występują, również uszkodzenia logiczne. Ma to miejsce w przypadku gdy blok jest rozpoznany, przez bazę danych Oracle, jako poprawny, ale zawartość bloku jest logicznie niespójna lub uszkodzona. Na przykład brakuje fragmentu rekordu lub indeks jest niedopasowany.

Dzięki temu, że RMAN pracuje na poziomie bloków bazodanowych, o czym mówię w: , po wykryciu uszkodzenia podczas wykonywania backup'u, możliwa jest naprawa pojedynczych bloków bazodanowych. Aby jednak nie powtarzać cyklu: próba wykonania backup'u->znalezienie uszkodzonego bloku->naprawa, aż do skutku, można hurtem wykryć uszkodzenia. Po czym wybrać optymalny sposób naprawy: odtworzenie pojedynczych bloków, plików czy całej bazy danych.

RMAN jako narzędzie czytające wszystkie lub większość bloków bazodanych podczas wykonywania backup'u bazy danych jest szczególnie predestynowany do wykrywania uszkodzeń. O ile fizyczne wykrywa domyślnie o tyle wykrywanie błędów logicznych trzeba zaordynować. Służy do tego komenda 'check logical'.

Użyta w taki sposób:

RMAN> backup check logical database;

będzie wykrywać błędy logiczne jednocześnie wykonując backup.
Takie, natomiast wywołanie:

RMAN> backup validate check logical database; (od wersji 11gR2 wystarczy 'validate check logical database')

spowoduje jedynie odczyt bazy danych i sprawdzenie bez skopiowania bloków bazodanowych do backup piece.
Niemniej komunikaty podczas takiego przebiegu do złudzenia przypominają te z wykonania faktycznego backup'u.

Informację o znalezionych uszkodzeniach można odczytać z widoku V$DATABASE_BLOCK_CORRUPTION.

RMAN może również weryfikować bloki bazodanowe zapisane w backup piece. Przykładowa komenda:

RMAN> restore database validate;

Nie spowoduje to odtworzenia bazy danych z backup'u. Jedynie wykona odczyt backup'u i weryfikację poprawności bloków bazodanowych w nim zawartych.

Powyższe komendy zadziałają tylko dla najświeższego backup'u. Do walidacji dowolnego backup set'u służy komenda 'validate backupset'. Jako parametr przyjmuje backup set key - unikalny identyfikator nadawany w momencie powstania backup set'u. Aby dowiedzieć się jakie backup set'y są dostępne oraz jakie mają identyfikatory można użyć komendy: 'list backupset'. Backupset key można znaleźć w kolumnie 'BS Key'.

Keywords: #database #oracle #sql #backend #rman #backup #restore #recovery #corruption #validate #dba4dev #marcinbadtke

Z cyklu migracja #oracle do #postgresql

Witajcie,

Postgres jak zwykle nie przestaje mnie zadziwiać :) Pewna firma, z którą współpracowałem postanowiła przejść z oracle na postgresql. Bazę określiłbym jako "średnią w kierunku prostej" jeśli chodzi o złożoność dlatego też managerowie stwierdzili, że szkoda hajsu na oracle i przechodzimy na postgre. Większość rzeczy przeszła bez problemów i strukturę udało się przenieść ale kilka "modułów" nie działało prawidłowo. Pisząc nie działało prawidłowo mam na myśli, że baza nie rzucała wyjatkami ale dane były różne od oczekiwanych. No i po długich godzinach analizy znalazłem funkcję w oracle:

declare
  vlisttype integer;
BEGIN
	select distinct listtype into vlisttype from schemat.tabela where listname = :jakis_name
        ...xxx
EXCEPTION
  	WHEN TOO_MANY_ROWS THEN
    begin
    	...zzz
    end;
END;

ogólnie ten kawałek kodu w oracle powodował, że jeśli :jakis_name występował w scheat.tabela więcej niż 1 raz to odpalał się kod zzz
procedurka była na tyle sprytna, że 1 - 1 przeniosła się na postgresql bez błędów ale na postgresql zamiast odpalić się zzz odpalał się blok kodu xxx

no i doczytałem się, że postgresql nie rzuca wyjątku w takiej sytuacji ponieważ bierze PIERWSZY z brzegu rekord który mu pasuje (jeśli nie ma order by) i leci dalej.
Aby dostosować funkcję tej (i wielu innych podobnych procedur) konieczne jest dodanie słówka strict po into

declare
  vlisttype integer;
BEGIN
	select distinct listtype into strict vlisttype from schemat.tabela where listname = :jakis_name
        ...xxx
EXCEPTION
  	WHEN TOO_MANY_ROWS THEN
    begin
    	...zzz
    end;
END;

taka mała rzecz, a ile problemów :P