为什么我的日志文件这么大？22GB。我正在运行日志备份

Question

我似乎想不出答案。我见过多个这样的答案： 为什么事务日志不断增长或空间不足？

每个人都在谈论在您的日志文件上运行备份，以便它缩小。我正在这样做，但它不会缩小任何东西！我也不相信我正在运行任何超长事务。

服务器： SQL Server 2008

恢复模式： Full

我有一个维护计划来存储 5 天的备份。任务 1 备份具有备份类型的数据库Full，任务 2 备份事务日志。Verify backup integrity对两个任务都进行检查。

我的数据库的正常.ldf文件是 22GB。当我运行上述任务时，.bak文件为435mb，但.trn.文件为22gb，与ldf相同。并且在成功运行之后.ldf根本没有缩小，尽管我读过的所有内容都告诉我应该这样做？

这里发生了什么，为什么日志文件永远不会缩小？

我也试过运行另一个答案中提到的这个命令：

select name, log_reuse_wait_desc from sys.databases

它说LOG_BACKUP的是带有巨大日志文件的数据库。

根据下面的答案，我混淆了已用空间的分配。这些是我的统计数据：

由于我不知道为什么，初始大小设置为 22gb ...

Answer 1

您将分配的空间与已用空间混淆。运行备份后，使用此查询查看已分配空间和已用空间之间的差异。

select file_id
, type_desc
, name
, substring([physical_name],1,3) AS [Drive]
, physical_name
, state_desc
, size / 128 as 'AllocatedSizeMB'
, FILEPROPERTY([name],'SpaceUsed') /128 AS 'SpaceUsedMB'  --Addapted from https://sqlperformance.com/2014/12/io-subsystem/proactive-sql-server-health-checks-1
, (1- (FILEPROPERTY([name],'SpaceUsed') / CAST (size AS MONEY))) *100 AS 'PercentFree'
, growth / 128 as 'GrowthSettingMB'

 from sys.database_files
 order by type_desc Desc, name

您可以使用 GUI 通过更改“初始大小”来缩小日志文件

如果您在缩小日志时遇到问题，即使它看起来大部分是空的，请参阅我的帖子

Answer 2

进行此备份只会备份数据并清除日志。DBCC如果确实需要缩小日志，则需要通过命令缩小日志的实际大小。根据您备份日志文件的频率，它可能会再次增长。

尝试运行此命令以查看您的日志实际占用了多少空间。

SELECT 
    [TYPE] = A.TYPE_DESC
    ,[FILE_Name] = A.name
    ,[FILEGROUP_NAME] = fg.name
    ,[File_Location] = A.PHYSICAL_NAME
    ,[FILESIZE_MB] = CONVERT(DECIMAL(10,2),A.SIZE/128.0)
    ,[USEDSPACE_MB] = CONVERT(DECIMAL(10,2),A.SIZE/128.0 - ((SIZE/128.0) - CAST(FILEPROPERTY(A.NAME, 'SPACEUSED') AS INT)/128.0))
    ,[FREESPACE_MB] = CONVERT(DECIMAL(10,2),A.SIZE/128.0 - CAST(FILEPROPERTY(A.NAME, 'SPACEUSED') AS INT)/128.0)
    ,[FREESPACE_%] = CONVERT(DECIMAL(10,2),((A.SIZE/128.0 - CAST(FILEPROPERTY(A.NAME, 'SPACEUSED') AS INT)/128.0)/(A.SIZE/128.0))*100)
    ,[AutoGrow] = 'By ' + CASE is_percent_growth WHEN 0 THEN CAST(growth/128 AS VARCHAR(10)) + ' MB -' 
        WHEN 1 THEN CAST(growth AS VARCHAR(10)) + '% -' ELSE '' END 
        + CASE max_size WHEN 0 THEN 'DISABLED' WHEN -1 THEN ' Unrestricted' 
            ELSE ' Restricted to ' + CAST(max_size/(128*1024) AS VARCHAR(10)) + ' GB' END 
        + CASE is_percent_growth WHEN 1 THEN ' [autogrowth by percent, BAD setting!]' ELSE '' END
FROM sys.database_files A LEFT JOIN sys.filegroups fg ON A.data_space_id = fg.data_space_id 
order by A.TYPE desc, A.NAME; 

如果您确实有大量可用空间，则可以运行该DBCC SHRINKFILE命令，以便将日志文件缩小到您认为应该达到的大小。

编辑：您可能还想检查一下，DBCC LOGINFO;然后您可以看到事务日志文件正在使用的任何项目，因为它们的状态为 2。

但是，首先导致日志文件增长的任何活动都可能继续发生。听起来您每天只进行一次日志备份。

您应该做的是在完整数据库备份之间全天进行多次日志备份。我可能会建议从每小时开始并进行调整以最终查看最适合您的方式。如果您觉得舒服，您可以通过维护计划继续执行此操作。否则，您可以使用Ola Hallengren 的脚本来设置维护计划。有很多不同的选项可供选择，而且在大多数情况下，只要您经常进行备份，它们都非常棒。