事务日志是完整的是什么意思？我有文件设置在需要时增长20%.我的驱动器上还剩4GB.如何永久解决此问题？运行这些命令可以暂时解决问题:
DBCC SHRINKFILE('MyDatabase_log', 1)
BACKUP LOG MyDatabase WITH TRUNCATE_ONLY
DBCC SHRINKFILE('MyDatabase_log', 1)
Charles Bret.. 7
事务日志是SQL服务器"记录"它所做的每一次更改的地方,以便在出现问题时(从软件崩溃到电源故障,再到小行星打击......好吧也许不是小行星打击),它可以"恢复"通过"撤消"它所做的所有更改,因为最后一致的"CheckPoint" - 返回到该检查点的数据库的最后"一致"状态.每次事务完成(或"提交")时,已存储在事务日志中的所有更改都标记为"ok",并且允许CheckPopint标记在这些更改之后向前移动,以便将来恢复只会在此之后"撤消"某些方面的更改.发生这种情况后,
正如另一位绅士所提到的,您在服务器上设置的"恢复模型"控制了在检查点之前发生的事务日志条目.在简单模式下,它们会在检查点发生时被删除,但如果主数据磁盘崩溃,则存在风险,因为事务日志不包含自上次备份以来写入磁盘的更改.
在其他恢复模型中,在您执行备份之前不会删除事务日志条目,从而保护您免受此风险...
因此,通常,当出现此问题时,这是因为服务器处于设置的"正常"(非简单)恢复模型之一(增量或完全),并且它们不进行备份.... 在这种情况下,交易日志只是保持增长......,并且正在增长...有点像电视上的那些前列腺广告......
事务日志是SQL服务器"记录"它所做的每一次更改的地方,以便在出现问题时(从软件崩溃到电源故障,再到小行星打击......好吧也许不是小行星打击),它可以"恢复"通过"撤消"它所做的所有更改,因为最后一致的"CheckPoint" - 返回到该检查点的数据库的最后"一致"状态.每次事务完成(或"提交")时,已存储在事务日志中的所有更改都标记为"ok",并且允许CheckPopint标记在这些更改之后向前移动,以便将来恢复只会在此之后"撤消"某些方面的更改.发生这种情况后,
正如另一位绅士所提到的,您在服务器上设置的"恢复模型"控制了在检查点之前发生的事务日志条目.在简单模式下,它们会在检查点发生时被删除,但如果主数据磁盘崩溃,则存在风险,因为事务日志不包含自上次备份以来写入磁盘的更改.
在其他恢复模型中,在您执行备份之前不会删除事务日志条目,从而保护您免受此风险...
因此,通常,当出现此问题时,这是因为服务器处于设置的"正常"(非简单)恢复模型之一(增量或完全),并且它们不进行备份.... 在这种情况下,交易日志只是保持增长......,并且正在增长...有点像电视上的那些前列腺广告......
京公网安备 11010802040832号 | 京ICP备19059560号-6 