Główna baza danych jest uszkodzona, instancja się nie uruchamia - jakie są moje opcje?

Wsparcie! Moja główna baza danych jest uszkodzona, nie mogę nawet uruchomić instancji SQL w trybie online! Jakie mam opcje, aby odzyskać mój serwer?

Mam kopię zapasową wzorca, ale strona MSDN „Przywracanie wzorcowej bazy danych” prosi mnie o uruchomienie instancji w trybie pojedynczego użytkownika, czego nie mogę zrobić!

(Uwaga: pozostawiam to pytanie nieokreślone co do wersji SQL, aby było ono szerszym odniesieniem. Istnieją pewne podobne pytania dotyczące DBA.SE, ale żadne z nich nie dotyczy uruchomienia serwera.)

Oto kilka sposobów, które zbadałbym. Nie rób wszystkich z nich (niektóre z nich są różnymi technikami, aby osiągnąć ten sam cel), ale warto rozważyć:

1. Sprawdź bezpośrednio dziennik błędów SQL

Przejdź bezpośrednio do folderu zawierającego dzienniki błędów SQL i załaduj najnowsze ERRORLOGdo notatnika, aby uzyskać więcej informacji o tym, dlaczego wystąpienie SQL nie zostanie uruchomione. Być może okaże się, że problem w ogóle nie dotyczy głównej bazy danych.

2. Spróbuj uruchomić instancję w trybie pojedynczego użytkownika

Oto pełna lista opcji uruchamiania serwera SQL , w tym -m(tryb pojedynczego użytkownika) i -f(tryb minimalnej konfiguracji). Inne opcje pozwalają określić ścieżkę do głównej bazy danych, jeśli taki jest problem.

Jeśli możesz uruchomić instancję, wykonaj czynności opisane w artykule MSDN, który podłączyłeś w celu przywrócenia głównej bazy danych, lub w tym szczegółowym przewodniku Thomasa LaRocka .

Jeśli inna aplikacja zawsze pobiera połączenie z jednym użytkownikiem, zanim będzie to możliwe, najpierw wyłącz agenta SQL, aby się nie uruchamiał. Po drugie, zapoznaj się z pomysłami na to pytanie dotyczącymi używania -m"Application Name"parametru do określania nazwy aplikacji.

3. Przywróć masterdo innej instancji i skopiuj jej pliki

Znalazłem tylko jedną wzmiankę o tej nieudokumentowanej technice, ale z powodzeniem wykorzystałem ją w ostatni weekend, więc może warto spróbować.

Jeśli nie możesz uruchomić instancji w trybie pojedynczego użytkownika, ale masz inną instancję SQL z uruchomioną dokładnie tą samą wersją i kompilacją , spróbuj przywrócić ostatnią znaną dobrą kopię zapasową głównej bazy danych z martwego serwera do drugiej instancji:

• Przywróć jako inną nazwę, oczywiście ( master_please_god_let_this_work), WITH MOVEabyś nie zastępował masterswojego dobrego serwera
• Restore WITH NORECOVERY. Nie jestem pewien, czy jest to konieczne, ale sprawiło, że poczułem się lepiej, ponieważ wiedziałem, że drugi serwer nie zmieni niczego w przywróconym systemie głównym
• Ustaw tryb offline: ALTER DATABASE [master_please_god_let_this_work] SET OFFLINE
• Skopiuj przywrócone pliki MDF i LDF z dobrego serwera na martwy serwer
• Zmień nazwę plików master.mdfi mastlog.ldf, jeśli to konieczne, aby zastąpić złe pliki główne przywracanymi wersjami
• Trzymaj kciuki i rozpocznij instancję
• Opcjonalnie: wykonaj świeżą operację przywracania systemu głównego na odnowionym serwerze. Nie jestem pewien, czy jest to konieczne, ponieważ byliśmy bardzo ostrożni, aby się nie zmieniać master.

4. Odbuduj systemowe bazy danych

Jeśli nie masz innej instancji z tą samą wersją lub nie masz doświadczenia z korzystaniem z nieudokumentowanej procedury wymienionej w punkcie 3 lub jeśli nie masz kopii zapasowych master( dlaczego nie masz kopii zapasowych? ), możesz odbudować systemowe bazy danych SQL z oryginalnego dysku instalacyjnego :

Setup.exe /ACTION=REBUILDDATABASE /...

Po zakończeniu możesz wykonać czynności opisane wcześniej, aby przywrócić dane masterz ostatniej dobrej kopii zapasowej. Konieczne będzie również przywrócenie ostatniej kopii zapasowej, msdbaby zachować wszystkie zadania, harmonogram zadań i historię zadań.

5. Przywróć wszystkie bazy danych USER do nowej (lub istniejącej) instancji SQL

Jeśli masz już inną istniejącą instancję (odpowiednia wersja SQL, wystarczająca ilość miejsca na dysku), prawdopodobnie zacznę przywracanie bazy danych od najnowszych kopii zapasowych, pracując nad innymi krokami rozwiązywania problemów powyżej, na wypadek, gdyby były potrzebne.

Jeśli nowa (lub ponownie zainstalowana) instancja ma dostęp do tego samego dysku, znacznie szybciej jest po prostu dołączyć je jako nowe bazy danych:

CREATE DATABASE foo 
ON (FILENAME = 'D:\data\foo.mdf'),
   (FILENAME = 'D:\data\foo_log.ldf')
FOR ATTACH;

6. Wykonaj ponownie wszelkie zmiany w master

Po pomyślnym przywróceniu master(za pomocą dowolnej z powyższych technik) musisz zbadać wszelkie zmiany, które mogły zostać utracone, jeśli zostały wprowadzone po właśnie przywróconej kopii zapasowej:

• Zmiany bezpieczeństwa
• Nowe bazy danych (pliki nadal będą na dysku, wystarczy je dołączyć)
• Ustawienia całego serwera

Nie ma magicznego sposobu, aby je znaleźć, musisz wrócić do ścieżki dokumentacji własnej firmy, aby wprowadzić zmiany tego rodzaju, jeśli takie masz.

Chciałem tylko dodać potencjalny problem i rozwiązanie, na które właśnie wpadłem - miałem podobną sytuację podczas nieudanej aktualizacji zbiorczej (SQL2016 CU12) oraz komunikaty w przeglądarce zdarzeń i dzienniku błędów, w których powiedział: „Nie można odzyskać głównej bazy danych. SQL Server jest nie można uruchomić. Przywróć wzorzec z pełnej kopii zapasowej, napraw go lub odbuduj. ”, jednak w końcu odkryłem, że jeśli ponownie przestawię plik wykonywalny CU, wykryje stan uaktualnienia jako„ Niecałkowicie zainstalowany ”i pozwoli mi po prostu uruchomić zaktualizuj ponownie, po czym zakończy się powodzeniem, a główna baza danych i wszystkie inne otworzyły się bez problemów.