Opérations prises en charge avec l'évolution automatique des schémas

L'évolution automatique des schémas est prise en charge sur les cibles Oracle, MySQL, PostgreSQL, SQL Server, Db2 LUW, DB2400, Teradata et Oracle TimesTen.

L'évolution automatique des schémas est prise en charge sur les sources Oracle, MySQL, PostgreSQL, SQL Server, Db2 LUW, Db2 zOS, DB2400, Sybase, Teradata, Oracle TimesTen et Snowflake.

Les opérations prises en charge sont les suivantes :

La réponse d'évolution automatique de schéma par défaut peut être remplacée à l'aide de AUTOSCHEMAOPTIONS. Les options suivantes sont prises en charge :
- TYPEMAP : cette option permet de remplacer la correspondance de type de données par défaut
- IGNORE_DATA_TRUNCATION : si le mapping de type de données par défaut prévoit une éventuelle troncation des données, le processus Replicat s'interrompt avec l'erreur appropriée par défaut. Pour ignorer ces erreurs de troncation de données et permettre à la réplication de continuer sans abandonner, vous pouvez indiquer AUTOSCHEMAOPTIONS IGNORE_DATA_TRUNCATION dans le fichier de paramètres de réplication.
- IGNORE_MODIFY_KEY_COLUMN : par défaut, l'évolution automatique des schémas ne permet pas de modifier les colonnes de clé primaire et l'abandon du processus Replicat entraîne une erreur appropriée. Vous pouvez indiquer AUTOSCHEMAOPTIONS IGNORE_MODIFY_KEY_COLUMN pour ignorer les modifications apportées aux colonnes de clé.
- ALLOW_MODIFY_KEY_COLUMN : par défaut, l'évolution automatique des schémas ne permet pas de modifier les colonnes de clé primaire et le processus Replicat s'interrompt dans ce cas. Vous pouvez indiquer AUTOSCHEMAOPTIONS ALLOW_MODIFY_KEY_COLUMN pour autoriser toute modification des colonnes de clé.
- MODIFY_COLUMN_NULLABILITY_ONLY : vous pouvez indiquer AUTOSCHEMAOPTIONS MODIFY_COLUMN_NULLABILITY_ONLY s'ils souhaitent uniquement modifier la capacité d'annulation de la colonne et non la modification de type.

L'évolution automatique des schémas prend en charge les opérations suivantes en fonction des modifications de schéma, détectées à partir des enregistrements de métadonnées dans les fichiers trace pour conserver la synchronisation du schéma de la source et des tables cible :

Création de la table manquante sur la base de données cible
Modification de la table cible en exécutant les colonnes ADD/MODIFY/DROP

En fonction des métadonnées de chaque colonne source, le type de données le mieux adapté est choisi par défaut pour la colonne cible correspondante.

REMARQUE : Vérifiez les mappages de type de données par défaut applicables pour le scénario de réplication de base de données source spécifique à la base de données cible à partir de Mappage de type de données avant d'implémenter l'évolution automatique des schémas.

Dans tous les cas, les types de données cible peuvent être différents du type de données source. Dans la mesure du possible, le choix du type de données cible est fait de telle sorte que le type cible soit toujours compatible et suffisamment grand (avec la même taille que la colonne source ou plus large) pour pouvoir prendre en charge les données de la colonne source correspondante. Dans certains cas où aucun type approprié n'est disponible pour le type de données de colonne source correspondant sur la base de données cible (comme les types disponibles sur la base de données cible peuvent entraîner la troncation des données), une erreur est renvoyée à l'utilisateur avec une recommandation appropriée.

Créer la table manquante

AutoSchema prend en charge les cas d'utilisation suivants :

Créez la table manquante sur la cible lors de l'application des données de trace générées par l'extraction CDC.
Créez la table manquante sur la cible lors de l'application des données de trace générées par le processus Extract de chargement initial.
Lors de l'application de la trace générée par le processus d'extraction initialLoad uniquement, vous pouvez choisir de supprimer la table cible existante et de créer une autre extraction en indiquant OPTYPE RECREATE dans le cadre des critères d'inclusion DDL AUTOSCHEMA.
Si toutes les colonnes de clé source correspondantes des métadonnées de trace ne peuvent pas avoir la valeur NULL, Automatic Schema crée la table cible avec une clause PRIMARY KEY avec toutes les colonnes correspondantes.
Si l'une des colonnes de clé source correspondantes, issues des métadonnées de trace, peut avoir la valeur NULL, Automatic Schema crée la table cible avec une clause UNIQUE KEY avec toutes les colonnes correspondantes.

Modification de la table existante

Si des colonnes sont ajoutées, supprimées ou modifiées sur la source, les instructions LDD ALTER TABLE correspondantes sont générées et exécutées sur les tables cible mises en correspondance correspondantes. Le schéma automatique prend en charge les modifications liées uniquement au type (y compris le nom du type de données, la longueur, la précision et l'échelle, le cas échéant) et à la contrainte de nullité. Toutefois, elle n'honore aucune modification apportée aux autres attributs de colonne. Si des modifications de schéma liées au type/à la capacité nulle sont détectées sur les colonnes source, elles sont propagées sur les colonnes cible.

Une ou plusieurs modifications de schéma sur la table source peuvent entraîner l'utilisation d'instructions LDD ALTER TABLE uniques ou multiples sur les tables cible mises en correspondance, comme cela est pris en charge sur la base de données cible spécifique. Le nombre d'instructions LDD sur la cible dépend de la syntaxe prise en charge sur une base de données cible spécifique, par exemple dans les cas suivants :

Peu de bases de données n'autorisent pas l'ajout/la suppression/la modification de plusieurs colonnes dans un seul élément ALTER TABLE DDL.
Peu de bases de données ne permettent pas de modifier à la fois le type et la nullabilité des colonnes dans une instruction ALTER TABLE DDL unique.

Dans ce cas, le nombre requis d'instructions ALTER TABLE DDL est exécuté sur la table cible, en fonction des exigences de la base de données cible.

Il est possible que le schéma automatique ait un impact sur la base de données cible nécessitant une action supplémentaire. Par exemple, si une valeur ALTER TABLE MODIFY COLUMN peut entraîner une certaine troncation des données, différentes bases de données peuvent le gérer de différentes manières. Une base de données peut détecter que certaines données existantes peuvent être tronquées par l'opération et provoquer l'arrêt de la réplication, ce qui se produit généralement entre Oracle et MySQL, lorsque MySQL est exécuté avec le mode strict activé. Toutefois, si MySQL est configuré en mode non strict, la traction peut se produire sans avertissement.

Pour IBM i, selon la configuration du système, le processus Replicat peut sembler se bloquer. Pour certaines actions sur Db2 (anciennement Db2 LUW) et Db2 z/OS, certaines actions peuvent nécessiter une réorganisation des tables. Sur Db2 z/OS, une colonne de suppression ne sera pas reconnue tant qu'une réorganisation n'aura pas été effectuée. Pour Db2, la table pourrait se retrouver dans un état de réorganisation en attente et cesser d'autoriser d'autres opérations sur celle-ci.

REMARQUE : Si nécessaire, vous pouvez ajouter sélectivement OPTYPE ADDCOLUMN, OPTYPE DROPCOLUMN et OPTYPE MODIFYCOLUMN aux critères d'inclusion/exclusion DDL AUTOSCHEMA.