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 中修复。该修复程序不会更早地向后移植。
发生此错误的原因是事务日志因LOG_BACKUP
. 因此,您不能对此数据库执行任何操作,并且在这种情况下,
要解决此问题,您必须执行以下操作:
注意:执行shrink 命令时,Shrink 操作会影响SQL Server 性能。它还会导致索引碎片化,并会降低搜索索引范围的查询的性能。
所以,建议上线前准备LOG_BACKUP维护计划,经常备份日志文件,避免Production上的收缩操作。
有关更多详细信息,请检查数据库“SharePoint_Config”的事务日志由于 LOG_BACKUP 而已满
希望这对你有帮助
归档时间: |
|
查看次数: |
99622 次 |
最近记录: |