データベース 'database_name'のトランザクションログは、 'XTP_CHECKPOINT'が原因でいっぱいです。

について質問がありXTP_CHECKPOINTます。

SQL Server 2014を使用しています。シンプルリカバリモデルモードのデータベースがあります。また、複製されています。

開いているトランザクションはありません。私は実行しDBCC OPENTRAN、それが返されます：

「アクティブなオープントランザクションはありません。」

しかし、テーブルを作成または削除、またはデータを削除しようとするたびに、このメッセージが表示され続けます
（実際のデータベース名をに置き換えましたdatabase_name）。

「データベース「database_name」のトランザクションログは、「XTP_CHECKPOINT」が原因でいっぱいです」

なぜこれが起こっているのか誰も知っていますか、そしてもっと重要なことは、どうすればそれを止めることができますか？

そして、はい、データベースは本当に単純復旧モデルモードです。つまり、トランザクションログは自動的に切り捨てられます。

ちなみに、完全復旧モードで使用している別のデータベースは同じことを行い、同じエラーを返し始めました。

データベース 'database_name'のトランザクションログは、 'XTP_CHECKPOINT'が原因でいっぱいです。

ログの増加設定を無制限の増加に変更しようとしましたが、同じエラーが返されてしまいました。

ファイルグループのみを除いて、XTPを一切使用せずに問題を再現できます。方法は次のとおりです。http：//pastebin.com/jWSiEU9U

同様の問題がありました：レプリケーションはありませんでしたが、一度メモリ最適化テーブルをテストとして使用し、データベースをシンプルリカバリモードで使用しましたが、トランザクションログは切り捨てられませんでした。完全バックアップの直後であっても、手動切り捨てによりエラーが発生しました。

ファイルの末尾にある論理ログファイルが使用中のため、ログファイルXを圧縮できません。

手動チェックポイントが失敗しました：

メッセージ41315、レベル16、状態4、行Nチェックポイント操作がデータベースXで失敗しました。

手動チェックポイントは、SQLサービスを再起動した直後にのみ成功しました。これは、マルチTbデータベースサイズのために4時間のIn Recovery状態になります。また、自動拡張を特定のサイズに設定しようとしましたが、すべて同じようになりました。スペースがなくなるまでトランザクションログをいっぱいにします。

最後に、昼夜を問わず試行錯誤を繰り返した後、SQL Server 2014 SP1用の累積的な更新プログラム3をインストールすることで問題の解決策を見つけました。

接続項目で説明されているように、最初にレプリケーションがこれを引き起こしていないことを確認します。実行sp_repltransすることから始めて、すべてのデータが配布されたことを確認してください。

次に、この小さなスニペットがあります：

「メモリ最適化テーブルがあるかどうかに関係なく、メモリ最適化ファイルグループを持つデータベースで発生します。

現在の回避策は、AutoGrownを固定サイズに設定します。または、復旧モードをシンプルに変更し、ログを縮小します。」

したがって、レプリケーションのクリーンアップが機能しない場合は、次を試してください。

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

これがログファイルまたはデータベースファイル用であるかどうかは明記されていませんが、ログファイルを試すことから始めましょう。

XTP_CHECKPOINTの問題を解決するために追加されたログファイルを削除するとともに、別のログファイルを追加して問題を回避することができました。

私は顧客でこれを経験しました。ログとメモリ内のFILESTREAMデータファイルは同じドライブにありました。彼らは新しいログファイルを作成しましたが（これを提案する人はほとんどいませんでした）、システムはメモリ内チェックポイントファイル（* .HKCKP）の作成に失敗するためチェックポイントを実行できません。

メモリー内のFILESTREAMデータを使用して、ドライブのスペースを解放してください。