Logo SQL Index Optimizasyonu | Sistem Yavaşlığına Çözümler

Özet: Logo ERP'de sistem yavaşlığının %80'i veritabanı performansından kaynaklanır. Bu yazıda, index oluşturma, istatistik güncelleme ve bakım planları ile %40-50 performans artışı sağlamayı öğreneceksiniz.

Neden Logo Yavaşlar?

Logo ERP kullanıcılarının en sık şikayeti "Sistem çok yavaş" olur. Bunun temel nedenleri:

Eksik veya bozuk index'ler: Logo'nun standart index'leri büyük verilerde yetersiz kalır
Güncellenmeyen istatistikler: SQL Server'ın sorgu planları eskir
Fragmentasyon: Tablolar zamanla parçalanır
Büyüyen log dosyaları: Transaction log kontrolsüz büyür

1. En Kritik Tablolar ve Index Stratejisi

Logo'da en çok sorgu çalışan tablolar şunlardır:

Tablo	Önerilen Index Alanları	Etki
`LG_XXX_YY_STLINE`	DATE_, STOCKREF, LINETYPE	Stok raporları %50 hızlanır
`LG_XXX_YY_CLFLINE`	DATE_, CLIENTREF, TRCODE	Cari ekstreler %60 hızlanır
`LG_XXX_YY_INVOICE`	DATE_, CLIENTREF, TRCODE	Fatura listeleri %40 hızlanır
`LG_XXX_YY_EMFLINE`	DATE_, ACCREF	Mizan raporları %45 hızlanır

2. Covering Index Oluşturma

Aşağıdaki SQL komutları ile STLINE tablosuna performans index'i ekleyebilirsiniz:

-- STLINE için Covering Index
CREATE NONCLUSTERED INDEX IX_STLINE_Performance
ON LG_001_25_STLINE (DATE_, STOCKREF, LINETYPE)
INCLUDE (AMOUNT, PRICE, TOTAL)
WITH (ONLINE = ON, FILLFACTOR = 90);

-- CLFLINE için Covering Index  
CREATE NONCLUSTERED INDEX IX_CLFLINE_Performance
ON LG_001_25_CLFLINE (DATE_, CLIENTREF)
INCLUDE (DEBIT, CREDIT, TRCODE)
WITH (ONLINE = ON, FILLFACTOR = 90);

Not: ONLINE = ON parametresi sayesinde index oluşturulurken sistem çalışmaya devam eder. Büyük tablolarda bu işlem 10-30 dakika sürebilir.

3. İstatistik Güncelleme

SQL Server, sorgu planları için istatistiklere bakar. Güncel olmayan istatistikler yanlış plan seçimine neden olur:

-- Tüm istatistikleri güncelle (haftalık çalıştırın)
EXEC sp_updatestats;

-- Belirli bir tablonun istatistiklerini güncelle
UPDATE STATISTICS LG_001_25_STLINE WITH FULLSCAN;

-- Auto update istatistikleri aktif et
ALTER DATABASE LogoDB SET AUTO_UPDATE_STATISTICS ON;

4. Index Fragmentasyonu Temizleme

Zamanla index'ler parçalanır. Fragmentasyon %30'u geçtiğinde REBUILD yapılmalıdır:

-- Fragmentasyon oranını kontrol et
SELECT 
    OBJECT_NAME(ips.object_id) AS TableName,
    i.name AS IndexName,
    ips.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') ips
INNER JOIN sys.indexes i ON ips.object_id = i.object_id AND ips.index_id = i.index_id
WHERE ips.avg_fragmentation_in_percent > 10
ORDER BY ips.avg_fragmentation_in_percent DESC;

-- Index Rebuild (Fragmentasyon > 30%)
ALTER INDEX IX_STLINE_Performance ON LG_001_25_STLINE REBUILD;

-- Index Reorganize (Fragmentasyon 10-30%)
ALTER INDEX IX_STLINE_Performance ON LG_001_25_STLINE REORGANIZE;

5. Haftalık Bakım Planı

Aşağıdaki bakım planını SQL Server Agent Job olarak tanımlayın:

Haftalık Bakım Checklist

İstatistik güncelleme (sp_updatestats)
Index fragmentasyon kontrolü
%30+ fragmentasyon için REBUILD
Transaction log shrink (gerekirse)
DBCC CHECKDB (veri bütünlüğü)

-- Otomatik Bakım Script'i
-- Her Pazar gece 02:00'de çalıştırın

-- 1. İstatistik güncelle
EXEC sp_updatestats;

-- 2. Tüm index'leri reorganize et
EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? REORGANIZE';

-- 3. Veri bütünlüğü kontrolü
DBCC CHECKDB WITH NO_INFOMSGS;

6. Yavaş Sorguları Tespit Etme

Hangi sorguların sistemi yavaşlattığını bulmak için:

-- En yavaş 10 sorguyu bul
SELECT TOP 10
    qs.total_elapsed_time / qs.execution_count AS avg_elapsed_time,
    qs.execution_count,
    SUBSTRING(qt.text, (qs.statement_start_offset/2)+1, 100) AS query_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
ORDER BY avg_elapsed_time DESC;