Dziennik transakcji dla bazy danych „nazwa_bazy danych” jest pełny z powodu „XTP_CHECKPOINT”

Mam pytanie XTP_CHECKPOINT.

Korzystam z programu SQL Server 2014. Mam bazę danych, która jest w trybie modelu odzyskiwania SIMPLE. Jest również replikowany.

Brak otwartych transakcji. Uruchomiłem DBCC OPENTRANi zwraca:

„Brak aktywnych otwartych transakcji”.

Ale ciągle otrzymuję ten komunikat za każdym razem, gdy próbuję utworzyć lub upuścić tabelę lub usunąć dane:
(Zastąpiłem nazwę mojej bazy danych słowem database_name)

„Dziennik transakcji dla bazy danych„ nazwa_bazy danych ”jest pełny z powodu„ XTP_CHECKPOINT ””

Czy ktoś wie, dlaczego tak się dzieje i, co ważniejsze, jak mogę to zatrzymać?

I tak, baza danych naprawdę jest w trybie modelu odzyskiwania SIMPLE. tzn. dziennik transakcji powinien zostać automatycznie obcięty.

Nawiasem mówiąc, inna baza danych, którą mam w trybie pełnego odzyskiwania, zrobiła to samo, zaczęła zwracać ten sam błąd:

Dziennik transakcji dla bazy danych „nazwa_bazy danych” jest pełny z powodu „XTP_CHECKPOINT”

Próbowałem zmienić ustawienia wzrostu dziennika na nieograniczony wzrost, ale nie pozwoliło mi to, zwracając ten sam błąd.

Mogę odtworzyć problem bez żadnych elementów XTP, z wyjątkiem tylko grupy plików. Oto jak: http://pastebin.com/jWSiEU9U

Miałem podobny problem: nie miałem replikacji, ale kiedy użyłem tabeli zoptymalizowanej pod kątem pamięci jako testu, baza danych w trybie prostego odzyskiwania, ale moje dzienniki transakcji nie zostały obcięte. Ręczne obcięcie, nawet zaraz po pełnej kopii zapasowej, spowodowało błąd:

Nie można zmniejszyć pliku dziennika X, ponieważ jest używany plik dziennika logicznego znajdujący się na końcu pliku.

Ręczny punkt kontrolny nie powiódł się:

Msg 41315, poziom 16, stan 4, wiersz N Operacja punktu kontrolnego nie powiodła się w bazie danych X.

Ręczny punkt kontrolny odniósł sukces dopiero po ponownym uruchomieniu usługi SQL, co doprowadziłoby do 4-godzinnego stanu odzyskiwania z powodu rozmiaru bazy danych Multi Tb. Próbowałem również ustawić autogrowth na określony rozmiar, ale wszystko skończyło się tak samo: wypełnij dzienniki transakcji, aż nie pozostanie wolne miejsce.

Wreszcie, po wielu dniach i nocach prób i badań, znalazłem rozwiązanie mojego problemu, instalując aktualizację zbiorczą 3 dla programu SQL Server 2014 z dodatkiem SP1

Najpierw upewnij się, że replikacja nie powoduje tego, jak stwierdzono w elemencie connect „log_wait_reuse_desc = XTP_CHECKPOINT niekoniecznie oznacza, że ​​pracownik punktu kontrolnego XTP wstrzymuje obcinanie dziennika”. więc zacznij od uruchomienia sp_repltransi upewnij się, że wszystkie dane zostały rozpowszechnione.

Tutaj jest ten mały fragment :

„dzieje się to w bazie danych, która ma grupę plików zoptymalizowaną pod kątem pamięci, bez względu na to, czy istnieją tabele zoptymalizowane pod kątem pamięci, czy nie.

Bieżącym obejściem jest ustawienie AutoGrown na stały rozmiar. Lub zmieniając tryb odzyskiwania na Prosty i zmniejszając dziennik ”.

Jeśli więc czyszczenie replikacji nie działa, spróbuj wykonać następujące czynności:

checkpoint;
dbcc shrinkfile (Logfile, truncateonly)
alter database [database] modify file (filename = 'TRANSACTIONLOG', FILEGROWTH = 5MB)

Nie podano, czy dotyczy to pliku dziennika, czy plików bazy danych, ale zacznijmy od wypróbowania plików dziennika, a jeśli nie, spróbuj ustawić pliki bazy danych na stały wzrost:

Byłem w stanie obejść ten problem, dodając kolejny plik dziennika, co pozwoliło mi na uruchomienie pełnej kopii zapasowej, dostosowanie rozmiaru głównego pliku dziennika i ograniczenie wzrostu wraz z usunięciem dodatkowego pliku dziennika dodanego w celu rozwiązania problemu XTP_CHECKPOINT.

Doświadczyłem tego z klientem. Pliki danych dziennika i FILESTREAM w pamięci znajdowały się na tym samym dysku. Utworzyli nowy plik dziennika (niewiele osób to sugerowało), ale system nie może PUNKT KONTROLNY, ponieważ nie udało się utworzyć plików punktów kontrolnych w pamięci (* .HKCKP).

Spróbuj zwolnić miejsce na dysku za pomocą danych FILESTREAM w pamięci.