À propos de Openflow Connector for Oracle¶

1. Licence intégrée (fournie par Snowflake)¶

Snowflake vous fournit directement la licence Oracle XStream moyennant des frais. Ce modèle vous permet d’utiliser la réplication XStream sans contrat direct avec Oracle. Pour plus d’informations, voir Détails de la licence intégrée et le Complément du connecteur Openflow pour Oracle.

2. Licence indépendante (Bring Your Own License - BYOL)¶

Vous fournissez votre propre licence Oracle qui inclut XStream (par exemple, licence Oracle GoldenGate). Pour plus d’informations, voir Détails relatifs aux licences indépendantes (BYOL).

Facturation¶

Les services Oracle XStream sont facturés mensuellement et prélevés sur votre solde de capacité Snowflake. Les frais comportent deux éléments : des frais de licence et des frais d’assistance et de maintenance (S&M). Les frais de licence sont calculés en fonction du nombre de cœurs de processeur dans votre base de données source Oracle, multipliés par le facteur de cœur de processeur Oracle.

Engagement (la règle du « 61e jour »)¶

Les 60 premiers jours sont gratuits pour un maximum de 16 cœurs sous licence. Toutefois, l’activation du connecteur au-delà de la période d’essai de 60 jours déclenche une période de facturation de 36 mois non résiliable (« Condition initiale »).

• Conversion automatique : La facturation commence automatiquement le jour 61. Pour éviter les frais, vous devez annuler l’essai dans le tableau de bord Admin » Terms » Openflow for Oracle avant le jour 60.

• Verrouillé : Si votre contrat Snowflake est résilié pendant cette période initiale, le solde restant dû pour la période initiale devient immédiatement exigible.

Renouvellement après la période initiale et pénalités¶

Après la période initiale, les frais de licence s’élèvent à 0 $, mais les frais d’assistance et de maintenance (S&M) sont toujours en vigueur.

• Conséquences de la désactivation : Vous pouvez désactiver le renouvellement S&M via le tableau de bord dans Admin » Terms » Openflow for Oracle. Toutefois, si la couverture S&M s’arrête, les processeurs du connecteur sont bloqués. Pour reprendre les opérations, vous devez acheter une NEW licence intégrée (réinitialisation de l’engagement de 36 mois à plein tarif).

Exigences¶

Vous êtes responsable de la déclaration précise du nombre de cœurs de processeur et du facteur de cœur correct dans la configuration du connecteur. Ces informations doivent être actualisées si le matériel de votre base de données source change.

Restrictions¶

Si cette option n’est pas disponible :

• Entités du secteur public (par exemple, entités gouvernementales et de l’éducation).

• Les clients qui achètent Snowflake via la marketplace GCP.

• Clients ayant conclu un contrat avec Snowflake via un revendeur tiers (par exemple ,CDW, Optiv).

Configuration¶

Pour configurer la licence intégrée :

• Vérifiez et acceptez les conditions du Complément du connecteur Openflow pour Oracle présentées dans l’UI.

• Sélectionnez le type de Embedded License.

• Saisissez les détails du nombre de cœurs de CPU pour votre base de données Oracle source : Nombre total de cœurs (le nombre total de cœurs physiques sur le serveur de la base de données source) et Facteur de cœur (le facteur de cœur de processeur Oracle, par exemple, 0,5 pour les processeurs Intel). Consultez la table des facteurs de base du processeur Oracle pour connaître la valeur correcte.

Exigences¶

Vous êtes seul responsable de vous assurer que votre utilisation du connecteur est conforme aux conditions de votre contrat de licence Oracle existant. Snowflake ne valide ni ne vérifie vos droits Oracle.

Configuration¶

Pour configurer la licence indépendante (BYOL) :

• Vérifiez et acceptez les conditions du Complément du connecteur Openflow pour Oracle présentées dans l’UI.

• Sélectionnez le type de Independent License.

Lors de la configuration du connecteur, procédez sans saisir le nombre de cœurs ni les informations relatives à la facturation.

Comment les tables sont-elles répliquées ?¶

Les tables sont répliquées dans les zones de préparation suivantes :

1. Introspection du schéma : le connecteur découvre les colonnes de la table source, y compris les noms et les types de colonnes, puis les valide par rapport aux limites de Snowflake et du connecteur. Les échecs de validation entraînent l’échec de cette préparation et le cycle s’achève. Les échecs de validation entraînent l’échec de cette phase et le cycle se terminera. Une fois cette zone de préparation correctement terminée, le connecteur crée une table de destination vide dans Snowflake.

2. Chargement d’un instantané : le connecteur copie toutes les données disponibles dans la table source dans la table de destination. Si cette zone de préparation échoue, plus aucune donnée n’est répliquée. Une fois l’opération réussie, les données de la table source sont disponibles dans la table de destination.

3. Chargement incrémentiel : le connecteur suit les modifications apportées à la table source et applique ces modifications à la table de destination. Ce processus se poursuit jusqu’à ce que la table soit retirée de la réplication. Ce processus se poursuit jusqu’à ce que la table soit retirée de la réplication. L’échec à ce stade arrête définitivement la réplication de la table source, jusqu’à ce que le problème soit résolu.

Statut de réplication de la table¶

Les défaillances intermédiaires, telles que les erreurs de connexion, n’empêchent pas la réplication de la table. Toutefois, les défaillances permanentes, telles que les types de données non pris en charge, empêchent la réplication de la table.

Pour résoudre les problèmes de réplication ou vérifier qu’une table a été correctement supprimée du flux de réplication, consultez le magasin d’états des tables (Table State Store) :

1. Dans le canevas de l’environnement d’exécution Openflow, cliquez avec le bouton droit de la souris sur un groupe de processeurs et choisissez Controller Services. Une table répertoriant les services du contrôleur s’affiche.

2. Localisez la ligne intitulée Table State Store, cliquez sur le bouton More sur le côté droit de la ligne, puis choisissez View State.

Une liste des tables et de leurs états actuels s’affiche. Renseignez le champ de recherche pour filtrer la liste par nom de table. Les états possibles sont :

• NEW : La table est planifiée pour la réplication, mais la réplication n’a pas commencé.

• SNAPSHOT_REPLICATION : Le connecteur copie des données existantes. Cet état s’affiche jusqu’à ce que tous les enregistrements soient stockés dans la table de destination.

• INCREMENTAL_REPLICATION : Le connecteur réplique activement les modifications. Cet état s’affiche après la fin de la réplication des instantanés et continue de s’afficher indéfiniment jusqu’à ce qu’une table soit supprimée de la réplication ou que la réplication échoue.

• FAILED : La réplication s’est définitivement arrêtée en raison d’une erreur.

Replication state for table <database_name>.<schema_name>.<table_name> changed from <old_state> to <new_state>

Si une défaillance permanente empêche la réplication d’une table, supprimez la table de la réplication. Après avoir résolu le problème à l’origine de l’échec, vous pouvez ajouter à nouveau la table à la réplication. Pour plus d’informations, consultez Redémarrer la réplication des tables.

Conservation des données¶

Colonnes de métadonnées de la table de destination¶

Chaque table de destination comprend les colonnes de métadonnées suivantes qui suivent les informations de réplication :

Lignes supprimées logiciellement¶

Lorsqu’une ligne est supprimée de la table source, le connecteur ne la supprime pas physiquement de la table de destination. Au lieu de cela, la ligne est marquée comme supprimée en définissant la colonne de métadonnées _SNOWFLAKE_DELETED sur true.

Cette approche vous permet de :

• Conserver les données historiques à des fins d’audit ou de conformité.

• Interroger les enregistrements supprimés lorsque cela est nécessaire.

• Décider quand et comment supprimer définitivement des données en fonction de vos besoins.

Pour interroger uniquement les lignes actives (non supprimées), filtrez sur la colonne _SNOWFLAKE_DELETED :

SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = FALSE;

Pour interroger les lignes supprimées :

SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = TRUE;

Colonnes supprimées¶

Lorsqu’une colonne est supprimée de la table source, le connecteur ne supprime pas la colonne correspondante de la table de destination. Au lieu de cela, la colonne est renommée en ajoutant le suffixe __SNOWFLAKE_DELETED pour préserver les valeurs historiques.

Par exemple, si une colonne nommée EMAIL est supprimée de la table source, elle est renommée en EMAIL__SNOWFLAKE_DELETED dans la table de destination. Les lignes qui existaient avant la suppression de la colonne conservent leurs valeurs d’origine, tandis que les lignes ajoutées après la suppression affichent NULL dans cette colonne.

Vous pouvez toujours interroger les valeurs historiques à partir de la colonne renommée :

SELECT EMAIL__SNOWFLAKE_DELETED FROM my_table;

Colonnes renommées¶

En raison de limitations dans les mécanismes CDC (Change Data Capture), le connecteur ne peut pas faire la distinction entre une colonne renommée et une colonne supprimée, suivie de l’ajout d’une nouvelle colonne. Par conséquent, lorsque vous renommez une colonne dans la table source, le connecteur traite cela comme deux opérations distinctes : supprimer la colonne d’origine et ajouter une nouvelle colonne avec le nouveau nom.

Par exemple, si vous renommez une colonne A en B dans la table source, la table de destination contiendra :

• A__SNOWFLAKE_DELETED : Contient les valeurs d’avant le changement de nom. Les lignes ajoutées après le changement de nom affichent NULL dans cette colonne.

• B : Contient les valeurs d’après le changement de nom. Les lignes qui existaient avant le changement de nom affichent NULL dans cette colonne.

SELECT
    COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;

SELECT
    CASE
        WHEN B IS NOT NULL THEN B
        ELSE A__SNOWFLAKE_DELETED
    END AS A_RENAMED_TO_B
FROM my_table;

CREATE VIEW my_table_unified AS
SELECT
    *,
    COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;

Tables de journal¶

Lors de la réplication incrémentielle, les modifications de la base de données source sont d’abord écrites dans les tables de journal avant d’être fusionnées dans les tables de destination. Le connecteur ne supprime pas automatiquement les données des tables de journal, car ces données peuvent être utiles à des fins d’audit, de débogage ou de retraitement.

Les tables de journal sont créées dans le même schéma que les tables de destination correspondantes et suivent cette convention de dénomination :

<TABLE_NAME>_JOURNAL_<timestamp>_<number>

Où :

• <TABLE_NAME> est le nom de la table de destination.

• <timestamp> est l’horodatage de création au format d’époque Unix (secondes depuis le 1er janvier 1970), garantissant l’unicité.

• <number> commence à 1 et incrémente chaque fois que le schéma de la table de destination change, soit en raison de modifications de schéma dans la table source, soit en raison de modifications des filtres de colonnes.

Par exemple, si votre table de destination est SALES.ORDERS, la table du journal peut être nommée SALES.ORDERS_JOURNAL_1705320000_1.