标签: transaction-log

这个问题在大多数论坛和整个网络中似乎是一个常见问题，这里以多种格式提出，通常听起来像这样：

在 SQL Server 中 -

• 事务日志变得如此之大的一些原因是什么？
• 为什么我的日志文件这么大？
• 有什么方法可以防止这个问题的发生？
• 当我找到根本原因并希望将我的事务日志文件调整到正常大小时，我该怎么办？

我想知道如何识别实际填充 TEMPDB 数据库事务日志的确切查询或存储过程。

我有一个包含 64m 行的表，在磁盘上占用了 4.3 GB 的数据。

每行大约有 30 个字节的整数列，加上一个NVARCHAR(255)用于文本的变量列。

我添加了一个带有 data-type 的 NULLABLE 列Datetimeoffset(0)。

然后我为每一行更新了这一列，并确保所有新的插入都在这一列中放置了一个值。

一旦没有 NULL 条目，我就运行这个命令来使我的新字段成为强制性的：

ALTER TABLE tblCheckResult 
ALTER COLUMN [dtoDateTime] [datetimeoffset](0) NOT NULL

结果是事务日志大小大幅增长——从 6GB 增加到超过 36GB，直到空间用完！

有没有人知道 SQL Server 2008 R2 到底在为这个简单的命令做些什么来导致如此巨大的增长？

在立即标记为重复之前，我已阅读 Mike Walsh 的《为什么事务日志不断增长或空间不足？，但我认为它没有回答我的情况。我浏览了十几个类似的问题，但相关的问题大多只是说“重复”并指向迈克的问题。

详细信息：我在 SQL Server 2008 R2 上有一堆约 500MB 的数据库，都处于简单恢复模式（不是我的选择），每晚完整备份，包含约 200MB 的数据文件和约 300MB 的日志文件。日志不会立即增长到 300MB，而是在几个月的过程中缓慢增长。至少根据 sp_who2 和活动监视器，它们中的任何一个都没有打开的事务。如果我右键单击数据库并选择属性，它会告诉我有大约 50MB 可用空间。特别是在备份之后，整个日志不应该是免费的吗？在 SIMPLE 模式下，只要没有打开的事务，日志就不应该是免费的吗？

log_reuse_wait_descfromsys.databases说“NOTHING”，根据上面引用的问题和答案说它不应该等待任何东西来重用空间。

如果我做'DBCC SHRINKFILE'，日志文件缩小到1MB，所以它愿意回收空间。我可以设置一些每周缩小日志并防止事情失控的东西，但我很困惑为什么 SQL Server 会让我这样做。

我可以理解是否有一些疯狂的事务需要 300MB 来记录它，但我们没有做任何极端的事情，只是基本的 OLTP。来自迈克的问题/答案：

简单恢复模型 - 有了上面的介绍，最容易先讨论简单恢复模型。在此模型中，您是在告诉 SQL Server - 我对您使用您的事务日志文件进行崩溃和重新启动恢复感到满意（您在那里确实别无选择。查找 ACID 属性，这应该很快就有意义），但是一旦您没有不再需要它用于崩溃/重启恢复目的，继续并重用日志文件。

SQL Server 在 Simple Recovery 中侦听此请求，并且仅保留执行崩溃/重新启动恢复所需的信息。一旦 SQL Server 确定它可以恢复，因为数据已加固到数据文件（或多或少），已加固的数据在日志中不再需要并被标记为截断 - 这意味着它会被重新使用。

它一直说日志空间应该被重用，但是随着几个月的缓慢增长，它似乎不是。

我错过了什么？是否有什么原因使 SQL Server 无法将数据识别为“硬化”并释放日志？

(编辑) 行动后报告 - AKA 一点点知识是危险的

在发现这是一个“热门问题”后，我觉得我欠了一个解释 7 个月前发生的事情以及我学到的东西，希望能挽救一些其他人的悲伤。

首先，当您查看数据库的属性时，您在 SSMS 中看到的可用空间是数据文件中的可用空间。您可以通过在数据库上运行以下命令来查看这一点，您会发现 SSMS 报告的可用空间是 FileSizeMB 和 UsedSpaceMB …

我有一个数据库，它有一个350 MB 的数据文件(.mdf) 和一个4.9 GB 的日志文件(.ldf)。恢复模式设置为FULL.

当我尝试缩小日志文件时，它并没有缩小。

我知道缩小数据库不好，也不应该这样做。但我仍然试图缩小日志文件。

当我跑

DBCC SQLPerf(logspace) 

我发现日志大小为4932 MB，使用的日志空间为98.76%！

然后我尝试了这个命令

USE <databasename>;
DBCC loginfo;

现在几乎所有的 VLF 都是“状态 2”，这意味着都在使用中。

我尝试进行日志备份，然后缩小日志文件。收缩并没有减小尺寸。

我将恢复模型更改为SIMPLE并再次尝试缩小，但这也无济于事。

我检查了未结交易

DBCC opentran (database);

并发现现在没有交易打开。

是什么阻止我缩小日志文件？我该如何解决这个问题？

我有一个关于XTP_CHECKPOINT.

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

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

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

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

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

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

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

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

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

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

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

我在 SQL Server Central 线程中看到完整备份是否会截断日志？完整备份不会截断日志：

不会。完整备份或差异备份都不会截断事务日志。- Lynn Pettis
否 - 完整备份不会截断日志。-查德克劳馥

那么完整备份和仅复制完整备份有什么区别呢？

对于日志备份，只有复制备份可以防止日志链在不截断日志的情况下中断。那么什么是仅复制完整备份？

我们有多台机器，我们已将事务日志的大小预先分配为 50GB。我试图重组的表的大小是 55 - 60 GB，但会不断增加。我想重组的主要原因是回收空间和任何性能优势，因为这是一个额外的好处。

表的碎片级别为 30 - 35%。在其中一些机器上，我收到“事务日志已满”错误并且重组失败。事务日志大小高达 48GB。有什么好的方法可以解决这个问题？我们没有打开自动增量，我不愿意这样做。

我可以将日志大小增加到更大的值，但是随着将来表大小的增加，该值可能不够。如果我要同等地增加日志大小，它也会破坏进行重组以回收空间的目的。关于如何有效应对这种情况的任何想法？使用批量模式不是一种选择，因为数据丢失是不可接受的。

我需要截断一个包含 170 亿行的表，该表位于作为 AG 一部分的数据库中。

此操作对 AG 延迟和日志备份大小有什么影响？

有推荐的方法吗？

我有一个名为 SQL Server 2005 的表BRITTNEY_SPEARS_MARRIAGES，它具有以下列：

MarrigeId tinyint, 
HusbandName varchar(500),
MarrigeLength int

现在我有另一张桌子 BRITTNEY_SPEARS_MARRIAGE_STORIES

StoryId int, 
MarriageId tinyint, 
StoryText nvarchar(max)

问题是我们想将MarrigeId列int从 a更新为a tinyint。我们只是觉得布兰妮在一切都说完和做完之前会有很多婚姻。

现在BRITTNEY_SPEARS_MARRIAGE_STORIES表中有 1800 万行（嘿，这个女孩有一些问题），所以当我们进行更新时，事务日志填满了，我们的 SQL Server 框就死了。

我们怎样才能解决这个问题？

无论如何，是否可以说“嘿 SQL Server，我将更新此列并使其更大。相信我在此 SQL Server 上。请不要在尝试验证所有内容时填写事务日志？”