Migration de données, ETL et chargement pour les migrations Oracle
Cet article est le deuxième d’une série de sept, qui fournit des conseils sur la migration d’Oracle vers Azure Synapse Analytics. L’objectif de cet article sont les bonnes pratiques pour la migration concernant ETL et le chargement.
Considérations relatives à la migration des données
Il existe de nombreux facteurs à prendre en compte lorsque vous effectuez une migration de données avec ETL et chargements vers Azure Synapse à partir d’un entrepôt de données hérité Oracle et de datamarts.
Décisions initiales concernant la migration des données à partir d’Oracle
Lorsque vous planifiez une migration à partir d’un environnement Oracle existant, posez-vous les questions suivantes à propos des données :
Les structures de table inutilisées doivent-elle être migrées ?
Quelle est la meilleure approche de migration afin de réduire les risques et l’impact pour les utilisateurs ?
Lors de la migration de DataMarts, rester physique ou passer au virtuel ?
Les sections suivantes abordent ces questions dans le contexte d’une migration à partir d’Oracle.
Migrer les tables inutilisées ?
Il est logique de migrer uniquement les tables qui sont utilisées. Les tables qui ne sont pas actives peuvent être archivées au lieu d’être migrées afin que les données restent disponibles si nécessaire. Pour déterminer les tables encore utilisées, il est préférable de vous fier aux fichiers journaux et métadonnées système plutôt qu’à la documentation, car celle-ci peut être obsolète.
Les tables et journaux de catalogue système Oracle contiennent des informations qui peuvent être utilisées pour déterminer à quel moment une table donnée a été consultée pour la dernière fois, ce qui peut vous aider à déterminer si une table doit faire l’objet d’une migration.
Si vous avez une licence pour Oracle Diagnostic Pack, vous avez accès à l’historique des sessions actives, que vous pouvez utiliser pour déterminer à quel moment une table a été consultée pour la dernière fois.
Conseil
Dans les systèmes hérités, il n’est pas rare que les tables deviennent redondantes au fil du temps. Elles n’ont pas besoin d’être migrées dans la plupart des cas.
Voici un exemple de requête qui recherche si une table spécifique a été utilisée dans une période donnée :
SELECT du.username,
s.sql_text,
MAX(ash.sample_time) AS last_access ,
sp.object_owner ,
sp.object_name ,
sp.object_alias as aliased_as ,
sp.object_type ,
COUNT(*) AS access_count
FROM v$active_session_history ash
JOIN v$sql s ON ash.force_matching_signature = s.force_matching_signature
LEFT JOIN v$sql_plan sp ON s.sql_id = sp.sql_id
JOIN DBA_USERS du ON ash.user_id = du.USER_ID
WHERE ash.session_type = 'FOREGROUND'
AND ash.SQL_ID IS NOT NULL
AND sp.object_name IS NOT NULL
AND ash.user_id <> 0
GROUP BY du.username,
s.sql_text,
sp.object_owner,
sp.object_name,
sp.object_alias,
sp.object_type
ORDER BY 3 DESC;
Cette requête peut prendre un certain temps si vous avez exécuté de nombreuses requêtes.
Quelle est la meilleure approche de migration si l’on veut réduire les risques et l’impact pour les utilisateurs ?
Cette question se pose souvent, car les entreprises cherchent à réduire l’impact des changements sur le modèle de données de l’entrepôt de données afin de gagner en agilité. Les entreprises voient souvent une opportunité de moderniser ou de transformer davantage leurs données lors d’une migration ETL. Cette approche présente un risque plus élevé, car elle modifie plusieurs facteurs simultanément, ce qui rend difficile la comparaison des résultats de l’ancien système par rapport au nouveau. L’apport de modifications de modèle de données ici peut également affecter les travaux ETL en amont ou en aval à d’autres systèmes. Face à ce risque, il est préférable de reconcevoir à cette échelle après la migration de l’entrepôt de données.
Même si un modèle de données est intentionnellement modifié dans le cadre de la migration globale, il est préférable de migrer le modèle existant tel quel vers Azure Synapse, plutôt que de procéder à une réingénierie sur la nouvelle plateforme. Cette approche minimise l'effet sur les systèmes de production existants, tout en bénéficiant des performances et de l'évolutivité élastique de la plateforme Azure pour les tâches de réingénierie ponctuelles.
Conseil
Migrez le modèle existant tel quel initialement, même s’il est prévu de changer à l’avenir.
Migration des datamarts : rester physique ou passer au virtuel ?
Dans les environnements d’entrepôt de données Oracle hérités, il est courant de créer de nombreux datamarts structurés dans le but de fournir de bonnes performances pour les requêtes et les rapports libre-service ad hoc, pour un service ou une fonction commerciale donnés au sein d’une organisation. Un datamart se compose généralement d’un sous-ensemble de l’entrepôt de données qui contient des versions agrégées des données sous une forme qui permet aux utilisateurs de les interroger facilement avec des temps de réponse rapides. Les utilisateurs peuvent se servir d’outils de requête conviviaux comme Microsoft Power BI, qui prend en charge les interactions utilisateurs professionnelles avec des datamarts. Dans un datamart, les données prennent généralement la forme d’un modèle de données dimensionnelles. Les datamarts peuvent servir à exposer les données sous une forme utilisable, même si le modèle de données de l’entrepôt sous-jacent est différent, par exemple, un coffre de données.
Vous pouvez utiliser des mini-Data Warehouses distincts pour les différentes unités métier au sein d’une organisation afin d’implémenter des régimes de sécurité des données robustes. Autorisez uniquement les utilisateurs concernés à accéder aux datamarts, et éliminez, masquez ou anonymisez les données sensibles.
Si ces datamarts sont implémentés sous forme de tables physiques, ils auront besoin de davantage de ressources de stockage et d’un traitement supplémentaire pour les générer et les actualiser régulièrement. De plus, comme les données dans les DataMarts sont celles datant de la dernière opération d’actualisation, elles ne sont pas toujours appropriées pour les tableaux de bord de données hautement volatiles.
Conseil
La virtualisation des DataMarts peut économiser des ressources de stockage et de traitement.
Avec l’avènement des architectures MPP scalables plus abordables financièrement, telles que Azure Synapse, et leurs caractéristiques de performances intrinsèques, vous pouvez fournir des fonctionnalités de datamart sans avoir à instancier le datamart sous la forme d’un ensemble de tables physiques. Il existe une méthode qui consiste à virtualiser les datamarts via des vues SQL sur l’entrepôt de données principal. Une autre méthode consiste à virtualiser les magasins de données via une couche de virtualisation à l’aide de fonctionnalités telles que des vues dans Azure ou des produits de virtualisation tiers. Cette approche simplifie voire élimine les besoins supplémentaires en stockage et en traitement des agrégations, et réduit le nombre total d’objets de base de données à migrer.
Il y a un autre avantage potentiel à cette approche. Avec l’implémentation de la logique d’agrégation et de jointure dans une couche de virtualisation, et avec l’affichage des outils externes de création de rapports dans une vue virtualisée, le traitement nécessaire à la création de ces vues a lieu dans l’entrepôt de données. L’entrepôt de données est généralement le meilleur endroit pour exécuter des jointures, des agrégations et d’autres opérations connexes sur des volumes de données volumineux.
Les principaux facteurs conduisant à choisir l’implémentation d’un datamart virtuel par rapport à un datamart physique sont les suivants :
Une plus grande agilité : un DataMart virtuel est plus facile à modifier que des tables physiques et les processus ETL associés.
Réduction du coût total de possession : une implémentation virtualisée nécessite moins de magasins et de copies de données.
Élimination des travaux ETL pour migrer et simplifier l’architecture d’entrepôt de données dans un environnement virtualisé.
Amélioration des performances : les datamarts physiques sont historiquement plus performants. Toutefois, les produits de virtualisation implémentent désormais des techniques de mise en cache intelligentes pour l’atténuation de cette différence.
Conseil
Les performances et la scalabilité d’Azure Synapse permettent la virtualisation sans sacrifier les performances.
Migration de données à partir d’Oracle
Comprendre vos données
Dans le cadre de la planification de la migration, vous devez déterminer précisément le volume de données à migrer, car cela peut avoir un impact sur le choix de l’approche de migration. Utilisez les métadonnées système pour déterminer l’espace physique pris par les données brutes dans les tables à migrer. Dans ce contexte, les données brutes correspondent à la quantité d’espace utilisé par les lignes de données d’une table, en excluant les surcharges, telles que les index et la compression. Les tables de faits les plus volumineuses concentrent généralement plus de 95 % des données.
Cette requête vous donnera la taille totale de la base de données dans Oracle :
SELECT
( SELECT SUM(bytes)/1024/1024/1024 data_size
FROM sys.dba_data_files ) +
( SELECT NVL(sum(bytes),0)/1024/1024/1024 temp_size
FROM sys.dba_temp_files ) +
( SELECT SUM(bytes)/1024/1024/1024 redo_size
FROM sys.v_$log ) +
( SELECT SUM(BLOCK_SIZE*FILE_SIZE_BLKS)/1024/1024/1024 controlfile_size
FROM v$controlfile ) "Size in GB"
FROM dual
La taille de la base de données est égale à la taille de (data files + temp files + online/offline redo log files + control files). La taille globale de la base de données inclut l’espace utilisé et l’espace libre.
L’exemple de requête suivant montre l’utilisation de l’espace disque par les données de table et les index :
SELECT
owner, "Type", table_name "Name", TRUNC(sum(bytes)/1024/1024) Meg
FROM
( SELECT segment_name table_name, owner, bytes, 'Table' as "Type"
FROM dba_segments
WHERE segment_type in ('TABLE','TABLE PARTITION','TABLE SUBPARTITION' )
UNION ALL
SELECT i.table_name, i.owner, s.bytes, 'Index' as "Type"
FROM dba_indexes i, dba_segments s
WHERE s.segment_name = i.index_name
AND s.owner = i.owner
AND s.segment_type in ('INDEX','INDEX PARTITION','INDEX SUBPARTITION')
UNION ALL
SELECT l.table_name, l.owner, s.bytes, 'LOB' as "Type"
FROM dba_lobs l, dba_segments s
WHERE s.segment_name = l.segment_name
AND s.owner = l.owner
AND s.segment_type IN ('LOBSEGMENT','LOB PARTITION','LOB SUBPARTITION')
UNION ALL
SELECT l.table_name, l.owner, s.bytes, 'LOB Index' as "Type"
FROM dba_lobs l, dba_segments s
WHERE s.segment_name = l.index_name
AND s.owner = l.owner
AND s.segment_type = 'LOBINDEX')
WHERE owner in UPPER('&owner')
GROUP BY table_name, owner, "Type"
HAVING SUM(bytes)/1024/1024 > 10 /* Ignore really small tables */
ORDER BY SUM(bytes) desc;
En outre, l’équipe de migration des bases de données Microsoft fournit de nombreuses ressources, notamment Oracle Inventory Script Artifacts. L’outil Oracle Inventory Script Artifacts inclut une requête PL/SQL qui accède aux tables système Oracle et fournit un nombre d’objets par type de schéma, type d’objet et état. L’outil fournit également une estimation approximative des « données brutes », ainsi que du dimensionnement des tables dans chaque schéma, avec les résultats enregistrés dans un fichier au format CSV. Une feuille de calcul de calculatrice incluse prend le CSV comme entrée et fournit des données de dimensionnement.
Pour tous les tableaux, vous pouvez estimer avec précision le volume des données qui doivent être migrées en extrayant un échantillon représentatif de ces données (par exemple, 1 million de lignes) vers un fichier de données ASCII plat non compressé. Basez-vous ensuite sur la taille de ce fichier pour obtenir une taille moyenne de données brutes par ligne. Pour finir, multipliez cette taille moyenne par le nombre total de lignes de la table complète pour obtenir la taille de données brutes de la table. Utilisez cette taille de données brutes dans votre planification.
Utiliser des requêtes SQL pour rechercher des types de données
En interrogeant la vue DBA_TAB_COLUMNS du dictionnaire de données statique Oracle, vous pouvez déterminer quels types de données sont utilisés dans un schéma et si l’un d’eux doit être modifié. Utilisez des requêtes SQL pour rechercher les colonnes des schémas Oracle dont les types de données ne sont pas mappés directement sur les types de données Azure Synapse. De même, vous pouvez utiliser des requêtes pour compter le nombre d’occurrences de chaque type de données Oracle qui n’est pas directement mappé à Azure Synapse. En vous aidant des résultats de ces requêtes et de la table de comparaison de type de données, vous pouvez déterminer quels types de données doivent être modifiés dans un environnement Azure Synapse.
Pour rechercher les colonnes dont les types de données ne sont pas mappés à ceux d’Azure Synapse, exécutez la requête suivante après avoir remplacé <owner_name> par le propriétaire approprié de votre schéma :
SELECT owner, table_name, column_name, data_type
FROM dba_tab_columns
WHERE owner in ('<owner_name>')
AND data_type NOT IN
('BINARY_DOUBLE', 'BINARY_FLOAT', 'CHAR', 'DATE', 'DECIMAL', 'FLOAT', 'LONG', 'LONG RAW', 'NCHAR', 'NUMERIC', 'NUMBER', 'NVARCHAR2', 'SMALLINT', 'RAW', 'REAL', 'VARCHAR2', 'XML_TYPE')
ORDER BY 1,2,3;
Pour compter le nombre de types de données non mappables, utilisez la requête suivante :
SELECT data_type, count(*)
FROM dba_tab_columns
WHERE data_type NOT IN
('BINARY_DOUBLE', 'BINARY_FLOAT', 'CHAR', 'DATE', 'DECIMAL', 'FLOAT', 'LONG', 'LONG RAW', 'NCHAR', 'NUMERIC', 'NUMBER', 'NVARCHAR2', 'SMALLINT', 'RAW', 'REAL', 'VARCHAR2', 'XML_TYPE')
GROUP BY data_type
ORDER BY data_type;
Microsoft propose l’Assistant Migration SQL Server (SSMA) pour Oracle pour automatiser la migration des entrepôts de données à partir d’environnements Oracle hérités, y compris le mappage des types de données. Vous pouvez également utiliser Azure Database Migration Service pour planifier et effectuer une migration à partir d’environnements comme Oracle. Les fournisseurs tiers proposent également des outils et des services pour automatiser la migration. Si un outil ETL tiers est déjà utilisé dans l’environnement Oracle, vous pouvez utiliser cet outil pour implémenter toutes les transformations de données nécessaires. La section suivante explore la migration des processus ETL existants.
Considérations relatives à la migration ETL
Décisions initiales concernant la migration ETL Oracle
Pour le traitement ETL/ELT, les entrepôts de données Oracle hérités utilisent souvent des scripts personnalisés, des outils ETL tiers ou une combinaison d’approches qui ont évolué au fil du temps. Lors de la planification d’une migration vers Azure Synapse, vous devez déterminer la meilleure façon d’implémenter le traitement ETL/ELT nécessaire dans le nouvel environnement, tout en réduisant les coûts et les risques.
Conseil
Planifiez l’approche de la migration ETL et recourez aux services Azure qui peuvent être utiles.
L’organigramme suivant résume l’une des approches :
Comme le montre l’organigramme, l’étape initiale consiste toujours à créer un inventaire des processus ETL/ELT qui doivent faire l’objet d’une migration. Avec les fonctionnalités Azure standard intégrées, certains processus existants peuvent ne pas nécessiter de déplacement. À des fins de planification, il est important de bien évaluer l’échelle de la migration à effectuer. Ensuite, posez-vous les questions de l’arbre de décision :
Passer à Azure natif ? Cela dépend si vous effectuez une migration vers un environnement entièrement natif Azure. Si c’est le cas, nous vous recommandons de reconcevoir le traitement ETL en utilisant des pipelines et activités dans Azure Data Factory ou des pipelines Azure Synapse.
Utiliser des outils ETL tiers ? Si vous ne passez pas à un environnement entièrement natif Azure, vérifiez si un outil ETL tiers existant est déjà utilisé. Dans l’environnement Oracle, vous pouvez constater qu’une partie du traitement ETL, ou l’intégralité de celui-ci, est exécutée par des scripts personnalisés à l’aide d’utilitaires propres à Oracle, tels qu’Oracle SQL Developer, Oracle SQL*Loader et Oracle Data Pump. Dans ce cas, l’approche consiste à reconcevoir le traitement à l’aide d’Azure Data Factory.
L’outil tiers prend-il en charge les pools SQL dédiés dans Azure Synapse ? Déterminez si l’investissement en compétences est important dans l’outil ETL tiers, ou si des workflows et des planifications existants utilisent cet outil. Si c’est le cas, déterminez si l’outil peut prendre en charge efficacement Azure Synapse en tant qu’environnement cible. Dans l’idéal, l’outil doit inclure des connecteurs natifs qui peuvent tirer parti des fonctionnalités Azure, telles que PolyBase ou COPY INTO, pour un chargement de données plus efficace. Cela dit, même sans connecteurs natifs, il existe généralement un moyen d’appeler des processus externes, tels que PolyBase ou
COPY INTO, et de passer des paramètres applicables. Dans ce cas, utilisez les compétences et workflows existants avec Azure Synapse comme nouvel environnement cible.Si vous utilisez Oracle Data Integrator (ODI) pour le traitement ELT, vous aurez besoin de modules de connaissances ODI pour Azure Synapse. Si ces modules ne sont pas disponibles dans votre organisation, mais que vous disposez d’ODI, vous pouvez utiliser ODI pour générer des fichiers plats. Ces fichiers plats peuvent ensuite être déplacés vers Azure et ingérés dans Azure Data Lake Storage en vue de leur chargement dans Azure Synapse.
Exécuter des outils ETL dans Azure ? Si vous décidez de conserver un outil ETL tiers, vous pouvez exécuter cet outil dans l’environnement Azure (plutôt que sur un serveur ETL local existant) et laisser Azure Data Factory gérer l’orchestration globale des workflows existants. Vous devez donc décider si vous souhaitez laisser l’outil existant s’exécuter, ou si vous souhaitez le déplacer dans l’environnement Azure pour optimiser les coûts, les performances et la scalabilité.
Conseil
Vous pouvez exécuter des outils ETL dans Azure afin de tirer parti des performances, de la scalabilité et de la réduction des coûts.
Reconcevoir des scripts existants propres à Oracle
Si une partie ou l’intégralité des traitements ETL/ELT de l’entrepôt Oracle existants est gérée par des scripts personnalisés qui utilisent des utilitaires propres à Oracle, tels qu’Oracle SQL*Plus, Oracle SQL Developer, Oracle SQL*Loader ou Oracle Data Pump, vous devrez recoder ces scripts pour l’environnement Azure Synapse. De même, si des processus ETL ont été implémentés à l’aide de procédures stockées dans Oracle, vous devrez recoder ces processus.
Certains éléments du processus ETL sont faciles à migrer, par exemple, à l’aide d’un simple chargement de données en bloc dans une table intermédiaire à partir d’un fichier externe. Il peut même être possible d’automatiser ces parties du processus, par exemple, à l’aide d’Azure Synapse COPY INTO ou de PolyBase au lieu de SQL*Loader. La réingénierie d’autres parties du processus qui contiennent des procédures SQL et/ou stockées arbitraires prend plus de temps.
Conseil
L’inventaire des tâches ETL à migrer doit inclure des scripts et des procédures stockées.
Pour tester la compatibilité d’Oracle SQL avec Azure Synapse, vous pouvez capturer des instructions SQL représentatives à partir de la jointure de v$active_session_history et de v$sql d’Oracle afin d’obtenir sql_text, puis préfixer ces requêtes avec EXPLAIN. En supposant que vous exécutiez un modèle de données migrées de type like-for-like dans Azure Synapse, vous devrez exécuter ces instructions EXPLAIN dans Azure Synapse. Tout code SQL incompatible retournera une erreur. Vous pouvez utiliser ces informations pour déterminer l’ampleur de la tâche de recodage.
Conseil
Utilisez EXPLAIN pour rechercher les incompatibilités SQL.
Dans le pire des cas, un recodage manuel peut être nécessaire. Toutefois, il existe des produits et des services qui sont disponibles auprès des partenaires Microsoft et qui facilitent la conception du code Oracle.
Conseil
Les partenaires proposent des produits et des compétences qui aident à la conception du code Oracle.
Utiliser des outils ETL tiers existants
Souvent, le système d’entrepôt de données hérité existant est déjà rempli et géré par un produit ETL tiers. Si vous souhaitez obtenir la liste des partenaires actuels d’intégration de données Microsoft pour Azure Synapse, consultez Partenaires d’intégration de données d’Azure Synapse Analytics.
La communauté Oracle utilise fréquemment plusieurs produits ETL populaires. Les paragraphes suivants décrivent les outils ETL les plus populaires pour les entrepôts Oracle. Vous pouvez exécuter tous ces produits au sein d’une machine virtuelle dans Azure, et les utiliser pour lire et écrire des bases de données et des fichiers Azure.
Conseil
Tirez parti de l’investissement dans des outils tiers existants pour réduire les coûts et les risques.
Chargement de données à partir d’Oracle
Choix à faire pour le chargement de données à partir d’Oracle
Lorsque vous vous préparez à migrer des données à partir d’un entrepôt de données Oracle, vous devez déterminer comment les données seront déplacées physiquement de l’environnement local existant vers Azure Synapse dans le cloud, et quels outils seront utilisés pour effectuer le transfert et le chargement. Posez-vous les questions suivantes, qui sont abordées dans les sections ci-dessous.
Allez-vous extraire les données dans des fichiers ou les déplacer directement via une connexion réseau ?
Allez-vous orchestrer le processus à partir du système source ou de l’environnement cible Azure ?
Quels outils utiliserez-vous pour automatiser et gérer le processus de migration ?
Transférer des données via des fichiers ou une connexion réseau ?
Une fois que les tables de base de données à migrer ont été créées dans Azure Synapse, vous pouvez déplacer les données pour remplir ces tables dans le nouvel environnement, et donc, en dehors du système Oracle hérité. Il y a deux approches principales :
Extraction de fichier : extrayez les données des tables Oracle vers des fichiers plats délimités, généralement au format CSV. Vous pouvez extraire des données de table de plusieurs façons :
- Utilisez des outils Oracle standard tels que SQL*Plus, SQL Developer et SQLcl.
- Utilisez Oracle Data Integrator (ODI) pour générer des fichiers plats.
- Utilisez le connecteur Oracle dans Data Factory pour décharger des tables Oracle en parallèle afin de permettre le chargement des données par partition.
- Utilisez des outils ETL tiers.
Pour obtenir des exemples d’extraction de données de table Oracle, consultez l’annexe de l’article.
Avec cette approche, il faut suffisamment d’espace pour charger les fichiers de données extraits. L’espace peut être local dans la base de données source Oracle si un stockage suffisant est disponible, ou distant dans le Stockage Blob Azure. Les meilleures performances sont obtenues lorsqu’un fichier est écrit localement, car cela évite la surcharge réseau.
Pour réduire les exigences de stockage et de transfert réseau, compressez les fichiers de données extraits à l’aide d’un utilitaire tel que gzip.
Après l’extraction, déplacez les fichiers plats vers le Stockage Blob Azure. Microsoft propose différentes options pour déplacer de grands volumes de données, notamment :
- AzCopy pour déplacer des fichiers sur le réseau vers le Stockage Azure.
- Azure ExpressRoute pour déplacer des données en bloc via une connexion réseau privée.
- Azure Data Box pour déplacer des fichiers vers un appareil de stockage physique que vous envoyez à un centre de données Azure en vue de leur chargement.
Pour plus d’informations, consultez l’article Transférer des données vers et à partir d’Azure.
Extraction directe et chargement sur le réseau : l’environnement Azure cible envoie une requête d’extraction de données (normalement via une commande SQL) au système Oracle hérité pour extraire les données. Les résultats sont envoyés sur le réseau et chargés directement dans Azure Synapse, sans avoir à « déposer » les données dans des fichiers intermédiaires. Le facteur de limitation de ce scénario est normalement la bande passante de la connexion réseau qui existe entre la base de données Oracle et l’environnement Azure. Pour les volumes de données exceptionnellement importants, cette approche n’est pas toujours pratique.
Conseil
Ayez une idée précise des volumes de données à migrer et de la bande passante réseau disponible, car ces facteurs influencent le choix de l’approche de la migration.
Il existe également une approche hybride qui combine les deux méthodes. Par exemple, vous pouvez utiliser l’approche d’extraction de réseau directe pour des tables de dimension plus petites et des exemples de tables de faits plus grandes pour fournir rapidement un environnement de test dans Azure Synapse. Pour les grandes tables de faits historiques, vous pouvez utiliser l’approche d’extraction et de transfert de fichiers avec Azure Data Box.
Orchestrer à partir d’Oracle ou d’Azure ?
L’approche recommandée lorsque vous déplacez des données vers Azure Synapse est d’orchestrer l’extraction et le chargement des données à partir de l’environnement Azure à l’aide de SSMA ou de Data Factory. Utilisez les utilitaires associés, tels que PolyBase ou COPY INTO, pour un chargement de données optimal. Cette approche tire parti des fonctionnalités Azure intégrées et réduit les efforts nécessaires à la création de pipelines de chargement de données réutilisables. Pour automatiser le processus de migration, vous pouvez utiliser des pipelines de chargement de données basés sur les métadonnées.
L’approche recommandée réduit également l’impact sur les performances dans l’environnement Oracle existant pendant le processus de chargement des données, car les processus de gestion et de chargement s’exécutent dans Azure.
Outils de migration des données existants
La transformation et le déplacement des données sont les fonctions de base de tous les produits ETL. Si un outil de migration des données est déjà utilisé dans l’environnement Oracle existant et qu’il prend en charge Azure Synapse en tant qu’environnement cible, vous pouvez utiliser cet outil pour simplifier la migration des données.
Même si aucun outil ETL n’est encore installé, les partenaires d’intégration de données Azure Synapse Analytics offrent des outils ETL qui simplifient la migration des données.
Enfin, si vous prévoyez d’utiliser un outil ETL, exécutez cet outil dans l’environnement Azure afin de tirer parti des performances, de la scalabilité et de la réduction des coûts offertes par le cloud Azure. Cette approche libère également des ressources dans le centre de données Oracle.
Résumé
Pour résumer, nos recommandations relatives à la migration des données et des processus ETL associés d’Oracle vers Azure Synapse sont les suivantes :
Planifiez la migration pour bien la réussir.
Faites un inventaire détaillé des données et des processus à migrer le plus tôt possible.
Appuyez-vous sur les fichiers journaux et métadonnées système pour avoir une compréhension fine de l’utilisation des données et des processus. Ne vous fiez pas entièrement à la documentation, qui peut parfois être obsolète.
Déterminez avec précision les volumes de données à migrer, et la bande passante réseau entre le centre de données local et les environnements cloud Azure.
Vous pouvez utiliser une instance Oracle dans une machine virtuelle Azure comme tremplin pour déplacer la migration à partir de l’environnement Oracle hérité.
Tirez parti des fonctionnalités Azure intégrées standards pour réduire la charge de travail de migration.
Identifiez les outils les plus efficaces pour l’extraction et le chargement des données dans les environnements Oracle et Azure. Utilisez les outils appropriés dans chaque phase du processus.
Utilisez des services Azure comme Data Factory pour orchestrer et automatiser le processus de migration tout en réduisant l’impact sur le système Oracle.
Annexe : Exemples de techniques d’extraction de données Oracle
Vous pouvez utiliser plusieurs techniques pour extraire des données Oracle lors d’une migration d’Oracle vers Azure Synapse. Les sections suivantes montrent comment extraire des données Oracle à l’aide d’Oracle SQL Developer et du connecteur Oracle dans Data Factory.
Utiliser Oracle SQL Developer pour l’extraction des données
Vous pouvez utiliser l’interface utilisateur d’Oracle SQL Developer pour exporter des données de table dans de nombreux formats, notamment CSV, comme le montre la capture d’écran suivante :
Parmi les autres options d’exportation figurent JSON et XML. Vous pouvez utiliser l’interface utilisateur pour ajouter un ensemble de noms de tables à un « panier », puis appliquer l’exportation à l’ensemble du jeu dans le panier :
Vous pouvez également utiliser Oracle SQL Developer Command Line (SQLcl) pour exporter des données Oracle. Cette option prend en charge l’automatisation à l’aide d’un script d’interpréteur de commandes.
Pour les tables relativement petites, cette technique peut vous être utile si vous rencontrez des problèmes d’extraction de données via une connexion directe.
Utiliser le connecteur Oracle dans Azure Data Factory pour la copie parallèle
Vous pouvez utiliser le connecteur Oracle dans Data Factory pour décharger de grandes tables Oracle en parallèle. Le connecteur Oracle propose un partitionnement de données intégré pour copier des données à partir d’Oracle en parallèle. Vous trouverez les options de partitionnement de données sous l’onglet Source de l’activité de copie.
Pour plus d’informations sur la configuration du connecteur Oracle pour la copie parallèle, consultez Copie parallèle à partir d’Oracle.
Pour plus d’informations sur les performances et la scalabilité de l’activité de copie Data Factory, consultez Guide sur les performances et la scalabilité de l’activité de copie.
Étapes suivantes
Pour en savoir plus sur la sécurité, l’accès et les opérations, consultez l’article suivant de cette série : Sécurité, accès et opérations pour les migrations Oracle.