我有几个带有事务日志的 SQL Server 2008 数据库,这些数据库已经失控并填满了驱动器。这些日志之一是 68gb yikes。
我知道最好不要通过截断日志来终止我的备份链,但是当我单独进行收缩时,在几个数据库上我没有得到任何空间回收,而在我所做的那些上,数量可以忽略不计。我已经验证客户端每小时都在运行 t-log 备份,并且在过去几周内这些备份都成功了。
显然我错过了一些东西。有人可以指出我正确的方向,还是我只是不得不手动截断并祈祷在此期间什么也没有发生?
我有几个带有事务日志的 SQL Server 2008 数据库,这些数据库已经失控并填满了驱动器。这些日志之一是 68gb yikes。
我知道最好不要通过截断日志来终止我的备份链,但是当我单独进行收缩时,在几个数据库上我没有得到任何空间回收,而在我所做的那些上,数量可以忽略不计。我已经验证客户端每小时都在运行 t-log 备份,并且在过去几周内这些备份都成功了。
显然我错过了一些东西。有人可以指出我正确的方向,还是我只是不得不手动截断并祈祷在此期间什么也没有发生?
这是执行
DBCC SHRINKFILE
. 日志文件这么大很可能不是因为现在正在发生的事情,而是因为有一段时间没有运行每小时的事务日志(或者您有一个异常大的事务在日志备份之间或跨日志备份运行)。我不确定误解从何而来,但备份日志不会为您缩小文件,它只会释放文件内的空间。您可以在不干扰日志链的情况下执行这样的一次性操作(或者不必“希望”“在此期间什么也不会发生”),最好是在日志备份成功完成后立即执行:
这应该将文件缩小到 ~4 GB,希望有足够的空间来容纳您的每小时交易。你可能想选择不同的尺寸,我不确定......
如果此命令没有像您预期的那样缩小文件,您可以使用以下方法检查日志修改可能被阻止的原因: