SQL Server - separate Datenbank für Berichte?

Auf unserem SQL Server verfügen wir über eine Datenbank für jede unserer Webanwendungen. Für Berichte verwenden wir Reporting Services und alle Berichtsdaten (einschließlich der Berichtsparameter) stammen aus gespeicherten Prozeduren.

Die gespeicherten Prozeduren befinden sich in derselben Datenbank wie die Daten im Bericht. So befinden sich beispielsweise die Prozesse, die die Bestandsberichte bedienen, in der Bestandsdatenbank. Einige Berichte zeigen Informationen aus mehr als einer Datenbank an, und dann befindet sich der Proc in einer dieser Quellendatenbanken. Die Berichtsparameter beziehen ihre Daten aus Prozessen in einer Unternehmensdatenbank, die Daten wie Geschäfte, Mitarbeiter usw. enthält.

Dies bedeutet, dass alle Berichte mindestens eine Verbindung zur Unternehmensdatenbank und eine weitere Verbindung zu einer anderen Datenbank haben - und manchmal auch mehr.

Meine Frage ist: Gibt es einen Vorteil beim Verschieben der Berichtsprozesse in eine separate Datenbank "Berichte" . Ich kenne die Vorteile des Verschiebens von Berichten auf einen anderen Server, und ich spreche nicht darüber - dies wäre auf demselben Server.

Mögliche Auswirkungen sind:

• Beeinflusst mehr als eine Datenbankverbindung für einen Bericht die Geschwindigkeit des Berichts?
• Würde es uns verbieten, den Berichtsprozess in einer von den Daten getrennten Datenbank zu haben, indizierte Ansichten zu verwenden?
• Haben Sie es einfacher / schwieriger gefunden, Ihre Berichte in einer separaten Datenbank zu verwalten?

Bitte sag mir was du denkst.

Die Antwort lautet: Ja, das hat einen Vorteil. Berichte zur Betriebsdatenbank beanspruchen viele Ressourcen und beeinträchtigen die Leistung des Betriebssystems. Denken Sie daran, dass die Datenbankleistung mechanischen Einschränkungen unterliegt (hin und her bewegte Plattenköpfe und Latenz bei der Drehung, während wir darauf warten, dass der richtige Sektor unter dem Kopf angezeigt wird). Sie haben zwei weitreichende Optionen für eine Berichtsstrategie:

1. Replizieren Sie Ihre Datenbank auf einen anderen Server und verschieben Sie die Berichtsprocs darauf. Berichte werden vom replizierten Server ausgeführt. Dies ist der geringste Aufwand und kann Ihre vorhandenen Berichte und gespeicherten Prozeduren wiederverwenden.
2. Erstellen Sie ein Data Warehouse , das die Daten aus Ihren Produktionssystemen konsolidiert und in umwandelt eine Form für die Berichterstellung wesentlich benutzerfreundlicher ist . Wenn Sie über eine Vielzahl von statistischen Ad-hoc-Berichten verfügen, die ausgehend von einem Schnappschuss ab dem gestrigen Geschäftsschluss akzeptabel sind, ist ein Data Warehouse möglicherweise der bessere Ansatz.

Ich denke, es hängt stark von der Art der SP ab, die Sie ausführen. Wenn sie schwer sind und sich auf andere Dinge auswirken könnten, die auf dem Datenbankserver ausgeführt werden, würde ich sie verschieben. Andernfalls würde ich versuchen, die Datenbank, über die sie tatsächlich berichten, in der Nähe zu halten, wenn dies einfacher zu pflegen und nachzuverfolgen wäre. Schon der Bericht in der Nähe der eigentlichen Datenbank kann die Leistung beeinträchtigen. Wenn Sie jedoch eine Standardkonfiguration verwenden und keine enorme Datenmenge verschieben, ist dies vermutlich ein winziger Unterschied.

Ich fand diesen Artikel auch nützlich.

Ich würde aus mehreren Gründen empfehlen, die gespeicherten Prozeduren nicht in eine andere Datenbank zu verschieben. Aus Sicht der Entwicklung müssen Sie jedes Mal, wenn Sie Änderungen vornehmen möchten, zwei Datenbanken reproduzieren. Als Konsequenz werden Sie nun erfahren, wie Sie das Schema aus der "Daten" -Datenbank und die gespeicherten Prozeduren aus der zweiten mit den Produktionsversionen synchronisieren. In Bezug auf Disaster Recovery und Backup / Restore müssen Sie sich jetzt mit der Wiederherstellung von 2 Datenbanken befassen, um Ihr System zum Laufen zu bringen.

Beim Testen haben Sie auch Komplexitäten hinzugefügt. Sie haben mehr Fehlerquellen in Bezug auf Berechtigungen, Versionen usw. Wenn Sie mehr als eine Person haben, die an verschiedenen Initiativen in den Datenbanken arbeitet, müssen Sie mehr Zeit für die Koordinierung aufwenden. Stellen Sie sich vor, es ist drei Uhr morgens, das System ist heruntergefahren und Sie müssen die Berechtigungen für alle Datenbanken durchsuchen und sicherstellen, dass während der Entwicklung niemand eine Funktion oder Prozedur in der falschen Datenbank belassen hat.

Ich würde empfehlen, dass Sie zwei Datenbanken verwenden.

Das Ableiten von Berichten aus einer "Live" -Datenbank führt zu Leistungsproblemen.

Da die Berichtsdatenbank hauptsächlich für Suchvorgänge vorgesehen ist, können Sie die Indizes hier anpassen, um die Leistung zu verbessern. (Die Live-Datenbank würde Einfügungen enthalten, die durch bestimmte Indizes beeinträchtigt würden.)

Ein weiterer Ansatz besteht darin, Berichtstabellen in ein separates Schema und eine separate Dateigruppe zu verschieben. Dateien in der Berichtsdateigruppe könnten von Datenfestplatten entfernt werden. Dies erleichtert die Administration, zukünftige Entwicklung und das Zugriffsmanagement erheblich.