Openflow Connector for Oracle : Maintenance

Note

Ce connecteur est soumis aux conditions d’utilisation de Snowflake Connector.

Note

L’Openflow Connector for Oracle est également soumis à des conditions de service supplémentaires en plus des conditions de service standard du connecteur. Pour plus d’informations, consultez le Complément du connecteur Openflow pour Oracle.

Cette rubrique décrit les tâches de maintenance pour l’Openflow Connector for Oracle, comme la réinstallation du connecteur ou la définition de la position de départ du journal redo.

Ces opérations sont souvent utilisées conjointement avec la réplication incrémentielle avec instantanés.

Réinstaller le connecteur

Cette rubrique fournit des instructions sur la manière de réinstaller le connecteur et de continuer à répliquer les données pour les mêmes tables sans avoir à créer de nouveaux instantanés de celles-ci. Elle couvre les situations où le nouveau connecteur est installé dans le même environnement d’exécution, ainsi que déplacé vers un nouvel environnement d’exécution.

Avertissement

Pour que le connecteur continue la réplication à partir de la même position du flux CDC où il s’est arrêté avant la réinstallation, la base de données source doit conserver le journal redo archivé suffisamment longtemps pour couvrir la période écoulée après l’arrêt du connecteur précédent et avant le démarrage du nouveau connecteur. Assurez-vous que la période de conservation du journal redo archivé de la base de données Oracle est suffisamment longue et réduisez au minimum le temps nécessaire à la réinstallation.

En règle générale, une période de conservation de 24 heures est suffisante, mais des délais plus longs peuvent être appropriés pour assurer le temps nécessaire à la réinstallation. Pour plus d’informations sur la configuration de la conservation du journal redo archivé, consultez Openflow Connector for Oracle : Configurer la base de données Oracle.

Conditions préalables

Examinez et notez les valeurs contextuelles des paramètres du connecteur. Si vous réinstallez le connecteur dans le même environnement d’exécution, vous pouvez réutiliser le contexte existant. Si la nouvelle instance se trouve dans un environnement d’exécution différent, vous devez saisir à nouveau tous les paramètres.

  1. Terminez le traitement de tous les FlowFiles en cours dans le connecteur existant, puis arrêtez le connecteur.

    1. Connectez-vous à Snowsight.

    2. Dans le menu de navigation, sélectionnez Ingestion » Openflow.

    3. Sélectionnez Launch Openflow.

    4. Dans le volet Openflow, sélectionnez l’onglet Runtimes.

    5. Sélectionnez l’environnement d’exécution contenant le connecteur.

    6. Sélectionnez le connecteur.

    7. Arrêtez le processeur le plus élevé Set Tables for Replication dans le groupe Snapshot Load.

    8. Arrêtez le processeur le plus élevé Read Oracle CDC Stream dans le groupe Incremental Load.

    9. Si vous avez modifié la valeur du paramètre Merge Task Schedule CRON, rétablissez-le sur * * * * * ?. Sinon, les files d’attente ne seront pas vidées avant la prochaine exécution planifiée.

      Attendez que tous les FlowFiles du connecteur aient été traités et que toutes les files d’attente soient vides. Lorsque tous les FlowFiles ont été traités, la valeur Queued sur le groupe de processeurs du connecteur devient nulle. S’il reste des éléments dans les files d’attente du connecteur d’origine, des écarts de données peuvent se produire au démarrage du nouveau connecteur.

    10. Arrêtez tous les processeurs et tous les services de contrôleur dans le connecteur.

    Prudence

    Le connecteur existant peut rester dans l’environnement d’exécution et n’interfère pas avec la nouvelle instance, tant qu’il reste à l’arrêt.

  2. Créez une nouvelle instance du connecteur. Si vous utilisez le même environnement d’exécution que le connecteur d’origine, vous pouvez choisir de conserver les contextes de paramètres existants et de réutiliser les paramètres.

  3. Si vous procédez à une installation dans un environnement d’exécution différent, ou si vous avez supprimé les contextes de paramètres précédents, entrez les paramètres de configuration dans les nouveaux contextes de paramètres, y compris les noms et les modèles de tables, comme décrit dans Installer et configurer Openflow Connector for Oracle.

  4. Accédez au contexte Oracle Ingestion Parameters et définissez les paramètres suivants :

  5. Démarrez le nouveau connecteur.

Notes sur l’utilisation

Le nouveau connecteur utilise les tables de destination existantes qui ont été créées par le connecteur d’origine, mais le connecteur crée de nouvelles tables de journal.

Altérer le serveur sortant XStream

Le connecteur met régulièrement à jour le serveur XStream avec la dernière position SCN traitée. Si le connecteur est réinstallé et se connecte au même serveur sortant XStream, la lecture reprendra à partir de la position SCN où il s’est arrêté. Ce nombre SCN peut être vérifié avec :

SELECT PROCESSED_LOW_SCN
FROM DBA_XSTREAM_OUTBOUND_PROGRESS
WHERE SERVER_NAME = 'XOUT1';
Copy

Si vous souhaitez lire à nouveau des données à partir d’une position antérieure, vous devez d’abord modifier le SCN de départ du serveur XStream :

BEGIN
    DBMS_XSTREAM_ADM.ALTER_OUTBOUND(
        server_name => 'XOUT1',
        start_scn => <start_scn>
    );
END;
/
Copy

La valeur de <start_scn> doit être un SCN valide dans la plage des journaux redo disponibles. Le SCN le plus bas auquel la position de départ peut être réinitialisée peut être vérifié à l’aide de :

SELECT REQUIRED_CHECKPOINT_SCN
FROM DBA_CAPTURE
WHERE CLIENT_NAME = 'XOUT1';
Copy

Il s’agit du SCN le plus bas pour lequel le processus de capture nécessite des informations redo.

Spécifier la charge de la position XStream

Le connecteur Openflow Connector for Oracle vous permet de sélectionner la position de départ où les journaux redo Oracle sont lus. Par défaut, le connecteur lit à partir de la position la plus récente disponible. Vous pouvez également choisir la position la plus ancienne disponible sur l’instance source. Lors de la réinstallation du connecteur, il est courant de choisir de commencer par la position la plus ancienne. Cela permet à la nouvelle instance de rattraper son retard et de continuer à répliquer les tables existantes sans avoir à créer un nouvel instantané de chacune d’entre elles.

Note

Le fait de faire passer un connecteur en cours d’exécution de la position la plus récente à la position la plus ancienne entraîne la relecture, le retraitement et la ré-application de l’intégralité des journaux redo disponibles dans la table de destination.

Avertissement

Pendant la relecture des journaux redo, les colonnes et les données dans les tables de destination concernées peuvent être désynchronisées avec leurs sources, jusqu’à ce que tous les événements aient été retraités et fusionnés.

Les paramètres suivants sont disponibles dans le contexte Ingestion Parameters :

Paramètre

Description

Position XStream de départ

  • Latest (par défaut) : la lecture du flux CDC commence à la position la plus récente disponible et continue à partir de là.

  • Earliest : Active le chargement incrémentiel pour démarrer ou redémarrer la lecture à partir de la position XStream la plus ancienne disponible.

Relire les tables dans l’état

  • New (par défaut) : Lors de la relecture des journaux redo, seuls ces LCRs (enregistrements de modifications logiques) seront traités à partir des nouvelles tables ajoutées à la réplication après le début de la relecture. Les autres LCRs sont ignorés jusqu’à ce que le connecteur atteigne la position juste avant le début de la relecture.

  • Any active : Relisez et retraitez les événements de n’importe quelle table actuellement en réplication.

Pour déterminer si le connecteur a terminé la relecture des journaux redo, procédez comme suit :

  1. Accédez au canevas Openflow.

  2. Ouvrez le groupe de processus Incremental Load.

  3. Cliquez avec le bouton droit de la souris sur le processeur le plus élevé nommé Read Oracle CDC Stream, puis sélectionnez View state.

  4. Comparez les entrées d’état :

    • lcr.position.rewind : position la plus récente lue par le processeur avant le début de la relecture des journaux redo.

    • lcr.position.last : position la plus récente actuelle lue par le processeur. Tant que cette valeur est inférieure à la valeur de réinitialisation ci-dessus, le processeur continue de relire les journaux redo.

Notes sur l’utilisation

  • Une fois qu’un connecteur en cours d’exécution est activé pour lire à partir de la position la plus ancienne et démarre l’exécution, le processus ne peut pas être reconfiguré ou annulé, et il se poursuit jusqu’à ce que la position actuellement lue atteigne la position qui précédait son démarrage.

  • Le passage à la position la plus ancienne sur un connecteur en cours d’exécution entraîne, pour toutes les tables en cours de retraitement, la fin des journaux existants et la création de nouvelles tables de journal.

  • Si le journal redo contient des événements d’une table précédente qui a été détruite et recréée dans la base de données source, la relecture du flux traite à nouveau tous les événements dans la destination actuelle. Le connecteur ne peut pas faire la distinction entre une table source précédente et actuelle si elles partagent le même nom.