Was ist der beste Weg, um die Datenbank für SSRS zu replizieren?

Sie benötigen Transaktionsreplikation für Ihren Fall. Hier ist, warum Sie die anderen 4 Fälle nicht benötigen würden:

Spiegelung

• Dies wird im Allgemeinen verwendet, um die Verfügbarkeit eines Datenbankservers zu erhöhen, und bietet im Falle einer Katastrophe einen automatischen Failover.
• Normalerweise haben Sie zwar mehr als eine einzige Kopie der Datenbank (es wird empfohlen, sich auf verschiedenen Serverinstanzen zu befinden), jedoch ist jeweils nur einer aktiv, der als Hauptserver bezeichnet wird.
• Jede Operation auf dieser Serverinstanz wird kontinuierlich (so bald wie möglich) auf die anderen gespiegelt. Dies passt also nicht zu Ihrem Anwendungsfall.

Protokollversand

• In diesem Fall verfügen Sie, abgesehen von den Produktionsdatenbankservern, über zusätzliche Failoverserver, so dass die Sicherung der Datenbank des Produktionsservers, differential & amp; Transaktionsprotokolle werden automatisch an die Failovers gesendet (kopiert) und wiederhergestellt.
• Die Replikation ist hier relativ zu einem längeren Zeitintervall als die anderen Mechanismen geplant, typischerweise von einer Stunde bis zu einigen Stunden.
• Dies sieht auch vor, dass die Failover-Server im Falle einer Katastrophe an den Produktionsstandorten manuell vorbereitet werden.
• Dies passt auch nicht zu Ihrem Anwendungsfall.

Zusammenführungsreplikation

• Der Hauptunterschied zwischen diesen und den anderen besteht darin, dass die replizierten Datenbankinstanzen mit den verschiedenen Clientanwendungen kommunizieren können, unabhängig von den Änderungen, die an den anderen vorgenommen werden.
• Zum Beispiel wird ein Datenbankserver in Nordamerika von Kunden in ganz Amerika & amp; Europa und ein weiterer in Australien werden von Kunden in der asiatisch-pazifischen Region aktualisiert, und dann werden die Änderungen miteinander verschmolzen.
• Auch dies passt nicht zu Ihrem Anwendungsfall.

Snapshot-Replikation

• Der gesamte Snapshot der Datenbank wird veröffentlicht, um in die sekundäre Datenbank repliziert zu werden (anders als nur die Protokolldateien, die zur Replizierung gesendet werden.)
• Zu Beginn wird jedoch für jeden Replikationstyp ein Snapshot erzeugt, um die abonnierende Datenbank zu initialisieren, d. h. nur einmal.

Warum sollten Sie Transaktionsreplikation verwenden?

• Sie können die Objekte (Tabellen, Ansichten usw.) auswählen, die repliziert werden sollen kontinuierlich . Wenn also nur eine Teilmenge der Tabellen für die Berichterstellung verwendet wird, würde viel Bandbreite gespart . Dies ist in Spiegelung und Protokollversand nicht möglich.
• Sie können den Datenverkehr von Ihrer Anwendung an den Berichtsserver für alle Lesevorgänge und Berichte umleiten (was Sie auch in anderen tun können, btw).
• Sie können unabhängige Stapeljobs erstellen, die einige der häufiger verwendeten Berichte auf dem Berichtsserver generieren, wodurch die Belastung des Hauptservers verringert wird, wenn es recht häufig zu Einfügungen, Aktualisierungen oder Löschvorgängen kommt.

Gehen Sie Ihre Liste von oben nach unten durch.

1. Spiegelung : Wenn Sie Ihre Daten von Ihrem mainServer auf Ihren reportServer spiegeln, können Sie nicht auf Ihren reportServer zugreifen. Die Spiegelung versetzt die gespiegelte Datenbank in einen kontinuierlichen Wiederherstellungszustand . Spiegelung ist eine Hochverfügbarkeitslösung. In Ihrem Fall steht der reportServer nur zur Verfügung, wenn Sie einen Failover durchführen möchten. Der gespiegelte Server ist niemals betriebsbereit bis zum Failover. Dies ist nicht das, was Sie wollen, da Sie den reportServer nicht verwenden können, bis er betriebsbereit ist.

2. Protokollversand : Mit dem Protokollversand können Sie Transaktionsprotokollsicherungen für ein geplantes Ereignis auf den reportServer anwenden. Wenn Sie das Transaktionslog alle 15 Minuten sichern und die Daten auf den reportServer anwenden, haben Sie eine Verzögerung von mehr als 15 Minuten zwischen Ihrem mainServer und dem Log-Server. Die Spiegelung ist eigentlich der Echtzeit-Protokollversand. Je nachdem, wie Sie den Protokollversand eingerichtet haben, muss der Client die Verbindung trennen, während die Datenbank die Protokolldateien wiederherstellt. Während einer langen Wiederherstellung kann es daher unmöglich sein, Berichte zu verwenden. Der Protokollversand ist ebenfalls eine Funktion für hohe Verfügbarkeit und nicht wirklich nützlich für die Berichterstellung. In diesem Link finden Sie eine Beschreibung zum Versuch, auf eine Datenbank zuzugreifen, während sie versucht, Ссылка

3. Replikation : Ich stemple die Replikation hier zusammen. Durch die Replikation, insbesondere die Transaktionsreplikation, können Sie Ihre Berichtsanforderungen ausweiten. Es wäre in der Regel viel einfacher zu implementieren und auch Sie in der Lage, auf die Daten die ganze Zeit zu berichten, wo in Spiegelung Sie nicht über die Daten im Transaktionsprotokollversand berichten können Sie Lücken haben. In Ihrem Fall ist die Replikation also viel sinnvoller. Die Snapshot-Replikation wäre nützlich, wenn Ihre Berichte einen Tag alt sein könnten. Sie können jeden Morgen einen Snapshot der Daten erstellen, die Sie von mainServer benötigen, und diese Daten an den Abonnenten reportServer veröffentlichen. Wenn die Datenbank jedoch extrem groß ist, wird Snapshot täglich problematisch sein. Die Mergereplikation ist nur dann nützlich, wenn Sie die replizierten Daten aktualisieren möchten. In Ihrem Fall möchten Sie eine schreibgeschützte Kopie der zu reportierenden Daten haben, damit die Mergereplikation nicht hilft. Mit der Transaktionsreplikation können Sie Replikationen über die Leitung senden. In Ihrem Fall, in dem Sie häufig aktualisierte Informationen in Ihrem Berichtsserver benötigen, wäre dies äußerst nützlich. Ich würde diese Route wahrscheinlich für Sie vorschlagen.

Denken Sie daran, dass Sie durch die Implementierung des Replikations- / Spiegelungs- / Protokollversands mehr Wartungsarbeit leisten. Die Replikation kann fehlschlagen. So kann Spiegelung und so kann Transaktionsprotokollversand werden. Sie müssen diese Lösungen überwachen, um sicherzustellen, dass sie reibungslos funktionieren. Die Frage ist also, ob Sie Ihre Berichte wirklich auf einen anderen Server skalieren müssen oder ob Sie Zeit brauchen, um herauszufinden, warum Sie keinen Bericht auf dem Produktionsserver erstellen können.

Hoffe das hilft!