详细信息:我在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;
这表明当客户没有使用数据库时,日志在某些晚上会增长.这导致了与应用补丁的人的对话和神秘的答案.
再次感谢那些提供帮助的人,让我得到答案.
解决方法
无论如何,为什么你认为一旦达到300 MB就需要缩小日志文件?你是否真的在Mike’s question彻底阅读了所有的答案?日志文件本身不会缩小,因为将日志文件缩小到1MB – 只是因为它可以在最大的事务中再次增长 – 完全是浪费时间.在此期间你打算如何处理所有这些自由空间?