Administratorzy dzielą się na tych co robią backupy i tych którzy je będą robić.

Pewnie jako administrator dość często słyszysz ten cytat. Nie wiadomo kto go wymyślił ale ma zupełną rację. Jeśli nie robisz kopii zapasowych, założę się że niebawem będziesz je robić. Wielokrotnie ratują nas z opresji. Nie o tym jednak będzie dzisiejszy artykuł, a właśnie o tym jak z takiej kopii zapasowej nie skorzystać. Jakiś czas temu miałem pewną przygodę z bazami danych. Wykonywałem dość oczywistą czynność administracyjną, przenosiłem pliki logów na inny serwer. Niestety pliki logów powiedzmy to “zawieruszyły” się i po odpaleniu instancji miałem dość dziwny komunikat a baza była w statusie Recovery Pending no cóż zdarza się. Mam backup nie martwię się ale nie chcę żeby system był offline dłużej niż to jest naprawdę konieczne. Co tu zrobić? W pierwszym odruchu jednak zalogowałem się do systemu backupowego, jednak zrezygnowałem na rzecz bardziej wyszukanego rozwiązania. Nie należę do tych co łatwo się poddaje. Backup jest i sobie poczeka na lepsze czasy.

Mała uwaga przed dalszym czytaniem

Przedstawione scenariusze zostały zreprodukowane na potrzeby tej prezentacji, każdy przypadek należy rozwiązywać indywidualnie. Autor nie ponosi odpowiedzialności za szkody wyrządzone na środowiskach czytelników bloga, a przedstawiony materiał służy wyłącznie celon edukacyjnym. .

Od czego tu zacząć, co to jest ten plik LDF?

Jest to plik dziennika transakcji. Znajdują się w nim wszystkie potrzebne informacje do utrzymania transakcyjności bazy danych. Więc poniższe procedury nie zadziałają w przypadku kiedy baza nie zamknęła się prawidłowo a potem w wyniku tej awarii plik takiego dziennika uległ uszkodzeniu. Więc jeśli zamknęliśmy bazę danych prawidłowo istnieje duża szansa na to, że nasze operacje przebiegną z pełnym sukcesem.

Od czego zacząłem i czego nie polecam?

Zacząłem od najprostszej rzeczy jaka przyszła mi do głowy uruchomię sprawdzanie bazy danych przy pomocy csbcc checkdb, to jednak utwierdziło że mam uszkodzoną bazę danych. Cóż nie poddaję się i próbuję dalej. Jak nie wiem jak zrobić przechodzę do czytania instrukcji i metodą prób sprawdzam każdą opcję. Żartuję, jakbym nie wiedział co robię tylko eksperymentował na środowisku klienta to bym czuł się jak student medycyny uczący się podczas operacji na otwartym sercu bez asysty kardiologa. Jednak zajrzeć do dokumentacji nie zaszkodzi gdzie możemy zobaczyć że mamy opcję REPAIR_ALLOW_DATA_LOSS. Należy uważać ponieważ część danych może zostać usunięta.

Żeby wykonać sprawdzenie bazy danych należy przełączyć bazę danych w tryb EMERGENCY. W innych przypadkach będziemy dostawać dziwne błędy i nie będziemy mogli odbudować pliku logów.

Tutaj mała ciekawostka. Jeśli uruchomimy bazę w trybie emergency będziemy mogli zajrzeć do bazy, a nawet do danych. Co osobiście było dla mnie to miłym zaskoczeniem, ponieważ nie zawsze mam takie przygody z bazami

Możemy przystąpić do naprawy. W tym przypadku nic trudnego, uruchamiamy DBCC CHECKDB i czekamy jak się zakończy. W moim przypadku polecenie zostało uruchomione poprawnie i nie zwróciło żadnych błędów. Jeśli błędy wystąpią należ zweryfikować i ewentualnie użyć wcześniej wykonanej kopii bezpieczeństwa.

Kolejnym krokiem jest przełączenie bazy w tryb ONLINE, a potem w tryb MULTI_USER. Robimy jeszcze DBCC CHECKDB i wykonujemy pełny backup to tak dla świętego spokoju.

Jest jeszcze jedna metoda…

Kiedyś jak byłem młodym administratorem to robiłem dziwne rzeczy i teraz przyszedł mi do głowy pomysł a dlaczego nie sprawdzić czy w tym przypadku nie zadziała. Patent polega na tym żeby podłączyć bazę z tylko plikiem danych.

Zacznijmy jednak od początku. Przed przystąpieniem do pracy, musimy odłączyć istniejącą bazę danych. Może nie być to proste i na pewno nie będzie. Nie możemy odłączyć bazy danych która jest w trybie Recovery pending Pending, żeby to wykonać należy najpierw przełączyć bazę danych w tryb emergency, a następnie odłączyć.

Jeśli już skasowaliśmy i nie mamy bazy danych możemy spokojnie podłączyć odzyskiwaną bazę danych. Do tego celu możemy użyć kreatora przypadku którego w miejscu logów będziemy mieli puste miejsce (starsze wersje Management Studio pokazywały że takiego pliku nie ma). Warto korzystać z kreatora ponieważ po podłączeniu pliku podstawowego pokazuje wszystkie metadane i wiemy czego może nam jeszcze brakować. W tym miejscu nie przechodzimy dalej, ale generujemy skrypt.

Podsumowując

Trudno określić która metoda jest lepsza, każda jednak sprowadza się do tego, że jest utworzony nowy plik logu. W moim przypadku zadziałało, ale nie wiem czy w przypadku baz danych, gdzie jest przeprowadzana duża ilość transakcji to się uda. Dlatego przed przystąpieniem do prac warto jednak poświęcić trochę czasu na to żeby wykonać tą naszą kopię bazy przed pracami. Może się nie przyda ale nam nie zaszkodzi. Zawsze to będziemy mogli prowadzić nasze prace spokojniej.

Testy przeprowadzone na wersji Microsoft SQL Server 2017