Wie stelle ich sicher SQL Server-Replikation ausgeführt wird?

Question

Ich habe zwei SQL Server 2005-Instanzen, die geographisch voneinander getrennt sind. Wichtige Datenbanken von der primären zu dem sekundären Verwendung von Transaktionsreplikation repliziert werden.

Ich bin auf der Suche nach einem Weg, dass ich diese Replikation überwachen und sofort benachrichtigt werden, wenn es fehlschlägt.

Wir haben in der Vergangenheit wiederholt hatte, wo die Netzwerkverbindung zwischen den beiden Fällen hat sich für einen bestimmten Zeitraum zurückgegangen. Da die Replikation nicht auftreten konnte und wir wussten nicht, blies das Transaktionsprotokoll aus und füllte die Platte als auch einen Ausfall in der primären Datenbank zu verursachen.

Ihr Google-Suche vor einiger Zeit führte uns die MSrepl_errors Tabelle Überwachung und Alarmierung, wenn es irgendwelche Einträge waren aber einfach nicht funktioniert. Das letzte Mal, Replikation fehlgeschlagen (gestern Abend daher die Frage), Fehler trafen nur die Tabelle, wenn es neu gestartet wurde.

Hat jemand Monitor-Replikation und wie Sie es tun?

---

Nur ein wenig mehr Informationen:

Es scheint, dass das Problem gestern Abend war, dass der Protokolllese-Agent starb und begann nicht wieder auf. Ich glaube, dass dieses Mittel zum Lesen des Transaktionsprotokolls verantwortlich ist und Aufzeichnungen in der Verteilungsdatenbank setzen, damit sie auf dem sekundären Standort repliziert werden.

Da diese Mittel innerhalb von SQL Server ausgeführt wird, können wir nicht einfach sicherstellen, dass ein process in Windows ausgeführt wird.

Answer 1

Wir haben E-Mails an uns für die Mergereplikation Ausfälle gesendet. Ich habe nicht die Transaktionsreplikation verwendet, aber ich denke, Sie ähnliche Benachrichtigungen einrichten.

Der einfachste Weg ist es durch Replication Monitor einzurichten.

Gehen Sie

zu Replication Monitor und wählen Sie eine bestimmte Publikation. Dann wählen Sie die Warnungen und Agents Registerkarte und konfigurieren Sie die besondere Warnung, die Sie verwenden möchten. In unserem Fall ist es Replikation: Agent-Failure

.

Für diese Warnung haben wir die Antwort richten Sie einen Job auszuführen, die eine E-Mail sendet. Der Job kann auch einige Arbeit umfassen Details, was ausgefallen, usw.

Das funktioniert gut genug für uns, um das Problem alarmieren, so dass wir es sofort beheben.

Answer 2

Sie können eine regelmäßige Überprüfung führen, dass Datenänderungen stattfinden, obwohl dies sehr komplex sein könnte je nach Anwendung.

Wenn Sie haben irgendeine Form von Audit-Bahn-Tabelle, die sehr regelmäßig aktualisiert wird (dh unser Hauptprodukt hat eine Basis Audit-Tabelle, die Listen alle Aktionen, die in Daten führen aktualisiert oder gelöscht werden), dann könnten Sie Abfrage, die Tabelle auf beiden Servern und stellen Sie sicher, dass das Ergebnis, das Sie wieder das gleiche ist. So etwas wie:

SELECT CHECKSUM_AGG(*) 
FROM   audit_base 
WHERE  action_timestamp BETWEEN <time1> AND BETWEEN <time2> 

wo und sind rund Werte für verschiedene Verzögerungen zu ermöglichen, die Datenbanken in Kontakt gebracht wird. Zum Beispiel, wenn Sie zehn Minuten nach der vollen Stunde werden Überprüfung könnten Sie Elemente überprüfen aus der die letzten Stunde zu Beginn dieser Stunde beginnen. Sie haben nun zwei kleine Werte, die Sie irgendwo übertragen und vergleichen. Wenn sie unterschiedlich sind dann in dem Replikationsprozess etwas hat höchstwahrscheinlich schief gegangen -., Was jemals pocess hat die Überprüfung / Vergleich Ihnen eine E-Mail und eine SMS senden, damit Sie wissen, jedes Problem zu überprüfen und zu beheben, die Aufmerksamkeit braucht

Mit dem SELECT CHECKSUM_AGG mit (*), um die Datenmenge für jede Tabelle ist sehr, sehr klein, so dass die Nutzung der Bandbreite der Kontrollen unbedeutend sein wird. Sie müssen nur sicherstellen, dass Ihre Schecks in der Last nicht zu teuer sind, die auf den Server anwenden, und dass Sie keine Daten überprüfen, die so einen Teil der offenen Replikation Transaktionen könnte möglicherweise in diesem Moment, anders zu sein erwartet werden (daher die Überprüfung die Audit-trail von nun ein paar Minuten zurück in der Zeit, statt in meinem Beispiel) sonst werden Sie zu viele Fehlalarme bekommen.

auf Ihrer Datenbankstruktur Je die oben könnte unpraktisch. Bei Tabellen, die nicht einfügen geschützt sind (keine Aktualisierungen oder Löschungen) innerhalb des Zeitrahmens des Schecks (wie eine Audit-Trail wie oben), ausarbeitet, was sicher verglichen werden kann bei gleichzeitiger Vermeidung von Fehlalarmen komplex und teuer ist, wenn sein wahrscheinlich nicht eigentlich unmöglich zuverlässig zu tun.

Sie könnten einen Rolleinsatz nur Tabelle herstellen, wenn Sie nicht bereits eines haben, durch einen kleinen Tisch mit (enthält nur eine indexierte Spalte Timestamp), an die Sie regelmäßig eine Zeile hinzufügen - diese Daten dient keinem anderen Zweck als zu existieren so können Sie Aktualisierungen der Tabelle überprüfen repliziert zu werden. Sie können Daten, die älter als Ihr Giro Fenster löschen, so dass die Tabelle soll nicht groß werden. Nur die Prüfung eine Tabelle beweist nicht, dass alle anderen Tabellen replizieren (oder alle andere Tische für diese Angelegenheit), aber einen Fehler in diesem einem Tisch zu finden, wäre ein guter „canery“ Scheck (wenn dies Tabelle wird nicht in der Replik zu aktualisieren, dann die andere sind wahrscheinlich auch nicht).

Diese Art der Kontrolle hat den Vorteil des Replikationsprozesses unabhängig zu sein -. Sie warten nicht auf die Replikationsprozess Ausnahmen in Protokollen aufgezeichnet zu werden Sie stattdessen proaktiv einige der aktuellen Daten testen