SQL Server 中事务日志已满的实际原因

Question

我有一个数据库（恢复模式=满），它的事务日志已满。 我知道我可以通过缩小事务日志来解决这个问题。

但是，我想知道它变满的原因是什么？

因为我读过其他人，他们说大量的插入和删除会增加事务日志的大小。 但我无法复制问题来重现完整事务日志的错误（它以某种方式能够重新分配空间）

问题是：如何模拟“事务日志已满”的问题？ 如何查看物理事务日志？

这个查询是用来跟踪当前占用的日志空间的，但它不是实际的事务日志，因为在批量插入和删除的过程中，查询的占用空间是在颤抖而不是静态增加

假设只要不执行备份，日志空间就会增加

DECLARE @TMPTBL AS TABLE (
DatabaseName nvarchar(500),
LogSize decimal(18,2),
LogSpaceUsed decimal (18,2),
[Status] int
) 

INSERT INTO @TMPTBL
EXEC ('DBCC SQLPERF(LOGSPACE)')

SELECT * FROM @TMPTBL WHERE DATABASENAME LIKE '%MYDBNAME%'
GO

Answer 1

您的问题有多个要点，因此我将尝试分别针对它们进行分析：

获取日志的大小：我更喜欢以下内容，因为它包含最大大小信息。 我并不是说永远不要使用 SQLPERF，我只是在工具箱中添加了另一个工具。 还要意识到 SSMS 中有一个磁盘使用情况报告。

SELECT name, size/128 FileSizeInMB
, size/128 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128  AS EmptySpaceInMB
, iif (max_size = -1, null, (max_size)/128) AS MaxSize, iif(max_size > 0, cast(cast((cast(FILEPROPERTY(name, 'SpaceUsed') as decimal) /cast(max_size as decimal)*100) as decimal(18,2)) as varchar), '-') PctFilled
, file_id, type_desc, physical_name
FROM sys.database_files;

检查事务日志中的内容。 您应该探索 fn_dblog。 这是一个简要介绍的链接https://logicalread.com/sql-server-dbcc-log-command-tl01/#.YAnC39hKiUk这些查询应该可以帮助您入门。 这是一个未记录的功能，所以在生产中要小心。

SELECT *
FROM fn_dblog(null, null);

SELECT COUNT(1) as OperationCount,
    SUM (CAST([Log Record Length] as decimal)) as SumRecLen,
    [Operation]
FROM fn_dblog(null, null)
GROUP BY [Operation]    
ORDER BY 2 DESC;

可能的原因：检查日志的内容将帮助您了解负载来自何处。 查看具有高日志记录长度的操作并深入研究。如果您在列表顶部附近看到 LOP_SHRINK_NOOP 操作，则您可能需要关闭自动收缩。

如何模拟？ 我猜你的意思是触发 9002 错误。 我不确定这会完成什么，但这是一种方法。

1. 关闭日志的自动增长。
2. 将日志的最大大小设置为较小且仅大于当前大小的值。 如果已经分配了大量空白空间，您可能需要备份/缩小日志文件。
3. 执行数据操作，直到达到最大大小。 考虑移动大量数据的循环或手动事务。 示例：新建一个物理表，向其中插入 1000 个整数，然后重复将所有值更新 1。