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

HashTable HashIndex HashPartition

SQL Server 6 gün önce

Bu makalede modern veri tabanı sistemlerinde verimliliği artıran HashTable, HashIndex ve Hashpartition yapılarını inceleyeceğiz. Bu kavramların nasıl çalıştığını, avantajlarını, dezavantajlarını ve pratik kullanım örneklerini SQL kodlarıyla açıklayacağız.İçindekilerHash Table Nedir?Hash Index Nedir?Hash Partitioning Nedir? Hash tabanlı bir veri yapısı tasarlayacağımız ortamda bilmemiz gereken özellikle hash partitioning ya da bucketing gibi bölümlendirme stratejilerinde sıkça karşımıza çıkacak bir parametre olan bucket_count, verilerin kaç adet bucket içine dağıtılacağını belirleyen sayısal bir değerdir. Her bir bucket, belirli bir hash değeri aralığına denk gelir ve veriler, belirli bir kolona uygulanan hash fonksiyonunun çıktısına göre bu bucket ‘lardan birine atanır. Peki, bu bizim için neden önemli? Doğru belirlenmiş bir bucket_count değeri, verilerin eşit dağılımı sağlar bu da sorgu performansını iyileştirir. Bucket sayısı, paralel çalışan işlemlerin sayısını doğrudan etkiler, örneğin bir tablo 16 bucket sahipse, aynı anda 16 thread veriyi işleyebilir. Aynı bucket sayısıyla bölünmüş tablolar arasında yapılan join işlemleri daha verimli olur. CREATE TABLE UserActiviy ( Id_user […]

In-Memory Table and Native Stored Procedures

SQL Server 1 ay önce

Bu makalede 2014 yılında yayınlanan In-Memory Table OLTP(Online Transaction Processing) Engine yapısından bahsedeceğim.İçindekilerKaynak: In-Memory Table, adından da anlaşılacağı üzere, verileri fiziksel disk yerine RAM üzerinde saklandığı özel bir tablo türüdür. Bu yapı, geleneksel disk tabanlı tablolara kıyasla çok daha hızlı veri okuma ve yazma performansı sunar çünkü disk erişimi esnasında yaşanan darboğaz sorununa alternatif bir çözüm sunmuştur. Verinin, buffer pool içinde cache’lenmesi, düşük gecikme(low latency) ve yüksek throughput en büyük avantajlarıdır. Özellikle yüksek hacimli veri işleyen, çok sayıda eş zamanlı işlem gerçekleştiren veya gerçek zamanlı yanıt süresi gerektiren sistemlerin kullanımı oldukça yaygındır. (Örneğin: finansal platformlar, IoT işlemleri, sipariş işlemleri) Avantajlarını göz önünde bulundurarak o zaman her ortama bunu yapalım diyebiliriz 🙂 pahalı bir donanım olan RAM ‘den sınırsız bir şekilde elinizde bulunduruyor olmanız gerekebilir çünkü In-Memory bulunduğu ortama yüksek RAM maliyeti, kendine has filegroup yapısı ile yönetimsel zorluklar, failover sürelerinin uzaması gibi dezavantajları da beraberinde getirmektedir. In-Memory Tabloların kendine özgü […]

SMART BACKUP

SQL Server 1 ay önce

Bu makalede SQL Server 2017 versiyonuyla gelen DMV ‘ler ile kullanımı kolaylaşan bir özellik olan Smart Backup dan bahsedeceğim. Bu makaleye başlamadan şunu belirtmekte fayda var; bu özelliği üçüncü parti yazılımlar veya eklentiler ile yapabilmek mümkün MSSQL haricinde diğer ilişkisel veri tabanı sistemlerinde de buna benzer özellikler tanımlanabilir, kullanılabilir. Bu makalemizin anlaşılabilirliğini artırmak adına öncelikle performans ve veri bütünlüğü açısından hayati öneme sahip olan Checkpoint kavramından bahsetmek istiyorum; SQL Server, veri değişikliklerini önce RAM’de (buffer cache) tutar, bu sırada log dosyasına (LDF) işlemi yazar. Checkpoint olduğunda, bu değişmiş (dirty) geçici verileri .LDF dosyasından kalıcı hale getirir .MDF dosyasına (diske) yazar. Checkpoint, varsayılan olarak her 60 saniyede bir çalışır ancak SQL Server 2012 ile indirect checkpoints tanıtıldı ve veri tabanı bazlı olarak ayarlanabilir. Şimdi iki Checkpoint yönetimine daha yakından bakarak artı ve eksilerinden bahsedelim; Otomatik checkpoint modunda, tüm buffer pool’daki sayfalar taranır ve değişmiş sayfalar bulunur bu ilk baktığımızda bizim için […]

1 Yorum

Yorum Yaz

Rastgele