Architecture Multitenant

1. CDB et PDB

Depuis la version 12c, avec l’architecture Multitenant, vous pouvez concevoir votre base de données pour qu’elle soit une base de données conteneur (container database - CDB) qui va inclure une ou plusieurs bases de données dites "enfichables" (pluggable database - PDB).

Le terme multitenant pourrait être traduit en français par "multi-locataire", illustrant ainsi le fait qu’une base de données conteneur "héberge" plusieurs "locataires" que sont les bases de données enfichables.

Le schéma suivant présente de façon simplifiée l’architecture d’une base de données conteneur avec son instance :

Une base de données conteneur est composée obligatoirement d’un conteneur racine (Root ou CDB Root) et d’une base de données enfichable d’amorçage (Seed ou PDB Seed), et de zéro ou plusieurs bases de données enfichables "utilisateurs" (PDB), dans la pratique au minimum une puisque c’est dans une PDB "utilisateur" (simplement appelée PDB dans la suite) que seront créés les objets des applications (tablespace, tables, index, utilisateurs, etc.).

Pour un utilisateur ou une application, les PDB apparaissent logiquement comme des bases de données distinctes traditionnelles complètement isolées les unes des autres.

Dans la terminologie utilisée par Oracle, le terme "conteneur" désigne à la fois la base de données conteneur (CDB) dans son ensemble, parfois appelée "conteneur système", mais aussi la CDB Root et les différentes PDB (dont la PDB seed). Cela peut être parfois une source de confusion.

Dans cet ouvrage, afin d’éviter des traductions hasardeuses, les termes anglais, ou leurs abréviations, seront utilisés pour désigner les différentes composantes de cette architecture : CDB, PDB, CDB Root, PDB Seed, etc.

La base de données conteneur (CDB) porte un nom défini lors de sa création par le paramètre d’initialisation DB_NAME du fichier de paramètres, comme pour une base de données traditionnelle. Cette base de données conteneur est ouverte de façon...

1. Vue d’ensemble

Pour créer une base de données Multitenant, la première chose à faire consiste à créer la base de données CDB proprement dite qui contiendra initialement au minimum la CDB Root et la PDB Seed. Cette création s’effectue avec l’assistant Configuration de base de données (DBCA) comme pour une base de données non CDB. Lors de la création de la CDB, il est possible de créer aussi une ou plusieurs PDB, mais cette opération est le plus souvent effectuée dans un deuxième temps.

Pour créer une PDB, il existe plusieurs possibilités présentées dans l’organigramme suivant :

Ces différentes opérations peuvent être effectuées avec l’ordre SQL CREATE PLUGGABLE DATABASE dans un outil comme SQL*Plus, SQLcl ou SQL Developer. Elles peuvent aussi être effectuées dans un outil graphique comme l’assistant Configuration de base de données (DBCA), SQL Developer ou EM Express.

Il existe de nombreuses méthodes pour migrer une base de données non CDB en PDB au sein d’une CDB, parmi lesquelles :

Comme nous l’avons indiqué en introduction, il existe des catégories de PDB un peu plus avancées (PDB proxy, copie snapshot, Application Root) qui se créent elles aussi avec l’ordre SQL CREATE PLUGGABLE DATABASE. Ces cas particuliers ne sont pas présentés dans cet ouvrage.

2. Création de la CDB

La création...

1. Démarrage et arrêt

Lorsqu’une CDB est ouverte, les PDB peuvent être ouvertes ou fermées indépendamment les unes des autres. Par contre, les PDB sont dépendantes de l’ouverture de la CDB : si la CDB est arrêtée (instance arrêtée), les PDB sont aussi forcément arrêtées ; si la CDB est montée (MOUNT), les PDB sont elle aussi forcément montées. De plus, dans une CDB ouverte en lecture/écriture, les PDB peuvent être ouvertes en lecture écriture ou en lecture seule indépendamment les unes des autres. Enfin, il est aussi possible d’activer et de désactiver le mode RESTRICTED SESSION sur les PDB individuellement.

Le mode d’ouverture des PDB peut être visualisé avec la colonne OPEN_MODE de la vue V$PDBS ou avec la commande SHOW PDBS dans SQL*Plus ou SQLcl.

La première chose à faire est donc d’ouvrir la CDB en tant que telle (conteneur principal), à l’aide de la commande habituelle STARTUP, en étant connecté à la CDB Root dans SQL*Plus ou SQLcl.

Exemple

SQL> STARTUP 
Instance ORACLE lancée. 
Total System Global Area 1073739248 bytes 
Fixed Size                  9274864 bytes 
Variable Size             373293056 bytes 
Database Buffers          683671552 bytes 
Redo Buffers                7499776 bytes 
Base de données montée. 
Base de données ouverte.  
 
SQL> SHOW PDBS 
    CON_ID CON_NAME                       OPEN MODE  RESTRICTED 
---------- ------------------------------ ---------- ---------- 
         2 PDB$SEED                       READ ONLY  NO 
         3 PDBRH                         ...

1. Gestion des tablespaces et des fichiers de données

Dans une base de données conteneurs, chaque conteneur possède ces propres tablespaces, avec notamment les tablespaces SYSTEM et SYSAUX, ainsi qu’un tablespace temporaire et éventuellement un tablespace d’annulation selon le mode de gestion de l’annulation (abordé dans la suite).

En complément, chaque conteneur peut posséder un ou plusieurs tablespaces pour le stockage des schémas des différentes applications.

Dans la pratique, les schémas des différentes applications seront stockés dans les PDB et il n’y aura aucun objet applicatif dans la CDB Root. De ce fait, il ne sera pas nécessaire de créer des tablespaces supplémentaires dans la CDB Root, sauf éventuellement pour des besoins liés à l’administration de la base de données (par exemple, pour stocker le schéma d’un outil tiers de surveillance de la base de données).

Le tablespace SYSTEM dans la CDB Root stocke les définitions (métadonnées) de tous les objets fournis par Oracle (tables et vues du dictionnaire de données, packages fournis par Oracle, etc.). Le tablespace SYSTEM dans une PDB stocke uniquement les définitions des objets "utilisateurs" stockés dans la PDB, mais les définitions communes de la CDB Root sont rendues visibles par des mécanismes internes de lien. Du coup, le tablespace SYSTEM des PDB est beaucoup plus petit que celui de la CDB Root, alors qu’il semble contenir plus ou moins la même quantité d’informations lors de l’interrogation de certaines vues du dictionnaire de données :

SQL> SELECT con_id,tablespace_name,SUM(bytes)/1024/1024 mbytes 
  2  FROM cdb_data_files 
  3  WHERE tablespace_name = 'SYSTEM' 
  4  GROUP BY con_id,tablespace_name; 
    CON_ID TABLESPACE     MBYTES 
---------- ---------- ---------- 
         1 SYSTEM            890 -- CDB Root 
 ...

1. Principes

Dans une base de données conteneur, il est possible de définir des utilisateurs communs qui seront créés dans la CDB Root et qui existeront implicitement dans toutes les PDB. Sous réserve d’avoir le privilège CREATE SESSION, un utilisateur commun peut se connecter à n’importe quelle PDB, avec le même nom et le même mot de passe.

À l’inverse, un utilisateur créé dans une PDB est un utilisateur local qui existe uniquement dans cette PDB et qui ne pourra pas se connecter ni à la CDB Root ni à une autre PDB. Il est possible de créer deux utilisateurs ayant le même nom dans deux PDB différentes, mais ce seront bien deux utilisateurs différents (qui pourront avoir des mots de passe différents).

De la même manière, il est possible de créer des rôles communs ou locaux, ainsi que des profils communs ou locaux.

Les noms des utilisateurs, rôles et profils communs doivent commencer par un préfixe bien précis, c## ou C##. Ce préfixe est en fait défini par le paramètre COMMON_USER_PREFIX ; la valeur de ce paramètre peut être modifiée, et il est même possible de lui affecter une chaîne vide, mais à vos risques et périls. Par conséquent, les noms des utilisateurs, rôles et profils locaux ne doivent pas commencer par ce préfixe.

Un utilisateur commun peut avoir des privilèges différents dans les différentes PDB. L’attribution d’un privilège ou d’un rôle commun à un utilisateur commun (ou à un rôle commun) peut être locale ou commune. En cas d’attribution locale, le privilège peut être exercé uniquement dans le conteneur dans lequel il a été attribué. En cas d’attribution commune, le privilège peut être exercé dans tous les conteneurs (actuels et futurs). Pour un utilisateur local, l’attribution d’un privilège ou d’un rôle (local ou commun) est forcément locale.

Plusieurs ordres SQL relatifs à la gestion des utilisateurs et des droits peuvent avoir une clause CONTAINER qui accepte deux valeurs :

1. Principes

RMAN peut être utilisé pour sauvegarder et récupérer les différents conteneurs d’une base de données Multitenant :

En complément, comme dans une base de données non CDB, RMAN peut sauvegarder et récupérer des fichiers individuellement (fichiers de données, tablespaces, fichier de contrôle, fichier de paramètre serveur, etc.).

Les mêmes opérations qu’avec une base de données non CDB peuvent être effectuées (sauvegarde complète ou incrémentale, récupération complète ou incomplète, etc.), avec les mêmes commandes RMAN (même syntaxe avec parfois quelques différences mineures).

Si vous disposez déjà d’un script RMAN de sauvegarde d’une base de données non CDB, celui-ci fonctionnera normalement sans aucune modification pour sauvegarder la base de données conteneur dans son ensemble (CDB Root et toutes les PDB), en se connectant à la CDB Root.

Ce point est important et intéressant, car en fonctionnement normal, le plan de sauvegarde journalier classique consiste à sauvegarder la totalité de la base de données conteneur, à l’identique que ce qui est fait dans une base de données non CDB.

De même, à quelques restrictions près évoquées ci-dessous, ce script fonctionnera aussi sans aucune modification pour sauvegarder une PDB, en se connectant à celle-ci.

Le fait de pouvoir sauvegarder une PDB séparément du reste, en dehors du plan de sauvegarde journalier, est intéressant dans le cas où une opération particulière aurait été effectuée sur cette PDB (création, clonage, déplacement, chargement de données, etc.). C’est un peu l’équivalent d’une sauvegarde partielle (quelques tablespaces) qui pourrait être réalisée dans une base de données non CDB suite à une opération particulière sur une application.

Plusieurs opérations ne sont pas autorisées dans RMAN en étant connecté à...

1. Data Pump

Data Pump peut être utilisé pour effectuer des opérations d’export/import dans différentes situations :

L’utilisation de Data Pump avec une PDB est identique à une non CDB, mais il faut noter que l’utilisation de Data Pump n’est normalement pas nécessaire au niveau de la CDB Root, puisqu’il n’y a généralement pas de données applicatives dans ce conteneur. Lors de l’utilisation de Data Pump en étant connecté à la CDB Root, un message d’avertissement est affiché :

Avertissement : les opérations Oracle Data Pump ne sont généralement pas nécessaires en cas de connexion à la racine ou à la valeur de départ d'une base de données Conteneur. 

Dans ce message, "racine" désigne la CDB Root et "valeur de départ" la PDB Seed.

La principale particularité à noter concerne l’utilisation de l’objet DIRECTORY DATA_PUMP_DIR. 

Dans une base de données conteneur, cet objet DIRECTORY est défini au niveau de la CDB Root et il impose un chemin pour chaque PDB avec un sous-répertoire par PDB dont le nom est égal au GUID (Global Unique IDentifier) de la PDB :

SQL> SELECT...