Quand on interroge les sociétés ayant migré leurs applications vers des modèles de type « Cloud » sur leurs motivations, la première raison invoquée n’est pas celle du cout mais celle de la souplesse apportée.
Oracle a bien compris cela avec l’architecture « Multitenant » (pour plus d’information sur l’architecture Multitenant : http://blog.easyteam.fr/2013/06/26/oracle-database-12c-new-feature-pluggable-database-multitenant-architecture)

Problématique

Nous allons évoquer ici une problématique bien connue des administrateurs de bases de données Oracle (DBAs) : la gestion des environnements de test et recette.
Il est courant au sein d’une équipe de développement (et/ou de recette) de vouloir multiplier les bases de données pour les raisons suivantes :

• Pouvoir scinder les développements en plusieurs lots indépendants et réaliser les tests associés
• Accélérer les phases de recette (non-regression, performance, user-acceptance etc)

Le problème c’est que chaque base de données nécessite plusieurs interventions du DBA :

• Création initiale de la base de données
• Rafraichissement à fréquence régulière ou non
• Suppression

Ce qui fait qu’il y a souvent « conflit » quand au nombre de bases de données et leur gestion …..

Solution

Nous proposons l’utilisation de l’architecture « Multitenant », non à des fins de consolidation (encore que ce soit un bénéfice collatéral non négligeable) mais pour gagner en « souplesse« .
Nous allons montrer ici la simplicité avec laquelle, dans ce type d’architecture,  nous pouvons dupliquer une base de données (« pluggable database ») soit à des fins de création, soit à des fins de rafraichissement des données.

Démonstration

Soit une base de données en « container » nommée « MYCDB » hébergeant une base de données « pluggable » nommée « MYPDB01 » :

SQL> select database_name from v$instance;
DATABASE_NAME
--------------------------------------------------------------------------------
MYCDB
SQL> select pdb_id,pdb_name from cdb_pdbs;
PDB_ID PDB_NAME
------ --------------------
     3 MYPDB01
     2 PDB$SEED

Nous allons dupliquer « MYPDB01 » en « MYPDB02″ via »sqlplus » (au préalable il nous faut mettre « MYPDB01 » en « read-only ») :

SQL> alter pluggable database mypdb01 close;
Pluggable database altered.
SQL> alter pluggable database mypdb01 open read only;
Pluggable database altered.
SQL> create pluggable database MYPDB02 from MYPDB01
     file_name_convert=('MYPDB01','MYPDB02');
Pluggable database created.

Il ne nous reste plus qu’à réouvrir « MYPDB01 » et ouvrir « MYPDB02 » :

SQL> alter pluggable database mypdb01 close;
Pluggable database altered.
SQL> alter pluggable database mypdb01 open;
Pluggable database altered.
SQL> alter pluggable database mypdb02 open;
Pluggable database altered.
SQL> select pdb_id,pdb_name from cdb_pdbs;
PDB_ID PDB_NAME
------ --------------------
     3 MYPDB01
     2 PDB$SEED
     4 MYPDB02

En réalité Oracle recopie les fichiers de la base de données « MYPDB01 », fichiers se trouvant « naturellement » (et par défaut) dans l’arborescence de la CDB l’hébergeant : « MYCDB »

[root@oel6-db12C MYCDB]# pwd
/u01/app/oracle/oradata/MYCDB
[root@oel6-db12C MYCDB]# ls -l
total 1765296
-rw-r-----. 1 oracle dba  17973248 Jul  4 17:22 control01.ctl
drwxr-x---. 2 oracle dba      4096 Jul  4 17:05 MYPDB01
drwxr-x---. 2 oracle dba      4096 Jul  4 17:21 MYPDB02
drwxr-x---. 2 oracle dba      4096 Jul  4 16:47 pdbseed
-rw-r-----. 1 oracle dba  52429312 Jul  4 17:01 redo01.log
-rw-r-----. 1 oracle dba  52429312 Jul  4 17:01 redo02.log
-rw-r-----. 1 oracle dba  52429312 Jul  4 17:21 redo03.log
-rw-r-----. 1 oracle dba 723525632 Jul  4 17:20 sysaux01.dbf
-rw-r-----. 1 oracle dba 807411712 Jul  4 17:21 system01.dbf
-rw-r-----. 1 oracle dba  62922752 Jul  4 17:15 temp01.dbf
-rw-r-----. 1 oracle dba  94380032 Jul  4 17:22 undotbs01.dbf
-rw-r-----. 1 oracle dba   5251072 Jul  4 17:01 users01.dbf

Il existe d’autres méthodes non développées ici pour « dupliquer » des bases de données « pluggable » :

• « Create pluggable database » à travers un dblink
• Plug / Unplug (même concept que le « pack/unpack » d’ Oracle Weblogic)
• Recovery Manager (RMAN)

Conclusion

Dupliquer une base de données est maintenant simple et rapide, de plus avec l’architecture « Multitenant » ajouter une base de données (« pluggable ») a un impact plus faible sur la consommation de mémoire et CPU que dans le passé.
En conséquence :

• le nombre de base de données risque de se multiplier sur un serveur  (limitation par le stockage principalement)
• la fréquence de rafraichissement des environnements va pouvoir augmenter
• la question de déléguer la gestion de certains « containers » aux équipes intéressées va naturellement se poser (auparavant nous étions limités par les compétences techniques nécessaires)

Comment cela se passe t-il dans votre entreprise ? -> faites nous part de vos expériences utilisateur !