Anforderungsübersicht für die Erfassung und Bereitstellung von Datenbanken in einer Always On-Verfügbarkeitsgruppe

Oracle GoldenGate for SQL Server unterstützt die Erfassung von einem primären Replikat oder einem schreibgeschützten, synchronen Modus-Nebenreplikat einer Always On-Verfügbarkeitsgruppe und die Bereitstellung an das primäre Replikat.

Bei der Erfassung von Primär- oder Sekundärreplikaten in einer Always On-Verfügbarkeitsgruppe ist es wichtig zu verstehen, dass der Capture-Prozess nur gehärtete Transaktionen aus dem Log lesen darf und dass zwischen Replikatdatenbanken, aus denen Oracle GoldenGate erfasst wird oder aus denen es keinen Datenverlust geben wird, kein Risiko besteht.

Datenbankverbindung

Sowohl für Extract als auch für Replicat wird empfohlen, eine Datenbankverbindung zu erstellen, die den Listener der Always On-Verfügbarkeitsgruppe für die Verbindung verwendet.

Wenn das Replicat eine Verbindung zum Listener herstellt, kann das Replicat erneut eine Verbindung herstellen, wenn das primäre Replikat ein Failover auf eine neue Instanz ausführt, ohne die Verbindungseinstellungen manuell bearbeiten zu müssen, um auf die neue primäre Instanz zu verweisen.
Bei der Extract-Verbindung mit dem Listener können Sie nicht nur eine erneute Verbindung zur Primärinstanz herstellen, ohne die Verbindung so zu bearbeiten, dass sie auf die neue Instanz verweist. Sie können auch optional die gespeicherten Prozeduren für die Extraktion von Daten für eine schreibgeschützte Sekundärinstanz ausführen.
Verwenden Sie für Extract und Replicat, die mit einer Always On-Umgebung verbunden sind, den Parameter AUTORESTART für den Manager, um die Prozesse nach einem Failover neu zu starten.
Um die Datenextraktionsabfragen des Extract an eine schreibgeschützte Sekundärdatenbank weiterzuleiten, stellen Sie sicher, dass die Verbindung den Listener verwendet, dass Sie über mindestens ein schreibgeschütztes sekundäres Replikat verfügen, das für das schreibgeschützte Routing konfiguriert ist, und dass der Extract mit dem Parameter TRANLOGOPTIONS ALWAYSONREADONLYROUTING ausgeführt wird.

In der folgenden Microsoft-Dokumentation wird beschrieben, wie schreibgeschütztes Routing konfiguriert wird: https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/configure-read-only-routing-for-an-availability-group-sql-server?view=sql-server-2017

Zusätzliches Logging

Zusätzliches Logging muss auf normale Weise (ADD TRANDATA) mit dem Admin-Client oder der mit dem primären Replikat verbundenen Weboberfläche und nicht mit einem sekundären Replikat aktiviert werden.

Erstellen Sie einen DSN zum primären Replikat oder zum Listener der Always On-Verfügbarkeitsgruppe, um eine Verbindung mit DBLOGIN herzustellen und ADD TRANDATA auszuführen.
Wenn Sie zusätzliches Logging für die Primärreplikatdatenbank aktivieren, wird der SQL Server Change Data Capture-Job nicht automatisch für sekundäre Replikate erstellt. Beim Failover von einer primären zu einer sekundären Instanz müssen Sie den SQL Server Change Data Capture-Job und gegebenenfalls den Oracle CDC Cleanup-Job auf dem neuen primären Replikat manuell erstellen.

EXECUTE sys.sp_cdc_add_job N'capture
- Beim Erstellen des SQL Server CDC Capture-Jobs in der neuen Primärdatenbank werden die Standardkonfigurationseinstellungen eingerichtet. Wenn Sie also zuvor die Standardwerte für das frühere primäre Replikat geändert haben, müssen Sie sys.sp_cdc_change_job für das neue primäre Replikat ausführen und die Werte entsprechend festlegen. Hinweis: Weitere Informationen zum Aktivieren des CDC Capture-Jobs für sekundäre AlwaysOn-Replikate finden Sie in der Microsoft-Dokumentation.

Betriebsanforderungen und Überlegungen

Wenn eine Instanz nicht mehr die primäre Instanz ist, aber der SQL Server CDC Capture-Job installiert ist, wird der Job nach einiger Zeit nicht mehr ausgeführt und versucht nicht, ihn neu zu starten. Beim Failover auf diese Instanz wird der Job nicht automatisch gestartet. Daher muss er manuell gestartet werden.
Wenn sekundäre Replikatdatenbanken nicht mit der primären Replikatdatenbank synchronisiert sind, wird der CDC-Capture-Job nicht im Log weitergeleitet. Daher werden keine Datensätze von einem Extract erfasst, bis die primären und sekundären Replikate synchronisiert werden. In diesem Artikel von Microsoft finden Sie weitere Details:

https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/replicate-track-change-data-capture-always-on-availability?view=sql-server-2017

Hinweis: Beim Erfassen von Primär- oder Sekundärreplikaten in einer Always On-Verfügbarkeitsgruppe ist es wichtig zu verstehen, dass der Capture-Prozess nur gehärtete Transaktionen aus dem Log lesen darf und dass zwischen Replikatdatenbanken, aus denen Oracle GoldenGate erfasst wird oder aus denen es keinen Datenverlust geben wird, kein Datenverlust besteht.
Wenn Sie einen Extract von einem Middle Tier-Windows- oder Linux-Server ausführen, legen Sie das Datum, die Uhrzeit und die Zeitzone des Middle Tier-Servers auf dasselbe wie das primäre Replikat fest.
Wenn Extract für die Erfassung aus einem lesbaren sekundären Replikat konfiguriert ist, jedoch nicht mit schreibgeschütztem Routing konfiguriert ist, muss der SQL Server CDC Capture-Job für das sekundäre Replikat erstellt werden, bevor Extract gestartet wird, da der Extract prüft, ob der Job vorhanden ist. Um den SQL Server CDC Capture-Job zu erstellen, müssen alle potenziellen sekundären Elemente, bei denen ein Extract angemeldet ist, irgendwann auf eine beschreibbare primäre Datenbank gesetzt werden. Führen Sie dann die oben genannten Schritte unter zusätzlicher Protokollierung aus, um den SQL Server CDC Capture-Job manuell hinzuzufügen.
Wenn Sie Oracle GoldenGate deinstallieren und Change Data Capture in einer Datenbank deaktivieren, die Teil einer Always On-Verfügbarkeitsgruppe ist, führen Sie die zusätzlichen Schritte unter Change Data Capture deaktivieren aus.