為什麼全文索引落後了?
我在表格上設置了全文索引;該表處於相當恆定的負載下,每天接收約 50k 插入和約 35k 刪除,插入之間的間隔相當短(最多 5 分鐘)。
索引配置為自動更改跟踪,通常能夠在插入後的幾秒鐘內處理所有文件。然而,昨日監測提醒,該指數已超過 4 小時未更新。
收到該警報後,我檢查了以下內容:
- 全文日誌中沒有出現新條目。最後一個條目是資訊性的 - 全文自動填充已完成。
- 索引填充狀態(由 sys.dm_fts_index_population 報告)停留在“已停止處理”。
- 單個會話執行命令“FT BATCH CMPLETE”佔用了整個 CPU 核心。該會話的 last_request_start_time 在全文日誌中最後一個條目的幾秒鐘內。除此之外,CPU 處於空閒狀態。
- 兩個(共 30 個)片段的狀態為 6 / 正在用於合併輸入並準備好查詢(由 sys.fulltext_index_fragments 報告);這些片段的大小每個接近 60GB。
大約 10 小時後,索引恢復和停止時一樣神秘。
我認為索引因為合併而暫停是正確的嗎?如果不是,我還可以檢查什麼以獲得更好的診斷?
該問題大約每月在不同的伺服器上發生兩次。據我所知,索引沒有按計劃重組或重建。我正在尋找一種解決方案,它可以讓我完全避免索引暫停,或者在維護停機期間安排它們。伺服器是 SQL Server 2012 Enterprise。
顯然 MS SQL Server 2012 不能並行執行多個索引執行緒。由於索引執行緒在完成對目前批次文件的索引後可能會執行合併,因此索引暫停是不可避免的。
手動更改跟踪無濟於事。在執行合併時,在單獨會話上執行的多個 UPDATE POPULATION 命令也會相互阻塞。
可以控制要合併的片段的大小,例如通過重新組織索引。重組操作將所有索引片段合併為一個。reorganize 創建的片段太大而無法合併,而新片段相當小,因此合併它們很快。
在我們的案例中,新的索引碎片需要幾週時間才能達到數 GB,並且可以選擇每週重組。
似乎有一些查詢您可以嘗試從正在發生的事情中獲取更多資訊。從Stackoverflow中提取的以下查詢利用了
FULLTEXTCATALOGPROPERTY
.DECLARE @CatalogName VARCHAR(MAX) SET @CatalogName = 'FTS_Demo_Catalog' SELECT DATEADD(ss, FULLTEXTCATALOGPROPERTY(@CatalogName,'PopulateCompletionAge'), '1/1/1990') AS LastPopulated ,(SELECT CASE FULLTEXTCATALOGPROPERTY(@CatalogName,'PopulateStatus') WHEN 0 THEN 'Idle' WHEN 1 THEN 'Full Population In Progress' WHEN 2 THEN 'Paused' WHEN 3 THEN 'Throttled' WHEN 4 THEN 'Recovering' WHEN 5 THEN 'Shutdown' WHEN 6 THEN 'Incremental Population In Progress' WHEN 7 THEN 'Building Index' WHEN 8 THEN 'Disk Full. Paused' WHEN 9 THEN 'Change Tracking' END) AS PopulateStatus FROM sys.fulltext_catalogs AS cat
但是,在這篇文章中,微軟提到
在表級別檢查相應的 PopulateStatus 屬性通常是更好的選擇,即 OBJECTPROPERTYEX 系統函式中的 TableFullTextPopulateStatus。OBJECTPROPERTYEX 中的這個和其他新的全文屬性提供了有關全文索引表的更詳細的資訊。
為此,我將使用以下腳本:
DECLARE @TableId VARCHAR(MAX) SET @TableId = OBJECT_ID('gGastroversion') Select CASE OBJECTPROPERTYEX ( @TableId , 'TableFullTextPopulateStatus' ) WHEN 0 THEN 'Idle' WHEN 1 THEN 'Full Population In Progress' WHEN 2 THEN 'Full population is in progress.' WHEN 3 THEN 'Propagation of tracked changes is in progress.' WHEN 4 THEN 'Background update index is in progress, such as autochange tracking.' WHEN 5 THEN 'Full-text indexing is throttled or paused.' WHEN 6 THEN 'An error has occurred. Examine the crawl log for details' END
請注意,如果結果為 6,它將告訴您檢查爬網日誌。可以在此處找到此資訊的故障排除。