事务日志已满是什么意思？我将文件设置为在需要时增长 20%。我的驱动器上还剩 4GB。如何永久解决此问题？运行这些命令可以暂时解决问题：
DBCC SHRINKFILE('MyDatabase_log', 1)
使用 TRUNCATE_ONLY 备份日志 MyDatabase
DBCC SHRINKFILE('MyDatabase_log', 1)
Bruno Tyndall
问问题
6901 次
8 回答
7
事务日志是 SQL 服务器“记录”它所做的每一个更改的地方，因此如果出现问题（从软件崩溃到电源故障，再到小行星撞击……也许不是小行星撞击），它可以“恢复”通过“撤消”自上次一致的“检查点”以来所做的所有更改 - 回到数据库的最后一次“一致”状态......在那个检查点。每次事务完成（或“提交”）时，已存储在事务日志中的所有更改都被标记为“ok”，并且 CheckPopint 标记允许在这些更改之后向前移动，以便将来恢复之后只会“撤消”更改到某个点。发生这种情况后，
正如另一位先生所提到的，您在服务器上设置的“恢复模型”控制了检查点之前对事务日志条目的影响。在简单模式下，它们会在检查点发生时被删除，但如果主数据磁盘崩溃，您将面临风险，因为您的事务日志不会包含自上次备份以来写入磁盘的更改。
在其他恢复模式中，在您进行备份之前不会删除事务日志条目，从而保护您免受此风险...
所以，一般来说，当这个问题发生时，这是因为服务器处于设置的“正常”（不简单）恢复模型之一（增量或完整）并且他们没有进行备份......。在这种情况下，交易日志一直在增长……而且在增长……有点像电视上的那些前列腺广告……
于 2008-11-19T15:56:48.393 回答
3
听起来您没有适当的备份策略。执行任何备份（完整备份、差异备份或事务日志）都将截断日志，另外还有一个好处是可以保存一个点，在发生故障时您可以从中恢复。您可以运行数据库维护向导来帮助您设置定期运行的备份计划。
如果你真的根本不关心你的数据（在这种情况下，我想知道你为什么有一个数据库），那么你可以将数据库的恢复模式设置为“简单”，这将完全阻止 TLog 增长.
最后一件事：如果您正在执行批量加载操作，您可能还会考虑在执行批量操作时更改为“批量记录”。
于 2008-11-19T16:01:37.023 回答
2
您应该查看SQL Server 恢复模型。简短的回答是将恢复模式更改为“简单”，但这对备份/恢复有影响。
于 2008-11-19T15:46:03.563 回答
2
经常备份，每次备份数据库时都会清除事务日志。
于 2008-11-19T15:52:50.473 回答
2
您必须备份事务日志而不仅仅是数据库，否则日志将继续增长，直到您用完空间。
于 2008-11-20T21:20:24.573 回答
1
另一个简单的答案是您的备份可能没有安排。在升级周期中，我们的数据库备份计划之一已从作业中删除。日志一直在增长，直到我们发现备份没有运行。
于 2012-07-12T16:40:46.030 回答
0
我不会做 20% 的增长率。当它需要增长时，这可能会产生重大影响。如果它曾经增长到，比如说，100GB，它必须在下一次增长时增长 20GB - 准备好让你的系统变慢，而不是在这种情况发生时......相反，我会将它设置为固定速率 - 比如 100MB . 当然我们不知道当前的尺寸来做出更准确的推荐。
于 2008-11-19T15:49:20.467 回答
0
有许多不同的方法可以解决这个问题。这取决于您的备份要求。
主要问题是您的事务日志没有定期备份，这导致事务日志不断增长。
SQL Server 2005 具有简单恢复模式（数据库本身的属性/选项），我主要在不需要每小时快照的 DEV 和 TEST 环境中使用它，事务日志仅增长到足以处理服务器上运行的最大事务. 此恢复模式不需要计划或维护计划。
在 SQL Server 2000 中，您基本上有一个计划的备份脚本，该脚本运行您使用的相同命令，大约每小时一次：
BACKUP LOG MyDatabase WITH TRUNCATE_ONLY
对于生产环境，通常我们在数据库维护计划中安排了每小时的事务日志备份和每日的完整备份。这可以将事务日志截断到合理的大小（显然，这个大小可以保存 1 小时的事务数据）。
于 2008-11-26T02:22:07.893 回答