Oracle a introduit l’architecture multitenant en 12c. Le but du multitenant est la consolidation. Au lieu d’avoir plusieurs bases de données sur un serveur, vous pouvez maintenant créer une base de données consolidée appelée la CDB. Le CDB peut contenir plusieurs bases de données pluggables (PDB). Pour une application, un PDB apparaîtrait comme s’il s’agissait d’une base de données distincte. Mais en coulisses, il y a une instance, un ensemble de processus en arrière-plan, un pool partagé, et ainsi de suite. Cette architecture est basée sur le partage de données entre les CDB et les PDB. Avec le multitenant, Oracle a conçu l’architecture de façon à ce que les informations du dictionnaire existent dans le CDB tandis que les segments de données d’application restent privés au PDB.
Dans cet article, nous expliquerons comment fonctionne le partage de données entre PDB et CDB. Oracle 19c Database permet trois techniques différentes de partage de données :
- Lien de métadonnées
- Liaison de données
- Liaison de données étendue
Ces méthodes de partage sont celles utilisées en interne par les bases de données Oracle pour obtenir une architecture multilocataire. À partir de la version 12.2, Oracle 19c Database permet aux utilisateurs de créer leurs propres conteneurs racines d’application puis de créer des PDB à l’intérieur des conteneurs applicatifs. Le conteneur d’application racine est un PDB vers son conteneur principal – CDB$ROOT.
Commençons par un cas test. Nous allons d’abord créer un conteneur d’application puis un PDB à l’intérieur du conteneur. Ces tests sont effectués sur un Oracle Database 19c fonctionnant sur une plateforme Windows. Nous avons déjà installé un conteneur racine appelé ART01.
Connectez-vous en tant que SYSDBA sur ART01.
SQL> create pluggable database app_container as application container admin user admin identified by oracle file_name_convert=('D:\app\testart\oradata\ART01','D:\app\testart\oradata\app_container');
Pluggable database created.
SQL> alter session set container=app_container;
Session altered.
SQL> alter pluggable database open;
Pluggable database altered.
SQL> create pluggable database APP_PDB1 admin user pdb1admin identified by oracle file_name_convert=('D:\app\testart\oradata','D:\app\testart\oradata\APP_PDB1');
Pluggable database created.
SQL> alter pluggable database APP_PDB1 open;
Pluggable database altered.
Nous avons maintenant un conteneur d’applications appelé APP_CONTAINER. Et ce conteneur a un PDB appelé APP_PDB1.
Maintenant, connectons-nous à APP_CONTAINER et créons des objets partagés. Nous allons créer trois tableaux.
- ML_T : Une table liée aux métadonnées
- EL_T : Une table étendue liée aux données
- DL_T : Une table de liaison de données
Notez que pour pouvoir créer des objets partagés, le conteneur racine de l’application doit être en mode installation ou mise à niveau.
SQL> alter session set container=APP_CONTAINER;
Session altered.
SQL> alter pluggable database application app_container begin install '1';
Pluggable database altered.
SQL> create table ML_T SHARING=METADATA (A NUMBER);
Table created.
SQL> create table EL_T SHARING=EXTENDED DATA(A NUMBER);
Table created.
SQL> create table DL_T SHARING=DATA (A NUMBER);
Table created.
SQL> alter pluggable database application app_container end install '1';
Pluggable database altered.
SQL> alter session set container=APP_PDB1;
Session altered.
SQL> alter pluggable database application app_container sync;
Pluggable database altered.
TABLEAU DES LIENS DE MÉTADONNÉES
=====================
La table ML_T est une table liée aux métadonnées. La définition de la table ou les métadonnées sont stockées dans le conteneur applicatif, mais le segment de données réel est privé à chacun des conteneurs. La commande Sync exécutée dans l’exemple ci-dessus est une copie à usage unique, donc le Oracle database peut créer le segment de données réel dans les PDB. Maintenant, le tableau ML_T existe en APP_CONTAINER et en APP_PDB1. Ils partagent le dictionnaire de données, mais les données sont privées à chacun des conteneurs.
SQL> alter session set container=APP_CONTAINER;
Session altered.
SQL> insert into ML_T values(1);
1 row created.
SQL> commit;
Commit complete.
SQL> select * from ML_T;
A
----------
1
SQL> alter session set container=APP_PDB1;
Session altered.
SQL> insert into ML_T values(2);
1 row created.
SQL> commit;
Commit complete.
SQL> select * from ML_T;
A
----------
2
Comme montré ci-dessus, le segment de données ML_T est privé. APP_PDB1 ne peut voir que ses données (2). Tandis que APP_CONTAINER ne peut voir que sa version des données (1).
TABLEAU ÉTENDU DES LIENS DE DONNÉES
==========================
La EL_T est une table étendue de liaison de données. Les métadonnées sont partagées et les données existent dans les deux conteneurs. Le PDB peut accéder à ses propres données ainsi qu’aux données du conteneur applicatif.
SQL> alter session set container=APP_CONTAINER;
Session altered.
SQL> insert into EL_T values(1);
1 row created.
SQL> commit;
Commit complete.
SQL> select * from EL_T;
A
----------
1
SQL> alter session set container=APP_PDB1;
Session altered.
SQL> insert into EL_T values(2);
1 row created.
SQL> commit;
Commit complete.
SQL> select * from EL_T;
A
----------
2
1
Comme montré ci-dessus, cette dernière requête donne 1,2. Il affiche les données de la APP_CONTAINER et de la APP_PDB1. Dans la base de données APP_PDB1 référentielle, les lignes de la table EL_T peuvent être modifiées, mais pas celles provenant du conteneur applicatif.
TABLE DES LIAISONS DE DONNÉES
================
DL_T est une table liée aux données. Le segment de données n’existe que dans le APP_CONTAINER. Les données ne peuvent pas être modifiées dans le PDB. Mais le PDB peut voir les données stockées dans le conteneur root.
SQL> alter session set container=APP_CONTAINER;
Session altered.
SQL> insert into DL_T values(1);
1 row created.
SQL> commit;
Commit complete.
SQL> alter session set container=APP_PDB1;
Session altered.
SQL> select * from DL_T;
A
----------
1
Toute tentative de modifier ces données entraînerait une erreur.
SQL> update DL_T set A=99;
update DL_T set A=99
*
ERROR at line 1:
ORA-65097: DML into a data link table is outside an application action
Jusqu’à présent, nous avons vu des tableaux partagés, de la même façon nous pouvons aussi créer des vues partagées. Regardons quelques exemples.
OPINIONS PARTAGÉES
==============
Voici la création d’une vue de lien de données appelée DL_V. Cette vue sélectionne les données de la table ML_T qui est une table liée aux métadonnées que nous avons créée précédemment.
Il y a une autre vue appelée EL_V qui est une vue de liaison de données étendue. Cette vue sélectionne également des données provenant de la même table liée aux métadonnées, ML_T.
SQL> alter session set container=APP_CONTAINER;
SQL> alter pluggable database application app_container begin upgrade '1' to '2';
Pluggable database altered.
SQL> create view DL_V SHARING=DATA AS (SELECT * FROM ML_T);
View created.
SQL> create view EL_V SHARING=EXTENDED DATA AS (SELECT * FROM ML_T);
View created.
SQL> alter pluggable database application app_container end upgrade;
Pluggable database altered.
SQL> alter session set container=APP_PDB1;
Session altered.
SQL> alter pluggable database application app_container sync;
Pluggable database altered.
SQL> select * from DL_V;
A
----------
1
Dans l’exemple ci-dessus, nous sommes connectés à APP_PDB1. Nous savons que sélectionner à partir de ML_T nous donne la sortie de « 2 ». Mais en choisissant à partir de cette vue, DL_V, on obtient « 1 ».
Cela s’explique par le fait que la vue elle-même est définie comme un lien de données. Cela instruit le Oracle database pour extraire les données du conteneur racine de l’application et non du PDB actuel. Si vous voulez extraire les données du APP_PDB1 courant, utilisez la fonction fournie par Oracle NO_OBJECT_LINK.
SQL> select * from NO_OBJECT_LINK(DL_V);
A
----------
2
SQL> select * from EL_V;
A
----------
2
1
Vous pouvez voir un comportement similaire ici. En sélectionnant dans le tableau ML_T on obtient la sortie de '2'. Mais en choisissant dans cette vue , EL_V, on obtient 1,2, simplement parce que la vue est un lien de données étendu.
Le Oracle database extrait les données à la fois du conteneur racine de l’application (APP_CONTAINER) et du PDB actuel (APP_DB1). Encore une fois, si vous voulez extraire les données uniquement du PDB actuel, utilisez la fonction NO_OBJECT_LINK.
SQL> select * from NO_OBJECT_LINK(DL_V);
A
----------
2
L’utilisation des méthodes de partage de Metadata Link, Data Link ou Extended Data Link peut être très bénéfique et constitue un moyen simple de libérer tout le potentiel de l’infrastructure de la base de données et d’utiliser la fonctionnalité multilocataire consolidée offerte par Oracle 19c Database. Le partage de données est devenu une capacité clé et est essentiel pour augmenter votre potentiel de gestion de base de données. C’est l’une des fonctionnalités les plus instructives axées sur les données sorties avec la version 19c.