REPLICATION_GROUP_REFRESH_PROGRESS, REPLICATION_GROUP_REFRESH_PROGRESS_BY_JOB, REPLICATION_GROUP_REFRESH_PROGRESS_ALL¶

Syntaxe¶

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> ] )

Arguments¶

'secondary_group_name'

Nom du groupe de réplication ou de basculement secondaire. Notez que le nom entier doit être entre guillemets simples.

'query_id'

ID de la requête d’actualisation du groupe de réplication. L’ID de requête peut être obtenu à partir de la page History dans l’interface Web.

Les arguments suivants sont facultatifs pour REPLICATION_GROUP_REFRESH_PROGRESS_ALL.

DATE_RANGE_START => constant_expr , . DATE_RANGE_END => constant_expr

La plage date/heure pour laquelle renvoyer la progression de l’actualisation de la réplication.

• Si ni date de début, ni date de fin n’est spécifiée, la valeur par défaut correspondra aux 12 dernières heures.

• Si une date de début est spécifiée, mais qu’aucune date de fin ne l’est, CURRENT_DATE à minuit est utilisé comme fin de plage.

• Si une date de fin est spécifiée, mais qu’aucune date de début ne l’est, la plage commence 12 heures avant le début de DATE_RANGE_END.

Les données sont conservées pendant 14 jours. Si la plage demandée dépasse la fenêtre de conservation de 14 jours, la fonction renvoie une erreur.

Sortie¶

La fonction renvoie les colonnes suivantes. REPLICATION_GROUP_REFRESH_PROGRESS_ALL comporte des colonnes supplémentaires qui sont les deux premières colonnes du jeu de résultats.

Notes sur l’utilisation¶

• Lorsqu’aucun argument DATE_RANGE_START ou DATE_RANGE_END n’est fourni, REPLICATION_GROUP_REFRESH_PROGRESS_ALL renvoie les données des 12 dernières heures. Pour récupérer des données au-delà des 12 dernières heures, indiquez explicitement la plage de dates. Les données sont disponibles pour un maximum de 14 jours.

• Ne renvoie que les lignes pour un rôle ayant un quelconque privilège sur le groupe de réplication ou de basculement.

• Renvoie uniquement les lignes pour un groupe de réplication ou de basculement secondaire dans le compte actuel.

• Lors de l’appel d’une fonction de table Information Schema, la session doit avoir un schéma INFORMATION_SCHEMA en cours d’utilisation ou le nom de la fonction doit être complètement qualifié. Pour plus de détails, voir Schéma d’information de Snowflake.

• Voici la liste des phases de traitement dans l’ordre :

  #	Nom de la phase	Description
  1	SECONDARY_SYNCHRONIZING_MEMBERSHIP	Le groupe de réplication secondaire ou de basculement reçoit des informations du groupe principal sur les objets inclus dans le groupe et met à jour ses métadonnées d’appartenance.
  2	SECONDARY_UPLOADING_INVENTORY	Le groupe de réplication secondaire ou de basculement envoie un inventaire de ses objets dans le compte cible au groupe principal.
  3	PRIMARY_UPLOADING_METADATA	Le groupe de réplication ou de basculement principal crée un instantané des métadonnées dans le compte source et l’envoie au groupe secondaire.
  4	PRIMARY_UPLOADING_DATA	Le groupe de réplication principal ou de basculement copie les fichiers dont le groupe secondaire a besoin pour réconcilier les deltas entre les objets des comptes source et cible.
  5	SECONDARY_DOWNLOADING_METADATA	Le groupe de réplication ou de basculement secondaire applique l’instantané des métadonnées envoyées par le groupe principal. Les mises à jour des métadonnées ne sont pas appliquées de manière atomique mais au fil du temps.
  6	SECONDARY_DOWNLOADING_DATA	Le groupe de réplication secondaire ou de basculement copie les fichiers envoyés par le groupe principal vers le compte cible.
  7	COMPLETED / FAILED / CANCELED	Actualiser le statut de l’opération.

  See moreShow less

  Expand

• Dans les phases PRIMARY_UPLOADING_DATA et SECONDARY_DOWNLOADING_DATA, la valeur totalBytesToReplicate est estimée avant l’opération de réplication. Cette valeur peut différer de la valeur totalBytesToUpload ou totalBytesToDownload dans la phase respective.

  Par exemple, si au cours de la phase PRIMARY_UPLOADING_DATA, une opération de réplication précédente a téléchargé certains octets mais a été annulée avant la fin de l’opération, ces octets ne seront pas téléchargés à nouveau. Dans ce cas, totalBytesToUpload serait inférieur à totalBytesToReplicate.

Exemples¶

Pour récupérer la progression actuelle de l’actualisation du groupe de réplication rg1, exécutez l’instruction suivante :

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

Pour récupérer la progression de l’actualisation du groupe de réplication par ID de requête, remplacez l’ID de requête dans l’exemple et exécutez l’instruction suivante :

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

Pour récupérer la progression de l’actualisation des 12 dernières heures (par défaut) pour tous les groupes de basculement et tous les groupes de réplication, exécutez l’instruction suivante :

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

Pour récupérer la progression de l’actualisation des 7 derniers jours pour tous les groupes :

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));