这个数据库是用于少量使用(可能不是很重要)的数据库,同一个站点有另一个更重要,更大的数据库(大小在5 Gb的某个地方),它有一个较小的日志文件,所以我是假设正在修剪该数据库的日志文件.
我被告知该站点使用日志传送将其主数据库备份到第二台服务器,但我不确定是否还在备份较小的数据库.
所以,我猜他们要么只使用主数据库的日志传送,要么只备份主数据库.
这引出了一些问题
>网站上的用户/管理员是否可以执行任何干扰或中断日志传送的备份？
>如果您使用日志传送,这是否足以确保日志不会持续增长,或者您是否仍需要备份日志(例如使用维护计划)？
>这个并不太重要,但如果我得到的备份需要更多的日志文件空间而不是我可用的,有没有办法在没有日志文件的情况下恢复它,或者没有在源头修复问题并得到一个新备份.
解决方法
由于数据库的日志大小为10Gb,因此无论实际使用的数量如何,还原备份还将创建10Gb日志文件.这同样适用于任何数据文件.
您可以使用’DBCC SHRINKFILE‘命令缩小日志文件 – 尽管除非您确定日志不会再次增长到10Gb,否则我建议不要这样做(增加文件会对性能产生影响).长时间运行的事务或数据库维护活动可能会占用大量事务日志,因此有必要在收缩之前找出日志为10Gb的原因.
回答你的3个问题：
是否有任何类型的备份,用户/管理员在现场可以执行干扰或中断日志传送？
是 – 如果通过将日志备份到日志传送配置之外的目标来中断备份链,则导致备份未应用于辅助服务器.在这种情况下,您应该使用COPY_ONLY备份,因为这些备份不会破坏日志链.这仅适用于日志备份,因为完整备份不会截断日志.
如果您使用日志传送,或者您是否仍需要备份日志(例如使用维护计划)？
这应该没问题,除非有其他东西阻止日志被截断,例如数据库镜像,长时间运行的事务,复制甚至数据库快照创建.找出未截断日志的原因的方法是查看sys.databases中的log_reuse_wait_desc列.
日志传送的备份作业也可能(但不太可能)使用COPY_ONLY / NO_TRUNCATE进行备份,这意味着日志文件将在满载后不断增长.
这个并不太重要,但如果我得到的备份需要比我可用的日志文件更多的空间,或者没有在源头修复问题并获得新的备份.
如果缩小日志文件然后进行完整备份,则在还原时,sql Server将使用较小的日志文件创建数据库.
如果你不能缩小但是你要恢复到开发/测试服务器那么你可以挂载一些临时存储并在RESTORE语句上使用’WITH MOVE’将日志文件移动到该驱动器,然后收缩日志并移动日志从临时存储中提取文件(关于是否应该缩小日志的警告仍然适用！).
