Журнал транзакций для базы данных «database_name» переполнен из-за «XTP_CHECKPOINT»

У меня есть вопрос по поводу XTP_CHECKPOINT.

Я использую SQL Server 2014. У меня есть база данных, которая находится в режиме модели восстановления SIMPLE. Это также копируется.

Нет открытых транзакций. Я побежал, DBCC OPENTRANи он возвращается:

"Нет активных открытых транзакций."

Но я продолжаю получать это сообщение всякий раз, когда пытаюсь создать или удалить таблицу или удалить данные:
(я заменил свое фактическое имя базы данных словом database_name)

«Журнал транзакций для базы данных« имя_базы_данных »заполнен из-за« XTP_CHECKPOINT »»

Кто-нибудь знает, почему это может происходить, и, что более важно, как я могу остановить это?

И да, база данных действительно находится в режиме ПРОСТОЙ модели восстановления. т.е. журнал транзакций должен усекаться автоматически.

Кстати, другая база данных, которая у меня в режиме полного восстановления, сделала то же самое, начала возвращать ту же ошибку:

Журнал транзакций для базы данных «database_name» переполнен из-за «XTP_CHECKPOINT»

Я пытался изменить параметры роста журнала на неограниченный рост, но это не позволило мне, возвращая ту же ошибку.

Я могу воспроизвести проблему без каких-либо XTP-материалов, за исключением только файловой группы. Вот как это сделать: http://pastebin.com/jWSiEU9U

У меня была похожая проблема: у меня не было репликации, но однажды я использовал таблицу Memory Optimized в качестве теста, базу данных в режиме простого восстановления, но мои журналы транзакций не были усечены. Ручное усечение, даже сразу после полного резервного копирования, дало ошибку:

Невозможно сжать файл журнала X, поскольку файл логического журнала, расположенный в конце файла, используется.

Ошибка ручной контрольной точки:

Сообщение 41315, уровень 16, состояние 4, строка N, операция проверки контрольной точки завершилась неудачно в базе данных X.

Ручная контрольная точка прошла успешно только после перезапуска службы SQL, что привело к 4-часовому состоянию восстановления из-за размера базы данных Multi Tb. Я также попытался установить определенный размер для автоматического роста, но все закончилось тем же: заполнял журналы транзакций, пока не осталось свободного места.

Наконец, после нескольких дней попыток и исследований я нашел решение своей проблемы, установив Накопительное обновление 3 для SQL Server 2014 с пакетом обновления 1 (SP1).

Сначала убедитесь, что репликация не вызывает этого, как указано в элементе соединения: «log_wait_reuse_desc = XTP_CHECKPOINT не обязательно означает, что работник контрольной точки XTP задерживает усечение журнала». поэтому начните с запуска sp_repltransи убедитесь, что все данные распределены.

Тогда есть этот маленький фрагмент здесь:

"это происходит в базе данных, в которой есть файловая группа, оптимизированная для памяти, независимо от того, есть ли таблицы, оптимизированные для памяти, или нет.

Текущий обходной путь установлен для AutoGrown, чтобы быть фиксированным размером. Или изменив режим восстановления на «Простой» и сократив журнал ».

Поэтому, если очистка репликации не работает, попробуйте следующее:

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

Не указано, если это для файла журнала или файлов базы данных, но давайте начнем с попытки попробовать файлы журнала, а если нет, то попробуйте установить файлы базы данных с фиксированным ростом:

Я смог обойти эту проблему, добавив еще один файл журнала, который затем позволил мне выполнить полное резервное копирование, настроить размер основного файла журнала и ограниченный рост, а также удалить дополнительный файл журнала, добавленный для решения проблемы XTP_CHECKPOINT.

Я испытал это с клиентом. Файлы журнала и данные FILESTREAM в памяти находились на одном диске. Они создали новый файл журнала (немногие предложили это), но система не может CHECKPOINT, поскольку она не может создать файлы контрольных точек в памяти (* .HKCKP).

Попробуйте освободить место на диске с данными FILESTREAM в памяти.