sql-server – 查询SQL备份,日志文件和日志传送

我有一个MS-sql服务器备份.bak文件在我的机器上恢复,大小约为25mb,但需要10Gb的可用磁盘空间,因为日志文件是那个大小,这表明他们的日志文件没有被退出也没有被截断. (请注意,10Gb日志文件必须大部分为空,否则.bak文件将大于25mb)

这个数据库是用于少量使用(可能不是很重要)的数据库,同一个站点有另一个更重要,更大的数据库(大小在5 Gb的某个地方),它有一个较小的日志文件,所以我是假设正在修剪该数据库的日志文件.

我被告知该站点使用日志传送将其主数据库备份到第二台服务器,但我不确定是否还在备份较小的数据库.

所以,我猜他们要么只使用主数据库的日志传送,要么只备份主数据库.

这引出了一些问题

>网站上的用户/管理员是否可以执行任何干扰或中断日志传送的备份？
>如果您使用日志传送,这是否足以确保日志不会持续增长,或者您是否仍需要备份日志(例如使用维护计划)？
>这个并不太重要,但如果我得到的备份需要更多的日志文件空间而不是我可用的,有没有办法在没有日志文件的情况下恢复它,或者没有在源头修复问题并得到一个新备份.

解决方法

sql实际上并不在日志备份后调整日志大小 – 而只是更改内部元数据以标记可以重用的日志部分(称为虚拟日志文件或VLF).此过程称为日志截断.因此,如果没有免费的VLF,您的日志文件将会增长,但除非您手动告诉sql Server这样做,否则它将永远不会缩小.

由于数据库的日志大小为10Gb,因此无论实际使用的数量如何,还原备份还将创建10Gb日志文件.这同样适用于任何数据文件.

您可以使用’DBCC SHRINKFILE‘命令缩小日志文件 – 尽管除非您确定日志不会再次增长到10Gb,否则我建议不要这样做(增加文件会对性能产生影响).长时间运行的事务或数据库维护活动可能会占用大量事务日志,因此有必要在收缩之前找出日志为10Gb的原因.

回答你的3个问题：

是否有任何类型的备份,用户/管理员在现场可以执行干扰或中断日志传送？

是 – 如果通过将日志备份到日志传送配置之外的目标来中断备份链,则导致备份未应用于辅助服务器.在这种情况下,您应该使用COPY_ONLY备份,因为这些备份不会破坏日志链.这仅适用于日志备份,因为完整备份不会截断日志.

如果您使用日志传送,或者您是否仍需要备份日志(例如使用维护计划)？

这应该没问题,除非有其他东西阻止日志被截断,例如数据库镜像,长时间运行的事务,复制甚至数据库快照创建.找出未截断日志的原因的方法是查看sys.databases中的log_reuse_wait_desc列.

日志传送的备份作业也可能(但不太可能)使用copY_ONLY / NO_TruncATE进行备份,这意味着日志文件将在满载后不断增长.

这个并不太重要,但如果我得到的备份需要比我可用的日志文件更多的空间,或者没有在源头修复问题并获得新的备份.

如果缩小日志文件然后进行完整备份,则在还原时,sql Server将使用较小的日志文件创建数据库.

如果你不能缩小但是你要恢复到开发/测试服务器那么你可以挂载一些临时存储并在RESTORE语句上使用’WITH MOVE’将日志文件移动到该驱动器,然后收缩日志并移动日志从临时存储中提取文件(关于是否应该缩小日志的警告仍然适用！).