Newsletter 1/ APEX et 12c multi tenant Audit Vault and DB Firewall Move Partition Online with 12c Oracle WebCenter Sites

Transcription

1 SWISS ORACLE US ER GRO UP Newsletter 1/2014 APEX et 12c multi tenant Audit Vault and DB Firewall Move Partition Online with 12c Oracle WebCenter Sites

2 8 TIPS&TECHNIQUES Arnaud Berbier, dbi services Apex et l architecture multi-tenante 12c 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 données Oracle. Le présent article énumère cette architecture et expose les enjeux pour les applicatifs Oracle, plus précisément Oracle Application Express. APEX en quelques mots Oracle Application Express est un moteur développé en PL/SQL et embarqué 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 données (CDB) et une non-cdb ont été créés afin de pouvoir tester les nouvelles fonctionnalités de l architecture multi-tenante dans le contexte APEX. L instance standard (DB12C01) CON_ID OPEN_MODE 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) VERSION PDB$SEED APEX HRDB ERPDB L instance non standard (DB12C02) CON_ID OPEN_MODE READ WRITE 2 PDB$SEED READ ONLY 3 PDB422 READ WRITE 4 PDB423 READ WRITE Versions d apex installées (DB12C01) VERSION - - PDB PDB L instance non-cdb (DB12C03) *********** dbi services Ltd. *********** STATUS : OPEN DB_UNIQUE_ : DB12C03 OPEN_MODE : READ WRITE DATABASE_ROLE : PRIMARY VERSION : CDB Enabled : NO ***************************************** Versions d apex installées (DB12C03) VERSION - - DB12C Versions des composants utilisés Base de données Oracle 12cR1 ( ), PSU Oracle Application Express et 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 partageant ainsi les processus et les ressources. Avantages principaux de l architecture multi-tenante 1 moteur de transaction 1 stratégie de sauvegarde 1 solution de haute disponibilité 1 Framework de monitoring Figure 1: Architecture multi-tenante Du point de vue applicatif, cela permet 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 application 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.

3 TIPS&TECHNIQUES 9 Afin de bien comprendre l article voici la description des mots clés importants à connaître : CDB : Base de données Oracle incluant un conteneur «ROOT» et des PDBs «pluggable DB» : Collection d informations de schéma et de non schéma accessible pas toutes les PDBs PDB$SEED : Système de modèle qui est utilisé pour créer de nouvelle PDB PDB : Collection de schémas et utilisateurs pour une application spécifique Gestion des utilisateurs Un 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 communs. 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. APEX et l architecture multi-tenante Dans le contexte d APEX, l architecture multi-tenante amène une autre dimension. Il est possible d avoir plusieurs moteurs APEX hébergés dans le même conteneur de base de données. Deux types d architecture sont possibles L architecture dite standard (par défaut) L architecture dite non standard L architecture standard Dans ce type d architecture, le moteur APEX est installé dans la 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 2: Gestion des utilisateurs Figure 3: Architecture standard 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: [email protected], [email protected] Der Vorstand freut sich auf den Anlass und hofft auf zahlreiches Erscheinen! Dans la, 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 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.

4 10 TIPS&TECHNIQUES L architecture non standard Dans ce type d architecture, la ne contient aucune information propre à APEX. APEX est installé directement au niveau de chaque PDB. Cette architecture peut être associée à l architecture connue jusqu ici. Avantages et inconvénients Le tableau ci-dessous énumère les avantages et inconvénients des deux architectures possibles. Les informations ci-après sont données à titre indicatif et peuvent complétement changer selon l adéquation des besoins métier. Figure 4: Architecture non standard Architecture Standard Homogénéité des versions d APEX au sein d un conteneur de base de données Stratégie d administration commune Gestion du cycle de vie APEX facilité Architecture Non Standard Plusieurs versions d APEX au sein du conteneur de base de données Montée de version par conteneur Chaque conteneur PDB a sa propre installation d APEX et est complétement autonome des autres conteneurs PDB. Montée de version commune Pas possible de passer en architecture non standard après utilisation d APEX sans perte de données Possibilité de passer en architecture standard 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 et des PDBs, les objets relatifs au schéma APEX_ sont dit partagés. Le type est «METADATA LINK» SELECT COUNT(*) OBJECT_COUNT, SHARING, OBJECT_TYPE FROM USER_OBJECTS GROUP BY SHARING, OBJECT_TYPE ORDER BY SHARING, OBJECT_COUNT DESC OBJECT_COUNT SHARING OBJECT_TYPE 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

5 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 SELECT CON., OBJ.OBJECT_ID, OBJ.OBJECT_ FROM CDB_OBJECTS OBJ, V$CONTAINERS CON WHERE OBJ.CON_ID = CON.CON_ID AND OBJ.OBJECT_ LIKE 'APEX_WORKSPACES' AND OBJ.OBJECT_TYPE = 'VIEW'; OBJECT_ID OBJECT_ APEX_WORKSPACES PDB$SEED APEX_WORKSPACES APEX APEX_WORKSPACES HRDB APEX_WORKSPACES ERPDB APEX_WORKSPACES A contrario, dans l architecture «non standard» et au niveau de la, les utilisateurs et schémas propres à APEX n existent pas. Aucun schéma APEX_ n est présent dans la. Au niveau du conteneur PDB, exemple avec PDB423, les objets propres à APEX ne sont pas partagés SELECT COUNT(*) OBJECT_COUNT, SHARING, OBJECT_TYPE FROM USER_OBJECTS GROUP BY SHARING, OBJECT_TYPE ORDER BY SHARING, OBJECT_COUNT DESC; OBJECT_COUNT SHARING OBJECT_TYPE 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 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 SELECT WORKSPACE, SCHEMAS, APPLICATIONS, APEX_USERS FROM APEX_WORKSPACES; WORKSPACE SCHEMAS APPLICATIONS APEX_USERS INTERNAL COM.ORACLE.APEX.REPOSITORY Au niveau d une PDB, exemple avec ERPDB SELECT WORKSPACE, SCHEMAS, APPLICATIONS, APEX_USERS FROM APEX_WORKSPACES; WORKSPACE SCHEMAS APPLICATIONS APEX_USERS INTERNAL COM.ORACLE.APEX.REPOSITORY APX_WS_ERPDB On remarque bien que les informations contenu dans la et la PDB sont différentes. Le workspace APX_ WS_ERPDB existe uniquement dans la PDB ERPDB. 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 : SELECT CON., OBJ.OBJECT_ID, OBJ.OBJECT_ FROM CDB_OBJECTS OBJ, V$CONTAINERS CON WHERE OBJ.CON_ID = CON.CON_ID AND OBJ.OBJECT_ LIKE 'APEX_WORKSPACES' AND OBJ.OBJECT_TYPE = 'VIEW'; OBJECT_ID OBJECT_ PDB APEX_WORKSPACES PDB APEX_WORKSPACES Stockage de chaque schéma Les schémas propres à APEX stockent leurs données dans la tablespace SYSAUX (par défaut) : SELECT CON., SEG.OWNER, SEG.TABLESPACE_,SUM(SEG. BYTES)/1024/1024 "Space Used in MB" FROM CDB_SEGMENTS SEG,V$CONTAINERS CON WHERE CON.CON_ID=SEG.CON_ID AND TABLESPACE_='SYSAUX' AND (OWNER = 'ANONYMOUS' OR OWNER LIKE '%APEX%' OR OWNER LIKE '%FLOW%') GROUP BY CON., SEG.OWNER, SEG.TABLESPACE_ ORDER BY CON., SEG.OWNER; OWNER TABLESPACE_ Space Used in MB APEX APEX_ SYSAUX APEX FLOWS_FILES SYSAUX APEX_ SYSAUX ERPDB APEX_ SYSAUX ERPDB FLOWS_FILES SYSAUX HRDB APEX_ SYSAUX HRDB FLOWS_FILES SYSAUX PDB$SEED APEX_ SYSAUX

6 12 TIPS&TECHNIQUES Le stockage s effectue dans des fichiers différents SELECT CON., DF.TABLESPACE_, DF.FILE_ID, SUBSTR(DF.FILE_,INSTR(DF.FILE_,'/','-1')+1,LENGTH(DF.FILE_)) DATAFILE FROM V$CONTAINERS CON, CDB_DATA_FILES DF WHERE CON.CON_ID=DF.CON_ID AND TABLESPACE_ = 'SYSAUX' ORDER BY CON.; TABLESPACE_ FILE_ID DATAFILE APEX SYSAUX 8 o1_mf_sysaux_97oqn6x8_.dbf SYSAUX 3 o1_mf_sysaux_97nqhjn3_.dbf ERPDB SYSAUX 14 o1_mf_sysaux_97q8pch5_.dbf HRDB SYSAUX 12 o1_mf_sysaux_97q82c24_.dbf PDB$SEED SYSAUX 4 o1_mf_sysaux_97nqkv1p_.dbf PDB_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 : SELECT CON., USR.USER_ID, USR.USER, USR.COMMON, USR.ORAC- LE_MAINTAINED FROM CDB_USERS USR, V$CONTAINERS CON WHERE CON.CON_ID = USR.CON_ID AND (USR.USER = 'ANONYMOUS' OR USR.USER LIKE '%APEX%' OR USR.USER LIKE '%FLOW%') AND CON. ='' ORDER BY USER_ID DESC; USER_ID USER COMMON APEX_REST_PUBLIC_USER YES 102 APEX_LISTENER YES 98 APEX_ YES 95 APEX_PUBLIC_USER YES 94 FLOWS_FILES YES 50 ANONYMOUS YES Utilisateurs liés à APEX pour une PDB : SELECT CON., USR.USER_ID, USR.USER, USR.COMMON FROM CDB_USERS USR, V$CONTAINERS CON WHERE CON.CON_ID = USR.CON_ID AND (USR.USER = 'ANONYMOUS' OR USR.USER LIKE '%APEX%' OR USR.USER LIKE '%FLOW%') AND CON. ='ERPDB' ORDER BY USER_ID DESC; USER_ID USER COMMON ERPDB 103 APEX_REST_PUBLIC_USER YES ERPDB 102 APEX_LISTENER YES ERPDB 98 APEX_ YES ERPDB 95 APEX_PUBLIC_USER YES ERPDB 94 FLOWS_FILES YES ERPDB 50 ANONYMOUS YES Nombre de containers : select count(*) from v$containers; COUNT(*) 5 Nombre d utilisateur APEX communs SELECT COUNT(*) NBUSER, USR.USER_ID, USR.USER FROM CDB_USERS USR WHERE (USR.USER = 'ANONYMOUS' OR USR.USER LIKE '%APEX%' OR USR.USER LIKE '%FLOW%') GROUP BY USR.USER_ID, USR.USER ORDER BY USR.USER_ID DESC; NBUSER USER_ID USER APEX_REST_PUBLIC_USER APEX_LISTENER 5 98 APEX_ 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 uniquement dans le conteneur l hébergeant. Chacun, ayant sa propre identité SELECT CON., USR.USER_ID, USR.USER, USR.COMMON FROM CDB_USERS USR, V$CONTAINERS CON WHERE CON.CON_ID = USR.CON_ID AND (USR.USER = 'ANONYMOUS' OR USR.USER LIKE '%APEX%' OR USR.USER LIKE '%FLOW%') ORDER BY USER_ID DESC; USER_ID USER COMMON PDB APEX_ NO PDB APEX_ NO PDB APEX_PUBLIC_USER NO PDB APEX_PUBLIC_USER NO PDB FLOWS_FILES NO PDB FLOWS_FILES NO PDB$SEED 50 ANONYMOUS YES 50 ANONYMOUS YES PDB ANONYMOUS YES PDB ANONYMOUS YES

7 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 modification de l utilisateur ne peut se faire que depuis la. Les extraits suivants montrent la modification d un utilisateur d une PDB et de la Modification de l utilisateur APEX_PUBLIC_USER depuis une PDB show con_name CON_ ERPDB show user USER is "SYS" ALTER USER APEX_PUBLIC_USER IDENTIFIED BY manager ACCOUNT UNLOCK; ALTER USER APEX_PUBLIC_USER IDENTIFIED BY manager ACCOUNT UNLOCK; * ERROR at line 1: Modification de l utilisateur APEX_PUBLIC_USER depuis show con_name CON_ show user USER is "SYS" ALTER USER APEX_PUBLIC_USER IDENTIFIED BY manager ACCOUNT UNLOCK; User altered. La modification, connecté à la, 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 Modification de l utilisateur APEX_PUBLIC_USER depuis pdb422 show con_name CON_ PDB422 User altered. L utilisateur APEX_PUBLIC_USER a uniquement été modifié pour le conteneur PDB422 SELECT CON., USR.USER_ID, USR.USER, USR.ACCOUNT_STATUS FROM CDB_USERS USR, V$CONTAINERS CON WHERE CON.CON_ID=USR.CON_ID AND USR.USER='APEX_PUBLIC_USER' ORDER BY CON., USR.USER_ID DESC; USER STATUS PDB422 APEX_PUBLIC_USER OPEN PDB423 APEX_PUBLIC_USER LOCKED show con_name CON_ * ERROR at line 1: ORA-01918: user 'APEX_PUBLIC_USER' does not exist

8 14 TIPS&TECHNIQUES Gestion du cycle de vie APEX Installation et montée de version Architecture standard L installation et la migration d APEX se fait uniquement depuis la et pour tout le conteneur de base de données. Le script suivant permet d installer et migrer APEX au niveau show con_name CON_ apexins_con.sql SYSAUX SYSAUX TEMP /i/ Architecture non standard Pour pouvoir mettre en place une architecture non standard, il faut au préalable s assurer que APEX n est pas in stallé au niveau de la. Si celui-ci est installé au niveau de la, 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. 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 complétement APEX de la, de la PDB$SEED et de toutes les PDBs. Cela supprime également toutes les métadonnées d APEX c est-à-dire, toutes les définitions d applications. Il ne sera plus possible de les recréer et tous les développements effectués seront perdus. Suppression d APEX au PL/SQL procedure successfully completed. Version d APEX après suppression SELECT CON., REG.COMP_ID, REG.VERSION FROM CDB_REGISTRY REG, V$CONTAINERS CON WHERE CON.CON_ID = REG.CON_ID AND COMP_ID='APEX' ORDER BY CON.CON_ID; no rows selected show con_name CON_ PDB422 apexins.sql SYSAUX SYSAUX TEMP /i/ SMS > > > > > > Einsendeschluss Infokenel Umfrage Der Einsendeschluss der in der letzten Ausgabe vorgestellten Umfrage von Infokenel wurde verlängert! Einsendeschluss ist der also hopp auf ch/j/index.php/dwh-umfrage und die Fragen beantworten. Hier der passende QR Code: 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 PL/SQL procedure successfully completed. Cela supprime uniquement APEX de la PDB à laquelle l utilisateur est connecté.

9 TIPS&TECHNIQUES 15 Configuration du listener web La configuration du listener web n a pas changé avec l arrivée de l architecture multi-tenante. Au niveau du listener Oracle et pour chaque PDB, un service est créé. La configuration du listener web s effectue par le biais du service propre à chaque PDB. Statut du «listener» Oracle avec configuration de la passerelle EPG - XDB Manipulation de l architecture multi-tenante Les 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 fonctionnalités relatives à la manipulation d architecture multi-tenante dans le contexte APEX. (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 service... Service "hrdb" has 1 instance(s). Instance "DB12C01", status READY, has 1 handler(s) for this service... Service "pdb422" has 1 instance(s). Instance "DB12C02", status READY, has 1 handler(s) for this service... Service "pdb423" has 1 instance(s). Instance "DB12C02", status READY, has 1 handler(s) for this service... The command completed successfully Scénario de test Scénario 1 : Clone depuis la PDB$SEED Si la passerelle embarqué PL/SQL est utilisé, la configuration du service APEX doit être associé à un port non utilisé. Configuration du module mod_plsql Exemple d utilisation du service pour la configuration du module mod_plsql d un serveur web (DADS.conf) CREATE PLUGGABLE DATABASE PDB_FROM_SEED ADMIN USER pdbadm IDENTIFIED BY manager Post installation dans une architecture standard APEX Dans ce cas, APEX est installé dans la 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. <Location /erpdb> Order deny,allow PlsqlDocumentPath docs AllowOverride None PlsqlDatabaseConnectString vmtestora12cdev01:1521:erpdb ServiceNameFormat PlsqlNLSLanguage AMERICAN_AMERICA.AL32UTF8 PlsqlAuthenticationMode Basic SetHandler pls_handler PlsqlDatabaseUsername APEX_PUBLIC_USER PlsqlDefaultPage apex PlsqlDatabasePassword manager Allow from all </Location> Vérification des PDBs à disposition SELECT FROM V$PDBS; PDB$SEED APEX HRDB ERPDB PDB_FROM_SEED Version d APEX installé après clone SELECT CON., REG.VERSION FROM CDB_REGISTRY REG, V$CONTAINERS CON WHERE CON.CON_ID=REG.CON_ID AND REG.COMP_ID= APEX ORDER BY CON.CON_ID; VERSION PDB$SEED APEX HRDB ERPDB PDB_FROM_SEED

10 16 TIPS&TECHNIQUES Post installation dans une architecture non standard Dans ce cas, APEX n est pas installé dans la. 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» A distance depuis une architecture standard à standard 1ère étape : Création d un db link manager using 'DB12C02'; Scénario 2 : Clone depuis une PDB 1. D une architecture standard à standard : En local 1ère étape : Ouverture de la PDB en mode read only alter pluggable database HRDB close; Pluggable database altered. alter pluggable database HRDB open read only Pluggable database altered. 2ème étape : Vérification du db link select name, open_mode from v$containers@remote_db12c02; OPEN_MODE READ WRITE PDB$SEED READ ONLY PDB422 MOUNTED PDB423 READ ONLY 3ème étape : Creation de la PDB CREATE PLUGGABLE DATABASE PDB423 FROM PDB423@remote_db12c02 FILE CONVERT=('/u01/oradata/DB12C02/EB568C2E E0431E- 38A8C02478/',' /u01/oradata/db12c01/pdb423/'); 2ème étape: Création d un répertoire pour stocker les fichiers de données et configurer OMF [DB12C01 ()] mkdir /u01/oradata/db12c01/hrdb_clone [DB12C01 ()] sqlplus / as sysdba Cette fonctionnalité n est pour l instant pas fonctionnelle et a déjà été relevé comme bug n Voici l erreur retourné ERROR at line 1: ORA-17628: Oracle error returned by remote Oracle server 3ème étape: Clone PDB HRDB to HRDB_CLONE CREATE pluggable database HRDB_CLONE from HRDB; Pluggable database altered. 4ème étape: Vérification Vérification des containers OPEN_MODE ---- READ WRITE PDB$SEED READ ONLY APEX READ WRITE HRDB READ ONLY ERPDB READ WRITE PDB_FROM_SEED READ WRITE HRDB_CLONE READ WRITE Vérification des versions APEX installées VERSION PDB$SEED APEX HRDB ERPDB PDB_FROM_SEED HRDB_CLONE 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 à standard Dans 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 ALTER PLUGGABLE DATABASE PDB423 CLOSE; Pluggable database altered. ALTER PLUGGABLE DATABASE PDB423 UNPLUG INTO '/tmp/pdb423.xml'; Pluggable database altered. 2ème étapes : Plug PDB depuis DB12C01 en tant que clone CREATE PLUGGABLE DATABASE PDB423 AS CLONE USING '/tmp/pdb423.xml' Pluggable database created.

11 TIPS&TECHNIQUES 17 3ème étapes : Ouverture de la PDBv ALTER PLUGGABLE DATABASE PDB423 OPEN; Warning: PDB altered with errors. Puisque la PDB423 contient APEX installé en non standard, il faut appliquer un script qui va créer les METADATA LINK vers la. 4ème étapes : Modification de la PDB d APEX en standard cd $ORACLE_HOME/rdbms/admin Connected to sqlplus with sys as sysdba to the on DB12C01 ALTER SESSION SET CONTAINER = PDB423 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. 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 Scénario 4 : Déplacement d une non-cdb vers une architecture APEX standard Cette 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 PDB La suppression d une PDB peut essentiellement se faire de deux manières SELECT, OPEN_MODE, RESTRICTED FROM V$CONTAINERS WHERE = PDB423 OPEN_MODE RES --- PDB423 READ WRITE YES Bug ou pas bug, cette fonctionnalité n est pas encore complétement fonctionnelle. Il est possible de contourner le problème en forçant l ouverture de la PDB en READ WRITE avec la commande suivante. En gardant les fichiers de données : KEEP DATAFILES DROP PLUGGABLE DATABASE PDB423 KEEP DATAFILES; Pluggable database dropped. En supprimant les fichiers de données : INCLUDING DATAFILES DROP PLUGGABLE DATABASE PDB423 INCLUDING DATAFILES; Pluggable database dropped. 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.

12 18 TIPS&TECHNIQUES Application Multitenant self provisionning BETA Oracle fournit depuis le 23 septembre 2013, une application 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éressant de l installé afin de se familiariser avec ce nouveau concept. Figure 5: Application multitenant self provisionning A NZEIGE globâle Services Conclusion Pour conclure, l architecture multi-tenante offre de nouvelles possibilités afin de mettre en place des architectures APEX. Il est assez difficile d appréhender le gain que ce nouveau 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. Contact dbi services Arnaud Berbier [email protected] Individuelle Softwarelösungen Business Intelligence Application Engineering Seit 13 Jahren lokal, in Ihrer weltweiten Nähe. The local player for global solutions [email protected] Dornacherstrasse 192 CH 4053 Basel T