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 错误。我不确定这会完成什么，但这是一种方法。

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

SQL Server中完整事务日志的实际原因

1 个答案: