Hinweise zur Replikation¶

Datenbank- und Freigabeobjekte¶

Die folgenden Einschränkungen gelten für Datenbank- und Freigabeobjekte:

• Ein Objekt kann nur in genau einer Failover-Gruppe enthalten sein.

• Ein Objekt kann in mehreren Replikationsgruppen enthalten sein, solange jede Gruppe in ein anderes Zielkonto repliziert wird.

• Ein Objekt kann nicht sowohl in einer Failover-Gruppe als auch in einer Replikationsgruppe enthalten sein.

• Sekundäre (Replikat-)Objekte können nicht zu einer primären Replikations- oder Failover-Gruppe hinzugefügt werden.

Sie können nur ausgehende Freigaben replizieren. Die Replikation von eingehenden Freigaben (Freigaben von Anbietern) wird nicht unterstützt.

Kontoobjekte¶

Ein Konto kann nur genau eine Replikations- oder Failover-Gruppe haben, die neben Datenbanken und Freigaben auch andere Kontoobjekte enthält.

Verwaiste Referenzen und Netzwerkrichtlinien¶

Verwaiste Referenzen in Netzwerkrichtlinien können dazu führen, dass die Replikation mit der folgenden Fehlermeldung fehlschlägt:

Dangling references in the snapshot. Correct the errors before refreshing again.
The following references are missing (referred entity <- [referring entities])

Um verwaiste Referenzen zu vermeiden, geben Sie beim Ausführen des CREATE- oder ALTER-Befehls für die Replikations- oder Failover-Gruppe die folgenden Objekttypen in der Liste OBJECT_TYPES an:

• Wenn eine Netzwerkrichtlinie eine Netzwerkregel verwendet, geben Sie die Datenbank an, die das Schema enthält, in dem die Netzwerkregel erstellt wurde.

• Wenn dem Konto eine Netzwerkrichtlinie zugeordnet ist, nehmen Sie NETWORK POLICIES und ACCOUNT PARAMETERS in die Liste OBJECT_TYPES auf.

• Wenn eine Netzwerkrichtlinie einem Benutzer zugeordnet ist, fügen Sie NETWORK POLICIES und USERS in die Liste OBJECT_TYPES ein.

Weitere Details dazu finden Sie unter Replizieren von Netzwerkrichtlinien.

Verwaiste Referenzen und Paketrichtlinien¶

Wenn für das Konto eine Paketrichtlinie festgelegt ist, tritt während der Aktualisierungsoperation für eine Replikations- oder Failover-Gruppe, die Kontoobjekte enthält, der folgende Fehler aufgrund verwaister Referenzen auf:

003131 (55000): Dangling references in the snapshot. Correct the errors before refreshing again.
The following references are missing (referred entity <- [referring entities]):
POLICY '<policy_db>.<policy_schema>.<packages_policy_name>' <- [ACCOUNT '<account_locator>']

Um verwaiste Referenzen zu vermeiden, replizieren Sie die Datenbank, die die Paketrichtlinie enthält, in das Zielkonto. Die Datenbank, die die Richtlinie enthält, kann sich in der gleichen oder einer anderen Replikations- oder Failover-Gruppe befinden.

Verwaiste Referenzen und Geheimnisse¶

Weitere Details dazu finden Sie unter Replikation und Geheimnisse.

Verwaiste Referenzen und Streams¶

Verwaiste Referenzen für Streams können dazu führen, dass die Replikation mit der folgenden Fehlermeldung fehlschlägt:

Primary database: the source object ''<object_name>'' for this stream ''<stream_name>'' is not included in the replication group.
Stream replication does not support replication across databases in different replication groups. Please see Streams Documentation
https://docs.snowflake.com/en/user-guide/account-replication-considerations#replication-and-streams for options.

So vermeiden Sie Fehler durch verwaiste Referenzen:

• Die Primärdatenbank muss sowohl den Stream als auch dessen Basisobjekt enthalten oder

• Die Datenbank, die den Stream enthält, und die Datenbank, die das vom Stream referenzierte Basisobjekt enthält, müssen in derselben Replikations- oder Failover-Gruppe enthalten sein.

In Zielkonten neu erstellt Objekte¶

Wenn ein bestehendes Objekt im Quellkonto mit einer CREATE OR REPLACE-Anweisung ersetzt wird, wird in einer einzigen Transaktion das bestehende Objekt gelöscht und anschließend ein neues Objekt mit demselben Namen erstellt. Wenn Sie beispielsweise eine CREATE OR REPLACE-Anweisung für eine bestehende Tabelle t1 ausführen, wird die Tabelle t1 gelöscht und anschließend eine neue Tabelle t1 erstellt. Weitere Informationen dazu finden Sie in den Nutzungshinweisen für CREATE TABLE.

Wenn Objekte im Zielkonto ersetzt werden, werden die Anweisungen DROP und CREATE während einer Aktualisierungsoperation nicht atomar ausgeführt. Das bedeutet, dass das Objekt möglicherweise kurzzeitig aus dem Zielkonto verschwindet, während es als neues Objekt neu erstellt wird.

Authentifizierungs-, Kennwort- und Sitzungsrichtlinien¶

Referenzen von Authentifizierungs-, Kennwort- und Sitzungsrichtlinien für Benutzer werden repliziert, wenn in einer Replikations- oder Failover-Gruppe die Datenbank, die die Richtlinie enthält (ALLOWED_DATABASES = policy_db), und USERS angegeben werden.

Wenn entweder die Richtliniendatenbank oder die Benutzer bereits in ein Zielkonto repliziert wurden, aktualisieren Sie die Replikations- oder Failover-Gruppe im Quellkonto, um die Datenbanken und Objekttypen aufzunehmen, die für eine erfolgreiche Replikation der Richtlinie erforderlich sind. Führen Sie dann eine Aktualisierungsoperation aus, um das Zielkonto zu aktualisieren.

Wenn auf Benutzerebene keine Richtlinien verwendet werden, muss USERS nicht in die Replikations- oder Failover-Gruppe aufgenommen werden.

Externe Tabellen in einer Primärdatenbank¶

Externe Tabellen in einer Primärdatenbank führen derzeit dazu, dass die Replikations- oder Aktualisierungsoperation mit der folgenden Fehlermeldung fehlschlägt:

003906 (55000): SQL execution error:
Primary database contains an external table '<database_name>'. Replication of a database with external table is not supported

Um diesen Fehler zu vermeiden, verschieben Sie die externen Tabellen in eine separate Datenbank, die nicht repliziert wird. Wenn Sie Ihre Datenbanken auf ein anderes Konto migrieren, können Sie alternativ die primäre Datenbank klonen, die externe Tabelle aus dem Klon löschen und dann die geklonte Datenbank replizieren. Nachdem Sie die Sekundärdatenbank im Zielkonto zur Primärdatenbank heraufgestuft haben, müssten Sie die externen Tabellen in der Datenbank neu erstellen.

Externe Tabellen in einer Sekundärdatenbank¶

Externe Tabellen können in einer Sekundärdatenbank existieren, wenn diese zu einem früheren Zeitpunkt die Primärdatenbank war und die externen Tabellen in dieser Zeit erstellt wurden. Sobald eine andere Datenbank zur Primärdatenbank heraufgestuft wird, wird die bisherige Primärdatenbank wieder zur Sekundärdatenbank. Externe Tabellen in einer Sekundärdatenbank führen derzeit dazu, dass die Aktualisierungsoperation mit dem folgenden Fehler fehlschlägt:

003958 (55000): SQL execution error:
Secondary database contains an external table '<table_name>'. Replication of a database with external table is not supported.

Um diesen Fehler zu vermeiden, verschieben Sie die externe Tabelle in eine separate Datenbank, bei der es sich nicht um eine replizierte Sekundärdatenbank handelt.

Dynamische Tabellen und Replikationsgruppen¶

Eine Datenbank, die eine dynamische Tabelle enthält, kann mithilfe einer Replikationsgruppe repliziert werden. Die Basisobjekte, von denen sie abhängt, müssen sich nicht in derselben Replikationsgruppe befinden.

Sekundäre Objekte sind im Zielkonto schreibgeschützt. Wenn eine sekundäre Replikationsgruppe in einem Zielkonto gelöscht wird, sind die Datenbanken, die in der Gruppe enthalten waren, nicht mehr schreibgeschützt. Alle dynamischen Tabellen, die in einer Replikationsgruppe enthalten sind, bleiben jedoch schreibgeschützt, auch wenn die sekundäre Gruppe im Zielkonto gelöscht wird. Auf diesen schreibgeschützten dynamischen Tabellen können keine DML-Befehle oder Aktualisierungen ausgeführt werden.

Dynamische Tabellen und Failover-Gruppen und Datenbankreplikation¶

Eine Datenbank, die eine dynamische Tabelle enthält, kann mithilfe einer Failover-Gruppe repliziert werden. Die Basisobjekte, von denen sie abhängt, müssen in der gleichen Failover-Gruppe enthalten sein. Andernfalls entsteht während der Aktualisierungsoperation eine verwaiste Referenz mit der folgenden Fehlermeldung:

002749 (55000): SQL execution error: Dynamic table <dt_name> has dependencies that are missing in the replication membership: <dependency_table_name>

Dasselbe gilt, wenn die dynamische Tabelle in einer Datenbank mittels Datenbankreplikation repliziert wird. Die Basisobjekte, von denen die dynamische Tabelle abhängt, müssen in derselben Datenbank enthalten sein, um einen Fehler aufgrund verwaister Referenzen zu vermeiden.

Sekundäre dynamische Tabellen sind schreibgeschützt und werden nicht aktualisiert. Nachdem ein Failover stattgefunden hat und eine sekundäre dynamische Tabelle zur primären dynamischen Tabelle heraufgestuft wurde, ist die erste Aktualisierung eine Neuinitialisierung, gefolgt von inkrementellen Aktualisierungen, wenn die dynamische Tabelle für eine inkrementelle Aktualisierung der Daten konfiguriert ist.

Vermeiden von Datenverlusten¶

Um Datenverluste bei einem Failover zu vermeiden, muss die Datenaufbewahrungsdauer für erfolgreich eingefügte Zeilen in Ihrer Upstream-Datenquelle größer sein als die Replikationshäufigkeit. Wenn Daten in die Tabelle einer Primärdatenbank eingefügt werden und ein Failover stattfindet, bevor die Daten in die Sekundärdatenbank repliziert werden können, müssen dieselben Daten in die Tabelle der neu heraufgestuften Primärdatenbank eingefügt werden. Nachfolgend ein Beispielszenario:

1. Die Tabelle t1 in der Primärdatenbank repl_db wird über Snowpipe Streaming und den Kafka-Konnektor mit Daten gefüllt.

2. Der Wert von offsetToken ist 100 für Kanal 1 und 100 für Kanal 2 für t1 in der Primärdatenbank.

3. Eine Aktualisierungsoperation wird im Zielkonto erfolgreich abgeschlossen.

4. Der Wert von offsetToken ist 100 für Kanal 1 und 100 für Kanal 2 für t1 in der Sekundärdatenbank.

5. Weitere Zeilen werden in t1 in der Primärdatenbank eingefügt.

6. Der Wert von offsetToken ist jetzt 200 für Kanal 1 und 200 für Kanal 2 für t1 in der Primärdatenbank.

7. Ein Failover findet statt, bevor die zusätzlichen Zeilen und neuen Kanal-Offsets in die Sekundärdatenbank repliziert werden können.

In diesem Fall fehlen 100 Offsets in jedem Kanal für die Tabelle t1 in der neu heraufgestuften Primärdatenbank. Weitere Informationen zum Einfügen der fehlenden Daten finden Sie unter Aktive Kanäle für Snowpipe Streaming im neu heraufgestuften Quellkonto wieder öffnen.

Anforderungen¶

Für die Snowpipe Streaming-Replikation sind die folgenden Mindestversionen erforderlich:

• Snowflake Ingest SDK Version 1.1.1 und höher

• Bei Verwendung des Kafka-Konnektors: Kafka-Konnektor Version 1.9.3 und höher

Gespeicherte Prozeduren und UDFs und Stagingbereiche¶

Wenn eine gespeicherte Prozedur oder UDF von Dateien in einem Stagingbereich abhängt (z. B. wenn die gespeicherte Prozedur in Python-Code definiert ist, der aus einem Stagingbereich hochgeladen wird), müssen Sie den Stagingbereich und die Dateien in die Sekundärdatenbank replizieren. Weitere Informationen zum Replizieren von Stagingbereichen finden Sie unter Replikation von Stagingbereichen, Pipes und des Ladeverlaufs.

Wenn beispielsweise eine Primärdatenbank über eine Python-Inline-UDF verfügt, die jeden Code importiert, der in einem Stagingbereich gespeichert ist, funktioniert die UDF erst, wenn auch der Stagingbereich und der importierte Code in die Sekundärdatenbank repliziert wurden.

Gespeicherte Prozeduren und UDFs und externer Netzwerkzugriff¶

Wenn eine gespeicherte Prozedur oder UDF vom Zugriff auf einen externen Netzwerkstandort abhängt, müssen Sie die folgenden Objekte replizieren:

• EXTERNAL ACCESS INTEGRATIONS muss in der Liste allowed_integration_types der Replikations- oder Failover-Gruppe enthalten sein.

• Die Datenbank, die die Netzwerkregel enthält.

• Die Datenbank, die das Geheimnis enthält, in dem die Anmeldeinformationen für die Authentifizierung beim externen Netzwerkstandort gespeichert sind.

• Wenn das Geheimnisobjekt auf eine Sicherheitsintegration verweist, müssen Sie SECURITY INTEGRATIONS in die Liste allowed_integration_types der Replikations- oder Failover-Gruppe aufnehmen.

Unterstützte Quellobjekte für Streams¶

Replizierte Streams können erfolgreich die Änderungsdaten für Tabellen und Ansichten innerhalb derselben Datenbank verfolgen.

Derzeit werden die folgenden Quellobjekttypen nicht unterstützt:

• Externe Tabellen

• Tabellen oder Ansichten in Datenbanken, die von den Stream-Datenbanken getrennt sind, es sei denn, beide Datenbanken – die Stream-Datenbank und die Datenbank, die das Quellobjekt speichert – sind in derselben Replikations- oder Failover-Gruppe enthalten.

• Tabellen oder Ansichten in freigegebenen Datenbanken (d. h. Datenbanken, die von Anbieterkonten für Ihr Konto freigegeben wurden)

Die Replikation von Streams auf Verzeichnistabellen wird unterstützt, wenn Sie Replikation von Stagingbereichen, Pipes und des Ladeverlaufs aktivieren.

Die Replikations- oder Aktualisierungsoperation einer Datenbank schlägt fehl, wenn die Primärdatenbank einen Stream mit einem nicht unterstützten Quellobjekt enthält. Die Operation schlägt auch fehl, wenn das Quellobjekt eines Streams gelöscht wurde.

Nur-Anfügen-Streams werden bei replizierten Quellobjekten nicht unterstützt.

Vermeiden von Datenkopien¶

Eine Datenduplizierung tritt auf, wenn DML-Operationen dieselben Änderungsdaten aus einem Stream mehrfach schreiben, ohne eine Eindeutigkeitsprüfung auszuführen. Dies kann vorkommen, wenn ein Stream und eine Zieltabelle für die Stream-Änderungsdaten in separaten Datenbanken gespeichert sind und diese Datenbanken nicht in dieselbe Replikations- oder Failover-Gruppe übertragen werden.

Angenommen, Sie fügen regelmäßig Änderungsdaten aus Stream s in Tabelle dt ein. (Für dieses Beispiel spielt das Quellobjekt für den Stream keine Rolle.) Stream- und Zieltabelle werden in getrennten Datenbanken gespeichert.

1. Zum Zeitstempel t1 wird eine Zeile in die Quelltabelle von Stream s eingefügt und eine neue Tabellenversion erstellt. Der Stream speichert den Offset dieser Tabellenversion.

2. Zum Zeitstempel t2 wird die Sekundärdatenbank, in der der Stream gespeichert ist, aktualisiert. Der replizierte Stream s speichert nun den Offset.

3. Zum Zeitstempel t3 werden die Änderungsdaten von Stream s in die Tabelle dt eingefügt.

4. Zum Zeitstempel t4 wird für die Sekundärdatenbank, die Stream s speichert, ein Failover ausgeführt.

5. Zum Zeitstempel t5 werden die Änderungsdaten von Stream s erneut in die Tabelle dt eingefügt.

Um diese Situation zu vermeiden, müssen Sie Replikation und Failover für alle Datenbanken, in denen die Streams und deren Zieltabellen gespeichert sind, zusammen ausführen.

Streamreferenzen in WHEN-Klausel von Aufgaben¶

Um unerwartetes Verhalten zu vermeiden, wenn Sie replizierte Aufgaben ausführen, die Streams in der WHEN boolean_expr-Klausel referenzieren, gibt es folgende Optionen:

• Erstellen Sie die Aufgaben und Streams in derselben Datenbank oder

• Wenn Streams in einer anderen Datenbank gespeichert sind als die Aufgaben, die auf sie verweisen, schließen Sie beide Datenbanken in dieselbe Failover-Gruppe ein.

Wenn eine Aufgabe auf einen Stream in einer separaten Datenbank verweist und beide Datenbanken nicht in der gleichen Failover-Gruppe enthalten sind, könnte das Failover der Datenbank, die die Aufgabe enthält, ohne die Datenbank ausgeführt werden, die den Stream enthält. In diesem Szenario wird bei Fortsetzung der Aufgabe in der ausgefallenen Datenbank ein Fehler erfasst, wenn versucht wird, die Aufgabe auszuführen, und der referenzierte Stream nicht gefunden wird. Dieses Problem kann gelöst werden, indem entweder ein Failover der Datenbank ausgeführt wird, die den Stream enthält, oder Datenbank und Stream in demselben Konto wie die fehlgeschlagene Datenbank, die die Aufgabe enthält, neu erstellt werden.

Veralten von Streams¶

Wenn ein Stream in der Primärdatenbank veraltet, veraltet auch der replizierte Stream in einer Sekundärdatenbank, sodass dessen Daten nicht mehr abgefragt und Änderungsdaten nicht mehr verbraucht werden können. Um dieses Problem zu lösen, erstellen Sie den Stream in der Primärdatenbank neu (mit CREATE OR REPLACE STREAM). Wenn die Sekundärdatenbank aktualisiert wird, ist der replizierte Stream wieder lesbar.

Beachten Sie, dass der Offset für einen neu erstellten Stream standardmäßig die aktuelle Tabellenversion ist. Sie können einen Stream, der auf eine frühere Tabellenversion verweist, mit Time Travel neu erstellen. Der replizierte Stream wäre dann jedoch nicht lesbar. Weitere Informationen dazu finden Sie unter Streamreplikation und Time Travel (unter diesem Thema).

Streamreplikation und Time Travel¶

Wenn nach dem Failover einer Primärdatenbank ein Stream in der Datenbank Time Travel verwendet, um eine Tabellenversion für das Quellobjekt zu einem Zeitpunkt vor dem letzten Aktualisierungszeitstempel zu lesen, kann der replizierte Stream nicht abgefragt und Änderungsdaten können nicht verbraucht werden. Ebenso schlägt das Abfragen der Änderungsdaten für ein Quellobjekt zu einem Zeitpunkt vor dem letzten Aktualisierungszeitstempel bei Verwendung der CHANGES-Klausel in SELECT-Anweisungen mit einem Fehler fehl.

Dies liegt daran, dass bei einer Aktualisierungsoperation die Tabellenhistorie zu einer einzigen Tabellenversion zusammenfasst wird. Iterative Tabellenversionen, die vor dem Zeitstempel der Aktualisierungsoperation erstellt wurden, werden in der Tabellenhistorie der replizierten Quellobjekte nicht aufbewahrt.

Betrachten Sie das folgende Beispiel:

1. Tabelle t1 wird in der Primärdatenbank erstellt und die Änderungsverfolgung aktiviert (Tabellenversion tv0). Durch nachfolgende DML-Transaktionen werden die Tabellenversionen tv1 und tv2 erstellt.

2. Die Sekundärdatenbank, die die Tabelle t1 enthält, wird aktualisiert. Die Tabellenversion dieser replizierten Tabelle ist tv2, wobei die Tabellenhistorie jedoch nicht repliziert wird.

3. In der Primärdatenbank wird ein Stream erstellt, dessen Offset mithilfe von Time Travel auf die Tabellenversion tv1 gesetzt wird.

4. Für die Sekundärdatenbank wird ein Failover ausgeführt, wodurch sie zur Primärdatenbank wird.

5. Das Abfragen von Stream s1 gibt einen Fehler zurück, da die Tabellenversion tv1 nicht in der Tabellenhistorie enthalten ist.

Beachten Sie Folgendes: Wenn durch eine nachfolgende DML-Transaktion auf Tabelle t1 die Tabellenversion auf tv3 iteriert wird, wird der Offset für Stream s1 vorverlegt. Der Stream ist wieder lesbar.

Vermeiden von Datenverlusten¶

Datenverlusten können auftreten, wenn die letzte Aktualisierungsoperation einer Sekundärdatenbank nicht vor der Failover-Operation abgeschlossen ist. Wir empfehlen, Ihre Sekundärdatenbanken regelmäßig zu aktualisieren, um dieses Risiko zu minimieren.

Replikationsszenarios¶

In der folgenden Tabelle sind die verschiedenen Aufgabenszenarios beschrieben, und es wird angegeben, ob die Aufgaben repliziert werden oder nicht. Wenn nicht anders angegeben, beziehen sich die Szenarios sowohl auf eigenständige Aufgaben als auch auf Aufgaben in einem Task-Graphen:

Status „Fortgesetzt“ oder „Angehalten“ von replizierten Aufgaben¶

Wenn jede der folgenden Bedingungen erfüllt ist, wird eine Aufgabe im Status „Fortgesetzt“ in die Sekundärdatenbank repliziert:

• Eine eigenständige oder Stammaufgabe befindet sich in der Primärdatenbank im Status „Fortgesetzt“, wenn die Replikations- oder Aktualisierungsoperation beginnt und bis zum Abschluss der Operation. Befindet sich eine Aufgabe nur während eines Teils dieses Zeitraums im Status „Fortgesetzt“, kann sie dennoch im Status „Fortgesetzt“ repliziert werden.

  Eine untergeordnete Aufgabe befindet sich mit seiner neuesten Version im Status „Fortgesetzt“.

• Die übergeordnete Datenbank wurde zusammen mit Rollenobjekten derselben oder einer anderen Replikations- oder Failover-Gruppe in das Zielkonto repliziert.

  Nachdem die Rollen und die Datenbank repliziert wurden, müssen Sie die Objekte im Zielkonto aktualisieren, indem Sie ALTER REPLICATION GROUP … REFRESH bzw. ALTER FAILOVER GROUP … REFRESH ausführen. Wenn Sie die Datenbank durch Ausführen von ALTER DATABASE … REFRESH aktualisieren, wird der Status der Aufgaben in der Datenbank in „Angehalten“ geändert.

  Eine Replikations- oder Aktualisierungsoperation umfasst auch Berechtigungszuweisungen für eine Aufgabe, die zum Zeitpunkt der Commit-Ausführung der neuesten Tabellenversion gültig waren. Weitere Informationen dazu finden Sie unter Replizierte Aufgaben und Berechtigungszuweisungen (unter diesem Thema).

Wenn diese Bedingungen nicht erfüllt sind, wird die Aufgabe im Status „Angehalten“ in eine Sekundärdatenbank repliziert.

Replizierte Aufgaben und Berechtigungszuweisungen¶

Wenn die übergeordnete Datenbank zusammen mit Rollenobjekten derselben oder einer anderen Replikations- oder Failover-Gruppe in ein Zielkonto repliziert wird, werden auch die den Aufgaben in der Datenbank erteilten Berechtigungen repliziert.

Die folgende Logik bestimmt, welche Aufgabenberechtigungen bei einer Replikations- oder Aktualisierungsoperation repliziert werden:

• Wenn der aktuelle Aufgabeneigentümer (d. h. die Rolle mit OWNERSHIP-Berechtigung für die Aufgabe) dieselbe Rolle ist wie bei der letzten Fortsetzung der Aufgabe, werden alle aktuell für die Aufgabe erteilten Berechtigungen in die Sekundärdatenbank repliziert.

• Wenn der aktuelle Aufgabeneigentümer nicht dieselbe Rolle ist wie bei der letzten Fortsetzung der Aufgabe, dann wird in die Sekundärdatenbank nur die OWNERSHIP-Berechtigung repliziert, die der Eigentümerrolle in der Aufgabenversion zugewiesen wurde.

• Wenn die aktuelle Rolle des Aufgabeneigentümers nicht verfügbar ist (z. B. wenn eine untergeordnete Aufgabe gelöscht wurde, aber eine neue Version des Task-Graphen noch nicht mit Commit bestätigt wurde), wird in die Sekundärdatenbank nur die OWNERSHIP-Berechtigung repliziert, die der Eigentümerrolle in der Aufgabenversion zugewiesen wurde.

Aufgabenausführung nach einem Failover¶

Nachdem eine sekundäre Failover-Gruppe zur primären Gruppe heraufgestuft wurde, werden alle fortgesetzten Aufgaben in Datenbanken innerhalb der Failover-Gruppe schrittweise geplant. Die Zeit, die zur Wiederherstellung der normalen Planung aller fortgesetzten eigenständigen Aufgaben und Task-Graphen benötigt wird, hängt von der Anzahl der fortgesetzten Aufgaben in einer Datenbank ab.