我必须,因为我的磁盘空间不多了.
我会在执行此操作之前进行完整的数据库备份,因此我不需要保留事务日志中的任何内容(对吧？我每天都有完整的数据库备份,可能永远不需要时间点恢复,但我会保留如果我可以打开选项 – 这就是所有的.ldf都是真的,对吗？).
解决了：
好的,在通过SSMS(而不是Tsql)仅对日志进行2次备份后,创建了一个全新的备份集,SSMS中的Shrink-Files-Log对话框终于实际工作了,释放了一些磁盘空间.
不确定为什么需要2个备份,或者为什么Tsql不起作用,并且收缩对话框中报告的“可回收空间”没有区别(第一次备份后的所有收缩尝试都是99％)也是,但仍然没有释放任何空间),但问题现在解决了.谢谢大家.
解决方法
这将导致已从磁盘中删除已提交到数据库的事务日志.理想情况下,您应该实际创建一个数据库维护任务,以便经常性地为您执行此操作 – 正是出于这个原因 – 消除旧的事务日志,这样您就不会填满磁盘.
根据你问题的另一点……不,不是真的.是的,他们执行该功能,但不仅仅是该功能.
数据库不以其他文件的传统方式备份(或写入),因为数据库文件本身经常使用并且不断变化.因此,单个“时间点”备份要么需要使数据库脱机以将其“冻结”在一致状态,要么导致备份的不同部分包含与备份开始时不同的数据.
什么事务日志是数据库执行的每个“事务”的记录.每次更改,更新,添加,删除等记录时,不是写入数据库文件,而是将这些操作写入单独的文件,事务日志,然后在sql服务器确定安全时将其提交到数据库文件中这样做不会导致任何活动停止.因此,事务日志实际上是在数据库实际变为数据库[文件]之前进行的更改.
因此,如果您需要返回给定的数据库状态或时间点,则会“重播”事务日志.本质上,不是复制文件数据,而是访问为数据库找到的最新时间点状态,然后执行使数据库达到指定[稍后]状态的所有相同操作.但是,重要的是要注意,在任何给定时间,您的事务日志将包含尚未提交到数据库的事务.因此,它们不仅仅是执行时间点恢复的能力.它们包含正在进行的[某些]更改,或者很快将对数据库进行更改.
这就是为什么在清除事务日志之前你被迫进行备份的原因 – 一旦备份完成,系统就会有一个数据库的时间点副本,以供将来任何恢复引用,并且能够确定哪些事务有已经提交到数据库,哪些没有.使用该信息,系统知道要为您删除哪些过时的事务日志,哪些不是.
但是,这可能需要一些时间,具体取决于事务日志的大小.如果你以前从未做过一次,那么你需要一段时间.
