CHECKDB 錯誤後轉儲
我對雙節點鏡像和客戶要求有點問題：
每晚從 01:30 到 03:00 都有一個維護視窗，在此期間我必須執行rebuild/reorg 和 checkdb（physical_only）。如果 Murphy 發生，兩個作業都在同一個索引/表上執行，SQL Server 會創建一個（小型）轉儲。由於轉儲，主體在設置的超時期限內沒有響應，鏡像角色發生變化，導致應用程序出現問題。
我們晚上只有 90 分鐘的視窗，客戶/PFE 希望我們在這個視窗中執行這兩個作業。DBCC 執行約 80 分鐘，重建/重組約 30 分鐘。
有什麼建議可以繞過墨菲時刻或避免轉儲嗎？
- SQL Server 2012 SP3 CU7 由較舊的 Axapta 安裝 DB-Size 使用
- 900GB-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 Hallengren 的Physical_only選項。我不知道是否有“真正的”需要每晚執行這些重建/重組，但客戶告訴我們這樣做（也由 MSFT PFE 建議）。
我們正在與客戶就擴大維護視窗進行溝通，但我想知道是否有其他建議/提示。
實際的
DBCC CHECKDB錯誤資訊是：DBCC CHECKDB (XXXX) WITH all_errormsgs, no_infomsgs,physical_only 由 Username 執行，發現 2 個錯誤並修復 0 個錯誤。
表錯誤：對象 ID 111391516，索引 ID 2，分區 ID 720 57595795734528，分配單元 ID 72057595826864128（行內數據類型），頁面 (7:14130686)。
測試（IS_OFF (BUF_IOERR, p BUF->bstat)）失敗。
值為 133129 和 -4
當這些索引儲存在快閃記憶體/SSD 上時，對索引進行碎片整理幾乎毫無意義。我建議減少執行重新索引的頻率。請參閱 Paul在此處關於頁面密度和填充因子的回答，以減輕索引碎片的影響。
另一方面，更新統計資訊將為查詢優化器提供重要線索。如果給定數據庫禁用了自動更新統計資訊，請確保您通過夜間作業更新統計資訊。
確保您
DBCC CHECKDB盡可能頻繁地執行，以確保損壞不會對您的 RPO 產生負面影響。您可以考慮將 DBCC CHECKDB 解除安裝到非生產實例。這包括自動備份和恢復到非生產實例，然後在該非生產實例上自動執行 DBCC CHECKDB。您可能需要對執行 DBCC CHECKDB 的機器進行許可，因為它將處理生產數據，但我會與您的 Microsoft 代表核實以確定。如果您看到 SQL Server 創建記憶體轉儲，則表明 SQL Server 存在問題，應引起 Microsoft 技術支持的注意 - 他們可能有可用的修補程序來解決問題，或者他們可能會提供一些關於如何解決該問題。這個問題可能確實是一個需要修復的錯誤。