Full-Text Search Part-II

Full-Text Index Fragmentation and Crawl Full-Text Index kullanırken kontrol edilmesi gereken 2 bilgi vardır. Bunlardan biri fragmentation diğeri ise Crawl bilgisi. Fragmentation Bilgisine aşağıdaki scriptinden ulaşılabilir; WITH FragmentationDetails AS ( SELECT table_id, COUNT(*) AS FragmentsCount, CONVERT(DECIMAL(9,2), SUM(data_size/(1024.*1024.))) AS IndexSizeMb, CONVERT(DECIMAL(9,2), MAX(data_size/(1024.*1024.))) AS largest_fragment_mb FROM sys.fulltext_index_fragments GROUP BY table_id ) SELECT DB_NAME() AS DatabaseName, ftc.fulltext_catalog_id AS CatalogId, ftc.[name] AS CatalogName, fti.change_tracking_state AS ChangeTrackingState, fti.object_id AS BaseObjectId, QUOTENAME(OBJECT_SCHEMA_NAME(fti.object_id)) + '.' + QUOTENAME(OBJECT_NAME(fti.object_id)) AS BaseObjectName, f.IndexSizeMb AS IndexSizeMb, f.FragmentsCount AS FragmentsCount, f.largest_fragment_mb AS IndexLargestFragmentMb, f.IndexSizeMb - f.largest_fragment_mb AS IndexFragmentationSpaceMb, CASE WHEN f.IndexSizeMb = 0 THEN 0 ELSE 100.0 * (f.IndexSizeMb - f.largest_fragment_mb) / f.IndexSizeMb END AS IndexFragmentationPct FROM sys.fulltext_catalogs ftc JOIN sys.fulltext_indexes fti ON fti.fulltext_catalog_id = ftc.fulltext_catalog_id JOIN FragmentationDetails f ON f.table_id = fti.object_id ; Full-text crawl olduğunda veri akışı sağlanmaz ve aramalarda veriyi bulamayabilirsiniz. Aramanın devam etmesi için aşağıdaki script çalıştırılmalı. ALTER FULLTEXT INDEX ON CatalogName SET CHANGE_TRACKING MANUAL; ALTER FULLTEXT INDEX […]

Full-Text Search Part-II

Full-Text Index Fragmentation and Crawl
Full-Text Index kullanırken kontrol edilmesi gereken 2 bilgi vardır. Bunlardan biri fragmentation diğeri ise Crawl bilgisi.

Fragmentation Bilgisine aşağıdaki scriptinden ulaşılabilir;

WITH FragmentationDetails
AS (
	SELECT 
		table_id,
        COUNT(*) AS FragmentsCount,
        CONVERT(DECIMAL(9,2), SUM(data_size/(1024.*1024.))) AS IndexSizeMb,
        CONVERT(DECIMAL(9,2), MAX(data_size/(1024.*1024.))) AS largest_fragment_mb
    FROM sys.fulltext_index_fragments
    GROUP BY table_id
)
SELECT 
	DB_NAME()				AS DatabaseName,
	ftc.fulltext_catalog_id AS CatalogId, 
	ftc.[name]				AS CatalogName, 
	fti.change_tracking_state AS ChangeTrackingState,
    fti.object_id				AS BaseObjectId, 
	QUOTENAME(OBJECT_SCHEMA_NAME(fti.object_id)) + '.' + QUOTENAME(OBJECT_NAME(fti.object_id)) AS BaseObjectName,
	f.IndexSizeMb		    AS IndexSizeMb, 
	f.FragmentsCount    	AS FragmentsCount, 
	f.largest_fragment_mb   AS IndexLargestFragmentMb,
	f.IndexSizeMb - f.largest_fragment_mb AS IndexFragmentationSpaceMb,
    CASE
		WHEN f.IndexSizeMb = 0 THEN 0
		ELSE 
			100.0 * (f.IndexSizeMb - f.largest_fragment_mb) / f.IndexSizeMb
	END AS IndexFragmentationPct
FROM 
	sys.fulltext_catalogs ftc
JOIN 
	sys.fulltext_indexes fti
ON 
	fti.fulltext_catalog_id = ftc.fulltext_catalog_id
JOIN FragmentationDetails f
    ON f.table_id = fti.object_id
;

Full-text crawl olduğunda veri akışı sağlanmaz ve aramalarda veriyi bulamayabilirsiniz.
Aramanın devam etmesi için aşağıdaki script çalıştırılmalı.
ALTER FULLTEXT INDEX ON CatalogName SET CHANGE_TRACKING MANUAL; ALTER FULLTEXT INDEX ON TableName SET CHANGE_TRACKING AUTO

Yukarıdaki script çalıştırıldıktan sonra,

select 
FULLTEXTCATALOGPROPERTY ('CatalogName','ItemCount') as [ItemCount],
FULLTEXTCATALOGPROPERTY ('CatalogName','MergeStatus') as [MergeStatus],
FULLTEXTCATALOGPROPERTY ('CatalogName','PopulateCompletionAge') as [PopulateCompletionAge],--Bu değeri aşağıda dateadd kısmında kullanacağız.
FULLTEXTCATALOGPROPERTY ('CatalogName','PopulateStatus') as [PopulateStatus],
FULLTEXTCATALOGPROPERTY ('CatalogName','ImportStatus') as [ImportStatus]
from sys.fulltext_catalogs as cat

scripti ile [PopulateCompletionAge] konu altında gelen veri takip edilmeli, dönen sayıyı;
select DATEADD (ss, PopulateCompletionAge değeri,’1/1/1990′)
sorgusuna bakılarak hangi tarihi crawl ettiği gözlemlenmeli.
!Eğer ki PopulateCompletionAge değişme gözlemlenmiyorsa;

Alter FULLTEXT INDEX On CatalogName Start update Population

komutu ile crawl update edilmeli.
Bu scrip ile crawl_type_desc değeri full_crawl’dan update crawl’a dönmesi beklenmeli. Tablo eğer küçük ise bu kısa zamanda olur. Eğer ki büyük ise günler alabilir.

SELECT [t].[name] [table_name], 
       [i].[name] [index_name],
       [fi].[change_tracking_state_desc], 
       [fi].[has_crawl_completed], 
       [fi].[crawl_type_desc], 
       [fi].[crawl_end_date],
       [ius].[last_user_update], 
       [ius].[last_user_seek],
       (SELECT [name]+',' FROM [sys].[fulltext_index_columns] [fc] INNER JOIN [sys].[columns] [c] ON [c].[object_id] = [fc].[object_id] AND [c].[column_id] = [fc].[column_id] WHERE [fc].[object_id] = [fi].[object_id] FOR XML PATH('')) [columns],
       (CASE WHEN [fi].[crawl_end_date] < ISNULL([ius].[last_user_update], [ius].[last_user_seek]) THEN 'ALTER FULLTEXT INDEX ON ['+[t].[name]+'] SET CHANGE_TRACKING MANUAL; ALTER FULLTEXT INDEX ON ['+[t].[name]+'] SET CHANGE_TRACKING AUTO' ELSE '' END) [Command]
FROM [sys].[fulltext_indexes] [fi]
INNER JOIN [sys].[indexes] [i] ON [i].[index_id] = [fi].[unique_index_id] AND [i].[object_id] = [fi].[object_id]
INNER JOIN [sys].[tables] [t] ON [t].[object_id] = [fi].[object_id]
LEFT JOIN [sys].[dm_db_index_usage_stats] [ius] ON [ius].[index_id] = [fi].[unique_index_id] AND [ius].[object_id] = [fi].[object_id] AND [ius].[database_id] = DB_ID()
ORDER BY [table_name], [index_name]

Benzer Yazılar

SQL SERVER SERViS RESTART HATASI

SQL Server 2 hafta önce

Bu haftaki yazımızda karşılan bir hata üzerindeki; logları ve çözümünü anlatacağım. Aşağıdaki GÖRSEL-1’de görüldüğü üzere SQL servisini restart ettiğimiz sırada bir hata ile karşılaşıyoruz. Servis running state’e geçemiyor. “The request failed or the service did not respond in a timely fashion. Consult the event log or other applicable error logs for details” şeklinde bir uyarı veriyor. Hatanın çözümüne doğru ilerlerken farklı servis hesaplarıyla veya “Local System” hesabı ile restart etmeye çalıştığınızda servis ilginç bir şekilde ayağa kalkıyor. Ancak Always on sistem çalışıyorsanız farklı servis hesaplarını kullandığınızda always on size haberleşme izni vermiyor. Aynı hesabın şifresi ile ilgili sorunlar olduğu düşünüp hesabın şifresini de değiştirdiğiniz de yine sonuç alamıyorsunuz. Burdan yola çıkıldığında sıkıntı servis hesabında gibi görünüyor olabilir ancak çözüme geçildiğinde regedit üzerinde yapacağımız bir işlem ile sorunu çözüyoruz. Servis hesabının kaydının olduğu regedit kaydını siliyoruz. Regedit üzerindeki servis hesap bilgisi güncellendiğinde sorun çözülmüş olmakta. GÖRSEL-1  Servis restart edildiğinde SQL’in verdiği Error […]

SQL’DE İKİ NODE’UN RESOLVING DURUMA DÜŞMESİ VE ÇÖZÜMÜ

SQL Server 1 ay önce

Bu yazımızda failover olma işlemi esnasında karşılaşılan bir durumdan kısaca bahsedeceğim. Kısa bir yazı olacak ama önemli olduğunu düşünüyorum. Bazen failover olmak istediğinizde cluster secondary’e node’a failover olamaz, hem secondary hem de primary node’unuz resolving durumuna geçer. Bu durumla daha çok otomatik failover olma durumlarında karşılaşılır çünkü sistem failover’a aslında hazır değildir ancak cluster bunu bir şekilde bilemez. Failover olma gerçekleşemez bir anlamda sql cluster askıda kalır ve hiçbir sunucu da sql engine çalışmaya devam edemez. (GÖRSEL-1) GÖRSEL-1 GÖRSEL-1 üzerinde gördüğünüz üzere availability group resolving duruma düşer. Availability replica’lar üzerinde de gördüğünüz üzere primary ve secondary tüm node’lar resolving state’e düşer. Böyle bir durumunda iki farklı çözüm yolumuz var;   Çözüm: ikinci node’a sunucu restart’ı atmak. Bu noktada secondary sql node’a servis restart atmak işe yaramıyor. Zaten db’ler iki taraflı resolving modda. O sebeple ancak sunucu restart atıldığında cluster ayakta olan sunucuyu görüyor ve askıda kalma durumundan ilk başta primary […]

Query Store Nedir?

SQL Server 1 ay önce

Query Store ile birlikte execution planın seçimi ve bu sürecin performansa etkisini anlayabiliriz. SQL Server içerisinde bulunan Query Store özelliği, çalıştırılan sorguların execution planını ve bu sırada oluşan istatistiklerini otomatik olarak yakalar. Böylece query plan değişikliği ile oluşan problemleri de hızlı ve kolay şekilde fark edebiliriz. Elinizde bulunan bir sorguya ait query plan zamanla değişebilir. Bunun birçok sebebi vardır. Tablo yapısına yeni bir column eklenmesi Veri tipinin değiştirilmesi Sorgularda yeni parametrelerin eklenip çıkarılması Verilerde, schemalarda veya sorgu parametrelerindeki değişiklik Burada önemli olan ise bazen bu değişimler sorgunun yavaş çalışmasına neden olur. Query Store ile beraber bu yavaşlığın kök nedenine inmek daha kolay oldu. Ayrıca query store sayesinde ilgili sorguya ait read-write bilgileri ve cpu tüketimi bilgilerine de erişebilirsiniz. Query Store’u veritabanı seviyesinde aktif edebiliyoruz. Veritabanı üzerine sağ tıklayarak properties diyoruz ve Query Store sekmesine geliyoruz. Operation Mode alanından Read Write’ı seçiyoruz. Böylelikle Query Store gerekli bilgiyi toplayabilir ve size ilgili sonuçları […]

1 Yorum

Yorum Yaz

Rastgele