ADD HEARTBEATTABLE

Valide pour toutes les bases de données prises en charge. Pour plus de détails sur les bases de données prises en charge, reportez-vous à la matrice de certification.

Cette commande requiert une connexion à une base de données à l'aide de DBLOGIN.

La commande ADD HEARTBEATTABLE permet de créer les objets nécessaires à l'utilisation de la fonctionnalité d'activité automatique. Elle exécute les tâches suivantes :

Remarque : les objets de table de signal d'activité ne doivent jamais être créés dans la base de données Conteneur racine d'une base de données Oracle Multitenant.

Les noms par défaut des tables prédéfinie, de signaux d'activité et d'historique sont respectivement GG_HEARTBEAT_SEED, GG_HEARTBEAT et GG_HEARTBEAT_HISTORY.

Dans l'architecture des microservices, le schéma est configuré à l'aide de Paramètres de réplication.

Pour Db2 LUW, vous devez définir la propriété DB2_ATS_ENABLE avec la commande db2set DB2_ATS_ENABLE=yes.

Pour Db2 for i, afin d'effectuer une mise à niveau ou une configuration incorrecte de la fonctionnalité des tables de signal d'activité, vous pouvez exécuter de nouveau la commande ADD HEARTBEATTABLE, qui réparera la fonctionnalité d'une configuration de table de signaux d'activité existante sans supprimer les données de signal d' activité existantes.

Pour Db2 for i, le programme sous licence, 5770SS1 Option 39 International Components for Unicode, doit être installé.

Pour DB2 for i, la table de signal d'activité doit être consignée dans le même journal que les objets répliqués dans l'extraction à l'aide de cette table. Dans le cas contraire, l'extraction prend anormalement fin et le système indique que plusieurs journaux sont disponibles. De plus, la table de signal d'activité ne peut pas être activée pour une autre extraction de l'installation Oracle GoldenGate spécifique qui ne lit pas le même journal.

Pour Amazon Aurora MySQL, la variable globale event_scheduler doit être activée dans le groupe d'options car Amazon RDS n'autorise pas la définition des variables globales. Lorsque la base de données est redémarrée, event_scheduler revient à être désactivé. Pour éviter cette situation, activez event_scheduler dans le fichier my.cnf/ini.

Pour PostgreSQL, un travail système doit être créé manuellement pour appeler régulièrement la fonction gg_hb_job_run de purge d'enregistrement d'historique et d'enregistrement de mise à jour d'enregistrement de rythme. Par exemple, vous pouvez créer un travail Cron exécuté toutes les minutes. La fonction vérifiera les paramètres effectifs de fréquence de purge et de mise à jour d'enregistrement de signal d'activité de la configuration de signal d'activité, et traitera uniquement les opérations qui respectent les limites :

PGPASSWORD="$passwd" psql -U gguser -d dbname -h dbhostname -p dbport# -c "select <ggschema.gg_hb_job_run();" >/dev/null 2>&1

Pour Azure SQL Database, seule la commandeADD HEARTBEATTABLE TARGETONLY est prise en charge. En outre, étant donnée qu'il n'existe aucun agent SQL Server avec Azure SQL Database, la routine de purge ne peut pas être créée. Les utilisateurs doivent donc exécuter régulièrement la procédure stockée GG_PURGE_HB_TAB pour enlever les anciens enregistrements d'activité.

Syntaxe

ADD HEARTBEATTABLE
[, FREQUENCY number_in_seconds]
[, RETENTION_TIME number_in_days] |
[, PURGE_FREQUENCY number_in_days]
[, PARTITIONED]
[, TARGETONLY]

FREQUENCY number_in_seconds

Indique la fréquence à laquelle les enregistrements de signal d'activité sont générés. La valeur par défaut est 60 secondes.

Tenez compte des limites suivantes :

RETENTION_TIME number_in_days

Indique que les entrées de signal d'activité dépassant la durée de conservation dans la table d'historique de signal d'activité sont purgées. La valeur par défaut est de 30 jours.

Pour toutes les bases de données, la valeur minimale est 1 et la valeur maximale est 2 147 483 646.

PURGE_FREQUENCY number_in_days

Indique la fréquence à laquelle la fonction de programmation de purge est exécutée pour supprimer de la table d'historique de signal d'activité les entrées de table dépassant la durée de conservation. Valeur par défaut : 1 jour.

Pour DB2 LUW et DB2 z/OS, la valeur minimale est 1 et la valeur maximale est 31.

Pour toutes les autres bases de données prises en charge, la valeur minimale est 1 et la valeur maximale est 199.

PARTITIONED

Valide pour Oracle.

Active le partitionnement sur la table d'historique de signal d'activité. La colonne de l'horodatage de signal d'activité reçu est utilisée pour partitionner la table avec un intervalle d'un jour. Par défaut, la table d'historique de signal d'activité n'est pas partitionnée.

TARGETONLY

Valide pour Oracle AI Database, Db2 série i, Db2 LUW, Db2 z/OS, MySQL, PostgreSQL et SQL Server.

N'active pas la journalisation supplémentaire sur la table prédéfinie de signal d'activité ni sur la table de signal d'activité. Ne crée pas de travail de fonction de programmation pour la mise à jour de la table de signal d'activité.

Exemples

La commande suivante crée les travaux, les procédures et les tables de signal d'activité par défaut.

ADD HEARTBEATTABLE

La commande suivante crée les travaux, les procédures et les tables de signal d'activité avec une fréquence, une durée de conservation et une fréquence de purge personnalisées.

ADD HEARTBEATTABLE, FREQUENCY 120, RETENTION_TIME 10, PURGE_FREQUENCY 2

La commande suivante crée les travaux, les procédures et les tables de signal d'activité avec le partitionnement activé dans la table d'historique de signal d'activité et la journalisation supplémentaire non activée dans la table prédéfinie de signal d'activité et la table de signal d'activité.

ADD HEARTBEATTABLE, partitioned, TARGETONLY