由于 log_backup,事务日志已满

The*_*war 7 sql-server transaction-log

我正在测试如何在不同的恢复模式下记录某些操作。以下是我到目前为止所做的步骤

1.在完全恢复模式下
创建数据库2.进行备份
3.创建一个表并插入 1000 万条记录
4.进行日志备份,检查 VLF 计数并查看日志空间可用百分比
5.现在进行索引重建并查看使用生成的记录fn_dblog 函数

6.现在我切换到批量恢复模型
7.进行了备份
8.进行了日志备份
9.进行了索引重建

奇怪的是,索引重建失败并出现以下错误。

该语句已终止。消息 9002,级别 17,状态 2,第 1 行 由于“LOG_BACKUP”,数据库“bulklogging”的事务日志已满。

那不是真的,实际上

1.日志空间自动增长不受限制

自增长设置

2.存储日志文件的空间

存储日志文件的驱动器上的空间

有人可以帮助我理解为什么我会遇到错误,即使有空间并且没有限制自动增长

添加索引大小的图像..

问题已解决,但不确定此更改有何不同。任何指针将不胜感激..

评论说两个长——所以在这里发帖......

我再次编写了索引,在更改恢复模型之后它起作用了。而且之前和之后的脚本索引完全保持不变,只有会话发生了变化。但我不确定这是如何工作的。

前 :

USE [bulklogging]  
GO  
ALTER INDEX [PK__bcc__3213E83FAC9DB5ED] ON [dbo].[bcc] 
REBUILD PARTITION = ALL WITH (PAD_INDEX = OFF, 
STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO
Run Code Online (Sandbox Code Playgroud)

后:

USE [bulklogging]  
GO  
ALTER INDEX [PK__bcc__3213E83FAC9DB5ED] ON [dbo].[bcc] 
REBUILD PARTITION = ALL WITH (PAD_INDEX = OFF, 
STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO
Run Code Online (Sandbox Code Playgroud)

更新关闭这个问题:
我使用Fn_dblog检查日志记录,这似乎有描述一个隐藏的Bug在这里,这可能会影响我的日志增长..

2013 年 8 月 15 日编辑:当心——乔纳森刚刚从一个广泛使用它的客户系统中发现,每次调用 fn_dump_dblog 时,它都会创建一个新的隐藏 SQLOS 调度程序和最多三个线程,这些线程不会消失(并且不会被重用)直到服务器重新启动。这是 SQL 团队将要修复的错误,现在我们已提醒他们注意。谨慎使用。

2015 年 5 月 15 日编辑:它已在 SQL Server 2012 SP2+ 和 SQL Server 2014 中修复。该修复程序不会更早地向后移植。

在此处输入图片说明

Moh*_*MVP 6

发生此错误的原因是事务日志因LOG_BACKUP. 因此,您不能对此数据库执行任何操作,并且在这种情况下,

SQL Server数据库引擎将引发9002错误

要解决此问题,您必须执行以下操作:

  • 进行完整的数据库备份。
  • 收缩日志文件以减小物理文件大小。
  • 创建一个 LOG_BACKUP。
  • 创建 LOG_BACKUP 维护计划以频繁获取备份日志。

注意:执行shrink 命令时,Shrink 操作会影响SQL Server 性能。它还会导致索引碎片化,并会降低搜索索引范围的查询的性能。

所以,建议上线前准备LOG_BACKUP维护计划,经常备份日志文件,避免Production上的收缩操作。

有关更多详细信息,请检查数据库“SharePoint_Config”的事务日志由于 LOG_BACKUP 而已满

希望这对你有帮助