SQLsimTools ile SQL Server Yük Testi: Değişiklikleri Canlıya Almadan Ölçün

SQL Server’da yapılan değişikliklerin çoğu canlıya çok az kanıtla çıkar. Yeni indeks execution plan’de doğru görünür, compatibility level değişikliği birkaç kısa testten geçer, yeni sunucunun çekirdek sayısı eskisinden fazladır. Ardından ilk yoğun pazartesi gelir, eşzamanlı kullanıcı sayısı artar ve değişiklik, sakin bir test sisteminde kimsenin görmediği şekilde davranır.

Bunun çözümü daha fazla temkin değil, ölçümdür: Aynı iş yükünü değişiklikten önce ve sonra, gerçekçi bir eşzamanlılıkla çalıştırmak ve sonuçları karşılaştırmak. SQLsimTools tam olarak bu iş için geliştirilmiş, ücretsiz ve yeni bir araç seti. Bu yazıyı hazırlamadan önce aracı kendi SQL Server 2025 test ortamımızda denedik. Aşağıda aracın ne yaptığını, çalıştırdığımız komutları, ölçtüğümüz sonuçları ve bir replay sonucuna güvenmeden önce bilmeniz gereken sınırları bulacaksınız.

SQLsimTools Nedir?

SQLsimTools; tekrarlanabilir bir SQL iş yükü oluşturmak, bu iş yükünü kontrollü bir eşzamanlılıkla çalıştırmak, ölçmek ve çalıştırmaları birbiriyle karşılaştırmak için geliştirilmiş açık kaynak bir araç setidir. 1.0.0 sürümü 14 Ekim 2026’da MIT lisansıyla yayınlandı. SQL Server 2019, 2022 ve 2025’i, Azure SQL Database’i, Azure SQL Managed Instance’ı ve Microsoft Fabric’teki SQL database’i destekler. Projenin resmî sayfası microsoft.github.io/sqlsimtools adresinde; kaynak kod, dokümantasyon ve sürümler ise GitHub üzerinde yayınlanıyor.

Araç seti dört farklı çalışma şekli sunuyor:

sqlsim ve sqlpysim, Windows x64/ARM64 ile Ubuntu 24.04/26.04 x64 üzerinde çalışıyor. Studio şu an yalnızca Windows x64 için Public Preview aşamasında. Araçlar hiçbir telemetri göndermiyor; kurulan tek ağ bağlantısı, sizin belirttiğiniz SQL hedefine yapılıyor.

Hangi Soruya Hangi Araç?

SQLsimTools, DBA’lerin zaten kullandığı araçların yerini almıyor. Her araç farklı bir soruya cevap veriyor; bunları birbirine karıştırmak yanlış sonuçlara götürür:

Sahadaki çalışmalarımızda ilk iki araç, beklenenden çok daha fazla işe yarıyor. Bugün canlı SQL Server’ların büyük bölümü paylaşımlı sanallaştırma ve depolama altyapıları üzerinde çalışıyor. DMV’ler ve wait istatistikleri bir performans sorununu I/O’ya kadar daralttığında, bir sonraki adım sorunun gerçekten diskten kaynaklandığını kanıtlamaktır. Üreticiye çağrı açarken ya da sanallaştırma ekibine giderken DiskSpd’den alınmış IOPS, gecikme ve kuyruk derinliği değerleriyle gitmek, çözüm sürecini belirgin şekilde hızlandırıyor. Aynı testleri, yeni bir ortamı canlıya almadan önce de çalıştırıyoruz; böylece depolamanın canlı ortam olmaya uygun olup olmadığını en baştan teyit ediyoruz.

SQLsimTools ise bir üst katmanda çalışıyor. Platformun sağlıklı olduğu bilindikten sonra, bir değişiklik için asıl önemli olan soruyu cevaplıyor: Bu iş yükü hızlanıyor mu, yavaşlıyor mu?

İlk Çalıştırma: Bağlantı Testi ve Eşzamanlı Yük

Paketi projenin GitHub sürüm sayfasından indirin ve ZIP dosyasının engelini kaldırın. Dosyalar kod imzası taşımadığı için Windows bir SmartScreen uyarısı gösterebilir. sqlsim, Microsoft ODBC Driver 18 for SQL Server’a ihtiyaç duyar. İşe bir bağlantı testiyle başlayın:

.\x64\sqlsim.exe -S localhost -d master -E -Q "SELECT @@VERSION"

Ardından bir betiği eşzamanlı olarak çalıştırın. -n thread sayısını, -r her thread’in tekrar sayısını belirler. -q sonuç kümelerini ekrana basmaz, -querystats ise sorgu bazında sunucu istatistiklerini toplar:

.\x64\sqlsim.exe -S sql01 -d SalesDB -E -i customer-orders.sql -n 8 -r 50 -q -querystats -json -o before.json

SQL login kullanıyorsanız şifreyi -P - ile standart girişten verin; böylece şifre işlem listesinde görünmez. Bunun yerine -c ile tam bir ODBC bağlantı dizesi verirseniz, sqlsim bu dizeyi olduğu gibi kullanır. Bizim testimizde bu durumda uygulama adı sqlsim yerine SQL Workload Simulator oldu. Bu ayrıntı, yazının ilerleyen bölümündeki replay filtresi için önemli; bu yolu seçerseniz bağlantı dizesine APP=sqlsim ekleyin.

Önce ve Sonra: Ölçülmüş Bir Örnek

Çıktının gerçek bir değişiklikte nasıl göründüğünü görmek için SQL Server 2025 test ortamımızda geçici bir veritabanı oluşturduk. İçinde bir milyon satırlık bir dbo.Orders tablosu ve uygulamalarda sık görülen türden bir sorgu vardı:

-- customer-orders.sql: uygulamanın en sık çalıştırdığı sorgu
DECLARE @CustomerID int = ABS(CHECKSUM(NEWID())) % 20000 + 1;
SELECT COUNT(*) AS OrderCount, SUM(Amount) AS TotalAmount, MAX(OrderDate) AS LastOrder
FROM dbo.Orders
WHERE CustomerID = @CustomerID;

Sabit bir tekrar sayısı yerine süre tabanlı bir iş yükü dosyası kullandık; böylece iki çalıştırma da birebir aynı süreyi aldı: 8 thread, 60 saniye. Testi çalıştırdık, ardından kapsayıcı bir indeks ekleyip aynı dosyayı tekrar çalıştırdık:

{
  "duration_seconds": 60,
  "workloads": [ { "file": "customer-orders.sql", "threads": 8 } ]
}

.\x64\sqlsim.exe -S sql01 -d SalesDB -E -workload dur60.json -q -querystats -json -o before.json -stream-json > before.ndjson

CREATE INDEX IX_Orders_CustomerID
    ON dbo.Orders (CustomerID)
    INCLUDE (Amount, OrderDate);

-stream-json parametresi her saniye bir ilerleme kaydı yazar. Ardışık kayıtlar arasındaki farkı çizdiğinizde her çalıştırmanın verim eğrisini elde edersiniz:

Bu rakamlardan üç ders çıkıyor. Birincisi, logical read ve CPU sütunları değişikliğin SQL Server’ın içinde ne yaptığını gösteriyor ve buradaki iyileşme bin kattan fazla. İkincisi, istemcinin ölçtüğü süre yalnızca 152 ms’den 64 ms’ye indi, çünkü bu süre iş istasyonumuzla test sunucusu arasındaki ağ gidiş-dönüşünü de içeriyor. Kullanıcı istemci tarafındaki süreyi hisseder, sunucu ise kendi tarafındaki maliyeti öder; bu yüzden iyi bir karşılaştırma her ikisini de raporlar. Test sırasında wait istatistiklerini okurken de aynı ayrım geçerli: Bir sorgu sunucuda hızlı olup kullanıcı için yine de yavaş olabilir.

Üçüncüsü, turuncu çizginin şekline bakın. Çizgi saniyede yaklaşık 127 sorguda neredeyse düz ilerliyor ve bu tavan SQL Server’a ait değil. 8 thread ve gidiş-dönüş başına yaklaşık 64 ms ile istemci saniyede en fazla 125 civarında sorgu gönderebilir (8 ÷ 0,064 sn). İndeks eklendikten sonra darboğaz sunucudan ağa taşındı. Sunucunun gerçek sınırını görmek için thread sayısını artırmanız ya da yük üreticisini sunucuya daha yakın bir yerde çalıştırmanız gerekir. Tek bir ortalama değer bunu gizlerdi; sabit süreli bir test ve saniyelik bir eğri ise ilk bakışta gösteriyor.

JSON Dosyasıyla Karma İş Yükü

Gerçek sistemler hiçbir zaman tek bir sorgu çalıştırmaz. -workload parametresi, her biri kendi thread, tekrar ya da süre ve bekleme (think time) ayarına sahip birden fazla grubu tanımlayan bir JSON dosyası alır. Aşağıdaki örnek; OLTP sorgularını, daha ağır bir raporlama grubunu ve bir izleme sorgusunu aynı anda çalıştırıyor:

{
  "workloads": [
    { "file": "sql\\oltp-lookups.sql",   "threads": 4, "iterations": 100 },
    { "file": "sql\\monthly-report.sql", "threads": 2, "iterations": 10 },
    { "queries": [ "SELECT COUNT(*) FROM sys.dm_exec_sessions WHERE is_user_process = 1" ],
      "threads": 1, "iterations": 50 }
  ]
}

.\x64\sqlsim.exe -S sql01 -d SalesDB -E -workload mixed.json -q -json -o mixed-before.json

Araçla birlikte gelen örnek iş yükü, test ortamımızda AdventureWorksLT üzerinde 7 thread ile 3.020 batch’i 54 saniyede ve hatasız tamamladı. Grupları bu şekilde bir arada çalıştırmak, tek sorguluk bir testin asla göstermeyeceği blokaj ve kaynak çekişmesini ortaya çıkarır.

Gerçek İş Yükünü Yakalayıp Yeniden Oynatmak

Kendi yazdığınız betikler yalnızca aklınıza gelen sorguları içerir. Replay bu açığı kapatır: Gerçek trafiği Extended Events ile yakalar, dönüştürür ve başka bir sunucuda ya da farklı bir yapılandırmada yeniden çalıştırırsınız. Akış dört adımdan oluşuyor:

1. Yakalama. sql_batch_completed, rpc_completed, login ve logout event’lerini, session_id ve database_name action’larıyla birlikte bir event dosyasına yazan bir oturum oluşturun. Proje, bunun için hazır başlatma ve durdurma betikleri sunuyor.
2. Dönüştürme. replay\convert-xel.ps1, .xel dosyasını sys.fn_xe_file_target_read_file() ile okur ve bir replay XML dosyası üretir.
3. Yeniden oynatma. -replay fast, yakalanan her oturum için ayrı bir bağlantı açar ve o oturumun event’lerini yakalandıkları sırayla, mümkün olan en yüksek hızda çalıştırır. -replay stress ise tüm event’leri tek bir sıraya dizer ve -n thread üzerinde -r kez çalıştırır.
4. Karşılaştırma. -querystats -json ile alınan çıktı, her sorgu için hem yakalanan orijinal metrikleri hem de replay ölçümlerini içerir.

.\replay\convert-xel.ps1 -XelFile "D:\xe\capture*.xel" -OutputFile trace.xml -ServerName sql01
.\x64\sqlsim.exe -S sql02 -d SalesDB -E -replay fast -replayfile trace.xml -querystats -json -o replay-sql02.json -q

Test ortamında 6 oturumdan 50 batch yakaladık. İzi bir kez indeks yerindeyken, bir kez de indeksi kaldırdıktan sonra yeniden oynattık. İzdeki ikinci sorgu indeksi kullanmayan bir rapor olduğu için kontrol görevi görüyor:

50 event’in tamamı iki çalıştırmada da hatasız tamamlandı. Kontrol sorgusu yerinde sayarken müşteri sorgusu belirgin şekilde geriledi. Bir geçiş öncesinde görmek istediğiniz sinyal tam olarak budur: Yeni sunucuda unutulmuş bir indeks, compatibility level değişikliğinden sonra değişen bir plan ya da bir parameter sniffing sorunu, “yeni sunucu daha yavaş gibi” belirsizliği yerine sorgu bazında ölçülmüş bir fark olarak karşınıza çıkar.

Yeni bir sunucuya taşıma yaparken ya da upgrade rehberimizi izleyerek SQL Server 2025’e geçerken, mesai saatlerinden yakalanmış bir örneği eski ve yeni ortamda yeniden oynatmak, gerilemeleri kullanıcılardan önce bulmanın en ucuz yollarından biridir.

ostress’ten Geçiş

SQLsimTools, RML Utilities’in uzun yıllardır kullanılan yük testi aracı ostress’in halefi olarak konumlanıyor. Projenin kendi karşılaştırmasına göre temel farklar şöyle:

Parametrelerin çoğu aynı kalıyor (-S -d -E -U -P -i -n -r -q -v -l -t), ancak bazılarının anlamı değişti. -p, sqlsim’de prepared statement’ları açarken ostress’te paket boyutunu belirliyor. -M, sqlsim’de multi-subnet failover, ostress’te ise en yüksek thread sayısı anlamına geliyor. İlk hatada durma seçeneği de -b yerine -stoponerror oldu. Bu nedenle mevcut ostress betiklerinizi yalnızca çalıştırılabilir dosyanın adını değiştirerek taşımak yerine satır satır gözden geçirmenizi öneririz.

Çalıştırmadan Önce Dikkat Edilmesi Gerekenler

• Sahibinin onayı olmadan asla canlı ortama yöneltmeyin. Araç, verdiğiniz SQL’i istediğiniz eşzamanlılıkla çalıştırır. Küçük başlayın; thread ve tekrar sayısını kademeli olarak artırın.
• Sertifika doğrulamasını açın. sqlsim, sqlcmd (Go) gibi, siz istemedikçe sunucu sertifikasını doğrulamaz. Azure SQL’e ve makinenizin dışına çıkan her bağlantıya -N m ya da -N s ekleyin.
• Gizli bilgileri komut satırında bırakmayın. Şifre ve token’ları -P - ya da -T - ile standart girişten verin.
• Kaydedilen yapılandırmaları koruyun. Studio gizli bilgileri saklamaz, ancak kaydedilen dosyalarda sorgu metinleri ve sunucu adları düz metin olarak yer alır.
• Önce platformu düzeltin. DiskSpd testinden zaten geçemeyen bir depolama üzerinde yapılan yük testi, yalnızca depolamayı ölçer. Disk katmanını önce disk depolama best practice’leri yazımızdaki önerilerle kontrol edin.

Aryasoft Yük Testini Nasıl Kullanıyor?

Yük testi, upgrade, taşıma ve performans çalışmalarındaki riski azaltma yöntemimizin bir parçası. Depolama katmanında DiskSpd ve SQLIOSim ile yeni bir ortamın canlı yükü taşıyıp taşıyamayacağını doğruluyoruz. Bir sorun I/O’ya kadar indirildiğinde de sanallaştırma ve depolama ekiplerine somut IOPS, gecikme ve kuyruk değerleriyle gidiyoruz. Platform karşılaştırmalarında HammerDB’yi, tek bir sorunlu sorgu için SqlQueryStress’i kullanıyoruz. SQLsimTools ise bu araçların arasındaki eksik parçayı tamamlıyor: Müşterinin kendi iş yükünün, betiklerden ya da yakalanmış bir izden, tekrarlanabilir ve ölçülebilir bir önce/sonra karşılaştırması.

Amacımız her zaman aynı: Bir değişiklik, sakin bir test sisteminde sorunsuz göründüğü için değil, rakamlar daha iyi olduğunu gösterdiği için canlıya çıkmalı.