Oracle Multitenant : connexion, navigation et pièges quotidiens

Comprendre la connexion

Premier réflexe à avoir : le mode de connexion détermine le container dans lequel vous arrivez.

-- Connexion locale / as sysdba
-- → Vous êtes DANS le CDB (root)
sqlplus / as sysdba

-- Connexion via service
-- → Vous êtes directement dans la PDB cible
sqlplus sys/oracle@//host/pdb19:1521 as sysdba

Quand vous utilisez / as sysdba en local, vous atterrissez toujours dans le CDB$ROOT. Pour travailler dans une PDB, il faut soit utiliser un service, soit switcher de container.

Lister les PDB et les services

-- Lister toutes les PDB depuis le CDB
SQL> show pdbs

    CON_ID CON_NAME    OPEN MODE  RESTRICTED
---------- ----------- ---------- ----------
         2 PDB$SEED    READ ONLY  NO
         3 PDB19       READ WRITE NO
         4 PDB20       READ WRITE NO

-- Lister les services disponibles
SQL> select NAME, CON_ID, pdb from v$services order by name;

NAME           CON_ID PDB
-------------  ------ ----------
ORCL19              1 CDB$ROOT
ORCL19XDB           1 CDB$ROOT
SYS$BACKGROUND      1 CDB$ROOT
SYS$USERS           1 CDB$ROOT
pdb19               3 PDB19
pdb20               4 PDB20

Notez que chaque PDB possède son propre service, créé automatiquement lors de sa création. Vous pouvez le vérifier côté listener :

$ lsnrctl services

Service "pdb20" has 1 instance(s).
  Instance "ORCL19", status READY, has 1 handler(s) for this service...
    Handler(s):
      "DEDICATED" established:5 refused:0 state:ready
         LOCAL SERVER

Naviguer entre les containers

Une fois connecté au CDB, utilisez alter session set container pour changer de contexte :

-- Se connecter à PDB20
SQL> alter session set container=pdb20;

Session altered.

SQL> show pdbs

    CON_ID CON_NAME    OPEN MODE  RESTRICTED
---------- ----------- ---------- ----------
         4 PDB20       READ WRITE NO

-- Revenir au CDB root
SQL> alter session set container=cdb$root;

Session altered.

SQL> show pdbs

    CON_ID CON_NAME    OPEN MODE  RESTRICTED
---------- ----------- ---------- ----------
         2 PDB$SEED    READ ONLY  NO
         3 PDB19       READ WRITE NO
         4 PDB20       READ WRITE NO

Connexion directe à une PDB avec SQL*Plus

$ sqlplus sys/oracle@//host19/pdb20:1521 as sysdba

Connected to:
Oracle Database 19c Standard Edition 2
Release 19.0.0.0.0 - Production
Version 19.14.0.0.0

SQL> show pdbs

    CON_ID CON_NAME    OPEN MODE  RESTRICTED
---------- ----------- ---------- ----------
         4 PDB20       READ WRITE NO

La chaîne de connexion utilise le service de la PDB (pdb20) et non celui du CDB. Le plus simple est de récupérer le nom du service depuis v$services ou depuis la sortie de lsnrctl services.

Gérer l'ouverture des PDB

Une PDB peut être montée mais pas ouverte. Cela arrive après un redémarrage du CDB si l'état n'a pas été sauvegardé :

-- Ouvrir une PDB
ALTER PLUGGABLE DATABASE pdb20 OPEN;

-- Sauvegarder l'état pour persister après redémarrage
ALTER PLUGGABLE DATABASE pdb20 SAVE STATE;

Sans SAVE STATE, la PDB restera en mode MOUNT au prochain redémarrage du CDB. C'est une source d'incidents fréquente quand on migre des bases pré-12c vers l'architecture multitenant.

Fichiers de données d'une PDB

Chaque PDB possède ses propres datafiles, physiquement isolés :

SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/ORCL19/DED84E1D96A09D43E053A81FA8C06640/datafile/o1_mf_system_k7tz8w0x_.dbf
/u01/app/oracle/oradata/ORCL19/DED84E1D96A09D43E053A81FA8C06640/datafile/o1_mf_sysaux_k7tz8w0y_.dbf
/u01/app/oracle/oradata/ORCL19/DED84E1D96A09D43E053A81FA8C06640/datafile/o1_mf_undotbs1_k7tz8w0z_.dbf
/u01/app/oracle/oradata/ORCL19/DED84E1D96A09D43E053A81FA8C06640/datafile/o1_mf_users_k7tz8w0z_.dbf

Les datafiles sont stockés dans un répertoire propre à la PDB, avec un OID unique. Si vous créez un tablespace, le fichier apparaît dans le même répertoire :

SQL> create tablespace tbs_index datafile size 10M autoextend on ;

Tablespace created.

SQL> select name from v$datafile;
-- → un nouveau fichier apparaît dans le même dossier OID

Pièges à éviter

• Paramètres au niveau CDB vs PDB : certains paramètres (comme optimizer_features_enable) peuvent être positionnés différemment selon le container
• Jobs scheduler : les jobs DBMS_SCHEDULER sont propres à chaque PDB — vérifiez dans quel container vous les créez
• RMAN : la connexion au CDB permet de backuper toutes les PDB, mais une connexion à une PDB ne backupera que celle-ci
• Audit unifié : les politiques d'audit se configurent au niveau CDB et s'appliquent à toutes les PDB

À retenir : "Dans quel container suis-je ?" — cette question doit devenir un réflexe. show pdbs et show con_id sont vos meilleurs amis.