SSRS Veritabanı Upgrade Hatası mı Aldınız? Gerçek Upgrade Scriptini Oluşturup Sorunu Çözün

Bu yazıda, SSRS veritabanı upgrade scripti nasıl elde edilir ve gerçek hata nasıl bulunup çözülür anlatıyoruz. SQL Server 2008’den bu yana Microsoft, Reporting Services Configuration Manager’daki eski “Upgrade” butonunu ve elle çalıştırılan .sql dosyalarını kaldırdı. Bu, upgrade işleminin ortadan kalktığı anlamına gelmiyor; sadece perde arkasına, Report Server servisinin içine taşındı. Çoğu zaman bunu hiç fark etmezsiniz: SQL Server’ı patch’lersiniz, Report Server servisi yeniden başlar, eski bir veritabanı şeması görür ve ReportServer veritabanını arka planda sessizce günceller — Microsoft’un resmi upgrade dokümantasyonunda da bu davranış aynen böyle tarif edilir.

Sorun, bu sessiz güncellemenin yarıda kalması ya da hatayla sonuçlanmasıdır. Ekranda ne bir uyarı ne de anlaşılır bir hata mesajı çıkar — raporlar bir anda açılmaz olur. Tek ipucu genelde “An error occurred within the report server database” gibi belirsiz bir mesaj, ya da RSManagement log dosyasına gömülü “Database upgrade failed!! The database may now be in an inconsistent state.” satırıdır. Bu noktada tahmin yürütmek zaman kaybettirir. En doğru yaklaşım, SSRS’in arka planda çalıştırmaya çalıştığı gerçek upgrade scriptini elde etmek ve hangi adımın neden başarısız olduğunu doğrudan görmektir.

SSRS Veritabanını Güncellemenin Üç Yolu

1. Otomatik Güncelleme (varsayılan davranış)

Neredeyse her patch işleminde karşınıza çıkan yöntem budur. Reporting Services Configuration Manager’ı açar, servisi eski bir ReportServer veritabanına bağlarsınız (ya da servisi başlatırsınız); şema güncellemesi servis ayağa kalkar kalkmaz otomatik olarak çalışır. Herhangi bir onay istemez, script de göstermez — ya sorunsuz tamamlanır ya da sessizce başarısız olur.

2. Configuration Manager Üzerinden

Eski bir ReportServer veritabanını elle daha yeni bir Report Server’a bağlarsanız, sürüm farkını fark eder ve güncellemeyi onaylamanızı ister. “Apply” dediğinizde aynı güncelleme mantığı çalışır; tek fark, önünüze açık bir onay adımı çıkmasıdır.

3. SSRS Veritabanı Upgrade Scripti: WMI ile Elle Oluşturma

Asıl işinize yarayacak yöntem budur — özellikle bir şeyler ters gittiğinde veya üretim ortamındaki her şema değişikliğinin önce bir DBA tarafından incelenmesi gerektiğinde. Reporting Services, otomatik güncellemenin arka planda çalıştıracağı T-SQL kodunu, hiçbir şeyi veritabanına dokundurmadan üretmenizi sağlayan bir WMI metodu sunar: GenerateDatabaseUpgradeScript. SSRS veritabanı upgrade scripti, bu yöntemle üretildiğinde veritabanına hiçbir şey uygulamadan tam olarak hangi T-SQL komutlarının çalışacağını gösterir.

# SSRS 2022'ye ait olası WMI namespace'lerini sırayla tarayalım
$possibleNamespaces = @(
    "root\Microsoft\SqlServer\ReportServer\RS_SSRS\v16\Admin",
    "root\Microsoft\SqlServer\ReportServer\RS_MSSQLSERVER\v16\Admin",
    "root\Microsoft\SqlServer\ReportServer\RS_SSRS\v15\Admin"  # Yükseltilmiş bir sunucuda bazen v15'te kalabilir
)

$correctNamespace = $null

foreach ($ns in $possibleNamespaces) {
    try {
        $check = Get-WmiObject -Namespace $ns -Class "MSReportServer_ConfigurationSetting" -ErrorAction Stop
        if ($check) {
            $correctNamespace = $ns
            Write-Host "Doğru namespace bulundu: $correctNamespace" -ForegroundColor Green
            break
        }
    } catch {
        # Bu namespace geçerli değil, sonrakine geç
    }
}

if ($correctNamespace) {
    $wmi = Get-WmiObject -Namespace $correctNamespace -Class "MSReportServer_ConfigurationSetting"

    # Ham scripti üret (veritabanınızın adı farklıysa "ReportServer" kısmını güncelleyin)
    $rawScript = $wmi.GenerateDatabaseUpgradeScript("ReportServer", "16.0")

    if (![string]::IsNullOrEmpty($rawScript)) {
        # Satır sonlarını CRLF'ye normalize et
        $cleanScript =$rawScript -replace "(?<!\r)\n", "`r`n"
        $cleanScript | Out-File "C:\temp\SSRS_Upgrade_Script.sql"
        Write-Host "İşlem başarılı! Script C:\temp\SSRS_Upgrade_Script.sql konumuna kaydedildi." -ForegroundColor Cyan
    } else {
        Write-Host "Namespace bulundu ancak script üretilemedi (veritabanı adı 'ReportServer' olmayabilir)." -ForegroundColor Yellow
    }
} else {
    Write-Host "Hiçbir geçerli SSRS namespace'i bulunamadı. WMI hizmeti yanıt vermiyor olabilir." -ForegroundColor Red
}

Bu versiyon, önceki tek satırlık namespace tahminini elle güncellemek yerine olası SSRS 2022 namespace’lerini otomatik olarak dener — sabit kurulumlarda genelde RS_SSRS, adlandırılmış örneklerde RS_MSSQLSERVER kullanılır, bu yüzden ikisi de sırayla denenir. Gözden kaçırılmaması gereken birkaç nokta:

• Namespace yolu sürüme göre değişir — SQL Server 2017 için v14, 2019 için v15, 2022 için v16 kullanılır. Yanlış sürüm yazarsanız anlamlı bir hata almazsınız, sadece boş bir WMI sınıfı dönersiniz; script bu yüzden birden fazla adayı sırayla dener.
• GenerateDatabaseUpgradeScript‘in ikinci parametresi SQL Server sürümünüz değil, ulaşmak istediğiniz hedef katalog sürümüdür (SQL Server 2022 için "16.0"). Bunu motor sürümüne göre değil, geçmek istediğiniz SSRS sürümüne göre girin.
• Bu komut yalnızca scripti üretir, veritabanına hiçbir şey uygulamaz. Servisin güncellemeyi tekrar kendi başına denemesine izin vermeden önce en güvenli teşhis adımı olmasının sebebi de budur.

SSRS Veritabanı Upgrade Scripti Çalıştırılınca Gerçekte Ne Görürsünüz?

Yukarıdaki örnekte veritabanı adının ReportServer olduğunu varsayıyoruz — farklı bir named instance kullanıyorsanız gerçek veritabanı adınız ReportServer$InstanceAdı şeklinde olacaktır.

Böylece belirsiz bir “bir şeyler bozuldu” durumu, net ve çözülebilir bir T-SQL hatasına dönüşür — sorun bir trigger olabilir, ya da msdb veritabanındaki bir operator veya yetki/rol eksikliği olabilir. Sahada en sık karşılaştığımız hatalar genelde şu birkaç kalıptan birine giriyor:

Bu hataların hiçbiri canlı bir veritabanında deneme yanılmayla çözülecek türden değil. Gerçek scriptin asıl değeri de burada ortaya çıkıyor: hangi satırın başarısız olduğunu ve hangi nesneyi etkilediğini net görürsünüz, genel bir arayüz hatasından tahmin yürütmek zorunda kalmazsınız.

Sorun Pratikte Nasıl Çözülüyor?

SSRS veritabanı upgrade scripti hata verdiğinde, çözüm genelde “scripti tekrar çalıştır, umalım ki bu sefer geçsin” değildir. Deneyimli bir DBA çoğunlukla şu sırayı izler:

1. Çakışmayı ayırt edin. Scale-out ortamlarda bir şeye dokunmadan önce tüm node’ların kapalı olduğundan ve şemanın hepsinde aynı durumda olduğundan emin olun.
2. Şema çakışmasını doğrudan giderin. Önceki yarım kalmış bir güncellemeden kalan fazla ya da sahipsiz kolonları, scriptin beklediği yapıyla eşleşecek şekilde elle temizleyin.
3. Büyük sürüm farklarını kademeli kapatın. Script eski veri tipi dönüşümünde takılıyorsa, doğrudan hedefe değil ara bir sürümden geçin (örneğin 2012 → 2017 → 2019). Böylece her aşama daha küçük, daha iyi test edilmiş bir farkı yönetir.
4. Düzeltilmiş scripti önce bir kopya üzerinde tekrar çalıştırın, sorunsuz tamamlandığını görün, sonra üretime uygulayıp Report Server servisinin normal şekilde bağlanmasına izin verin.
5. DBUpgradeHistory tablosundaki sürüm bilgisinin hedef SSRS sürümüyle uyuştuğunu doğrulayın ve güncellemeyi kapatmadan önce raporların gerçekten doğru göründüğünden emin olun.

Portalı zorla açmak için DBUpgradeHistory tablosundaki sürüm numarasını elle değiştirmek internette bazen çözüm diye önerilir — değildir. Bu, altta yatan şema sorununu çözmez, sadece gizler; genelde daha sonra tespiti daha zor raporlama hataları olarak geri döner. Bunu bir çözüm değil, son çare bir teşhis sinyali olarak görün.

In-Place Upgrade mi, Migration mı? Sürümünüze Göre Yol Değişiyor

Hangi upgrade yöntemini kullanabileceğiniz, nereden nereye geçtiğinize bağlı — ve bu ayrım genelde atlanıyor. Microsoft’un upgrade ve migration dokümantasyonuna göre:

• SQL Server 2016 ve öncesi → SQL Server 2016 ve öncesi: Klasik in-place upgrade çalışır; SQL Server kurulum medyası SSRS’i de günceller.
• SQL Server 2016 ve öncesi → SSRS 2017 ve sonrası: In-place upgrade desteklenmiyor. SSRS 2017 ile birlikte SQL Server kurulumundan ayrılıp bağımsız bir ürün haline geldi; bu nedenle migration (veritabanını yeni bir SSRS 2017+ kurulumuna bağlama) yapmanız gerekiyor.
• SSRS 2017 ve sonrası → sonraki sürümler: Kurulum GUID’leri aynı kaldığı için in-place upgrade tekrar mümkün; SQLServerReportingServices.exe ile doğrudan üzerine kurulum yapılabiliyor.

Scale-out bir dağıtımda upgrade’i tüm node’ları Configuration Manager üzerinden scale-out’tan çıkarıp, bir node’u güncelleyip, sonra tek tek geri ekleyerek yapmanız gerekiyor — tabloda yukarıda bahsettiğimiz SessionData hatasının en sık çıktığı senaryo tam olarak bu.

SQL Server 2022’ye Geçerken SSRS’te Neler Değişti?

Upgrade başarıyla tamamlansa bile bazı raporlar veya entegrasyonlar beklenmedik şekilde çalışmayabilir — çünkü SSRS her büyük sürümde bazı özellikleri tamamen kaldırıyor. Microsoft’un discontinued functionality listesine göre son sürümlerde kaldırılan başlıca özellikler:

Özellikle XLS/DOC export’una bağımlı otomasyonlar ve eski Mobile Report aboneleri, upgrade sonrası veritabanı sorunsuz güncellenmiş olsa bile “rapor artık farklı davranıyor” şikayetiyle karşımıza çıkıyor. Bu yüzden upgrade planında sadece şema değil, kullanılan özelliklerin listesi de gözden geçirilmeli.

Sık Sorulan Sorular