由于“XTP_CHECKPOINT”，数据库“database_name”的事务日志已满

Question

我有一个关于XTP_CHECKPOINT.

我使用的是 SQL Server 2014。我有一个处于 SIMPLE 恢复模式模式的数据库。它也在被复制。

没有未结交易。我跑了DBCC OPENTRAN，它返回：

“没有活跃的未结交易。”

但是每当我尝试创建或删除表或删除数据时，我都会收到此消息：（
我已将实际数据库名称替换为单词database_name）

“由于 'XTP_CHECKPOINT'，数据库 'database_name' 的事务日志已满”

有谁知道为什么会发生这种情况，更重要的是，我怎样才能让它停止？

是的，数据库确实处于 SIMPLE 恢复模式模式。即事务日志应自动截断。

顺便说一句，我在完全恢复模式下的另一个数据库做了同样的事情，开始返回相同的错误：

由于“XTP_CHECKPOINT”，数据库“database_name”的事务日志已满

我试图将日志增长设置更改为无限增长，但它不会让我返回相同的错误。

除了文件组之外，我可以在没有任何 XTP 内容的情况下重现该问题。方法如下：http : //pastebin.com/jWSiEU9U

Answer 1

首先确保复制不会导致这种情况，如连接项中所述，“log_wait_reuse_desc=XTP_CHECKPOINT 并不一定意味着 XTP 检查点工作人员正在阻止日志截断。” 所以首先运行sp_repltrans并确保所有数据都已分发。

然后这里有这个小片段：

“它发生在具有内存优化文件组的数据库上，无论是否有内存优化表。

当前的解决方法是将 AutoGrown 设置为固定大小。或者，将恢复模式更改为简单，并缩小日志。”

因此，如果清理复制不起作用，请尝试以下操作：

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

没有说明这是用于日志文件还是数据库文件，但让我们从尝试日志文件开始，如果不是，则尝试将数据库文件设置为固定增长：

Answer 2

我有一个类似的问题：我没有复制，但是一旦我使用内存优化表作为测试，数据库处于简单恢复模式，但我的事务日志没有被截断。手动截断，即使在完全备份之后，也会出现错误：

无法收缩日志文件 X，因为位于文件末尾的逻辑日志文件正在使用中。

手动检查点失败：

消息 41315，级别 16，状态 4，第 N 行检查点操作在数据库 X 中失败。

手动检查点仅在重新启动 SQL 服务后立即成功，由于我的多 Tb 数据库大小，这将导致 4 小时的恢复状态。我还尝试将自动增长设置为特定大小，但结果都是一样的：填满事务日志，直到没有空间为止。

最后，经过日日夜夜的尝试和研究，我通过安装SQL Server 2014 SP1的累积更新 3找到了解决我的问题的方法

Answer 3

我能够通过添加另一个日志文件来解决这个问题，然后我可以运行完整备份，调整主日志文件大小并限制增长，同时删除为解决 XTP_CHECKPOINT 问题而添加的额外日志文件。