Diagnozowanie błędu Microsoft SQL Server 9001: Dziennik bazy danych jest niedostępny

W ciągu weekendu uruchomiona przeze mnie witryna przestała działać, rejestrując następujący błąd w Podglądzie zdarzeń za każdym razem, gdy żądanie jest wysyłane do witryny:

Identyfikator zdarzenia: 9001

Dziennik bazy danych „ nazwa bazy danych ” jest niedostępny. Sprawdź dziennik zdarzeń pod kątem powiązanych komunikatów o błędach. Rozwiąż wszelkie błędy i uruchom ponownie bazę danych.

Witryna jest hostowana na dedykowanym serwerze, więc mogę połączyć się z serwerem RDP i przekopać się. LDFPlik bazy danych istnieje w C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATAfolderze, ale stara się wykonywać żadnej pracy z bazy danych z wynikami Management Studio w oknie dialogowym raportowania ten sam błąd - 9001: Log do bazy danych nie jest dostępna ...

Ten błąd pojawia się po raz pierwszy i od ponad dwóch lat hostuję tę witrynę (i inne) na tym dedykowanym serwerze internetowym.

Rozumiem, że ten błąd oznacza uszkodzony plik dziennika. Udało mi się przywrócić witrynę do trybu online, odłączając bazę danych, a następnie przywracając kopię zapasową sprzed kilku dni, ale obawiam się, że ten błąd wskazuje na bardziej złowieszczy problem, a mianowicie awarię dysku twardego.

Wysłałem e-mailem wsparcie do firmy hostingowej i oto była ich odpowiedź:

Wydaje się, że w Dzienniku zdarzeń nie ma żadnych innych przyczyn przyczyny, więc możliwe jest, że dziennik został uszkodzony. Obecnie zasoby pamięci wynoszą 87%, co również może mieć wpływ, ale jest mało prawdopodobne.

Czy dziennik może po prostu „zostać uszkodzony?”

Moje pytanie: jakie kolejne kroki powinienem podjąć, aby zdiagnozować ten problem? Jak mogę ustalić, czy rzeczywiście jest to problem sprzętowy? A jeśli tak, to czy są jakieś opcje oprócz wymiany dysku?

Dzięki

Ponad 99% problemów z uszkodzeniem bazy danych dotyczy systemu pamięci masowej. Połowa pozostałych problemów jest spowodowana złą pamięcią, a druga połowa to błędy w SQL Server.

Prawdopodobnie jest to problem z przechowywaniem.

Jeśli to się powtórzy, uruchom DBCC CHECKDB dla bazy danych, a to dostarczy ci więcej informacji o uszkodzeniu, a jeśli problem można naprawić bez przywracania. Prawdopodobnie będziesz musiał przełączyć bazę danych w tryb awaryjny, aby uruchomić checkdb z bazą danych.

Zużycie pamięci wynoszące 87% nie ma nic wspólnego z problemem. SQL Server uruchomi pamięć do 100% (lub blisko niej) zgodnie z projektem.

Udało mi się to rozwiązać, przełączając bazę danych w tryb offline w Management Studio, a następnie natychmiast przywracając ją do trybu online. dbcc checkdbzgłosił błędy, które zostały rozwiązane po wykonaniu tej czynności. Nie mogę powiedzieć, dlaczego to działało tylko, że zrobił pracę.

Ostatnio miałem ten problem i po wielu badaniach wydaje się być powszechny, gdy baza danych jest ustawiona na AUTO ZAMKNIĘCIE. Ustawiłem wszystkie bazy danych na AUTO CLOSE = FALSE. Zaczęło się od jednej bazy danych, a następnie do dwóch, a następna była na wszystkich. Po prostu ponownie uruchomiłem usługę wystąpienia programu SQL Server zamiast przywracania baz danych. Innym sposobem na rozwiązanie tego problemu jest przełączenie problematycznej bazy danych w tryb offline i przełączenie jej z powrotem do trybu online.

MS SQL przełączy dzienniki bazy danych, której dotyczy problem, w tryb offline, aby uniknąć uszkodzenia bazy danych. Dlatego pojawia się błąd 9001.

Gdy przejdziesz do bazy danych, której dotyczy problem, offline / online, MS SQL włączy dzienniki bazy danych, której dotyczy problem, dopóki błąd nie pojawi się ponownie.

Innym sposobem rozwiązania tego jest zmiana opcji Auto_Close na OFF

http://sqlmag.com/blog/worst-practice-allowing-autoclose-sql-server-databases

Zgaduję / mam nadzieję, że masz nalot na dysk dla twojego serwera SQL. jeśli podejrzewasz problemy ze sprzętem, pierwszą rzeczą, którą chciałbym zrobić, to uruchomić narzędzia do konserwacji / diagnostyki.

drugą rzeczą (prawdopodobnie równolegle, jeśli możesz) jest uruchomienie dbcc checkdb w bazie danych (być może również w bazach systemowych).

Ok, pierwszy krok, wykonaj kopię zapasową dziennika i plików mdf na zupełnie innym dysku. SZYBKO! (kopia pliku)

Spróbuj także wykonać pełną kopię zapasową bazy danych.

Następnie spróbuj wykonać następujące czynności. Korzystając z bieżącej bazy danych, odłącz ją, jeśli możesz, a następnie usuń plik dziennika lub przenieś go do zupełnie innej lokalizacji na dysku. Następnie ponownie podłącz bazę danych, a pojawi się ona w gui z plikiem dziennika, kliknij usuń (lub usuń) dla pliku dziennika, aby się nie pojawił, a następnie kliknij OK. Zasadniczo dołączenie go bez dziennika zmusi go do utworzenia pliku dziennika dla bazy danych w domyślnej lokalizacji.

Daj mi znać.

Tak, też dostałem ten sam problem, dotyczył błędu tempDb 9001, tzn. Log niedostępny. Uruchomiliśmy ponownie usługi i wszystko było w porządku.

Problemem był SAN lub problem z pamięcią, podczas gdy operacja zapisu we / wy nie była w stanie zapisywać przez ponad 15 sekund.

Wczoraj otrzymałem ten sam błąd „dziennik bazy danych '%' nie jest dostępny. Błąd krytyczny 9001, msg 21. Proszę skontaktować się z administratorem” -

Obejście - sprawdziłem „TempDB”, ale nie był dostępny podobnie jak pozostałe systemowe bazy danych. Następnie przed przejściem do opcji naprawy po prostu ponownie uruchomiłem usługi SQL dla tego wystąpienia i problem został rozwiązany :) :)

Widziałem to, gdy nie ma miejsca na dysku dla rozszerzenia dziennika; czy możesz sprawdzić, czy na C: \ jest wystarczająco dużo miejsca i czy twoje dzienniki są zarządzane, tj. tworzenie kopii zapasowej, jeśli jesteś w trybie pełnego odzyskiwania?

Chciałbym przenieść twoje pliki ldf (i mdf) z woluminu rozruchowego, jeśli masz taką opcję.