Problem Definition

Unsere Benutzer müssen in der Lage sein, eine Datenbank abzufragen, die größtenteils auf dem neuesten Stand ist. Die Daten können bis zu 24 Stunden veraltet sein und das ist akzeptabel. Was wäre der kostengünstigste Ansatz, um eine zweite Datenbank mit einer Produktionskopie zu erhalten und auf dem neuesten Stand zu halten? Gibt es einen Ansatz, an den ich nicht denke?

Arbeitsbelastung

Wir haben eine Drittanbieteranwendung, mit der wir die Aktienhandelsaktivität überwachen. Während des Tages treten im Rahmen verschiedener Arbeitsabläufe viele kleine Änderungen auf (ja, dieser Handel war gültig. Nein, das ist verdächtig usw.). In der Nacht führen wir große setbasierte Operationen durch (laden Sie die Trades des Vortages).

Die aktuelle Lösung und das aktuelle Problem

Wir verwenden Datenbank-Snapshots . Um 22 Uhr legen wir ab und erstellen den Schnappschuss neu. Die ETL-Verarbeitung beginnt dann. Dies belastet natürlich unsere Festplatte, ermöglicht es unseren Benutzern jedoch, die Datenbank abzufragen, ohne die Datenbank zu sperren (sie verwenden ein Access-Front-End). Sie verwenden es bis spät in die Nacht und am frühen Morgen, damit sie Ausfallzeiten bemerken.

Das Problem bei diesem Ansatz ist zweifach. Die erste ist, dass im Falle, dass die nächtliche Verarbeitung fehlschlägt und dies nicht ungewöhnlich ist, wir die Datenbank wiederherstellen müssen, was dazu führt, dass der Snapshot gelöscht wird. Das andere Problem ist, dass unsere Bearbeitungszeiten über unsere SLA hinausgehen. Wir versuchen, dies zu beheben, indem wir mit dem Anbieter zusammenarbeiten, nachdem wir schlecht geschriebene Abfragen und fehlende Indizierung identifiziert haben. Der Datenbank-Schnappschuss ist auch ein Schuldiger an dieser Verlangsamung, wie der Geschwindigkeitsunterschied zeigt, wenn er vorhanden ist und nicht - schockierend, wie ich weiß.

Ansätze berücksichtigt

Clustering

Wir hatten das Datenbank-Clustering aktiviert, aber das entsprach nicht den Erfordernissen, die Daten verfügbar zu machen, und komplizierte im Allgemeinen das Leben des Administrators. Es wurde seitdem ausgeschaltet.

SQL Server-Replikation

Wir haben letzte Woche angefangen, uns die Replikation anzusehen. Unsere Theorie ist, dass wir einen zweiten Katalog erstellen und mit der Produktionsdatenbank synchronisieren können. Vor dem Beginn von ETL trennen wir die Verbindung und aktivieren sie erst wieder, wenn der ETL-Prozess abgeschlossen ist.

Der Administrator hat mit der Snapshot-Replikation begonnen , befürchtet jedoch, dass die Erstellung des Snapshots und des erforderlichen Festplattenverbrauchs mehrere Tage mit hoher CPU-Auslastung dauert. Er gibt an, dass anscheinend alle Daten in physische Dateien geschrieben werden, bevor sie an den Abonnenten gesendet werden, sodass die Speicherkosten für unsere .6TB-Datenbank 1,8TB betragen. Wenn die Erstellung eines Snaps mehrere Tage in Anspruch nimmt, passt er nicht in das gewünschte SLA.

Nach dem Lesen des Artikels scheint Snapshot der Weg zu sein, um die Abonnenten zu initialisieren, aber dann möchten wir zu Transactional Replication wechseln , um es danach synchron zu halten. Ich gehe davon aus, dass das Ein- und Ausschalten der Transaktionsreplikation keine vollständige Neuinitialisierung erzwingen wird. Ansonsten sprengen wir unser Zeitfenster

Datenbankspiegelung

Unsere Datenbank befindet sich im vollständigen Wiederherstellungsmodus, daher ist die Datenbankspiegelung eine Option, aber ich weiß noch weniger darüber als die Replikation. Ich habe die SO-Antwort gefunden , die angibt, dass "Datenbankspiegelung den direkten Zugriff auf Daten verhindert. Auf gespiegelte Daten kann nur über einen Datenbank-Snapshot zugegriffen werden."

Protokollversand

Es hört sich so an, als wäre der Holzversand auch eine Option, aber dies ist eine andere Sache, von der ich nichts weiß. Wäre es eine kostengünstigere Lösung (Implementierung und Wartung) als alles andere? Basierend auf Remus ' Kommentar "Der Protokollversand ermöglicht den schreibgeschützten Zugriff auf die Replikatkopie, trennt jedoch alle Benutzer, wenn das nächste empfangene Sicherungsprotokoll angewendet wird (z. B. alle 15 bis 30 Minuten)." Ich bin mir nicht sicher, wie lange diese Ausfallzeit dauern würde, so dass die Benutzer etwas Angst haben könnten.

MS Sync

Ich habe erst am vergangenen Wochenende von der Verwendung von Sync gehört und es noch nicht untersucht. Ich würde es hassen, eine neue Technologie für etwas mit hoher Sichtbarkeit wie dieses Problem einzuführen, aber wenn es der beste Ansatz ist, sollte es so sein.

SSIS

Wir machen hier viel SSIS, daher ist es für uns eine Option, ein paar hundert SSIS-Pakete zu generieren, um die sekundäre Synchronisierung aufrechtzuerhalten, wenn auch eine hässliche . Ich bin kein Fan davon, da dies viel Wartungsaufwand bedeutet, den mein Team lieber nicht in Kauf nimmt.

SAN "Magic" -Snapshot

In der Vergangenheit habe ich gehört, dass unsere Administratoren eine SAN-Technologie verwenden, um sofort Backups ganzer Festplatten zu erstellen. Vielleicht gibt es etwas EMC-Magie, die verwendet werden könnte, um schnelle Kopien der mdf / ldf zu erstellen, und wir können dann die Zieldatenbank trennen / anhängen.

Sichern und Wiederherstellen

Ich denke, wir machen einmal pro Woche vollständige Backups, nächtliche Differentiale und alle 15 Minuten Logs. Wenn die Benutzer mit dem 3-4-stündigen Ausfall für die vollständige Wiederherstellung zurechtkommen könnten, könnte dies ein Ansatz sein.

Einschränkungen

Windows 2008 R2, SQL Server 2008 R2 (Enterprise Edition), VMware v5 Enterprise Edition, EMC SAN-Speicher mit Laufwerken, die VMDK-Dateien zugeordnet sind, Commvault-Sicherungskopien und 0,6 TB Daten im Quellkatalog. Dies ist eine Drittanbieteranwendung, die wir intern hosten. Das Ändern ihrer Struktur wird im Allgemeinen verpönt. Die Benutzer können nicht auf die Abfrage der Datenbank verzichten und sich weigern, sich durch die proaktive Identifizierung der Tabellen, die sie überwachen, um ihre Arbeit zu erledigen, einschränken zu lassen.

Unsere DBAs sind derzeit reine Auftragnehmer. Die Vollzeitkräfte haben die Segel gesetzt und wir haben sie noch nicht ersetzt. Die Anwendungsadministratoren sind mit SQL Server-Angelegenheiten nicht vertraut, und wir verfügen über ein Team von Storage / VM-Administratoren, die diese Bemühungen unterstützen bzw. behindern können. Entwicklungsteams sind derzeit nicht beteiligt, können jedoch je nach Ansatz hinzugezogen werden. Daher wäre eine einfacher zu implementierende und zu wartende Lösung vorzuziehen.

Ich bin auf der Entwicklungsseite des Hauses, also kann ich nur Ansätze vorschlagen und musste mich nicht mit der Verwaltungsseite befassen. Da ich keine Zeit im Admin-Sattel habe, zögere ich zu sagen, dass ein Ansatz dem anderen überlegen wäre - den Zeitungen zufolge sieht alles großartig aus. Ich bin voll und ganz bereit, jede Richtung einzuschlagen, die ich vorschlage, denn aus meiner Sicht wird es mich als DB-Profi nur noch wertvoller machen. Ich habe eine Schubkarre, aber keinen Holocaust-Umhang .

Verwandte Fragen

• /programming/525637/what-are-the-scenarios-for-using-mirroring-log-shipping-replication-and-cluste

• /programming/434982/mirroring-vs-replication

• /programming/4303020/sync-databases-mirroring-replication-log-shipping

• /programming/4303020/sync-databases-mirroring-replication-log-shipping

• http://nilebride.wordpress.com/2011/07/24/log-shipping-vs-mirroring-vs-replication/

Bearbeitungen

Um @ onpnts Fragen zu beantworten

Datenlatenzannahme

Die Benutzer sehen derzeit Daten, die bis zu 24 Stunden zurückliegen. Die Daten sind erst ab 2200 aktuell

Datenänderungsmenge in einer bestimmten Minute, Stunde und einem bestimmten Tag. Geschäftszeiten, vielleicht Hunderte von Änderungen pro Stunde. Nächtliche Verarbeitung, Millionen Zeilen pro Arbeitstag

Konnektivität zum sekundären

Internes Netzwerk, separater virtueller Host und dedizierter Speicher

Lesen Sie die Anforderungen für die sekundäre Instanz

Die Windows-Gruppe hat Lesezugriff auf die sekundären Tabellen

Betriebszeit der sekundären Instanz

Es gibt keine genaue Definition einer Verfügbarkeitsanforderung. Benutzer möchten, dass es immer verfügbar ist, sind aber bereit, dafür zu zahlen, wahrscheinlich nicht so viel. Realistisch würde ich sagen, dass 23 Stunden pro Tag ausreichen würden.

Änderungen am vorhandenen Schema und allen Objekten

Seltene Änderungen, möglicherweise einmal pro Quartal für Tabellenobjekte. Möglicherweise einmal im Monat für Codeobjekte.

Sicherheit

Keine besonderen Sicherheitsbedürfnisse. Die Produktionsberechtigungen stimmen mit den Berechtigungen der Kopie überein. Obwohl ich darüber nachdenke, könnten wir den Benutzern den Lesezugriff auf prod entziehen und ihnen nur erlauben, die Kopie zu lesen ... Dies ist jedoch keine Voraussetzung.

@ Darin Straße

Es könnte eine Option sein, auf den Schnappschuss zurückzugreifen, aber ich glaube, es gab einen Grund, warum sie ihn nicht weiterverfolgt haben. Ich werde mit dem Administrator überprüfen

@cfradenburg

Meine Annahme war, dass wir nur einen dieser Ansätze verwenden würden, aber das ist ein guter Punkt, bei dem Wiederherstellungen die "anderen" Synchronisierungstechnologien zum Erliegen bringen würden. Sie untersuchen die Verwendung der EMC-Snapshot-Magie. Wie der Administrator es beschrieb, machten sie um 1900 einen Schnappschuss und migrierten das Image in die Zone des sekundären Servers. Das sollte bis 2200 abgeschlossen sein, und dann würden sie eine Trennung und erneute Verknüpfung der sekundären Datenbank durchführen.

Einpacken

2012-10-29 Wir haben EMC Snapshot Magic und einige andere Replikationsoptionen evaluiert, aber die Datenbankadministratoren haben entschieden, dass sie das Spiegeln am besten herausfinden können. Die Antworten wurden positiv bewertet, weil sie mir alle geholfen haben und mir viele Optionen sowie "Hausaufgaben" zur Untersuchung gaben.

Das Ändern ihrer Struktur wird im Allgemeinen verpönt

Replikation ist mehr als wahrscheinlich und ich würde Sync davor rauswerfen. (aus realen High-Transacitonal-Tests mit Sync Framework)

Wenn Ihre Datenlatenz 3-4 Stunden beträgt, ist der Protokollversand wahrscheinlich die beste Wahl für eine schreibgeschützte Kopie. Aber wie viel ändert sich im Protokoll? Stellen Sie fest, dass Sie es überwachen müssen, um zu sehen, wie schnell und wie viel Sie übertragen müssen.

Wenn Sie nicht zu Mirroring wechseln oder ein Upgrade auf 2012 Enterprise durchführen können, ist dies nicht möglich, obwohl dies eine gute Strategie wäre, wenn Sie nicht zu Enterprise wechseln können.

SSIS soll nicht nur Daten sichern, sondern kann dies auch. Bei der Suche nach Transformationen wird jedoch viel zu viel Wert darauf gelegt, und die Aufgabe wäre zeit- und ressourcenintensiv. Obwohl, wie ich schon sagte, es das kann.

Wirklich, es wird eine deutliche Einschränkung der Auswahl geben, die auf der Beantwortung einiger Fragen basiert

• Datenlatenzannahme
• Datenmenge ändert sich in einer bestimmten Minute, Stunde und am Tag. Konnektivität zur sekundären
• Lesen Sie die Anforderungen für die sekundäre Instanz
• Betriebszeit der sekundären Instanz
• Änderungen am vorhandenen Schema und allen Objekten
• Sicherheit

Dies wird eines der Dinge sein, die Sie selbst ausprobieren müssen, um herauszufinden, was am besten funktioniert. Die Replikation kann knifflig sein, so dass ein administrativer Aufwand für die Verwaltung der Replikation entsteht, obwohl keine direkten Kosten anfallen.

Um den Protokollversand zu erweitern, müssen Sie die Protokolle nicht alle 15 bis 30 Minuten wiederherstellen. Wenn Sie möchten, können Sie dies alle vier Stunden oder einmal am Tag tun. Eine ähnliche Lösung, die ich implementiert habe, ist das wöchentliche vollständige Sichern und Wiederherstellen in einer Berichtsdatenbank (was eine Weile dauern kann und am Wochenende vorkommt). Während der Woche werden differenzielle Backups erstellt und diese werden jede Nacht in der Berichtsdatenbank wiederhergestellt. Benutzer müssen vor der Wiederherstellung gebootet werden, aber da es sich bei der Berichtsdatenbank um eine Geschäftszeitanwendung handelt, ist dies kein Problem. Daten sind einen Tag alt, was aufgrund Ihrer Anforderungen kein Problem sein sollte.

Um die Datenbankspiegelung zu verwenden, müssen Sie Enterprise erwerben, um Snapshots verwenden zu können, wenn Sie Enterprise noch nicht ausführen. Außerdem werden die Daten nicht zu 100% auf dem neuesten Stand gehalten, da der Snapshot gelöscht (dh alle Benutzer müssen abwesend sein) und anschließend neu erstellt werden muss, um die neuen Daten abzurufen. Dies wäre jedoch kürzer als die Protokollwiederherstellung oder die oben erläuterte Methode.

Wenn ein Upgrade auf SQL 2012 möglich ist, können Sie eine schreibgeschützte sekundäre Datenbank einrichten, die mit der primären Datenbank auf dem neuesten Stand gehalten wird. Ich erwähne dies nur, weil es wahrscheinlich die reibungsloseste Lösung ist.

So sehr die Leute bei der Transaktionsreplikation zerlumpen, es klingt nach einer guten Anpassung an Ihre Situation. Ein paar Notizen:

1. Sie müssen den Abonnenten nicht mit einem Snapshot initialisieren. Sie können eine Sicherungskopie des Herausgebers erstellen und damit initialisieren.
2. Sie können die Übermittlung von Befehlen an den Abonnenten anhalten, indem Sie den Verteilungsjob beenden (dies ist nur ein normaler SQL Agent-Job entweder beim Verteiler oder beim Abonnenten, je nachdem, ob Sie ihn als Push- oder Pull-Abonnement eingerichtet haben). Denken Sie nur daran, wie lange Sie beim Händler bleiben, damit Sie genügend Daten haben, die Sie nachholen können.
3. Sie können die Indizierung auf dem Abonnenten ändern, um den dort ausgeführten Workloads Rechnung zu tragen (vermutlich vom Berichtstyp), anstatt die Indizierung von Ihrem Herausgeber (vermutlich vom OLTP-Typ) akzeptieren zu müssen, wenn Sie möchten.