CHECKDB错误后转储

Question

对于双节点镜像和客户需求，我有一个小问题：

每天晚上都有一个维护窗口，从01:30到03:00，我必须在其中运行reorg/reorg和checkdb (physical_only)。如果墨菲发生了，那么这两个作业都会在同一个索引/表上运行，并且Server会创建一个(Mini)转储。由于转储，主体在设定的超时时间内没有响应，镜像角色改变，导致应用程序问题。

我们晚上只有90分钟的窗口，而customer/PFE希望我们在这个窗口中运行两个作业。DBCC运行80 for，重构/重组运行30 for。

有什么建议可以绕开墨菲的那些时刻或者避开那个垃圾堆吗？

• Server 2012 SP3 CU7用于较旧的Axapta安装DB-Size
• 900 on 1TB(SSD上的数据文件)

用Ola Hallengren维护

索引：

EXECUTE dbo.IndexOptimize @Databases = 'PROD',
@FragmentationLow = NULL,
@FragmentationMedium = NULL,
@FragmentationHigh = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 50,
@FragmentationLevel2 = 80,
@SortInTempdb = 'Y',
@MaxDOP = 0,
@LogToTable = 'Y',
@TimeLimit = 3600

DBCC CHECKDB也来自Ola和Physical_only选项。

我不知道是否有“真正”的需要，每天晚上运行这些重建/重新操作，但客户告诉我们这样做(也由MSFT建议)。

我们正在与客户就扩展维护窗口进行沟通，但我想知道是否还有其他建议/提示。

实际的DBCC CHECKDB错误消息是：

DBCC (XXXX)与all_errormsgs，no_infomsgs，physical_only用用户名执行，发现2个错误，修复0错误。表错误:对象ID 111391516，索引ID 2，分区ID 720 57595795734528，分配单元ID 72057595826864128 (输入行数据)，页(7:14130686).测试(IS_OFF (BUF_IOERR，p BUF->bstat) failed.值为133129和-4。

Answer 1

当这些索引存储在Flash/SSD上时，去碎片化索引几乎毫无意义。我建议不要频繁地执行重新索引。参见Paul关于页面密度和填充因子的回答这里，以减轻索引碎片的影响。

另一方面，更新统计信息将为查询优化器提供重要线索。如果为给定数据库禁用了自动更新统计数据，请确保通过夜间作业更新统计信息。

确保您尽可能频繁地运行DBCC CHECKDB，以确保损坏不会对您的RPO产生负面影响。您可以考虑将DBCC卸载到非生产实例。这包括对非生产实例的自动备份和还原，然后在该非生产实例上自动运行DBCC。您可能需要授权运行DBCC的机器，因为它将处理生产数据，但是我会与您的Microsoft代表检查以确定。

如果您看到SQL Server正在创建内存转储，这表明应该提请Microsoft技术支持部门注意SQL Server的问题--它们可能有一个可用于解决该问题的修补程序，或者就如何解决该问题提供了一些进一步的建议。这个问题可能确实是一个需要修复的错误。

Answer 2

我想回到你的客户的决定..。以及整个“解决方案”。

客户对他自己的"ETL"-jobs进行了改进，使他们能够扩展他们的维护窗口。现在，我们在一个(第二步)中运行这两个作业。第一步(更重要)是DBCC，第二步是索引维护。

完整的运行时介于1:50和1:57之间，完全适合于维护窗口。

多谢你们的支持!