Surveiller le décalage
Les statistiques de décalage indiquent si les processus Oracle GoldenGate suivent le rythme de la quantité de données générées par les applications métier. Ces informations vous permettent de diagnostiquer les problèmes suspects et de régler les performances des processus Oracle GoldenGate afin de réduire la latence entre les bases de données source et cible.
A propos du décalage
Pour l'extraction, le décalage est la différence (en secondes) entre l'heure à laquelle un enregistrement a été traité par l'extraction (selon l'horloge système) et l'horodatage de cet enregistrement dans la source de données.
Pour la réplication, le décalage est la différence (en secondes) entre l'heure à laquelle le dernier enregistrement a été traité par la réplication (selon l'horloge système) et l'horodatage de l'enregistrement dans la trace.
Pour afficher les statistiques de décalage, utilisez les commandes [LAG](/pls/topic/lookup?ctx=en/database/goldengate/core/26/coredoc&id=GCLIR-GUID-52D1B2C3-6ACF-4461-9ED2-FD3AE9121022) ou [SEND ER](/pls/topic/lookup?ctx=en/database/goldengate/core/26/coredoc&id=GCLIR-GUID-DD62102E-A84D-4866-9A3A-9C2281CFEED7), [SEND EXTRACT](/pls/topic/lookup?ctx=en/database/goldengate/core/26/coredoc&id=GCLIR-GUID-2A83CA04-DAB8-494B-BF36-F8D15E645749) et [SEND REPLICAT](/pls/topic/lookup?ctx=en/database/goldengate/core/26/coredoc&id=GCLIR-GUID-DBA8F45C-6016-4AB4-BF9A-00C117029E7F).
Remarque : la commande INFO renvoie également une statistique de décalage, mais cette statistique provient du dernier enregistrement ayant fait l'objet d'un point de reprise, et non de l'enregistrement en cours de traitement. Il est moins précis que LAG ou INFO.
Surveiller le décalage à l'aide de tables de signal d'activité automatiques
Vous pouvez utiliser la fonctionnalité de table de signal d'activité automatique par défaut pour surveiller le décalage de réplication de bout en bout. Les signaux d'activité automatiques sont envoyés de chaque base de données source vers les flux de réplication, en mettant à jour les enregistrements dans une table de départ de signal d'activité et une table de signal d'activité, et en créant une heartbeat history table. Chacun des processus de réplication dans le chemin de réplication traite ces enregistrements de signal d'activité et met à jour les informations qu'ils contiennent. Ces enregistrements de signal d'activité sont insérés ou mis à jour dans la table de signal d'activité des bases de données cible.
Les tables de signal d'activité contiennent les informations suivantes :
-
Base de donnée source
-
Base de données de destination
-
Informations sur les flux de réplication sortants :
-
Noms des processus Extract, Distribution Service et ou Replicat dans le chemin
-
Horodatage du traitement des enregistrements de signal d'activité par les processus de réplication.
-
-
Informations sur les flux de réplication entrants :
-
Noms des processus Extract, Distribution Service et ou Replicat dans le chemin
-
Horodatage du traitement des enregistrements de signal d'activité par les processus de réplication.
-
A l'aide des informations de la table des signaux d'activité et de la table d'historique des signaux d'activité, les décalages actuels et historiques de chaque réplication peuvent être calculés.
Le processus Replicat peut suivre la position de redémarrage en cours de l'extraction avec des tables de signal d'activité automatiques (LOGBSN). Cela permet de régénérer les fichiers trace à partir de la base de données source, si nécessaire, et réduit la période de conservation des fichiers de journalisation de la base source. En outre, en suivant la position de redémarrage de l'extraction la plus récente, les tables de pierre tombale pour les tables automatiques de détection et de résolution des conflits (ACDR) peuvent être purgées plus fréquemment.
Dans une configuration bidirectionnelle, la table de signal d'activité comporte autant d'entrées que le nombre de chemins de réplication vers les voisins de la base de données et, dans une configuration unidirectionnelle, la table de la source est vide. Les colonnes sortantes ont les horodatages et le chemin sortant, l'extraction locale et les processus en aval. Les colonnes entrantes ont les horodatages et le chemin des processus en amont et du processus Replicat local.
Dans une configuration unidirectionnelle, la base de données cible ne renseigne que les colonnes entrantes de la table de signal d'activité.
Remarque : la fonctionnalité de signal d'activité automatique n'est pas prise en charge sur MySQL version 5.5.
Flux de réplication de bout en bout de la table de signal d'activité
Le processus de réplication de bout en bout pour les tables de signal d'activité repose sur l'utilisation du format de trace Oracle GoldenGate. Le processus est le suivant :
Ajoutez une table de signal d'activité à chacune de vos bases de données à l'aide de la commande ADD HEARTBEATTABLE. Ajoutez la table de signal d'activité à toutes les instances source et cible, puis redémarrez les processus Oracle GoldenGate existants pour activer la fonctionnalité de signal d'activité. Selon la base de données, vous devrez peut-être créer ou activer un travail pour alimenter les données de la table de signal d'activité.
Reportez-vous à l'exemple suivant :
DBLOGIN USERIDALIAS *alias* [DOMAIN domain]|[SYSDBA | SQLID sqlid][SESSIONCHARSET character_set]}ADD HEARTBEATTABLE(Facultatif) Pour les bases de données Oracle, vous devez vous assurer que l'instance Oracle DBMS_SCHEDULER fonctionne correctement car la mise à jour du signal d'activité en dépend. Pour interroger DBMS_SCHEDULER, exécutez la commande suivante :
SELECT START_DATE, LAST_START_DATE, NEXT_RUN_DATE
FROM DBA_SCHEDULER_JOBSOù job_name ='GG_UPDATE_HEARTBEATS';
Recherchez ensuite des entrées valides pour NEXT_RUN_DATE, qui est la prochaine exécution du planificateur. S'il s'agit d'un horodatage dans le passé, aucun travail ne sera exécuté et vous devez le corriger.
Une raison courante pour laquelle le planificateur ne fonctionne pas est lorsque le paramètre job_queue_processes est défini sur une valeur trop faible (généralement zéro). Augmentez le nombre de processus job_queue_processes configurés dans la base de données à l'aide de la commande ALTER SYSTEM SET JOB_QUEUE_PROCESSES = ##;, où ## est le nombre de processus de file d'attente de travaux.
Exécutez une extraction qui, à la réception des enregistrements logiques de modification (LCR), vérifie la valeur de la colonne OUTGOING_EXTRACT.
-
Si le nom de l'extraction correspond à cette valeur, la colonne
OUTGOING_EXTRACT_TSest mise à jour et l'enregistrement est entré dans la trace. -
Si le nom de l'extraction ne correspond pas, le LCR est supprimé.
-
Si la valeur
OUTGOING_EXTRACTestNULL, elle est renseignée avecOUTGOING_EXTRACT_TSet l'enregistrement est entré dans la trace.
Lors de la lecture de l'enregistrement, le service de distribution vérifie la valeur dans la colonne OUTGOING_ROUTING_PATH. Cette colonne contient une liste de chemins de distribution.
Si la valeur est NULL, la colonne est mise à jour avec le nom de groupe en cours (et le chemin s'il s'agit d'un service de distribution),"*", la colonne OUTGOING_ROUTING_TS est mise à jour et l'enregistrement est écrit dans son fichier trace cible.
Si la valeur a une valeur "*" dans la liste, remplacez-la par group name[:pathname],"*"', mettez à jour la colonne OUTGOING_ROUTING_TS et l'enregistrement est écrit dans son fichier trace cible. Lorsque la valeur ne comporte pas d'astérisque (*) dans la liste et que le nom du chemin de distribution figure dans la liste, l'enregistrement est envoyé au chemin indiqué dans la paire group name[:pathname],"*"' correspondante dans la liste. Si le nom du chemin de distribution ne figure pas dans la liste, l'enregistrement est supprimé.
Exécutez une réplication qui, à la réception de l'enregistrement, vérifie la valeur de la colonne OUTGOING_REPLICAT.
-
Si le nom de la réplication correspond à la valeur, la ligne de la table de signal d'activité est mise à jour et l'enregistrement est inséré dans la table d'historique.
-
Si le nom de la réplication ne correspond pas, l'enregistrement est supprimé.
-
Si la valeur est
NULL, la ligne des tables d'historique des signaux d'activité et des signaux d'activité est mise à jour avec un appel implicite du mapping de colonne Replicat.Mise en correspondance automatique des colonnes de réplication :
REMOTE_DATABASE = LOCAL_DATABASE INCOMING_EXTRACT = OUTGOING_EXTRACT INCOMING_ROUTING_PATH = OUTGOING_ROUTING_PATH with "*" removed INCOMING_REPLICAT = @GETENV ("GGENVIRONMENT", "GROUPNAME") INCOMING_HEARTBEAT_TS = HEARTBEAT_TIMESTAMP INCOMING_EXTRACT_TS = OUTGOING_EXTRACT_TS INCOMING_ROUTING_TS = OUTGOING_ROUTING_TS INCOMING_REPLICAT_TS = @DATE ('UYYYY-MM-DD HH:MI:SS.FFFFFF','JTSLCT',@GETENV ('JULIANTIMESTAMP')) LOCAL_DATABASE = REMOTE_DATABASE OUTGOING_EXTRACT = INCOMING_EXTRACT OUTGOING_ROUTING_PATH = INCOMING_ROUTING_PATH OUTGOING_HEARTBEAT_TS = INCOMING_HEARTBEAT_TS OUTGOING_REPLICAT = INCOMING_REPLICAT OUTGOING_HEARTBEAT_TS = INCOMING_HEARTBEAT_TS
Remarques supplémentaires :
Le calcul des décalages au fur et à mesure que le signal d'activité circule dans le système repose sur les horloges des systèmes source et cible à configurer correctement. Il est possible que le décalage soit négatif si le système cible est en avance sur le système source. Le décalage est affiché sous la forme d'un nombre négatif afin que vous soyez conscient de l'écart d'horloge et que vous puissiez prendre des mesures pour le corriger.
L'horodatage qui passe par le système est au format UTC. Aucun fuseau horaire n'est associé à l'horodatage. Ainsi, lors de l'affichage des tables de signal d'activité, le décalage peut être affiché rapidement même si différents composants se trouvent dans des fuseaux horaires différents. Vous pouvez écrire n'importe quelle vue que vous voulez sur les tables sous-jacentes ; UTC est recommandé.
Toutes les entrées de signal d'activité sont écrites dans la trace dans UTF-8.
Les chemins sortants et entrants déterminent une ligne de manière unique. Cela signifie que si vous avez deux lignes avec le même chemin sortant et un chemin entrant différent, il est considéré comme deux entrées uniques.
Détails de la table de signal d'activité
La table GG_HEARTBEAT affiche les informations d'horodatage de l'heure de réplication de bout en bout et les informations de synchronisation sur les différents composants, processus Extract et Replicat principal et secondaire.
Dans un environnement unidirectionnel, seule la base de données cible contient des informations sur le décalage de réplication. Il s'agit du moment où un enregistrement est généré dans la base de données source et devient visible par les clients de la base de données cible. Remarque : les tables de signal d'activité automatique ne remplissent pas les colonnes OUTGOING_% avec des données, lorsque les bases de données source et distante portent le même nom. Pour modifier le nom de la base de données, utilisez l'utilitaire DBNEWID. Pour en savoir plus, reportez-vous à l'utilitaire DBNEWID.
| Colonne | Type de données | Description |
|---|---|---|
LOCAL_DATABASE |
VARCHAR2 |
Base de données locale où le temps de réplication à partir de la base de données distante est mesuré. |
HEARTBEAT_TIMESTAMP |
TIMESTAMP(6) |
Point dans le temps où un horodatage est généré dans la base de données distante. |
REMOTE_DATABASE |
VARCHAR2 |
Base de données distante dans laquelle l'horodatage est généré |
INCOMING_EXTRACT |
VARCHAR2 |
Nom de l'extraction principale (capture) dans la base de données distante |
INCOMING_ROUTING_PATH |
VARCHAR2 |
Nom de l'extraction secondaire (pump) dans la base de données distante |
INCOMING_REPLICAT |
VARCHAR2 |
Nom du processus Replicat sur la base de données locale. |
INCOMING_HEARTBEAT_TS |
TIMESTAMP(6) |
Horodatage final lorsque les informations sont insérées dans la table GG_HEARTBEAT de la base de données locale. |
INCOMING_EXTRACT_TS |
TIMESTAMP(6) |
L'horodatage généré est traité par le processus Extract principal dans la base de données distante. |
INCOMING_ROUTING_TS |
TIMESTAMP(6) |
L'horodatage généré est traité par le processus Extract secondaire dans la base de données distante. |
INCOMING_REPLICAT_TS |
TIMESTAMP(6) |
L'horodatage généré est traité par le processus Replicat dans la base de données locale. |
OUTGOING_EXTRACT |
VARCHAR2 |
Réplication bidirectionnelle/N-way : nom de l'extraction principale sur la base de données locale. |
OUTGOING_ROUTING_PATH |
VARCHAR2 |
Réplication bidirectionnelle/N-way : nom de l'extraction secondaire sur la base de données locale. |
OUTGOING_REPLICAT |
VARCHAR2 |
Réplication bidirectionnelle/N-way : nom de la réplication sur la base de données distante. |
OUTGOING_HEARTBEAT_TS |
TIMESTAMP(6) |
Réplication bidirectionnelle/à sens unique : horodatage final lorsque les informations sont insérées dans la table de la base de données distante. |
OUTGOING_EXTRACT_TS |
TIMESTAMP(6) |
Réplication bidirectionnelle/à sens unique : l'horodatage de l'horodatage généré est traité par l'extraction principale sur la base de données locale. |
OUTGOING_ROUTING_TS |
TIMESTAMP(6) |
Réplication bidirectionnelle/à sens unique : l'horodatage de l'horodatage généré est traité par l'extraction secondaire sur la base de données locale. |
OUTGOING_REPLICAT_TS |
TIMESTAMP(6) |
Réplication bidirectionnelle/à sens unique : l'horodatage de l'horodatage généré est traité par le processus Replicat sur la base de données distante. |
INCOMING_REPLICAT_LW_CSN |
VARCHAR2 |
- |
INCOMING_EXTRACT_HEARTBEAT_CSN |
VARCHAR2 |
- |
INCOMING_EXTRACT_RESTART_CSN |
VARCHAR2 |
- |
INCOMING_EXTRACT_RESTART_TS |
TIMESTAMP(6) |
- |
La table GG_HEARTBEAT_HISTORY affiche les informations d'horodatage historique de l'heure de réplication de bout en bout et les informations de synchronisation sur les différents composants, processus Extract et Replicat principal et secondaire.
Dans un environnement unidirectionnel, seule la base de données de destination contient des informations sur le décalage de réplication.
Les horodatages sont gérés dans le fuseau horaire UTC. Il s'agit du moment où un enregistrement est généré dans la base de données source et devient visible par les clients de la base de données cible.
| Colonne | Type de données | Description |
|---|---|---|
LOCAL_DATABASE |
VARCHAR2 |
Base de données locale dans laquelle le décalage de bout en bout est mesuré. |
HEARTBEAT_RECEIVED_TS |
TIMESTAMP(6) |
Point dans le temps où un horodatage de la base de données distante est reçu dans la base de données locale. |
REMOTE_DATABASE |
VARCHAR2 |
Base de données distante dans laquelle l'horodatage est généré. |
INCOMING_EXTRACT |
VARCHAR2 |
Nom du processus Extract principal sur la base de données distante. |
INCOMING_ROUTING_PATH |
VARCHAR2 |
Nom de l'extraction secondaire de la base de données distante. |
INCOMING_REPLICAT |
VARCHAR2 |
Nom du processus Replicat sur la base de données locale. |
INCOMING_HEARTBEAT_TS |
TIMESTAMP(6) |
Horodatage final lorsque les informations sont insérées dans la table GG_HEARTBEAT_HISTORY de la base de données locale. |
INCOMING_EXTRACT_TS |
TIMESTAMP(6) |
Horodatage lorsque l'horodatage généré est traité par l'extraction principale sur la base de données distante. |
INCOMING_ROUTING_TS |
TIMESTAMP(6) |
Horodatage lorsque l'horodatage généré est traité par l'extraction secondaire sur la base de données distante. |
INCOMING_REPLICAT_TS |
TIMESTAMP(6) |
Horodatage lorsque l'horodatage généré est traité par le processus Replicat sur la base de données locale. |
OUTGOING_EXTRACT |
VARCHAR2 |
Réplication bidirectionnelle/N-way : nom de l'extraction principale à partir de la base de données locale. |
OUTGOING_ROUTING_PATH |
VARCHAR2 |
Réplication bidirectionnelle/N-way : nom de l'extraction secondaire à partir de la base de données locale. |
OUTGOING_REPLICAT |
VARCHAR2 |
Réplication bidirectionnelle/N-way : nom de la réplication sur la base de données distante. |
OUTGOING_HEARTBEAT_TS |
TIMESTAMP(6) |
Réplication bidirectionnelle/N-way : horodatage final lorsque les informations sont insérées de manière persistante dans la table de la base de données distante. |
OUTGOING_EXTRACT_TS |
TIMESTAMP(6) |
Réplication bidirectionnelle/à sens unique : horodatage lorsque l'horodatage généré est traité par l'extraction principale sur la base de données locale. |
OUTGOING_ROUTING_TS |
TIMESTAMP(6) |
Réplication bidirectionnelle/à sens unique : horodatage lorsque l'horodatage généré est traité par l'extraction secondaire sur la base de données locale. |
OUTGOING_REPLICAT_TS |
TIMESTAMP(6) |
Réplication bidirectionnelle/à sens unique : horodatage lorsque l'horodatage généré est traité par le processus Replicat sur la base de données distante. |
REPLICAT_LOW_WATERMARK_CSN |
String |
Cette colonne est renseignée par le processus Replicat lorsqu'il traite cet enregistrement de signal d'activité. Elle remplit cette colonne avec son filigrane bas actuel (LWM) lorsqu'elle traite cet enregistrement. Cela nous permet de choisir un LOGBSN à partir d'un enregistrement de signal d'activité qui est à partir du LWM de réplication. |
SOURCE_EXTRACT_HEARTBEAT_CSN |
String |
Cette colonne est renseignée par le processus Extract et contient le SCN de validation source pour la transaction de signal d'activité dans la base de données source. Le travail de signal d'activité de la base de données source ne peut pas renseigner cette valeur car il ne connaîtra pas le SCN de validation apriori. |
SOURCE_EXTRACT_RESTART_CSN |
String |
Cette colonne sera renseignée par l'extraction et contiendra le LOGBSN actuel lorsque l'extraction traitera cet enregistrement de signal d'activité particulier. Le travail de signal d'activité de la base de données source ne renseigne pas cette valeur. |
SOURCE_EXTRACT_RESTART_CSN_TS |
TIMESTAMP |
Cette colonne sera renseignée par le processus Extract et contiendra l'horodatage des informations de journalisation au format UTC qui correspond au LOGBSN actuel lorsque le processus Extract traitera cet enregistrement de signal d'activité particulier. Le travail de signal d'activité de la base de données source ne renseigne pas cette valeur. |
La vue GG_LAG affiche des informations sur le décalage de réplication entre les bases de données locales et distantes.
Dans un environnement unidirectionnel, seule la base de données de destination contient des informations sur le décalage de réplication. Le décalage est mesuré en secondes.
| Colonne | Type de données | Description |
|---|---|---|
LOCAL_DATABASE |
VARCHAR2 |
Base de données locale où le décalage de réplication de bout en bout à partir de la base de données distante est mesuré. |
CURRENT_LOCAL_TS |
TIMESTAMP(6) |
Horodatage en cours de la base de données locale. |
REMOTE_DATABASE |
VARCHAR2 |
Base de données distante dans laquelle l'horodatage est généré. |
INCOMING_HEARTBEAT_AGE |
NUMBER |
Age du signal d'activité le plus récent reçu de la base de données distante. |
INCOMING_PATH |
VARCHAR2 |
Chemin de réplication de la base de données distante vers la base de données locale avec les composants Extract et Replicat. |
INCOMING_LAG |
NUMBER |
Délai de réplication entre la base de données distante et la base de données locale. Il s'agit de l'heure à laquelle le signal d'activité a été généré dans la base de données distante moins l'heure à laquelle les informations ont été insérées de manière persistante dans la table de la base de données locale. |
OUTGOING_HEARTBEAT_AGE |
NUMBER |
Age du signal d'activité le plus récent de la base de données locale à la base de données distante. |
OUTGOING_PATH |
VARCHAR2 |
Chemin de réplication de la base de données locale vers la base de données distante avec les composants Extract et Replicat |
OUTGOING_LAG |
NUMBER |
Décalage de réplication entre la base de données locale et la base de données distante. Il s'agit de l'heure à laquelle le signal d'activité a été généré dans la base de données locale moins l'heure à laquelle les informations ont été insérées de manière persistante dans la table de la base de données distante. |
REMOTE_EXTRACT_RESTART_CSN |
String |
Position de redémarrage de l'extraction source. |
REMOTE_DATABASE DB_UNIQUE_NAME |
String |
Le nom unique de la base de données distante apparaît. Si aucun nom unique n'existe, la valeur DB_NAME est affichée. |
REMOTE_EXTRACT_RESTART_CSN_TIME |
Timestamp |
Horodatage associé à la position des informations de journalisation Extract source. |
REMOTE_DB_OLDEST_OPEN_TXN_AGE |
Timestamp |
Ancienneté de la transaction ouverte la plus ancienne dans la base de données source en cours de traitement par Extract. Cette colonne peut être calculée comme suit : SYSTIMESTAMP - REMOTE_EXTRACT_RESTART_TIME. |
LOCAL_REPLICAT_LWM_CSN |
String |
CSN de filigrane faible de la réplication locale lors du traitement du signal d'activité. |
La vue GG_LAG_HISTORY affiche les informations d'historique sur l'historique des décalages de réplication entre les bases de données locales et distantes.
Dans un environnement unidirectionnel, seule la base de données de destination contient des informations sur le décalage de réplication.
L'unité des unités de décalage est en secondes.
| Colonne | Type de données | Description |
|---|---|---|
LOCAL_DATABASE |
VARCHAR2 |
Base de données locale où le décalage de réplication de bout en bout à partir de la base de données distante est mesuré. |
HEARTBEAT_RECEIVED_TS |
TIMESTAMP(6) |
Point dans le temps où un horodatage de la base de données distante est reçu sur la base de données locale. |
REMOTE_DATABASE |
VARCHAR2 |
Base de données distante dans laquelle l'horodatage est généré. |
DB_NAME |
Chaîne | Nom de la base de données distante. |
DB_UNIQUE_NAME |
Chaîne | Nom unique de la base de données distante. Si le nom unique de la base de données n'existe pas, DB_NAMEet DB_UNIQUE_NAME seront identiques. Dans un scénario de permutation vers la base de données de secours, db_unique_name est modifié, mais db_name et le chemin de réplication restent identiques. |
INCOMING_HEARTBEAT_AGE |
NUMBER |
L'âge de la table des battements de coeur. |
INCOMING_PATH |
VARCHAR2 |
Chemin de réplication de la base de données distante vers la base de données locale avec les composants Extract et Replicat. |
INCOMING_LAG |
NUMBER |
Délai de réplication entre la base de données distante et la base de données locale. Il s'agit de l'heure à laquelle le signal d'activité a été généré dans la base de données distante moins l'heure à laquelle les informations ont été insérées de manière persistante dans la table de la base de données locale. |
OUTGOING_HEARTBEAT_AGE |
NUMBER |
|
OUTGOING_PATH |
VARCHAR2 |
Chemin de réplication de la base de données locale vers la base de données distante avec les composants Extract et Replicat. |
OUTGOING_LAG |
NUMBER |
Décalage de réplication entre la base de données locale et la base de données distante. Il s'agit de l'heure à laquelle le signal d'activité a été généré dans la base de données locale moins l'heure à laquelle les informations ont été insérées de manière persistante dans la table de la base de données distante. |
REMOTE_EXTRACT_RESTART_CSN |
String |
Position de redémarrage de l'extraction source. |
REMOTE_EXTRACT_RESTART_CSN_TIME |
TIMESTAMP |
Horodatage associé à la position des informations de journalisation Extract source. |
REMOTE_DB_OLDEST_OPEN_TXN_AGE |
TIMESTAMP |
Ancienneté de la transaction ouverte la plus ancienne dans la base de données source en cours de traitement par le processus Extract. Cette colonne peut être calculée comme suit : SYSTIMESTAMP - REMOTE_EXTRACT_RESTART_TIME |
LOCAL_REPLICAT_LWM_CSN |
String |
CSN de filigrane faible de la réplication locale lors du traitement du signal d'activité. |
INCOMING_EXTRACT_LAG |
- | - |
INCOMING_ROUTINE_LAG |
- | - |
INCOMING_REPLICAT_READ_LAG |
- | - |
INCOMING_REPICAT_LAG |
- | - |
OUTGOING_EXTRACT_LAG |
- | - |
OUTGOING_ROUTINE_LAG |
- | - |
OUTGOING_REPLICAT_READ_LAG |
- | - |
OUTGOING_REPLICAT_LAG |
- | - |
Tables de mise à jour du signal d'activité
La colonne HEARTBEAT_TIMESTAMP de la table d'origine du signal d'activité doit être mise à jour régulièrement par un travail de base de données. L'intervalle de signal d'activité par défaut est de 1 minute et cet intervalle peut être spécifié ou remplacé à l'aide de la ligne de commande ou de l'interface Web du service d'administration.
Pour Oracle AI Database, le travail de base de données est créé automatiquement.
Pour PostgreSQL, vous pouvez configurer une tâche automatisée pour mettre à jour la table de signal d'activité. Reportez-vous à Configuration de la tâche d'automatisation pour mettre à jour la table de signal d'activité pour PostgreSQL.
Pour toutes les autres bases de données prises en charge, vous devez créer des travaux en arrière-plan pour mettre à jour l'horodatage du signal d'activité à l'aide de la fonctionnalité de planificateur propre à la base de données.
Pour plus d'informations sur la mise à jour de la table de signal d'activité, reportez-vous à [ADD HEARTBEATTABLE](/pls/topic/lookup?ctx=en/database/goldengate/core/26/coredoc&id=GCLIR-GUID-126E30A2-DC7A-4C93-93EC-0EB8BA7C13CB) et à [ALTER HEARTBEATTABLE](/pls/topic/lookup?ctx=en/database/goldengate/core/26/coredoc&id=GCLIR-GUID-08BC29F9-8A5D-4AD9-B355-528A270EECC8).
Configuration de la tâche d'automatisation pour la mise à jour de la table de signal d'activité pour PostgreSQL
L'interface Web d'Oracle GoldenGate pour PostgreSQL fournit la fonctionnalité permettant de créer un travail cron pour la mise à jour périodique de la table de signal d'activité.
Pour créer cette tâche à partir de l'interface Web, procédez comme suit :
-
Dans le panneau de navigation de gauche, développez Tâches et sélectionnez l'option Mettre à jour les tâches de signal d'activité.
\
\
-
Cliquez sur le signe plus sur la page Mettre à jour les tâches de signal d'activité. La boîte de dialogue Créer une nouvelle tâche de signal d'activité s'affiche.\
-
Indiquez les valeurs suivantes dans la boîte de dialogue, puis cliquez sur Soumettre :
-
Nom : indiquez le nom de la tâche.
-
Domaine d'informations d'identification : sélectionnez le nom de domaine dans la liste déroulante.
-
Alias d'informations d'identification : sélectionnez l'alias d'informations d'identification de l'instance de base de données PostgreSQL pour laquelle vous créez la tâche de mise à jour du signal d'activité.
-
Intervalle de fréquence : spécifiez l'intervalle de fréquence pour l'exécution de la tâche de mise à jour. La valeur minimale est 60 (valeur par défaut) et la valeur maximale peut être définie sur 7999.
-
Pour modifier ou supprimer une tâche Mettre à jour le signal d'activité, procédez comme suit : 1. Dans le panneau de navigation de gauche de l'interface du service d'administration, sélectionnez Tâches.
-
Cliquez sur Mettre à jour les tâches de signal d'activité. La liste des tâches de mise à jour du signal d'activité existantes s'affiche.
-
Dans la colonne Actions, cliquez sur l'icône de crayon. La boîte de dialogue Modifier la tâche de mise à jour du signal d'activité apparaît.
-
Vous pouvez modifier ou modifier le domaine d'informations d'identification, l'alias ou l'intervalle de fréquence, puis cliquer sur Soumettre. La tâche de mise à jour du signal d'activité modifiée est répertoriée sur la page Mettre à jour les tâches de signal d'activité.
-
Pour supprimer une tâche, cliquez sur l'icône Supprimer dans la colonne Actions de la tâche. Pour confirmer la suppression, cliquez sur OK.
Purger les tables d'historique des signaux d'activité
La table d'historique des signaux d'activité est purgée régulièrement à l'aide d'un travail. L'intervalle par défaut est de 30 jours et peut être spécifié ou remplacé à l'aide d'une interface de ligne de commande telle que Admin Client ou l'interface Web du service d'administration.
Pour Oracle AI Database, le travail de base de données est créé automatiquement.
Pour toutes les autres bases de données prises en charge, vous devez créer des travaux en arrière-plan pour purger la table d'historique des signaux d'activité à l'aide de la fonctionnalité de planificateur propre à la base de données.
Meilleure pratique
Oracle recommande d'effectuer les opérations suivantes :
-
Utilisez la même fréquence de pulsation sur toutes les bases de données pour faciliter le diagnostic.
-
Ajustez la période de conservation en cas de problème d'espace.
-
Conservez la fréquence par défaut de la table de signal d'activité. La fréquence définie sur 30 à 60 secondes donne les meilleurs résultats pour la plupart des charges globales.
-
Utilisez les statistiques d'historique de décalage pour collecter les informations de décalage et d'âge.
Utilisation des commandes de signal d'activité automatique
Vous pouvez utiliser les commandes de table de signaux d'activité pour contrôler la fonctionnalité de signaux d'activité automatique Oracle GoldenGate comme suit.
| Commande | Description |
|---|---|
ADD HEARTBEATTABLE |
Crée les tables de signal d'activité requises pour la fonctionnalité de signal d'activité automatique, y compris les colonnes LOGBSN. |
ALTER HEARTBEATTABLE |
Modifie les objets de signal d'activité existants. |
ALTER HEARTBEATTABLE UPGRADE |
Modifie les tables de signal d'activité pour ajouter les colonnes LOGBSN aux tables de signal d'activité. Cette option est facultative. |
DELETE HEARTBEATTABLE |
Supprime les objets de signal d'activité existants. |
DELETE HEARTBEATENTRY |
Supprime des entrées dans la table de signal d'activité. |
INFO HEARTBEATTABLE |
Affiche les informations de la table de signal d'activité. |
Décalage de reporting
Les rapports de décalage sont accessibles à partir du service d'administration. Vous pouvez configurer une tâche de rapport de décalage pour générer automatiquement des rapports de décalage pour une certaine durée et émettre des avertissements si la valeur de décalage dépasse le seuil spécifié. Pour configurer une tâche automatisée de génération de rapports de décalage : 1. Dans le panneau de navigation de gauche du service d'administration, cliquez sur Tâches et sélectionnez Rapport de décalage.
-
La colonne Action contient toutes les options permettant de supprimer, de modifier, d'actualiser et d'afficher les détails de la tâche de rapport de décalage.
-
Sélectionnez l'option requise.
-
Si vous sélectionnez l'option Modifier la tâche, les options permettant de modifier le rapport de décalage s'affichent. Les options proposées sont les suivantes :
-
Activé : permet de continuer le traitement de la tâche de rapport de décalage.
-
Vérifier toutes les (en minutes) : pour définir un intervalle de temps pour vérifier le rapport de décalage.
-
Rapport : Pour générer automatiquement un rapport de décalage si le seuil spécifié est dépassé. Vous pouvez spécifier la valeur de seuil dans le champ Si dépasse.
-
Si dépasse : pour spécifier un seuil après lequel un avertissement doit être lancé. La valeur peut être secondes, minutes ou heures.
-
Avertissement : permet de générer un avertissement si le seuil de décalage dépasse le seuil spécifié.
-
Lorsque dépasse : seuil de décalage après lequel l'avertissement est déclenché.
-
-
Cliquez sur Soumettre.
Identifier le décalage dans Replicat
Pour identifier le décalage dans le processus Replicat et modifier les colonnes d'une table :
-
Suspendez l'activité sur la base de données source pour toutes les tables liées à Oracle GoldenGate.
-
Démarrez le client Admin.
-
Exécutez cette commande pour le groupe Replicat :
INFO REPLICAT *group*-
Sur la ligne
Checkpoint Lag, vérifiez s'il existe un décalage Replicat. Si nécessaire, continuez à émettreINFO REPLICATjusqu'à ce que le décalage soit égal à zéro, ce qui indique que toutes les données de la trace ont été traitées. -
Arrêtez le groupe Replicat.
STOP REPLICAT *group*-
Apportez les modifications de table aux bases de données cible.
-
Démarrez le processus Replicat.
START REPLICAT *group*- Autoriser l'activité utilisateur à reprendre sur toutes les tables source liées à Oracle GoldenGate.