Zidentyfikuj główną przyczynę, dlaczego baza danych utknęła w stanie PRZYWRACANIA

Wiem, że są pytania, które rozwiązują problem zatrzymania bazy danych RESTORINGi wykorzystały te rozwiązania do ręcznego przywrócenia bazy danych do trybu online, ale mój scenariusz jest nieco inny.

Mam automatyczne przywracanie za pomocą skryptów Powershell, które przywracają kopię produkcyjną do instancji DEV. Skrypty pozostają niezmienione przez około rok, a czasami proces przywracania kończy się, ale przywrócona baza danych utknęła w RESTORINGstanie (czasami skrypt działa dobrze, a czasem tak się nie udaje).

Za każdym razem, gdy ręcznie ponownie uruchomię proces, działa lub jeśli ręcznie przywracam bazę danych z interfejsu użytkownika SSMS lub za pomocą T-SQL, kończy się bez problemu.

Znalazłem odpowiedzi, które zalecały uruchomienie CHECKDBna przywróconej bazie danych, ale nic nie wyszło jako przyczyna tego problemu.

Ponieważ skrypty przywracają PEŁNĄ kopię zapasową bazy danych i korzystają z "WITH RECOVERY"opcji, próbuję dowiedzieć się, co może zatrzymać proces przywracania, chociaż w rzeczywistości przywracam go "WITH RECOVERY".

Wszelkie sugestie są bardzo mile widziane, ponieważ od czasu do czasu próbuję zrozumieć, dlaczego tak się dzieje.

Bardzo chciałbym rozwiązać podstawową przyczynę problemu, a nie leczyć objawy, czyli ponowne ręczne przywrócenie bazy danych.

Aktualizacja:

Polecany Github Gist jako @Brent - tutaj .

— Radu Gheorghiu
źródło

Możesz uzyskać odpowiedź z dzienników programu SQL Server i przeglądarki zdarzeń, czy sprawdziłeś? Czy zdarza się problem z przestrzenią, ponieważ może to spowodować zablokowanie stanu przywracania. Czy weryfikujesz integralność kopii zapasowej przed przywróceniem? Jaki jest twój podsystem pamięci

— Shanky

@Shanky Rzucę okiem na te, chociaż nie mam bezpośredniego dostępu do tych informacji (muszę się zaznajomić z administratorem SAN). Integralność kopii zapasowej jest sprawdzana zarówno podczas tworzenia kopii zapasowej, jak i podczas zapisywania na dysk.

— Radu Gheorghiu

Co mówi dziennik błędów SQL Server? Spróbuj uruchomić EXEC sys.xp_readerrorlog 0,1;- poszukaj komunikatów w czasie operacji przywracania.

— Max Vernon

@MaxVernon Dziennik błędów od momentu przywrócenia . Sprawdziłem komunikat o błędzie i wydaje się, że zaleca sprawdzanie miejsca na dysku, które jest dużo. Kopię głębiej i zobaczę, co mogę znaleźć, ale na pierwszy rzut oka może się to znacznie rozwinąć i sprawić, że spojrzę na wiele rzeczy .

— Radu Gheorghiu

Brzytwa Ockhama sugeruje zacząć od oczywistego:

Jeśli skrypt czasami pozostawia bazę danych w stanie przywracania, debuguj skrypt.

Zacznij od zalogowania się w tabeli lub pliku. Następnie, gdy baza danych zostanie przywrócona, przejdź do swoich dzienników, aby zobaczyć, co poszło nie tak. (Jeśli chcesz mieć drugą grupę oczu od społeczności, spróbuj przesłać swój skrypt jako Github Gist, ale pamiętaj, że im większy, tym trudniej jest wykryć błędy).

Jeśli nie chcesz tego robić, spróbuj uruchomić profil Profiler lub Extended Events, aby śledzić zdarzenia przywracania, ale ostrzegaj - jest to o wiele trudniejsze niż się wydaje. (Przeczytaj komentarze do tego wpisu, aby uzyskać więcej pomysłów czytelników, które wypróbowali i nie powiodło się).

— Brent Ozar
źródło

Dzięki Brent, to są dobre wytyczne! Wrócę z aktualizacją, gdy będę miał więcej informacji, na razie DB będzie w porządku, zobaczę, co się stanie, gdy proces uruchomi się jutro rano.

— Radu Gheorghiu