Tehlikeli SQL Server Build’leri: Sürümünüzü Nasıl Kontrol Eder, Güncellemeleri Nasıl Planlarsınız?

Her SQL Server instance’ı belirli bir build üzerinde çalışır ve bu build, sunucuya hangi güncellemelerin uygulandığını gösterir. Microsoft zaman zaman belirli build’lerde veri bozulmasına, yanlış sorgu sonuçlarına ya da güvenlik açıklarına yol açan hatalar tespit eder ve bunları sonraki güncellemelerde giderir. Ancak bu düzeltmeler yalnızca güncelleme uygulandığında işe yarar. İncelediğimiz sunucuların önemli bir kısmının hâlâ kurulduğu günkü build ile çalıştığını görüyoruz.

Bu rehberde bir build numarasının neyi ifade ettiğini, bir build’i hangi durumların riskli hale getirdiğini, sunucunuzun durumunu nasıl kontrol edebileceğinizi ve güncellemeleri üretim ortamını riske atmadan nasıl planlayabileceğinizi ele alıyoruz.

SQL Server Build Numarası Neyi İfade Eder?

SQL Server sürüm bilgisi 16.0.4035.4 gibi dört parçalı bir numaradan oluşur. İlk parça ana sürümü, üçüncü parça ise build numarasını gösterir. Build numarası, sunucuya hangi Cumulative Update (CU) veya güvenlik güncellemesinin (GDR) uygulandığını tespit etmek için kullanılır. Ana sürüm numaralarının karşılıkları şöyledir:

Sunucunuzun sürüm ve güncelleme bilgilerini, metin ayrıştırmaya gerek kalmadan SERVERPROPERTY fonksiyonuyla alabilirsiniz:

SELECT
    SERVERPROPERTY('ProductVersion')             AS product_version,
    SERVERPROPERTY('ProductMajorVersion')        AS major_version,
    SERVERPROPERTY('ProductLevel')               AS product_level,   -- RTM, SP1 ...
    SERVERPROPERTY('ProductUpdateLevel')         AS update_level,    -- CU4 ...
    SERVERPROPERTY('ProductUpdateReference')     AS kb_article,      -- KB5026717 ...
    SERVERPROPERTY('Edition')                    AS edition,
    SERVERPROPERTY('ResourceLastUpdateDateTime') AS last_update_applied;

ProductUpdateLevel ve ProductUpdateReference değerleri, 2015 sonrasında yayımlanan güncellemelerle birlikte gelmiştir; daha eski build’lerde NULL dönebilir. ResourceLastUpdateDateTime ise sunucuya en son ne zaman güncelleme uygulandığına dair pratik bir gösterge sunar.

Bir Build’i Riskli Hale Getiren Durumlar

Her güncelleme düzinelerce düzeltme içerir ve bunların büyük bölümü yalnızca belirli koşullarda ortaya çıkan sorunlarla ilgilidir. Bir build’in gerçekten riskli sayılması için genellikle aşağıdaki dört durumdan birinin söz konusu olması gerekir.

1. Veri bozulmasına yol açan hatalar

Bu kategorinin en bilinen örneği, SQL Server 2012 ve SQL Server 2014’ün belirli build’lerinde görülen online index rebuild hatasıdır. Online index rebuild paralel olarak çalışırken aynı tabloda çok sayıda satırı değiştiren eşzamanlı işlemler varsa, belirli koşullar altında clustered index’te bozulma ve veri kaybı yaşanabiliyordu. Örneğin replikasyonun bir tabloyu yoğun şekilde güncellediği sırada aynı tabloda çalışan bir index bakımı bu senaryoyu tetikleyebiliyordu. Microsoft bu sorunu KB2969896 ile giderdi; güncelleme uygulanana kadar önerilen geçici çözüm ise online index rebuild işlemlerini MAXDOP = 1 ile seri olarak çalıştırmaktı.

2. Yanlış sonuç döndüren hatalar

Bu tür hatalar, hata mesajı üretmedikleri için çoğu zaman uzun süre fark edilmez. Örneğin SQL Server 2022 CU4 ile birlikte, azalan sıralama (DESC) ile tanımlanmış index’leri kullanan ve WHERE ... IN ya da birden fazla eşitlik koşulu içeren sorgular yanlış sonuç döndürebiliyordu. Microsoft bu sorunu CU4’ün bilinen sorunlar listesine ekledi ve CU5 ile giderdi. Geçici çözüm olarak güncellemenin kaldırılması ya da trace flag 13166’nın etkinleştirilip DBCC FREEPROCCACHE çalıştırılması önerildi.

3. Microsoft’un geri çektiği güncellemeler

Bazı durumlarda bir güncelleme yayımlandıktan sonra ciddi bir sorun tespit edilir ve Microsoft güncellemeyi dağıtımdan kaldırır. SQL Server 2019 CU7 bunun bir örneğidir. Database snapshot özelliğinde tespit edilen bir güvenilirlik sorunu nedeniyle CU7, Download Center, Microsoft Update Catalog ve Linux repolarından kaldırıldı; düzeltme CU8 ile yayımlandı. Bu sorun yalnızca snapshot’ları bilinçli olarak kullanan ortamları değil, arka planda database snapshot kullanan DBCC CHECKDB çalıştıran tüm ortamları ilgilendiriyordu. Geri çekilmiş bir güncellemeyi daha önce indirip saklamış olmak, onu sonradan farkında olmadan kurma riskini de beraberinde getirir.

4. Güvenlik açıkları ve desteği sona ermiş sürümler

Güvenlik açıkları da build seviyesine bağlıdır. Örneğin Temmuz 2015’te yayımlanan MS15-058 bülteni, SQL Server 2008’den 2014’e kadar birçok sürümde uzaktan kod çalıştırmaya imkân tanıyan açıkları kapatıyordu; bu güncellemeyi almamış build’ler bugün hâlâ aynı açığı taşır. Daha da önemlisi, desteği sona ermiş bir sürüm artık yeni güvenlik düzeltmesi almaz. SQL Server 2016’nın extended support dönemi Temmuz 2026’da sona erdi; bu tarihten sonra güvenlik güncellemeleri yalnızca ücretli Extended Security Updates programı kapsamında sunuluyor. Desteklenen sürüme geçiş planlaması için SQL Server upgrade rehberimize göz atabilirsiniz.

Sunucunuzun Durumunu Nasıl Kontrol Edersiniz?

Belirli build aralıklarını sabit olarak içeren script’ler kısa sürede güncelliğini yitirir; çünkü her ay yeni güncellemeler ve yeni bilinen sorunlar yayımlanır. Bunun yerine aşağıdaki adımları düzenli bir süreç haline getirmenizi öneriyoruz:

1. Build bilgisini toplayın. Yukarıdaki sorguyu tüm instance’larda çalıştırın. Çok sayıda sunucu yönetiyorsanız SSMS’teki Registered Servers veya Central Management Server özelliğiyle sorguyu bir grup sunucuda aynı anda çalıştırabilirsiniz.
2. Microsoft’un sürüm listesiyle karşılaştırın. Microsoft’un “Latest updates and version history for SQL Server” sayfası, her sürüm için yayımlanan tüm CU ve GDR build’lerini KB numaralarıyla birlikte listeler. Böylece hangi güncellemede olduğunuzu ve en güncel build’in kaç adım gerisinde kaldığınızı görebilirsiniz.
3. Bilinen sorunları okuyun. Her CU’nun KB makalesinde “Known issues in this update” başlıklı bir bölüm bulunur. Hem kullandığınız CU’nun hem de geçmeyi planladığınız CU’nun bu bölümünü inceleyin.
4. Kullandığınız özelliklere odaklanın. Sonraki CU’ların düzeltme listelerinde Always On, columnstore, Query Store veya replikasyon gibi ortamınızda kullandığınız özelliklere ait maddeleri arayın. Sizi ilgilendiren bir veri bozulması veya yanlış sonuç düzeltmesi varsa, güncellemeyi önceliklendirin.

GDR mı, CU mu?

SQL Server 2017’den itibaren service pack yayımlanmıyor; tüm düzeltmeler Cumulative Update’ler aracılığıyla sunuluyor. Bunun yanında yalnızca güvenlik düzeltmelerini içeren GDR güncellemeleri de bulunuyor. Bu iki yol arasındaki fark, güncelleme stratejinizi doğrudan etkiler:

• GDR dalı yalnızca güvenlik ve kritik düzeltmeleri içerir. Değişiklik miktarını en aza indirir, ancak veri bozulması veya yanlış sonuç gibi güvenlik dışı hataların düzeltmelerini almazsınız.
• CU dalı güvenlik düzeltmeleri dahil tüm düzeltmeleri içerir. Güvenlik güncellemeleri bu dal için de ayrı bir paket olarak yayımlanır.

Microsoft, CU’ların service pack’lerle aynı seviyede test edildiğini belirtiyor ve yayımlandıkça proaktif olarak uygulanmalarını öneriyor. Bizim de üretim ortamlarının büyük çoğunluğu için önerimiz CU dalında kalmak ve güncellemeleri düzenli bir takvimle uygulamaktır.

Güncellemeleri Güvenli Bir Şekilde Planlamak

Riskli bir build’den kurtulmanın yolu güncelleme yapmaktır; ancak güncellemenin kendisi de planlı yürütülmesi gereken bir değişikliktir. Üretim ortamlarında izlediğimiz süreç şu adımlardan oluşur:

• Kısa bir gözlem süresi bırakın. Yeni yayımlanan bir CU’yu hemen üretime almak yerine, Microsoft’un bilinen sorunlar listesini güncellemesi veya paketi yeniden yayımlaması ihtimaline karşı birkaç hafta beklemek yaygın ve makul bir uygulamadır. Kritik bir güvenlik açığı söz konusuysa bu süre kısaltılmalıdır.
• Önce test ortamında uygulayın. Güncellemeyi üretime benzer bir iş yükü altında test edin; kritik raporları, job’ları ve uygulama akışlarını kontrol edin.
• Yedek ve tutarlılık kontrolünü doğrulayın. Güncellemeden önce geçerli bir tam yedek bulunduğundan ve yakın tarihli bir DBCC CHECKDB sonucunun temiz olduğundan emin olun.
• Yüksek erişilebilirlik ortamlarında kademeli ilerleyin. Always On Availability Group ve failover cluster ortamlarında önce secondary node’ları güncelleyin, ardından failover yapıp eski primary’yi güncelleyin. Ayrıntılar için Always On ortamlarında patch uygulama rehberimize göz atabilirsiniz.
• Güncelleme sonrasını doğrulayın. Build numarasını yeniden kontrol edin, error log’u inceleyin ve Agent job’larının sorunsuz çalıştığını teyit edin. Nadir de olsa bir CU sonrasında veritabanı yükseltme script’i hata verebilir; bu durumda başvurulabilecek acil durum araçları trace flag rehberimizde yer alıyor.
• Geri dönüş planını hazırlayın. CU’lar Windows’taki “Programs and Features” üzerinden kaldırılabilir. Geri dönüş adımlarını ve bunun ne kadar süreceğini, güncellemeden önce belirlemiş olmanız gerekir.

Güncellemeyi Hemen Yapamıyorsanız

Bazen bakım penceresi, uygulama tedarikçisinin onayı veya değişiklik yönetimi süreçleri nedeniyle güncellemeyi hemen yapmak mümkün olmaz. Bu durumda riski geçici olarak azaltmak için şu adımları değerlendirebilirsiniz:

• Microsoft’un ilgili KB makalesinde belirttiği geçici çözümü uygulayın; örneğin online index rebuild hatası için index bakım job’larında MAXDOP = 1 kullanmak ya da CU4’teki yanlış sonuç sorunu için belgelenmiş trace flag’i etkinleştirmek gibi.
• Güvenlik açıklarında sunucunun ağ erişimini daraltın ve yetkili hesapları gözden geçirin. Bu konuda SQL Server güvenlik yazımız yol gösterici olacaktır.
• Veri bozulması riski taşıyan build’lerde DBCC CHECKDB sıklığını artırın ve yedek saklama süresini, bir bozulmayı tespit etmeden önceki temiz yedeğe ulaşabilecek kadar uzun tutun.
• Güncellemeyi bir sonraki bakım penceresi için planlayın ve tarihini değişiklik kaydına işleyin; geçici çözümlerin kalıcı hale gelmesine izin vermeyin.