SQL Server 2025 Yönetici Tarafı: Ne Değişti?
Üç cümlede
Bir: Bu seri yöneticinin tarafını alıyor: motor içi, teşhis, kurtarma ve güvenlik. Geliştirici özellikleri ayrı bir eserin konusu.
İki: Değişmeyen şeyler değişenlerden fazla. Sayfa yapısı, kilitleme ve günlük mimarisi yerinde duruyor.
Üç: En sık hata: motoru yükseltip uyumluluk düzeyini eski bırakmak. Yeni iyileştirmeler o durumda kapalı kalır.
Yeni bir sürüm çıktığında yazılanların çoğu özellik listesi oluyor. Geliştirici tarafı için bu yeterli; bir yönetici içinse asıl soru başka: elimdeki sistem bu yükseltmeden sonra nasıl davranacak?
Bu seri o soruyu merkeze alıyor. On dört yazı boyunca motorun içine bakacağız: depolama, günlük, eşzamanlılık, bellek, dizin, istatistik, plan, bekleme türleri, kurtarma ve güvenlik. Kodun tamamı yerel bir kapsayıcıda gerçekten çalıştırıldı; hiçbir adımda bulut kaynağı kullanılmadı.
İçindekiler
- Bu seri neyi kapsıyor, neyi kapsamıyor
- Gerçekten değişen: uyumluluk düzeyine bağlı olanlar
- Yeni görünen ama değişmeyen
- Yükseltme sonrası kontrol listesi
- Serinin haritası
- Bu hafta yapılabilecek beş şey
- Sık sorulanlar
- Kaynaklar
Bu seri neyi kapsıyor, neyi kapsamıyor
Kapsam ayrımını baştan net koyalım, çünkü aynı sürüm hakkında iki farklı okur kitlesi var ve ikisi farklı şeyler arıyor.
| Bu seride var | Bu seride yok |
|---|---|
| Depolama motoru, sayfa ve extent davranışı | Vektör veri tipi ve gömme üretimi |
| İşlem günlüğü ve kurtarma mekaniği | Yerel JSON tipi ve JSON fonksiyonları |
| Kilit, latch, izolasyon ve satır sürümleme | Düzenli ifadeler ve metin fonksiyonları |
| tempdb, bellek ve paralellik | T-SQL’den REST çağrısı ve API üretimi |
| Dizin, istatistik, plan ve bekleme türleri | Uygulama tarafı sürücü ve ORM konuları |
| Yedek, geri yükleme ve güvenlik işletimi | Örnek uygulama geliştirme |
Sağ sütun boşlukta değil. Geliştirici tarafını ayrı bir eserde, “Yazılımcılar İçin SQL Server 2025” kitabında topladım. İki taraf birbirini besliyor: geliştirici yeni tipleri kullanıyor, yönetici o kullanımın motorda ne ürettiğini görüyor.
Serinin haritası
On dört yazı üç blok hâlinde ilerliyor. Sıra rastgele değil; her blok bir öncekinin üstüne kuruluyor. Belirtiden sebebe, sebepten sorumluluğa MOTOR İÇİ · 02-06 Depolama · günlük · eşzamanlılık kilitlenme · tempdb Soru: belirti nereden çıkıyor? Bu blok olmadan teşhis belirti tarifinden ibaret kalır SORGU BAŞARIMI · 07-12 Bellek · dizin · istatistik plan · IQP · bekleme türleri Soru: nereye müdahale edilir? Teşhis sırası bu blokta adım adım kuruluyor İŞLETME · 13-14 Yedek ve kurtarma güvenlik seti Soru: sorumluluk kimde? İddiayı kanıta çeviren maddeler burada Her yazıda bir şema, gerçekten çalıştırılmış kod ve sahadan bir not var. Rozet neyin nasıl doğrulandığını söyler. Geliştirici tarafı (vektör, JSON, düzenli ifadeler, REST) bilinçli olarak kapsam dışı; ayrı bir eserin konusu. Blokları sırayla okumak zorunlu değil, ama teşhis akışı bu sırayla kuruluyor.
Bu yazıda geçen terimler
Uyumluluk düzeyiVeritabanının hangi sürümün sorgu iyileştirici davranışını kullanacağını belirleyen ayar. Veritabanı kapsamlı yapılandırmaSunucu geneli yerine veritabanı bazında uygulanan iyileştirici ve motor ayarları. Sorgu DeposuSorgu metinlerini, planlarını ve çalışma istatistiklerini veritabanı içinde saklayan bileşen. Kardinalite tahminiİyileştiricinin bir işlemden kaç satır döneceğine dair tahmini; plan seçiminin temeli. Bekleme türüBir görevin ne beklediğini adlandıran kayıt; teşhisin en doğrudan girdisi. Kurtarma modeliGünlük kayıtlarının nasıl tutulacağını ve hangi geri dönüş seçeneklerinin mümkün olduğunu belirleyen ayar.
Gerçekten değişen: uyumluluk düzeyine bağlı olanlar
Yeni sürümde gelen iyileştirmelerin önemli bölümü otomatik devreye girmiyor; veritabanının uyumluluk düzeyine bağlı. K1.1 K1.2 Bu, yükseltmelerin en sık gözden kaçan tarafı.
Tipik sahne şöyle: motor yükseltilir, veritabanları taşınır, uyumluluk düzeyi eski değerde kalır. Sonra “yükselttik ama hiçbir fark yok” cümlesi kurulur. Doğru; çünkü yeni iyileştiricinin davranışı hâlâ kapalı.
| Karar | Sonucu |
|---|---|
| Motoru yükselt, düzeyi eski bırak | En güvenli yol; planlar değişmez, ama yeni iyileştirmeler kapalı kalır |
| Motoru yükselt, düzeyi yükselt | Yeni davranış devreye girer; bazı planlar değişir ve önce ölçülmelidir |
| Düzeyi yükselt, Sorgu Deposu kapalı | Riskli; plan değişikliğini karşılaştıracak veriniz olmaz |
| Düzeyi yükselt, Sorgu Deposu açık | Önerilen yol; öncesi ve sonrası karşılaştırılabilir |
Dördüncü satır bu yazının en pratik önerisi. Sorgu Deposu’nu yükseltmeden önce açıp bir süre veri toplamak, yükseltme sonrası “bu sorgu eskiden daha hızlıydı” tartışmasını ölçüme dönüştürüyor. K6.6
Yeni görünen ama değişmeyen
Yöneticiler için asıl iyi haber bu: motorun temeli yerinde duruyor. Yirmi yıllık bilgi geçerliliğini koruyor.
- Sayfa yapısı ve extent mantığı aynı. Sayfa boyutu, sayfa başlığı ve ayırma birimleri bildiğiniz gibi çalışıyor. K2.1
- Kilitleme ve izolasyon düzeyleri aynı. Paylaşımlı ve dışlayıcı kilitlerin uyum matrisi, satır sürümlemenin davranışı değişmedi. K3.1
- İşlem günlüğü mimarisi aynı. Sanal günlük dosyaları, kesme noktaları ve günlük yeniden kullanım beklemesi aynı mantıkla işliyor. K2.2
- Bekleme türü mantığı aynı. Teşhis akışınız aynen geçerli. K6.8
- Yedek zinciri kuralları aynı. Kurtarma modelinin belirlediği şeyler değişmedi. K2.4
Bu liste kısa görünebilir ama kapsadığı alan çok geniş. Bir yöneticinin günlük işinin büyük bölümü bu beş başlıkta geçiyor ve hiçbiri sıfırdan öğrenilmiyor.
Yükseltme sonrası kontrol listesi
Yükseltme yapıldıktan sonra sırayla bakılacaklar. Her maddenin ayrıntısı seride ilgili yazıda:
- Uyumluluk düzeyi ne? Bilinçli bir karar mı, yoksa öyle mi kalmış? K1.3
- İstatistikler güncel mi? Yükseltme sonrası istatistik güncelleme, plan kalitesini doğrudan etkiler. K5.5
- Sorgu Deposu açık mı ve saklama süresi yeterli mi? Karşılaştırma yapabilmek için gerekli. K6.6
- Plan regresyonu var mı? Süresi belirgin biçimde artan sorguları listeleyin.
- Bekleme profili değişti mi? Sayaçları sıfırlayıp yeni profili çıkarın. K6.8
- Yedek ve geri yükleme yordamınız aynen çalışıyor mu? Yükseltme sonrası bir tatbikat, en ucuz sigorta. K7.2
Dördüncü madde atlanmasın. Yükseltme sonrası ortaya çıkan başarım şikâyetlerinin çoğu birkaç sorguya bağlı oluyor. O sorguları bulmak için öncesi ve sonrasını karşılaştıran bir veriye ihtiyaç var; o veri de üçüncü maddeden geliyor.
Serinin haritası
On dört yazı üç bloğa ayrılıyor. Sıra rastgele değil; her blok bir öncekine dayanıyor.
| Blok | Yazılar | Ne öğretiyor |
|---|---|---|
| Motor içi | 02-06 | Depolama, günlük, eşzamanlılık, kilitlenme, tempdb. Belirtilerin nereden çıktığını anlamak |
| Sorgu başarımı | 07-12 | Bellek, dizin, istatistik, plan, akıllı sorgu işleme, bekleme türleri. Teşhis ve müdahale |
| İşletme | 13-14 | Yedek ve kurtarma derinliği, güvenlik seti. Sorumluluk taşıyanın tarafı |
Her yazıda şu üç şey var: bir şema, gerçekten çalıştırılmış kod ve sahadan bir not. Kodun altındaki rozet, o bloğun tam olarak nasıl doğrulandığını söylüyor; yapılmayan bir doğrulama iddia edilmiyor.
Devralınan bir ortamda ilk gün
Yeni bir ortamın sorumluluğunu aldığınızda, ne olduğunu anlamak için sırayla bakılacaklar var. Bu liste seride ilerledikçe derinleşecek; burada başlangıç hâli.
| Soru | Neden ilk günde |
|---|---|
| Kaç veritabanı, hangi boyutta? | Bakım penceresi ve yedek süresi bununla belirlenir |
| Kurtarma modelleri ne? | Veri kaybı toleransının teknik karşılığı |
| Yedek zinciri sağlam mı? | En kritik risk; on üçüncü yazının konusu |
| Sorgu Deposu açık mı? | Her teşhisin dayanacağı veri kaynağı |
| Uyumluluk düzeyleri ne? | Plan davranışını doğrudan belirler |
| Kimde sysadmin var? | En büyük güvenlik açığının bulunduğu yer; on dördüncü yazı |
| Bekleme profili neye benziyor? | Sistemin karakterini tek bakışta gösterir |
Bu yedi sorunun cevabı bir sayfaya sığıyor ve o sayfa, sonraki bütün çalışmanın zeminini kuruyor. Cevaplar olmadan yapılan her müdahale tahmine dayanıyor.
Sürüm desteği: teknik olmayan ama kritik bir konu
Yükseltme kararlarında sık atlanan bir boyut var: destek durumu. Yama alamayan bir sürüm, bilinen açıklara açık kalıyor ve bu, teknik bir tercih olmaktan çıkıp bir uyumluluk sorununa dönüşüyor.
| Durum | Sonucu |
|---|---|
| Ana destek sürüyor | Yeni özellikler ve düzeltmeler gelir |
| Genişletilmiş destek | Yalnız güvenlik güncellemeleri |
| Destek bitmiş | Yama yok; denetimde bulgu, sigortada risk |
Planlama önerisi: destek bitiş tarihini yükseltme takviminin girdisi yapın, sonucu değil. Destek bittikten sonra başlayan bir yükseltme projesi, aylarca açık bir pencerede çalışmak demek.
Yükseltme yolu: kademeli ilerlemek
Bir yükseltmeyi tek bir gece olarak planlamak yaygın ama riskli. Daha güvenli sıra şöyle:
- Sorgu Deposu’nu açın ve bir süre veri biriktirin. En az bir tam iş döngüsünü kapsamalı: ay sonu raporları, gece işleri, yoğun günler.
- Motoru yükseltin, uyumluluk düzeyini değiştirmeyin. Bu adımda plan davranışı değişmez; risk düşüktür.
- Bir süre gözlemleyin. Motor kaynaklı bir sorun varsa burada görünür.
- Tek bir veritabanında düzeyi yükseltin. Tercihen en az kritik olanda.
- Karşılaştırın. Süresi belirgin biçimde artan sorgu var mı?
- Sorun çıkanları hedefli çözün. Bütün düzeyi geri almak yerine ilgili sorguya ipucu vermek genellikle daha doğru.
- Kalan veritabanlarına yayın.
Bu sıra daha uzun sürüyor ama her adımda geri dönüş imkânı bırakıyor. Tek gecede yapılan yükseltmelerde sorun çıktığında elinizde tek seçenek kalıyor: her şeyi geri almak.
Yükseltme öncesi envanter: tek oturumda çıkarın
Bu üç sorgu, birinci yazıdaki kontrol listesinin veri tarafını üretiyor. Çıktıyı bir yere kaydedin; yükseltme sonrası karşılaştırma yapacaksınız. T-SQL · sürüm ve uyumluluk düzeyi · motorla düzey arasında fark var mı
-- Motor surumu ve orneğin kunyesi
SELECT SERVERPROPERTY('ProductVersion') AS surum,
SERVERPROPERTY('ProductLevel') AS surum_duzeyi,
SERVERPROPERTY('Edition') AS sunum;
-- Veritabani bazinda uyumluluk duzeyi.
-- Motor yeni ama duzey eskiyse, yeni iyilestirmelerin cogu KAPALIDIR.
SELECT name AS veritabani,
compatibility_level AS uyumluluk_duzeyi,
recovery_model_desc AS kurtarma_modeli,
state_desc AS durum,
is_read_committed_snapshot_on AS rcsi_acik,
is_query_store_on AS sorgu_deposu_acik
FROM sys.databases
ORDER BY name;ÇalıştırıldıSQL Server 2025 üzerinde gerçekten çalıştırılarak doğrulandı (yerel Docker; bulut kaynağı yok). T-SQL · veritabanı kapsamlı yapılandırma · hangi ayar varsayılandan sapmış
-- Varsayilandan sapan ayarlari gormek, devralinan bir ortamda
-- ilk yapilacak islerden biridir. Sapma her zaman yanlis degildir;
-- ama gerekcesi bilinmelidir.
SELECT configuration_id, name, value, value_for_secondary, is_value_default
FROM sys.database_scoped_configurations
ORDER BY name;ÇalıştırıldıSQL Server 2025 üzerinde gerçekten çalıştırılarak doğrulandı (yerel Docker; bulut kaynağı yok). T-SQL · bekleme profilinin taban ölçümü · yükseltme öncesi fotoğraf
-- Iyi huylu turler elenmis bekleme profili.
-- Bu ciktiyi yukseltme oncesi kaydedin; sonrasinda karsilastirin.
SELECT TOP (15)
wait_type,
waiting_tasks_count AS bekleyen_gorev,
wait_time_ms AS toplam_ms,
wait_time_ms - signal_wait_time_ms AS kaynak_bekleme_ms,
signal_wait_time_ms AS sinyal_bekleme_ms
FROM sys.dm_os_wait_stats
WHERE waiting_tasks_count > 0
AND wait_type NOT IN (
'CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK',
'SLEEP_SYSTEMTASK','SQLTRACE_BUFFER_FLUSH','WAITFOR','LOGMGR_QUEUE',
'CHECKPOINT_QUEUE','REQUEST_FOR_DEADLOCK_SEARCH','XE_TIMER_EVENT',
'BROKER_TO_FLUSH','BROKER_TASK_STOP','CLR_MANUAL_EVENT','CLR_AUTO_EVENT',
'DISPATCHER_QUEUE_SEMAPHORE','FT_IFTS_SCHEDULER_IDLE_WAIT',
'XE_DISPATCHER_WAIT','XE_DISPATCHER_JOIN','SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
'DIRTY_PAGE_POLL','SP_SERVER_DIAGNOSTICS_SLEEP','HADR_FILESTREAM_IOMGR_IOCOMPLETION',
'QDS_PERSIST_TASK_MAIN_LOOP_SLEEP','QDS_ASYNC_QUEUE','QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP')
ORDER BY wait_time_ms DESC;ÇalıştırıldıSQL Server 2025 üzerinde gerçekten çalıştırılarak doğrulandı (yerel Docker; bulut kaynağı yok).
Sahadan not · yükseltip düzeyi unutmak
Yükseltme sonrası en sık duyduğumuz cümle şu: “yeni sürüme geçtik ama hiçbir fark yok.” Neredeyse her seferinde aynı sebep çıkıyor: motor yükseltilmiş, veritabanları taşınmış, uyumluluk düzeyi eski değerde bırakılmış. Yani yeni iyileştiricinin davranışı hiç devreye girmemiş.
Bu bir hata değil; göç sırasında bilinçli olarak yapılan güvenli bir tercih. Sorun, o tercihin geçici olması gerektiğinin unutulması. Yükseltme planına, düzeyin ne zaman ve hangi ölçüme bakılarak yükseltileceğini ayrı bir madde olarak yazın. Aksi hâlde ödediğiniz lisans bedelinin karşılığını almıyorsunuz.
Bu hafta yapılabilecek beş şey
- Veritabanlarınızın uyumluluk düzeyini listeleyin. Motorla düzey arasında fark varsa, bunun bilinçli bir karar olup olmadığını sorun.
- Sorgu Deposu’nun açık olup olmadığını ve saklama süresini kontrol edin; yükseltme kararının ön koşulu bu.
- Bekleme profilinizin bugünkü hâlini kaydedin. Karşılaştırma yapabilmek için bir taban ölçüme ihtiyacınız var.
- En son ne zaman geri yükleme tatbikatı yaptığınızı yazın. Cevap yoksa, o tatbikatı takvime alın.
- Sürüm destek durumunuzu kontrol edin. Yama alamayan bir sürüm, bilinen açıklara açık kalır.
Sık sorulanlar
Bu seri kitabın tekrarı mı?
Hayır, kapsamları ayrı. Kitap geliştirici tarafını anlatıyor: vektör, JSON, düzenli ifadeler, REST. Bu seri yönetici tarafını alıyor: motor içi, teşhis, kurtarma ve güvenlik. İkisi birbirini tamamlıyor.
Uyumluluk düzeyini hemen yükseltmeli miyim?
Sorgu Deposu ile bir taban ölçüm almadan yükseltmeyin. Yükselttikten sonra plan regresyonu kontrolü yapın; sorun çıkarsa düzeyi geri almak ya da tek tek ipucu vermek mümkün.
Eski sürümdeyim, bu seri işime yarar mı?
Büyük ölçüde evet. Motorun temeli sürümler arasında değişmiyor; seride anlatılan depolama, günlük, kilitleme ve teşhis mantığı eski sürümlerde de geçerli. Sürüme özgü noktaları ayrıca işaretliyorum.
Kodları kendi ortamımda çalıştırabilir miyim?
Evet, hepsi salt okunur teşhis sorguları ya da açıkça belirtilmiş yapılandırma komutları. Kodun tamamı yayın öncesi yerel bir kapsayıcıda çalıştırıldı ve her bloğun altında ne şekilde doğrulandığı yazıyor.
Bulut tarafını da anlatacak mısınız?
Bulut tarafı ayrı bir seride duruyor. Bu seri bilinçli olarak kutu sürüme odaklanıyor; kavramların çoğu iki tarafta da aynı olduğu için birbirini besliyorlar.
Neden bekleme türleri için ayrı bir yazı var?
Çünkü teşhiste en çok kullanılan ve en çok yanlış okunan veri o. Bir sözlük hâline getirmek, her teşhiste sıfırdan arama yapmayı ortadan kaldırıyor.
Kaynaklar
Yazıdaki her olgusal iddianın yanındaki kod bu listeye denk gelir. Resmî belge, üreticinin kendi dokümanıdır: bir yeteneğin var olduğunu kanıtlar, o yeteneğin sizin ortamınızda ne kadar iyi çalıştığını kanıtlamaz. Bir rakam buradaki belgede farklıysa belge doğrudur, yazı eskimiştir; bize yazın, düzeltelim.
- K1.1 · SQL Server 2025’te neler yeni Resmî belge
https://learn.microsoft.com/en-us/sql/sql-server/what-s-new-in-sql-server-2025 - K1.2 · ALTER DATABASE SCOPED CONFIGURATION Resmî belge
https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-database-scoped-configuration-transact-sql - K6.6 · Sorgu Deposu Resmî belge
https://learn.microsoft.com/en-us/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store - K2.1 · Sayfa ve extent mimari rehberi Resmî belge
https://learn.microsoft.com/en-us/sql/relational-databases/pages-and-extents-architecture-guide - K3.1 · İşlem kilitleme ve satır sürümleme rehberi Resmî belge
https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide - K2.2 · İşlem günlüğü mimari rehberi Resmî belge
https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-log-architecture-and-management-guide - K6.8 · sys.dm_os_wait_stats Resmî belge
https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-os-wait-stats-transact-sql - K2.4 · Kurtarma modelleri Resmî belge
https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/recovery-models-sql-server - K1.3 · sys.databases Resmî belge
https://learn.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-databases-transact-sql - K5.5 · İstatistikler Resmî belge
https://learn.microsoft.com/en-us/sql/relational-databases/statistics/statistics - K7.2 · Geri yükleme ve kurtarma Resmî belge
https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/restore-and-recovery-overview-sql-server
Çıkar beyanı. Bu yazıyı yazan Çağlar Özenç, DMC Bilgi Teknolojileri kurucusudur ve Microsoft Data Platform MVP unvanını taşır. DMC, SQL Server tarafında sağlık değerlendirmesi, başarım ayarlama ve yönetilen işletme hizmeti satar. Yani bu konuda tarafsız değil, taraflı ve bunu açıkça yazıyoruz. Yazıdaki her olgusal iddia Microsoft’un kendi belgesine dayanır ve yazının sonundaki kaynak listesinde kodludur. Aksini gösteren bir ölçümünüz varsa yazın, düzeltiriz.