www.soug.ch

Newsletter 1/2014

S W I S S O R A C L E U S E R G R O U P

· APEX et 12c multi tenant

· Audit Vault and DB Firewall

· Move Partition Online with 12c

· Oracle WebCenter Sites

SOUG Newsletter 1/2014

8 TIPS&TECHNIQUES

Apex et l’architecture multi-tenante 12c

Arnaud Berbier, dbi services

Depuis la sortie de la base de données Oracle en sa version 12c, le concept d’architecture multi-tenante amène de nouvelles stratégies de consolidation et de virtualisation de base de don-nées Oracle. Le présent article énumère cette architecture et expose les enjeux pour les appli-catifs Oracle, plus précisément Oracle Application Express.

APEX en quelques motsOracle Application Express est un

moteur développé en PL/SQL et em-barqué directement dans la base de données Oracle. Celui-ci permet de créer rapidement des applications web basées sur les objets contenus dans la base de données Oracle.

Infrastructure APEX utilisée pour cet article

Deux conteneurs de base de don-nées (CDB) et une non-CDB ont été créés afin de pouvoir tester les nou-velles fonctionnalités de l’architecture multi-tenante dans le contexte APEX. L’instance standard (DB12C01)

CON_ID NAME OPEN_MODE------ ----------- ---------- 1 CDB$ROOT READ WRITE 2 PDB$SEED READ ONLY 3 APEX READ WRITE 4 HRDB READ WRITE 5 ERPDB READ WRITE

Versions d’apex installées (DB12C01)

NAME VERSION ----------- -----------CDB$ROOT 4.2.3.00.08PDB$SEED 4.2.3.00.08APEX 4.2.3.00.08HRDB 4.2.3.00.08ERPDB 4.2.3.00.08

L’instance non standard (DB12C02)

CON_ID NAME OPEN_MODE------ ----------- ---------- 1 CDB$ROOT READ WRITE 2 PDB$SEED READ ONLY 3 PDB422 READ WRITE 4 PDB423 READ WRITE

Versions d’apex installées (DB12C01)

NAME VERSION ----------- -----------PDB422 4.2.2.00.11PDB423 4.2.3.00.08

L’instance non-CDB (DB12C03)

*********** dbi services Ltd. ***********STATUS : OPENDB_UNIQUE_NAME : DB12C03OPEN_MODE : READ WRITEDATABASE_ROLE : PRIMARYVERSION : 12.1.0.1.0CDB Enabled : NO*****************************************

Versions d’apex installées (DB12C03)

NAME VERSION ----------- -----------DB12C03 4.2.3.00.08

Versions des composants utilisésQ� �Base de données Oracle 12cR1

(12.1.0.1.1), PSU 17027533Q� � Oracle Application Express

4.2.2.00.11 et 4.2.3.00.08

La base de données Oracle et l’architecture multi-tenante

L’architecture multi-tenante du point de vue Oracle consiste à faire cohabiter plusieurs bases de données au sein d’une instance commune par-tageant ainsi les processus et les res-sources.

Avantages principaux de l’architec-ture multi-tenanteQ� 1 moteur de transactionQ� 1 stratégie de sauvegardeQ� 1 solution de haute disponibilitéQ� 1 Framework de monitoring

Figure 1: Architecture multi-tenante

Du point de vue applicatif, cela per-met d’isoler et d’administrer plus aisé-ment les instances incluses dans le conteneur de base de données.

La mise à niveau des bases et l’ap-plication de correctifs sont facilitées car ils sont effectués une seule fois pour l’ensemble des bases de données appartenant à l’instance principale.

9

SOUG Newsletter 1/2014

TIPS&TECHNIQUES 9

Afin de bien comprendre l’article voici la description des mots clés im-portants à connaître :

CDB : Base de données Oracle incluant un conteneur « ROOT » et des PDBs « pluggable DB »CDB$ROOT : Collection d’informations de schéma et de non schéma accessible pas toutes les PDBsPDB$SEED : Système de modèle qui est utilisé pour créer de nouvelle PDBPDB : Collection de schémas et utilisateurs pour une application spécifique

APEX et l’architecture multi-tenante

Dans le contexte d’APEX, l’architec-ture multi-tenante amène une autre di-mension. Il est possible d’avoir plu-sieurs moteurs APEX hébergés dans le même conteneur de base de données.

Deux types d’architecture sont pos-siblesQ� L’architecture dite standard (par

défaut)Q� L’architecture dite non standard

L’architecture standardDans ce type d’architecture, le mo-

teur APEX est installé dans la CDB$ROOT et dans la PDB$SEED. Chaque PDB créée depuis la PDB$SEED va ainsi contenir les liens dits « METADATA LINK » représentant la définition et la structure des objets.

Figure 3: Architecture standard

Dans la CDB$ROOT, les vues TAB$ et COL$ stockent la définition et la structure des tables communes au conteneur de base de données, c’est le dictionnaire commun.

Le dictionnaire propre à une PDB, est ainsi réparti entre la CD$ROOT et son conteneur. La CDB$ROOT contient la définition et la structure des objets communs. La PDB contient quant à elle, la définition et la structure de ces objets et également les informations propres au stockage des données et son contenu.

Gestion des utilisateursUn nouveau paradigme propre aux

utilisateurs est également apparu avec l’architecture multi-tenante : on parle de « Commonality ». Cela permet d’avoir des utilisateurs communs, qui ont la même identité (nom d’utilisateur/mot de passe), et ce au sein de toutes les bases de données contenues dans la CDB.

Oracle impose un standard quant à la nomenclature des utilisateurs com-muns. Il est obligatoire de les nommer avec le préfixe C##. A l’inverse, il est interdit de créer un utilisateur avec le préfixe C## en local.

Figure 2: Gestion des utilisateurs

SMS> > >

SOUG Generalversammlung Die SOUG Generalversammlung findet am 3. April 2014 statt. Anträge sind bis spätestens 26. Februar 2014 an das Sekretariat, res pektive den Vorstand zu richten:sekretariat@soug.ch, vorstand@soug.chDer Vorstand freut sich auf den Anlass und hofft auf zahlreiches Erscheinen!

SOUG Newsletter 1/2014

10 TIPS&TECHNIQUES

L’architecture non standard Dans ce type d’architecture, la

CDB$ROOT ne contient aucune infor-mation propre à APEX. APEX est ins-tallé directement au niveau de chaque PDB. Cette architecture peut être asso-ciée à l’architecture connue jusqu’ici.

Figure 4: Architecture non standard

Chaque conteneur PDB a sa propre installation d’APEX et est compléte-ment autonome des autres conteneurs PDB.

Avantages et inconvénientsLe tableau ci-dessous énumère les avantages et inconvénients des deux archi-

tectures possibles. Les informations ci-après sont données à titre indicatif et peuvent complétement changer selon l’adéquation des besoins métier.

Architecture Standard Architecture Non Standard

Homogénéité des versions d’APEX au sein d’un conteneur de base de données

Plusieurs versions d’APEX au sein du conteneur de base de données

Stratégie d’administration commune Montée de version par conteneur

Gestion du cycle de vie APEX facilité

Montée de version commune Possibilité de passer en architecture standard

Pas possible de passer en architec-ture non standard après utilisation d’APEX sans perte de données

Stratégie d’administration par conteneur PDB

Analyse des deux architectures APEX

Structure et définition des objets APEX

Dans l’architecture Standard, au niveau de la CDB$ROOT et des PDBs, les objets relatifs au schéma APEX_040200 sont dit partagés. Le type est « METADATA LINK »

SELECT COUNT(*) OBJECT_COUNT, SHARING, OBJECT_TYPE FROM USER_OBJECTS GROUP BY SHARING, OBJECT_TYPEORDER BY SHARING, OBJECT_COUNT DESC

OBJECT_COUNT SHARING OBJECT_TYPE------------ ------------- ------------- 457 METADATA LINK TRIGGER 451 METADATA LINK TABLE 268 METADATA LINK PACKAGE 260 METADATA LINK PACKAGE BODY 211 METADATA LINK VIEW 16 METADATA LINK PROCEDURE 11 METADATA LINK FUNCTION 11 METADATA LINK SYNONYM 6 METADATA LINK TYPE 3 METADATA LINK SEQUENCE 1518 NONE INDEX 198 NONE LOB 4 NONE JOB 1 NONE TABLE

11

SOUG Newsletter 1/2014

TIPS&TECHNIQUES 11

Exemple d’objet et existence dans les conteneurs

En prenant la vue APEX_WORKSPACES en exemple dans l’architecture standard, l’objet est présent dans chaque conteneur

SQL> SELECT CON.NAME, OBJ.OBJECT_ID, OBJ.OBJECT_NAME FROM CDB_OBJECTS OBJ, V$CONTAINERS CON WHERE OBJ.CON_ID = CON.CON_ID AND OBJ.OBJECT_NAME LIKE 'APEX_WORKSPACES' AND OBJ.OBJECT_TYPE = 'VIEW';

NAME OBJECT_ID OBJECT_NAME--------------------------- ------------- ----------------CDB$ROOT 89849 APEX_WORKSPACESPDB$SEED 89557 APEX_WORKSPACESAPEX 89557 APEX_WORKSPACESHRDB 89557 APEX_WORKSPACESERPDB 89557 APEX_WORKSPACES

A contrario, dans l’architecture «non standard» et au ni-veau de la CDB$ROOT, les utilisateurs et schémas propres à APEX n’existent pas. Aucun schéma APEX_040200 n’est pré-sent dans la CDB$ROOT.

Au niveau du conteneur PDB, exemple avec PDB423, les objets propres à APEX ne sont pas partagés

SQL>SELECT COUNT(*) OBJECT_COUNT, SHARING, OBJECT_TYPEFROM USER_OBJECTSGROUP BY SHARING, OBJECT_TYPEORDER BY SHARING, OBJECT_COUNT DESC;

OBJECT_COUNT SHARING OBJECT_TYPE------------ ------------- ------------- 1518 NONE INDEX 457 NONE TRIGGER 452 NONE TABLE 266 NONE PACKAGE 258 NONE PACKAGE BODY 211 NONE VIEW 198 NONE LOB 16 NONE PROCEDURE 11 NONE FUNCTION 11 NONE SYNONYM 6 NONE TYPE 4 NONE JOB 3 NONE SEQUENCE

Exemple d’objet et existence dans les containers

En exemple, la vue APEX_WORKSPACES est présente dans PDB422 et PDB423 mais pas dans la CDB$ROOT :

SQL> SELECT CON.NAME, OBJ.OBJECT_ID, OBJ.OBJECT_NAME FROM CDB_OBJECTS OBJ, V$CONTAINERS CON WHERE OBJ.CON_ID = CON.CON_ID AND OBJ.OBJECT_NAME LIKE 'APEX_WORKSPACES' AND OBJ.OBJECT_TYPE = 'VIEW';

NAME OBJECT_ID OBJECT_NAME------------------------------- --------- ----------------PDB422 93637 APEX_WORKSPACESPDB423 93642 APEX_WORKSPACES

Informations contenues dans les objets APEX Dans l’architecture standard et bien que l’identité des

objets soit les mêmes, les données différent d’un conteneur à l’autre.

Au niveau CDB$ROOT

SQL> SELECT WORKSPACE, SCHEMAS, APPLICATIONS, APEX_USERSFROM APEX_WORKSPACES;

WORKSPACE SCHEMAS APPLICATIONS APEX_USERS--------------------------- ------- ------------ ----------INTERNAL 1 14 1COM.ORACLE.APEX.REPOSITORY 1 70 0

Au niveau d’une PDB, exemple avec ERPDB

SQL> SELECT WORKSPACE, SCHEMAS, APPLICATIONS, APEX_USERS FROM APEX_WORKSPACES;

WORKSPACE SCHEMAS APPLICATIONS APEX_USERS--------------------------- ------- ------------ ----------INTERNAL 1 14 1COM.ORACLE.APEX.REPOSITORY 1 70 0APX_WS_ERPDB 1 1 1

On remarque bien que les informations contenu dans la CDB$ROOT et la PDB sont différentes. Le workspace APX_WS_ERPDB existe uniquement dans la PDB ERPDB.

Stockage de chaque schémaLes schémas propres à APEX stockent leurs données

dans la tablespace SYSAUX (par défaut) :

SQL> SELECT CON.NAME, SEG.OWNER, SEG.TABLESPACE_NAME,SUM(SEG.BYTES)/1024/1024 "Space Used in MB"FROM CDB_SEGMENTS SEG,V$CONTAINERS CONWHERE CON.CON_ID=SEG.CON_ID AND TABLESPACE_NAME='SYSAUX' AND (OWNER = 'ANONYMOUS' OR OWNER LIKE '%APEX%' OR OWNER LIKE '%FLOW%')GROUP BY CON.NAME, SEG.OWNER, SEG.TABLESPACE_NAMEORDER BY CON.NAME, SEG.OWNER;

NAME OWNER TABLESPACE_NAME Space Used in MB-------------- -------------- --------------- ----------------APEX APEX_040200 SYSAUX 264.5625APEX FLOWS_FILES SYSAUX 1.5625CDB$ROOT APEX_040200 SYSAUX 260.4375ERPDB APEX_040200 SYSAUX 264.375ERPDB FLOWS_FILES SYSAUX 3.5625HRDB APEX_040200 SYSAUX 264.375HRDB FLOWS_FILES SYSAUX 3.5625PDB$SEED APEX_040200 SYSAUX 254.3125

SOUG Newsletter 1/2014

12 TIPS&TECHNIQUES

Le stockage s’effectue dans des fichiers différents

SQL>SELECT CON.NAME, DF.TABLESPACE_NAME, DF.FILE_ID, SUBSTR(DF.FILE_NAME,INSTR(DF.FILE_NAME,'/','-1')+1,LENGTH(DF.FILE_NAME)) DATAFILEFROM V$CONTAINERS CON, CDB_DATA_FILES DFWHERE CON.CON_ID=DF.CON_ID AND TABLESPACE_NAME = 'SYSAUX'ORDER BY CON.NAME;

NAME TABLESPACE_NAME FILE_ID DATAFILE-------------- --------------- ------- ----------------------------- APEX SYSAUX 8 o1_mf_sysaux_97oqn6x8_.dbfCDB$ROOT SYSAUX 3 o1_mf_sysaux_97nqhjn3_.dbfERPDB SYSAUX 14 o1_mf_sysaux_97q8pch5_.dbfHRDB SYSAUX 12 o1_mf_sysaux_97q82c24_.dbfPDB$SEED SYSAUX 4 o1_mf_sysaux_97nqkv1p_.dbfPDB_FROM_SEED SYSAUX 20 o1_mf_sysaux_98j6z8w0_.dbf

Pour l’architecture non standard, le comportement est le même.

APEX et «COMMONALITY» des utilisateurs

Dans l’architecture standard, les utilisateurs liés à APEX sont communs à chaque conteneur. Ils ont ainsi la même identité.

Utilisateurs liés à APEX pour CDB$ROOT :

SQL> SELECT CON.NAME, USR.USER_ID, USR.USERNAME, USR.COMMON, USR.ORAC-LE_MAINTAINEDFROM CDB_USERS USR, V$CONTAINERS CONWHERE CON.CON_ID = USR.CON_ID AND (USR.USERNAME = 'ANONYMOUS' OR USR.USERNAME LIKE '%APEX%' OR USR.USERNAME LIKE '%FLOW%')AND CON.NAME ='CDB$ROOT'ORDER BY USER_ID DESC;

NAME USER_ID USERNAME COMMON ------------------ ------- ---------------------------- ------CDB$ROOT 103 APEX_REST_PUBLIC_USER YES CDB$ROOT 102 APEX_LISTENER YES CDB$ROOT 98 APEX_040200 YES CDB$ROOT 95 APEX_PUBLIC_USER YES CDB$ROOT 94 FLOWS_FILES YES CDB$ROOT 50 ANONYMOUS YES

Utilisateurs liés à APEX pour une PDB :

SQL> SELECT CON.NAME, USR.USER_ID, USR.USERNAME, USR.COMMONFROM CDB_USERS USR, V$CONTAINERS CONWHERE CON.CON_ID = USR.CON_ID AND (USR.USERNAME = 'ANONYMOUS' OR USR.USERNAME LIKE '%APEX%' OR USR.USERNAME LIKE '%FLOW%')AND CON.NAME ='ERPDB'ORDER BY USER_ID DESC;

NAME USER_ID USERNAME COMMON ------------------ ------- ---------------------------- ------ERPDB 103 APEX_REST_PUBLIC_USER YES ERPDB 102 APEX_LISTENER YES ERPDB 98 APEX_040200 YES ERPDB 95 APEX_PUBLIC_USER YES ERPDB 94 FLOWS_FILES YES ERPDB 50 ANONYMOUS YES

Nombre de containers :

SQL> select count(*) from v$containers;

COUNT(*)---------- 5

Nombre d’utilisateur APEX communs

SQL> SELECT COUNT(*) NBUSER, USR.USER_ID, USR.USERNAMEFROM CDB_USERS USRWHERE (USR.USERNAME = 'ANONYMOUS' OR USR.USERNAME LIKE '%APEX%' OR USR.USERNAME LIKE '%FLOW%')GROUP BY USR.USER_ID, USR.USERNAMEORDER BY USR.USER_ID DESC;

NBUSER USER_ID USERNAME---------- ------- ---------------------- 5 103 APEX_REST_PUBLIC_USER 5 102 APEX_LISTENER 5 98 APEX_040200 5 95 APEX_PUBLIC_USER 5 94 FLOWS_FILES 5 50 ANONYMOUS

On distingue cinq utilisateurs distincts ayant la même identité au sein d’un même conteneur de base de données

Dans l’architecture non standard, les utilisateurs/sché-mas APEX ne sont pas communs et sont présents unique-ment dans le conteneur l’hébergeant. Chacun, ayant sa propre identité

SQL> SELECT CON.NAME, USR.USER_ID, USR.USERNAME, USR.COMMONFROM CDB_USERS USR, V$CONTAINERS CONWHERE CON.CON_ID = USR.CON_ID AND (USR.USERNAME = 'ANONYMOUS' OR USR.USERNAME LIKE '%APEX%' OR USR.USERNAME LIKE '%FLOW%')ORDER BY USER_ID DESC;

NAME USER_ID USERNAME COMMON---------- ------- ---------------------- ------ PDB423 106 APEX_040200 NO PDB422 106 APEX_040200 NO PDB423 104 APEX_PUBLIC_USER NO PDB422 104 APEX_PUBLIC_USER NO PDB422 103 FLOWS_FILES NO PDB423 103 FLOWS_FILES NO PDB$SEED 50 ANONYMOUS YES CDB$ROOT 50 ANONYMOUS YES PDB423 50 ANONYMOUS YES PDB422 50 ANONYMOUS YES

13

SOUG Newsletter 1/2014

TIPS&TECHNIQUES 13

La gestion des utilisateurs/schémas dans le contexte APEX

Dans une architecture APEX standard, les utilisateurs et schémas APEX sont communs et ils ont la même identité (username/password) dans chaque conteneur. La modifica-tion de l’utilisateur ne peut se faire que depuis la CDB$ROOT.

Les extraits suivants montrent la modification d’un utilisa-teur d’une PDB et de la CDB$ROOT

Modification de l’utilisateur APEX_PUBLIC_USER depuis une PDB

SQL> show con_name

CON_NAME---------- ERPDB SQL> show userUSER is "SYS"

SQL>ALTER USER APEX_PUBLIC_USER IDENTIFIED BY manager ACCOUNT UNLOCK;ALTER USER APEX_PUBLIC_USER IDENTIFIED BY manager ACCOUNT UNLOCK;*ERROR at line 1:25$��������7KH�VSHFLºHG�FKDQJHV�PXVW�DSSO\�WR�DOO�FRQWDLQHUV

Modification de l’utilisateur APEX_PUBLIC_USER depuis CDB$ROOT

SQL> show con_name

CON_NAME---------- CDB$ROOT SQL> show userUSER is "SYS"

SQL> ALTER USER APEX_PUBLIC_USER IDENTIFIED BY manager ACCOUNT UNLOCK;

User altered.

La modification, connecté à la CDB$ROOT, a affecté tous les utilisateurs APEX_PUBLIC_USER du conteneur de base de données.

Dans une architecture non standard, la modification d’un utilisateur ne peut se faire que depuis son conteneur. L’utilisateur APEX_PUBLIC_USER n’existe pas dans la CDB$ROOT

SQL> show con_name

CON_NAME---------- CDB$ROOT SQL> DOWHU�XVHU�$3(;B38%/,&B86(5�LGHQWLºHG�E\�PDQDJHU�DFFRXQW�XQORFN�DOWHU�XVHU�$3(;B38%/,&B86(5�LGHQWLºHG�E\�PDQDJHU�DFFRXQW�XQORFN *ERROR at line 1:ORA-01918: user 'APEX_PUBLIC_USER' does not exist

Modification de l’utilisateur APEX_PUBLIC_USER depuis pdb422

SQL> show con_name

CON_NAME---------- PDB422 SQL> DOWHU�XVHU�$3(;B38%/,&B86(5�LGHQWLºHG�E\�PDQDJHU�DFFRXQW�XQORFN�

User altered.

L’utilisateur APEX_PUBLIC_USER a uniquement été mo-difié pour le conteneur PDB422

SQL> SELECT CON.NAME, USR.USER_ID, USR.USERNAME, USR.ACCOUNT_STATUSFROM CDB_USERS USR, V$CONTAINERS CONWHERE CON.CON_ID=USR.CON_ID AND USR.USERNAME='APEX_PUBLIC_USER'ORDER BY CON.NAME, USR.USER_ID DESC;

NAME USERNAME STATUS------- ---------------- ------ PDB422 APEX_PUBLIC_USER OPENPDB423 APEX_PUBLIC_USER LOCKED

SOUG Newsletter 1/2014

14 TIPS&TECHNIQUES

Gestion du cycle de vie APEX

Installation et montée de version

Architecture standardL’installation et la migration d’APEX se fait uniquement

depuis la CDB$ROOT et pour tout le conteneur de base de données. Le script suivant permet d’installer et migrer APEX au niveau CDB$ROOT

SQL> show con_name

CON_NAME---------- CDB$ROOT SQL> apexins_con.sql SYSAUX SYSAUX TEMP /i/

Architecture non standardPour pouvoir mettre en place une architecture non stan-

dard, il faut au préalable s’assurer que APEX n’est pas in stallé au niveau de la CDB$ROOT.

Si celui-ci est installé au niveau de la CDB$ROOT, il faut au préalable le supprimer (cf. Suppression du moteur APEX, architecture standard)

Ensuite, pour chaque PDB qui hébergera APEX, le script apexins.sql permet d’installer APEX dans une PDB.

SQL> show con_name

CON_NAME---------- PDB422 SQL> apexins.sql SYSAUX SYSAUX TEMP /i/

Suppression du moteur APEX

Architecture standard, APEX commun au conteneur

Oracle fournit un script permettant de supprimer APEX de l’architecture standard. Ceci a pour effet de supprimer com-plétement APEX de la CDB$ROOT, de la PDB$SEED et de toutes les PDBs. Cela supprime également toutes les méta-données d’APEX c’est-à-dire, toutes les définitions d’applica-tions. Il ne sera plus possible de les recréer et tous les déve-loppements effectués seront perdus.

Suppression d’APEX au niveau CDB$ROOT

SQL> @apxremov_con.sql

PL/SQL procedure successfully completed.

Version d’APEX après suppression

SQL> SELECT CON.NAME, REG.COMP_ID, REG.VERSIONFROM CDB_REGISTRY REG, V$CONTAINERS CONWHERE CON.CON_ID = REG.CON_ID AND COMP_ID='APEX'ORDER BY CON.CON_ID;

no rows selected

Ce script doit uniquement être utilisé pour mettre en place une architecture non standard et lorsqu’aucun dé-veloppement APEX n’a été effectué au sein du conteneur.

Une fois l’architecture standard mise en place, il n’est plus possible d’enlever APEX du conteneur et de migrer une PDB sans toucher l’ensemble. Il faudra au préalable mettre en place un conteneur parallèle, le configurer en architecture non standard et effectuer les opérations « UNPLUG » et « PLUG » vers le nouveau conteneur pour pouvoir effectuer une monter de version uniquement sur une PDB.

Architecture non standard, APEX au niveau d’une PDB

La suppression d’APEX s’effectue par le biais du script apxremov.

SQL> @apxremov.sql

PL/SQL procedure successfully completed.

Cela supprime uniquement APEX de la PDB à laquelle l’utilisateur est connecté.

SMS> > >

> > >

Der Einsendeschluss der in der letzten Ausgabe vor-gestellten Umfrage von In-fokenel wurde verlängert! Einsendeschluss ist der 31.1.2014 – also hopp auf ht tp://www.infokennel.ch/j/index.php/dwh-um-frage und die Fragen be-antworten. Hier der pas-sende QR Code:

Einsendeschluss Infokenel Umfrage

15

SOUG Newsletter 1/2014

TIPS&TECHNIQUES 15

Configuration du listener webLa configuration du listener web n’a pas changé avec l’ar-

rivée de l’architecture multi-tenante. Au niveau du listener Oracle et pour chaque PDB, un service est créé. La configu-ration du listener web s’effectue par le biais du service propre à chaque PDB.Q� Statut du « listener » Oracle avec configuration de la

passerelle EPG - XDB

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=vmtestora12cdev01)(PORT=8085))(Presentation=HTTP)(Session=RAW)) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=vmtestora12cdev01)(PORT=8086))(Presentation=HTTP)(Session=RAW)) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=vmtestora12cdev01)(PORT=8091))(Presentation=HTTP)(Session=RAW)) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=vmtestora12cdev01)(PORT=8092))(Presentation=HTTP)(Session=RAW))Services Summary...

Service "erpdb" has 1 instance(s). Instance "DB12C01", status READY, has 1 handler(s) for this ser-vice...Service "hrdb" has 1 instance(s). Instance "DB12C01", status READY, has 1 handler(s) for this ser-vice...Service "pdb422" has 1 instance(s). Instance "DB12C02", status READY, has 1 handler(s) for this ser-vice...Service "pdb423" has 1 instance(s). Instance "DB12C02", status READY, has 1 handler(s) for this ser-vice...The command completed successfully

Si la passerelle embarqué PL/SQL est utilisé, la configu-ration du service APEX doit être associé à un port non utilisé.

Q� Configuration du module mod_plsqlExemple d’utilisation du service pour la configuration du

module mod_plsql d’un serveur web (DADS.conf)

<Location /erpdb>Order deny,allowPlsqlDocumentPath docsAllowOverride None3OVTO'RFXPHQW3URFHGXUH�����ZZYB»RZBºOHBPJU�SURFHVVBGRZQORDGPlsqlDatabaseConnectString vmtestora12cdev01:1521:erpdb ServiceNameFormatPlsqlNLSLanguage AMERICAN_AMERICA.AL32UTF8PlsqlAuthenticationMode BasicSetHandler pls_handler3OVTO'RFXPHQW7DEOHQDPH�����ZZYB»RZBºOHBREMHFWV�PlsqlDatabaseUsername APEX_PUBLIC_USERPlsqlDefaultPage apexPlsqlDatabasePassword managerAllow from all</Location>

Manipulation de l’architecture multi-tenanteLes opérations présentées dans la figure ci-contre sont

possibles dans une architecture multi-tenante. Les exemples qui vont suivre permettent de montrer les fonc-tionnalités relatives à la manipulation d’architecture multi-te-nante dans le contexte APEX.

Scénario de testScénario 1 :

Clone depuis la PDB$SEED

CREATE PLUGGABLE DATABASE PDB_FROM_SEEDADMIN USER pdbadm IDENTIFIED BY manager

Post installation dans une architecture standard APEXDans ce cas, APEX est installé dans la CDB$ROOT et est

par conséquent contenu dans la PDB$SEED. Après le clone, APEX est prêt à être utilisé après configuration du « listener web » pour y accéder. Vérification des PDBs à disposition

SQL>SELECT NAME FROM V$PDBS;

NAME-------------------------PDB$SEEDAPEXHRDBERPDBPDB_FROM_SEED

Version d’APEX installé après clone

SQL>SELECT CON.NAME, REG.VERSIONFROM CDB_REGISTRY REG, V$CONTAINERS CONWHERE CON.CON_ID=REG.CON_ID AND REG.COMP_ID=’APEX’ORDER BY CON.CON_ID;

NAME VERSION---------------- ----------CDB$ROOT 4.2.3.00.08PDB$SEED 4.2.3.00.08APEX 4.2.3.00.08HRDB 4.2.3.00.08ERPDB 4.2.3.00.08PDB_FROM_SEED 4.2.3.00.08

SOUG Newsletter 1/2014

16 TIPS&TECHNIQUES

Post installation dans une architecture non standardDans ce cas, APEX n’est pas installé dans la CDB$ROOT.

Il est nécessaire d’effectuer son installation en local dans la PDB. Veuillez-vous référez au point « Gestion du cycle de vie APEX, Installation et montée de version, architecture non standard »

Scénario 2 : Clone depuis une PDB1. D’une architecture standard à standard :

Q� En local

1ère étape : Ouverture de la PDB en mode read only

SQL> alter pluggable database HRDB close;

Pluggable database altered.

SQL>alter pluggable database HRDB open read only

Pluggable database altered.

2ème étape: Création d’un répertoire pour stocker les fichiers de don-

nées et configurer OMF

[DB12C01 (CDB$ROOT)] mkdir /u01/oradata/DB12C01/HRDB_CLONE[DB12C01 (CDB$ROOT)] sqlplus / as sysdbaSQL>$/7(5�VHVVLRQ�VHW�GEBFUHDWHBºOHBGHVW �X���RUDGDWD�'%��&���+5'%B&/21(�

3ème étape: Clone PDB HRDB to HRDB_CLONE

SQL>CREATE pluggable database HRDB_CLONE from HRDB;

Pluggable database altered.

4ème étape: Vérification

Vérification des containers

NAME OPEN_MODE-------------- ----------CDB$ROOT READ WRITEPDB$SEED READ ONLYAPEX READ WRITEHRDB READ ONLYERPDB READ WRITEPDB_FROM_SEED READ WRITEHRDB_CLONE READ WRITE

Vérification des versions APEX installées

NAME VERSION --------------- -------------CDB$ROOT 4.2.3.00.08PDB$SEED 4.2.3.00.08APEX 4.2.3.00.08HRDB 4.2.3.00.08ERPDB 4.2.3.00.08PDB_FROM_SEED 4.2.3.00.08HRDB_CLONE 4.2.3.00.08

Q� A distance depuis une architecture standard à standard

1ère étape : Création d’un db link

64/!�FUHDWH�GDWDEDVH�OLQN�UHPRWHBGE��F���FRQQHFW�WR�V\VWHP�LGHQWLºHG�E\�manager using 'DB12C02';

2ème étape : Vérification du db link

SQL> select name, open_mode from v$containers@remote_db12c02;

NAME OPEN_MODE------------------------------ ----------CDB$ROOT READ WRITEPDB$SEED READ ONLYPDB422 MOUNTEDPDB423 READ ONLY

3ème étape : Creation de la PDB

CREATE PLUGGABLE DATABASE PDB423 FROM PDB423@remote_db12c02FILE_NAME_CONVERT=('/u01/oradata/DB12C02/EB568C2E71951893E0431E-38A8C02478/',' /u01/oradata/DB12C01/PDB423/');

Cette fonctionnalité n’est pour l’instant pas fonctionnelle et a déjà été relevé comme bug n° 15931910. Voici l’erreur retourné

ERROR at line 1:ORA-17628: Oracle error 19505 returned by remote Oracle server25$��������IDLOHG�WR�LGHQWLI\�ºOH���

Il faut attendre le patch relatif pour pouvoir cloner une PDB à distance

Scénario 3 : Déplacement d’une PDB (unplug – plug)1. D’une architecture non standard à standardDans cet exemple, la PDB423 de l’instance non standard

(DB12C02) va être déplacement de CDB. La PDB423 a APEX d’installé en non standard, localement à la PDB et va être déplacer dans l’instance standard (DB12C01)

1ère étape : Unplug PDB423 depuis DB12C02

SQL> ALTER PLUGGABLE DATABASE PDB423 CLOSE;

Pluggable database altered.

SQL> ALTER PLUGGABLE DATABASE PDB423 UNPLUG INTO '/tmp/PDB423.xml';

Pluggable database altered.

2ème étapes : Plug PDB depuis DB12C01 en tant que clone

SQL> CREATE PLUGGABLE DATABASE PDB423 AS CLONE USING '/tmp/PDB423.xml'

Pluggable database created.

17

SOUG Newsletter 1/2014

TIPS&TECHNIQUES 17

3ème étapes : Ouverture de la PDBv

SQL> ALTER PLUGGABLE DATABASE PDB423 OPEN;

Warning: PDB altered with errors.

Puisque la PDB423 contient APEX installé en non stan-dard, il faut appliquer un script qui va créer les METADATA LINK vers la CDB$ROOT.

4ème étapes : Modification de la PDB d’APEX en standard :

@apex_to_common.

cd $ORACLE_HOME/rdbms/adminConnected to sqlplus with sys as sysdba to the CDB$ROOT on DB12C01

SQL> ALTER SESSION SET CONTAINER = PDB423 ;

SQL>@apex_to_common.sql

Le script s’est presque exécuté correctement. Une erreur dans l’exécution du script a été détectée à la fin, lors de l’ouverture de la PDB.

…Pluggable database altered.

SQL> alter pluggable database "&pdbname" open;

Warning: PDB altered with errors.…

Cause possible: Après l’exécution du script, la PDB est en mode RESTRICTED

SQL> SELECT NAME, OPEN_MODE, RESTRICTED FROM V$CONTAINERS WHERE NAME =’PDB423’

NAME OPEN_MODE RES------------------------------ ---------- ---PDB423 READ WRITE YES

Bug ou pas bug, cette fonctionnalité n’est pas encore complétement fonctionnelle. Il est possible de contour-ner le problème en forçant l’ouverture de la PDB en READ WRITE avec la commande suivante.

ALTER PLUGGABLE DATABASE PDB423 OPEN READ WRITE FORCE

Cette solution n’est pas recommandée car lors du prochain arrêt ou ouverture de la PDB, celle-ci sera à nouveau en mode restreinte. Il n’est également pas possible de connaître toute les implications.

Scénario 4 : Déplacement d’une non-CDB vers une architecture APEX

standardCette opération a lieu après avoir effectuée une migration

de 11g vers 12cR1 ou lorsque une base de données 12cR2 a été installé sans l’option conteneur de base de données.

Malheureusement, La problématique décrite dans le scé-nario précédent est à nouveau survenue lors du déplacement d’une base de données non CDB vers une architecture APEX standard. Après l’exécution du script $ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql, la pdb était également en mode restreinte.

Suppression d’une PDBLa suppression d’une PDB peut essentiellement se faire

de deux manières

Q� En gardant les fichiers de données : KEEP DATAFILES

SQL> DROP PLUGGABLE DATABASE PDB423 KEEP DATAFILES;Pluggable database dropped.

Q� En supprimant les fichiers de données : INCLUDING DATAFILES

SQL> DROP PLUGGABLE DATABASE PDB423 INCLUDING DATAFILES;Pluggable database dropped.

SOUG Newsletter 1/2014

18 TIPS&TECHNIQUES

Application Multitenant self provisionning – BETAOracle fournit depuis le 23 septembre 2013, une applica-

tion APEX permettant de gérer, à travers d’une interface web, toutes les manipulations à effectuer au sein d’un architecture multi-tenante. Bien que celle-ci s’installe dans une PDB et qu’elle ne voit uniquement les PDB de ça CDB, il est intéres-sant de l’installé afin de se familiariser avec ce nouveau concept.

Figure 5: Application multitenant self provisionning

ConclusionPour conclure, l’architecture multi-tenante offre de nou-

velles possibilités afin de mettre en place des architectures APEX. Il est assez difficile d’appréhender le gain que ce nou-veau concept va apporter sans l’avoir mis en pratique.

Notons également qu’après les tests effectués, tous n’est pas encore fonctionnel et qu’il reste encore des bugs. Il faut attendre les premiers patches pour tester l’intégralité des fonctionnalités de l’architecture multi-tenante de base de données Oracle. Q

Contact

dbi services

Arnaud BerbierE-Mail:arnaud.berbier@dbi-services.com

gloBâleServices

info@irix.ch www.irix.chDornacherstrasse 192 CH – 4053 Basel T 061 367 93 33

The local

player for

global

solutions

Individuelle Softwarelösungen

Business Intelligence

Application Engineering

Seit 13 Jahren lokal, in Ihrer

weltweiten Nähe.

A N Z E I G E