Conception et performances pour les migrations Oracle

Cet article est le premier d’une série de sept, qui fournit des conseils sur la migration d’Oracle vers Azure Synapse Analytics. Cet article est consacré aux meilleures pratiques pour la conception et les performances.

Vue d’ensemble

En raison du coût et de la complexité de la maintenance et de la mise à niveau des environnements Oracle locaux hérités, de nombreux utilisateurs Oracle souhaitent tirer parti des innovations fournies par les environnements cloud modernes. Les environnements cloud IaaS (Infrastructure as a Service) et PaaS (Platform-as-a-Service) vous permettent de déléguer des tâches telles que la maintenance de l’infrastructure et le développement de plateforme au fournisseur cloud.

Conseil

Plus qu’une base de données, l’environnement Azure inclut un ensemble complet de fonctionnalités et d’outils.

Oracle et Azure Synapse Analytics sont dans les deux cas des bases de données SQL conçues pour utiliser des techniques de traitement massivement parallèle (MPP, Massively Parallel Processing), lesquelles permettent d’obtenir des performances de requête élevées sur d’énormes volumes de données. Il y a toutefois quelques différences d’approche fondamentales entre les deux :

• Les systèmes Oracle hérités sont souvent installés localement et utilisent du matériel relativement coûteux, tandis qu’Azure Synapse est basé sur le cloud et utilise les ressources de stockage et de calcul d’Azure.

• La mise à niveau d’une configuration Oracle constitue une tâche majeure impliquant du matériel physique supplémentaire et une reconfiguration potentiellement laborieuse de la base de données, ou un vidage et un rechargement. Étant donné que les ressources de stockage et de calcul sont séparées dans l’environnement Azure et qu’elles disposent d’une capacité de mise à l’échelle, il est facile de les mettre à l’échelle vers le haut et vers le bas.

• Vous pouvez suspendre ou redimensionner Azure Synapse en fonction des besoins afin de réduire la consommation des ressources et par là-même, le coût.

Microsoft Azure est un environnement cloud disponible dans le monde entier, hautement sécurisé et scalable, qui comprend Azure Synapse et un écosystème d’outils et de capacités qui le complètent. Le diagramme suivant récapitule l’écosystème Azure Synapse.

Azure Synapse fournit de très bonnes performances de bases de données relationnelles en utilisant des techniques telles que le traitement MPP et la mise en cache automatique en mémoire. Vous pouvez constater les résultats de ces techniques dans des benchmarks indépendants, comme celui récemment réalisé par GigaOm, qui compare Azure Synapse à d’autres offres populaires d’entrepôt de données dans le cloud. Les clients qui migrent vers l’environnement Azure Synapse voient de nombreux avantages, notamment :

• Amélioration des performances et du rapport prix/performance.

• Une plus grande souplesse et un temps de valorisation plus court.

• Déploiement de serveur et d’applications plus rapide.

• Scalabilité élastique : payez uniquement pour l’utilisation réelle.

• Amélioration de la conformité/sécurité.

• Réduction des coûts de stockage et de récupération d’urgence.

• Réduction du coût total de possession, meilleur contrôle des coûts et dépenses opérationnelles (OPEX) simplifiées.

Pour optimiser ces avantages, migrez les données et applications nouvelles ou existantes vers la plateforme Azure Synapse. Dans de nombreuses organisations, la migration comprend la migration d’un entrepôt de données existant à partir d’une plateforme sur site existante telle que Oracle vers Azure Synapse. En général, le processus de migration comprend les étapes suivantes :

    Préparation 🡆

• Définissez l’étendue de ce qui doit être migré.

• Créez un inventaire des données et processus pour la migration.

• Définissez les modifications de modèle de données (le cas échéant).

• Définissez le mécanisme d’extraction de données sources.

• Identifiez les outils et fonctionnalités Azure (et tiers) à utiliser.

• Formez le personnel à un stade précoce sur la nouvelle plateforme.

• Configurez la plateforme cible Azure.

    Migration 🡆

• Commencez par une migration simple et à petite échelle.

• Automatisez autant que possible.

• Utilisez les outils et fonctionnalités Azure intégrés pour réduire l’effort de migration.

• Migrez les métadonnées des tables et des vues.

• Migrez les données historique à conserver.

• Migrez ou refactorisez les procédures stockées et les processus métier.

• Migrer ou refactoriser les processus de charge incrémentielle ETL/ELT

    Tâches de post-migration

• Surveillez et documenter toutes les étapes du processus.

• Servez-vous de l’expérience acquise pour créer un modèle en vue de futures migrations.

• Remaniez le modèle de données si nécessaire, en exploitant les performances et la scalabilité de la nouvelle plateforme.

• Testez les applications et les outils de requête.

• Évaluez et optimisez les performances des requêtes.

Cet article fournit des informations générales et des instructions relatives à l’optimisation des performances lors de la migration d’un entrepôt de données d’un environnement Oracle existant vers Azure Synapse. L’objectif de l’optimisation des performances est d’obtenir les mêmes performances d’entrepôt de données dans Azure Synapse après la migration.

Remarques relatives à la conception

Étendue de la migration

Lorsque vous préparez la migration à partir d’un environnement Oracle, tenez compte des choix de migration suivants.

Choisir la charge de travail pour la migration initiale

Habituellement, les environnements Oracle hérités ont évolué au fil du temps pour englober plusieurs domaines thématiques et charges de travail mixtes. Quand vous décidez de commencer un projet de migration, choisissez un domaine qui pourra :

• Prouver la viabilité de la migration vers Azure Synapse en tirant rapidement parti des avantages du nouvel environnement.

• Permettre à votre personnel technique interne d’acquérir une expérience adaptée aux processus et aux outils qu’il utilisera lors de la migration d’autres domaines.

• Créer un modèle pour d’autres migrations propres à l’environnement Oracle source et aux outils et processus déjà en place.

Être un bon candidat pour une migration initiale à partir d’un environnement Oracle prend en charge les éléments précédents et :

• Implémente une charge de travail BI/Analytics plutôt qu’une charge de travail OLTP (Online Transaction Processing).

• Possède un modèle de données, par exemple un schéma en étoile ou en flocons qui peut être migré avec un minimum de modifications.

Conseil

Créez un inventaire des objets à migrer et documentez le processus de migration.

Le volume de données migrées dans la migration initiale doit être suffisamment important pour illustrer les fonctionnalités et les avantages de l’environnement Azure Synapse, mais pas trop volumineux pour illustrer rapidement la valeur. La valeur typique se situe dans la plage de 1 à 10 téraoctets.

Pour un projet de migration, une première approche consiste à réduire les risques, les efforts et le temps nécessaires afin que vous puissiez voir rapidement les avantages de l’environnement cloud Azure. Les approches suivantes limitent l’étendue de la migration initiale aux datamarts et ne traitent pas les aspects de migration plus larges, tels que la migration ETL et la migration des données historiques. Toutefois, vous pouvez traiter ces aspects dans les phases ultérieures du projet une fois que la couche de magasin de données migrée est répliquée avec les données et les processus de génération requis.

Migration lift-and-shift et approche par phase

En règle générale, il existe deux types de migration, quel que soit l’objectif et l’étendue de la migration planifiée : le lift-and-shift en l’état et une approche par phases qui incorpore les modifications.

Migration lift-and-shift

Dans la migration lift-and-shift, le modèle de données existant, par exemple le schéma en étoile, est migré sans modifications vers la nouvelle plateforme Azure Synapse. Cette approche réduit les risques et la durée de la migration en diminuant le travail nécessaire pour profiter pleinement des avantages du passage à l’environnement cloud Azure. La migration lift-and-shift est adaptée à ces scénarios :

• Vous disposez d’un environnement Oracle existant avec un seul magasin de données à migrer ou
• Vous disposez d’un environnement Oracle existant avec des données qui se trouvent déjà dans un schéma en étoile ou en flocon bien conçu, ou
• Vous êtes sous pression, du point de vue de la planification, mais aussi du point de vue financier, pour passer à un environnement cloud moderne.

Conseil

La migration lift-and-shift est un bon point de départ, même si les phases suivantes implémentent des modifications apportées au modèle de données.

Approche par phases qui incorpore les modifications

Si un entrepôt de données hérité a évolué sur une longue période, vous devrez peut-être le reconcevoir pour maintenir les niveaux de performances requis. Vous devrez peut-être également le retravailler pour prendre en charge de nouvelles données telles que celles de l’Internet des objets (IoT). Dans le cadre du processus de retravail, migrez vers Azure Synapse pour profiter des avantages d’un environnement cloud scalable. La migration peut inclure un changement dans le modèle de données sous-jacent, par exemple un déplacement d’un modèle Inmon vers un coffre de données.

Microsoft recommande de déplacer le modèle de données existant tel quel vers Azure et d’exploiter les performances et la flexibilité de l’environnement Azure pour appliquer les modifications de réingénierie. De cette façon, vous bénéficiez des fonctionnalités d’Azure pour apporter les modifications sans affecter le système source existant.

Utiliser les installations Microsoft pour implémenter une migration basée sur les métadonnées

Vous pouvez automatiser et orchestrer le processus de migration en utilisant les fonctionnalités de l’environnement Azure. Cette approche permet de réduire l’impact sur les performances dans l’environnement Oracle existant, qui est peut-être déjà près de sa pleine capacité.

L’Assistant Migration SQL Server (SSMA) pour Oracle peut automatiser de nombreuses parties du processus de migration, notamment dans certains cas, des fonctions et du code procédural. SSMA prend en charge Azure Synapse en tant qu’environnement cible.

L’Assistant Migration Microsoft SQL Server (SSMA) pour Oracle peut vous aider à migrer un entrepôt de données Oracle ou un mini-Data Warehouse vers Azure Synapse. SSMA est conçu pour automatiser le processus de migration de tables, de vues et de données à partir d’un environnement Oracle existant.

Azure Data Factory est un service d’intégration de données basé sur le cloud qui vous permet de créer des flux de travail orientés données dans le cloud pour orchestrer et automatiser le déplacement des données et la transformation des données. Vous pouvez utiliser Azure Data Factory pour créer et planifier des workflows pilotés par les données (les pipelines) qui ingèrent des données provenant de différents magasins de données. Data Factory peut traiter et transformer les données à l’aide de services de calcul tels que Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics et Azure Machine Learning.

Data Factory peut être utilisé pour déplacer des données à la source vers une cible Azure SQL. Ce déplacement de données hors connexion réduit considérablement le temps d’arrêt lié à la migration.

Azure Database Migration Service peut vous aider à planifier et à effectuer une migration à partir d’environnements comme Oracle.

Si vous prévoyez d’utiliser Azure pour gérer le processus de migration, créez des métadonnées qui listent toutes les tables de données à migrer et leur emplacement.

Différences de conception entre Oracle et Azure Synapse

Comme mentionné précédemment, il existe des différences de base entre les bases de données Oracle et les bases de données Azure Synapse Analytics. SSMA pour Oracle permet non seulement de combler ces lacunes, mais également d’automatiser la migration. Bien que SSMA ne soit pas l’approche la plus efficace pour des données très volumineuses, il est utile pour des tables de plus petite taille.

Différences entre l’utilisation de plusieurs bases de données et l’utilisation d’une seule base de données avec schémas

L’environnement Oracle contient souvent plusieurs bases de données distinctes. Par exemple, il peut y avoir des bases de données distinctes pour l’ingestion des données et les tables intermédiaires, les tables d’entrepôt de base et les datamarts. C’est ce que l’on appelle parfois « couche sémantique ». Dans les pipelines ETL ou ELT, le traitement peut implémenter des jointures entre bases de données et déplacer des données entre les différentes bases de données.

Par contre, l’environnement Azure Synapse contient une seule base de données et utilise des schémas pour séparer les tables en groupes séparés logiquement. Nous vous recommandons d’utiliser une série de schémas dans la base de données Azure Synapse cible pour imiter toutes les bases de données séparées qui sont migrées à partir de l’environnement Oracle. Si l’environnement Oracle utilise déjà des schémas, il se peut que vous deviez employer une nouvelle convention de nommage pour déplacer les tables et les vues Oracle existantes vers le nouvel environnement. Par exemple, vous pouvez concaténer les noms de table et de schéma Oracle existants dans le nouveau nom de table Azure Synapse, puis utiliser les noms de schéma dans le nouvel environnement pour conserver les noms initiaux des bases de données séparées. Bien que vous puissiez utiliser des vues SQL sur les tables sous-jacentes pour maintenir les structures logiques, cette approche présente certains inconvénients :

• Les vues dans Azure Synapse étant en lecture seule, toutes les mises à jour des données doivent avoir lieu sur les tables de base sous-jacentes.

• Il existe peut-être déjà une ou plusieurs couches de vue. Le fait d’en ajouter une autre risque d’avoir une incidence sur les performances.

Conseil

Combinez plusieurs bases de données en une seule dans Azure Synapse et utilisez des noms de schémas pour créer une séparation logique des tables.

Considérations relatives aux tables

Lorsque vous migrez des tables entre différents environnements, seules les données brutes et les métadonnées qui les décrivent physiquement sont migrées. Les autres éléments de base de données du système source, tels que les index, ne sont généralement pas migrés, car ils peuvent être inutiles ou implémentés différemment dans le nouvel environnement.

Les optimisations des performances dans l’environnement source, telles que les index, indiquent où vous pouvez ajouter l’optimisation des performances dans le nouvel environnement. Par exemple, si des requêtes dans l’environnement Oracle source utilisent fréquemment des index bitmap, cela suggère qu’un index hors cluster doit être créé dans Azure Synapse. D’autres techniques d’optimisation des performances natives, telles que la réplication de table, peuvent être plus applicables qu’une création d’index « like for like ». SSMA pour Oracle peut être utilisé afin de fournir des recommandations de migration pour la distribution et l’indexation des tables.

Conseil

Les index existants marquent les candidats à l’indexation dans l’entrepôt migré.

Types d’objets de base de données Oracle non pris en charge

Les fonctionnalités propres à Oracle peuvent souvent être remplacées par des fonctionnalités Azure Synapse. Toutefois, certains objets de base de données Oracle ne sont pas directement pris en charge dans Azure Synapse. La liste suivante d’objets de base de données Oracle non pris en charge explique comment obtenir une fonctionnalité équivalente dans Azure Synapse.

• Différentes options d’indexation : dans Oracle, plusieurs options d’indexation, telles que les index bitmap, les index basés sur des fonctions et les index de domaine, n’ont pas d’équivalent direct dans Azure Synapse.

  Vous pouvez déterminer les colonnes indexées et le type d’index en :

  • Interrogeant des tables et des vues de catalogue système, comme ALL_INDEXES, DBA_INDEXES, USER_INDEXES et DBA_IND_COL. Vous pouvez utiliser les requêtes intégrées dans Oracle SQL Developer, comme illustré dans la capture d’écran suivante.

    

    Vous pouvez également exécuter la requête suivante pour rechercher tous les index d’un type donné :

    SELECT * FROM dba_indexes WHERE index_type LIKE 'FUNCTION-BASED%';
    

  • Interrogeant des vues dba_index_usage ou v$object_usage quand le monitoring est activé. Vous pouvez interroger ces vues dans Oracle SQL Developer, comme illustré dans la capture d’écran suivante.

    

  Les index basés sur des fonctions, qui contiennent le résultat d’une fonction exécutée sur des colonnes de données sous-jacentes, n’ont pas d’équivalent direct dans Azure Synapse. Nous vous recommandons de d’abord effectuer la migration des données, puis, dans Azure Synapse, d’exécuter les requêtes Oracle qui utilisent des index basés sur des fonctions pour évaluer les performances. Si les performances de ces requêtes dans Azure Synapse ne sont pas acceptables, vous pouvez créer une colonne qui contient la valeur précalculée, puis indexer cette colonne.

  Lorsque vous configurez l’environnement Azure Synapse, il est logique d’implémenter uniquement les index en cours d’utilisation. Azure Synapse prend actuellement en charge les types d’index indiqués ici :

  

  Les fonctionnalités Azure Synapse, telles que le traitement des requêtes parallèles et la mise en cache en mémoire des données et des résultats, font que les applications de l’entrepôt de données auront probablement besoin de moins d’index pour atteindre les objectifs de performances. Nous vous recommandons d’utiliser les types d’index suivants dans Azure Synapse :

  • Index columnstore cluster : quand aucune option d’index n’est spécifiée pour une table, Azure Synapse par défaut crée un index columnstore cluster. Les tables columnstore cluster offrent le plus haut niveau de compression des données, les meilleures performances globales des requêtes, et surpassent généralement les performances de tous les autres index cluster et segments de mémoire. Un index columnstore cluster constitue généralement le meilleur choix pour les tables volumineuses. Lorsque vous souhaitez créer une table, choisissez « columnstore cluster » si vous ne savez pas comment indexer votre table. Toutefois, il existe certains scénarios où les index columnstore cluster ne sont pas la meilleure option :

    • Les tables avec des données pré-triées sur une ou plusieurs clés de tri pourraient tirer parti de l’élimination de segment activée par les index columnstore en cluster ordonnés.
    • Les tables avec des types de données varchar(max), nvarchar(max) ou varbinary(max), car les index columnstore cluster ne prennent pas en charge ces types de données. Utilisez plutôt un segment de mémoire ou un index cluster.
    • Les tables qui contiennent des données temporaires, car les tables columnstore peuvent être moins efficaces que les tables de segments de mémoire ou les tables temporaires.
    • Petites tables avec moins de 100 millions de lignes. Utilisez plutôt des tables de segments de mémoire.

  • Index columnstore en cluster ordonnés : En permettant l’élimination efficace des segments, les index columnstore en cluster ordonnés dans Azure Synapse pools SQL dédiés offrent des performances beaucoup plus rapides en ignorant de grandes quantités de données ordonnées qui ne correspondent pas au prédicat de requête. Le chargement des données dans une table à index columnstore cluster ordonné peut prendre plus de temps que dans une table à index columnstore cluster non-ordonné en raison de l’opération de tri des données. Toutefois, les requêtes peuvent s’exécuter plus rapidement après avec l’index columnstore cluster ordonné. Pour plus d’informations sur les index columnstore ordonnés en cluster, consultez Optimisation des performances avec un index columnstore en cluster ordonné.

  • Index cluster et non cluster : les index cluster peuvent surpasser les performances des index columnstore cluster lorsqu’une seule ligne doit être récupérée rapidement. Pour les requêtes où une seule recherche de ligne ou quelques recherches de lignes doivent s’effectuer avec une rapidité extrême, utilisez plutôt un index cluster ou un index secondaire non cluster. L’inconvénient d’utiliser un index cluster est que seules les requêtes qui utilisent un filtre hautement sélectif sur la colonne d’index cluster en bénéficient. Pour améliorer le filtrage sur d’autres colonnes, vous pouvez ajouter un index non cluster aux autres colonnes. Toutefois, chaque index que vous ajoutez à une table utilise de l’espace et augmente le temps de chargement.

  • Tables de segments de mémoire : lorsque vous placez temporairement des données dans Azure Synapse, vous pouvez constater que l’utilisation d’une table de segments de mémoire accélère le processus global. Cela est dû au fait que le chargement de données dans des tables de segments de mémoire est plus rapide que le chargement de données dans des tables d’index et que, dans certains cas, les lectures suivantes peuvent être effectuées à partir du cache. Si vous chargez des données uniquement pour les indexer avant d’exécuter d’autres transformations, il sera beaucoup plus rapide de les charger dans une table de segments de mémoire plutôt que dans une table columnstore cluster. En outre, le chargement des données dans une table temporaire est plus rapide que dans un stockage permanent. Pour les petites tables de recherche avec moins de 100 millions de lignes, les tables de segments de mémoire sont généralement recommandées. Les tables columnstore cluster commencent à atteindre une compression optimale lorsqu’elles comptent plus de 100 millions de lignes.

• Tables cluster : les tables Oracle peuvent être organisées afin que les lignes de table fréquemment consultées ensemble (selon une valeur commune) soient stockées physiquement ensemble pour réduire les E/S de disque lorsque les données sont récupérées. Oracle fournit également une option hash-cluster pour les tables individuelles, qui applique une valeur de hachage à la clé de cluster et stocke physiquement toutes les lignes qui ont la même valeur de hachage. Pour lister les clusters au sein d’une base de données Oracle, utilisez la requête SELECT * FROM DBA_CLUSTERS;. Pour déterminer si une table se trouve dans un cluster, utilisez la requête SELECT * FROM TAB;, qui affiche le nom et l’ID de cluster de chaque table.

  Dans Azure Synapse, vous pouvez obtenir des résultats similaires à l’aide de tables matérialisées et/ou répliquées, car ces types de tables réduisent les E/S nécessaires au moment de l’exécution de la requête.

• Vues matérialisées : Oracle prend en charge les vues matérialisées et recommande l’utilisation d’une ou plusieurs grandes tables pour les grandes tables comportant de nombreuses colonnes si quelques colonnes seulement sont régulièrement utilisées dans les requêtes. Les vues matérialisées sont automatiquement actualisées par le système après la modification de données dans la table de base.

  En 2019, Microsoft a annoncé qu’Azure Synapse prendrait en charge les vues matérialisées avec les mêmes fonctions que dans Oracle. Les vues matérialisées sont désormais une fonctionnalité d’évaluation dans Azure Synapse.

• Déclencheurs dans la base de données : dans Oracle, un déclencheur peut être configuré pour s’exécuter automatiquement lorsqu’un événement de déclenchement se produit. Les événements de déclenchement peuvent être :

  • Une instruction DML (Data Manipulation Language), comme INSERT, UPDATE ou DELETE, qui s’exécute sur une table. Si vous avez défini un déclencheur qui se déclenche avant une instruction INSERT sur la table d’un client, le déclencheur se déclenchera une fois avant qu’une nouvelle ligne soit insérée dans la table.

  • Une instruction DDL, comme CREATE ou ALTER, s’exécute. Ce déclencheur est souvent utilisé à des fins d’audit pour enregistrer les modifications de schéma.

  • Un événement système, tel que le démarrage ou l’arrêt de la base de données Oracle.

  • Un événement utilisateur, tel que la connexion ou la déconnexion.

  Vous pouvez obtenir la liste des déclencheurs définis dans une base de données Oracle en interrogeant les vues ALL_TRIGGERS, DBA_TRIGGERS ou USER_TRIGGERS. La capture d’écran suivante montre une requête DBA_TRIGGERS dans Oracle SQL Developer.

  

  Azure Synapse ne prend pas en charge les déclencheurs de base de données Oracle. Toutefois, vous pouvez ajouter des fonctionnalités équivalentes à l’aide de Data Factory, bien que cela vous oblige à refactoriser les processus qui utilisent des déclencheurs.

• Synonymes : Oracle prend en charge la définition de synonymes en tant que noms alternatifs pour plusieurs types d’objets de base de données. Ces types d’objets incluent les tables, les vues, les séquences, les procédures, les fonctions stockées, les packages, les vues matérialisées, les objets de schéma de classe Java, les objets définis par l’utilisateur ou un autre synonyme.

  Azure Synapse ne prend pas en charge la définition de synonymes. Toutefois, si dans Oracle un synonyme fait référence à une table ou à une vue, vous pouvez définir une vue dans Azure Synapse pour qu’elle corresponde au nom alternatif. Si dans Oracle un synonyme fait référence à une fonction ou à une procédure stockée, vous pouvez créer une autre fonction ou procédure stockée dans Azure Synapse (avec un nom correspondant au synonyme) qui appelle la cible.

• Types définis par l’utilisateur : Oracle prend en charge les objets définis par l’utilisateur qui peuvent contenir une série de champs, chacun avec sa propre définition et ses propres valeurs par défaut. Ces objets peuvent être référencés dans une définition de table de la même façon que les types de données intégrés comme NUMBER ou VARCHAR. Vous pouvez obtenir la liste des types définis par l’utilisateur dans une base de données Oracle en interrogeant les vues ALL_TYPES, DBA_TYPES ou USER_TYPES.

  Azure Synapse ne prend pas en charge les types définis par l’utilisateur. Si les données que vous devez déplacer incluent des types de données définis par l’utilisateur, vous devez soit les « aplatir » dans une définition de table conventionnelle, soit, s’il s’agit de tableaux de données, les normaliser dans une table distincte.

Mappage de types de données Oracle

La plupart des types de données Oracle ont un équivalent direct dans Azure Synapse. Le tableau suivant montre l’approche recommandée pour mapper les types de données Oracle vers Azure Synapse.

Type de données Oracle	Type de données Azure Synapse
BFILE	Non pris en charge. Mapper vers VARBINARY (MAX).
BINARY_FLOAT	Non pris en charge. Mapper vers FLOAT.
BINARY_DOUBLE	Non pris en charge. Mapper vers DOUBLE.
BLOB	Non pris en charge directement. Remplacer par VARBINARY(MAX).
CHAR	CHAR
CLOB	Non pris en charge directement. Remplacer par VARCHAR(MAX).
DATE	Dans Oracle, DATE peut également contenir des informations relatives à l’heure. Selon l’utilisation, mapper vers DATE ou TIMESTAMP.
DECIMAL	DECIMAL
DOUBLE	PRECISION DOUBLE
FLOAT	FLOAT
INTEGER	INT
INTERVAL YEAR TO MONTH	Les types de données INTERVAL ne sont pas pris en charge. Utilisez des fonctions de comparaison de dates, telles que DATEDIFF ou DATEADD, pour les calculs de date.
INTERVAL DAY TO SECOND	Les types de données INTERVAL ne sont pas pris en charge. Utilisez des fonctions de comparaison de dates, telles que DATEDIFF ou DATEADD, pour les calculs de date.
LONG	Non pris en charge. Mapper vers VARCHAR(MAX).
LONG RAW	Non pris en charge. Mapper vers VARBINARY(MAX).
NCHAR	NCHAR
NVARCHAR2	NVARCHAR
NUMBER	FLOAT
NCLOB	Non pris en charge directement. Remplacer par NVARCHAR(MAX).
NUMERIC	NUMERIC
Types de données multimédias ORD	Non prise en charge
RAW	Non pris en charge. Mapper vers VARBINARY.
real	RÉEL
ROWID	Non pris en charge. Mapper vers GUID, qui est similaire.
Types de données géospatiales SDO	Non prise en charge
SMALLINT	SMALLINT
timestamp	DATETIME2 ou la fonction CURRENT_TIMESTAMP()
TIMESTAMP WITH LOCAL TIME ZONE	Non pris en charge. Mapper vers DATETIMEOFFSET.
TIMESTAMP WITH TIME ZONE	Non pris en charge, car TIME est stocké à l’aide de l’heure « wall clock » sans décalage de fuseau horaire.
URIType	Non pris en charge. Stocker dans un VARCHAR.
UROWID	Non pris en charge. Mapper vers GUID, qui est similaire.
VARCHAR	VARCHAR
VARCHAR2	VARCHAR
XMLType	Non pris en charge. Stocker les données XML dans un VARCHAR.

Oracle prend également en charge la définition d’objets définis par l’utilisateur qui peuvent contenir une série de champs, chacun avec sa propre définition et ses propres valeurs par défaut. Ces objets peuvent ensuite être référencés dans une définition de table de la même façon que les types de données intégrés comme NUMBER ou VARCHAR. Azure Synapse ne prend pas en charge les types définis par l’utilisateur. Si les données que vous devez déplacer incluent des types de données définis par l’utilisateur, vous devez soit les « aplatir » dans une définition de table conventionnelle, soit, s’il s’agit de tableaux de données, les normaliser dans une table distincte.

Conseil

Évaluez le nombre et le type de types de données non pris en charge pendant la phase de préparation de la migration.

Des fournisseurs tiers proposent des outils et services permettant d’automatiser la migration, dont le mappage de type de données. Si un outil ETL tiers est déjà utilisé dans l’environnement Oracle, utilisez cet outil pour implémenter toutes les transformations de données nécessaires.

Différences de syntaxe SQL DML

Il existe des différences de syntaxe SQL DML entre Oracle SQL et Azure Synapse T-SQL. Ces différences sont abordées en détail dans Réduction des problèmes SQL pour les migrations Oracle. Dans certains cas, vous pouvez automatiser la migration DML à l’aide d’outils Microsoft tels que SSMA pour Oracle et Azure Database Migration Service, ou des produits et services de migration tiers.

Fonctions, procédures stockées et séquences

Quand vous effectuez la migration d’un entrepôt de données à partir d’un environnement hérité mature comme Oracle, vous devez la plupart du temps migrer d’autres éléments que des tables et vues simples. Vérifiez si les outils dans l’environnement Azure peuvent remplacer les fonctionnalités des fonctions, des procédures stockées et des séquences, car il est généralement plus efficace d’utiliser des outils Azure intégrés que de les recoder pour Azure Synapse.

Dans le cadre de votre phase de préparation, créez un inventaire des objets qui doivent être migrés, définissez une méthode pour les gérer et allouez les ressources appropriées dans votre plan de migration.

Les outils Microsoft tels que SSMA pour Oracle et Azure Database Migration Service, ou les produits et services de migration tiers, peuvent automatiser la migration de fonctions, de procédures stockées et de séquences.

Les sections suivantes décrivent plus en détail la migration des fonctions, des procédures stockées et des séquences.

Fonctions

Comme la plupart des produits de base de données, Oracle prend en charge les fonctions système et les fonctions définies par l’utilisateur dans l’implémentation SQL. Lorsque vous migrez une plateforme de base de données héritée vers Azure Synapse, les fonctions système courantes peuvent généralement être migrées sans modification. D’autres présentent une syntaxe légèrement différente, mais les modifications requises sont automatisables. Vous pouvez obtenir la liste des fonctions d’une base de données Oracle en interrogeant la vue ALL_OBJECTS avec la clause WHERE appropriée. Vous pouvez utiliser Oracle SQL Developer pour obtenir une liste de fonctions, comme illustré dans la capture d’écran suivante.

Pour les fonctions système Oracle ou les fonctions arbitraires définies par l’utilisateur qui n’ont pas d’équivalent dans Azure Synapse, recodez ces fonctions à l’aide d’un langage d’environnement cible. Les fonctions Oracle définies par l’utilisateur sont codées en PL/SQL, Java ou C. Azure Synapse utilise le langage Transact-SQL pour l’implémentation de ce type de fonctions.

Procédures stockées

La plupart des produits de base de données modernes offrent la possibilité de stocker des procédures. Oracle fournit le langage PL/SQL à cet effet. Une procédure stockée contient généralement les instructions SQL et la logique procédurale et peut retourner des données ou un état. Vous pouvez obtenir la liste des procédures stockées d’une base de données Oracle en interrogeant la vue ALL_OBJECTS avec la clause WHERE appropriée. Vous pouvez utiliser Oracle SQL Developer pour obtenir la liste des procédures stockées, comme illustré dans la capture d’écran suivante.

Azure Synapse prend en charge les procédures stockées à l’aide de T-SQL. Vous devrez donc recoder toutes les procédures stockées migrées dans ce langage.

Séquences

Dans Oracle, une séquence est un objet de base de données nommé créé avec CREATE SEQUENCE. Une séquence fournit des valeurs numériques uniques via les méthodes CURRVAL et NEXTVAL. Vous pouvez utiliser les nombres uniques générés en tant que valeurs de clé de substitution pour les clés primaires.

Azure Synapse n’implémente pas CREATE SEQUENCE, mais vous pouvez implémenter des séquences avec des colonnes IDENTITY ou du code SQL qui génère le numéro de séquence suivant dans une série.

Extraction de métadonnées et de données à partir d’un environnement Oracle

Génération du langage DDL

La norme ANSI SQL définit la syntaxe de base pour les commandes DDL (Data Definition Language). Certaines commandes DDL, telles que CREATE TABLE et CREATE VIEW, sont communes à Oracle et Azure Synapse, mais fournissent également des fonctionnalités spécifiques à l’implémentation telles que l’indexation, la distribution des tables et les options de partitionnement.

Vous pouvez modifier les scripts Oracle CREATE TABLE et CREATE VIEW existants pour obtenir les mêmes définitions dans Azure Synapse. Pour ce faire, vous devrez peut-être utiliser des types de données modifiés et supprimer ou modifier des clauses spécifiques à Oracle, telles que TABLESPACE.

Dans l’environnement Oracle, les tables de catalogue système spécifient la définition actuelle de la table et de la vue. Contrairement à la documentation gérée par l’utilisateur, les informations du catalogue système sont toujours complètes et synchronisées avec les définitions de table actuelles. Vous pouvez accéder aux informations du catalogue système à l’aide d’utilitaires tels qu’Oracle SQL Developer. Oracle SQL Developer peut générer des instructions DDL CREATE TABLE que vous pouvez modifier pour créer des tables équivalentes dans Azure Synapse.

Vous pouvez également utiliser SSMA pour Oracle afin d’effectuer la migration des tables d’un environnement Oracle existant vers Azure Synapse. SSMA pour Oracle applique les mappages de types de données appropriés, ainsi que les types de table et de distribution recommandés, comme illustré dans la capture d’écran suivante.

Vous pouvez également utiliser des outils de migration tiers et des outils ETL qui traitent les informations du catalogue système pour obtenir des résultats similaires.

Extraction de données à partir d’Oracle

Vous pouvez extraire des données de table brutes à partir de tables Oracle et les envoyer vers des fichiers délimités plats, tels que des fichiers CSV, à l’aide d’utilitaires Oracle standards tels qu’Oracle SQL Developer, SQL*Plus et SCLcl. Ensuite, vous pouvez compresser les fichiers délimités plats avec gzip et charger les fichiers compressés sur Stockage Blob Azure avec AzCopy ou des outils de transport de données Azure comme Azure Data Box.

Extrayez les données de table aussi efficacement que possible, en particulier lors d’une migration de tables de faits volumineuses. Pour les tables Oracle, utilisez le parallélisme afin d’optimiser le débit d’extraction. Vous pouvez obtenir un parallélisme en exécutant plusieurs processus qui extraient individuellement des segments discrets de données ou en utilisant des outils capables d’automatiser l’extraction parallèle par le biais du partitionnement.

Conseil

Utilisez le parallélisme pour une extraction de données optimale.

Si une bande passante réseau suffisante est disponible, vous pouvez extraire les données d’un système Oracle local directement dans des tables Azure Synapse ou dans le stockage de données d’objet blob Azure. Pour ce faire, utilisez des processus Data Factory, Azure Database Migration Service, ou des produits tiers d’ETL ou de migration de données.

Les fichiers de données extraits doivent contenir du texte délimité au format CSV, ORC (Optimized Row Columnar) ou Parquet.

Pour plus d’informations sur le processus de migration des données et ETL (extraction, transformation et chargement) à partir d’un environnement Oracle, consultez Migration de données, ETL et chargement pour la migration Oracle.

Recommandations en matière de performances pour les migrations Oracle

L’objectif de l’optimisation des performances est de même ou de meilleures performances d’entrepôt de données après la migration vers Azure Synapse.

Similitudes dans les concepts de l’approche du réglage des performances

De nombreux concepts de réglage des performances pour les bases de données Oracle sont applicables aux bases de données Azure Synapse. Par exemple :

• Recourir à la distribution des données pour colocaliser les données à joindre sur le même nœud de traitement

• Utiliser le plus petit type de données pour une colonne donnée afin d’économiser l’espace de stockage et d’accélérer le traitement des requêtes

• Faire en sorte que les colonnes à joindre ont le même type de données afin d’optimiser le traitement des jointures et de réduire le besoin de transformations de données

• Pour que l’optimiseur puisse produire le meilleur plan d’exécution possible, s’assurer que les statistiques sont à jour

• Monitorer les performances avec des fonctionnalités de base de données intégrées pour s’assurer que les ressources sont utilisées efficacement

Conseil

Hiérarchisez les options de paramétrage dans Azure Synapse au début d’une migration.

Différences dans l’approche du réglage des performances

Cette section détaille les différences d’implémentation du réglage du niveau de performance entre Oracle et Azure Synapse.

Options de distribution de données

Pour les performances, Azure Synapse a été conçu avec une architecture à plusieurs nœuds et utilise un traitement parallèle. Pour optimiser les performances des tables dans Azure Synapse, vous pouvez définir une option de distribution de données dans les instructions CREATE TABLE à l’aide de l’instruction DISTRIBUTION. Par exemple, vous pouvez spécifier une table distribuée par hachage, qui distribue les lignes de la table entre les nœuds de calcul à l’aide d’une fonction de hachage déterministe. De nombreuses implémentations Oracle, en particulier les systèmes locaux plus anciens, ne prennent pas en charge cette fonctionnalité.

Contrairement à Oracle, Azure Synapse prend en charge les jointures locales entre une petite table et une grande table via la réplication de la petite table. Par exemple, prenons une petite table de dimension et une table de faits volumineuse dans un modèle de schéma en étoile. Azure Synapse pouvez répliquer la plus petite table de dimension sur tous les nœuds pour garantir que la valeur de n’importe quelle clé de jointure pour la table volumineuse a une ligne de dimension correspondante disponible localement. La surcharge de la réplication de table de dimension est relativement faible pour une petite table de dimension. Pour les tables de dimensions volumineuses, l’approche par distribution de hachage est plus appropriée. Pour plus d’informations sur les options de distribution de données, consultez Conseils de conception pour l’utilisation de tables répliquées et Conseils sur la conception de tables distribuées.

Conseil

La distribution de hachage améliore les performances des requêtes sur les tables de faits volumineuses. La distribution par tourniquet (round robin) est utile pour améliorer la vitesse de chargement.

La distribution de hachage peut être appliquée sur plusieurs colonnes pour une distribution plus uniforme de la table de base. La distribution multicolonne vous permet de choisir jusqu’à huit colonnes pour la distribution. Cela réduit non seulement l’asymétrie des données au fil du temps, mais améliore également les performances des requêtes.

Notes

La distribution multicolonne est actuellement en préversion pour Azure Synapse Analytics. Vous pouvez utiliser la distribution multicolonne avec CREATE MATERIALIZED VIEW, CREATE TABLE et CREATE TABLE AS SELECT.

Distribution Advisor

Dans Azure Synapse SQL, la façon dont chaque table est distribuée peut être personnalisée. La stratégie de distribution des tables affecte considérablement les performances des requêtes.

Le Conseiller de distribution est une nouvelle fonctionnalité de Synapse SQL qui analyse les requêtes et recommande les meilleures stratégies de distribution pour les tables afin d’améliorer les performances des requêtes. Les requêtes à considérer par le conseiller peuvent être fournies par vous-même ou extraites des requêtes historiques disponibles dans DMV.

Pour obtenir plus d’informations ainsi que des exemples sur l’utilisation du conseiller de distribution, consultez Conseiller de distribution dans Azure Synapse SQL.

Indexation des données

Azure Synapse prend en charge plusieurs options d’indexation définissables par l’utilisateur qui ont un fonctionnement et une utilisation différents par rapport aux mappages de zone gérés par le système dans Oracle. Pour plus d’informations sur les différentes options d’indexation dans Azure Synapse, consultez Index sur les tables de pool SQL dédiées.

Les définitions d’index d’un environnement Oracle source peuvent fournir des indications utiles sur la façon dont les données sont utilisées et sur les colonnes candidates à l’indexation dans l’environnement Azure Synapse. En règle générale, vous n’aurez pas besoin de déplacer chaque index à partir d’un environnement Oracle hérité, car Azure Synapse ne s’appuie pas sur les index et implémente les fonctionnalités suivantes pour obtenir des performances exceptionnelles :

• Traitement de requêtes en parallèle.

• Mise en cache des données en mémoire et des jeux de résultats.

• Distribution des données, telle que la réplication de petites tables de dimension, pour réduire les E/S.

Partitionnement des données

Dans un entrepôt de données d’entreprise, les tables de faits peuvent contenir des milliards de lignes. Le partitionnement constitue un moyen d’optimiser la maintenance et l’interrogation de ces tables en les fractionnant en parties séparées afin de réduire la quantité de données traitées. Dans Azure Synapse, l’instruction CREATE TABLE définit la spécification du partitionnement d’une table.

Vous ne pouvez utiliser qu’un seul champ par table pour le partitionnement. Ce champ est souvent un champ de date. En effet, beaucoup de requêtes sont filtrées selon une date ou une plage de dates. Vous avez la possibilité de changer le partitionnement d’une table après le chargement initial en recréant la table avec la nouvelle distribution. Pour cela, vous utilisez l’instruction CREATE TABLE AS (ou CTAS). Pour une présentation détaillée du partitionnement dans Azure Synapse, consultez Partitionnement de tables dans un pool SQL dédié.

PolyBase ou COPY INTO pour le chargement des données

PolyBase prend en charge le chargement efficace de grandes quantités de données dans un entrepôt de données à l’aide de flux de chargement parallèles. Pour plus d’informations, consultez Stratégie de chargement des données PolyBase.

COPY INTO prend également en charge l’ingestion de données à haut débit et les opérations suivantes :

• Extraction de données à partir de tous les fichiers dans un dossier et ses sous-dossiers.
• Extraction de données à partir de plusieurs emplacements dans le même compte de stockage. Vous pouvez spécifier plusieurs emplacements à l’aide de chemins séparés par des virgules.
• Azure Data Lake Storage (ADLS) et Stockage Blob Azure.
• Formats de fichier CSV, PARQUET et ORC.

Conseil

La méthode recommandée pour le chargement des données consiste à utiliser COPY INTO avec le format de fichier PARQUET.

Gestion des charges de travail

L’exécution de charges de travail mixtes peut poser des problèmes de ressources sur les systèmes chargés. Un schéma de gestion des charges de travail réussi gère efficacement les ressources, garantit une utilisation hautement efficace des ressources et optimise le retour sur investissement (ROI). La classification de la charge de travail, l’importance de la charge de travail et l’isolation de la charge de travail donnent plus de contrôle sur la façon dont la charge de travail utilise les ressources système.

Le guide de gestion des charges de travail décrit les techniques permettant d’analyser la charge de travail, de gérer et de superviser l’importance de la charge de travail ainsi que les étapes de conversion d’une classe de ressources en groupe de charge de travail. Utilisez le Portail Azure et les requêtes T-SQL sur les DMV pour surveiller la charge de travail pour vous assurer que les ressources applicables sont utilisées efficacement.

Étapes suivantes

Pour en savoir plus sur ETL et le chargement dans le cadre d’une migration Oracle, consultez l’article suivant de cette série : Migration de données, ETL et chargement pour la migration Oracle.