主页 / dba / 问题 / 93588
Accepted
user3469285
Asked: 2015-02-24 09:25:14 +0800 CST

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

  • 772

我有一个关于XTP_CHECKPOINT.

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

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

“没有有效的未结交易。”

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

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

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

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

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

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

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

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

sql-server sql-server-2014

4 个回答

  1. Best Answer

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

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

    手动检查点失败：

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

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

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

    • 10

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

    然后这里有这个小片段：

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

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

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

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

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

    • 9

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

    • 5

  4. 我曾与一位客户经历过这种情况。日志和内存中的 FILESTREAM 数据文件位于同一驱动器上。他们创建了一个新的日志文件（很少有人建议这样做），但系统无法检查点，因为它无法创建内存检查点文件 (*.HKCKP)。

    尝试使用内存中的 FILESTREAM 数据释放驱动器上的空间。

    • 1

相关问题