Baza danych uruchamia się zawsze w trybie odzyskiwania

Za każdym razem, gdy ponownie uruchamiam serwer, baza danych jest zawsze w trybie odzyskiwania, a jego normalne działanie zajmuje około 20 minut. Dzieje się tak zawsze i tylko po ponownym uruchomieniu serwera, więc mam kilka pytań ...

1. Powiedziano mi, że może to być spowodowane dużym plikiem dziennika? Czy to może być poprawne? Jeśli nie, to jakie mogą być inne przyczyny?
2. Muszę zmniejszyć przestrzeń pliku dziennika, aby zapobiec odzyskiwaniu. Co jest lepsze: zmniejszanie się lub obcięcie?
3. Jak zmniejszyć lub skrócić plik dziennika / bazę danych, aby zmniejszyć rozmiar? Jaka jest składnia?

Obecnie używam Microsoft SQL Server 2008.

Mam ten sam problem i wydaje mi się, że go rozwiązałem, ale nie byłem w stanie w pełni go przetestować, aby potwierdzić.

Uważam, że problemy są związane z liczbą plików VLF, które masz w pliku dziennika, a nie z ich rozmiarem. Jeśli masz duży plik dziennika, prawdopodobne jest, że urósł on organicznie poprzez zdarzenia związane z automatycznym wzrostem i że nie był to zamierzony wzrost. W takim przypadku możesz mieć tysiące plików VLF w plikach dziennika.

Oto zapytanie, aby zobaczyć, ile masz VLF, których użyłem tutaj :

    Create Table #stage(
    FileID      int
  , FileSize    bigint
  , StartOffset bigint
  , FSeqNo      bigint
  , [Status]    bigint
  , Parity      bigint
  , CreateLSN   numeric(38));

Create Table #results(
    Database_Name   sysname
  , VLF_count       int 
);

Exec sp_msforeachdb N'Use ?; 
            Insert Into #stage 
            Exec sp_executeSQL N''DBCC LogInfo(?)''; 

            Insert Into #results 
            Select DB_Name(), Count(*) 
            From #stage; 

            Truncate Table #stage;'

Select * 
From #results
Order By VLF_count Desc;

Drop Table #stage;
Drop Table #results;

Aby uzyskać dodatkowe wyjaśnienie, jakie są VLF, zobacz ten link .

Uważam, że problem polega na tym, że przy tak dużej liczbie VLF serwer SQL zajmuje dużo czasu, aby ocenić ich stan, a następnie wyciągnąć bazę danych z odzyskiwania. Jeśli zmniejszysz plik dziennika do najmniejszego możliwego rozmiaru, często rozmiar pierwszego pliku VLF, który został utworzony w pliku dziennika, możesz natychmiast celowo go powiększyć, aby w ten sposób utworzyć odpowiednią liczbę plików VLF (mniej niż 16).

Po zakończeniu tej operacji uważam, że będzie można znacznie szybciej odzyskać bazę danych.

Po rozwiązaniu własnych problemów z VLF nie miałem okazji przetestować przełączania awaryjnego naszych instancji produkcyjnych, więc byłbym bardzo ciekawy, czy możesz potwierdzić, że jest to podstawowa przyczyna problemu. Eksperymentalnie widziałem, jak dużo czasu potrzeba, aby wyjść z przywracania w naszym środowisku inscenizacji dramatycznie zmniejszone z tego powodu, więc mam nadzieję, że o to chodzi.

Z tego artykułu MSDN :

Długotrwałe niezaangażowane transakcje wydłużają czas odzyskiwania dla wszystkich typów punktów kontrolnych.

Zasadniczo nie jest zalecane uruchamianie jakiegokolwiek pliku skurczowego DBCC w produkcyjnych bazach danych. Również zachowanie obcinania dziennika zmieniło się z wcześniejszych wersji na 2008 (dzięki @Edward) - na tego bloga :

Dziennik kopii zapasowej z trucate_only nie jest już obsługiwany w SQL 2008. Jeśli twoja baza danych jest w trybie pełnego lub pełnego odzyskiwania, zaplanuj tworzenie kopii zapasowej T-Log w regularnych odstępach czasu, aby zachować t-log w formie.

Jeszcze raz wspomnę, jak często tworzysz kopie zapasowe bazy danych? Zwykle regularne kopie zapasowe najlepiej „zarządzają” rozmiarem dziennika.

Zmniejszenie rozmiaru dziennika transakcji online może rozwiązać problem, tj. Przyspieszyć przejście bazy danych do trybu online, ale zanim to zrobisz, powinieneś pomyśleć o przywróceniu po awarii. Pamiętaj, że jeśli używasz prostego modelu odzyskiwania, przywrócenie do określonego momentu nie będzie możliwe. Z drugiej strony, jeśli korzystasz z pełnego modelu odzyskiwania, najlepszym sposobem na utrzymanie rozmiaru dziennika transakcji online jest tworzenie kopii zapasowej dziennika transakcji na regularnych podstawach (zaplanuj).

Obcinanie dziennika transakcji nie zwalnia fizycznego miejsca na dysku twardym, pozwala tylko SQL Serverowi ponownie wykorzystać to miejsce dla transakcji, które miały miejsce od ostatniego CHEKPOINT (od ostatniego utworzenia kopii zapasowej dziennika transakcji).

Jeśli zmniejszysz bazę danych, zmniejszysz rozmiar plików. Aby zmniejszyć bazę danych MyDB o 15 procent:

DBCC SHRINKDATABASE (MyDB, 15); UDAĆ SIĘ