主页 / dba / 问题 / 285415
Accepted
Vladimir Baranov
Asked: 2021-02-16 02:50:46 +0800 CST

在数据库备份之前和之后缩小事务日志文件的原因可能是什么？

  • 772

我是一个偶然的 DBA。我是一家公司中唯一一个对 SQL Server 有一定经验的人，我必须处理从另一家公司继承的系统在被收购后。最初设置的人不再可用。

服务器版本：Microsoft SQL Server 2016 (SP1-CU15-GDR) (KB4505221) - 13.0.4604.0 (X64) Jun 15 2019 07:56:34 版权所有 (c) Microsoft Corporation Enterprise Edition：基于内核的许可（64 位）在 Windows Server 2016 Datacenter 10.0（内部版本 14393：）（管理程序）上

当我查看服务器时，首先引起我注意的事情之一是一个 SQL Server 代理作业，它对主数据库进行备份。数据库处于简单恢复模式。这项工作分为三个步骤：

-- step 1
DBCC SHRINKFILE (N'DWH_Main_log' , 0)

-- step 2
declare @disk varchar(100) = replace(N'G:\DB_Backup\DWH_Main_&d&.bak','&d&', convert(varchar, getdate(), 112))
--print @disk
;
BACKUP DATABASE [DWH_Main] 
    TO  DISK = @disk
    WITH  RETAINDAYS = 2
        , NOFORMAT
        , NOINIT
        ,  NAME = N'DWH_Main-Full Database Backup'
        , SKIP
        , NOREWIND
        , NOUNLOAD
        , COMPRESSION
        ,  STATS = 10
GO

-- step 3
WAITFOR DELAY '00:05'
;
DBCC SHRINKFILE (N'DWH_Main_log' , 0)

数据文件大小约为 400GB，目前的日志文件大小约为 50GB。

CREATE DATABASE [DWH_Main]
 CONTAINMENT = NONE
 ON  PRIMARY 
( NAME = N'DWH_Main', FILENAME = N'E:\Data\DWH_Main.mdf' , SIZE = 411114496KB , 
  MAXSIZE = UNLIMITED, FILEGROWTH = 65536KB )
 LOG ON 
( NAME = N'DWH_Main_log', FILENAME = N'F:\Log\DWH_Main_log.ldf' , SIZE = 53941184KB , 
  MAXSIZE = 2048GB , FILEGROWTH = 65536KB )

我可以看到很多日志文件自动增长事件，这并不奇怪。DBCC LOGINFO返回 858 行，即 858 个片段，几乎每个片段 64MB。

对于这种情况，我应该对我的老板说些什么？我不明白为什么有人会希望在完整备份后每天都缩小事务日志文件，尤其是对于处于简单恢复模式的数据库。

我的第一反应是简单地DBCC SHRINKFILE从脚本中删除命令，然后重新配置事务日志文件的初始大小。以 8GB 块手动将其增长到 ~64GB 以减少碎片，但也许我遗漏了什么？

sql-server sql-server-2016

2 个回答

  1. Best Answer

    很可能设置该配置的人对 SQL Server 不是很有经验。

    或者，磁盘空间非常宝贵，即使您只在它（很快）再次增长之前回收一些磁盘空间，执行收缩的成本和缺点被认为比磁盘空间成本优先级低。不太可能，但理论上的可能性。

    为什么在完整备份之前和之后都进行收缩？打败我。完整备份会执行一个检查点，这将清空日志（处于简单恢复中），因此在完整备份之后进行收缩是合理的做法。当我们谈论常规日志收缩时，如果可以使用“合理”这个词。

    我会删除收缩并添加一些监控。即，每 5 分钟轮询一次日志的大小，看看它是否/何时增长。

    当然，正如您所说，将其扩大到合理的大小。如果您有可用的信息，那可能应该是您的高水印文件大小。可能是第一次缩小之前的大小 - 数据库中的异常事件不计算在内......

    • 3

  2. 对于这种情况，我应该对我的老板说些什么？

    对你的老板说这是错误的，收缩对于数据文件和日志文件都是邪恶的操作。

    我不明白为什么有人会希望在完整备份后每天都缩小事务日志文件，尤其是对于处于简单恢复模式的数据库。

    缺乏关于 SQL Server 如何工作的知识。完全不需要运行压缩文件，只需要在备份前后运行它。唯一可以缩小日志文件的时间是当它由于一些不需要的事务而大幅增长时。

    我的第一反应是简单地从脚本中删除 DBCC SHRINKFILE 命令，然后重新配置事务日志文件的初始大小

    你的想法绝对正确。继续删除它

    • 3

相关问题