当在大型和高度支离破碎的数据库上一夜之间运行索引重建脚本时,我们经常会遇到停止作业的索引,因为它们似乎从未完成它们的重新构建。作业已经停止,早上我们必须手动取消语句,永远等待回滚,导致停机。我们可以补救这些偶尔的索引,我手动删除和重新创建。
如果没有什么进展,是否有一种方法可以自动超时索引重建语句,以便脚本可以继续执行下一个重新构建语句?
我们的脚本的形式如下:
ALTER INDEX ALL ON [Table1] REBUILD WITH (FILLFACTOR = 90)
ALTER INDEX ALL ON [Table2] REBUILD WITH (FILLFACTOR = 90)
我有一个SQL Server代理作业,该作业重建两个计划每天运行的索引。我这样做的原因是为了提高存储过程的性能。
当代理作业按计划运行时,它不会影响存储过程的性能,但是,如果我手动运行该作业,则会影响性能。
查看作业的日志,手动运行和计划运行都完成,没有错误,甚至花费了相似的时间才能完成。日志甚至表明它们都是以同一用户身份运行的。
我在预定的实施中遗漏了什么,或者如何安排它的另一种方式?
作业的T-SQL:
USE [TestingDB]
GO
ALTER INDEX [_dta_index_TestingOrders_randomIndex]
ON [dbo].[Orders]
REB
最近,我们遇到了一个问题,在这个问题上,事务日志增长并耗尽了存储空间。这发生在维护窗口(使用Ola Hallengren索引优化脚本)。由于某些原因,过去有人将事务日志备份设置为停止3小时,似乎是在索引作业运行时(它们被设置为运行3小时)。
我的组织最近从2008 r2迁移到了sql server 2016。从事迁移的人员更改了不处理事务日志的窗口,缩短了30分钟,所以现在5:30开始工作。我想他认为他们是为了全力支援而被阻止的。但我相信他们是被阻止让索引维护运行的。在这两种情况下都有这个必要吗?似乎停止tlog备份比帮助更有害。
sql server 2008r2计划为:
凌晨3:00:事
我目前正致力于将sqlserver2008r2迁移到SQL server 2016。我之前的DBA使用了https://ola.hallengren.com/downloads.html中的“C0”来创建iIndex解决方案。我可以看到作业是按月调度和运行的,逻辑应用是:如果碎片< 20,那么重新组织索引,如果碎片> 40,重构索引,我计划通过SSMS使用维护计划来重组或重建索引。如何找到哪一个已经运行了“重组/重建”,我可以看到一些表的碎片在66以上。认为重建指数没有发生是对的吗?