Maintenant qu’elle est disponible, après une attente qui nous a semblé interminable ! – Pour rappel la version 12.1.0.1 est disponible depuis juin 2013 et le patchset 12.1.0.2 depuis le mois de juillet 2014, soit pratiquement 2 années et demi entre deux versions – Il est temps d’en profiter et de faire évoluer son architecture pour profiter pleinement des nouvelles fonctionnalités !
Ce qui nous a sauté aux yeux dès que nous avons pu disposer de la version Bêta en novembre 2015, ce sont toutes les améliorations apportées à l’infrastructure multitenant. Même si vous ne comptez pas investir dans ce qui reste une option, les possibilités apportées sont intéressantes, et ce dans le cadre légal associé à votre licence SE2 ou EE, c’est à dire une configuration avec une seule base PDB par container racine CDB.
Voici comment passer de votre architecture actuelle :
– Base 11.2 en production
– Un environnement de développement
– Autres environnements (qualification, intégration)
– Procédures de rafraichissement
à une architecture 12cR2 et sa facilité de gestion et d’exploitation via les containers.

La cible de cette nouvelle configuration sera donc un container racine par environnement et une seule base de données pluggée (une PDB, pour « Pluggable Database ») sur chacun des containers.
La PDB de production pourra être clonée rapidement et à chaud (sans aucun arrêt de production) sur les autres environnements grâce aux nouvelles fonctionnalités de la version.

L’article va balayer toutes les phases nécessaires : de l’installation de la nouvelle distribution en passant par la migration de la base 11g, avant de réaliser l’opération de clonage à chaud.
Pour simuler tout cela, j’ai utilisé une VM X86_64 Oracle Entreprise Linux (version 6.1) via Virtual Box.
Les différentes étapes que je déroule pour la transformation sont :
1) Installation de la version 12cR2 dans un nouvel ORACLE_HOME
2) Création des containers racines pour les environnements :
– CDPROD pour accueillir la PDB de production
– CDBDEV pour le développement
– CDBQUALIF pour la qualification, etc.
Ici, je ne traite qu’un environnement de développement (CDNDEV); pour d’autres environnements, la logique sera la même, il faudra s’assurer d’avoir les ressources nécessaires (CPU, disques et mémoire) sur votre serveur.
3) Création du PBD de production (PDBPROD) dans le conteneur racine CDBPROD à partir de la base d’origine (en version 11.2.0.4)
4) Clonage à chaud et création de la base pour le développement : PDBDEV sur CDBDEV
5) Mise en place des procédures de rafraichissement
1) Installation de la version 12.2.0.1
Choix d’installation dans le répertoire /u01/app/oracle/product/12.2/dbhome_1
Pas de changement fondamental dans l’exécution de l’installeur qui laisse le choix entre les éditions « Enterprise » ou « Standard Edition 2 » (voir plus d’informations ici sur la SE2). Les deux distributions annoncent une empreinte identique de 7,5 Go

on peut noter incidemment l’apparition d’un nouveau groupe de privilèges spécifiques : OSRACDBA

Les prérequis évoluent avec la nécessité d’être sur un noyau Linux de version supérieure ou égale à : 2.6.39-400.211.1 (soit une version Oracle Linux 6.5 minimum)
L’espace requis pour la version EE apparait bien dans l’écran de l’étape 8 sur 10 comme 7,5 Go et c’est bien exactement la même chose pour la version SE2.
L’exécution des orainstroot.sh et root.sh demandée reste classique :

[root]# /u01/app/oraInventory/orainstRoot.sh
[root]# /u03/app/oracle/product/12.2.2/dbhome/root.sh
Check /u03/app/oracle/product/12.2.2/dbhome/install/root_ele1ole6_2017-03-10_16-11-48-772647302.log for the output of root script

Il n’y a plus de sortie de l’information, mais il faut visualiser le contenu du fichier de log indiqué :

Performing root user operation.
The following environment variables are set as:
    ORACLE_OWNER= oracle
    ORACLE_HOME=  /u03/app/oracle/product/12.2.2/dbhome
   Copying dbhome to /usr/local/bin ...
   Copying oraenv to /usr/local/bin ...
   Copying coraenv to /usr/local/bin ...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Oracle Trace File Analyzer (TFA) is available at : /u03/app/oracle/product/12.2.2/dbhome/suptools/tfa/release/tfa_home/bin/tfactl

Noter l’installation automatique de « Oracle Trace File Analyser », qui discrètement vous met à disposition de nombreux outils pour l’analyse de problèmes.
La lettre d’informations du support vous donnera des informations sur le sujet au travers de la note MOS : « Oracle Premier Support – Oracle Database Support News – Issue February 2017, Volume 72 (Doc ID 230.1) »
Pas d’anomalie pour cette installation et une durée habituelle de moins de dix minutes pour la réaliser, l’empreinte réelle résultat d’une commande « du -sh » est de 7,2 Go.
Bien sûr, le mode silencieux est toujours disponible, pour rappel voici un exemple de commandes :

$ export DISTRIB=/u01/distrib/db122/database
$ cd $DISTRIB
$ ./runInstaller -silent -ignoreSysPrereqs  -ignorePrereq \
-responseFile $DISTRIB/response/db_install.rsp \
oracle.install.option=INSTALL_DB_SWONLY UNIX_GROUP_NAME=oinstall \
SELECTED_LANGUAGES=en ORACLE_BASE=/u01/app/oracle  \
ORACLE_HOME=/u01/app/oracle/product/12.2/dbhome_1
oracle.install.db.InstallEdition=EE
oracle.install.db.DBA_GROUP=dba
oracle.install.db.OPER_GROUP=dba
oracle.install.db.BACKUPDBA_GROUP=dba
oracle.install.db.DGDBA_GROUP=dba
oracle.install.db.KMDBA_GROUP=dba
oracle.install.db.OSRACDBA_GROUP=dba
DECLINE_SECURITY_UPDATES=true

Une fois les binaires de la version en place, la première chose à faire est de déclarer un listener; pour ne pas perturber votre configuration, il suffit de le faire écouter sur un port particulier :

# listener.ora Network Configuration File: /u03/app/oracle/product/12.2/network/admin/listener.ora
# Generated by Oracle configuration tools.
LSNR_12R2 =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ele1ole6.ele.com)(PORT = 1527))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1527))
    )
  )

Démarrage avec la commande habituelle :

$ lsnrctl start lsnr_12R2

2) Création des containers
Container pour la base de production : CDBPROD
Le premier container est créé avec l’outil DBCA en mode graphique avec les options standards, cela permet de visualiser les nouveautés de l’outil,
comme le choix important d’utiliser un tablespace dédié à chaque PDB pour la gestion des segments d’annulation de la base, c’est ce qui va permettre les opérations de clonage à chaud :

ou la possibilité de créer un container sans toutes les options :

ou encore, l’étape de définition des fichiers qui devient optionnelle dans le déroulement et que l’on retrouve en cliquant sur « Personnaliser les emplacements de stockage » au step 12 :

Container suivant : CDBDEV
Pour créer les containers suivants, j’ai utilisé DBCA pour récupérer les scripts de création du container CDBPROD et les adapter, ce qui donne un ensemble de 9 fichiers :
– CreateClustDBViews.sql
– CreateDB.sql
– CreateDBCatalog.sql
– CreateDBFiles.sql
– cdbdev.sh
– cdbdev.sql
– init.ora
– lockAccount.sql
– postDBCreation.sql
Voici le contenu de CreateDB.sql, une fois modifié pour mon nouveau nom de container; noter l’avant-dernière ligne qui comprend les termes « LOCAL UNDO ON » :

SET VERIFY OFF
connect "SYS"/"&&sysPassword" as SYSDBA
set echo on
spool /u01/app/oracle/admin/CDBDEV/scripts/CreateDB.log append
startup nomount pfile="/u01/app/oracle/admin/CDBDEV/scripts/init.ora";
CREATE DATABASE "CDBDEV"
MAXINSTANCES 8
MAXLOGHISTORY 1
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 1024
DATAFILE '/u01/app/oracle/oradata/CDBDEV/system01.dbf' SIZE 700M REUSE AUTOEXTEND ON NEXT  10240K MAXSIZE UNLIMITED
EXTENT MANAGEMENT LOCAL
SYSAUX DATAFILE '/u01/app/oracle/oradata/CDBDEV/sysaux01.dbf' SIZE 550M REUSE AUTOEXTEND ON NEXT  10240K MAXSIZE UNLIMITED
SMALLFILE DEFAULT TEMPORARY TABLESPACE TEMP TEMPFILE '/u01/app/oracle/oradata/CDBDEV/temp01.dbf' SIZE 20M REUSE AUTOEXTEND ON NEXT  640K MAXSIZE UNLIMITED
SMALLFILE UNDO TABLESPACE "UNDOTBS1" DATAFILE  '/u01/app/oracle/oradata/CDBDEV/undotbs01.dbf' SIZE 200M REUSE AUTOEXTEND ON NEXT  5120K MAXSIZE UNLIMITED
CHARACTER SET AL32UTF8
NATIONAL CHARACTER SET AL16UTF16
LOGFILE GROUP 1 ('/u01/app/oracle/oradata/CDBDEV/redo01.log') SIZE 200M,
GROUP 2 ('/u01/app/oracle/oradata/CDBDEV/redo02.log') SIZE 200M,
GROUP 3 ('/u01/app/oracle/oradata/CDBDEV/redo03.log') SIZE 200M
USER SYS IDENTIFIED BY "&&sysPassword" USER SYSTEM IDENTIFIED BY "&&systemPassword"
enable pluggable database
seed file_name_convert=('/u01/app/oracle/oradata/CDBDEV/system01.dbf','/u01/app/oracle/oradata/CDBDEV/pdbseed/system01.dbf','/u01/app/oracle/oradata/CDBDEV/sysaux01.dbf','/u01/app/oracle/oradata/CDBDEV/pdbseed/sysaux01.dbf','/u01/app/oracle/oradata/CDBDEV/temp01.dbf','/u01/app/oracle/oradata/CDBDEV/pdbseed/temp01.dbf','/u01/app/oracle/oradata/CDBDEV/undotbs01.dbf','/u01/app/oracle/oradata/CDBDEV/pdbseed/undotbs01.dbf') LOCAL UNDO ON;
spool off

On peut ensuite utiliser ce modèle pour créer n’importe quel container racine particulier.
N’oublions pas de déclarer le container au listener (procédure identique pour chaque container) :

$ export ORACLE_SID=CDBDEV
$ sqlplus / as sysdba
SQL> alter system set local_listener='LSNR_12R2' scope=both ;
SQL> alter system register ;

3) Création de la nouvelle base de production
Pour rappel, le point de départ est une base en version 11.2.0.3 en mode archivelog.
Parmi l’ensemble des scénarios possibles, celui du clonage par le réseau est le plus simple; il permet de plus de conserver la base dans la version précédente (en cas de besoin) :
– Créer un alias réseau dans le fichier tnsnames.ora de la distribution 12c

PROD =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = ele1ole6.ele.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = PROD)
    )
  )

– Créer le répertoire de destination et le DBLINK vers la base d’origine
Connecter au container racine CDBPROD

$ export ORACLE_SID=CDBPROD
$ sqlplus / as sysdba
SQL> !mkdir /data/oradata/CDB1/datafile/pdb_prod
SQL> create database link link_prod connect to system identified by easy_4U using 'PROD' ;
Database link created.

– Clonage de la base de production d’origine ORCL (même connexion SQLPLUS) :

SQL> create pluggable database PDB_PROD from NON$CDB@link_prod create_file_dest='/data/oradata/CDB1/datafile/pdb_prod' ;
Pluggable database created.
SQL> show pdbs
    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         4 PDB_PROD                       MOUNTED

– Transformation de la base d’origine en Pluggable Database (PDB) (toujour même connexion SQLPLUS)

SQL> alter session set container = pdb_prod
SQL> @?/rdbms/admin/noncdb_to_pdb

Durée de 10 minutes environ sur ma configuration, liée à 80% à la durée de utlrecomp, recompilation des objets invalides.
Et voilà, un service PDB_PROD est disponible pour accéder à votre nouvelle de production en version 12.2.
Il vous reste à changer les alias réseaux de vos datasources pour que vos serveurs d’applications utilisent la base dans sa nouvelle version.
4) Clonage de la production
Voici enfin le moment le plus intéressant, la création de votre base de dev sans interrompre votre production.
Pour cela, il vous faut :
– Créer un alias réseau Oracle Net vers votre base de production
– Créer un DBlink depuis votre container de développement vers la base de production
Entrée du fichier tnsnames.ora sous $ORACLE_HOME/network/admin de la version 12.2 :

PDBROD =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = ele1ole6.ele.com)(PORT = 1527))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = PDB_PROD)
    )
  )

Création du lien base de données :

$ export ORACLE_SID=CDBDEV
$ sqlplus / as sysdba
SQL> create database  link l_pdbprod connect to system identified by easy_4U using 'PDBPROD' ;

Clonage de la base de production :

SQL> !mkdir /u03/oradata/cdbdev/pdb_dev
SQL> create pluggable database pdb_dev from pdbprod@l_pdbprod create_file_dest='/u03/oradata/cdbdev/pdb_dev' ;
Base de donnees pluggable creee.
SQL> show pdbs
    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB                            MOUNTED
         4 PDB_DEV                         MOUNTED

Ouverture de la base PDB_DEV pour les utilisateurs :

SQL> alter session set container=PDB_DEV ;
SQL> alter pluggable database open ;

Et vous voilà avec votre nouvel environnement disponible pour votre équipe projet.
5) Rafraichissement des environnements
Après quelques temps, il est nécessaire de rafraichir les informations; voici ce qu’il faut faire, et ce, toujours sans arrêt de la production.
Pour valider, je génère quelques actions sur ma base de production, soit des transactions validées, soit non :

$ sqlplus scott@pdbprod
SQL> select * from dept ;
     DEPTNO DNAME          LOC
---------- -------------- -------------
        10 ACCOUNTING     NEW YORK
        20 RESEARCH       DALLAS
        30 SALES          CHICAGO
        40 OPERATIONS     BOSTON
SQL> insert into dept values(50,'DEV','TOULOUSE' ) ;
1 ligne créée.
SQL> commit ;

Validation effectuee.

SQL> select * from dept ;
    DEPTNO DNAME          LOC
---------- -------------- -------------
        50 DEV            TOULOUSE
        10 ACCOUNTING     NEW YORK
        20 RESEARCH       DALLAS
        30 SALES          CHICAGO
        40 OPERATIONS     BOSTON
SQL> insert into dept values(60,'DEV2','PARIS') ;
1 ligne creee.

Cette fois pas de commit pour cette entrée.
Rafraichisement de la base PDBDEV :
Depuis le container CDBDEV.
(Ce qui sera les ordres SQL à scripter pour de l’automatisation)

SQL> alter pluggable database pdbdev close ;
SQL> drop pluggable database pdbdev including datafiles ;
Base de donnees pluggable supprimee.
SQL> create pluggable database pdb_dev from pdbprod@l_pdbprod create_file_dest='/u03/oradata/cdbdev/pdbdev';
Base de donnees pluggable creee.
SQL> show pdbs
SQL> alter pluggable database pdb_dev open ;
SQL> show pdbs
    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB                            MOUNTED
         4 PDB_DEV                         READ WRITE YES

Vérification de la présence des modifications faites :

SQL> alter session set container=pdbdev ;
SQL> select * from scott.dept ;
    DEPTNO DNAME          LOC
---------- -------------- -------------
        50 DEV            TOULOUSE
        10 ACCOUNTING     NEW YORK
        20 RESEARCH       DALLAS
        30 SALES          CHICAGO
        40 OPERATIONS     BOSTON

La valeur pour ‘TOULOUSE’ est bien présente, mais pas celle pour ‘PARIS’ qui n’avait pas été committée, je me retrouve bien avec une image cohérente de ma base source.
Il y a bien sûr un impact pendant la durée du clonage, qui va dépendre des caractéristiques de vos serveurs.
Sur mon Laptop, avec un simulation de charge pendant le clonage, le taux de transactions sur ma base de prod a diminué d’un tiers, c’est beaucoup, mais attention, je n’ai qu’un laptop avec un seul disque !
Rien à voir avec un serveur dédié.
La manipulation de clonage est très simple et facile à automatiser.
Donc, même avec une configuration Standard Edition, on peut utiliser l’architecture multitenant pour disposer d’une architecture souple à utiliser.
Rien que pour cela, cette release 2 est une réussite.
On peut aller encore plus loin et propager automatiquement les transactions vers la base de DEV, ou encore se créer un container applicatif pour séparer le code de l’application et son dictionnaire des données utilisateurs et ne rafraichir par clonage que les données.
Mais ça se sont d’autres histoires…

—