Performans · SQL Server · Sorun Giderme

Production İçin Güvenli SQL Server Performans İnceleme Akışı

3 dk okuma

Performans olayları, inceleme doğrudan değişiklik yaparak başladığında riskli hale gelir. Daha güvenli akış önce belirtiyi tanımlar, kanıtı korur ve configuration veya indexlere dokunmadan problemi daraltır.

[company_article_image src=”articles/performance-investigation.svg” alt=”Altı adımlı production güvenli SQL Server performans inceleme akışı” caption=”Disiplinli süreç kanıtı korur ve production değişikliklerini geri alınabilir tutar.”]

1. Belirtiyi tanımlayın

Hangi işlemin yavaş olduğunu, ne zaman başladığını, tüm kullanıcıların etkilenip etkilenmediğini ve normal davranışın ölçüsünü netleştirin. Time zone, uygulama release’i ve altyapı olaylarını kaydedin.

2. Kapsamı ve kaynak baskısını belirleyin

Sorunun instance genelinde mi, tek veritabanında mı, yoksa belirli sorguda mı olduğunu ayırın. Aynı zaman aralığında CPU, runnable task, memory grant, I/O latency, blocking, log throughput ve wait dağılımını kontrol edin.

3. Sorgu kanıtını koruyun

Mevcutsa Query Store kullanın. Değilse aktif request, plan ve ilgili sayaçları düşük maliyetli yöntemle kaydedin. Peak yükte pahalı tanılama sorgularını sık aralıklarla çalıştırmayın.

SELECT r.session_id, r.status, r.wait_type,
       r.blocking_session_id, r.cpu_time,
       r.logical_reads, r.total_elapsed_time,
       DB_NAME(r.database_id) AS database_name,
       SUBSTRING(t.text, (r.statement_start_offset / 2) + 1,
         ((CASE r.statement_end_offset WHEN -1 THEN DATALENGTH(t.text)
           ELSE r.statement_end_offset END - r.statement_start_offset) / 2) + 1)
         AS statement_text
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t
WHERE r.session_id <> @@SPID;

DMV snapshotları geçicidir. Daha sonra korelasyon yapılabilmesi için UTC timestamp, instance kimliği ve incident referansı ekleyin.

4. Yanlışlanabilir hipotez kurun

Statistics değişimi sonrası plan regresyonu, uzun transaction kaynaklı blocking veya index değişimi sonrası artan okuma gibi açıklamalar kurun. Hipotezi hangi kanıtın doğrulayacağını ve hangi kanıtın reddedeceğini önceden yazın.

5. En küçük geri alınabilir değişikliği yapın

Temsilî parametre ve concurrency ile test edin. Orijinal durum, beklenen sonuç, izleme süresi ve rollback komutunu kaydedin. Acil mitigation ile kalıcı çözüm aynı işlem olmayabilir.

6. Kullanıcıdan sisteme doğru doğrulayın

Önce uygulama response time değerini; ardından query duration, CPU, reads, waits ve hata oranını doğrulayın. İlk problemi ortaya çıkaran workload desenini kapsayacak kadar gözlem yapın.

Disiplinli inceleme daha yavaş değildir; ilgisiz tuning çalışmalarını önler, kanıtı korur ve iyileştirmeyi açıklanabilir hale getirir.

İlgili Makaleler