best practice

Question

Hallo,

wir möchten unsere transaktionale Datenbank für die Erstellung von Berichten entkoppeln und die notwendigen Daten in einer zweiten Datenbank speichern. Es besteht die Anforderung, dass die Daten innerhalb einer Minute in der zweiten Datenbank vorhanden sind.

Was ist hierfür die bestmögliche Technologie, beim Einsatz von SQL Server 2008 Enterprise?

Danke

Answer 1

Hi,

wir möchten unsere transaktionale Datenbank für die Erstellung von Berichten entkoppeln und die notwendigen Daten in einer zweiten Datenbank speichern. Es besteht die Anforderung, dass die Daten innerhalb einer Minute in der zweiten Datenbank vorhanden sind.

welche Daten sollen wie in die andere Datenbank gepackt werden?

Stimmt das Schema der zu übertragenden Tabellen in etwa überein oder sollen diese schon "umgebaut" werden?

Wenn es eine (fast) 1:1 Kopie werden soll, könntet ihr das über Trigger in der Quelldatenbank lösen. Allerdings ist das bei sehr vielen Transaktionen natürlich auch ein wenig performancelastig.

Alternativ könnte man auch aus der Zieldatenbank heraus alle xx Sekunden einen Job starten, der die neuen bzw. geänderten Daten aus der Quelldatenbank abholt. Da gibt es dann aber die Problematik, dass gelöschte DS nicht erkannt werden, was bei Triggern in der Quelle problemlos zu lösen ist.

...

Du siehst, es wäre wichtig, dass Du ein wenig mehr ins Detail gehst und schreibst, was ihr wie erreichen wollt.

 

---

Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

Answer 2

die Struktur in der zweiten Datenbank ist identisch.

welche Daten? Zahlen, Texte (auch mit varchar(max))

Unsere Gedanken sind in Richtung CDC oder Replikation gegangen -liegen wir da falsch?

Answer 3

hi Michi,

Prinzipiell wäre das dann wohl Log Shipping:

http://msdn.microsoft.com/en-us/library/ms190016%28v=SQL.90%29.aspx

---

Microsoft MVP Office Access
https://mvp.support.microsoft.com/profile/Stefan.Hoffmann

Answer 4

warum nicht CDC? Ist doch für Datenänderungen in Richtung DWH-DB bestimmt, oder?

Answer 5

hi Michi,

Nö, sowie ich es verstehe, eigentlich nicht. Es dient lediglich dazu Veränderungen an den Daten zu erkennen und Aufzuzeichnen, bzw. darauf zu reagieren.

Im ersten Abschnitt von Log Shipping steht genau das was du willst:

"reallocate query processing from the primary server to one or more read-only secondary servers"

Komplett erklärt in

http://msdn.microsoft.com/en-us/library/ms189572.aspx

Natürlich gibt es nicht nur das. Aber es ist imho die "natürlichste" Variante.

DWH hat ja erst mal nichts mit Reporting zu tun, das wäre hier ja Analysis Services im Gegensatz zum Reporting Services:

http://msdn.microsoft.com/en-us/library/ff772732%28SQL.100%29.aspx

---

Microsoft MVP Office Access
https://mvp.support.microsoft.com/profile/Stefan.Hoffmann

Answer 6

Hallo Michi,
ich finde die Anforderung bedenkenswert: Reporting auf der (fast) live Datenbank, wahrscheinlich damit die Performance dort nicht leidet, möglichst ohne Einfluss auf die Performance.
- Die Lösung mit dem Job auf dem Zielsystem gefällt mir sehr gut, aber Du hast immer den Overhead, auch wenn nur wenige Berichte gezogen werden. Löschungen dürfen nur logisch vollzogen werden und müssen in der Software entsprechend abgehandelt werden.
- Falls Du einen Zeitunterschied von vielleicht 15 Minuten akzeptieren könntest und die Zieldatenbank nicht permanent mit Abfragen belagert ist, könntest Du dies über LogShipping realisieren. Dann hast Du aber auch auf beiden Systemen die identische Struktur. Zusätzliche Indizes für Reporting könnten dann nur ebenfalls auf dem Quellsystem angelegt werden.
- Dann gibt es noch die Replikation, welche auch Daten in zwei Datenbanken auf einem Stand halten kann. Das wäre vielleicht für Euch noch die beste Alternative.

Soll das Zielsystem denn eine eigene Hardware und damit auch Lizenz bekommen?

Falls Du nur die Last auf dem Quellsystem in den Griff bekommen willst, kannst Du es auch über den Resource Governor versuchen:
http://www.sql-server-performance.com/articles/per/Resource_Governor_in_SQL_Server_2008_p1.aspx
Falls es zu Engpässen kommt, regelt der die Ressourcen-Verteilung nach Deinen Vorstellungen.

Ansonsten beschreibe doch mal, warum ihr die Systeme trennen wollt.

Einen schönen Tag noch,
Christoph

---

Microsoft SQL Server MVP
http://www.insidesql.org/blogs/cmu

Answer 7

Wir wollen die System trennen, um eine Reporting-Schichten zu generieren. In weiterer Zukunft kann es mehrere Systeme geben und die Daten sollten alle auf eine Reporting-Schicht zusammen gefasst werden. Die Reporting-Schicht soll dann auch schon Aggregationen enthalten und Grundlage für ggf. Analyse Services sein. Primär geht es jetzt erst mal die bestmögliche Technologie zum Transferieren der Daten - insbesondere die zeitnahe Bereitstellung der Veränderungen der transaktionallen Daten zu evaluieren.

Die Zielsysteme werden alle eigene Hardware und jeweils Enterprise-Lizenzen besitzen.

Answer 8

Hallo,

dafür eignen sich am besten die Integration Services

Dort kannst Du Dinge wie Transformationen und Aggregationen
auf (relativ) einfache Weise implementieren.

Ihr solltet jedoch zunächst ein eigenständiges Konzept aufstellen.
Eine 1 : 1 Übertragung ist in den meisten Fällen nicht sinnvoll.

Gruß Elmar