Microsoft SQL Server - 这意味着事务日志已满？

Question

这意味着事务日志已满？我有它需要的时候增长20％的文件。驱动器上剩下4GB。我该如何永久解决这个问题？ 运行这些命令，暂时解决了这个问题：

 
DBCC SHRINKFILE('MyDatabase_log', 1) 
BACKUP LOG MyDatabase WITH TRUNCATE_ONLY 
DBCC SHRINKFILE('MyDatabase_log', 1) 

Answer 1

事务日志是SQL服务器'记录'它所做的每一个更改，以便如果出现问题（从软件崩溃到电源故障，小行星罢工......也许不是一个小行星罢工），它可以通过从最后一致的“CheckPoint”中“撤消”它所做的所有更改来“恢复” - 回到数据库的最后一个“一致”状态......在该检查点。每次事务完成（或“提交”）时，存储在事务日志中的所有更改都会标记为“正常”，并且CheckPopint标记可以在这些更改之后向前移动，以便将来进行恢复在那之后只会“撤销”到某个点的变化。在发生这种情况之后，CheckPoint之前的事务日志中的所有条目不再需要从系统崩溃中恢复......但是它们仍然可能需要从硬盘崩溃中恢复，所以...

正如另一位先生提到的那样，您在服务器上设置的“恢复模式”控制着检查点之前发生的事务日志条目。在简单模式下，当检查点发生时，它们将被删除，但是如果主数据磁盘崩溃，则存在风险，因为事务日志不包含自上次备份以来写入磁盘的更改。

在其他恢复模式，事务日志项不会被删除，直到你做一个备份，从而保护您免受这种风险...

所以，通常，发生此问题时，那是因为服务器在其中一个“正常”（而不是简单）恢复模式设置，（增量或完整），他们没有做备份......。在这种情况下，交易日志只是不断增长...，并且增长...有点像电视上的那些前列腺广告...

Answer 2

你应该看看SQL Server Recovery models。简单的答案是将恢复模式更改为“简单”，但这会影响备份/恢复。

Answer 3

我不会做20％的增长率。当它需要增长时会产生很大的后果。如果它增长到100GB，那么在下一次增长时它将不得不增长20GB--为系统的减速做准备，而不是发生这种情况......相反，我将它设置为固定速率 - 比如100MB 。当然，我们不知道目前的尺寸以作出更准确的建议。

Answer 4

备份通常会在每次备份数据库时清除事务日志。

Answer 5

这听起来像你没有适当的备份策略。执行任何备份 - 完全备份，差异备份或事务日志 - 将会截断日志，同时还可以节省您可以在发生故障时从中恢复的点。您可以运行数据库维护向导来帮助您设置定期运行的备份计划。

如果你真的不关心你的数据（在这种情况下，我想你为什么有一个数据库），那么你可以设置数据库的恢复模式为“简单”，这将阻止TLog从成长。最后一件事：如果您正在进行批量加载操作，您也可以在进行批量操作时考虑更改为“批量记录”。

Answer 6

您必须备份事务日志而不仅仅是数据库，否则日志将继续增长，直到空间用完。

Answer 7

有许多不同的方法来解决这个问题。这取决于您的备份要求。

主要问题是您的事务日志不会定期备份，这会导致事务日志不断增长。

SQL Server 2005中有一个简单恢复模式，这是我在开发和测试环境中主要使用其中不要求每小时的快照（属性/数据库本身的选项），事务日志只生长足以应付最大的事务在服务器上运行。此恢复模式不需要计划或维护计划。

在SQL Server 2000中，你基本上已经跑你使用相同的命令定时备份脚本，每小时左右：

BACKUP LOG MyDatabase WITH TRUNCATE_ONLY

对于生产环境，通常我们有一个小时事务日志备份数据库维护计划中预定的每日完整备份。这使得事务日志被截断为合理的大小（显然，这个大小可以保存1小时的事务数据）。

Answer 8

另一个简单的答案是您的备份可能没有安排。在升级周期中，我们的一个数据库备份计划已从作业中删除。日志增长直到我们发现备份没有运行。