数据库 'DJABC' 的日志已满.请备份该数据库的事务日志以释放一些日志空间.

Posted 2023-05-15

数据库 'DJABC' 的日志已满。请备份该数据库的事务日志以释放一些日志空间。
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Data.SqlClient.SqlException: 数据库 'DJABC' 的日志已满。请备份该数据库的事务日志以释放一些日志空间。

Stack Trace:

[SqlException (0x80131904): 数据库 'DJABC' 的日志已满。请备份该数据库的事务日志以释放一些日志空间。]

求会的教教，实在不会备份清楚

数据库组成：sqlserver数据库是由2个文件 组成的，一个是数据文件，一个日志文件；数据文件保存系统所有数据，日志文件保存的是对数据库所有的修改细节；通常情况下日志文件的增长速度比数据文件要快得多，一段时间后，我们就需要对日志文件进行清理，否则一旦日志文件超过磁盘的可用空间大小，就会导致数据库服务无法正常进行，所有对数据库的操作都会失败。 查看组成数据库2个文件的位置：，进入企业管理器，找到要查看的数据库，鼠标右键点击弹出菜单，选择“属性”。
数据文件和日志文件：显示出数据文件位置，大小，和增长规则等，同理，你可以切换到“事务日志”页面查看日志文件的相关信息。
一、清除日志：
1、选择数据 “DJABC”，鼠标右键弹出菜单，选择“所有任务”“分离数据库”。
2、分离数据库：
如果有其他程序当前正连接到本数据库，请点击“清除”按钮清除所有连接，然后按下
“确定”按钮即可完成对数据库的分离。
3、删除数据库的日志文件：数据库一旦被分离后，你可以直接删除数据库的日志文件。
4、附加数据库：依次选择菜单 “数据库”“所有任务”“附加数据库”，系统会弹出附加数据库窗口。
5、选择数据文件和附加数据库名称，完成后按下确定即可将刚刚分离的数据库重新加到当前 sqlserver服务器上。
6、所有完成后，系统重新创建日志文件，新创建的日志文件大小为1K，等到以后长到很大时，再执行上面的日志清除过程即可。
二、备份
在企业管理器中SQL服务器-Northwind-右键-所有任务-备份数据库, 然后在图形界面下进行相应的操作,这是非常简和安全的 。 参考技术A 数据库右键属性--文件--日志文件--自动增长设置不限制文件增长
数据库右键任务 --收缩--文件--文件类型：日志文件 参考技术B 中科同向HeatsOne Backup™ 备份和恢复软件结合，Microsoft SQL Server与当前任务相关的信息会被截取，同时发送一个拷贝到HeatsOne Backup™ 日志，并且与其他的HeatsOne Backup任务信息一起显示。Microsoft SQL Server插件模块通过快速在线备份Windows NT和2003，2008等环境下的SQL数据库，提高了应用的可用性。其广泛特色主要包括热备份、多种备份操作和高级日志功能。

数据库中事务日志已满的潜在原因和解决方案[关闭]

【中文标题】数据库中事务日志已满的潜在原因和解决方案[关闭]

【英文标题】：Potential causes and solutions for the transaction log in database being full [closed]

【发布时间】：2012-12-08 04:38:43

【问题描述】：

在我的团队 ASP.NET 应用程序的数据访问层中，我通过使用 .NET SQLClient 对我们的数据库运行存储过程。添加新代码以允许对数据库进行插入操作后，我测试了代码，并收到以下异常：

The transaction log for database 'DBName' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

我确认在 MS SQL Server Management Studio 中尝试插入操作时收到了相同的消息。我很担心，因为我最近在数据库中添加了三个两个触发器，以基于插入和更新某些表来执行一些数据插入，并且我认为我可能会导致无限循环或类似性质的东西。

但是，根据其他在线问题的实例，这似乎不是一般由触发器或旋转查询引起的问题。我查询了log_reuse_wait 和log_reuse_wait_desc 列并返回了以下内容：

2 | LOG_BACKUP

另外，查询SELECT [name], recovery_model_desc, log_reuse_wait_desc FROM sys.databases 返回：

name | recovery_model_desc| log_reuse_wait_desc

DBName|   FULL            | LOG_BACKUP

其中第一列是log_reuse_wait，第二列是log_reuse_wait_desc。 根据msdn 上代码的定义，我需要执行日志备份，然后可以自动截断日志，以便对数据库进行进一步的操作。这是一个正确的假设吗？这可能是由错误编码的触发器引起的，还是更多的日常维护任务，由数据库上的大量事务引起？

编辑：

查询select type_desc, size, max_size from sys.database_files 返回：

   type_desc | size | max_size
1| ROWS      |  512 | -1
2| LOG       |  64  |  -1

【问题讨论】：

你知道你对这个数据库的备份策略吗？

“select type_desc, size, max_size from sys.database_files”返回什么？

是的，这就是文档所说的以及您需要做的。如果触发器添加、更新或删除，则将被记录。如果触发器不必要地添加、更新或删除，则将被不必要地记录。问题是你需要一个完整的恢复模型吗？

我相信每天都有一个自动备份的任务集，生成一个 .bak 文件。恢复模型列指示它是“完整”备份？我想。我看了看，我相信服务器已经用完了磁盘空间，所以可能阻止了根据需要生成备份，因此不允许截断事务日志？

除了 FULL 之外，还有哪些其他选项？备份与数据库相关的所有内容不是最佳做法吗？还是 FULL 也存储其他信息？

【参考方案1】：

如果您的数据库处于完全恢复模式，则日志不会被截断（截断是一个糟糕的词，我希望他们选择其他内容）直到执行日志备份。基本上，当您将数据库置于 FULL 恢复模式时，您就是在告诉 SQL Server 您需要时间点恢复。为了做到这一点，SQL Server 需要来自上次完整（或差异）备份的完整日志链，并且为了做到这一点，它不会重新使用（“截断”）日志空间，直到您备份了日志.

这是处于完全恢复模式的数据库的例行操作问题。如果您不需要时间点恢复，请将您的数据库设置为 SIMPLE 恢复模式 - 这将自动重用日志空间，但您只能恢复到上次的完整/差异备份。

如果您确实需要时间点恢复，那么您需要（嗯，您的 DBA 团队需要）设置一个定期执行日志备份的维护计划。

【讨论】：

谢谢，我相信这告诉我我需要什么。