La migration d'Oracle 12c vers 19c, c'est un chantier que j'ai mené l'année dernière pour une base de 4 To dans le secteur bancaire. Voici le retour d'expérience concret : ce qui s'est bien passé, ce qui a coincé, et ce que je ferai différemment la prochaine fois.

Pourquoi 19c et pas 21c ou 23c ?

19c est la version Long Term Support (LTS) la plus récente, supportée jusqu'en 2028 (extended jusqu'en 2030). Pour une base bancaire, la stabilité prime sur les fonctionnalités. Pas question de partir sur une version sans recul.

Architecture cible

Paramètre Source (12c) Cible (19c)
OS Oracle Linux 7 Oracle Linux 8
Taille 4 To 4,2 To (growth)
RAC 2 nœuds 2 nœuds
Data Guard Physical Standby Physical Standby
PDB Non (non-CDB) Oui (Multitenant)

Le passage en Multitenant était le vrai challenge technique. La base 12c était en architecture legacy non-CDB.

Préparation : les vérifications qui évitent les surprises

Avant toute migration réelle, j'ai passé deux semaines sur l'analyse de compatibilité.

-- Vérifier les objets obsolètes ou incompatibles
select owner, object_type, count(*)
from dba_objects
where status != 'VALID'
group by owner, object_type;

-- Identifier les paramètres supprimés dans 19c
select name, description
from v$parameter
where name in (
  'parallel_automatic_tuning',
  'plsql_debug',
  'serial_reuse'
);

Les paramètres supprimés dans 19c peuvent causer des erreurs de démarrage. J'ai constitué une mapping list des paramètres obsolètes avec leur équivalent 19c.

Phase 1 : migration Oracle Home (5 jours)

J'ai utilisé autoupgrade.jar (outil Oracle officiel) pour la mise à niveau du logiciel Oracle.

# Analyse pré-migration
java -jar autoupgrade.jar -analysis -config myconfig.cfg

# Exécution
java -jar autoupgrade.jar -deploy -config myconfig.cfg

Problème rencontré : l'analyse autoupgrade signalait un COMPATIBLE à 12.1.0.2 qui bloquait l'upgrade. Solution : passage à 12.2.0.1 en deux étapes (12c → 12.2 → 19c), ce qui a doublé le temps prévu.

Phase 2 : conversion Multitenant (3 jours)

Le vrai morceau. J'ai utilisé noncdb_to_pdb.sql (script Oracle) pour convertir la base non-CDB en PDB.

-- Vérifier que la base est prête pour la conversion
select name, cdb from v$database;
-- Si CDB = NO, la conversion est possible

-- Nettoyer avant conversion
-- Supprimer les références aux répertoires obsolètes
drop directory DATA_PUMP_DIR;

-- Exécuter la conversion
-- (via DBMS_PDB.DESCRIBE puis plug dans le CDB)

Piège : les synonymes publics pointant vers des objets dans des schémas utilisaient des chemins absolus qui ne fonctionnaient plus après le plug. J'ai dû les recréer manuellement.

Phase 3 : test et validation (1 semaine minimum)

La phase la plus critique et souvent la plus sous-estimée.

Jour 1-2  : Tests fonctionnels par les équipes métier
Jour 3-4  : Tests de performance (comparaison AWR avant/après)
Jour 5    : Tests de basculement Data Guard
Jour 6-7  : Mise sous stress et validation des sauvegardes

Le test qui a tout sauvé : le test de rollback. J'avais préparé un script de retour arrière complet. La direction nous a demandé un "go" un vendredi soir à 23h. On a détecté un problème de performance sur une requête critique à 3h du matin. On est revenus en arrière en 45 minutes, pas de panique.

Checklist de migration

À retenir : une migration réussie n'est pas celle qui se passe sans accroc, c'est celle qui a un plan de retour viable. Testez le rollback autant que le go.

Yacine Oumghar · DBA Oracle depuis 1998 Retour au blog