Jak już to się nam przydarzyło że baza danych uległa zniszczeniu, odtworzyliśmy już ją do punktu w czasie i nadal brakuje nam danych nie musimy załamywać rąk, to się zdarza, a jeśli Tobie się nie zdarzyło to jest duże prawdopodobieństwo że kiedyś będziesz mieć takie wyzwanie. Dlaczego to piszę? A to że miałem kiedyś sytuację, że był uszkodzony plik danych, nie można było nic z nim zrobić, musiałem odtworzyć całą bazę danych do punktu w czasie ale część danych, która była wprowadzona po wykonaniu kopii pliku logu została utracona. Niestety jak wiemy nie da się wykonać odtwarzania z takiego pliku więc musiałem przełknąć porażkę, a użytkownicy musieli wprowadzić jeszcze raz te dane. Dobrze, że tych danych nie było dużo więc sprawa rozeszła się po kościach.

Jeśli nie masz środowiska testowego do wykonywania poniższych operacji należy upewnić się czy masz kopię bezpieczeństwa, autor nie odpowiada za szkody wyrządzone przez  czytelników bloga na swoich środowiskach. Moje wszystkie zabawy są wykonywane w miejscach specjalnie do tego przygotowanych. Każdy przypadek należy traktować oddzielnie.

Dzisiaj mógłbym postąpić trochę inaczej. Przeszukując internet do poprzedniego artykułu natknąłem się na pewne narzędzie o którym chciałbym dzisiaj napisać.  Jest to program ApexSQL Log (klikając na nazwę przeniesiesz się na stronę producenta) a właściwie jeden z wielu produktów firmy ApexSQL, a ja w swoim przypadku korzystam z wersji testowej.

Na początek musimy pobrać i zainstalować oprogramowanie. Będziemy musieli zainstalować zarówno wersję serwerową jak i wersję kliencką. Instalacja jest naprawdę banalnie prosta więc pominę tą część i przejdę do następnej.

Po uruchomieniu klienta pierwszą rzeczą jaką zobaczymy to jest ekran logowania do odzyskiwanej instancji.

Ashampoo_Snap_niedziela, 6 maja 2018_08h57m02s_001_

To był prosty krok 🙂 Program pobierze sobie informację z bazy danych i przedstawi nam w kolejnym kroku możliwości odtwarzania.

Tutaj mamy do dyspozycji kilka źródeł “odtwarzania”. Od tych podstawowych jakim jest backup zimny, backup transact logów (o ile wykonujemy) i to co nie dawało mi ostatnio spokoju aktywny plik logów z uszkodzonej bazy danych. Zawsze chciałem wiedzieć czy uda się dobrać do takiego pliku i sprawdzić czy możemy jeszcze odzyskać informację o transakcjach jakie były od ostatniego backupu logów do awarii.

OK. Ja wybrałem nieszczęsny log bazy danych. Kolejnym krokiem jest wybór w jaki sposób ma być przedstawiony wynik. 

nie wiem czy jest sens omawiania kolejnych opcji programu. Jeśli dotarłeś do tego miejsca to myślę że wiesz co robisz, a ja nie muszę specjalnie się rozpisywać.

Ok ja wybrałem trzecią opcję. Zostało nam jeszcze jedno przed rozpoczęciem pracy przez program, to jest jaki zakres czasu ma być przetworzony. Czasami musimy sprawdzić tylko część danych i nie ma sensu zaznaczania przetwarzania wszystkiego.

Program teraz przetworzy cały plik logów tak jak na rysunku poniżej, mówiąc szczerze nie sądziłem że mam w tak małej instancji tyle przetworzonych danych, znaczy samych insertów.Na sam koniec mamy piękny raport w tabelce do przejrzenia. Możemy wybrać sobie poszczególną transakcję, sprawdzić jak wyglądał kod samego zapytania, a jeśli wybraliśmy opcję Redo mamy także kod który wycofa daną transakcję z bazy.

Ze względu na fakt że używam wersji demo i moje dane, nie mogę przedstawić wszystkich opcji programu. Dla mnie jest on bardzo fajny i jeśli miałbym kiedyś użyć jakiegoś programu to na pewno bym się zastanowić właśnie nad tym programem. Oprócz samego odtwarzania danych transakcji z bazy widzę dla tego programu wiele innych zastosowań np. sprawdzenie pod kontem audytowym, albo kto zmienił daną wartość (o ile wiemy kiedy to się stało).

Mam nadzieję, że tekst był pomocny i zapraszam do lektury innych moich artykułów.