9

所以我们的 SQL Server 2000 给我一个错误,“数据库的日志文件已满。备份数据库的事务日志以释放一些日志空间。”

我该如何解决这个问题而不像其他一些网站提到的那样删除日志?

附加信息:启用 AutoGrowth 启用增长 10% 并限制为 40MB。

4

12 回答 12

18

只是清空它:

backup log <dbname> with truncate_only  

将其保存在某处:

backup log <dbname> to disk='c:\somefile.bak'

如果您真的不需要事务历史记录,请尝试将数据库恢复模式设置为简单。

于 2008-09-16T14:41:26.843 回答
4

斯科特,正如您所猜测的:如果您关心您的数据,那么截断日志是一个糟糕的举动。

以下免费视频将帮助您准确了解正在发生的事情,并向您展示如何在不截断日志的情况下解决问题。(这些视频还解释了为什么这是一个如此危险的黑客攻击,以及为什么寻找其他解决方案是正确的。)

这些视频将帮助您准确了解正在发生的事情,并向您展示是否要切换到简单恢复,或者考虑实际更改备份例程。还有一些额外的“操作指南”视频将向您展示如何设置备份以确保可用性,同时管理日志文件的大小和增长。

于 2008-09-16T16:53:21.287 回答
2

我不认为在数据库在线时重命名或移动日志文件会起作用。

IMO,最简单的事情是打开数据库的属性并将其切换到简单恢复模型。然后缩小数据库,然后返回并将数据库设置为 Full Recoery 模型(或您需要的任何模型)。

更改日志记录模式会强制 SQL Server 在数据库中设置检查点,之后收缩数据库将释放多余的空间。

于 2008-09-16T14:37:25.060 回答
2

如果您需要恢复到最新状态或在未来做其他有趣的事情(例如日志传送),或者将数据库设置为简单模式并缩小数据文件,请定期备份您的数据库日志。

请勿复制、重命名或删除 .ldf 文件,这将破坏您的数据库,并且在您从中恢复后,您的数据可能会处于不一致的状态,从而使其无效。

于 2008-09-16T20:50:06.817 回答
1

我过去遇到此错误的朋友建议:

尝试

  • 备份数据库。维护计划包括截断这些文件。
  • 还尝试将数据库的“恢复模式”更改为简单(例如,而不是完整

原因:由于记录的事件导致事务日志膨胀(也许您有许多事务失败并被回滚..或者服务器上的事务突然达到峰值)

于 2008-09-16T14:58:12.750 回答
1

您可能需要检查相关的 SO 问题:

于 2008-09-16T16:08:32.127 回答
0

好吧,您可以获取事务日志的副本,然后截断日志文件,这就是错误消息所暗示的。

如果磁盘空间已满并且您无法通过网络将日志复制到另一台计算机,则通过 USB 连接驱动器并以这种方式将其复制。

于 2008-09-16T14:37:09.710 回答
0

您的问题有答案:备份日志,然后将其缩小。制定维护计划,定期备份数据库,不要忘记选择“备份事务日志”。这样你就可以保持小。

于 2008-09-16T14:38:12.500 回答
0

如果是非生产环境使用

dump tran <db_name> with no_log;

完成此操作后,缩小日志文件以释放磁盘空间。最后将数据库恢复模式切换为简单。

于 2008-09-16T14:47:30.840 回答
0

一旦您对数据库进行了完整备份,并且数据库未使用简单恢复模型,SQL Server 就会完整记录数据库上曾经执行的所有事务。这样做是为了在您丢失数据文件的灾难性故障事件中,您可以通过备份日志恢复到故障点,并且在恢复旧数据备份后,恢复日志以重播丢失的数据交易。

为防止这种情况累积,您必须备份事务日志。或者,您可以使用 BACKUP LOG 的 TRUNCATE_ONLY 或 NO_LOG 选项在当前点断开链。

如果您不需要此功能,请将恢复模式设置为简单。

于 2008-09-16T15:14:26.860 回答
0

我亲爱的朋友,对于 DBA 来说,经常检查他的日志文件非常重要。因为如果有一天你不给予太多关注,它会给出这个错误。

为此,您必须定期进行备份,以便日志文件不会遇到此类错误。

除此之外,上面给出的建议是完全正确的。

于 2012-06-11T11:38:34.897 回答
-1

重命名它。例如:
old-log-16-09-08.log

然后 SQL 服务器可以使用一个新的空的。

于 2008-09-16T14:34:25.597 回答