İnternette herhangi bir iyi kaynak bulamadım, bu yüzden biraz daha uygulamalı araştırma yaptım ve bu araştırmaya dayanarak uyguladığımız tam metin bakım planını göndermenin faydalı olacağını düşündüm.
Bakıma ne zaman ihtiyaç duyulduğunu belirlemek için buluşsal yöntemimiz
Birincil hedefimiz, temel tablolarda veri geliştikçe tutarlı tam metin sorgu performansını korumaktır. Bununla birlikte, çeşitli nedenlerden dolayı, her gece veritabanlarımıza karşı temsili bir tam metin sorgusu paketi başlatmamız ve bu sorguların performansını ne zaman bakıma ihtiyaç olduğunu belirlemek için kullanmamız zor olacaktır. Bu nedenle, çok hızlı bir şekilde hesaplanabilen ve tam metin dizini bakımının garanti altına alınabileceğini belirtmek için bir buluşsal yöntem olarak kullanılabilecek temel kurallar oluşturmak istiyorduk.
Bu araştırma sırasında, sistem kataloğunun verilen herhangi bir tam metin indeksinin nasıl parçalara bölündüğü hakkında çok fazla bilgi sağladığını gördük. Bununla birlikte, hesaplanan resmi bir "% fragmentasyon" yoktur ( sys.dm_db_index_physical_stats aracılığıyla b-ağacı dizinleri için olduğu gibi ). Tam metin parçası bilgisine dayanarak, kendi "tam metin parçalanma%" mizi hesaplamaya karar verdik. Daha sonra, her seferinde 100 ila 25.000 satır arasında rastgele güncellemeler yapmak, bir anda 10 milyon satırlık üretim verilerinin kopyasını yapmak, tam metin parçalanmasını kaydetmek ve tam metin sorgusunu kullanarak bir karşılaştırma yapmak için bir dev sunucu kullandık CONTAINSTABLE.
Yukarıdaki ve altındaki çizelgelerde görüldüğü gibi sonuçlar çok aydınlatıcıydı ve yarattığımız parçalanma ölçüsünün gözlemlenen performansla oldukça yüksek derecede ilişkili olduğunu gösterdi. Bu aynı zamanda üretimdeki kalitatif gözlemlerimizle de bağlantılı olduğu için, tam metin indekslerimizin ne zaman bakıma ihtiyaç duyduğuna karar vermek için% parçalanmayı sezgisel olarak kullanmamız rahattır.
Bakım planı
Her tam metin dizini için% parçalanma hesaplamak için aşağıdaki kodu kullanmaya karar verdik. En az% 10 parçalanma ile önemsiz boyutta olmayan herhangi bir tam metin indeksi, gece boyunca yapılan bakımlarımız tarafından yeniden yapılandırılmak üzere işaretlenecektir.
-- 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
Bu sorgular, aşağıdaki gibi sonuçlar verir ve bu durumda, sıralar 1, 6 ve 9, tam metin dizini 1 MB'den büyük ve en az% 10 parçalanmış olduğundan, optimum performans için fazla parçalanmış olarak işaretlenir.
Bakım ritmi
Zaten bir gece bakım penceremiz var ve parçalanma hesaplaması hesaplamak için çok ucuz. Bu yüzden her gece bu kontrolü yapacağız ve daha sonra sadece% 10 parçalanma eşiğine dayanarak gerektiğinde tam metin dizini yeniden oluşturma işleminin daha pahalı çalışmasını gerçekleştireceğiz.
REBUILD vs. REORGANİZE vs. DROP / CREATE
SQL Server teklifler REBUILDve REORGANIZEseçenekler sunar, ancak bunlar yalnızca bir tam metin kataloğu (herhangi bir sayıda tam metin dizini içerebilir) bütünüyle kullanılabilir. Eski nedenlerden dolayı, tam metin dizinlerimizin tümünü içeren tek bir tam metin kataloğumuz var. Bu nedenle, bunun yerine tek tek tam metin dizini düzeyinde ( DROP FULLTEXT INDEX) ve ardından yeniden yaratmayı ( CREATE FULLTEXT INDEX) seçtik .
Tam metin dizinlerini mantıksal bir şekilde ayrı kataloglara ayırmak ve REBUILDbunun yerine gerçekleştirmek daha ideal olabilir , ancak bırak / oluştur çözümü bu arada bizim için de işe yarayacaktır.
