Miałem już ten problem.
- Masz dużą bazę danych i mały dysk dziennika. Chcesz się zreorganizować (z różnych powodów).
- Gdy spróbujesz to zrobić na dużej pofragmentowanej tabeli, dziennik zapełni się, dopóki dysk dziennika nie zostanie zapełniony, a następnie polecenie zostanie przerwane.
- Jeśli jest w trybie prostym, inne transakcje mogą zakończyć się niepowodzeniem, dopóki dziennik nie zostanie wyczyszczony w następnym punkcie kontrolnym, a jeśli jest w trybie pełnym, inne transakcje mogą zakończyć się niepowodzeniem do momentu utworzenia kolejnej kopii zapasowej dziennika. Czop!
- Jeśli jesteś w trybie pełnym, zwiększasz częstotliwość tworzenia kopii zapasowej dziennika, ale to nie pomaga uniknąć problemu, ponieważ reorganizacja odbywa się w ramach transakcji niejawnej, dziennik nie jest czyszczony, dopóki transakcja nie zakończy się, nie zostanie przerwana lub zatrzymana.
- I NAPRAWDĘ chcesz, aby reorganizacja przebiegła do końca.
Jest to trochę sprzeczne z intuicją, ponieważ wiesz, że jeśli przerwiesz reorganizację, możesz kontynuować od miejsca, w którym została przerwana, po prostu przerwanie dokonuje transakcji, a nie wycofuje.
Oto co robisz. Jest trochę długi, ale prosty.
- Rozwiń wstępnie plik dziennika do stosunkowo dużego rozmiaru, ale nie maksymalnego. Zasadniczo chcesz zostawić wystarczająco dużo miejsca na użyteczne prace, a także na niektóre niewielkie wzrosty, jeśli wystąpią, aby normalne operacje się nie zatrzymały.
- Utwórz zadanie, aby uruchomić reorganizację indeksu („Reorganizuj”).
Utwórz alert WMI agenta („Reorganizuj zawór nadmiarowy”) pod warunkiem wydajności.
- Obiekt: SQLServer: Bazy danych
- Licznik: wykorzystano dziennik procentowy
- Instancja: (Twoja duża nazwa bazy danych)
- Alarmuj, jeśli licznik wzrośnie powyżej: 80
- Odpowiedź: Wykonaj zadanie („Reorganizuj czek”)
Utwórz pracę („Reorganizuj czek”)
- W zadaniu sprawdź msdb.dbo.sysjobactivity, aby sprawdzić, czy uruchomione jest zadanie „Reorganizuj”. A jeśli to jest ...
- Zatrzymaj zadanie i odpytuj, aż się zatrzyma. Może to potrwać kilka sekund.
- (Jeśli jesteś w trybie pełnym) Uruchom zadanie tworzenia kopii zapasowej dziennika i potwierdź jego zakończenie.
- Sprawdź dokładnie sys.dm_os_performance_counters, że licznik wolnego miejsca w dzienniku zmniejszył się poniżej progu.
- Rozpocznij zadanie „Reorganizuj”.
Sprawdź to wszystko gdzieś, nawet w piaskownicy programistycznej, aby upewnić się, że działa poprawnie przed przyklejeniem go do serwera produkcyjnego.
Zobaczysz, że zadanie „Reorganizacja” rozpoczyna się i zaczyna wypełniać dziennik. Gdy dziennik zapełni się w procentach, uruchamia alarm WMI (w ciągu około 30 sekund), który uruchamia inne zadanie, w którym widać, że zadanie „Reorganizacja” jest uruchomione, a więc prawdopodobnie jest z winy. Następnie zatrzymuje „Reorganizację”, wykonuje kopię zapasową, potwierdza, że ilość wolnego miejsca w dzienniku powróciła do rozsądnej wartości, a następnie ponownie rozpoczyna zadanie „Reorganizacja”, które rozpocznie od miejsca, w którym zostało przerwane.
Tak więc, jak możesz, powodem, dla którego wstępnie przeskalowałeś dziennik do rozsądnej wartości w tym scenariuszu, jest zmniejszenie liczby wzrostu / wyzwalacza / zadania / zatrzymania / ponownego uruchomienia, aby mógł być bardziej wydajny, a także zachować wystarczającą ilość miejsca na sporadyczne wzrosty, które nie są łapane w czasie.
To rodzaj dziwnego scenariusza. Jestem prawie pewien, że bym sobie z tego poradził kilka lat temu i oczywiście są tutaj podstawowe podstawowe problemy. Ale jeśli masz do czynienia z setkami serwerów, pojawi się kilka takich przypadków, które nie mogą być rozwiązane w żaden sposób, z jakiegokolwiek powodu biznesowego, z wyjątkiem MacGyvering tymczasowego rozwiązania, które wykona zadanie.
Tak długo, jak jest to bezpieczne, logiczne, przetestowane i dobrze udokumentowane, nie powinno być problemu.