SQL Server Sunucularında Windows Otomatik Güncellemeleri: Kapatmak Yerine Nasıl Kontrol Edilir?

Windows güncellemelerinin varsayılan ayarlarla çalıştığı bir SQL Server sunucusunda, güncellemelerin ne zaman indirileceği, kurulacağı ve sunucunun ne zaman yeniden başlatılacağı büyük ölçüde işletim sisteminin kararına kalır. Bu durum, mesai saatinde beklenmedik bir yeniden başlatmaya, uzun süren bir veritabanı kurtarma sürecine ya da cluster ortamlarında planlanmamış bir failover’a yol açabilir. Öte yandan güncellemeleri tamamen kapatmak da sunucuyu bilinen güvenlik açıklarına karşı savunmasız bırakır.

Bu nedenle SQL Server sunucularında amaç, Windows güncellemelerini devre dışı bırakmak değil, ne zaman ve nasıl uygulanacaklarını kontrol altına almaktır. Bu rehberde otomatik güncellemelerin SQL Server açısından neden risk oluşturduğunu, mevcut ayarınızı nasıl kontrol edebileceğinizi ve önerdiğimiz yapılandırmayı ele alıyoruz.

Otomatik Güncellemeler SQL Server İçin Neden Risk Oluşturur?

Windows güncellemelerinin büyük bölümü kurulumun tamamlanması için yeniden başlatma gerektirir. Bu yeniden başlatma bir masaüstü bilgisayarda küçük bir kesinti anlamına gelirken, bir veritabanı sunucusunda çok daha geniş etkiler doğurur:

• Açık işlemler geri alınır. SQL Server servisi durduğunda tamamlanmamış işlemler sonlandırılır; servis yeniden başladığında her veritabanı bir kurtarma (recovery) sürecinden geçer. Uzun süren işlemlerin yoğun olduğu sunucularda bu süreç, veritabanlarının dakikalarca erişilemez kalmasına yol açabilir. Bu tür bir kesintide izlenmesi gereken adımları SQL Server kesintisinin ilk 30 dakikası yazımızda ele alıyoruz.
• Cluster ortamlarında planlanmamış failover tetiklenebilir. Always On Availability Group veya Failover Cluster Instance node’larından birinin kendi kendine yeniden başlaması, iş yükünün beklenmedik bir anda başka bir node’a geçmesine neden olur.
• Kurulum sırasında kaynak tüketimi artar. Güncellemelerin indirilmesi ve kurulması CPU, disk ve ağ kaynaklarını kullanır; bu işlemler yoğun saatlere denk geldiğinde, kaynağı açıkça görülmeyen performans sorunları ortaya çıkabilir.
• SQL Server güncellemeleri de bu sürece dahil olabilir. Microsoft Update üzerinden SQL Server güvenlik güncellemeleri de dağıtılır. Bu güncellemelerin kurulumu sırasında SQL Server servisi durdurulur.

Güncellemeleri Tamamen Kapatmak Neden Doğru Bir Çözüm Değil?

Bu riskler nedeniyle Windows Update’i tamamen devre dışı bırakmak sık başvurulan bir yöntemdir. Ancak bu yaklaşım yeniden başlatma sorununu ortadan kaldırsa da yerine çok daha ciddi bir risk getirir: güncelleme almayan bir sunucu, yayımlanan her güvenlik açığına karşı korumasız kalır. Saldırıların önemli bir kısmı SQL Server’a işletim sistemi üzerinden ulaştığı için, işletim sisteminin güncel tutulması veritabanı güvenliğinin de temel bir parçasıdır. Bu konuyu SQL Server güvenlik sıkılaştırma rehberimizde ayrıntılı olarak ele alıyoruz.

Mevcut Ayarınızı Nasıl Kontrol Edersiniz?

Sunucunuzdaki güncelleme davranışını birkaç farklı yerden kontrol edebilirsiniz:

• sconfig: Windows Server’da sconfig aracını çalıştırıp güncelleme ayarları menüsüne girdiğinizde, mevcut modun Automatic, Download only veya Manual olduğunu görebilirsiniz. Microsoft’a göre varsayılan mod “Download only”dır: güncellemeler taranır ve indirilir, ancak kurulum yöneticinin onayını bekler. “Automatic” modda ise güncellemeler her gün saat 03:00’te kurulur.
• Grup ilkesi: Etki alanındaki sunucularda geçerli olan ayarlar Group Policy ile belirlenir. Hangi politikaların uygulandığını gpresult /h rapor.html komutuyla oluşturacağınız raporda görebilirsiniz.
• Kayıt defteri: Politika ile tanımlanmış ayarlar aşağıdaki kayıt defteri anahtarında tutulur.

# Politika ile tanımlanmış Windows Update ayarları
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' -ErrorAction SilentlyContinue |
    Select-Object NoAutoUpdate, AUOptions, ScheduledInstallDay, ScheduledInstallTime, UseWUServer

# Son yeniden başlatmaları kim veya hangi süreç başlattı?
Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 1074 } -MaxEvents 10 |
    Select-Object TimeCreated, Message

System log’daki 1074 numaralı olaylar, yeniden başlatmayı hangi sürecin hangi gerekçeyle başlattığını gösterir. Beklenmedik yeniden başlatmalarda Windows Update bileşenlerinin bu listede görünmesi, güncelleme ayarlarının gözden geçirilmesi gerektiğine işaret eder. SQL Server tarafında ise servisin en son ne zaman başladığını şu sorguyla görebilirsiniz:

SELECT sqlserver_start_time
FROM sys.dm_os_sys_info;

Önerilen Yapılandırma

SQL Server sunucuları için hedef, güncellemelerin otomatik olarak tespit edilip indirilmesi, ancak kurulum ve yeniden başlatmanın yalnızca planlı bir bakım penceresinde, yöneticinin kontrolünde yapılmasıdır. Ortamınızın büyüklüğüne göre bunu iki şekilde sağlayabilirsiniz.

1. Merkezi güncelleme yönetimi

Birden fazla sunucunun bulunduğu ortamlarda en sağlıklı yöntem, güncellemeleri WSUS, Configuration Manager veya kullandığınız merkezi patch yönetim aracı üzerinden dağıtmaktır. Bu yaklaşımda SQL Server sunucularını ayrı bir grupta toplamanızı, güncellemeleri önce test grubunda onaylamanızı ve üretim grubuna ancak test sonuçları değerlendirildikten sonra açmanızı öneriyoruz. Böylece hangi sunucunun hangi güncellemeyi ne zaman alacağı tamamen sizin kontrolünüzde olur.

2. Grup ilkesi veya kayıt defteri ile yapılandırma

Group Policy’de Computer Configuration > Administrative Templates > Windows Components > Windows Update > Configure Automatic Updates ayarı için Microsoft’un sunucular için sunduğu 7 – Notify for install and notify for restart seçeneğini öneriyoruz. Bu seçenek Windows Server 2016 ve sonrasında kullanılabilir; güncellemeler otomatik olarak indirilir, ancak kurulum ve yeniden başlatma için yönetici onayı beklenir. Daha eski sunucularda benzer bir sonuç için 3 – Auto download and notify for install seçeneği kullanılabilir.

Güncellemelerin belirli bir gün ve saatte otomatik kurulmasını sağlayan 4 – Auto download and schedule the install seçeneğini ise SQL Server sunucuları için önermiyoruz. Zamanlama bakım penceresine denk getirilse bile, yeniden başlatma bir DBA’nın gözetimi olmadan gerçekleşir ve sonrasında servisin, veritabanlarının ve job’ların durumu kontrol edilmez.

Etki alanına dahil olmayan sunucularda aynı ayarı kayıt defteri üzerinden yapabilirsiniz:

# Güncellemeleri indir, kurulum ve yeniden başlatma için yönetici onayı bekle
$path = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU'
New-Item -Path $path -Force | Out-Null
Set-ItemProperty -Path $path -Name NoAutoUpdate -Value 0 -Type DWord
Set-ItemProperty -Path $path -Name AUOptions    -Value 7 -Type DWord   # Windows Server 2016 ve sonrası

Etki alanındaki sunucularda Group Policy ayarları yerel kayıt defteri değerlerinin üzerine yazacağı için değişikliği doğrudan politika üzerinden yapmanız gerekir.

SQL Server Güncellemeleri ve Microsoft Update

Windows Update ayarlarında “Microsoft ürünleri için güncellemeleri al” seçeneği açıksa ya da sunucular WSUS’a bağlıysa, SQL Server güncellemeleri de bu kanallar üzerinden sunulabilir. Microsoft’un dokümantasyonuna göre otomatik güncelleme kanalı, henüz CU almamış instance’lara yalnızca güvenlik güncellemelerinin GDR sürümünü, CU dalındaki instance’lara ise güvenlik güncellemesinin CU dalı sürümünü sunar. WSUS ve Microsoft Update Catalog kanalı ise desteklenen sürümlerde, hiç güncelleme almamış bir instance’a da doğrudan CU sunabilir.

Aylık Bakım Penceresini Planlamak

Microsoft, güvenlik güncellemelerini her ayın ikinci salı günü yayımlıyor. Bu düzen, güncellemeleri öngörülebilir bir takvimle planlamayı kolaylaştırır. Tek sunuculu ortamlar için önerdiğimiz akış şöyledir:

1. Güncellemeleri yayımlandıkları hafta test sunucularına uygulayın ve uygulamaların, job’ların ve raporların sorunsuz çalıştığını doğrulayın.
2. Üretim sunucuları için uygulama sahipleriyle önceden belirlenmiş bir bakım penceresi kullanın.
3. Güncellemeden önce son yedeklerin başarılı olduğunu kontrol edin.
4. Güncellemeleri kurun ve sunucuyu yeniden başlatın.
5. Yeniden başlatmadan sonra SQL Server ve SQL Server Agent servislerinin çalıştığını, tüm veritabanlarının çevrimiçi olduğunu ve error log’da beklenmedik bir hata bulunmadığını doğrulayın.

-- Yeniden başlatma sonrası: çevrimiçi olmayan veritabanı var mı?
SELECT name, state_desc
FROM sys.databases
WHERE state_desc <> N'ONLINE';

Always On Availability Group ve Failover Cluster Instance ortamlarında ise güncellemelerin node node, belirli bir sırayla ve manuel failover ile uygulanması gerekir. Bu süreci Always On ortamlarında SQL Server ve Windows güncellemeleri rehberimizde adım adım ele alıyoruz.