SQL Server中事务日志已满的实际原因
SQL Server中事务日志已满的实际原因
提问于 2019-03-25 17:07:30
我有一个数据库(恢复模式= full)，它的事务日志已满。我知道我可以通过缩小事务日志来解决这个问题。
但是，我想知道它变满的原因？
因为我读了其他人，他们说大量的插入和删除会增加事务日志的大小。但是我不能复制这个问题来重现完整事务日志的错误(它以某种方式能够重新分配空间)
问题是:如何模拟“事务日志已满”的问题？如何查看物理事务日志？
此查询用于跟踪当前占用的日志空间，但它确实不是实际的事务日志，因为在批量插入和删除过程中，查询的占用空间是抖动的，而不是静态增加的
假设只要不执行备份，日志空间就会增加
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回答 1
Stack Overflow用户
发布于 2021-01-22 03:24:52
你的问题有多个要点，所以我将尝试逐一回答它们：
获取日志的大小：我更喜欢下面的内容，因为它包含最大大小信息。我并不是说永远不要使用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错误。我不确定这能实现什么，但这里有一种方法。
- 关闭日志的自动增长。
- 将日志的最大大小设置为比当前大小略大的值。如果有大量的空闲空间正在进行allocated.
- Perform数据操作，则可能需要备份/收缩日志文件，直到达到最大大小。考虑移动大量数据的循环或手动事务。示例:创建一个新的物理表，在其中插入1000个整数，然后按1重复更新所有值。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/55334379
复制相关文章
相似问题
腾讯云开发者
