En savoir plus sur la réduction du temps d'inactivité pendant une migration de base de données

Un temps d'inactivité planifié pour migrer une base de données de production vers une nouvelle plate-forme peut perturber les opérations en tant qu'arrêt imprévu. Cela est particulièrement vrai pour les entreprises internationales qui soutiennent les utilisateurs sur plusieurs fuseaux horaires et pour les entreprises qui fournissent un accès Internet aux clients 24 heures par jour et 7 jours par semaine. Que vous migrez une base de données du cloud vers le cloud, ou du service cloud en cours vers une nouvelle infrastructure ou une nouvelle plate-forme, vous pouvez réduire le temps d'inactivité en utilisant les technologies Oracle qui fournissent une haute disponibilité.

En savoir plus sur les temps d'inactivité attendus

Lorsque vous migrez une base de données sur site vers le cloud, certaines options génèrent un temps d'inactivité inférieur à d'autres.

La table suivante présente le temps d'inactivité attendu pour les solutions de migration haute disponibilité.

Solution Oracle	Durée de coupure attendue
Oracle GoldenGate	Zéro à secondes
Oracle Data Guard	Moins de 5 minutes
Oracle Recovery Manager	Moins de 2 heures
Instanciation à partir de la sauvegarde Oracle Cloud	Nombre de minutes, en fonction de la taille de la base de données

Remarques concernant la migration d'une base de données vers Oracle Database Cloud Service

Différentes méthodes et outils sont disponibles pour migrer votre environnement Oracle Database sur site vers Oracle Database Cloud Service.

Toutes les méthodes de migration ne s'appliquent pas à tous les scénarios de migration. La plupart des méthodes de migration ne s'appliquent que si les caractéristiques spécifiques de la base de données source et de la base de données de destination sont compatibles. D'autres facteurs peuvent avoir une incidence sur la méthode que vous choisissez pour la migration à partir des méthodes techniquement applicables au scénario de migration.

Voici certaines caractéristiques et options de base de données à prendre en compte lorsque vous choisissez une méthode de migration :

Version de base de données source
Version de la base de données Oracle Database Cloud Service
Système d'exploitation et version de l'hôte sur site
Jeu de caractères de la base de données sur site
Quantité de données, y compris les index
Types de données utilisés dans la base de données sur site
Stockage pour la préparation des données
Longueur acceptable de la coupure système
Bande passante et connectivité réseau

Pour déterminer les méthodes de migration applicables à votre scénario de migration, collectez les informations suivantes.

Version de base de données de votre base de données source sur site.

Une version d'Oracle Database 11g version 2 inférieure à 11.2.0.4 nécessite une mise à niveau vers 11.2.0.4., au minimum.
Pour les bases de données sur site Oracle Database 12c version 1 version 12.1.0.2 ou supérieure, l'architecture de la base de données est la suivante :
- Une base de données Conteneur peut prendre en charge plusieurs bases de données (PDB) pluggables (colocatives) à locataire unique.
- Une base de données non Conteneur
Plate-forme hôte et format endian de la base de données source sur site.
Les plates-formes sont little-endian ou big-endian, selon le classement des octets qu'elles utilisent. Oracle Database Cloud Service utilise la plate-forme Linux x86–64, à savoir little endian.

Interrogez V$DATABASE afin d'identifier le nom de plate-forme pour votre base de données source.

Interrogez V$TRANSPORTABLE_PLATFORM pour visualiser toutes les plates-formes qui prennent en charge le transport de tablespace multiplate-forme, ainsi que le format endian de chaque plate-forme.
Jeu de caractères de votre base de données on-premise et votre base de données Oracle Database Cloud Service.

Certaines méthodes de migration exigent que la base de données source et la base de données cible utilisent des jeux de caractères de base de données compatibles. Par défaut, les bases de données sont configurées pour utiliser le jeu de caractères de la base de données AL32UTF8.
Version de base de données cible vers laquelle vous effectuez la migration dans Oracle Database Cloud Service.

Les bases de données d'Oracle Cloud qui utilisent Oracle Database 12c ou version ultérieure utilisent l'architecture CDB. Les bases de données créées à l'aide de l'option Enterprise Edition sont colocatives et les bases de données créées à l'aide de l'option Enterprise Edition - High Performance ou Enterprise Edition - Extreme Performance sont colocatives.
- Oracle Database 11g version 2
- Oracle Database 12c version 1
- Oracle Database 12c version 2
- Oracle Database 18c

Remarques concernant la migration d'une base de données DBCS vers de nouveaux services cloud

Vous pouvez migrer une instance Oracle Database d'un environnement Oracle Database Cloud Service vers un autre.

Examinez l'environnement en cours pour connaître les facteurs qui peuvent avoir une incidence sur la migration, tels que la taille des fichiers de base de données, le niveau de charge globale et les versions du logiciel que vous utilisez.

Prenez en compte les exigences de l'environnement cible, telles que les versions, les patches et le stockage, qui auront une incidence sur la manière dont vous pouvez optimiser votre base de données source avant la migration.

Pour vous aider à déterminer quels services cloud conviennent à votre migration, collectez les informations suivantes.

Déterminez la taille des fichiers de base de données dans la base de données source, afin de déterminer la quantité d'espace à allouer au système de base de données cible.

Vous trouverez la taille totale des fichiers de base de données dans la base de données que vous envisagez de migrer, y compris la taille des fichiers de journalisation, en exécutant la requête suivante :
```
SELECT SUM(BYTES)/1024/1024 SIZE_IN_MB FROM DBA_SEGMENTS;
```
Pour connaître la taille des fichiers de journalisation, interrogez la vue dynamique V$LOG.
```
SELECT GROUP#, BYTES FROM V$LOG;
```
Déterminez le niveau de charge globale.

Vous pouvez générer un rapport AWR (Automatic Workload Repository) Oracle pour rechercher un échantillon de la charge globale pour la base de données source. Vous pouvez également générer un rapport ADDM (Automatic Database Diagnostic Monitor) pour rechercher les performances de la base de données source sur une période donnée entre des clichés indiqués. Les statistiques de modèle de temps, les statistiques du système d'exploitation et les événements d'attente fournissent un indicateur relativement clair de la charge globale, en ce qui concerne la capacité du système d'exploitation.
Déterminez les variables d'environnement définies dans la base de données source.

Vous pouvez utiliser ces mêmes paramètres dans la base de données cible.
Vérifiez les jeux de caractères de la base de données source.

Vous pouvez rechercher les jeux de caractères de la base de données en exécutant la requête suivante :
```
SELECT NLS_CHARACTERSET, NLS_NCHAR_CHARACTERSET
 FROM NLS_DATABASE_PARAMETERS;
```
La base de données cible doit également contenir ces jeux de caractères.
Déterminez le plan de récupération après sinistre actuellement en place.

Par exemple, si Oracle Data Guard est déjà déployé, vous pouvez créer une base de données de secours pour la procédure de migration. Si vous utilisez des sauvegardes hors site, vous devez effectuer une nouvelle sauvegarde dans Oracle Cloud à l'aide d'Oracle Recovery Manager (RMAN).
Vérifiez si Oracle GoldenGate est configuré avec la base de données source.

Pour rechercher des informations sur Oracle GoldenGate, exécutez l'utilitaire ggsci. Oracle GoldenGate peut être utilisé comme outil de migration de remplacement si vous ne souhaitez pas utiliser Oracle Data Guard pour la migration.

Simplifier et optimiser votre base de données avant la migration

Avant de migrer la base de données, vous pouvez réduire le temps d'inactivité en procédant à une mise à niveau vers la version de la plate-forme cible, en supprimant les objets inutilisés et en exécutant d'autres optimisations.

La migration de toutes les plates-formes de base de données doit inclure une quantité importante de test ainsi que les stratégies de simplification et d'optimisation suivantes.

Simplification : la plupart des environnements de base de données ayant changé par le biais de versions différentes et dont les administrateurs de base de données contiennent d'anciennes informations (et le DBA en cours peut vous demander la raison pour laquelle un objet, des données, une règle ou un environnement similaire sont utilisés dans le système). Il a pour but de simplifier l'administration et de rendre plus fiable. Cette simplification conduit à un système plus disponible.

Envisagez de supprimer des objets de schéma qui ne sont pas nécessaires dans la base de données source avant la migration. Cela permet de réduire la quantité de données migrées.
Optimiser : dans de nombreux cas, la migration implique une version de base de données mise à jour, y compris les nouvelles fonctionnalités. Lors d'une migration, vous devez prendre en compte les recommandations liées aux nouvelles fonctionnalités et meilleures pratiques.

Envisagez de mettre à niveau la base de données source pour qu'elle corresponde à la version de la base de données cible, car cela peut améliorer la migration (dans certains cas de manière significative). Par exemple, les fonctions parallèles de Data Pump sont améliorées par chaque nouvelle version d'Oracle Database ; par conséquent, l'export d'une base de données à partir du système source peut être amélioré et terminé plus rapidement si la base de données source est mise à niveau pour correspondre à la version de la base de données cible.

Indiquez si vous pouvez effectuer la migration en étapes. Par exemple, si la base de données source contient une grande quantité de données en lecture seule, elle peut être migrée avant la migration des données en temps réel pour réduire le temps d'inactivité.