Wpisy z tagiem: dba4dev

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

Najważniejsze na początku: dziękuję wszystkim za czas poświęcony na czytanie i oglądanie moich materiałów. Również za czas poświęcony na 'votowanie', komentarze i prywatne wiadomości.

Moim zamiarem jest publikacja materiałów głównie o, szeroko pojętej, tematyce baz danych. Chcę to robić w sposób atrakcyjny, zrozumiały i przyjazny dla ODBIORCY.

Bazy danych są skomplikowanymi i niezwykle użytecznymi narzędziami bogatymi w przydatne funkcje. Uważam, że wiedza o tym jak działają i jak można wykorzystać ich funkcje będzie procentować w pracy zarówno programisty jak i administratora. Finalnie uprości pracę, skróci czas potrzebny na jej wykonanie czy pozwoli na lepsze zabezpieczenie danych znajdujących się w bazie. Również język SQL ma się dobrze, stale rozwija i wygląda na to, że zostanie z nami jeszcze przez dłuższy kawałek czasu. Znajomość jego nowych możliwości pozwoli na zlecanie coraz bardziej skomplikowanych zadań bazie danych. W końcu po to ją stworzono - aby przetwarzała dane. Tworzywem spajającym język SQL i motor bazy danych w jeden sprawny mechanizm jest wiedza o tym jak projektować relacyjne bazy danych.

Z moich obserwacji wynika, że internet przesycony jest receptami i sposobami jak coś zrobić. Jak zainstalować, skonfigurować, naprawić. Mało jest natomiast materiałów ilustrujących jak coś działa i wyjaśniających po co zostało stworzone. Uważam, że zrozumienie działania mechanizmów bazy danych ma istotne znaczenie gdy chcemy jej używać. Od podziału danych na tabele, ich rodzaj, dobór typów dla kolumn, ilość i rodzaj indeksów po sposoby i ilość zaszycia w bazie danych logiki biznesowej.

Z moich doświadczeń wynika, że bezcennym 'informatykiem' na rynku pracy jest człowiek, który oprócz wiedzy technicznej posiada umiejętności miękkie. Asertywność, komunikacja, radzenie sobie z krytyką, stresem czy ogólnie emocjami - żeby wymienić choć garść. O tym również chcę publikować bo są to tematy z którymi mierzymy się na co dzień. A przydatne sa również w życiu prywatnym. Kto nie potrafił odmówić szefowej/szefowi, koleżance/koledze w pracy ? Kto nie stresował się przed wejściem nowego oprogramowanie na produkcję ? Kto nie spędził bezsennej nocy na naprawianiu awarii ? Czasem własnoręcznie spowodowanej ;-) Kto nie mierzył się ze stresem przed konsekwencjami ?

Zapraszam i zachęcam Cię do rozmowy co z powyższych ma dla Ciebie wartość. Jaka forma prezentacji przemawia do Ciebie najbardziej - artykuł czy wideo ? A może podcast ? A może ...
A może jest coś czego nie wymieniłem, a jest dla Ciebie najważniejsze ?

Jestem wdzięczy za każdy kontakt - pod postem czy w wiadomości prywatnej.

Zdjęcie dzikiego kota bo lubię koty i lubię jak zwierzęta są wolne. A trochę śniegu bo ostatnio zimy nam go skąpią ;-)

#dba4dev #marcinbadtke