İzleme · Performans · SQL Server

SQL Server Kapasite Planlama: Dashboard’dan Karar Zamanına

3 dk okuma

Dashboard bugün CPU’nun yüzde 70 olduğunu gösterebilir. Kapasite planlama daha zor bir soruyu yanıtlamalıdır: Beklenen büyüme ve sezon etkisi altında platform güvenli çalışma sınırından ne zaman çıkacak ve hangi aksiyon için ne kadar hazırlık süresi var?

[company_article_image src=”articles/capacity-signals.svg” alt=”Güvenli çalışma sınırına yaklaşan SQL Server workload trendi ve karar ufku” caption=”Kapasite planlama telemetriyi tuning, scale veya mimari değişiklik için kalan zamana dönüştürür.”]

Önce servis talebini tanımlayın

Workload bağlamı olmadan altyapı kullanımı eksik kalır. Transaction, batch request, active user, data ingestion, database boyutu ve iş döngülerini izleyin. CPU artışı sağlıklı büyüme olabilir; aynı CPU ile throughput düşmesi ise verimsizlik gösterebilir.

Tek ortalama yerine dağılım kullanın

Günlük ortalama peak pencereleri gizler. Ortalama yanında percentile, sürdürülen maximum dönem ve concurrency değerlerini saklayın. Mesai, batch, ay sonu ve bakım workloadlarını ayrı baseline olarak değerlendirin.

Tüm kaynak yolunu ölçün

  • CPU: utilization, runnable queue, compilation ve sorgu verimliliği.
  • Memory: grant, grant wait, cache baskısı ve işletim sistemi headroom.
  • Data I/O: latency, IOPS, throughput ve logical read.
  • Transaction log: üretim hızı, flush latency, backup throughput ve AG send/redo queue.
  • Storage: kullanılan alan, autogrowth, backup footprint, TempDB peak ve boş alan ufku.

Karar ufkunu hesaplayın

Büyümeyi mutlak tükenmeye değil tanımlı güvenli sınıra göre modelleyin. Failure mode, bakım, failover ve tahmin hatası için pay bırakın. Talep belirsizse birden fazla senaryo kullanın.

SELECT DB_NAME(database_id) AS database_name,
       type_desc,
       SUM(size) * 8.0 / 1024 AS allocated_mb,
       SUM(FILEPROPERTY(name, 'SpaceUsed')) * 8.0 / 1024 AS used_mb
FROM sys.master_files
WHERE database_id > 4
GROUP BY database_id, type_desc;

Bu sorgu yalnızca anlık allocation görünümüdür. Tutarlı snapshotları monitoring repository içinde saklayıp temsilî dönemlerde değişim hızını hesaplayın.

Aksiyonu doğru sırada seçin

  1. Verimsiz sorgu, redundant index ve kontrolsüz retention gibi gereksiz talebi kaldırın.
  2. Scheduling, batching veya workload isolation ile peak değerleri azaltın.
  3. Configuration ve platform limitlerini doğrulayın.
  4. Satın alma ve değişiklik penceresi kapanmadan scale veya redesign kararı alın.

Her forecast için owner, güvenli limit, gözden geçirme sıklığı ve aksiyon tarihi bulunmalıdır. Faydalı çıktı “disk ayda yüzde 4 büyüyor” değil; “şu tarihe kadar archive veya expansion uygulanmalı” sonucudur.

İlgili Makaleler