AlexandreLabrousse OEM12c

Alexandre Labrousse
Ingnieur Informatique en Apprentissage

Spcialit Systmes dinformation
Master 2, FIP 3
Dploiement et Exploitation dOracle

Enterprise Manager 12c
MMOIRE DINGENIEUR
Sous la direction de

Tuteur pdagogique : Matre dapprentissage :
Monsieur Nicolas TRAVERS Monsieur Jean-Luc GUERIN
Matre de Confrences en informatique Administrateur Base de donnes Snior
Enseignant-chercheur ESSILOR FRANCE
CNAM - Paris

Anne Universitaire 2015/2016
Alexandre LABROUSSE 2015 - 2016
Mmoire dingnieur
Page | 2

Mmoire dingnieur
Alexandre Labrousse
Ingnieur Informatique en Apprentissage
Spcialit Systmes dinformation
Master 2, FIP 3
Dploiement et Exploitation dOracle

Enterprise Manager 12c
MMOIRE DINGENIEUR
Sous la direction de

Tuteur pdagogique : Matre dapprentissage :
Monsieur Nicolas TRAVERS Monsieur Jean-Luc GUERIN
Matre de Confrences en informatique Administrateur Base de donnes Snior
Enseignant-chercheur ESSILOR FRANCE
CNAM - Paris

Anne Universitaire 2015/2016
Page | 3

Mmoire dingnieur

Avant-propos

Le prsent mmoire rentre dans le cadre de l'obtention du diplme de fin d'tude du cycle
ingnieur informatique du Conservatoire National des Arts et Mtiers (CNAM), spcialit systmes
dinformation.
A lissue de mon rapport de recherche de deuxime anne sur la supervision informatique, de
nombreuses questions sont restes en suspens. En effet plusieurs aspects techniques,
mthodologiques et fonctionnels de notre logiciel de supervision de base de donnes (OEM)
restaient encore dcouvrir. Cest donc naturellement quest venue lide du sujet de ce mmoire
qui porte sur le dploiement de la nouvelle version dOracle Enterprise Manager Cloud Control
entreprise durant cette dernire anne de Master. En effet, Essilor a profit de larrive de la
nouvelle version de son principal logiciel de supervision pour bnficier des amliorations lies
ladministration de ses bases et des nouvelles fonctionnalits proposes par le logiciel. Ce projet
ma donc permis de mettre en pratique les connaissances acquises durant les annes prcdentes
chez Essilor. Jai galement pu appliquer les mthodologies de gestion de projet acquises au
CNAM directement cette mission.
Nous avons t confronts plusieurs difficults lors de ce projet. En effet, la phase de conduite
de changement destine rendre reproductible toutes les oprations techniques ralises et
exploiter les nouvelles fonctionnalits par les quipes administrateurs base de donnes en Asie a
reprsent un vraie dfi pour notre quipe.
Malgr les contraintes souleves par le dploiement de la nouvelle version dOEM, le calendrier
prvisionnel a pu tre respect. Le dploiement sest finalis la date prvue et la solution Cloud
Control est utilise par notre quipe pour superviser nos bases les plus stratgiques.
Page | 4

Mmoire dingnieur

Remerciements

En prambule, je veux adresser tous mes remerciements aux personnes avec lesquelles jai pu
changer et qui mont aid pour la rdaction de ce mmoire.
Je tenais remercier tout dabord mon tuteur dapprentissage Monsieur Nicolas Travers. Je le
remercie de mavoir encadr, orient, aid et conseill pour la rdaction de mon mmoire.
Jadresse mes sincres remerciements toute lquipe dadministrateurs base de donnes qui par
leurs paroles, leurs crits, leurs conseils et leurs critiques ont guid mes rflexions durant ma
mission.
Je remercie Monsieur Lamine Bouciouf qui ma accord son temps et a su me guider pendant la
phase de ralisation du projet.
Enfin, je remercie Monsieur Luc Perrin-Turenne et Monsieur Jean-Luc Guerin pour les rfrences
quils mont transmises au sujet de mes recherches.
Page | 5

Mmoire dingnieur

Table des matires

Avant-propos ...................................................................................................................................... 4
Remerciements ................................................................................................................................... 5
Table des matires .............................................................................................................................. 6
Liste des figures .................................................................................................................................. 9
Liste des tableaux ............................................................................................................................... 9
Table des sigles et abrviations ........................................................................................................ 10
I Introduction ............................................................................................................................. 12
I.1 Prsentation de lentreprise .................................................................................................. 12
I.2 Prsentation du dpartement ............................................................................................... 14
I.3 Prsentation du poste ........................................................................................................... 15
I.4 Prsentation de la mission .................................................................................................... 16
II Dfinition du projet ................................................................................................................... 17
II.1 Expression du besoin ............................................................................................................. 17
II.1.1 Note de cadrage ......................................................................................................... 17
II.2 Etude davant-projet .............................................................................................................. 20
II.2.1 Prsentation du produit ............................................................................................. 20
II.2.2 Architecture technique dOEM Cloud Control ............................................................ 20
II.3 Cahier des charges ................................................................................................................. 23
II.3.1 Les contraintes ............................................................................................................ 23
II.3.2 Critres de satisfaction ............................................................................................... 25
II.3.3 Dtail des versions logicielles dployes .................................................................... 26
II.3.4 Budget & Dlais .......................................................................................................... 26
II.3.5 Cahier des charges fonctionnel .................................................................................. 28
II.4 Etude de faisabilit ................................................................................................................ 29
II.4.1 Etude Rseaux ............................................................................................................ 29
II.4.2 Ressources alloues .................................................................................................... 30
II.4.3 Les risques et les impacts ........................................................................................... 31
III La solution Oracle Enterprise Manager Cloud Control 12c ....................................................... 33
III.1 Analyse de larchitecture dOEM ........................................................................................... 33
III.1.1 Cloud Control Console ................................................................................................ 34
III.1.2 Oracle Management Agent ......................................................................................... 35
III.1.3 Gestion et dcouverte des cibles supervises ............................................................ 36
Page | 6

Mmoire dingnieur

III.1.4 Oracle Management Service ....................................................................................... 37
III.1.5 Oracle Management Repository ................................................................................. 38
III.1.6 Flux de donnes .......................................................................................................... 40
III.2 Les choix dimplmentation dOEM Cloud Control 12c ......................................................... 42
III.2.1 Dfinition du nombre denvironnements Cloud Control mis en uvre ..................... 44
III.2.2 Environnement de production Vs Environnement de non-production ...................... 44
III.2.3 Dcision du choix darchitecture dOracle Cloud Control ........................................... 45
III.2.4 Dcision concernant sur le choix darchitecture de la base de donnes Repository .. 46
III.2.5 Dcision concernant le choix darchitecture dOracle Management Server .............. 47
III.2.6 Dcision concernant le choix de regroupement du serveur OMS et de la base OMR 48
III.3 Conclusion ............................................................................................................................. 49
IV Ralisation ................................................................................................................................. 50
IV.1 Introduction ........................................................................................................................... 50
IV.1.1 Installation dune base de donnes Repository .......................................................... 51
IV.1.2 Etape 1 : Installation du logiciel Grid Infrastructure (facultative) ............................... 52
IV.1.3 Etape 2 : Installation du logiciel de base de donnes ................................................. 53
IV.2 Configuration de la base de donnes Repository .................................................................. 57
IV.2.1 Renommage des fichiers de donnes Cloud Control .................................................. 58
IV.2.2 Dsactivation de loptimisateur de rcupration automatique des statistiques ....... 58
IV.2.3 Cration de groupes de redo logs additionnels .......................................................... 59
Implmentation des HugePages ............................................................................................... 60
IV.2.4 Activation de la base de donnes Flashback (Flashback Database) ........................... 61
IV.2.5 Activation du Block Change Tracking .......................................................................... 62
IV.2.6 Excution du Kit de prrequis de OEM en mode indpendant .................................. 62
IV.3 Installation et Configuration dOracle Enterprise Manager Cloud Control ........................... 63
IV.3.1 Ractivation de loptimisateur de rcupration automatique des statistiques ......... 63
IV.3.2 Mise en uvre des variables denvironnement sur le serveur-hte OMS ................. 63
IV.3.3 Planification des purges priodiques des fichiers logs de Cloud Control ................... 64
Mise en place de la politique de sauvegarde des composants de Cloud Control ..................... 65
IV.4 Configuration de la console Cloud Control ............................................................................ 65
IV.4.1 Mise en place des mthodes de notification .............................................................. 66
IV.5 Conclusion ............................................................................................................................. 69
V Aprs Projet ............................................................................................................................... 70
Page | 7

Mmoire dingnieur

V.1 Conduite du changement ...................................................................................................... 70
V.1.1 Dtails et explications de ladministration de Cloud Control ..................................... 70
V.1.2 Analyse des amliorations dadministration .............................................................. 71
V.2 Maintenance oprationnelle ................................................................................................. 76
V.2.1 Alarmes, alertes et mtriques de supervisions ........................................................... 76
V.2.2 Configuration des rgles dincidents dans OEM 12c .................................................. 78
VI Conclusion ................................................................................................................................. 79
Glossaire ........................................................................................................................................... 80
Rfrences Bibliographiques ............................................................................................................ 81
Annexes ............................................................................................................................................ 82
Table des matires ........................................................................................................................ 82
I. 11gR2 Database Installation (11.2.0.4) on Linux server x64 ..................................................... 83
II. Oracle Enterprise Manager Cloud Control 12c Installation ....................................................... 99
1. Starting Cloud Control and all Its Components ................................................................... 106
2. Stopping Cloud Control and all Its Components .................................................................. 107
III. OEM 12c Agent installation & Database Discovery with Cloud Control .................................. 108
IV Planning prvisionnel .............................................................................................................. 119
Implmentation et exploitation dOracle Enterprise Manager CC v12c ......................................... 120
Installing and exploiting Oracle Enterprise Manager CC v12c ........................................................ 120

Page | 8

Mmoire dingnieur

Liste des figures

Figure 1: Prsentation du dpartement ........................................................................................... 14
Figure 2: Schma du processus de notification ................................................................................ 18
Figure 3: Planning prvisionnel ........................................................................................................ 27
Figure 4: Architecture dOracle Enterprise Management Cloud Control 12c ................................... 33
Figure 5: Flux de donnes ................................................................................................................. 40
Figure 7:Mise en place des adresses mails des administrateurs ...................................................... 67
Figure 8: Ecran de lemploi du temps des notifications luvre chez EssilorError! Bookmark not
defined.
Figure 9: Ecran de lemploi du temps des notifications luvre chez Essilor ................................ 68
Figure 10: Ecran de mise en place de la priode rotation chez Essilor ............................................. 68
Figure 11: Fentre de cration dune accrditation ......................................................................... 72
Figure 12: Fentre de cration dune accrditation ............................. Error! Bookmark not defined.
Figure 13: Fentre de gestion de dlgation des privilges ............................................................. 73
Figure 14: Fentre daudit de control OEM 12c ............................................................................... 74
Liste des tableaux

Tableau 1: Prrequis rseaux minimum ncessaires de connexion ................................................. 30
Tableau 2: Ordre de grandeur des sites superviss .......................................................................... 45
Tableau 3: Adquation entre la taille du site supervis et la taille recommande des redo logs .... 56
Tableau 4: Statut actif de l'Auto Optimizer Stats Collection ............................................................ 59
Tableau 5: Hugepage ........................................................................................................................ 60
Tableau 6: Statut inactif de l'Auto Optimizer Stats Collection ......................................................... 63
Tableau 7: Commandes d'arrt et de dmarrage de l'agent ............................................................ 64
Tableau 8: Objectifs et mthodes dployes pour scuriser OEM Cloud Control ........................... 75
Tableau 9: Seuils d'alertes OEM ....................................................................................................... 77
Tableau 10: Rgles d'incident OEM .................................................................................................. 78
Page | 9

Mmoire dingnieur

Table des sigles et abrviations

ASLM : Application Service Level Management / Niveau de service dapplication
ASM : Automatic Storage Management / Gestion de Stockage Automatique
ASMM : Automatic Shared Memory Management/Gestion du Partage de la Mmoire Automatique
BP : Best Practice / Meilleure mthode
CC : Cloud Control / OEM 12c
CFC : Cold Failover Cluster
CNAM : Conservatoire National des Arts et Mtiers
CPU : Central Processing Unit / Unit Centrale de Calcul
DBA : Database Administrator / Administrateur Base de donnes
DBCA : Database Configuration Assistant / Assistant de Configuration de base de donnes
DR : Disaster Recovery / Rcupration aprs Dsastre
ERP : Enterprise Ressource Planning / Gestion des ressources dentreprise
EUS : Enterprise User Security
FMA : Functional Maintenance Applicative / Equipe de Maintenance Fonctionnelle
FRA : Fast Recovery Area / Zone de Rcupration Rapide
GC : Grid Control / OEM 10g
GI : Grid Infrastructure / Infrastructure Grid
GigE : Gigabit Ethernet
HA : High Availability / Haute Disponibilit
HTTP/HTTPS : Hypertext Transfer Protocol / Hypertext Transfer Protocol Secure
ICMP : Internet Control Message Protocol / Protocole de Control de Message Internet
JDBC : Java Database Connectivity / Connectivit de base de donnes Java
MAA : Maximum Availability Architecture / Architecture de Disponibilit Maximale
NAS : Network Attached Storage / Stockage Rseaux
NC : Named Credential / Accrditation nominative
NLS : National Language Support / Support de Langage National
OAS : Oracle Application Server / Serveur dApplication Oracle
OCI : Oracle Call Interface
ODG : Oracle Data Guard
OEM : Oracle Enterprise Manager
OHS : Oracle HTTP Server
OMA : Oracle Management Agent
OMF : Oracle Managed File
OMR : Oracle Management Repository / Base de donnes Repository
OMS : Oracle Management Server
ORON : Real Application Clusters (RAC) One Node
OUI : Oracle Universal Installer / Installateur Universel Oracle
PSU : Patch Set Update / Groupe de mises jour
RAC : Real Application Cluster
RAM : Random Access Memory / Mmoire Accs Alatoire
Page | 10

Mmoire dingnieur

RMAN : Oracle Recovery Manager / Gestionnaire de Rcupration Oracle
SAN : Storage Array Networks / Rseau de Stockage
SGA : System Global Area / Zone Globale Systme
SGBD : Systme de Gestion de Base de donnes
SLA : Service Level Agreement / Contrat de niveau de service
SLB : Server Load Balancing / Serveur Rpartition des charges
SMTP : Simple Mail Transfer Protocol / Protocole de transfert de Mail
SSL : Secure Socket Layer
TMA : Tierce Maintenance Applicative / Equipe de Maintenance Technique
T-Center : Developer Team / Equipe de dveloppeur
WLS : WebLogic Server
WWSCP : World Wide Supply Chain / Logistique
Page | 11

Mmoire dingnieur

I Introduction
Dans le cadre de ma formation dingnieur informatique en
apprentissage jai t recrut par ESSILOR en tant quapprenti
administrateur de bases de donnes Oracle et Oracle Application pour
une dure de trois ans.
Jai t intgr au sein de lquipe DBA Oracle (Administrateur de base
de donnes) du dpartement logistique WWSCP (World Wide Supply
Chain Project) qui appartient la branche logistique dEssilor sur le site
de Crteil.
Cette quipe est compose de six DBA Oracle (trois en France et trois
en Asie) et dun manager qui pilote lactivit de cette quipe.
Il sagit dune quipe oprationnelle qui est charge de la
maintenance de toutes les bases de donnes Oracle utilises dans les
applications gres dans le dpartement WWSCP.
Cette quipe joue un rle cl au sein de ce dpartement car elle gre
notamment les bases de production. Ces bases sont stratgiques car
elles sont directement lies lactivit de ce dpartement.
Je vais maintenant vous prsenter le contexte de mon travail, lquipe dans laquelle jeffectue
mon apprentissage, ainsi que la mission qui ma t confie dans le cadre de ce mmoire.
I.1 Prsentation de lentreprise

Activits
Essilor International, leader mondial de la production de verre ophtalmiques,
doit sa position de leader tant la qualit de ses produits que de ses
services. En 2015, le chiffre daffaire de la socit a augment de 18.4 % par
rapport lanne 2014 avec 6 716 M. Essilor fait partie de lindice CAC40
depuis 2005.
Structure Organisationnelle
La majeure partie de lactivit dEssilor soriente sur les 4 axes principaux suivants :

Ces axes sont grs au travers de son systme dinformation qui a normment volu depuis la
cration de lentreprise.
Page | 12

Mmoire dingnieur

Systme dInformation
Aujourdhui, cest lui qui coordonne les activits de lentreprise, qui vhicule linformation au sein
de l'organisation, et qui reprsente l'ensemble des ressources et systmes du groupe ayant pour
but :
La saisie des informations
Le stockage des informations
Le traitement des informations
La restitution des informations
La transmission des informations
etc.

Diffrents supports sont utiliss pour matrialiser ces informations dans le SI tels que :
Les bases de donnes (Oracle, SQL Server, etc.)
Les serveurs de fichiers,
Les intranets,
Les GED,
etc.
Page | 13

Mmoire dingnieur

I.2 Prsentation du dpartement

Figure 1: Prsentation du dpartement

Chez Essilor, suite une rcente rorganisation des services, lquipe DBA prcdemment
base Vincennes a rejoint le dpartement WWSCP Crteil Oudry ; World Wide Supply Chain
Project, service dans lequel jvolue dans le cadre de mon apprentissage Essilor. Elle travaille
conjointement avec les quipes Projets / TMA (Tierce Maintenance Applicative) et FMA
(Functional Maintenance Applicative) qui sont notamment charges du support technique et
fonctionnel des applications.
De plus, avec les rattributions des responsabilits lies laugmentation de la taille de
lentreprise et de son internationalisation, le scope de bases de donnes gres par lquipe DBA
sest considrablement diversifi et largi ; notamment par la gestion de nouvelles bases
anciennement gres par dautres quipes travaillant pour lessentiel ltranger.
Le scope couvert par les DBA (Administrateur de bases de donnes) comprend aujourdhui un
ensemble de bases de donnes fonctionnant sur plusieurs versions de SGBD (Systme de Gestion
de Base de Donnes) notamment Oracle et SQL Serveur, hberges sur diffrents OS (Linux, Unix,
Windows Server, ), et sur diffrents sites (Asie, Europe, US, ).
Notre quipe maintient plus dune dizaine de base de donnes de production. Ces bases sont
particulirement surveilles car elles sont essentielles au fonctionnement de nos modules ERP
Oracle Application. De plus nous grons galement des bases de donnes issues denvironnements
de test et dintgration qui sont principalement utiliss par le T-Center et la TMA.
Page | 14

Mmoire dingnieur

I.3 Prsentation du poste

Pour comprendre et apprendre le mtier de DBA, il convient de connatre tout dabord les
diffrents rles que ladministrateur base de donnes doit pouvoir grer et matriser :

La conception du modle de donnes : bien qu'elle incombe normalement l'analyste ou
au concepteur, les principes de modlisation des donnes doivent tre parfaitement
maitriss par le DBA. En effet, les facteurs de dgradation des performances sont en
premier lieu lis la structuration des donnes.

La dfinition et la gestion des espaces de stockage : Comme une base de donnes a
besoin de beaucoup de place pour les donnes, il doit dimensionner les espaces de
stockage physiques (ex : Disque dur) et logiques (ex : Tablespaces) de faon prcise.

L'intgrit des donnes : il vrifie ou aide vrifier la cohrence des donnes de la base
afin qu'elles ne rentrent pas en conflit avec les principes du systme rel.

La gestion des incidents : il doit crer et tester des solutions de maintien (procdures de
rcupration) afin dassurer la continuit de la production en cas dincidents.

Le maintien de la performance : il doit sassurer que l'accs aux donnes se fasse dans un
temps raisonnable et que cette performance soit maintenue dans le temps.

L'optimisation : il doit rgulirement et de manire proactive faire des campagnes de
mesure afin de dbusquer les problmes de contention ou de temps de rponse avant
qu'ils ne deviennent handicapants pour l'exploitation de lentreprise.

Migration et mises jour : il doit rgulirement appliquer les mises jour prconises par
les diteurs (systme et SGBD).
Page | 15

Mmoire dingnieur

I.4 Prsentation de la mission

Mon sujet de mmoire de fin dtude dingnieur CNAM porte sur ma mission principale de cette
troisime anne dingnieur en entreprise. Celle-ci consiste au remplacement progressif de notre
logiciel de supervision de bases de donnes Oracle Entreprise Manager (OEM).
Plus prcisment, je vais procder au remplacement de la version 10g existante de cet outil par sa
version la plus rcente en 12c.
Je vais directement intervenir dans la partie support du systme dinformation dEssilor.
Le premier objectif qui ma t donn par lquipe DBA (Database Administrator ou
Administrateur de base de donnes) est didentifier puis de mettre en place tous les lments
permettant limplmentation de la version 12c du logiciel, plans de maintenance inclus.
Ce nouvel outil permettrait de faire bnficier dans un premier temps lquipe DBA dune
supervision des bases de donnes amliore, de paramtrages plus fins du systme denvoi des
alertes ainsi que de mtriques plus dtailles pour faciliter la rsolution des incidents. Ceci
permettant doptimiser la supervision des bases de donnes stratgiques de lentreprise.
Le second objectif de cette mission est double. Je suis charg danalyser les nouvelles
fonctionnalits du logiciel et de les communiquer mon quipe afin de lui faire profiter de mes
dcouvertes. Je dois galement prparer la conduite du changement afin de faciliter la transition
entre les deux versions dOracle Entreprise Manager.
Mon sujet se situe donc dans la continuit de mon rapport de recherche rdig lanne
prcdente. En effet, celui-ci portait sur la supervision informatique dans lequel ont t
dvelopps les enjeux et les mthodologies de la supervision des bases de donnes ainsi que les
potentielles amliorations fonctionnelles et ergonomiques quapporterait la monte dOracle
Entreprise Manager en version 12c.
Cette mission ma t confie dans son intgralit, depuis la rdaction de lexpression du besoin
jusqu la phase daprs projet avec la rdaction du plan de maintenance et du plan de conduite
de changement.
Ce projet est soumis au contrle de notre expert DBA Oracle qui est charg de ma formation pour
les parties techniques de la ralisation. Plus concrtement les phases dinstallation de la base de
donnes dpt et du logiciel Oracle Entreprise Manager seront opres sur un serveur Linux
donn via une connexion distance. Les tapes suivantes seront, quant elles, effectues
directement sur linterface OEM.
Je dispose galement dune documentation spcialise destine me former et dcouvrir les
spcificits de la version 12c de ce nouvel outil.
Les aspects organisationnels de la mission sont, quant eux, soumis mon suprieur, manager
dquipe.
Page | 16

Mmoire dingnieur

II Dfinition du projet
Nous allons maintenant dfinir compltement le rfrentiel du projet. Nous dvelopperons les
lments du rfrentiel du projet suivant :
Lexpression du besoin
Ltude davant-projet
Le cahier des charges
Ltude de faisabilit

Cette phase est particulirement importante pour nous car elle va nous permettre de mettre en
uvre une dmarche de conduite de projet organise, cohrente et collective.
II.1 Expression du besoin

Dans le cadre de ma mission de cette troisime anne en entreprise je suis charg de mettre en
uvre toutes les tapes suivantes :
1re tape : Implmentation et mise en fonctionnement dOracle Enterprise Manager 12c
2ime tape : Rdaction des procdures dinstallation et de dploiement du logiciel
3ime tape : Analyse et transmission lquipe DBA des nouvelles fonctionnalits phares de la
nouvelle version de loutil
4ime tape : Mise en uvre de la conduite du changement du logiciel
La date de fin de la mission est fixe pour la fin Juin 2016.
II.1.1 Note de cadrage

Nous expliquerons dans cette partie les principaux enjeux lis au dploiement de la nouvelle
version dOEM. Aprs avoir explicits les raisons de cette mission, nous nous intresserons aux
objectifs que nous nous sommes fixs permettant de rpondre la problmatique expose.
II.1.1.1 Contexte
En ce jour, le dpartement World Wide Supply Chain (WWSCP ou Logistique) dans laquelle
lquipe DBA opre possde une architecture informatique htrogne en raison du
renouvellement progressif du parc informatique et logiciel dEssilor (machines, systmes
dexploitation, ordinateurs de bureau, licences logicielles etc.)
Comme toute socit qui possde des systmes informatiques, Essilor doit grer lobsolescence de
ses systmes et de ses applications.
En effet une partie de nos serveurs et de nos applications vieillissantes sont renouveles
progressivement. Essilor possde de ce fait des environnements techniques diffrents adapts aux
applications plus ou moins rcentes fonctionnant sur nos systmes.
En raison de lhtrognit de ces environnements, notre parc de bases de donnes est
galement diversifi car elles sont hberges sur des architectures techniques adaptes ces
applications.
Page | 17

Mmoire dingnieur

Nous possdons par consquent des bases de donnes Oracle dont les versions vont des
anciennes versions 7 jusquaux plus rcentes en 11gR2.

Afin de faire face la complexit engendre par les problmes daccessibilit, de rseau ou de
performance et de faciliter la maintenance des bases de donnes, lquipe DBA a d mettre en
place trois outils de surveillance qui sont destins alerter les administrateurs de tous
disfonctionnements et comportements anormaux des bases de donnes dont ils ont la charge :
Patrol (logiciel de la socit BMC Software)
o Version v3.5 : assure la surveillance des bases Oracle : versions 7 8i
o Version v7.6 : assure la surveillance des bases Oracle : versions 9i 10g
OEM (Oracle Entreprise Manager, logiciel de la socit Oracle)
o Version 11g : Assure la surveillance des bases 11gR2.

La Figure 2 rsume le processus de notification existant des alertes provenant des logiciels Patrol
et OEM.
Figure 2: Schma du processus de notification

Note : Lencadr Rapport Alertes multiplateformes a fait lobjet de ma mission de suivi des
alertes de ma premire anne de cycle ingnieur.
Page | 18

Mmoire dingnieur

II.1.1.2 Problmatique
Au cours de ces dernires annes, le parc de bases de donnes a subi une forte augmentation
pour rpondre aux besoins croissants de lentreprise. De faon parallle, les besoins en termes de
maintenabilit des bases de donnes se sont intensifis et la performance de loutil existant qui les
supervise nest aujourdhui plus satisfaisante pour plusieurs raisons :

I. La version de loutil de supervision existant OEM v10g ne centralise pas les alertes et les
incidents de toutes les bases de donnes quelle supervise. Plus prcisment chaque DBA
doit se connecter individuellement sur chaque serveur hbergeant la ou les bases en
question pour effectuer son analyse ou ses modifications. Cela complique la tche
dadministration du DBA et engendre au mme titre une perte de productivit.
II. Un des objectifs sous-jacents de la mise niveau dOEM en sa version 12c est de remplacer
court terme le logiciel Patrol v3.5 et Patrol v7.6. Ceci aurait pour consquence de
simplifier larchitecture applicative de lentreprise et de bnficier par la mme occasion
dun outil certifi unique pour toutes nos bases de donnes Oracle et Oracle application
(ERP).
Notre quipe est donc confronte une problmatique multiple :

Comment implmenter et exploiter OEM 12c au sein de notre environnement informatique tout
en garantissant une supervision continue pour nos bases de donnes ?
II.1.1.3 Objectifs atteindre

Loutil de surveillance de bases de donnes OEM envoie les alertes sous forme de mail dont les
messages sont formats de faon rendre une information qui soit rapidement dchiffrable. Le
remplacement des versions existantes de Patrol permettra donc de rcuprer sous la mme forme
et via le mme biais de communication tous les incidents et alertes de bases de donnes
supervises par notre quipe. Cette solution prsente lavantage de permettre notre quipe de
crer des filtres sur la messagerie qui leur est commune. De cette faon, chacun peut discriminer
efficacement la criticit des alertes et des incidents en cours.
De plus, la monte de version dOracle Entreprise Manager fera bnficier toute lquipe de
nombreuses nouvelles fonctionnalits destines simplifier et amliorer lefficience de notre
travail. Ces nouvelles fonctionnalits seront explicites en dtail plus tard dans ce mmoire.
Page | 19

Mmoire dingnieur

II.2 Etude davant-projet

Nous prsenterons dans cette partie la manire dont fonctionne Oracle Enterprise Manager en
tudiant ses lments internes et leurs interactions. Nous nous pencherons galement sur les
diffrentes contraintes lies notamment aux prrequis du logiciel auxquels nous devrons
rpondre.
II.2.1 Prsentation du produit

Oracle Enterprise Manager Cloud Control 12c (plus souvent rfrenc comme Cloud Control, CC,
ou CC 12c) est une solution Oracle pour superviser un environnement informatique complet quil
soit compos de produits Oracle ou non. Loutil Cloud Control runit les informations concernant
un systme informatique en centralisant sa supervision dans un rpertoire central. OEM CC affiche
les informations aux administrateurs responsables dans une console web puis loutil leur envoie
des alertes bases sur des seuils plus ou moins critiques. Les superviseurs peuvent alors utiliser ces
informations pour que Cloud Control opre les tches permettant la supervision de tout le
systme informatique de lentreprise.
OEM v12c est bas sur la technologie Oracle, une base de donnes Oracle et un serveur WebLogic
de niveau intermdiaire (Middle Tier) qui hberge lapplication OMS (Oracle Management
Service). Pour rsumer, une base de donnes Oracle va servir de base de donnes dpt
appel aussi OMR (Oracle Management Repository), celle-ci va stocker toutes les donnes de
mtriques des cibles supervises. Ces donnes sont collectes et transmises par des agents locaux
appels OMA (Oracle Management Agents). Ces agents envoient ces donnes au service OMS qui
va envoyer son tour ces informations la base de donnes pour que celle-ci les stocke. Le service
OMS va gnrer une page dinterface web aux administrateurs, celle-ci va servir de passerelle de
communication entre les oprateurs CC et la base de donnes Dpt.
II.2.2 Architecture technique dOEM Cloud Control

Linstallation et larchitecture dOracle Enterprise Manager GC v10g et de CC v12c ne sont pas les
mme car leurs composants diffrent. De plus, les modes de fonctionnement du service OMS et
de la base de donnes dpt sont bien distincts :
II.2.2.1 Installation et architecture du logiciel OMS

La version 12 dOracle Management Service est base sur un Serveur Weblogic Oracle (WLS) 11g
R1 (10.3.5) tandis que la version 10g dOMS est base sur un serveur dapplication Oracle (v
10.1.2.3). Cette amlioration darchitecture a renforc la scurit des flux de donnes entre les
diffrents composants de Cloud Control.
Page | 20

Mmoire dingnieur

II.2.2.2 Installation de la base de donnes dpt

Dans les versions 11g et 12c dOEM, linstallation de la base de donnes dpt ou Repository
est spare de linstallation dOEM. Dans la version GC 10g, une des options dOracle Universal
Installer (OUI) tait (en plus de linstallation dOMS) de crer une nouvelle base de donnes 10g
pour servir de base de dpt. Les versions GC 11g et 12c de loutil ne disposent pas dune base de
donnes intgre pour servir de base Repository. Contrairement la version 10g, nous avons donc
tout dabord prinstall une base de donnes Oracle pour procder linstallation de la version
12c. Nanmoins, CC v12.1.0.4 propose un modle dans lassistant de configuration de bases de
donnes (Database Configuration Assistant ou DBCA) qui crer une base Repository prconfigure.
II.2.2.3 Prrequis de linstallation dOracle Cloud Control 12c

Avant de procder linstallation dOEM 12c, nous devons dabord installer une base de donnes
certifie pour hberger les donnes de supervision du logiciel contrairement OEM Grid Control
10g o lon devait choisir dinstaller dans un premier temps une base de donnes Oracle 10g ou
11g par lintermdiaire dOracle Universal Installer. Il sagit ici dune diffrence darchitecture
substantielle entre la version v10g et les celles en v11g et v12c. Cela est d au fait quOracle
propose ce jour trop de types dinstallations de bases de donnes diffrentes (groupes de patchs
inclus) dans OEM v11g et v12c pour les inclure dans linstallateur de loutil.
Les versions des bases de donnes et des groupes de patchs inclus les versions v11.2.0.1+,
v11.1.0.7 et v10.2.0.5+.
Les types dinstallation proposs sont varis :
Un Oracle RAC (Real Application Cluster)
Un Oracle RAC one-node (ORON)
Une base de donnes unique : Cest le choix que notre quipe DBA a pris. Nous
expliquerons les raisons de ce choix un peu plus loin dans ce mmoire.
Un Cold Failover Cluster (CFC)
Page | 21

Mmoire dingnieur

II.2.2.4 Diffrences concernant WLS

Dans la version 10g, le service OMS est une application de niveau intermdiaire base sur la
plateforme Java 2 Entreprise Edition (J2EE) qui gnre linterface utilisateur, cest--dire la console
GC. (J2EE est un environnement de dveloppement et de dploiement dapplications
dentreprise). La couche intermdiaire de GC 10g qui utilise Oracle Application Server (OAS ou
Oracle AS) 10g, contient 3 lments :
1. Oracle Application Server Containers pour J2EE (OC4J) ou Serveurs Conteneurs
dapplications Oracle
2. Oracle HTTP Server (OHS) ou Serveur HTTP Oracle
3. Oracle AS Web Cache

OHS dploie la version 10g du Management Service J2EE web Application.
OMS 10g quant lui fait techniquement partie dOC4J toutefois, la couche intermdiaire de GC
10g fait habituellement rfrence OMS.
OracleAS Web Cache fournit un moyen supplmentaire de sidentifier dans la console GC.
Contrairement la version 10g o OMS est dploy dans son propre conteneur OC4J, chacune des
plateformes intergiciels GC v11 et CC 12c se composent dune instance WLS dans laquelle un
domaine dapplication OMS est cr (appel GCDomain).
De plus, OracleAS Web Cache nest pas utilis dans les versions GC v11g et CC v12c alors que celui-
ci est exploit dans la version GC v10g. De ce fait, les versions 11g et 12c possdent un avantage
certain vis--vis de la version 10g pour plusieurs raisons :
OracleAS Web Cache ne savre finalement pas trs utile dans GC v10g car ce dernier ne fournit
quun trs lger gain de performance par rapport lidentification directe sur OHS depuis la
console GC. La plupart des requtes de la console tant ad hoc, celles-ci sont faites pour traiter
des donnes dynamiques avec trs peu de donnes en cache. Gnralement, les donnes se
limitent des icnes, des items de menus, des en-ttes et pieds de page.
OracleAS Web Cache complique le diagnostic des problmes de GC v10g.
Enfin, Laccs la console OEM via le Web Cache nest pas scuris (sur HTTP port 7777) lorsque
lon sort des sentiers battus. En effet, le processus de configuration pour scuriser un tel accs
nest pas ais et nest pas document. Il sagit ici dune faille de scurit pour les sites qui veulent
utiliser Web Cache et qui ont besoin de renforcer la scurit des communications entre tous les
composants de GC v10g.
Bien quOracle donne ses clients le choix de construire leurs propres applications sur OC4J ou
WLS, elle a choisi dimplmenter WLS dans sa solution Cloud Control , pour des raisons de scurit
et de maintenabilit logicielle.
Page | 22

Mmoire dingnieur

II.3 Cahier des charges

Nous expliquerons dans cette partie quelles sont les contraintes et les attentes lies Cloud
Control.
II.3.1 Les contraintes

Nous allons nous intresser maintenant aux contraintes ncessaires linstallation et
lexploitation de notre environnement Cloud Control. Nous allons mettre en lumire les dcisions
auxquelles notre quipe doit se confronter au niveau de larchitecture de loutil.
Nous parlerons notamment de la question du nombre denvironnement CC 12c installer ainsi
que de larchitecture choisie de ses lments.
Nous nous intresserons ici aux prrequis des lments de CC suivant :
Oracle Management Service : Un service OMS doit tre install sur le serveur-hte sur
lequel linstalleur est excut.
Oracle Management Repository : La base de donnes dpt appele aussi base dpt ou
OMR est cre partir dune base de donnes que vous devez avoir prinstalle.
Oracle Management Agent : Un agent ou OMA est install sur chaque serveur-hte
que vous voulez superviser avec Cloud Control. Il existe deux types dagents : lagent
prinstall et lagent autonome.
Agent prinstall : Linstallation de ces types dagents (Chain-installed Agent) est couple
avec celle OMS, par consquent, celle-ci est ralise de faon automatique par
linstallateur OUI. Comme nimporte quel agent, il supervise les cibles du serveur-hte sur
lequel il est install dont OMS et la base Repository si ces derniers sont installs sur le
mme serveur-hte.
Agent autonome : Contrairement lagent prinstall, les agents autonomes (Standalone
Agents) doivent tre installs manuellement sur tous les serveur-htes hbergeant des
cibles supervises except le serveur OMS lui-mme sur lequel lagent est prinstall. Le
dploiement dagents autonomes doit tre opr aprs linstallation de la base Repository
et du service OMS. Ces deux types dagent exigent les mmes prrequis. Une fois installs,
ces agents sont en tout point identiques.
CC Console Client : Il sagit ici de la console client de Cloud Control. Celle-ci est rserve
aux administrateurs de bases de donnes. Ces derniers se connectent la console via un
navigateur internet. La console est affiche par OMS et celle-ci na pas besoin dtre
installe sparment. Les seuls prrequis ncessaires relatifs la console concernent la
bande passante du rseau et la latence maximale autorise entre le poste client et OMS.
Page | 23

Mmoire dingnieur

Les prrequis explicits ici sappliquent aux serveurs-htes sur lesquels OMR, OMS et les agents
prinstalls seront installs, ceux o les agents autonomes seront dploys et aux postes clients
chargs dafficher la console Cloud Control. Tous ces prrequis reprsentent, en plus des autres
bases de donnes qui hbergent la base de dpt, lensemble de tous les prrequis ncessaires
linstallation et lexploitation dun environnement CC 12c.
Les tches de pr-installation sorganisent en quatre catgories :
Conception architecturale : Le premier prrequis consiste concevoir une architecture de
CC qui prend en compte le nombre denvironnements CC mettre en place et le nombre
de serveurs OMS installer. Nous devons galement prendre en compte tous les critres
de hautes disponibilits (HA) et des plans de rcupration aprs sinistre.
Configuration rseaux : Aprs stre mis daccord sur larchitecture de Cloud Control
dployer, la deuxime tape consiste satisfaire les prrequis de la configuration rseaux
en passant par les rgles et les contraintes de nommage des serveurs-htes, les tests de
connectivit entre les diffrents lments de CC, la configuration des pare-feux et du
systme dquilibrage (Load Balancing) des charges du serveur si un tel systme est utilis.
Prrequis matriel : Cette catgorie fournit des spcifications concernant OMR, OMS et les
serveurs-htes hbergeant les agents relatifs aux ressources (espace disque, RAM, swap et
rapidit du CPU) ncessaires pour satisfaire les prrequis ncessaires linstallation et
lexploitation de CC.
Prrequis logiciel : Nous devons tout dabord vrifier que les plateformes OMS et OMR
rpondent aux prrequis ncessaires la certification Cloud Control. Il faut crer les
groupes systmes, les utilisateurs et les rpertoires. Il faut synchroniser les fuseaux
horaires des serveurs-htes et satisfaire les prrequis des plateformes logicielles
spcifiques.
Il est important de souligner que nous avons d tout dabords satisfaire les prrequis ncessaires
linstallation de OMR et OMS avant dexcuter linstallateur de Cloud Control (Oracle Universal
Installer). Toutefois, les prrequis ncessaires linstallation des agents autonomes peuvent tre
retards et tre satisfait aprs la phase dinstallation de CC. Il est fortement conseill de sassurer
au minimum que les prrequis des agents prinstalls (chain-installed agent) soient satisfaits sur
les serveur-htes sur lesquels les agents autonomes sont oprationnels. En effet, un certain
nombre de ces prrequis sont relatifs aux exigences rseaux demandes qui sont la plupart du
temps vrifis par ladministrateur rseaux lui-mme.
Page | 24

Mmoire dingnieur

II.3.2 Critres de satisfaction

a. La centralisation des informations
Dans ce projet, le principal critre de satisfaction attendu par limplmentation de cette nouvelle
version dOEM repose sur la centralisation des informations relatives aux bases de donnes
supervises. En effet jusqu maintenant il fallait configurer pour chaque base supervise un
ensemble de rgles dincidents et de notifications. Cela pouvait poser problme en termes de
maintenabilit de ces bases de donnes. Grce la nouvelle interface fournie dans Cloud Control,
il sera dsormais possible de surveiller les activits de lintgralit de nos bases de donnes via la
mme console utilisateur ce qui reprsente une amlioration substantielle dans le travail de
maintenance quotidienne de notre quipe.

b. Fonctionnalits amliores
Oracle Enterprise Manager 12c nous fera profiter des fonctionnalits amliores. Voici deux
exemples des amliorations attendus :

Amlioration du fonctionnement interne de Cloud Control : Beaucoup doprations de
contrle des agents de supervisions sont maintenant disponibles. Par exemple le
dmarrage, le redmarrage et larrt des agents sont ds prsent accessibles sur
linterface de gestion du systme.
De plus, tous problmes entre les agents de supervisions et le service Oracle Management
sont dsormais automatiquement dtects et peuvent tre traits dans la section de
traitement des incidents du systme. Dans cette section, on peut accder au support de
test qui va tablir pour vous le diagnostic du problme rencontr. Ce support peut par la
suite utiliser le diagnostic tabli pour lenvoyer au support Oracle qui pourra trouver une
solution ce problme. Cela a pour avantage de faire conomiser du temps aux quipes
support concerns de lentreprise, notamment en matire de rsolution des incidents.

Amlioration des mtriques : Les mtriques de linterface utilisateur ont t amliores et
permettent une meilleure navigation et un meilleur accs aux donnes de mesure. On a
accs aussi aux mtriques dont les alertes ont t le plus souvent dclenches sur sept
jours la nouvelle fonctionnalit de suggestion de seuils est maintenant disponible pour
nous aider affiner notre configuration.

Page | 25

Mmoire dingnieur

c. Nouvelles fonctionnalits
Jai par ailleurs lister les nouvelles fonctionnalits proposes, afin dtudier lvolution du mtier
de maintenance pour les DBA au sein de lquipe dEssilor. Deux nouveaux dispositifs sont
disponibles :

Les actions correctives sur les incidents : Nous pourrons effectuer des actions correctives
sur des incidents dans un groupe ou un systme depuis le tableau de bord systme. Ces
actions peuvent tres assignes des personnes et une liste de priorit peut tre tablie
sur les incidents les plus urgents rsoudre.

La mise en place dalertes sensibles au temps : Diffrents seuils dalertes pourront tre
configurs en fonction du temps. Par exemple, durant la journe, nous pourrons tablir un
seuil dalerte relativement exigeant, pouvant dtecter tout dlai anormal concernant
lmission de requtes SQL par les utilisateurs. Mais en soire, parce quun certain nombre
de scripts tournent, nous pouvons baisser les seuils dalertes car les enjeux ne sont pas les
mmes en journe et en soire.
II.3.3 Dtail des versions logicielles dployes

Version du logiciel install : Oracle Enterprise Manager Cloud Control 12c v12.1.0.4
Version de la base de donnes installe : Oracle Database v11.2.0.4
Version du modle de base de donnes installe : DB Template v12.1.0.2
Version des agents dploys sur les serveurs-cibles : Oracle Enterprise Agent v12.1.0.2.0
II.3.4 Budget & Dlais

a. Budget Logiciel
Oracle Enterprise Manager est logiciel de gestion de bases de donnes propos par Oracle en
libre-service. Contrairement aux logiciels concurrents tels que Patrol utiliss pour superviss les
bases de donnes Oracle v7i et v8i.
Bien quil soit gratuit, ce nest pas le critre qui a t pris en compte quant ladoption de ce
logiciel. Dautres critres plus importants tels que la disponibilit de documentations en ligne, la
certification de prise en charge des bases Oracle (versions suprieures 8i) par OEM et de la
fiabilit dOracle ont t pris en compte.
b. Budget Humain
Les mthodes de dploiement et de configuration dOEM ont t supervises par lexpert DBA
Oracle de notre quipe, un deuxime administrateur Oracle et moi-mme pendant un peu plus de
6 mois.
Pour des raisons de confidentialit, il nest pas possible de fournir plus de dtails vis--vis du
budget allou ce projet.

Page | 26

Mmoire dingnieur

c. Dlais
Le dtail du planning prvisionnel est fourni en annexe. Le projet a dbut le premier dcembre
2015 et sest rellement termine le 20 mai 2016.
Voici un bref rcapitulatif du planning prvisionnel des diffrentes phases du projet

Figure 3: Planning prvisionnel
Page | 27

Mmoire dingnieur

II.3.5 Cahier des charges fonctionnel

Outre les besoins prcdemment dfinis pour lquipe de DBA en termes de maintenance, Oracle
Enterprise Manager Cloud Control possde de nombreuses fonctionnalits. Il nest pas possible de
toutes les numrer ici mais en voici une liste rsume :
Fonctionnalits d'administration centralise des bases de donnes pour la gestion des
bases de donnes Oracle locales et distantes.
Simplification des tches du DBA grce une interface graphique intuitive.
Excution de tches sans saisie manuelle de la syntaxe SQL, PL/SQL ou RMAN.
Gestion des instances et des sessions de base de donnes Oracle.
Gestion des objets de schma, comme les index, les tables, les partitions, les vues et les
procdures stockes.
Gestion des utilisateurs de base de donnes et de leurs privilges, profils et rles.
Gestion des exigences de la base de donnes en matire d'espace physique et d'espace
logique, notamment la gestion des fichiers de contrle, des espaces disque logiques et des
fichiers de journalisation.
Entre et extraction de donnes dans les bases de donnes l'aide des assistants de
gestion des donnes.
Impression et enregistrement des informations rcapitulatives relatives la base de
donnes, comme l'ensemble des utilisateurs de base de donnes.
Cration et programmation des travaux de sauvegarde via les assistants de gestion des
sauvegardes (disponibles si connecte Oracle Management Server).
Visualisation des dpendances pour les objets de la base de donnes.
Visualisation et modification des donnes accessibles par l'intermdiaire des tables, des
vues et des synonymes.
Suppression rapide et facile de colonnes de table.
Analyse des objets de base de donnes l'aide d'assistants.
Mise disposition de plusieurs tats prdfinis qui permettent aux DBA de personnaliser,
de programmer et de publier ces tats vrifier ltat de la base.
Page | 28

Mmoire dingnieur

II.4 Etude de faisabilit

A travers cette tude nous allons prouver que le projet est techniquement faisable et
conomiquement viable. Ainsi nous expliciterons dans cette partie les ressources techniques et
humaines ncessaires la ralisation de ce projet.
II.4.1 Etude Rseaux

Les tudes rseaux et matrielles ont t ralises succinctement car le logiciel Oracle Grid Control
10g, qui est une ancienne version dOracle Enterprise Manager, est install et utilis sur nos
systmes depuis plus de cinq ans. Les lments internes dOEM 12c tant semblables ceux de la
version 10g, il na pas t ncessaire de faire des tudes rseaux et matriels approfondies pour
implmenter la solution Cloud Control. Nous allons nanmoins exposer ici les prrequis rseaux
respecter pour implmenter une solution OEM quel que soit la version du produit dploye.
Pour calculer et donc connaitre le nombre denvironnements Cloud Control installer en fonction
de lloignement gographique des cibles supervises il faut connaitre les prrequis rseaux
ncessaires pour la communication entre les composants dOEM 12c ainsi que la performance
rseaux des serveurs hbergeant ces lments. (Voir tableau n1)
La gestion des erreurs rseaux de Cloud Control est robuste. Elle permet entre autres de tolrer
des bugs et des interruptions rseaux entre les diffrents composants dOEM. Toutefois, les
problmes rseaux entre un agent et OMS ou entre la console et OMS nont que trs peu dimpact
sur les performances globales de CC compar ceux pouvant affects les communications entre
OMS et OMR. La connexion dun agent ou dune console OMS peut tre interrompue sans
impacter les fonctions du systme Cloud Control. Nanmoins, un problme rseaux entre un OMS
actif et OMR peut rduire les performances globales du systme de supervision. La connexion de
la console, le systme de notification automatique, lexcution des tches et presque toutes les
autres fonctions de CC peuvent tre impacts.
En rgle gnrale, la performance rseaux minimale requise entre les htes OMS et OMR dicte le
choix dimplantation gographique de ces deux composants car les performances rseaux de
communication entre les agents et le serveur OMS passent au second plan. Il nexiste pas de
limitations spcifiques propres lapplication OEM car celle-ci a t conue pour administrer
plusieurs centaines de milliers de cibles par plus dune centaine dadministrateurs.
Le tableau 1 met en vidence la bande passante rseau minimale ainsi que la latence maximale
respecter entre un OMS actif, la base Repository et les agents OMA. Les prrequis ncessaires de
connexion rseaux entre OMR et ses disques de stockages sont en gnral pris en compte lorsque
lhte OMR nest pas physiquement coupl avec ses propres quipements de stockage. Les
serveurs-htes situs dans le Cloud ( Cloud hosting ou Cloud storage ) reprsentent un
exemple concret de cette ralit.

Page | 29

Mmoire dingnieur

Tableau 1: Prrequis rseaux minimum ncessaires de connexion
Connexion entre les lments Bande Passante Latence

de Cloud Control Minimale Requise Maximale autorise

Console Client <-> OMS 300 Kbps 300 ms
OMA <-> OMS 300 Kbps 300 ms
OMS <-> OMR 1 Gbps 30 ms
OMR <-> Stockage OMR 1 Gbps 10 ms

Remarque : Il semble important de souligner que les prrequis de connexion rseaux explicits ici
se basent sur le postulat que le rseau est entirement ddi au trafic de Cloud Control.
Ce mme tableau montre quel point la bande passante minimal et la latence maximale
demande sont bien plus exigeantes que celles requise entre les htes OMA et OMS. Il sagit ici
dun diffrentiel de 10x pour la latence et de plus de 3000x pour la bande passante. Il est essentiel
de connaitre les ordres de grandeur des prrequis rseaux entre les diffrents composant dOEM
et de les comparer avec les performances rseaux de lentreprise pour pouvoir allouer
lquipement adquat au bon fonctionnement de Cloud Control. En raison des fortes exigences de
connexion entre OMS et les tiers OMR, la plupart des sites runissent au sein de leur(s) centre(s)
de donnes (Datacenters) au moins un serveur-hte ddi OMS celui ddi OMR. Essilor
possde un quipement rseau Gigabit Ethernet (GigE) ou suprieur. Nous sommes donc capables
de rpondre au prrequis de 1Gbps minimum demand en bande passante entre les serveurs
OMS et OMR.
II.4.2 Ressources alloues

Notre mission a ncessit de mettre en place un certain nombre de ressources matriels, logiciels
et humaines. Voici le dtail des ressources utilises durant le projet.
II.4.2.1 Ressources matrielles et logicielles

Mise disposition dun serveur Linux x64
Cration dun File system de 100 Go sur le disque dur allou au serveur
Cration dun compte systme utilisateur standard sur le serveur
Xming. Logiciel destin lancer les excutables DBCA (Database Configuration Assistant)
pour la cration de la base Repository et OUI (Oracle Universal Installer) pour lancer
linstallation de Cloud Control
Putty. Logiciel de prise de contrle distance pour se connecter sur le serveur destin
hberger Oracle Enterprise Manager 12c.
Page | 30

Mmoire dingnieur

II.4.2.2 Ressources humaines : les acteurs

Expert Administrateur base de donnes Oracle : Il a jou le rle de superviseur pendant
toutes les phases du projet. Ses conseils et ses avertissements ont permis notre quipe
de rsoudre certains points bloquants notamment sur la phase de configuration de Cloud
Control.
Un administrateur base de donnes snior : Il ma donn les rfrences dont javais besoin
durant la phase de recherche des nouvelles fonctionnalits.
Moi-mme, apprenti administrateur base de donnes
II.4.3 Les risques et les impacts

Le remplacement de la version dOracle Enterprise Manager 10g par la version 12c entraine un
certain nombre de risques au niveau de la supervision des bases de production dont nous avons la
charge. Voici les tapes auxquelles il a fallu tre particulirement vigilant au niveau des risques
encourus :
1. Le rapatriement de nos bases de donnes sur la nouvelle version dOEM
a. Dsinstallation des anciens agents OEM 10g
b. Installation des nouveaux agents compatibles OEM 12c
2. La configuration des seuils dalertes des mtriques des bases de donnes
3. La configuration des notifications des incidents
II.4.3.1 Les risques associs

1. La perte des informations de supervision. Lenjeu principal de cette tape a consist
maintenir la supervision continue de nos bases de donnes de production pendant la
priode de transition entre OEM 10g - OEM 12c.
Afin de se prmunir contre toute discontinuit de la surveillance de ces bases stratgiques,
nous avons, dans un premier temps, test nos procdures de dploiement des agents sur
des serveurs qui hbergeaient des bases de donnes non-stratgiques pour lentreprise.
Nous avons galement profit de ces premiers dploiements pour tester nos procdures
de configuration des seuils dalertes et des mthodes de notification. Ces tapes ayant t
raliss sans difficult, notre quipe a opt pour :

Ladoption immdiate et globale de Cloud Control pour nos bases de donnes non-
stratgiques.
Une transition lente et progressive de nos bases de donnes de production.

Nous avons donc gard lenvironnement OEM 10g pour nous prmunir contre dventuels
bugs critiques de la nouvelle version 12c dploye. En effet nous aurions pu tout moment
dcider de revenir lancienne version du logiciel si de telles erreurs taient survenues sur
Cloud Control.

Page | 31

Mmoire dingnieur

2. La survenance dincidents sur les bases de donnes. Lorsque les seuils dalertes sont mals
configurs, certains problmes peuvent ne pas tre dtects temps et le niveau de
performance de nos applications et de nos bases de donnes en subit les consquences.
Cela peut nous mener devoir arrter une base de donnes pour la rparer (Downtime).
Inversement, des seuils trop sensibles peuvent amener ce que des alarmes soient
dclenches cause de simples oprations de routine de nos systmes. Dans de tels
scnarios, les alarmes gnrent des alertes sans quaucun mal nait t fait au systme.

Non-dtection dalertes et dincidents. Si la mthode de notification des alertes et incidents est
mal configure, les administrateurs ne sont pas notifis de lapparition de problmes au sein de
leurs bases de donnes. Par consquent, si des alertes sont gnres, celles-ci ne seront pas
traites temps et des incidents critiques peuvent survenir. De la mme faon, si des incidents ne
sont pas dtects, les performances globales des bases de donnes et des applications sont
directement impactes et celles-ci peuvent cesser de fonctionner.
II.4.3.2 Les impacts associs

Le dploiement de Cloud Control nous a contraint mettre en uvre de nouvelles procdures.

Procdure dinstallation de la base Repository
Procdure dinstallation dOEM 12c
Procdure de dploiement des agents et dajout des bases de donnes dans OEM 12c
Procdure de configuration de la mthode de notification par mail
Procdure de configuration des seuils dalertes de bases de donnes
Procdure de cration de rgles dincidents

Toutes ces procdures ont d tre ralises en amont de la phase de dploiement grce la
documentation que lditeur Oracle met en libre-service sur son site internet. Celles-ci ont t
testes et valides par lexpert administrateur base de donnes Oracle de notre quipe et moi-
mme.
Cloud Control a fait lobjet dune tude approfondie et dun travail duniformisation des diverses
configurations existantes des bases de donnes.
Ces procdures sont par la suite communiques aux quipes DBA de Thalande et permettent de
transmettre des nouvelles mthodes et de nouveaux savoir-faire.

La clarification de lexpression du besoin, la rdaction du cahier des charges et de ltude de
faisabilit nous a permis de mieux apprhender les enjeux de la mission. Nous pouvons
maintenant analyser larchitecture dOEM 12c pour comprendre le fonctionnement interne du
logiciel.
Page | 32

Mmoire dingnieur

III La solution Oracle Enterprise Manager Cloud

Control 12c

Dans cette partie, nous analyserons tout dabord larchitecture de Cloud Control et les diffrents
choix de dploiement qui nous sont proposs. Nous serons ainsi capables de choisir larchitecture
logicielle dOEM la plus mme de rpondre aux besoins lis la maintenance de nos
environnements informatiques. Pour ce faire, nous dvelopperons les parties suivantes :
Analyse de larchitecture dOEM
Les choix architecturaux de Cloud Control
III.1 Analyse de larchitecture dOEM

Nous allons examiner dans un premier temps quels sont les composants communs aux diffrentes
versions de loutil de supervision sorties ce jour. La structure classique de Cloud Control se
dcompose en quatre composants principaux qui sont :
1. La console Cloud Control
2. Lagent dOracle Management (OMA)
3. Le service Oracle Management (OMS)
4. La base Repository (OMR)

Chaque composant peut tre spar par un firewall.
Figure 4: Architecture dOracle Enterprise Management Cloud Control 12c
Page | 33

Mmoire dingnieur

III.1.1 Cloud Control Console

La console Cloud Control est une application base sur un navigateur web au travers de laquelle
nous pouvons superviser de faon centralise les environnements informatiques. La page daccueil
donne une vue densemble de linfrastructure technique supervise dans laquelle nous accdons
une cible bien prcise administre par le logiciel. La console CC est certifie pour fonctionner avec
les navigateurs internet les plus connus comme Internet Explorer, Firefox, Safari, Google Chrome
mais aussi avec le plug-in Adobe Flash Player pour certaines autres fonctionnalits de la console.
La console na pas besoin dtre installe par nos soins, cest le service OMS qui se charge
dafficher cette interface. Il suffit douvrir un navigateur internet et de se connecter la console
via lURL didentification dEntreprise Manager.
La console dOEM nous permet donc de nous connecter quasiment partout via son navigateur
internet. Linterface de la console tant code en HTML, celle-ci utilise par dfaut le protocole
HTTPS (ou HTTP si laccs est non-scurise) qui la rend donc fluide, facile daccs et facilement
configurable pour dventuels pare-feux.
La manire la plus courante de nous identifier la console se fait par lintermdiaire de la barre
dadresse du navigateur en utilisant le format suivant : <nom-serveur-hte> :<port>/em.
Linstallation de Cloud Control restreint les accs du navigateur pour scuriser les communications
(SSL), cependant aprs linstallation, celle-ci vous permet dtablir des accs HTTP avec une
configuration minimale.
Dans GC v10g, nous pouvions nous identifier directement via le serveur HTTP Oracle (OHS) ou
indirectement via OracleAS Web Cache qui vous relayait ensuite OHS. En revanche, dans les
versions OEM 11g et CC 12c, vous ne pouvons le faire qu travers le serveur Apache WLS (WLS
Apache Web Server) avec le protocole HTTPS et le port par dfaut 7799. Il ny a pas daccs par le
cache Web aux consoles GC 11g et CC 12c.
Dans la version 10g dOEM, presque toutes les fonctionnalits de la console Java dOEM v9i
avaient t reprises et redveloppes en code HTML. Pour excuter les anciennes fonctionnalits
des versions 9i propres aux clients lourds Java qui ntaient pas encore disponibles dans la console
de GC 10g comme la gestion avance de la rplication Oracle, nous devions tlcharger le logiciel
client Oracle 10g et installer les composants de la console Java dOracle GC 10g. La console Java
dOEM fonctionne de faon autonome, elle ne se connecte pas au service OMS. Dans GC 11g, il ny
a plus besoin dinstaller une console Java en mode client lourd. Dans les versions GC 11g et CC 12c,
toutes les fonctionnalits sont accessibles via leur console.
Page | 34

Mmoire dingnieur

III.1.2 Oracle Management Agent

Lagent de supervision install sur chaque serveur-hte supervis surveille ce dernier ainsi que
toutes les cibles quil hberge. Celui-ci communique galement toutes les informations relatives
aux composants cibls au service OMS provenant des produits Oracle ou de socits extrieures.
Cloud Control peut superviser plus de 200 types de cibles diffrentes. Chaque instance dun type
de cible particulier prsent sur le serveur-hte compte comme une cible supervise. Les types de
cible les plus rpandues sont par exemple les instances de bases de donnes, les Listeners (ou
Auditeur), le serveur Oracle Application et le serveur-hte hbergeant ces mmes cibles.
Les plug-ins dOEM permettent quant eux de contrler de faon spcifique des cibles Oracle et
non-Oracle. Dans les versions Grid Control v10g et v11g, certains types de cibles couples avec le
produit sont maintenant packags comme de simples plug-ins dans CC 12c. Cela permet aux
quipes de dveloppement Oracle de mettre jour les plug-ins indpendamment des versions du
produit lui-mme. En effet, les plug-ins tant la fois dvelopps par la socit Oracle et par des
socits partenaires, ceux-ci sont non seulement utiliss dans les produits Oracle mais galement
dans beaucoup dautres produits non-Oracle. Par exemple, les produits Microsoft SQL Server,
Microsoft Active Directory, IBM WebSphere Application Server ainsi que dautres produits les
utilisent.
Le logiciel Cloud Control se monitor galement lui-mme par consquent un agent OMA doit aussi
fonctionner sur tous les nuds hbergeant les services OMS et OMR. Sur chaque hte surveill,
virtuel et non virtuel, seul un seul agent doit tre oprationnel.
Oracle certifie son agent pour les versions actuelles 12c (v12.1.0.2) sur les serveurs-htes
dinfrastructure 32-bit 64-bit en passant par les systmes Linux x86-64 et x86, Oracle Solaris avec
SPARC (64-bits), Oracle Solaris 64-bit, IBM Linux sur systme Windows (x64 et x86) et HP-UX
(Itanium, PA-RISC).
OMS fait partie du Framework dOracle Enterprise Manager, lagent est cod dans le langage de
programmation C pour des raisons de performance et de ressource. Les bibliothques de
programmation du cur Oracle sont utilises par un processus paralllis (multithread) et ce sont
Oracle Call Interface (OCI) et Oracle Secure Socket Layer (SSL) qui se chargent de le scuriser par
dfaut. Pour comprendre de faon plus prcise le fonctionnement de lagent nous allons expliciter
les tapes de dcouverte des cibles des agents lintrieur des serveur-htes sur lesquelles ils
sont hbergs.
Page | 35

Mmoire dingnieur

III.1.3 Gestion et dcouverte des cibles supervises

Dans cette partie nous allons nous intresser aux agents de supervision dOEM. Les agents font
partie intgrante dOEM. Nous expliquerons leur fonctionnent et le rle quils jouent au sein
dOEM.
Il ne peut y avoir quun seul agent oprationnel au sein dun serveur-hte supervis. Un agent
OMS qui a t correctement install commence par se surveiller lui-mme puis vrifie ltat de son
hte, du service OMS si celui-ci est prsent et des autres produits Oracle prsents sur la machine
(Listeners, Bases de donnes etc.). Il est noter que lagent lui-mme et son hte sont traits par
Cloud Control comme des cibles part entire. La dcouverte automatique des cibles commence
ds que lagent est install et dmarr. Les cibles qui nont pas t dcouvertes par lagent
peuvent tre mises en lumire par la console OEM. Cette dernire mthode permet galement de
dcouvrir de nouvelles cibles de faon manuelle ou automatique.
Les cibles peuvent se dcomposer en plusieurs types de catgories comme nous lavons expliqu
prcdemment, cependant, un certain nombre de plug-ins de GC 11g nont pas encore t mis
jour pour CC 12c mais il est trs probable quils soient pris en charge dans un futur proche.
Lagent utilise un niveau de supervision par dfaut pour la rcolte des donnes des cibles
surveilles. Ces donnes sont transmises au systme de supervision. OMA envoie immdiatement
les mtriques dalertes et mettent de faon priodique des informations de supervision au
service OMS. Lagent effectue des tches pour le compte de OMS qui peuvent tre de diffrentes
natures :
Des tches mtiers appels jobs . Ce sont des units de travail crs pour automatiser
des tches administrateurs comme lapplication de patchs ou limplmentation de
sauvegardes rgulires.
Des tches de coupure qui arrtent la rcolte de donnes sur les cibles superviss pour
effectus des maintenances planifies. Ces coupures permettent dobtenir une image plus
juste et plus prcise des performances de la cible supervise car celle-ci permet non
seulement de librer des ressources supplmentaires pour le serveur mais elle autorise
galement larrt planifi du service OMS. De ce fait, le contrat de niveau de service
(Service Level Agreement) de la cible ne sen retrouve pas affect.
Page | 36

Mmoire dingnieur

III.1.4 Oracle Management Service

Dans la version 10g, le service OMS est une application de niveau intermdiaire base sur la
plateforme Java 2 Entreprise Edition (J2EE) qui gnre linterface utilisateur, cest--dire la console
GC. Les agents transmettent les donnes relatives aux cibles supervises au service OMS. Celui-ci
traite les donnes entrantes avant de les envoyer son tour la base de donnes dpt, plus
communment appele Repository (OMR). La couche intermdiaire de Cloud Control est
compose dune instance dOracle WebLogic Server v10.3.5 qui se charge de dployer lapplication
Web J2EE.
Nous devons installer OMS sur un ou plusieurs serveur-htes afin de pouvoir garantir pour notre
environnement informatique supervis, des niveaux de disponibilit et de flexibilit acceptables.
Chaque service de supervision doit tre oprationnel sur le serveur-hte quil hberge. OMS et
OMR peuvent se situer sur le mme hte mais, pour des raisons de performance, Oracle ne
recommande pas cette configuration pour un environnement de production de plus de mille
cibles. Tous les htes physiques dOMS changent de faon indpendante avec le service Oracle
Management Service. En revanche, plusieurs htes dOMS ayant un rpertoire partag peuvent se
coordonner pour traiter la transmission des fichiers de chaque agent dans ce mme rpertoire.
Le service de supervision dOracle est dploy avec WLS v11gR1 (10.3 .5). Comme nous lavons
dj expliqu, linstallation dOMS est couple avec linstallateur de CC 12c. LorsquOUI crer un
nouveau systme de supervision, une instance de WLS est installe dans le sous-rpertoire
wlserver_10.3 du rpertoire ddi la couche intermdiaire de lapplication. (Par exemple :
/u01/app/Middleware). OMS est dploy dans un nouveau domaine appel GCDomain dans
linstance WLS et nutilise aucun domaine dj existant de larchitecture en place. Pour
comprendre de faon prcise larchitecture dun serveur OMS il faut dabord comprendre le rle
que joue chacun des lments qui la compose. WLS 10.3.5 (qui contient le serveur HTTP Oracle) et
lapplication J2EE dOMS qui font partie du domaine de WLS Fusion runissent eux seuls ce que
nous appelons communment OMS .
Tous les composants de ce service sont installs sur le mme serveur indpendamment de la
mthode dinstallation de Cloud Control utilise (via OUI ou installation silencieuse). On peut
dployer nanmoins plusieurs OMS sur des serveurs-htes diffrents. En revanche, sur chacun de
ces serveurs doivent tre prsents tous les composants dOMS et doivent obligatoirement faire
rfrence la mme base Repository pour un environnement Cloud Control donn. Chacun de ces
services communiquent avec la base de dpt via JDBC qui sert dinterface standard Java pour les
connexions entre Java et les bases de donnes relationnelles.
Page | 37

Mmoire dingnieur

III.1.5 Oracle Management Repository

Nous expliquerons ici le rle et le fonctionnement de la base Repository au sein de larchitecture
OEM. Celle-ci joue un rle central et ncessite dtre tudie pour comprendre ses possibilits de
dploiement et de configuration.
La base de donnes dpt agit comme un entrept de donnes pour Cloud Control. Celle-ci peut
tre prinstalle manuellement ou par le modle EM dans lassistant de configuration de base de
donnes DBCA. Le Repository est cre par dfaut par le schma utilisateur SYSMAN, celui-ci
contient les informations sur toutes les cibles de Cloud Control, schmas administrateurs compris.
La base de donnes dpt organise toutes ces donnes de faon ce quOMS puisse accder mais
aussi afficher ces informations dans la console dadministration. Cloud Control nutilise quune
seule base centrale Repository. Celle-ci peut tre une base de donnes simple ou issue dun
ensemble RAC et doit tre en version 10gR2 (10.2.0.5), en 11gR1 (11.1.0.7.0) ou en 11gR2
(11.2.0.1+) quOracle prconise.
Les consoles administrateur et agent communiquent avec OMS de faon directe ou par
lintermdiaire de scripts (en dehors des alertes). Ils utilisent les protocoles rseaux respectifs :
Nous pouvons mettre des requtes dans la console travers le protocole HTTP(S) dans
notre session de navigateur internet, celles-ci seront traites par OMS. Le serveur va
rcuprer les donnes demandes par ces requtes dans la base dpt et les afficher
directement dans la console.
Les agents envoient les informations au serveur OMS via le protocole HTTP(S) et les
transmet son tour OMR via JDBC (Java DataBase Connectivity). La base Repository
retourne ces donnes OMS via le mme protocole et les relaient lagent OMA via un
protocole dcoute HTTP.
Toutes les consoles administrateurs ont accs aux informations prsentes dans la base de donnes
dpt pour un niveau de droit daccs donn. Les informations dont dispose la base Repository
sont :
Les dtails de configurations des cibles supervises.
Les informations de disponibilit des cibles surveilles.
Lhistorique des mtriques et des informations relatives aux alertes.
Les donnes concernant les temps de rponse des cibles.
Les informations dinventaire des patchs et des produits installs.

Page | 38

Mmoire dingnieur

Toutes ces informations vont nous permettre :
De superviser lensemble de nos environnements (Bases de donnes, serveurs
dapplication, serveur-htes etc.), les applications modlises et les tches automatises.
Danalyser les donnes de statuts et de performances.
De mettre en place des niveaux de service applicatif (ASLM pour Application Service Level
Management).
De pister et deffectuer des changements de configuration.
Et de mener bien beaucoup dautres tches pour superviser des systmes dinformation
complexes fonctionnant de pair avec des technologies Oracle et non-Oracle.
Nous allons maintenant examiner le schma utilisateur de OMR ainsi que le schma propritaire,
les tablespaces (segments logiques de bases de donnes) et des objets qui font partie de ces
schmas. Lutilisateur SYSMAN correspond la fois au schma propritaire et au compte par
dfaut du Super Administrateur. On ne peut supprimer ou renommer ce compte, celui-ci est utilis
pour :
Effectuer la configuration de Cloud Control comme par exemple la cration de privilges,
de rles, de comptes administrateurs ou de rgles de notifications.
La dcouverte de nouvelles cibles
La cration de tches gnriques pouvant tre excutes sur tout hte ou base de
donnes.
Page | 39

Mmoire dingnieur

III.1.6 Flux de donnes

Afin de mieux comprendre le modle darchitecture de CC, nous allons maintenant nous intresser
la faon dont les composants interagissent. Le diagramme ci-dessous montre les diffrentes
interactions qui soprent au sein de loutil.
Figure 5: Flux de donnes

Nous allons procder tape par tape en suivant le flux de donnes :
1) La console OEM et les agents peuvent utiliser trois types de communications diffrents
a) Nous nous identifions dans la console en se connectant ladresse
http[s]://<serveurhteOMS>/<port>/em via le serveur HTTP Oracle (OHS) du WLS. LURL
didentification dpend de la scurit de la connexion utilise par ladministrateur.
Connexion scurise : https://<serveurhteOMS>:7799/em
Connexion non-scurise : http://<serveurhteOMS>:7788/em
Page | 40

Mmoire dingnieur

b) Lagent envoie les mtriques quil rcolte et les alertes quil dtecte lURL du serveur
HTTP Oracle du serveur WebLogic. OMA envoie galement priodiquement des messages
test appels Agent ping son service OMS lui faisant tat de sa disponibilit. LURL par
dfaut des deux types de communication se font via une connexion scurise ou non-
scurise dfinie dans la proprit REPOSITORY_URL du fichier de configuration
emd.properties .
Connexion scurise : https://<serveurhteOMS>:1159/empbs/upload
Connexion non-scurise : http://<serveurhteOMS>:4889/empbs/upload
c) Lagent contourne le service OMS en se connectant directement la base Repository pour
lui rapporter tout changement des mtadonnes des cibles supervises et toutes alertes
critiques.
2) Ladministrateur tablit sa demande dans la console ou lagent met la demande OMS pour
la transmettre via le protocole HTTP ou HTTPS lapplication OMS
3) Le service de supervision dOracle envoie la requte mise de la console ou de lagent la base
de donnes dpt via JDBC. Ds rception, OMS affiche le rsultat de la requte dans la console
administrateur.
4) OMS communique avec OMA de plusieurs faons :
a) OMS transmet directement les donnes lagent via HTTP(S) lagent intgr au Listener
HTTP. Celui-ci coute lURL de lagent ladresse : http(s)://<OMAhost>:3872/emd/main
(https par dfaut), dfini par la proprit EMD_URL localise dans le fichier de
configuration de lagent emd.properties . OMS soumet galement des tches de
diffrentes natures travers cet URL.
b) Si la communication OMS-Agent choue, le service OMS va vrifier le statut du serveur-
hte sur lequel lagent rside en lui envoyant des pings via des requtes chos (Echo
Requests) passant par le protocole Internet Control Message Protocol (ICMP).
c) OMS envoie toute les requtes SQL*NET aux ports TCP des Listeners des bases de donnes
supervises sur les serveurs-htes o les agents sont installs. (Ex : Application de patch
sur une base de donnes)
Toutes ces informations peuvent tre utiles pour identifier les sources possibles dun problme
donn.
A travers ltude dtaille de larchitecture dOEM, nous avons pu comprendre le fonctionnement
interne de ses diffrents composants qui sont lorigine de flux de donnes complexes. Cette
analyse va maintenant nous permettre de comprendre les diffrents choix darchitecture que nous
pouvons adopter pendant la phase de dploiement du logiciel.
Page | 41

Mmoire dingnieur

III.2 Les choix dimplmentation dOEM Cloud Control 12c

Avant dinstaller Cloud Control, nous devons prendre des dcisions cls concernant le choix
darchitecture adopt par OEM 12c. De cette faon, nous nous assurons que le systme sur lequel
nous oprerons rpondra aux prrequis ncessaires la supervision de linfrastructure
informatique dEssilor. Nos dcisions doivent prendre en compte des critres importants tels que
le niveau de disponibilit ncessaire lenvironnement Cloud Control ainsi que le plan de
rcupration adopter aprs dsastre. Ces types de questions doivent peser sur le choix
architectural de CC que nous implmenterons.
Afin de fournir un haut niveau de disponibilit (High Availability ou HA) et de reprise aprs sinistre
(Disaster Recovery ou DR), nous avons besoin de faire appel aux services dOracle et/ou dautres
technologies dont Oracle Real Application Clusters (RAC), Oracle Automatic Storage Management
(ASM), Storage Array Networks (SAN) et Network Attached Storage (NAS), des solutions externes
de rcupration du cluster froid (Cold Failover Cluster ou CFC), Oracle Data Guard, Oracle
Recovery Manager (RMAN), Oracle Flashback, des pare-feux, des serveurs proxys et des serveurs
de rpartition de charges (Server Load Balancing ou SLB).
Nous navons pas besoin dintgrer ces technologies HA et DR lorsque lon installe pour la
premire fois Oracle Cloud Control mais il peut savrer plus facile de le faire en premier si certains
prrequis de loutil le demande. Il a fallu que nous prenions en compte des dcisions prliminaires
concernant larchitecture adopter pour permettre ces technologies dtre implmentes dans
le futur.
Cette solution temporaire a pour but de donner le temps ncessaire notre quipe DBA pour la
mise en place dune architecture Cloud Control HA/DR plus conforme. Une analyse cot/bnfice
doit tre effectue et prise en compte pour valuer les conomies de main-duvre ralises via
la construction dune architecture complte dun systme CC 12c vis--vis des cots de
reconfiguration des lments de Cloud Control effectue aprs mise en place de loutil. Cette
analyse a donc pour objectif darriver une architecture finale de la faon la plus efficiente.
Page | 42

Mmoire dingnieur

Aux bnfices fournis par limplmentation de CC sajoutent encore dautres avantages que lon
peut tirer pour la reconfiguration des solutions HA/DR :
Nous pouvons compter sur les fonctionnalits propres Cloud Control pour amliorer les
solutions de hautes disponibilits et de rcupration aprs sinistre qui ont t dployes.
Par exemple, OEM 12c peut aider construire ou convertir la base Repository pour
Oracle Real Application Cluster qui bnficie de meilleurs standards de disponibilits. Cet
outil peut galement crer dans un premier temps une base de donnes temporaire
pouvant hberger les donnes de la base de dpt et la placer dans un second temps dans
une configuration Data Guard en tant que base primaire.
Cloud Control peut tre utilis pour dfinir et pister un Contrat de Niveau de Service (Service Level
Agreement ou SLA) et de mesurer la disponibilit et la performance de loutil vis--vis de ce mme
SLA. A partir de cette donne, nous pourrions convenir quant la ncessit dimplmenter des
instances OMS supplmentaires ou de convertir la base Repository en RAC pour satisfaire le SLA
mis en place.
Il est possible de mettre en place un systme Cloud control supervisant un environnement
de production et de le reconfigurer pour quil supervise un autre type denvironnement.
Cela se fait par la suppression des cibles de production et par la dcouverte et lajout de
nouvelles cibles.
Que lon dcide de mettre en place un environnement Cloud Control basique en laissant de ct
les lments de configurations avance ou dinstaller un environnement CC avec les technologies
HA et DR, nous devons prendre deux dcisions cls concernant larchitecture dOEM 12c avant de
linstaller. Pour cela nous nous sommes poss les questions suivantes :
Combien denvironnements Cloud Control devons-nous mettre en place ?
Quel est le type dinstallation dont nous avons besoin ?
Page | 43

Mmoire dingnieur

III.2.1 Dfinition du nombre denvironnements Cloud Control mis en uvre

Un environnement Cloud Control se dfinit par un systme compos dun ou plusieurs couples de
serveurs-htes OMS et OMR associ(s) des agents OMA sur les serveurs-cibles superviss. Les
environnements CC fonctionnement de manire indpendante. Ils ne communiquent pas entre
eux et on ne peut pas les lier entre eux ou les srialiser. La dcision de la mise en place de
plusieurs environnements de supervision OEM est dicte par plusieurs choix :
Nous pouvons faire le choix dutiliser deux environnements CC. Nous pouvons choisir par
exemple de sparer la supervision de notre environnement de production de nos autres
environnements moins stratgiques.
Les limitations du rseau dentreprise peuvent exiger linstauration de plusieurs systmes
OEM.
III.2.2 Environnement de production Vs Environnement de non-production

Llment dcisif qui va dterminer le nombre denvironnements Cloud Control que nous
utiliserons dpend du choix que nous aurons fait pour superviser nos environnements de
production et de non-production. En effet si nous dcidons de sparer leur supervision, le nombre
denvironnements va augmenter. Nous sommes donc confronts deux choix de stratgie :
Installer deux environnements Cloud Control, un pour les cibles de production et lautre
pour ceux de non-production et de gestion de linstance de CC (Mises jour, correctifs,
etc.) pour tester les changements dinfrastructure dOEM et de les appliquer sur linstance
ddie la production.
Installer un seul environnement Cloud Control pour les univers de production et de non-
production.
Il semble important de souligner que les entreprises utilisent souvent plusieurs instances dOEM
pour superviser des environnements de non-production galement. Une pour le dveloppement,
une pour lintgration etc. Toutefois, un environnement de supervision est dans la plupart des cas
suffisant pour tester tout changement dinfrastructure de CC.
La meilleure pratique (Best Practice) reconnue est dutiliser un systme Cloud Control ddi pour
superviser des cibles de production. Cette mthode empche toutes cibles de non-production
dimpacter sur le Framework Cloud Control de production.
Si nous faisons le choix de sparer la supervision de nos environnements de production et de non-
production, lusage est dimplmenter dabord la solution OEM 12c pour les environnements de
non-production. Nous devrions alors assigner un ou plusieurs serveurs pour dmarrer les
installations. Ds lors, nous devrions avoir dcid si ces serveurs-htes seront attribus un
environnement CC de production ou de non-production.
Nous allons maintenant dvelopper deux sections o nous dterminerons dans un premier temps
le nombre de serveurs OMS et de serveurs hbergeant OMR ncessaires. Nous nous intresserons
dans un second temps la question de la runion de ces deux composants sur le mme serveur.
Page | 44

Mmoire dingnieur

III.2.3 Dcision du choix darchitecture dOracle Cloud Control
Les choix architecturaux de Cloud Control auxquels nous sommes confronts doivent rpondre
aux questions essentielles concernant les diverses implmentations possibles dOEM.
Quelle architecture de base de donnes devons-nous utiliser pour la base Repository ?
Quelle architecture OMS devons-nous dployer ?
Avons-nous besoin que la base OMR et OMS soient sur le mme nud lorsque ces deux
lments sont physiquement au mme endroit ?
Tableau 2: Ordre de grandeur des sites superviss

Le tableau ci-dessus rpond de faon rsume aux trois questions prcdentes en listant les
configurations recommandes par Oracle. Celles-ci sont donnes en fonction de la taille du site de
production que lon veut superviser. Cet ordre de grandeur est dfini par trois variables qui sont le
nombre de cibles, dagents et de sessions concurrentes actives. Pour chaque taille de site, le
tableau liste le nombre de serveurs OMS et OMR actifs * ainsi que le nombre total de serveurs
requis pour une taille de site donne. Ce nombre minimum de serveurs prend dj en compte la
solution o OMS et OMR sont sur le mme serveur.
Remarque : Si nous avions besoin dune haute disponibilit pour nos bases tierces OMR, nous en
aurions galement besoin pour les instances OMS (actives ou passives). En effet, OMR et OMS
doivent fonctionner pour permettre Cloud Control de rester oprationnel. Toutes les
configurations listes ci-dessous prennent en considration ces lments de HA.
Page | 45

Mmoire dingnieur

III.2.4 Dcision concernant sur le choix darchitecture de la base de donnes

Repository
Nous pouvons installer OMR partir de nimporte quelle version certifie de base de donnes
pour Repository sur une plateforme donne. Nanmoins, Oracle nous recommande dutiliser la
version la plus rcente de la v11gR2. Larchitecture de la base OMR adopter dpend des critres
de haute disponibilit qui sont en vigueur chez Essilor et de la taille de notre environnement
superviser. Il existe deux choix darchitecture CC disponible : une qui ne dispose que dune seule
base Repository et une autre qui en dispose de plusieurs. Si nous avons besoin dune haute
disponibilit pour notre base ou si nous devons superviser un environnement informatique
comprenant plus de 1000 cibles, Oracle nous recommanderait alors dutiliser plusieurs instances
de bases de dpt. Cependant, nous ne nous situons pas dans ce cas, par consquent une seule
base Repository suffit. Nous avons donc le choix entre deux types de base de donnes uniques :
Standalone Database : Une seule instance de base de donnes peut tre utilise. Celle-ci
dispose de fichiers stocks sur le serveur.
Oracle Restart database : Il sagit dune fonctionnalit des bases de donnes en version
11g. Celle-ci est utilise sur des serveurs qui ne sont pas mis en grappe. Oracle Restart
redmarre automatiquement les lments de la base de donnes (instance, service,
listener et instance ASM) aprs un chec dun matriel ou dun logiciel ou alors en cas de
redmarrage intempestif du serveur-hte.
Toutefois, bien que cette fonctionnalit puisse savrer utile, celle-ci nest pas considre
comme une solution de haute disponibilit car il nexiste pas de seconde instance de
Repository pouvant prendre le relais en cas de panne critique. Par consquent, une base
de donnes Oracle Restart doit tre considre comme une simple base de donnes
pendant ltape de dimensionnement de Cloud Control et dvaluation des critres HA.

Page | 46

Mmoire dingnieur

III.2.5 Dcision concernant le choix darchitecture dOracle Management

Server
Il existe plusieurs choix dimplmentation pour maintenir un haut niveau de disponibilit sur le
serveur OMS. Ces solutions vont dpendre de nos besoins en termes de haute disponibilit.

Serveur OMS simple : Un seul serveur OMS peut suffire si lenvironnement supervis par OEM 12c
est petit (infrieur 1000 cibles) et sil ne ncessite pas dtre hautement disponible. Ce cas
correspond celui dEssilor.

Multiple Serveurs OMS : Si nous avions besoin dune haute disponibilit pour notre serveur OMS,
Nous devrions dcider du nombre de serveurs OMS implmenter et du mode de configuration
dans lequel ils vont fonctionner. Il peut sagir de configuration Actif/Actif ou Actif/Passif. Nous
devrions galement faire le choix de la localisation de ces serveurs OMS.

Pour maintenir un haut niveau de disponibilit sur de petits sites, deux serveurs OMS sont
requis. Ils peuvent tre configurs en mode Actif/Actif ou Actif/Passif. (Deux serveurs sont
en effet requis pour la HA car un des deux serveurs peut rester passif dans des
environnements relativement petits car la charge des traitements effectus reste grable
pour une seule instance dOMS).

Pour les sites superviss de tailles moyennes ou grandes, deux serveurs OMS en mode
Actif/Actif suffisent. Toutefois, Il existe galement une solution runissant les deux modes
de configurations cits. On peut par exemple utiliser la configuration Actif/Passif sur
chaque OMS dj implments en mode Actif/Actif. Si les serveurs OMS sont
gographiquement loigns lun de lautre, mettre en uvre une solution CFC (Cold
Failover Cluster) pour chaque OMS actif peut sembler redondant voire inutile tant donn
que les serveurs OMS actifs fournissent dj un bon niveau de HA. Cependant, le CFC a
lavantage de fournir une solution locale de HA.

Il existe plusieurs facteurs pouvant justifier limplmentation de plusieurs serveurs OMS. La
flexibilit, la haute disponibilit et les besoins en termes de couverture rseaux
reprsentent tous des raisons valables pour mettre au point une telle configuration. Le
dernier facteur prcdemment voqu est particulirement important car la
communication Agent-OMS ncessite une bande passante dau moins 300 Kbps et une
latence maximale de 300 ms.

Page | 47

Mmoire dingnieur

Nous pourrions installer un serveur OMS actif ou passif lendroit o le dispositif de
rcupration aprs dsastre (Disaster Recovery ou DR) est mis en place. Nous pourrions
configurer une instance OMS de veille depuis le lieu de rcupration prte lemploi en cas
de dsastre. Une instance active permettrait quant elle de lutiliser soit en SLB (Server
Lod-balancer) pour rpartir les charges entre les diffrents serveurs OMS actifs soit en SLB
gographique ayant lavantage de donner plus de flexibilit vis--vis des contraintes
rseaux concernant les communications OMS-Agent.

Lexpert administrateur base de donnes Oracle de notre quipe et moi-mme avons fait le choix
de limplmentation dune instance unique OMS au sein de lenvironnement Cloud Control tant
donn le nombre modeste de cibles superviser au sein de nos systmes de production (<1000
cibles).

III.2.6 Dcision concernant le choix de regroupement du serveur OMS et de la

base OMR
Aprs avoir fait le choix des architectures dOMS et dOMR, nous sommes maintenant confronts
la question de la runion de ces lments sur le mme serveur-hte. Il existe plusieurs solutions
cette question car celles-ci dpendent des choix architecturaux qui ont t pris concernant la
base Repository et OMR :
Installation dOMR et dOMS sur des serveurs htes diffrents : Cest la configuration
adquate pour des environnements Cloud Control de moyenne et de grande taille (>1000
cibles).
Installation dOMR et dOMS sur le mme nud : OMS et OMR peuvent tre installs sur
le mme nud. Celui-ci peut tre rpliqu pour des raisons de haute disponibilit et/ou de
flexibilit.
Installation dOMR et dOMS sur le mme serveur-hte : Cette solution nest approprie
que sur des environnements Cloud Control de petites tailles (<1000cibles) qui ne requiert
pas dune haute disponibilit. Cest la solution la plus adquate pour lenvironnement
informatique dEssilor.
Installation dOMR et dOMS sur de multiples nuds : Installer des instances OMS sur des
nuds de RAC OMR est une solution supporte par OEM 12c et approprie pour des
environnements CC de petites tailles. Toutefois, cette configuration peut prsenter
certains dangers pour des environnements Cloud Control de production de moyennes et
de grandes tailles. En effet, il existe un danger de saturation des ressources disponibles des
nuds pour OMR et OMS pendant les priodes de fortes charges. Cest la raison pour
laquelle les instances OMS doivent tre installes sur des nuds ddis, spars des
nuds de bases de donnes OMR pour des sites OEM de moyennes ou de grandes tailles.

Page | 48

Mmoire dingnieur

Notre quipe DBA a fait le choix de linstallation dOMR et dOMS sur le mme serveur hte tant
donn la petite taille de lenvironnement Cloud Control supervis. Les priodes de fortes charges
tant facilement gres par OEM, nous avons dcid de maintenir ce type de configuration pour
OEM 12c.
III.3 Conclusion
Nous avons pu grce lanalyse des diffrentes architectures disponibles dans Cloud Control de
choisir la configuration de dploiement la plus adapt aux besoins de notre entreprise. Nous avons
finalement opt pour linstallation dOMR et dOMS sur le mme serveur-hte. Deux facteurs
essentiels ont t pris en compte :
La petite taille de nos environnements de supervisions
Labsence de besoin en termes de haute disponibilit
Maintenant que nous avons choisi la mthode de dploiement de Cloud Control, nous pouvons
passs ltape de ralisation du projet.
Page | 49

Mmoire dingnieur

IV Ralisation
Dans les parties prcdentes nous avons dtaill les prrequis lis linstallation des diffrents
composants dOEM 12c et trouv des solutions pour y rpondre. Puis nous avons choisi, travers
une tude approfondie des diffrents choix dimplmentation propos par Cloud Control,
larchitecture OEM la plus adapt nos besoins.
IV.1 Introduction
Nous allons maintenant nous intresser aux processus dinstallation dune base de donnes 11gR2
prconfigure pour hberger la base Repository (base de dpt des donnes OEM) de OEM Cloud
Control. Distinguerons les tapes suivantes :
Partie I : Cette premire partie explicite les tapes ncessaires linstallation dune base
de donnes en mode Repository, celle-ci se dcompose en deux sous-parties :
Effectuer une installation logiciel simple (sofware-only) dune base de donnes 11gR2
et lui appliquer le plus rcent ensemble de patchs disponible (Patch Set Update ou
PSU).
Crer une base de donnes via lassistant de configuration de base de donnes
(Database Configuration Assistant ou DBCA) avec le nouveau modle nomm
DB11.2.0.4 EM seed database qui prconfigure la base Repository avec tous ses
objets.
Partie II : Cette seconde partie dcrit comment terminer la configuration de la base de
donnes pour effectuer des oprations spcifiques une base Repository.
o Configuration des redo logs
o Implmentation du HugePage
o Activations de fonctionnalits avances

Dans ces deux parties, nous allons expliciter toutes les tapes dinstallation dune base de donnes
11gR2 selon les meilleures pratiques de lArchitecture Oracle de Disponibilit Maximum (Oracle
Maximum Availability Architecture ou MAA).
Page | 50

Mmoire dingnieur

IV.1.1 Installation dune base de donnes Repository

Avant de procder linstallation dOEM 12c, nous devons dans un premier temps installer une
base de donnes destine hberger OMR.
Nous allons expliquer les procdures suivre concernant les installations de Grid Infrastructure
(GI), de la base de donnes et de lapplication de leur PSU respectif. Ceux-ci peuvent tre
appliques sur des architectures de base de donnes indpendantes ou en grappe (RAC).
1er tape (facultative) : Installation de GI Oracle home avec son dernier PSU (Si nous avions
recours larchitecture de GI). Nous nutiliserons pas cette solution toutefois nous avons
jug important dinclure les procdures suivre pour mettre en uvre cette mthode.
2me tape : Installation de la base de donnes Oracle 11gR2 avec son dernier PSU. Si nous
utilisions GI, nous devrions appliquer le dernier PSU de GI sur la base de donnes car celui-
ci contient galement la mme version du PSU pour la base de donnes elle-mme.

Il est important de respecter lordre des tapes indiques. Si nous utilisions GI, nous devrions
procder linstallation de la base de donnes et de son PSU seulement aprs avoir install et
patch GI. Patcher le logiciel de base de donnes avant que celle-ci ne soit installe faciliterait le
processus dinstallation car cela permettrait de contourner les tapes de post-installation des
composants. Il sagit ici de la meilleure mthode (Best practice) concernant la cration dune base
de donnes Oracle.
En rgle gnrale, nous procderions linstallation de GI et de son dernier PSU puis refuserions
ltape de cration de la base. Dans un second temps nous appliquerions GI avec son dernier PSU
et ferions de mme pour la base de donnes. Enfin, Nous lancerions DBCA en mode indpendant
(standalone) pour enfin crer la base de donnes.

Remarque : Il est fortement recommand par Oracle dinstaller la dernire version certifie de
base de donnes et du PSU pour laquelle il existe un modle Enterprise Manager dans DBCA pour
profiter des dernires fonctionnalits de la version 11.2, des derniers correctifs de bugs et de
lutilisation dEM template.

Bien que nous ayons opt pour une installation basique de bases de donnes (correspondant
uniquement la deuxime tape cite ci-dessus) pour hberger les donnes dOMR, nous avons
dcid dexplorer les opportunits que pourraient nous apporter larchitecture Grid Infrastructure.
En effet, le seul fait de pouvoir redmarrer automatiquement tous les services dune base de
donnes aprs le redmarrage (prvu ou imprvu) dun serveur reprsenterait une amlioration
non ngligeable concernant la disponibilit de nos bases de donnes. De ce fait, nous allons
brivement nous intresser aux tapes dinstallation de ce logiciel.
Page | 51

Mmoire dingnieur

IV.1.2 Etape 1 : Installation du logiciel Grid Infrastructure (facultative)

La procdure dinstallation de GI et de son dernier PSU peut diffrer selon le choix darchitecture
adopt par la base de donnes (Simple ou en grappe) :

Installation de GI sur serveur indpendant (Oracle Restart).
Installation de GI sur un cluster de serveurs pour une configuration en RAC ou ORON.

Nous dvelopperons ici brivement les tapes fondamentales de ces procdures.
Durant toutes les tapes dinstallation, nous devons prendre le soin de vrifier que la version de la
base de donnes installe par GI et celle de Cloud Control implmente au sein du systme
informatique sont certifies pour fonctionner ensemble.

a. Installation de la dernire version logicielle GI 11gR2
Si nous choisissons dutiliser Grid Infrastructure, nous devons installer la dernire version de loutil
disponible pour la plateforme du serveur sur lequel linstallation est mise en uvre. Il faut de plus
que nous nous assurions que la version du logiciel implmente est certifie pour fonctionner avec
la Cloud Control 12c et quil existe la version quivalente pour la base template.

b. Installation du dernier PSU de GI pour le logiciel de la base de donnes 11.2.0.x
Aprs linstallation de la dernire version de Grid Infrastructure, il nous faut lui appliquer le
dernier ensemble de correctifs (PSU).
Page | 52

Mmoire dingnieur

IV.1.3 Etape 2 : Installation du logiciel de base de donnes

Nous allons expliciter la procdure classique de linstallation du logiciel de la base de donnes
11gR2.
Nous indiquerons cependant les options suivre qui sont adaptes aux choix dEssilor.

Option dinstallation : Il nous faut choisir loption Installer uniquement le logiciel de base de
donnes . Comme nous lavons dj expliqu, nous devons dabord appliquer le dernier PSU de la
base de donnes avant dinstaller la base de donnes elle-mme (tape suivante).

Option dinstallation Grid : Nous avons le choix entre trois options dinstallation. Seul le choix en
bleu est adapt au contexte et aux choix dEssilor :
Installation dune seule instance de base de donnes (Single-instance database)
Installation de bases de donnes en mode Oracle Real Application Clusters (mode grappe)
Installation de bases de donnes RAC One Node (Une seule instance de base de donnes
est active parmi la grappe)

Nous avons maintenant accs aux lments de configurations suivant via DBCA :
Langage du produit : Il sagit de ltape de slection de la langue, Essilor demande
dinstaller les produits Oracle en anglais afin dtre en accord avec la configuration
effective sur les serveurs de Thalande.
Type de la base de donnes : Pour les milieux professionnels comme le ntre, il nous faut
choisir la version Enterprise Edition mais ce nest pas tout : nous devons cocher la case de
partitionnement Oracle. Cest une option obligatoire car la base Repository cre un
nombre consquent de tables partitionnes et dindexes dans le schma SYSMAN afin de
stocker les nombreuses mtriques de supervision. Les autres lments lists sont
facultatifs.
Localisation de linstallation : nous devons spcifier un certain nombre dlments
concernant le chemin dinstallation du logiciel et celui de la base Oracle :
o Chemin dinstallation de la base (Oracle Base) : /u01/app/oracle
o Chemin dinstallation logiciel (Sofware Location) :
/u01/app/oracle/product/11.2.0/db_1
Groupe dappartenance systme (Operating System Groups) : Il nous faut spcifier les
valeurs concernant les groupes dappartenance systme pour les groupes OSDBA et
OSOPER :
o Groupe dadministrateur base de donnes OSDBA : dbdb. Essilor a choisi la valeur
dbdb.
o Groupe des oprateurs OSOPER (Facultatif) : dbdb. Essilor ne spcifie pas ce champs

Sommaire : Vrification des choix effectus et finalisation de linstallation.
Page | 53

Mmoire dingnieur

IV.1.3.1 Installation du dernier PSU
Comme nous lavons dj mentionn, aprs linstallation du logiciel de base de donnes nous
devons lui appliquer son PSU le plus rcent. Une liste des PSU est disponible dans les notes MOS
(My Oracle Support) n7566671.1 au chapitre Patchs Oracle Recommands Bases de donnes
Oracle .
IV.1.3.2 Modle Enterprise Manager DBCA

Avant de commencer cette partie, il nous faut imprativement nous assurer que le logiciel Grid
Infrastructure (si GI est choisi) ou que le logiciel de base de donnes ait t install avec son PSU le
plus rcent. Cette dernire tape consiste crer une base de donnes conforme pour servir de
base dpt (Repository) en faisant appel lassistant de configuration de base de donnes DBCA.
Celui-ci est directement excutable dans le rpertoire $ORACLE_HOME/bin.
Pour crer une instance unique (single instance) de base de donnes pour la base Repository,
Oracle recommande dutiliser son propre modle de base de donnes nomme EM template que
nous allons brivement introduire.

Introduction au modle EM template
En plus de crer la structure adquate, EM template dfinit un certain nombre de proprits qui
vont saligner avec les prrequis de la base Repository. Par exemple, loutil peut dfinir
automatiquement les valeurs les plus compatibles concernant attributs de stockage, les
paramtres dinitialisation etc.
Dans la premire version de Cloud Control (v12.1.0.1), seul linstalleur de CC pouvait installer et
configurer la base Repository. Toutefois, les versions CC 12.1.0.2 ou suprieurs contiennent en son
sein un modle DBCA prconfigur appel DB11.2.0.3 EM seed database ou EM template
qui va nous permettre de crer une base de donnes 11.2.0.3 contenant une base Repository
prconfigure. De telles bases de donnes diffrent des bases de donnes classiques tant dans
leurs structures que dans leurs donnes. Dans ce cas prcis, la base cre par le EM template
issue de DBCA contiendra ds sa cration une base de donnes Repository contenant :
Tous les schmas requis par OEM Cloud Control 12c : SYSMAN, SYSMAN_APM,
SYSMAN_MDS, SYSMAN_OPSS et SYSMAN_RO.
Tous les espaces de stockages logiques (Tablespaces) : MGMT_AD4J_TS,
MGMT_TABLESPACE et MGMT_ECM_DEPOT_TS)
Les diffrents objets de bases de donnes.
Le modle EM template apparait dans loutil DBCA dans la fentre des choix des modles de bases
de donnes ct des autres templates standard.
Vis--vis de cette option, lquipe DBA a opt pour suivre les recommandations dOracle et de
slectionner le modle spcialement destin OEM 12c. En effet, faire le choix dun modle
standard dEM template pour une base Repository demanderait des tapes de configurations
manuelles supplmentaires et fastidieuses dans les tapes dinstallations et de post-installations
de la base de donnes.
Page | 54

Mmoire dingnieur

Cela impliquerait notamment de consulter la documentation oracle en ligne pour effectuer une
srie de scripts supplmentaires sur la base Repository. Cela aurait pour effet de ralentir
considrablement ltape de configuration dOMR.
IV.1.3.3 Configuration de la base dpt avec EM template

Avant lavnement du modle EM template pour les versions Cloud Control 12.1.0.2 et
suprieures, il nous fallait slectionner un modle EM gnrique dans DBCA et configurer
manuellement les proprits de la base de donnes pour quelle puisse accueillir une base
Repository. Par exemple, nous devions spcifiquement expliciter les paramtres dinitialisation et
la taille des journaux dvnements (Redo Log). Aujourdhui, quasiment toutes les tapes de
configuration de la base de donnes sont effectues par lassistant de configuration avec le
template EM. Celui-ci est spcialement conu pour crer une base de donnes avec les proprits,
les structures, les donnes et les objets adquats pour servir de base Repository Cloud Control.
Nanmoins, il existe plusieurs prrequis et quelques bonnes pratiques quil nous reste effectuer.
Lquipe DBA a fait le choix dadopter la plupart des lments de la configuration par dfaut
propose par le template EM de loutil DBCA pour des raisons de simplicit et de maintenabilit et
dadquation avec nos besoins actuels. Nous nous intresserons donc dans un premier temps aux
options qui diffrent vis--vis de la configuration par dfaut puis, dans un deuxime temps, aux
tapes de configuration de la base Repository que le template EM ne couvre pas.
IV.1.3.4 Paramtres dinitialisation

Choix sur le type de mmoire utilis : Lors de la configuration de la base Repository via le logiciel
DBCA, il est possible de choisir un certain nombre de paramtre dinitialisation dont celui de la
mmoire. Lors de cette tape, nous avons le choix entre loption de gestion automatique de la
mmoire (Automatic Memory Management ou AMM) qui est coch par dfaut et loption de
gestion automatique du partage de la mmoire (Automatic Shared Memory Management ou
ASMM). Ces options sont toutes les deux des choix valides pour grer la mmoire ddie la base
Repository. Nanmoins, nous avons opts pour le type de mmoire ASMM car seul celui-ci permet
limplmentation de la configuration HugePages qui fait partie des meilleurs pratiques (Best
Practices ou BP) prconises par Oracle. Bien quil sagisse ici dune configuration optionnelle,
celle-ci permet de bnficier dun plus grand espace de mmoire partag (System Global Area ou
SGA) pour tous les processus Oracle. Par consquent, le HugePages amliore les performances de
la mmoire mme pour des allocations mmoires trs faibles (2 Go minimum).
Nous nous intresserons plus en dtails la mise en place de cette configuration un peu plus loin
dans cette partie.
Choix sur le jeu de caractre utilis : Lors du choix du jeu de caractres (Character Set) utilis par
la base de donnes, le modle EM Template choisi par dfaut celui qui est utilis par le systme
dexploitation du serveur. Nous avons choisi comme Oracle le recommande, dadopter le jeu de
caractre Unicode qui permet de stocker plusieurs groupes de langages. Bien que la politique
dEssilor soit dutiliser prioritairement langlais sur ses logiciels, notre quipe DBA a choisi cette
option pour des raisons de flexibilit.
Page | 55

Mmoire dingnieur

Redfinition de la taille des groupes des Redo Logs : Lors du choix de lallocation mmoire des
groupes de redo logs, il nous faut spcifier la fois le nombre de groupes crer et le nombre de
membres utiliser dans chaque groupe.
Concernant la taille des fichiers redo que nous devons adopter, le modle EM Template cre par
dfaut trois groupes de redo logs de 100 Mo. Notre quipe DBA a fait le choix dagrandir cette
taille 600 Mo pour respecter les recommandations dOracle. En effet cette taille est plus
approprie avec le nombre de redo logs que peut gnrer un petit environnement de production
qui change de fichiers logs toutes les 20 minutes. De plus agrandir la taille de ces fichiers
diminuent les oprations de maintenance les concernant et amliore les performances de
lcriture et de larchivage de la base de donnes.
Il est plus ais de laisser linstallateur DBCA crer des fichiers redo logs avec la bonne taille
mmoire que de la modifier manuellement plus tard. La taille prconise de ces fichiers dpend de
limportance du systme supervis par Cloud Control. Voici le tableau ici des recommandations
dOracle :
Tableau 3: Adquation entre la taille du site supervis et la taille recommande des redo logs
Taille du site supervise Taille recommande des fichiers Redo Log (Mo)
Petite 600
Moyenne 1024
Grande 1536

Lors de ltape de cration des groupes de redo logs, le modle EM Template propose par dfaut
de ne crer que trois groupes de ces fichiers. Cependant, nous avons opts pour la cration dun
groupe supplmentaire servant de de groupe tampon (Buffer group) et ce, malgr la taille
modeste de notre environnement superviser. En effet, une base de donnes en mode
ARCHIVELOG restera en suspend si un groupe de redo logs est sollicit mais ne peut pas tre
archiv.
Enfin, concernant le nombre de membres redo log crer pour chacun de ces groupes, nous avons
opt pour le multiplexage des fichiers redo log et les fichiers de contrle. Il sagit ici dune Best
Practice recommande par Oracle et que nous avons adopte.
Rappel : Les fichiers redo logs permettent la base de garder une trace de toutes les altrations
de donnes, ainsi en cas de crash de la base, ils permettent de rejouer les modifications apportes
la base. Ces fichiers doivent tre au moins au nombre de deux et ncessitent une attention toute
particulire tant au niveau de la sauvegarde que de l'optimisation des accs.
En mode ARCHIVELOG, les redo logs sont archivs afin de garder une trace de toutes les
modifications apportes et non pas seulement dans la limite de la taille des fichiers de redo log.

Sauvegarde du Template EM : Aprs ces tapes de configuration du template EM, nous avons
choisi comme nous le propose loutil DBCA de sauvegarder ce modle au cas o nous aurions
besoin de crer un deuxime environnement Cloud Control. En effet la mise en place de nouvelles
bases aux Etats-Unis et en Asie nous forcera peut-tre de monter des environnements de
Page | 56

Mmoire dingnieur

supervision entirement ddis ces sites. De ce fait, sauvegarder ce Template prsenterait
lavantage de ne pas repasser par les tapes de configuration du modle lors de la mise en place
dune future base Repository.
IV.2 Configuration de la base de donnes Repository

Ltape de configuration de la base Repository a un double objectif : elle doit rpondre aux
prrequis imposs par linstallation dOEM 12c et dimplmenter un certain nombre de
fonctionnalits ncessaires au fonctionnement et la fiabilit de la base Repository.
Les tapes de configuration de la base Repository qui suivent sont effectuer aprs lexcution de
DBCA.
La premire tape consiste renommer les fichiers de donnes (Datafile) de Cloud Control pour
quils correspondent aux noms attendu par linstalleur de Cloud Control : Oracle Universal Installer
ou CC OUI. De plus, ayant choisi le mode de gestion des donnes OMF (Oracle Managed File) nous
devons dsactiver loptimisateur de rcupration automatique des statistiques. Cette tape doit
faire lobjet dune attention toute particulire car elle peut bloquer le logiciel OUI de Cloud
Control.
Les autres tapes de configuration ont pour principal objectif de suivre les Best Practice prconiss
par Oracle en termes de disponibilit dune base de donnes 11gR2 (Maximum Availabilty
Architecture ou MAA). Ces meilleures mthodes sont dcrites dans la documentation que fournit
Oracle sur son site internet et sont aussi bien pertinentes pour une base Repository que pour une
base de donnes standard.
Ces lignes directrices peuvent tre mises en pratique la fois sur des bases en mode Grappe (RAC)
et sur des bases de donnes indpendantes. Voici donc les tapes de configurations additionnelles
effectuer sur la base Repository faisant partie des Best Practices reconnues par Oracle :
1) Renommage des fichiers de donnes Cloud Control destins aligner leur nom avec ceux
attendus par linstalleur de Cloud Contol OUI.
2) Dsactivation de loptimisateur de rcupration automatique des statistiques.
3) Dfinition du paramtre dinitialisation compatible avec la version du patch applique la base
de donnes.
4) Cration de groupes de redo logs additionnels (Ayant choisi le mode de gestion de stockage
des donnes OMF, nous devons faire cette tape aprs avoir excut loutil DBCA).
5) Vrification de ladquation de la configuration du systme dexploitation du serveur local avec
la configuration NLS de la base de donnes Repository.
6) Vrification de ladquation des fuseaux horaires entre le systme dexploitation du serveur et
celui de la base de donnes.
7) Implmentation du HugePages.
8) Activation du mode Flashback pour la base de donnes.
9) Activation du mode FORCE LOGGING.
10) Activation du Block Change Tracking pour la mise en place de sauvegarde incrmentale.
11) Excution du Kit de prrequis de OEM en mode indpendant.

Page | 57

Mmoire dingnieur

Seules les tapes en bleu feront lobjet dexplications dtailles.
Lordre dimplmentation de ces tapes na pas dimportance car celles-ci sont indpendantes les
unes des autres.
Pour des raisons de scurit, nous avons choisi deffectuer une sauvegarde de la base de donnes
Repository. De cette faon, la base donnes et sa configuration pourront tre restaures en cas
derreurs irrcuprables de la base de donnes durant les manipulations suivre.
IV.2.1 Renommage des fichiers de donnes Cloud Control

Ayant slectionn le mode de gestion Oracle-Managed File durant la cration de la base de
donnes dans longlet Chemin de stockage de DBCA, nous devons imprativement renommer
les trois fichiers de donnes crs par cet outil pour quils correspondent aux noms attendus par le
logiciel installeur de Cloud Control. En effet, il ne nous est pas possible de renommer directement
les fichiers de contrle durant ltape dinstallation dOEM Cloud Control. Voici la marche suivre :

SQL> select tablespace_name, file_name from dba_data_files;
SQL> Alter tablespace MGMT_AD4J_TS offline;
SQL> !mv o1_mf_mgmt_ad4_8gmfqckg_.dbf mgmt._ad4j.dbf
SQL>Alter database rename file
/orahome/app/oraoem/oradata/EMREP/datafile/o1_mf_mgmt_ad4_8gmfqckg_.dbf to
/orahome/app/oraoem/oradata/EMREP/datafile/mgmt._ad4j.dbf;
SQL> Alter tablespace MGMT_AD4J_TS online;

IV.2.2 Dsactivation de loptimisateur de rcupration automatique des

statistiques
Il sagit ici de lunique prrequis auquel loutil DBCA ne peut pas rpondre pendant la phase de
cration de la base de donnes. Il sagit ici dune opration de maintenance laquelle nous avons
implicitement adhr lorsque nous avons laiss par dfaut loption Activer les tches de
maintenance automatique dans les options de gestion de DBCA.
Notre expert administrateur base de donnes Oracle et moi-mme avons laiss cette option
coche car elle permet dactiver deux tches (jobs) supplmentaires qui savrent utiles pour
administrer plus facilement la base Repository. Il sagit des fonctions Auto Space Advisor et de
SQL Tuning Advisor .
La requte suivante permet dafficher ltat de ces fonctionnalits :

SQL> Select CLIENT_NAME, STATUS FROM DBA_AUTOTAST_CLIENT ;

Page | 58

Mmoire dingnieur

Tableau 4: Statut actif de l'Auto Optimizer Stats Collection
CLIENT_NAME STATUS
Auto Optimizer Stats collection ENABLED*
Auto Space Advisor ENABLED
SQL Tuning Advisor ENABLED
*Activ

Pour dsactiver loptimisateur automatique de rcolte des statistiques, nous devons excuter les
commandes suivantes puis vrifier nouveau le statut de cette fonctionnalit en excutant de
nouveau la commande explicite ci-dessus :

SQL> exec DBMS_AUTO_TASK_ADMIN.DISABLE(
SQL> client_name => auto optimizer stats collection,
SQL> operation => NULL,
SQL> window_name=> NULL);

IV.2.3 Cration de groupes de redo logs additionnels

Lors de la cration de la base de donnes, lassistant DBCA ne cre que trois groupes de redo logs
qui reprsente le nombre minimum requis pour effectuer des oprations sur une base Oracle.
Ayant voulu suivre les meilleures mthodes prconises par Oracle, nous avons cr un groupe de
redo log supplmentaire (Groupe 4). Ayant opt pour loption OMF, nous devons crer
manuellement ce groupe additionnel car loutil DBCA nest pas encore capable de grer cette
tape cration.
Voici le nom de lutilisateur systme et la commande SQL qui nous ont permis de crer ce nouveau
groupe :

ATLER DATABASE ADD LOGFILE GROUP 4 SIZE 600;

Page | 59

Mmoire dingnieur

Implmentation des HugePages

Sur la plupart des systmes dexploitions UNIX (Linux et AIX compris) et Windows, Oracle
recommande aux administrateurs de configurer loption des HugePages (Grandes Pages) pour des
bases de donnes dont le SGA (System Global Area) est suprieure 2 Go. Cette option nous
permet galement de mieux supporter lallocation mmoire des instances ASM (Automatic
Storage Management). La fonctionnalit HugePages est aussi connue sous le nom de Large
Pages pour les systmes AIX et Windows. Afin de rester dans le contexte dEssilor, nous ne
parlerons ici que des tapes dimplmentation de cette fonctionnalit sur un systme Linux x64.
HugePages est une fonctionnalit intgre dans les systmes Linux depuis la version 2.6 qui
permet dutiliser de grandes quantits de mmoire SGA de faon optimale en sassurant que la
mmoire ne fait jamais appel au disque dur. HugePages nous permet dutiliser des pages
mmoires beaucoup plus importantes (2 Mo ou 4 Mo) compares aux pages par dfaut de taille
de 4 Ko. Cela a pour principal avantage damliorer de faon consquente les performances de la
base de donnes sur Linux. Les avantages de cette fonctionnalit sont dautant plus marqus que
nous disposons de serveurs de grandes capacits dont la mmoire dpasse 100 Go.
Le seul point sur lequel nous devons prter attention concerne la restriction sur le type de
mmoire choisi durant ltape de configuration de la mmoire de DBCA. En effet, comme nous
lavons explicit prcdemment dans ce mmoire, HugePages ne peut pas tre utilis
conjointement avec la gestion automatique de la mmoire (Automatic Memory Management ou
AMM). Nous devons veiller cocher le mode de gestion automatique de mmoire partage
(Automatic Shared Memory Management ou ASMM). Par consquent, il a fallu peser les
avantages et les inconvnients avant dopter au final pour le mode ASMM. Deux critres ont t
dcisifs : le gain consquent de performance soulign par Oracle et la grande quantit de mmoire
dont nos serveurs disposaient. Nous avons pu de ce fait allouer plus de 100 Go sans inconvnients.
Pour vrifier si cette fonctionnalit est implmente, il suffit de taper la commande suivante :

grep Huge /proc/meminfo

Le tableau suivant montre la diffrence de configuration entre le HugePage configur et non
configur.
Tableau 5: Hugepage
HugePage non configure HugePage configure chez Essilor

AnonHugePages 53248 Ko AnonHugePages 55296 Ko
HugePages_Total 0 HugePages_Total 2050
HugePages_Free 0 HugePages_Free 1551
HugePages_Rsvd 0 HugePages_Rsvd 1550
HugePages_Surp 0 HugePages_Surp 0
Hugepagesize 2048 Ko Hugepagesize 2048

Les valeurs recommandes des proprits du tableau sont dfinies dans le MOS ID 401749.1

Page | 60

Mmoire dingnieur

IV.2.4 Activation de la base de donnes Flashback (Flashback Database)
La base de donnes Flashback nous permet de restaurer une base un moment prcis de son tat
antrieur sans utiliser le moindre media. Lorsquune base de donnes est active, Flashback
Database crit dans une zone tampon des images passes des blocks de donnes (Datablock) dans
les fichiers logs de Flashback. Ceux-ci sont gnrs par dfaut dans des tablespaces permanents
localiss dans la zone de restauration rapide du systme (Fast Recovery Area ou FRA). Les logs
Flashback permettent la base de donnes Flashback de gagner du temps sur la correction dune
erreur inattendu en restaurant la base originale dans un tat prcdent jug plus fiable.
Lquipe DBA a donc adopt cette fonctionnalit pour lui donner plus de flexibilit lors derreurs
critiques inattendues. En effet, lexpert DBA Oracle de notre quipe et moi-mme avons
dtermin quil est parfois plus judicieux de restaurer un tat antrieur fiable plutt que dessayer
de trouver la source de lerreur et de la corriger. Ce type de restauration est dautant plus efficace
quil est rapide mettre en uvre.
Afin de mettre en uvre cette fonctionnalit, il est indispensable dactiver le mode FORCE
LOGGING.

IV.2.4.1 Activation du mode FORCE LOGGING

Pour finaliser lactivation de Flashback Database nous avons d activer le mode FORCE LOGGING.
Cette option permet de forcer lcriture de redo log pour certains types de commande SQL nen
gnrant pas par dfaut. Par exemple, les commandes de crations de table CREATE TABLE
autorisent la clause NOLOGGING. Ceci a pour inconvnient majeur dempcher la restauration de
cette table un tat antrieur.
Par consquent, nous avons donc activ cette fonctionnalit pour permettre la base de donnes
Flashback de construire une image fidle de la base Repository.
Pour activer la mode FORCE LOGGING, il suffit dexcuter les commandes SQL suivantes :

SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database FORCE LOGGING;
SQL> alter database OPEN;
Page | 61

Mmoire dingnieur

IV.2.5 Activation du Block Change Tracking

Lorsque lon active cette fonctionnalit dans une base de donnes v11g, Oracle fait linventaire
des chemins physiques de toutes les modifications de la base afin de crer une sauvegarde
incrmentale dans le temps. De ce fait, le logiciel RMAN, qui est loutil de gestion des sauvegardes
et de restaurations des bases de donnes Oracle, utilise automatiquement cet inventaire pour
dterminer les blocks de donnes qui doivent tre lus pendant une sauvegarde incrmentale.
Dans un deuxime temps, RMAN accde ces donnes pour les sauvegarder. Lorsque la
fonctionnalit Block Change Tracking nest pas active, cest lintgralit du bloc de donnes qui
doit tre lu par RMAN. De plus, si une toute petite partie des donnes du bloc a t modifie, cest
le bloc de donnes tout entier qui sera sauvegard. Ceci a pour principal dsavantage de grossir
inutilement la taille des sauvegardes effectues.
Nous avons donc dcid dactiver cette option qui permet doptimiser la taille mmoire des
sauvegardes effectues.
Cette option sactive partir dun fichier binaire localis dans la zone de rcupration rapide du
systme (FRA). Ce fichier est localis dans le mme rpertoire que les fichiers de la base de
donnes.

Pour vrifier si cette fonctionnalit est active il suffit dexcuter la commande SQL suivante :

SQL> Select * From V$BLOCK_CHANGE_TRACKING;

Voici comment procder maintenant lactivation :

SQL> Alter database enable BLOCK CHANGE TRACKING;

IV.2.6 Excution du Kit de prrequis de OEM en mode indpendant

Le kit de prrequis Enterprise Manager est un logiciel qui vrifie de faon automatique si tous les
prrequis ncessaires pour la base Repository ont t installs. En effet, nous devons nous assurer
que tous ces prrequis sont satisfaits pour procder linstallation de Cloud Control. Ce kit permet
galement dentreprendre certaines actions correctives quand un prrequis fait dfaut.
Linstallateur OUI dOEM 12c excute automatiquement ce kit mais nous pouvons galement
lexcuter indpendamment de cet outil comme nous lavons fait en excutant la commande :
emprereqkit
Notre expert DBA et moi-mme avons pens quil serait plus pratique de corriger les
manquements signals dans le rapport transmis par cette commande que de les rsoudre la
vole pendant linstallation de Cloud Control.
La validation des prrequis par ce kit reprsente laboutissement des tapes de configuration de la
base Repository. Il va maintenant falloir installer OEM 12c et le configurer son tour pour
bnficier des fonctionnalits de notifications dalertes et dincidents.
Page | 62

Mmoire dingnieur

IV.3 Installation et Configuration dOracle Enterprise Manager Cloud Control
Dans cette partie nous allons principalement nous intresser aux tapes de configuration du
systme de supervision. Cela nous permettra notamment de bnficier des fonctionnalits
avances de notification dalerte et de configuration des seuils de mtriques. Les tapes
dinstallation du logiciel et de lagent sont consultables dans les annexes de ce mmoire. Voici
donc les tapes de configuration que lon a effectu pour OMS et OMR :
Ractivation de loptimisateur de rcupration automatique des statistiques
Mise en uvre des variables denvironnement sur le serveur-hte OMS
Planification des purges priodiques des fichiers logs de Cloud Control
Mise en place de la politique de sauvegarde des composants de Cloud Control
IV.3.1 Ractivation de loptimisateur de rcupration automatique des

statistiques
Lors de ltape de configuration de la base Repository, nous avions dsactiv cette fonctionnalit
afin de nous prparer linstallation de Cloud Control. Une fois OEM dploy, il est important de
ractiver loptimisateur de rcupration automatique des statistiques pour optimiser les plans
dexcution des commandes SQL. Pour ce faire, il suffit de procder de la manire suivante :

SQL> exec DBMS_AUTO_TASK_ADMIN.ENABLE(
SQL> client_name => auto optimizer stats collection,
SQL> operation => NULL,
SQL> window_name=> NULL);

La requte suivante nous permet de vrifier le statut de cette fonctionnalit :

SQL> Select CLIENT_NAME, STATUS FROM DBA_AUTOTAST_CLIENT order by 1;

Tableau 6: Statut inactif de l'Auto Optimizer Stats Collection
CLIENT_NAME STATUS
Auto Optimizer Stats collection ENABLED*
Auto Space Advisor ENABLED
SQL Tuning Advisor ENABLED
*Activ

IV.3.2 Mise en uvre des variables denvironnement sur le serveur-hte OMS

Comme pour une grande majorit de logiciels informatiques, OEM Cloud Control est plus facile
administrer lorsque lon peut dfinir des variables denvironnement qui viennent raccourcir et
donc simplifier certaines critures de chemins de rpertoire (chemins absolus). Lutilisation de ces
variables denvironnement peut mme savrer obligatoire lorsque lon veut dmarrer ou stopper
un lment de Cloud Control.
Page | 63

Mmoire dingnieur

Par exemple, pour stopper ou dmarrer lagent OMA, nous avons d mettre en mettre les
variables denvironnement suivantes :
export AGENT_HOME=/IDBO/oem/core/12.1.0.4.0
export ORACLE_HOME=/IDBO/oem/core/12.1.0.4.0
export PATH=$ORACLE_HOME/bin:$PATH

Il suffit maintenant de lancer les commandes darrt ou de dmarrage :

Tableau 7: Commandes d'arrt et de dmarrage de l'agent
Consignes Commandes Rponses attendues du systme

administrateur systme
Dmarrage de lagent emctl start agent Agent is Running and Ready
Arrt de lagent emctl stop agent Agent is not Running
Statut de lagent emctl status agent Agent is Running and Ready / Agent is not
Running

IV.3.3 Planification des purges priodiques des fichiers logs de Cloud Control
Les fichiers logs gnrs par Cloud Control peuvent nous tre utiles pour dboguer et rsoudre
certains problmes daccs la console OEM et de transmission des donnes des agents. Tous les
fichiers logs gnrs par OMS et WLS (WebLogic Server) dpassant une certaine taille gnrent,
une fois arrivs leur limite (5 Mo) de nouveaux fichiers et effacent les anciens fichiers logs de
faon automatique. Cependant, toutes les anciens logs ne sont pas systmatiquement effacs et
requirent une suppression manuelle de la part de ladministrateur.
Sans cette intervention, lespace disque que nous avons allou OMS pourrait se saturer
rapidement ce qui aurait pour consquence darrter les activits de supervision de Cloud Control
comme lenvoie des alertes, la rcolte des mtriques et la transmission des donnes des agents.
Etant donn la taille modeste de notre environnement de supervision et de lespace disque
disponible sur notre serveur OMS, lquipe DBA a planifie une purge des anciens fichiers logs tous
les trente jours.
Page | 64

Mmoire dingnieur

Mise en place de la politique de sauvegarde des composants de Cloud

Control
Afin de finaliser les tapes dinstallation et de configuration dOEM 12c, notre quipe a mis en
place une politique de sauvegarde de Cloud Control pour se prmunir contre des dfaillances
matrielles, logicielles et humaines qui pourraient potentiellement nous amener repasser par
toutes les tapes dinstallation et de configuration effectues jusqu maintenant. Voici donc les
diffrentes parties de notre politique de sauvegarde :

Sauvegarde de la base Repository : La base de donnes OMR ainsi que son logiciel sont
sauvegards rgulirement selon les meilleures mthodes recommandes par Oracle dont
voici le rsum :
Sauvegarde des rpertoires Oracle homes et de lOracle Inventory dans la zone de
sauvegarde du systme dexploitation du serveur.
Sauvegarde de la base de donnes hbergeant la base Repository avec le logiciel RMAN
via la console Cloud Control ou via des scripts de lignes de commandes.
Planification de sauvegardes rgulires dOMS :
Sauvegarde des rpertoires Oracle homes et de lOracle Inventory dans la zone de
sauvegarde du systme dexploitation du serveur.
Capture de la configuration dOMS via lutilisation des fonctionnalits emctl suivantes :
Emctl exportconfig oms -dir <backup_dir> -sysman_pwd <pwd>

Ainsi, en sauvegardant la fois les donnes (datafile) et le logiciel de la base Repository, il est ais
de recrer une image fidle de la base aprs la survenance dun dsastre.
IV.4 Configuration de la console Cloud Control

Une fois finalise linstallation et la configuration dOEM 12c, il nous faut mettre en uvre les
mthodes de supervision destines surveiller lactivit de notre environnement de production.
Les tapes de configuration de Cloud Control seffectuent via sa console. Nous y accdons depuis
un navigateur internet avec une URL indique par OEM lors de son installation. Ces tapes ont
pour objectif dactiver les fonctionnalits de notification dincidents survenus sur les bases de
donnes supervises.
Page | 65

Mmoire dingnieur

IV.4.1 Mise en place des mthodes de notification

Les mthodes de notification reprsentent les mcanismes permettant de nous contacter lorsque
certains vnements ont lieu. Par exemple, lapparition dalertes de mtriques ou le changement
de ltat dune base sont des vnements qui doivent nous tre notifis en permanence afin de
nous permettre dadministrer correctement nos bases de donnes. Nous avons fait le choix de
notifications sous forme de mails destins la messagerie commune de notre quipe en France et
celle de Thalande qui travaille en collaboration avec nous en horaire dcal. Il existe dautres
moyens de notification (procdures PL/SQL ou scripts OS etc.) mais pour des raisons de simplicit
et de maintenabilit nous avons dcid dadopter ce moyen de communication.
Pour recevoir des notifications au sujet de certains vnements, ladministrateur doit en premier
souscrire des rgles de notifications que nous expliquerons plus en dtail dans la suite de ce
mmoire. Dans ces rgles, il est possible entres autres de dfinir les destinataires des notifications
mais aussi la nature des vnements dont nous souhaitons nous tenir au courant. Pour ce faire,
ladministrateur doit avoir configur au pralable une mthode de notification.
a. Serveur Mail
Le mail reste la mthode de notification principale que nous utilisons chez Essilor, quil sagisse de
superviser des environnements de production ou de non-production. Pour mettre en place ce
systme, il faut quun super administrateur (notre expert DBA) dfinisse au moins un serveur mail
travers lequel Cloud Control puisse envoyer des notifications aux diffrents administrateurs. Le
champ du serveur mail sortant (SMTP) sur la page prsente ci-dessous contiendra dj une
entre si lon a spcifi un serveur SMTP lors de linstallation de Cloud Control.

Pour que nous puissions fournir une haute disponibilit concernant la transmission de
notifications il nous est possible de spcifier des serveurs mails additionnels.
Une fois que tous les champs sont spcifis, il ne reste plus qu tester la configuration.

b. Spcification des adresses mails pour les utilisateurs
Maintenant que nous avons configur le serveur mail sortant nous devons dfinir les adresses
mails des administrateurs chargs de la maintenance des bases supervises. Limage ci-dessous
montre la section de la console utilisateur o lon peut renseigner ces adresses.

Page | 66

Figure 6:Mise en place des adresses mails des administrateurs

Mmoire dingnieur

Pour finaliser cette tape, nous devons utiliser la fonctionnalit de test propose par le produit
pour sassurer de lintgrit des adresses renseignes.
c. Configuration de lemploi du temps des notifications
A travers cette fonctionnalit, il nous est possible de dfinir pour chaque administrateur de notre
quipe les adresses et les horaires pendant lesquelles ils recevront les notifications de Cloud
Control. Lemploi du temps est configurable. Nous pouvons par exemple renseigner une adresse
de notification diffrente pour chaque heure. En ce qui concerne notre quipe, nous avons laiss
les notifications actives toutes les heures durant toute la semaine, weekend compris pour
ladresse mail de lexpert DBA Oracle de notre quipe. En effet, celui-ci dirige les oprations de
maintenance en France et en Thalande et de ce fait, il doit rester notifi en permanence.
Lemploi du temps propos par Cloud Control autorise des rotations allant dune huit heures.
Cela est dautant plus pratique que beaucoup de professionnels de linformatique travaillent sur
une rotation de sept jours compose de cinq jours ouvrs et de deux jours de repos.
Voici la marche suivre pour mener bien cette tape :
1. Dfinir des horaires et de la rotation effectue sur lemploi du temps.
2. Renseigner la frquence de rotation dsire
3. Modifier ou remplacer lemploi du temps existant
4. Dfinir la date de dbut de lemploi du temps Lundi.
5. Choisir le fuseau horaire dans lequel ladministrateur se situe

Page | 67

Figure 8: Ecran de mise en place de la priode rotation chez Essilor
Figure 7: Ecran de lemploi du temps des notifications luvre chez Essilor

Mmoire dingnieur

d. Scurit de Cloud Control

La scurit est une partie importante de ladministration dOracle Enterprise Manager. Celle-ci
sest beaucoup renforce dans la version 12c vis--vis des versions 10g et 11g via lapparition
didentifiants partags.
Cette nouvelle fonctionnalit permet certains privilges dont nous disposons dtre attribus
plusieurs autres administrateurs (situs en Thalande). De ce fait, cela rduit considrablement le
nombre de personnes se partageant les mmes mots de passe. Sagissant ici dune amlioration
de scurit substantielle, jai t charg dtudier ce sujet afin den expliquer les avantages
lexpert DBA oracle de notre quipe dans loptique dune future implmentation de cette
fonctionnalit.
Nous nous intresserons galement aux amliorations concernant les commandes Sudo et
PowerBroker.
Page | 68

Mmoire dingnieur

IV.5 Conclusion

Ltape de configuration de Cloud Control nous a permis dimplmenter des fonctionnalits
essentielles la supervision de nos bases de donnes. En effet, les fonctionnalits de notification
dalertes et dincidents sont celles que notre quipe utilise principalement pour surveiller lactivit
de nos bases de production dans la version 10g dOEM. Cependant, afin dtre notifier des
vnements survenus sur nos bases de donnes supervises, il est ncessaire que :

La base Repository fonctionne correctement
Lagent prsent sur le serveur et les agents prsents sur les serveurs-cibles fonctionnement
galement
Le service OEM soit activ

Ne disposant pas de dispositifs de redondance, nous ne pouvons pas assurer en cas de sinistre la
continuit de la supervision de nos bases de donnes. De ce fait, si un incident critique lieu
pendant la maintenance dOMR ou dOMS, nous ne serions pas notifis de cet vnement.
En revanche, nous disposons des sauvegardes ncessaires pour rcuprer lintgralit de notre
base Repository si celle-ci venait tomber en erreur.
Page | 69

Mmoire dingnieur

V Aprs Projet
Maintenant que nous avons dploy et configur OEM 12c, nous allons expliciter dans cette partie
comment fonctionne ladministration dOEM. Cette premire tape est ncessaire pour
comprendre par la suite les amliorations qui ont t apportes dans Cloud Control. Dans un
second temps, nous donnerons les explications ncessaires lexploitation des nouvelles
fonctionnalits dadministration de Cloud Control afin que les quipes de Thalande puissent en
tirer parti.
V.1 Conduite du changement

Dans cette partie nous allons analyser les principales amliorations dadministration qui ont t
apportes dans la version Cloud Control puis brivement expliquer comment les exploiter.
Avant de commencer la phase danalyse nous allons mettre en vidence les diffrents acteurs de
ladministration dOracle Enterprise Manager afin de mieux comprendre le fonctionnement de
loutil dans sa globalit.
V.1.1 Dtails et explications de ladministration de Cloud Control

Chaque utilisateur de Cloud Control est appel administrateur. Il existe trois types dutilisateur
OEM : ladministrateur, le super administrateur et le propritaire de la base Repository. Le compte
SYSMAN est lunique propritaire de cette base de donnes. Le super administrateur a quant lui
tous les privilges dont dispose un administrateur standard mais il dispose galement de ceux
permettant de grer tous les administrateurs au sein de lenvironnement Cloud Control.
Comme le recommande Oracle, chaque utilisateur de CC dispose au sein de notre quipe de son
propre compte, compos dun identifiant et dun mot de passe qui lui appartient. Il existe trois
types de rles disponibles pour un administrateur : le concepteur et loprateur et le super
administrateur :
Le Super Administrateur : Un compte Super Administrateur est semblable un compte
administrateur standard, nanmoins celui-ci dispose de la capacit de gestion des comptes
administrateurs de Cloud Control. Celui-ci dispose dun accs total toutes les cibles
monitores par OEM. De plus, le super administrateur dispose des droits de cration et de
modification de comptes administrateurs.
Le concepteur : Un concepteur est un administrateur disposant des autorisations lui
permettant de crer des modles de procdures de dploiement, des plans et des modles
de correctifs.
Loprateur : un oprateur est un administrateur qui dispose de droits rduits sur les
procdures de dploiement et les bibliothques logiciels. Un oprateur dploie et utilise
les procdures, les patchs et les modles de correctifs. Il nest pas cens modifier ni mme
crer ces procdures.
Page | 70

Mmoire dingnieur

Le propritaire de la base Repository : Le propritaire de la base Repository appartient la
classe des Supers Administrateurs et possde des droits additionnels lui permettant de
grer et de maintenir cette base. Par dfaut, le compte SYSMAN est le propritaire de cette
base et son utilisation est rserve des oprations de mise jour ou de maintenance de
la base Repository.

Au sein de notre quipe, nous disposons tous de comptes administrateurs nominatifs. Lexpert
DBA Oracle dispose quant lui du compte Super Administrateur car il est le responsable des
oprations en France.
V.1.2 Analyse des amliorations dadministration

Les accrditations
Les accrditions (credentials) sont au cur de la scurit dOEM Cloud Control. Lorsque nous nous
connectons linterface de loutil, nous navons dabord accs qu une vue basique des
informations de supervision rcolts par les agents. Pour accder une vision complte de ces
informations il est ncessaire que nous nous identifiions la base de donnes via une
accrditation dfinie pour chaque compte utilisateur. Cela permet nos dveloppeurs de bases de
donnes, nos gestionnaires et notre quipe administrateurs de se connecter la base en
utilisant nos accrditations respectives. Cest une mesure essentielle pour scuriser et auditer
OEM.
Les accrditations sont maintenant gres de faon nominative. Plus prcisment, celles-ci sont
sauvegardes sous forme de noms ce qui facilite grandement leur gestion mais aussi leur partage.
Les noms des accrditations sont sauvegards et peuvent tre utiliss pour se connecter sur des
cibles supervises. De plus, des accrditations prfrentielles peuvent tre utiliss pour un certain
nombre de connexion par dfaut et peuvent tre sauvegardes dans la base Repository.
La nouvelle fonctionnalit de partage des accrditations prsente plusieurs avantages :
Rduction du partage des mots de passes : Notre expert DBA Oracle est maintenant la seul
personne ayant besoin de connaitre le mot de passe du compte system pour une base de
donnes. Les informations de connexion sont caches mais peuvent tre partages entre
plusieurs autres administrateurs.
Mise en place de permission de groupe : Il nous est possible de donner accs une base
de donnes certains groupes dutilisateurs uniquement. Par exemple, nous pouvons
dcider que tous les administrateurs concepteurs aient accs en lecture seulement une
base de donnes qui initialement leur tait interdite.
Il sagit ici dune fonctionnalit qui nous a t particulirement utile lors de la configuration des
seuils dalertes des mtriques et des rgles dincidents. En effet, mon compte administrateur
standard a pu hriter de certains droits du compte Super Administrateur de lexpert DBA de notre
quipe. De ce fait, cela ma permis de configurer avec son accord et ses prconisations un certain
nombre de ces dispositifs.
Page | 71

Figure 9: Fentre de cration dune accrditation

Mmoire dingnieur

Accrditations nominatives
Les accrditations nominatives (Named credentials ou NC) sont sauvegardes et associes
chaque administrateur dans la base Repository. Celles-ci peuvent contrler selon leur nature les
accs une base de donnes, un serveur-hte ou bien une application. Au cur de laccrditation
sont dfinis un identifiant et un mot de passe qui sont associs au type de cible vis. Une
accrditation nominative peut tre utilise sur une ou plusieurs cibles si les identifiants et les mots
sont les mmes pour chacune dentre elles. Les NC peuvent tre gres dans OEM Cloud Control
via la fentre Security Named Credentials . Nous pouvons y supprimer ou modifier les
accrditations existantes ou encore en crer de nouvelles.
La cration daccrditation varie lgrement en fonction de lauthentification exige par le type de
cible slectionn dans le Target Type .
Ce champ dtermine galement les proprits qui seront disponibles dans la partie proprit de
laccrditation

Accrditations automatiques
Les accrditations automatiques sont stockes et assignes en gnral des cibles spcifiques.
Nanmoins, nous pouvons mettre en place ces accrditations pour des cibles ou des types de
cibles plus gnrales via loutil daccrditation automatique Preferred Credential . Si ces types
daccrditations ne sont pas dfinies, nous sommes contraints dentrer manuellement la bonne
accrditation chaque fois que nous dsirons avoir accs toutes les informations de la cible dont
nous souhaitons nous renseigner (laccs aux informations basiques nexigent pas daccrditations
particulires).
Page | 72

Figure 10: Fentre de gestion de dlgation des privilges
Mmoire dingnieur

Chez Essilor, la mise en place de ces accrditations est peu envisageable car chaque serveur-hte,
chaque base de donnes et chaque application requiert diffrents identifiants et mots de passe. Il
faudrait par consquent crer autant daccrditations quil existe de cibles diffrentes. Cest la
raison pour laquelle nous nenvisageons pas pour le moment de mettre en place un tel systme.
Accrditations de supervision
Les accrditations de supervision sont utilises par les agents OMA pour superviser des cibles
spcifiques dans lenvironnement OEM Cloud Control. Celles-ci peuvent tre mis en uvre par un
Super Administrateur et fonctionner pour tous les agents si les identifiants de connexion sur les
serveur-htes sont les mmes. De manire gnrale, nous attribuons une accrditation spcifique
pour chaque serveur sur lequel un agent est install. Laccrditation est renseigne une seule fois
lors de la phase de dploiement de lagent sur le serveur-hte.
Ces accrditations sont essentielles pour le bon fonctionnement de Cloud Control et sont faciles
maintenir. Il est indispensable que nous changions les mots de passe des accrditations
renseignes dans OEM lorsque nous changeons les mots de passe systme (ou de base de
donnes).
Cette remarque est dautant plus importante que notre quipe met en application sa politique de
changement de mots de passe pour renforcer la scurit de ses systmes.
Dlgation de droits
La dlgation de droits ou de privilges permet aux utilisateurs systme dun serveur-cible
dobtenir un niveau de privilge suprieur via les commandes Sudo ou PowerBroker. Ces droits
sont utiliss durant le processus de configuration de lagent et dpendent de sa mthode
dinstallation. Toutefois, si lon souhaite utiliser la fonctionnalit de dlgation de privilges aprs
ltape dinstallation de lagent, il est ncessaire de configurer cette dlgation dans la section de
gestion de dlgatio des privilges.
Page | 73

Mmoire dingnieur
Figure 11: Fentre daudit de control OEM 12c
Cas pratique :
Prenons le cas dun administrateur oprateur dOEM voulant stopper ou dmarrer un agent sur un
serveur. Ce dernier ne dispose pas ncessairement des privilges suffisant pour effectuer ces types
doprations. En revanche, il est trs probable que le Super Administrateur dOEM dispose des
privilges suffisant sur ce mme serveur. Grce loutil de dlgation des privilges,
ladministrateur oprateur pourra donc demander au Super administrateur de configurer cette
fonctionnalit afin quil puisse hriter des droits dont il manque.
Dans notre quipe, tous nos membres possdent des comptes utilisateurs disposant des droits
suffisants effectuer des oprations de maintenance sur les agents OMA. Cette fonctionnalit ne
nous est donc pas ncessaire pour le moment.
Audit avec Cloud Control
La fonctionnalit daudit de Cloud Control est destine surveiller son utilisation. Les informations
de connexion et de dconnexion sont enregistres et nous pouvons les consulter depuis la section
Audit Data de Cloud Control. Afin que cette surveillance soit efficace, chacun des DBA Oracle
doit se connecter avec son propre compte. En effet, dans le cas contraire, si tous les
administrateurs sidentifient la console OEM avec le compte super administrateur SYSMAN, il est
impossible de connaitre les rels utilisateurs de loutil.
Chez Essilor, laccs OEM 12c reste trs restreint car il nexiste que trois personnes qui ont accs
la console utilisateur :

Un expert DBA Oracle qui possde le compte Super Administrateur.
Un administrateur snior Oracle qui dispose dun compte administrateur.
Moi-mme qui dispose du compte utilisateur SYSMAN.

Grce cette fonctionnalit, il nous est trs ais de contrler laccs OEM. Voici un exemple de
ce que peut afficher cette fonctionnalit.

Page | 74

Mmoire dingnieur

Il sagit ici dun cas trs simple naffichant que les informations de connexion et de dconnexion
dune seule aprs-midi mais il est possible dagrandir lintervalle de temps plusieurs annes en
configurant les champs adquats (ici Start Date et End Date).

Scurisation des transferts de donnes de Cloud Control
OEM Cloud Control dispose dune multitude de fonctionnalits lui permettant dassurer sa scurit
au niveau de son application et au niveau des lments avec lesquels elle interagit. Celles-ci sont
accessibles via la console de loutil ou via des lignes de commandes (emctl sous OMS_HOME). Les
lments sous-jacents tels que la base de donnes Oracle 11g et OMS/Oracle HTTP Server
possdent leurs propres fonctionnalits de scurit intgres que Cloud Control coopte pour se
protger.
Tableau 8: Objectifs et mthodes dployes pour scuriser OEM Cloud Control
Objectifs de scurit de Cloud Control Mthode choisie pour atteindre lobjectif

Protger les donnes sensibles (mots de Scuriser la cl emkey
passe etc.)
Fournir la possibilit dauditer pour les sites Activer la fonctionnalit daudit de Cloud
qui en ont le besoin Control
Refuser les utilisateurs non-autoriss Renforcer les droits daccs des
accder la console OEM ; donner les administrateurs
droits daccs au personnel autoris
Adoption des standards de scurits des Mettre en place des politiques de scurit
entreprises pour scuriser les lments de pour les lments de CC et les serveurs-htes
CC et les serveurs-htes
Scuriser le transfert des donnes entre les Activer le Framework de scurit EM
agents et le serveur OMS Framework Security
Crypter les transmissions des donnes de la Utiliser la fonctionnalit avance de scurit
base Repository dOracle : Oracle Advanced Security
Scuriser les donnes transfres entre le Renforcer la scurit du serveur HTTP dOracle
navigateur internet et la console OEM et
restreindre le nombre dutilisateur de la
console
Intgrer CC avec dautres technologies Intgrer CC au sein dEUS
Oracle permettant didentifier les
utilisateurs
Dployer CC lorsque les pare-feu sont mis Configurer les proprits dans le fichier de
en place configuration de CC, renforcer la scurit des
serveurs proxy et configurer les pare-feu.
Page | 75

Mmoire dingnieur

Le tableau ci-dessus fait la liste des objectifs de scurit atteindre et de la mthode adopter les
satisfaire. Ce bref rcapitulatif a t utile pour valuer et mettre en place un certain nombre de
dispositifs de scurit lors du dploiement de Cloud Control.
Les lignes en bleu montrent les objectifs atteints ce jour par notre quipe DBA.
Les lignes en orange dsignent les objectifs en cour de ralisation.
Les lignes en noir sont les objectifs qui restent mettre en uvre.

V.2 Maintenance oprationnelle

Il existe deux types de maintenance de Cloud Control : la maintenance oprationnelle et la
maintenance physique du logiciel. La maintenance oprationnelle renvoie aux fonctionnalits que
notre quipe doit implmenter pour automatiser les tches de dtection des problmes et de
notification des vnements qui se sont produits. Les environnements informatiques que nous
avons la charge de maintenir sont composs de plusieurs centaines de cibles ncessitant une
supervision constante. Nous ne pourrions donc pas grer de tels environnements sans des logiciels
de supervision comme OEM. En effet, le cur de la maintenance oprationnelle de Cloud Control
concerne la fois la configuration des alarmes via les mtriques de supervision et la configuration
des rgles dincidents.
Aprs avoir dfini brivement les notions dalarmes, dalertes et de mtriques dans OEM, nous
expliquerons les raisons qui nous ont amens mettre en place des seuils dalertes spcifiques
certaines cibles supervises.
Nous expliquerons par la suite les rgles dincidents que nous avons cres pour superviser nos
bases de donnes de production.
V.2.1 Alarmes, alertes et mtriques de supervisions

Une alarme est un lment de configuration dcrivant le changement dtat dun systme.
Typiquement il met en vidence un changement indsirable travers la fluctuation de points de
donnes dans une srie de donnes. Les alarmes sont composes de mtriques de supervision, de
mesures de dates et de temps et peuvent potentiellement dclencher dautres alarmes.
Une alerte est une notification dun problme potentiel, celui-ci peut prendre diffrentes formes :
un e-mail, un SMS, un appel tlphonique. Une alerte est transmise par une alarme lorsque le
systme dtecte, par lintermdiaire du superviseur, quun de ses seuils dalerte a t atteint. Par
exemple, on peut configurer une alarme pour vous alerter quand le systme dpasse 80 %
dutilisation CPU sur une priode continue de 10 minutes.
Une mtrique de supervision est attache une srie de donnes et value cette dernire pour
sassurer quaucun seuil na t franchi. Le seuil est constitu de limites (exprimes sous la forme
de nombre de points donn) et de la dure pour laquelle ce mme seuil a t franchi. Lorsque les
points de donnes sortent du cadre dfini du seuil dalerte, le seuil est dit atteint ou franchi et le
superviseur passe de ltat normal ( Clear ) ltat alerte ( Alert ). De la mme manire,
Page | 76

Mmoire dingnieur Tableau 9: Seuils d'alertes OEM

lorsque les points de donnes reviennent dans le cadre les limites dfinies par le seuil dalerte, le
superviseur revient ltat normal. Les tats du superviseur sont utiliss comme des indicateurs
cls lorsque lon veut apprcier les tats des alarmes.
Parmi toutes les mtriques disponibles dans longlet de configuration des seuils dalertes, nous
avons dcids de mettre laccent sur un type de mtrique en particulier :
Tablespace Space Used (%) : Lespace allou un tablespace est gale la somme des espaces
mmoires occups par ses fichiers de donnes. Cette mtrique calcule lespace utilis pour chaque
tablespace existant.
Les tablespaces font lobjet dune attention particulire au sein de notre quipe car nous voulons
surveiller leur agrandissement. Plus prcisment nous voulons connaitre comment voluent les
fichiers de donnes (Datafile) situs dans chaque tablespace. De cette faon nous pouvons
connaitre comment voluent nos bases de donnes et dtecter des activits anormales sur celles-
ci. De plus, surveiller laccroissement des tablespaces nous permet de mieux anticiper les
problmes ventuels de stockage matriel.
Nous avons dcid de mettre en place la configuration suivante pour tous nos tablespaces (Voir
ligne All others ) :

Nous avons modifi les seuils par dfaut du champ All others qui tait initialement 94-97.
Nous avons descendu les seuils dalertes Warning et Critical 85-90 pour donner plus de
flexibilit nos quipes. Nous voulons dans la mesure du possible viter dentreprendre des
modifications dans des situations de stress.
Deux tablespaces font lobjet dune attention particulire :
APPS_TS_MEDIA : Ce tablespace stocke tous les documents lis lERP Oracle Application
APPS_TS_TX_IDX : Ce tablespace stocke les indexes de la base de donnes.
Ce sont des tablespaces qui voluent trs lentement dans le temps, nous avons donc gard la
configuration initiale dOEM uniquement pour ces deux tablespaces.
Page | 77

Mmoire dingnieur

V.2.2 Configuration des rgles dincidents dans OEM 12c

Pour profiter des notifications dalertes et dincidents, il nous a fallu crer des rgles dincidents.
Pour ce faire, nous avons copi et modifi le premier ensemble de rgles que propose par dfaut
Cloud Control (voir Tableau 10).
Tableau 10: Rgles d'incident OEM

Ces rgles permettent dautomatiser les fonctions comme la notification dvnements, la
cration dincidents et la purge dvnements selon des scnarios que nous pouvons configurer.
Parmi cet ensemble de rgles, nous nous intresserons en particulier rgle de cration dincident
pour les alertes critiques des mtriques ( Create incident for critical metric alerts ). Nous avons
en effet effectu un certain nombre de modifications sur cette rgle pour ladapter aux besoins
dEssilor :
Rptition des notifications dalertes : A cause de certains impratifs de production, nous ne
pouvons pas toujours traiter immdiatement les alertes mises par OEM. Afin de sassurer que
toutes les alertes sont rsolues au jour le jour, nous avons instaur en guise de rappel une
rptition des alertes existantes sur nos bases de donnes toutes les huit heures. Cette frquence
de rappel permet nos quipes en Thalande qui travaillent des horaires dcals par rapport
nous dintervenir galement sur les alertes qui nont pas pu tre traites temps pendant nos
horaires de travail.
Notification des alertes : Nous avons configur la rgle de cration dincident afin de ne recevoir
uniquement les alertes davertissement (Warning), les alertes critiques (Critical) et les purges
(Clear). De plus, nous avons diffrenci les destinataires de ces alertes en fonction de leur priorit.
Plus prcisment, les alertes davertissement et les purges sont uniquement envoys aux quipes
support (TMA, Analystes) et les alertes critiques sont envoys aux quipes DBA de France et de
Thalande ainsi quau centre dassistance Essilor (Helpdesk). Cela nous permet de prioriser la
rsolution des alertes et des incidents survenus et de rpartir selon les diffrents niveaux de
comptences la charge de travail.
Page | 78

Mmoire dingnieur

VI Conclusion

Nous avons expos dans ce mmoire les mthodes dimplmentation et dexploitation de la
solution Cloud Control pour satisfaire nos besoins en termes de supervision de nos bases de
donnes de production.
Il en rsulte une rflexion et une mthodologie clairement dfinies pour identifier nos besoins
darchitecture OEM, satisfaire les prrequis, installer les composants de loutil mais aussi identifier
et mettre en uvre nos impratifs de supervision.
En effet, nous avons dans un premier temps tudi les diffrentes possibilits darchitecture des
composants de Cloud Control ce qui a permis notre quipe de dfinir linfrastructure interne du
logiciel la plus adapte au contexte Essilor.
Nous avons ensuite men une analyse approfondie vis--vis de la configuration de la base
Repository et des nouvelles fonctionnalits proposes dans la version 12c afin damliorer la
fiabilit de nos bases et de faciliter les oprations de maintenance de nos bases de donnes.
Enfin, nous avons mis en vidence les impratifs de supervision auxquels notre quipe doit
rpondre en termes de mthode de notification et de configuration des seuils dalertes et des
rgles dincidents. Ce travail nous a permis de reproduire et damliorer les mthodes de
supervision existantes dans la version Cloud Control.
Le travail ralis dans la phase de conduite de changement a permis aux quipes de Thalande de
comprendre le fonctionnement du nouvel outil et de leur transmettre les connaissances
ncessaires afin quils puissent pleinement exploiter les principales fonctionnalits du produit.
Cette mission a donc permis de remplacer la version existante dOracle Enterprise Manager Grid
Control par la version Cloud Control tout en assurant la continuit de la supervision de nos bases
de donnes. De plus, limplmentation et lexploitation de ce nouvel outil nous a permis
dautomatiser certaines routines manuelles de surveillance autrefois opres par les membres de
notre quipe. Nous pouvons donc conclure que le changement de version dOEM sest traduit par
une amlioration substantielle de la qualit de maintenance de nos bases de supervision.
Toutefois, nous devrons continuer de maintenir nos logiciels de supervision additionnels Patrol
v3.5 et Patrol 7.6 car Cloud Control ne permet pas de maintenir nos bases de donnes Oracle v7 et
v8. Par consquent, nos bases de donnes ne bnficient pas toutes des mmes niveaux de
fonctionnalits et de supervision. Pour remdier ce problme, nous mettrons jour ces bases de
donnes dans le cadre dun futur projet.
Page | 79

Mmoire dingnieur

Glossaire

accrditations automatiques, 72 jobs, 36
accrditations de supervision, 73 Les accrditions, 71
accrditations nominatives, 72 Listeners, 35
Administrateur de base de donnes, 12 niveaux de service applicatif, 39
Agent autonome, 23 oprateur, 70
agent de supervision, 35 Oracle Enterprise Manager Cloud Control
Agent prinstall, 23 12c, 20
audit, 74 Oracle Restart database, 46
base de donnes dpt, 38 Oracle WebLogic Server, 37
concepteur, 70 plug-ins, 35
Conservatoire National des Arts et Mtiers, 4 PowerBroker, 73
Console Client, 23 processus paralllis, 35
Contrat de Niveau de Service, 43 schma utilisateur, 38
dcouverte des cibles, 36 Standalone Database, 46
dlgation de droits, 73 Sudo, 73
EM template, 54 Super Administrateur, 70
Essilor International, 12 SYSMAN, 71
GCDomain, 37 World Wide Supply Chain, 17
JDBC, 37

Page | 80

Mmoire dingnieur

Rfrences Bibliographiques

Site Internet dOracle (Anglais uniquement) :
http://docs.oracle.com/cd/E24628_01/index.htm
Consult de Dcembre 2015 fin Janvier 2016

Monitoring & Alerting de Stawek Ligus
Publi par O'Reilly Media
ISBN 10:1-4493-3347-8

Oracle 10g Administration by Razvan Bizoi
Publi par :Tsoft, Groupe Eyrolles, 2006,
ISBN : 2-212-12055-9
ISBN 13 : 978-2-212-12055-4

Oracle Essentials for Oracle Database 12c
Publi par : OREILLY
ISBN-13 : 978-1449343033
ISBN-10 : 1449343031

Oracle Enterprise Manager Cloud Control 12c Deep Dive by Michael New
Publi par McGraw-Hill Professional
ISBN-10: 0071790578
ISBN-13: 978-0071790574

Page | 81

Mmoire dingnieur

Annexes
Table des matires

I. 11gR2 Database Installation (11.2.0.4) on Linux server x64 ..................................................... 83
II. Oracle Enterprise Manager Cloud Control 12c Installation ....................................................... 99
1. Starting Cloud Control and all Its Components ................................................................... 106
2. Stopping Cloud Control and all Its Components .................................................................. 107
III. OEM 12c Agent installation & Database Discovery with Cloud Control .................................. 108
IV Planning prvisionnel .............................................................................................................. 119

Page | 82

Mmoire dingnieur

I. 11gR2 Database Installation (11.2.0.4) on Linux

server x64
1. User Creation:

Start putty with Xming
And do as shown below:

mkdir -p /IDBO/oem12c/ker1/11.2.0 IDBO
mkdir -p /IDBO/tmp0/tmp
export TEMP=/IDBO/tmp0/tmp
export TMPDIR=/IDBO/tmp0/tmp
export TMP=/IDBO/tmp0/tmp
export ORACLE_HOME=/IDBO/ker1/11.2.0
DISPLAY=192.168.1.128:0.0;
export DISPLAY
/etc
cp -p oraInst.loc oraInst.loc_IIC1
vi oraInst.loc
cp -p oraInst.loc oraInst.loc_IDBO
./runInstaller
cd /oraclestg/oracleRDBMS/11.2.0.3_Linux/database
Page | 83

Mmoire dingnieur

Follow the installation instructions as below:

Dont do anything, just click on Next!

A warning message appears, click on Yes

Page | 84

Mmoire dingnieur

Select Skip software updates

Select Install databse only , Click on Next

Select Single instance installation , click on Next

Page | 85

Mmoire dingnieur

Just click on Next

Select Enterprise Edition , De-Select all the options and Click on OK and Next

Page | 86

Mmoire dingnieur

Oracle Base path is : D:\oracle\ora11g\database_SID (database_SID = IDBO for example)
Software location is: IDBO/ker1/11.2.0

Database Administrator group : dbdb
Database Operator Group : dbdb

Page | 87

Mmoire dingnieur

Select Ignore All Option to continue

A Warning window appears, click on Yes

Page | 88

Mmoire dingnieur

Click on Install

Dont do anything yet
Do as shown below

Page | 89

Mmoire dingnieur

Picture Version

Text Version

(root@freo1124:/root)cd /IDBO/ker1/11.2.0/
(root@freo1124:/IDBO/ker1/11.2.0)
(root@freo1124:/IDBO/ker1/11.2.0)./root.sh
Performing root user operation for Oracle 11g
The following environment variables are set as:

ORACLE_OWNER= orIDBO
ORACLE_HOME= /IDBO/ker1/11.2.0
Enter the full pathname of the local bin directory:

[/usr/local/bin]:
The contents of "dbhome" have not changed. No need to overwrite.
The contents of "oraenv" have not changed. No need to overwrite.
The contents of "coraenv" have not changed. No need to overwrite.
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.
Finished product-specific root actions.

Page | 90

Mmoire dingnieur

Now you can click on Ok

The installation has finished! You can close the program

Page | 91

Mmoire dingnieur

Now, youll have to run the following commands :
dbca

Click on Next

Select Create a Database option and click on Next

Page | 92

Mmoire dingnieur

Select the second option: 11.2.0.3 Database Template for EM12 1 0 4 Medium deployment
Click on Next

Global Database Name: IDBO.essilor.fr
SID: IDBO
Click on Next

Page | 93

Mmoire dingnieur

Unselect all options and click on nex

Type the SYS user password
Type the SYSTEM user Password
Click on Next

Page | 94

Mmoire dingnieur

Select the Use Oracle-Managed Files option and enter:
/IDBO/dbf1

Unselect all option and click on Next

Page | 95

Mmoire dingnieur

Select the Run the following scripts option and click on Next

Just click on Next

Page | 96

Mmoire dingnieur

Click on Next

Select the Create Database Option and click on Finish

Page | 97

Mmoire dingnieur

Click on Ok

Click on Exit, its over.
Page | 98

Mmoire dingnieur

II. Oracle Enterprise Manager Cloud Control 12c

Installation

Start putty with Xming
oraInst.loc Setup
Youll need to check if the oraInst.loc file has been correctly set. Follow the steps below:
cd /etc
cat oraInst.loc
The oraInst.loc should be set as :

inventory_loc=/IDBO/ker1/oraInventory
inst_group=dbdb
If you have to change the content of oraInst.loc, don't forget to save the information first:
mv oraInst.loc oraInst_XXXX.loc
mv oraInst.loc_IDBO oraInst.loc
Now you need to configure the environment that is necessary for the OEM installation
IDBO Environment Setup
export TEMP=/IDBO/tmp0/tmp
export TMPDIR=/IDBO/tmp0/tmp
export TMP=/IDBO/tmp0/tmp
export TEMPDIR=/IDBO/tmp0/tmp
export ORACLE_HOME=/IDBO/ker1/11.2.0/
export ORACLE_SID="IDBO"
export OMS_HOME=/IDBO/ker3/oem12cMHL/oms
export AGENT_HOME=/IDBO/ker3/oem12cA/core/12.1.0.4.0/
export TNS_ADMIN=/IDBO/ker1/11.2.0/network/admin
export ORACLE_UNQNAME=IDBO
Or run the IDBO environment script

cd /IDBO/ker1/11.2.0/IDBO
vi IDBO_freo1124.env
Then check / edit the listener

cd /IDBO/ker1/11.2.0/network/admin
vi listener.ora
Page | 99

Mmoire dingnieur

===
# listener.ora Network Configuration File:
/IDBO/oem12c/ker1/11.2.0/network/admin/listener.ora
# Generated by Oracle configuration tools.
IDBO =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = freo1124.essilor.fr)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
)
ADR_BASE_EM12 = /IDBO/ker1
===
vi tnsnames.ora
===
IDBO =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = freo1124.essilor.fr)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
)
===
lsnrctl start IDBO

cd /IDBO
mkdir ker3
chmod 775 ker3
cd /oraclestg/soft/linux/OEM/12c14
./runInstaller
Follow the installation instructions as below:

Page | 100

Mmoire dingnieur

Click on Next and confirm your choice by clicking Yes when the warning window appears.

Select Skip and click on Next
Page | 101

Mmoire dingnieur

You can choose to ignore the package warning, but it can be troublesome for the installation.
Click on Next

Select the Create a new Enterprise Manager System > Simpleoptions
Click on Next
Page | 102

Mmoire dingnieur

Middle Home Location: /IDBO/ker3/oem12cMHL
Agent Base directory: /IDBO/ker3/oem12cA
Host Name: freo1124.essilor.fr
Click on Next

Admin PWD = oem12c1234 Database Host Name: FREO1124
Service SID: IDBO Sys PWD = sysoem12c Port: 1521
Page | 103

Mmoire dingnieur

Check Disk Space and click on next if its ok.

Page | 104

Mmoire dingnieur

Youll need to connect as root to execute the script allroot.sh located in:
/IDBO/ker3/oem12cMHL/oms/allroot.sh

The installation finished successfully, just click on Close
Page | 105

Mmoire dingnieur

1. Starting Cloud Control and all Its Components

The following procedure summarizes the steps required to start all the components of the Cloud
Control. For example, use this procedure if you have restarted the host computer and all the
components of the Cloud Control have been installed on that host.
To start all the Cloud Control components on a host, use the following procedure.
If your Oracle Management Repository resides on the host, change directory to the Oracle Home
for the database where you installed the Management Repository and start the database and the
Net Listener for the database:
Set the ORACLE_HOME environment variable to the Management Repository
database home directory.
Set the ORACLE_SID environment variable to the Management Repository database
SID (default is asdb).
Start the Net Listener:
$PROMPT> $ORACLE_HOME/bin/lsnrctl start

Start the Management Repository database instance:
sqlplus /as sysdba ;
SQL> startup
SQL> quit

Start the Oracle Management Service:
$PROMPT> OMS_HOME/bin/emctl start oms
"Controlling the Oracle Management Service"

Change directory to the home directory for the Oracle Management Agent and start the
Management Agent:
$PROMPT> AGENT_HOME/bin/emctl start agent

"Controlling the Oracle Management Agent"
Be sure to run the emctl start agent command in the Oracle Management Agent home directory
and not in the Management Service home directory.

Page | 106

Mmoire dingnieur

2. Stopping Cloud Control and all Its Components
The following procedure summarizes the steps required to stop all the components of the Cloud
Control. For example, use this procedure if you have installed all the components of the Cloud
Control on the same host you want to shut down or restart the host computer.
To stop all the Cloud Control components on a host, use the following procedure :
Stop the Oracle Management Service :
$PROMPT> $ORACLE_HOME/bin/emctl stop oms -all

"Controlling the Oracle Management Service"
Change directory to the home directory for the Oracle Management Agent and stop the
Management Agent:
$PROMPT> AGENT_HOME/bin/emctl stop agent

"Controlling the Oracle Management Agent"
Be sure to run the emctl stop agent command in the Oracle Management Agent home directory
and not in the Oracle Management Service home directory.
If your Oracle Management Repository resides on the same host, change directory to the Oracle
Home for the database where you installed the Management Repository and stop the database
and the Net Listener for the database:
Set the ORACLE_HOME environment variable to the Management Repository
database home directory.
Set the ORACLE_SID environment variable to the Management Repository database
SID (default is asdb).

Stop the database instance:
1. $PROMPT> ORACLE_HOME/bin/sqlplus /nolog
2. SQL> connect SYS as SYSDBA
3. SQL> shutdown
4. SQL> quit

Stop the Net Listener:
$PROMPT> $ORACLE_HOME/bin/lsnrctl stop
Page | 107

Mmoire dingnieur

III. OEM 12c Agent installation & Database Discovery

with Cloud Control

URL OEM 12c sur Freo1124: https://freo1124.essilor.fr:7802/em/
1) Log into the system with the SYSMAN User

You have now access to the Home Page

Page | 108

Mmoire dingnieur

Warning: Before deploying the agent, you need to follow these steps:
Create a orPDBO user ,group dbdb, on the targeted server
Create a filesystem. Example : /PDBO
Create a directory. Example : /PDBO/oem12c
Configure the /etc/oraInst.loc file as following:

=== cat /etc/oraInst.loc
inventory_loc=/PDBO/oraInventory
inst_group=dbdb
===
2) Select the Setup menu and click on Add Target Manually

3) Choose Ass Host Targets and click on Add Host

Page | 109

Mmoire dingnieur

4) Click on the Add Menu and Select Manually as below

5) a) As Host, you need to enter a complete host name.
Example: freo1145 IS NOT CORRECT.
freo1145.essilor.fr IS CORRECT
b) Under the Plateform section, select the Linux x86-64 option
Click on Next

Example of deployment Agent on freo1151:
==========================
Installation Base Directory : /PDBO/oem12c
Instance Directory : (Automatic)
Named Credential: Choose a Sudo user
Privileged Delegation Setting: Do not touch
Port : Do not touch
==========================
Page | 110

Mmoire dingnieur

Click on the Blue Cross
6) Enter the asked information
Example:
UserName : emPDBO
Password: *********
Confirm Password: *********
Run Privilege: None
Check the Save As Box and rename it as you want

7) Before this step, as it has been reminded earlier, you need to:
Create a emPDBO user ,group dbdb, on the targeted server
Create a filesystem. Example : /PDBO
Create a directory. Example : /PDBO/oem12c
Configure the /etc/oraInst.loc file as following:

Page | 111

Mmoire dingnieur

8) You can now deploy the agent by clicking on the Deploy Agent button.

9) An advice will appear. Save this advice and keep it in your system. You will need this to run the
root.sh script later. Then Select the Continue Menu and click on Continue on all hosts
Example: /PDBO/oem12c/core/12.1.0.4.0/root.sh is the location of the root.sh script that you will need to run.

10) Click on the Done button.
Page | 112

Mmoire dingnieur

We will now proceed to the database discovery with the OEM 12c user interface

Click on Enterprise Manager on this upper side on the screen

1) Click on Target, Databases

2) Click on Add, Oracle Database
Page | 113

Mmoire dingnieur

3) Click on the magnifying glass

4) Now you just need to select the host server on which you have deployed the agent. The server
is normally on the list. Then, click on the Select Button.

Page | 114

Mmoire dingnieur

5) Check if you have selected the right host and proceed by clicking on the Select button.

6) You need to configure the Database connection you want to add. To do so, in the view
section, check the box corresponding to the database you are interested in. The Configure
Button will enable. Click on it.

Page | 115

Mmoire dingnieur

You need to enter the following information:
Monitor password:
Port:
You have to check what password and port number to enter
Then, TEST the connection by clicking on the test button

The following message will appear. It means that you have added correctly your database to OEM.

Click on Next
Page | 116

Mmoire dingnieur

Click on Save

Click on Close

Page | 117

Mmoire dingnieur

Starting - Stopping the Agent

1) You need to enter the following exports:

export AGENT_HOME=/IDBO/oem/core/12.1.0.4.0
export ORACLE_HOME=/IDBO/oem/core/12.1.0.4.0

2) Enter the following command line to START the agent:
emctl start agent
Expected answer: Agent is Running and Ready
------------------------------------------------------------
Enter the following command line to STOP the agent:
emctl stop agent
Expected answer: Agent is not Running

3) Check the status the agent:
emctl status agent
Expected answer: Agent is Running and Ready

Page | 118

Mmoire dingnieur

IV Planning prvisionnel

Page | 119

Mmoire dingnieur

Implmentation et exploitation dOracle Enterprise

Manager CC v12c

Lquipe DBA dEssilor France dont je fais partie est charge dadministrer plus dune trentaine de
bases de donnes Oracle. Afin de maintenir nos diffrents environnements informatiques de faon
efficace, nous avons besoin dun logiciel de supervision sophistiqu pouvant la fois dtecter et
signaler rapidement tout comportement anormal de nos bases de donnes. Oracle Enterprise
Manager est la solution logicielle que notre quipe a adopte pour des raisons de fiabilit, de
maintenabilit et flexibilit.
Dans ce mmoire nous exposerons les principales tapes qui nous ont permis de dployer et
dexploiter la nouvelle version dOEM Cloud Control :
Identification des choix darchitectures logiciels les plus adapts Essilor
Identification des prrequis propres la nouvelle version
Installation et configuration de la base de donnes Repository pour OEM 12c
Installation de Cloud Control et de ses fonctionnalits avances
Configuration des mthodes de notification, de seuils dalertes et des rgles dincident

Installing and exploiting Oracle Enterprise Manager CC

v12c

The Essilor DBA team I am part of can be tasked with the administration and management of
hundreds of systems. In order to maintain our databases and to be quickly and efficiently alerted
in the event of a problem, sophisticated tools must be deployed. We have chosen to deploy Oracle
Enterprise Manager Cloud Control 12c to supervise our environment because it is a scalable and
reliable solution that has proven its worth for almost ten years from now.
This memoire will explain how to install and take advantage of the features of OEM Cloud Control
12c. In order to achieve this purpose, the following tasks had to be performed:
Identification of the CC components topology that suits the best to the Essilor system
environments
Identification of Cloud Control special prerequisites
Installation and configuration of the Repository database for OEM 12c
Installation of Cloud Control along with its advanced functionalities
Configuration of notification methods, alert thresholds and incident rules
Page | 120

AlexandreLabrousse OEM12c

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

AlexandreLabrousse OEM12c

Загружено:

Авторское право:

Доступные форматы

Alexandre Labrousse

Ingnieur Informatique en Apprentissage

Dploiement et Exploitation dOracle

Dploiement et Exploitation dOracle

Table des matires

Liste des figures

Liste des tableaux

Table des sigles et abrviations

I.1 Prsentation de lentreprise

I.2 Prsentation du dpartement

I.3 Prsentation du poste

I.4 Prsentation de la mission

II.1 Expression du besoin

II.1.1 Note de cadrage

II.1.1.3 Objectifs atteindre

II.2 Etude davant-projet

II.2.1 Prsentation du produit

II.2.2 Architecture technique dOEM Cloud Control

II.2.2.1 Installation et architecture du logiciel OMS

II.2.2.2 Installation de la base de donnes dpt

II.2.2.3 Prrequis de linstallation dOracle Cloud Control 12c

II.2.2.4 Diffrences concernant WLS

II.3 Cahier des charges

II.3.1 Les contraintes

II.3.2 Critres de satisfaction

II.3.3 Dtail des versions logicielles dployes

II.3.4 Budget & Dlais

II.3.5 Cahier des charges fonctionnel

II.4 Etude de faisabilit

II.4.1 Etude Rseaux

Connexion entre les lments Bande Passante Latence

II.4.2 Ressources alloues

II.4.2.1 Ressources matrielles et logicielles

II.4.2.2 Ressources humaines : les acteurs

II.4.3 Les risques et les impacts

II.4.3.1 Les risques associs

II.4.3.2 Les impacts associs

III La solution Oracle Enterprise Manager Cloud

III.1 Analyse de larchitecture dOEM

III.1.1 Cloud Control Console

III.1.2 Oracle Management Agent

III.1.3 Gestion et dcouverte des cibles supervises

III.1.4 Oracle Management Service

III.1.5 Oracle Management Repository

III.1.6 Flux de donnes

III.2 Les choix dimplmentation dOEM Cloud Control 12c

III.2.1 Dfinition du nombre denvironnements Cloud Control mis en uvre

III.2.2 Environnement de production Vs Environnement de non-production

III.2.4 Dcision concernant sur le choix darchitecture de la base de donnes

III.2.5 Dcision concernant le choix darchitecture dOracle Management

III.2.6 Dcision concernant le choix de regroupement du serveur OMS et de la

IV.1.1 Installation dune base de donnes Repository

IV.1.2 Etape 1 : Installation du logiciel Grid Infrastructure (facultative)

IV.1.3 Etape 2 : Installation du logiciel de base de donnes

IV.1.3.2 Modle Enterprise Manager DBCA

IV.1.3.3 Configuration de la base dpt avec EM template

IV.1.3.4 Paramtres dinitialisation

IV.2 Configuration de la base de donnes Repository

IV.2.1 Renommage des fichiers de donnes Cloud Control

IV.2.2 Dsactivation de loptimisateur de rcupration automatique des

IV.2.3 Cration de groupes de redo logs additionnels

Implmentation des HugePages

HugePage non configure HugePage configure chez Essilor