ฉันไม่สามารถหาแหล่งข้อมูลที่ดีทางออนไลน์ได้ดังนั้นฉันจึงทำการวิจัยเชิงปฏิบัติเพิ่มเติมและคิดว่ามันจะมีประโยชน์ในการโพสต์แผนการบำรุงรักษาข้อความแบบเต็มที่เราได้นำไปใช้โดยอ้างอิงจากงานวิจัยนั้น
ฮิวริสติกของเราเพื่อกำหนดว่าต้องการการบำรุงรักษาเมื่อใด
เป้าหมายหลักของเราคือการรักษาประสิทธิภาพการค้นหาข้อความแบบเต็มตามที่ข้อมูลวิวัฒนาการในตารางที่สำคัญ อย่างไรก็ตามด้วยเหตุผลหลายประการมันเป็นเรื่องยากที่เราจะเปิดตัวชุดข้อความค้นหาที่เป็นข้อความเต็มรูปแบบสำหรับแต่ละฐานข้อมูลของเราในแต่ละคืนและใช้ประสิทธิภาพของข้อความค้นหาเหล่านั้นเพื่อพิจารณาว่าเมื่อใดที่จำเป็นต้องมีการบำรุงรักษา ดังนั้นเราจึงต้องการสร้างกฎง่ายๆที่สามารถคำนวณได้อย่างรวดเร็วและใช้เป็นฮิวริสติกเพื่อระบุว่าการบำรุงรักษาดัชนีข้อความแบบเต็มอาจได้รับการรับประกัน
ในการสำรวจครั้งนี้เราพบว่าแคตตาล็อกระบบให้ข้อมูลจำนวนมากเกี่ยวกับวิธีที่ดัชนีข้อความแบบเต็มใด ๆ ที่ถูกแบ่งออกเป็นชิ้นส่วน อย่างไรก็ตามไม่มีการคำนวณอย่างเป็นทางการ "fragmentation%" (เนื่องจากมีสำหรับดัชนี b-tree ผ่านsys.dm_db_index_physical_stats ) จากการที่ข้อมูลแฟรกเมนต์แบบเต็มเราตัดสินใจที่จะคำนวณ "การกระจายตัวของข้อความแบบเต็ม%" ของเราเอง จากนั้นเราใช้เซิร์ฟเวอร์ dev เพื่อทำการอัปเดตแบบสุ่มที่ใดก็ได้ระหว่าง 100 ถึง 25,000 แถวต่อครั้งเป็นสำเนาข้อมูลการผลิต 10 ล้านแถวบันทึกการกระจายตัวของข้อความแบบเต็มและดำเนินการสืบค้นข้อความมาตรฐานแบบเต็มรูปแบบโดยใช้CONTAINSTABLEล้านแถวของข้อมูลการผลิตการกระจายตัวของบันทึกข้อความแบบเต็มและดำเนินการสอบถามมาตรฐานเต็มรูปแบบข้อความโดยใช้
ผลลัพธ์ดังที่เห็นในแผนภูมิด้านบนและด้านล่างมีความส่องสว่างมากและแสดงให้เห็นว่าการวัดการกระจายตัวที่เราได้สร้างนั้นมีความสัมพันธ์อย่างมากกับประสิทธิภาพที่สังเกตได้ เนื่องจากสิ่งนี้ยังเกี่ยวข้องกับการสังเกตเชิงคุณภาพของเราในการผลิตนี่ก็เพียงพอแล้วที่เราจะสบายใจที่จะใช้การกระจายตัวของ% เพราะเราเรียนรู้ที่จะตัดสินใจว่าดัชนีข้อความแบบเต็มของเราต้องการการบำรุงรักษาเมื่อใด
แผนการบำรุงรักษา
เราได้ตัดสินใจที่จะใช้รหัสต่อไปนี้เพื่อคำนวณ% fragmentation สำหรับดัชนีข้อความแบบเต็มแต่ละอัน ดัชนีข้อความแบบเต็มขนาดไม่เล็กที่มีการแยกส่วนอย่างน้อย 10% จะถูกตั้งค่าสถานะเพื่อสร้างใหม่โดยการบำรุงรักษาข้ามคืนของเรา
-- Compute fragmentation information for all full-text indexes on the database
SELECT c.fulltext_catalog_id, c.name AS fulltext_catalog_name, i.change_tracking_state,
i.object_id, OBJECT_SCHEMA_NAME(i.object_id) + '.' + OBJECT_NAME(i.object_id) AS object_name,
f.num_fragments, f.fulltext_mb, f.largest_fragment_mb,
100.0 * (f.fulltext_mb - f.largest_fragment_mb) / NULLIF(f.fulltext_mb, 0) AS fulltext_fragmentation_in_percent
INTO #fulltextFragmentationDetails
FROM sys.fulltext_catalogs c
JOIN sys.fulltext_indexes i
ON i.fulltext_catalog_id = c.fulltext_catalog_id
JOIN (
-- Compute fragment data for each table with a full-text index
SELECT table_id,
COUNT(*) AS num_fragments,
CONVERT(DECIMAL(9,2), SUM(data_size/(1024.*1024.))) AS fulltext_mb,
CONVERT(DECIMAL(9,2), MAX(data_size/(1024.*1024.))) AS largest_fragment_mb
FROM sys.fulltext_index_fragments
GROUP BY table_id
) f
ON f.table_id = i.object_id
-- Apply a basic heuristic to determine any full-text indexes that are "too fragmented"
-- We have chosen the 10% threshold based on performance benchmarking on our own data
-- Our over-night maintenance will then drop and re-create any such indexes
SELECT *
FROM #fulltextFragmentationDetails
WHERE fulltext_fragmentation_in_percent >= 10
AND fulltext_mb >= 1 -- No need to bother with indexes of trivial size
ข้อความค้นหาเหล่านี้ให้ผลลัพธ์ดังต่อไปนี้และในกรณีนี้แถว 1, 6 และ 9 จะถูกทำเครื่องหมายว่ามีการแยกส่วนมากเกินไปเพื่อประสิทธิภาพที่ดีที่สุดเนื่องจากดัชนีข้อความแบบเต็มมีมากกว่า 1MB และอย่างน้อย 10% ที่มีการแยกส่วน
จังหวะการบำรุงรักษา
เรามีหน้าต่างการบำรุงรักษาทุกคืนแล้วและการคำนวณการแตกแฟรกเมนต์มีราคาถูกมากในการคำนวณ ดังนั้นเราจะเรียกใช้การตรวจสอบนี้ทุกคืนจากนั้นดำเนินการเฉพาะการดำเนินการที่แพงกว่าของการสร้างดัชนีข้อความแบบเต็มเมื่อจำเป็นตามเกณฑ์การแตกแฟรกเมนต์ 10%
สร้างใหม่กับสร้างใหม่เทียบกับ DROP / CREATE
ข้อเสนอREBUILDและREORGANIZEตัวเลือกของSQL Server แต่จะมีให้เฉพาะกับแคตตาล็อกข้อความแบบเต็ม (ซึ่งอาจมีดัชนีข้อความแบบเต็มจำนวนเท่าใดก็ได้) อย่างครบถ้วน ด้วยเหตุผลดั้งเดิมเรามีแคตตาล็อกข้อความเต็มหนึ่งรายการที่มีดัชนีข้อความแบบเต็มของเราทั้งหมด ดังนั้นเราจึงเลือกที่จะดร็อป ( DROP FULLTEXT INDEX) แล้วสร้างใหม่ ( CREATE FULLTEXT INDEX) ในระดับดัชนีข้อความแบบเต็มแทน
อาจเป็นการดีกว่าที่จะแยกดัชนีข้อความแบบเต็มออกเป็นแคตตาล็อกที่แยกกันในลักษณะที่เป็นตรรกะและดำเนินการREBUILDแทน แต่โซลูชันการปล่อย / สร้างจะทำงานให้เราในเวลาเดียวกัน
