sql-server – 为什么事务日志在使用夜间备份的简单恢复模式下继

发布时间：2020-12-12 17:00:34 所属栏目：MsSql教程来源：网络整理

导读：在立即标记为重复之前,我已经阅读了Mike Walsh的 Why Does the Transaction Log Keep Growing or Run Out of Space?,但我认为它没有回答我的情况.我查看了十几个类似的问题,但相关的问题大多只是说“重复”,并指出迈克的问题. 详细信息：我在SQL Server 2008

在立即标记为重复之前,我已经阅读了Mike Walsh的 Why Does the Transaction Log Keep Growing or Run Out of Space?,但我认为它没有回答我的情况.我查看了十几个类似的问题,但相关的问题大多只是说“重复”,并指出迈克的问题.

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

来自sys.databases的log_reuse_wait_desc说“NOTHING”,它基于上面提到的问题和答案说它不应该等待重用空间.

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

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

Simple Recovery Model – So with the above introduction,it is easiest to talk about Simple Recovery model first. In this model,you are telling SQL Server – I am fine with you using your transaction log file for crash and restart recovery (You really have no choice there.. Look up ACID properties and that should make sense quickly),but once you no longer need it for that crash/restart recovery purpose,go ahead and reuse the log file.

SQL Server listens to this request in Simple Recovery and it only keeps the information it needs to do crash/restart recovery. Once SQL Server is sure it can recover because data is hardened to the data file (more or less),the data that has been hardened is no longer necessary in the log and is marked for truncation – which means it gets re-used.

它一直在说日志空间应该重复使用,但随着这几个月的缓慢增长,似乎并非如此.

我错过了什么？是否有什么东西阻止SQL Server将数据识别为“硬化”并释放日志？

(编辑)
After Action Report – AKA一点点知识是危险的

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

首先,当您查看数据库中的属性时,您在SSMS中看到的可用空间是数据文件中的可用空间.您可以通过在数据库上运行以下命令来查看此内容,并且您将发现SSMS报告的可用空间是FileSizeMB和UsedSpaceMB之间的差异：

SELECT
    DB.name,MF.physical_name,MF.type_desc AS FileType,MF.size * 8 / 1024 AS FileSizeMB,fileproperty(MF.name,'SpaceUsed') * 8/ 1024 AS UsedSpaceMB,mf.name LogicalName
FROM
    sys.master_files MF
    JOIN sys.databases DB ON DB.database_id = MF.database_id
WHERE   DB.name = 'yourdatabasename'

这确实证实了在正常情况下我们使用的日志空间非常小(20MB或更少),但这导致第二项……

其次,我对原木日益增长的看法是随着时间的推移慢慢增长.然而,实际上日志在负责为第三方应用程序应用补丁的人正在应用补丁的那些夜晚正在快速增长.补丁是作为单个事务完成的,因此根据补丁,200MB数据需要300MB的日志.追踪这一点的关键是来自Aaron Bertrand在https://sqlblog.org/2007/01/11/reviewing-autogrow-events-from-the-default-trace年的询问

DECLARE @path NVARCHAR(260);

SELECT 
    @path = REVERSE(SUBSTRING(REVERSE([path]),CHARINDEX('',REVERSE([path])),260)) + N'log.trc'
FROM    sys.traces
WHERE   is_default = 1;

SELECT 
   DatabaseName,[FileName],SPID,Duration,StartTime,EndTime,FileType = CASE EventClass 
       WHEN 92 THEN 'Data'
       WHEN 93 THEN 'Log'
    END
FROM sys.fn_trace_gettable(@path,DEFAULT)
WHERE
    EventClass IN (92,93)
ORDER BY
    StartTime DESC;

这表明当客户没有使用数据库时,日志在某些晚上会增长.这导致了与应用补丁的人的对话和神秘的答案.

再次感谢那些提供帮助的人,让我得到答案.

解决方法

我们不可能猜到导致它的原因,但是SQL Server不仅仅会将日志文件增加到300 MB,它会增长到300 MB,因为在上次缩小操作后的某个时刻,它需要大量的日志空间(无论是由于某些大型单一事务还是许多较小的并发事务).您必须跟踪日志文件增长事件(我谈到了这个 here和 here)以尝试缩小何时或为何发生这种情况(如果您的日志文件增长设置为300 MB或其他什么,那么它将增长300 MB只要它需要超过1 MB的空间来容纳活动事务).

无论如何,为什么你认为一旦达到300 MB就需要缩小日志文件？你是否真的在Mike’s question彻底阅读了所有的答案？日志文件本身不会缩小,因为将日志文件缩小到1MB – 只是因为它可以在最大的事务中再次增长 – 完全是浪费时间.在此期间你打算如何处理所有这些自由空间？

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!