Журнал транзакцій для бази даних 'ім'я бази даних' заповнений через 'XTP_CHECKPOINT'

У мене є питання про XTP_CHECKPOINT.

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

Відкритих транзакцій немає. Я запустив, DBCC OPENTRANі він повертається:

"Немає активних відкритих транзакцій."

Але я постійно отримую це повідомлення кожного разу, коли я намагаюся створити або відкинути таблицю або видалити дані:
(Я замінив своє фактичне ім'я бази даних на слово database_name)

"Журнал транзакцій для бази даних 'ім'я бази даних' заповнений через 'XTP_CHECKPOINT'"

Хтось знає, чому це може статися, і, що ще важливіше, як я можу змусити його зупинитися?

І так, база даних дійсно знаходиться в простому режимі відновлення моделі. тобто журнал транзакцій повинен скорочуватися автоматично.

До речі, інша база даних, у якій я працюю в режимі повного відновлення, зробила те саме, почала повертати ту саму помилку:

Журнал транзакцій для бази даних 'ім'я бази даних' заповнений через 'XTP_CHECKPOINT'

Я намагався змінити параметри росту журналу на необмежений ріст, але це не дозволило мені повернути ту саму помилку.

Я можу відтворити проблему без будь-яких речей XTP, за винятком лише файлової групи. Ось як: http://pastebin.com/jWSiEU9U

У мене була подібна проблема: у мене не було реплікації, але одного разу я використав таблицю оптимізованої пам’яті як тест, базу даних у простому режимі відновлення, але мої журнали транзакцій не були усічені. Ручне усічення, навіть відразу після повної резервної копії, призвело до помилки:

Неможливо зменшити файл журналу X, оскільки використовується логічний файл журналу, що знаходиться в кінці файлу.

Помилка контрольного пункту вручну:

Повідомлення 41315, Рівень 16, стан 4, рядок N Операція контрольної точки не виконана в базі даних X.

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

Нарешті, після днів і ночей, намагаючись і досліджувати, я знайшов рішення для своєї проблеми, встановивши накопичувальне оновлення 3 для SQL Server 2014 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 журналу та пам'яті в пам'яті були на одному диску. Вони створили новий файл журналу (мало хто пропонував це), але система не може перевірити, оскільки не вдається створити файли контрольних точок в пам'яті (* .HKCKP).

Спробуйте звільнити місце на накопичувачі за допомогою даних FILESTREAM в пам'яті.