Gérer l'évolution des schémas

La gestion des schémas nécessite le suivi et la synchronisation des modifications structurelles telles que les tables, les colonnes, les index et les types de données entre les systèmes source et cible. Une technique efficace de gestion de schéma garantit que la réplication se poursuit sans heurt lorsque les applications évoluent ou que les modifications de base de données sont déployées. Elle permet également d'éviter les échecs causés par des structures non concordantes, des types de données non pris en charge ou des objets manquants.

Oracle GoldenGate fournit des techniques permettant de gérer les schémas pour une réplication de données homogène ou similaire et une réplication hétérogène ou interplateforme. Pour la réplication à domicile, les administrateurs peuvent utiliser la fonctionnalité existante de réplication LDD, qui est disponible avec les bases de données Oracle vers Oracle et MySQL vers MySQL.

Pour la réplication hétérogène, les administrateurs peuvent utiliser la fonctionnalité d'évolution automatique des schémas. L'évolution automatique des schémas dans Oracle GoldenGate fournit la validation des schémas, la détection des modifications, la mise en correspondance automatisée et le déploiement contrôlé des mises à jour de schéma. Cette fonctionnalité permet la réplication entre un large éventail de schémas de base de données source et cible hétérogènes.

Cibles prises en charge par le schéma automatique Oracle, MySQL, Amazon Aurora MySQL, Amazon RDS pour MySQL, Azure Database pour MySQL, MariaDB, SingleStoreDB, Google Cloud SQL pour MySQL, PostgreSQL, Amazon Aurora PostgreSQL, Amazon RDS pour PostgreSQL, YugabyteDB, EDB PostgreSQL Advanced Server, Azure Database pour PostgreSQL, Google Cloud SQL pour PostgreSQL, Microsoft SQL Server, Amazon RDS pour SQL Server, Azure SQL Database, IBM Db2 (LUW), IBM Db2 pour i, Teradata et TimesTen.

Sources prises en charge par le schéma automatique Oracle, MySQL, Amazon Aurora MySQL, Amazon RDS pour MySQL, Azure Database pour MySQL, MariaDB, SingleStoreDB, Google Cloud SQL pour MySQL, PostgreSQL, Amazon Aurora PostgreSQL, Amazon RDS pour PostgreSQL, YugabyteDB, EDB PostgreSQL Advanced Server, Azure Database pour PostgreSQL, Google Cloud SQL pour PostgreSQL, Microsoft SQL Server, Amazon RDS pour SQL Server, Azure SQL Database, Db2 (LUW), Db2 pour i, Db2 pour z/OS, Sybase et Snowflake.

Différences entre l'évolution automatique des schémas et la réplication LDD

Voici une comparaison entre l'évolution automatique des schémas et la gestion des schémas basée sur la réplication LDD :

Evolution automatique des schémas	Réplication DDL
Détecte automatiquement les différences de schéma et met à jour le schéma cible si nécessaire.	Réplique les instructions LDD réelles, telles que ALTER TABLE, CREATE TABLE ou DROP COLUMN, de la source vers la cible à l'aide d'opérations LDD et LMD.
Plus facile pour les utilisateurs, car de nombreuses modifications de schéma sont gérées sans intervention manuelle.	Requiert que le DDL source soit pris en charge et interprété correctement par le système de réplication.
Fonctionne au niveau logique ou de métadonnées	Fonctionne en capturant et en appliquant des commandes de modification de schéma de base de données.
Prend en charge uniquement les modifications de schéma sélectionnées, telles que l'ajout de colonnes, la création de la table manquante sur la base de données cible, la modification de la table cible en exécutant des colonnes ADD/MODIFY/DROP et la modification des types de données compatibles.	Peut conserver l'intention exacte des modifications de schéma côté source.
Utile lorsque les systèmes source et cible sont des plates-formes ou des services cloud différents.	Idéal lorsque les bases de données source et cible ont une syntaxe LDD et un comportement d'objet similaires.