Ich mache einige Nachforschungen zur Migration unserer SSRS 2005 bis 2015. ATM Ich habe eine DB-VM, auf der die Produktions-DB, Berichts-DB, Berichts-TempDB und Reporting Services/Server gehostet werden . Sehr problematisch, wie Sie sehen können.SQL Server-Berichtsdatenbankkatalog und Berichtsserver
ich die folgenden Szenarien für die neue Umgebung am überlegen (keine Sorge über die $$$ atm):
- Produktion db auf 1 VM, Bericht DB und Bericht TempDB auf einem anderen VM, Reporting Service auf einem anderen VM (3 VMs)
- Produktion db + Bericht DB + Bericht TempDB auf 1 VM, Reporting Service auf einem anderen VM (2 VMs)
- Produktion db auf 1 VM, Bericht-DB + Bericht TempDB + Reporting Services auf einer anderen VM (2 VMs)
- Produktionsdatenbank auf 1 VM, transaktional repliziert auf eine andere VM, auf der auch Report DB + Report TempDB + Reporting Services gehostet wird. Reporting Services verwenden die replizierte Datenbank nur als Quelle für Berichte. (2 VMs)
DR ist nicht ein Problem, das vereinbarte RTO ist 4 Stunden (!)
Wir haben nicht viel von Benutzern haben, aber viele Berichte (> 200) Einige sind grafikintensiv. Ad-hoc- und Off-Hour-Report-Snapshots erstellt. Wir haben einige Timeout-Probleme. (ein- oder zweimal am Tag)
Ich bin auf der Suche nach einem der oben genannten Szenarien, die die beste Leistung bietet.
Kann jemand vorschlagen, welcher der sinnvollste Ansatz ist? Kann mehr Informationen liefern.
Vielen Dank im Voraus. WM
Ich schlage vor, Sie versuchen, die Belastung auf Ihrem bestehenden System zu analysieren. Wird der Report tempdb häufig verwendet? (wahrscheinlich nicht). Gibt es irgendwelche Probleme aufgrund des direkten Lesens von Prod? Ich werde sagen, wenn Sie Ihre letzte Option verwenden, haben Sie im Grunde einen eigenständigen Server für Reportingzwecke, der config/dev in Zukunft viel einfacher machen könnte. –