Architecture multitenant Oracle 12c

Une des principales améliorations d'Oracle 12c est l'architecture multitenant ou bases de données enfichables.

Historiquement, Oracle a une architecture monobase de données, contrairement à la plupart de ses concurrents.

Dans Oracle, au niveau logique, une table se situe dans un schéma logé dans une base de données. Une instance Oracle contient une seule base de données (à l'exception notable du cluster qui peut faire pointer plusieurs instances sur la même base, mais ceci ne change rien au sujet qui nous occupe).

Chez la plupart des concurrents d'Oracle, nous avons une couche d'abstraction supplémentaire, car une instance peut contenir plusieurs bases de données.

Il est plus difficile de faire cohabiter plusieurs applications disparates dans une même instance Oracle :

• nécessité de créer plus d'instances ;
• coût supplémentaire en ressources ;
• hardware supplémentaire nécessaire ;
• coût supplémentaire en licences ;
• le jeu de caractères doit être similaire pour toute l'instance.

Pour les rares administrateurs de bases de données qui se sont prêtés au jeu de la fusion d'applications par affinité de schéma, d'autres problèmes surgissent :

1. Deux applications ayant des schémas/tables de même nom ne peuvent coexister, ou alors avec force bricolage ;
2. La gestion des droits Oracle est très limitée : on ne peut donner des droits qu'au niveau des objets (grant select on owner.tablename to…), au niveau de son propre login (grant select table to…) ou au niveau de l'instance dans sa globalité (grant select any table to…). Les rôles utilisateur sont quant à eux mal intégrés, pas pris en compte par les objets compilés : si l'on crée une vue dans un schéma, pointant sur un autre schéma, le grant select sur toutes les tables cibles doit être explicite, et les rôles ne sont pas pris en compte ;
3. Si une application est multischéma ou si l'on dissocie le connecteur du schéma, on se retrouve confronté à devoir donner les droits au niveau des objets, avec les soucis que cela génère au niveau des tables générées à la volée.

Create user a identified by toto ;
Create user b identified by toto quota unlimited on USERS;
Grant create session, create view to a ;
Grant create session, create role, create table to b ;
            
Connect b/toto 
Create table tb (i int) ;
insert into tb values(1) ;
commit ;
create role roleb ;
grant select on tb to roleb ;
grant roleb to a ;
            
connect a/toto 
Create view a.va as select i from b.tb ;
Create view a.va as select i from b.tb
              *
ERREUR A  la ligne 1 :
ORA-01031: privilèges insuffisants
            
Connect b/toto
Grant select on tb to a ;
            
connect a/toto
Create view a.va as select i from b.tb ;
Vue créée.

En singeant le modèle de ses concurrents, on peut traduire le nouveau modèle Oracle de la manière suivante :

• Pluggable databases Oracle (PDB) = bases de données utilisateur ;
• Container database Oracle (CDB) = base de données système.

1. L'architecture multitenant est soumise à licence (et elle est chère !) et nécessite l'Enterprise Edition. En fait, on peut la tester avec les autres éditions « gratuitement », mais uniquement avec une seule base enfichable… autant dire que cela n'amène rien ;
2. Ressources humaines : ce n'est pas tant le nombre d'instances Oracle qui détermine le nombre de DBA à engager pour les administrer que la complexité du système. L'architecture multitenant n'apportera donc pas d'économie substantielle en ce sens… si ce n'est lors de la restauration d'une base de données qui pourra se faire plus simplement et plus rapidement ;
3. Utilisateurs et privilèges : la nouvelle architecture permet la fusion de deux bases pré12c sans problème, en intégrant la gestion des droits et utilisateurs locaux. Elle ne permet par contre pas de résoudre les soucis existants précités. Le GRANT … CONTAINER ne permet que les options CURRENT (= base locale) ou ALL (instance) : à regret, on ne peut spécifier le nom d'un autre container. Oracle ne résout donc que très partiellement la problématique des droits multiapplicatifs ;
4. Le jeu de caractères des bases enfichables doit être le même que la base container. Cela équivaut à maintenir la contrainte d'un jeu de caractères par instance. L'architecture multitenant ne résout rien à ce niveau. Elle se retrouve au même niveau que SAP ASE, mais moins souple que MS-SQL Server qui autorise un jeu de caractères distinct par base, voire par table ;
5. La version de la base de données principale (container) est la même que toutes les bases enfichables ;
6. Les archivelogs sont propres à la CDB : si l'on souhaite répliquer une base enfichée, c'est le lot complet d'archivelogs qui sera malgré tout transféré…

1. Au niveau de l'espace disque, le gain ne se fera que sur l'économie des tablespaces système d'Oracle (temporary tablespaces, undo, redo, system, sysaux) qui ne seront plus démultipliés. Par contre, la fusion nécessitera peut-être de plus gros fichiers… donc le gain risque d'être neutre ;
2. Au niveau mémoire (SGA), c'est là que le gain est le plus important. La fusion des instances permet une gestion plus performante des caches si vos bases ne sont pas intensivement utilisées la majeure partie du temps. Mais le modèle de licence Oracle est insensible à la quantité de mémoire… ;
3. Au niveau CPU, on gagera que ce ne sont pas les schémas système qui sont le plus gourmands. Parions que deux applications ayant chacune son instance sur une machine dédiée à Oracle généreront la même consommation CPU si elles se retrouvaient dans une instance multitenant.

• créer une base en quelques secondes, puisque la recréation du métamodèle se fait par clonage ;
• restaurer une base plus simplement et plus rapidement.

Le gain n'est pas extraordinaire quant aux gains en ressources et aux limites historiques que l'on aurait espéré voir disparaître. Tout ce qui pouvait être amélioré rapidement l'a été… les principales pierres d'achoppement restent : une gestion enrichie des droits avec une granularité au niveau base, un jeu de caractères indépendant de la container database…

On se réjouit donc de voir ce qui nous attendra dans les versions à venir.

Mes remerciements à

• Frank Pachot et Waldar, pour leurs remarques techniques ;
• Claude Leloup, pour sa relecture orthographique.