2016-04-11 13 views
0

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

+0

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. –

Antwort

1

Wenn Ihre "production db" eine Art von OLTP-System ist, sollte dies vollständig getrennt von jeder Berichterstattung oder Analyse Aktivität sein. Wenn Sie über die Ressourcen verfügen, empfehle ich, eine AlwaysOn-Gruppe zu erstellen (den Nachfolger der Spiegelung in SQL 2005) und das sekundäre Replikat als Quelle für Ihre Berichte zu verwenden, z.

  1. Produktion db (1 VM)
  2. AlwaysOn sekundären Replikat der Produktion, lesen Sie in nur Modus (1 VM)
  3. Report db & Reporting Services (1 VM)

Dies hält Ihre Produktions-DB wird nicht von Berichtsabfragen beeinflusst, indem die Arbeit auf das Replikat ausgelagert wird (was auch als HA/Failover-Datenbank dient) und die Berichtserver-Komponenten auf einer einzelnen VM zusammengefasst werden, was basierend auf Ihrer Beschreibung ausreichend sein sollte Arbeitsbelastung.

+0

Ich stimme dem alwaysOn zu, aber entschuldige meine Unwissenheit, muss ich einen Cluster für alwaysOn einrichten? – WML

+0

Entschuldigung, ich hätte konkreter sein sollen - Punkt 2 bezieht sich auf eine AlwaysOn-Verfügbarkeitsgruppe und diese erfordern, dass jeder Windows-Host Teil eines Windows Server-Failoverclusters ist. In diesem Szenario befinden sich die Server in # 1 und # 2 in einem WSFC und der Server # 3 ist eigenständig. Wie aktuell müssen Ihre Berichtsdaten sein? Möglicherweise können Sie stattdessen den Protokollversand verwenden, um eine Datenbank im STANDBY-Modus zu erstellen, die stattdessen für die Berichterstellung verwendet wird. – Nathan

+0

Berichtdaten können ein paar Minuten Verzögerung haben. Danke Kumpel – WML

Verwandte Themen