REPLICATION_GROUP_REFRESH_PROGRESS, REPLICATION_GROUP_REFRESH_PROGRESS_BY_JOB, REPLICATION_GROUP_REFRESH_PROGRESS_ALL¶

Syntax¶

REPLICATION_GROUP_REFRESH_PROGRESS( '<secondary_group_name>' )

REPLICATION_GROUP_REFRESH_PROGRESS_BY_JOB( '<query_id>' )

REPLICATION_GROUP_REFRESH_PROGRESS_ALL(
      [ DATE_RANGE_START => <constant_expr> ]
      [ , DATE_RANGE_END => <constant_expr> ] )

Argumente¶

'secondary_group_name'

Name der sekundären Replikations- oder Failover-Gruppe. Beachten Sie, dass der gesamte Name in einfache Anführungszeichen gesetzt werden muss.

'query_id'

ID der Aktualisierungsabfrage der Replikationsgruppe. Die Abfrage-ID kann von der Seite History der Weboberfläche abgerufen werden.

Die folgenden Argumente sind für REPLICATION_GROUP_REFRESH_PROGRESS_ALL optional.

DATE_RANGE_START => constant_expr, . DATE_RANGE_END => constant_expr

Der Datums-/Uhrzeitbereich, für den der Aktualisierungsfortschritt der Replikation zurückgegeben werden soll.

• Wenn weder Start- noch Enddatum angegeben sind, werden standardmäßig die letzten 12 Stunden verwendet.

• Wenn ein Startdatum, aber kein Enddatum angegeben ist, wird CURRENT_DATE um Mitternacht als Ende des Bereichs verwendet.

• Wenn ein Enddatum, aber kein Startdatum angegeben ist, beginnt der Bereich 12 Stunden vor dem Start von DATE_RANGE_END.

Daten werden 14 Tage lang aufbewahrt. Wenn der angeforderte Bereich über das 14-tägige Aufbewahrungsfenster hinausgeht, gibt die Funktion einen Fehler zurück.

Ausgabe¶

Die Funktion gibt die folgenden Spalten zurück: REPLICATION_GROUP_REFRESH_PROGRESS_ALL hat zusätzliche Spalten, die die ersten beiden Spalten im Resultset sind.

Nutzungshinweise¶

• Wenn keine Argumente des Typs DATE_RANGE_START oder``DATE_RANGE_END`` angegeben werden, gibt REPLICATION_GROUP_REFRESH_PROGRESS_ALL Daten für die letzten 12 Stunden zurück. Um Daten abzurufen, die über die letzten 12 Stunden hinausgehen, geben Sie den Datumsbereich explizit an. Die Daten sind bis zu 14 Tage lang verfügbar.

• Gibt nur Zeilen für eine Rolle mit beliebigen Berechtigungen für die Replikations- oder Failover-Gruppe zurück.

• Gibt nur Zeilen für eine sekundäre Replikations- oder Failover-Gruppe im aktuellen Konto zurück.

• Beim Aufrufen einer Tabellenfunktion des Information Schema muss die Sitzung über ein aktives INFORMATION_SCHEMA-Schema verfügen oder der Funktionsname muss vollqualifiziert sein. Weitere Details dazu finden Sie unter Snowflake Information Schema.

• Die folgende Liste zeigt die Verarbeitungsreihenfolge der Phasen:

  #	Phasenname	Beschreibung
  1	SECONDARY_SYNCHRONIZING_MEMBERSHIP	Die sekundäre Replikations- oder Failover-Gruppe erhält von der primären Gruppe Informationen über die in der Gruppe enthaltenen Objekte und aktualisiert ihre Mitgliedschaftsmetadaten.
  2	SECONDARY_UPLOADING_INVENTORY	Die sekundäre Replikations- oder Failover-Gruppe sendet eine Bestandsliste ihrer Objekte im Zielkonto an die primäre Gruppe.
  3	PRIMARY_UPLOADING_METADATA	Die primäre Replikations- oder Failover-Gruppe erstellt einen Snapshot der Metadaten im Quellkonto und sendet ihn an die sekundäre Gruppe.
  4	PRIMARY_UPLOADING_DATA	Die primäre Replikations- oder Failover-Gruppe kopiert die Dateien, die die sekundäre Gruppe benötigt, um etwaige Deltas zwischen den Objekten in den Quell- und Zielkonten abzugleichen.
  5	SECONDARY_DOWNLOADING_METADATA	Die sekundäre Replikations- oder Failover-Gruppe wendet den von der primären Gruppe gesendeten Snapshot der Metadaten an. Die Metadatenaktualisierung werden nicht atomar, sondern im Laufe der Zeit vorgenommen.
  6	SECONDARY_DOWNLOADING_DATA	Die sekundäre Replikations- oder Failover-Gruppe kopiert die von der primären Gruppe gesendeten Dateien auf das Zielkonto.
  7	COMPLETED / FAILED / CANCELED	Betriebsstatus aktualisieren

  See moreShow less

  Expand

• In den Phasen PRIMARY_UPLOADING_DATA und SECONDARY_DOWNLOADING_DATA erfolgt vor der Replikationsoperation eine Schätzung des totalBytesToReplicate-Werts. Dieser Wert kann von dem totalBytesToUpload- oder totalBytesToDownload-Wert der jeweiligen Phase abweichen.

  Wenn beispielsweise während der Phase PRIMARY_UPLOADING_DATA von einer vorherigen Replikationsoperation einige Bytes hochgeladen wurden, die Operation aber vorzeitig abgebrochen wurde, werden diese Bytes nicht erneut hochgeladen. In diesem Fall wäre totalBytesToUpload niedriger als totalBytesToReplicate.

Beispiele¶

Um den aktuellen Aktualisierungsfortschritt für die Replikationsgruppe rg1 abzurufen, führen Sie die folgende Anweisung aus:

SELECT phase_name, start_time, end_time, progress, details
  FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_PROGRESS('rg1'));

Um den Aktualisierungsfortschritt der Replikationsgruppe über die Abfrage-ID abzurufen, ersetzen Sie die Abfrage-ID im Beispiel und führen Sie die folgende Anweisung aus:

SELECT phase_name, start_time, end_time, progress, details
  FROM TABLE(
    INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_PROGRESS_BY_JOB(
      '012a3b45-1234-a12b-0000-1aa200012345'));

Um den Aktualisierungsfortschritt der letzten 12 Stunden (Standard) für alle Failover-Gruppen und Replikationsgruppen abzurufen, führen Sie die folgende Anweisung aus:

SELECT phase_name, start_time, end_time, progress, details
  FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_PROGRESS_ALL());

Abrufen des Aktualisierungsfortschritts der letzten 7 Tage für alle Gruppen:

SELECT phase_name, start_time, end_time, progress, details
  FROM TABLE(
    INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_PROGRESS_ALL(
        DATE_RANGE_START => DATEADD(D, -7, CURRENT_DATE),
        DATE_RANGE_END => CURRENT_DATE));