D50102FR20 sg1

Oracle University and OMNIDATA.
use only
Oracle Database 11g :
Administration Workshop I
Manuel du stagiaire - Volume I
D50102FR20
Edition 2.0
Mai 2010
D65638
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS
COMPUTER IS STRICTLY PROHIBITED
Auteurs Copyright © 2009, Oracle. Tous droits réservés.
Deirdre Matishak Avertissement
Mark Fuller Cette documentation contient des informations qui sont la propriété d'Oracle
Corporation et sont protégées par les lois relatives aux droits d'auteur et à la propriété
intellectuelle. Vous ne pouvez copier et imprimer ce document qu'à des fins
Révisions et d'utilisation personnelle lors de la participation à une formation dispensée par Oracle.
contributions techniques Le document ne peut être modifié ou altéré en aucune manière. A l'exception des cas
où l'utilisation faite du document s'inscrit dans le respect des lois relatives aux droits
Maria Billings d'auteur, vous ne pouvez pas utiliser, partager, télécharger, copier, imprimer, afficher,
Herbert Bradbury exécuter, reproduire, publier, breveter, diffuser, transmettre ou distribuer ce
document, en partie ou en totalité, sans l'autorisation expresse d'Oracle.
Yanti Chang
Les informations fournies dans ce document sont susceptibles de modification sans
Timothy Chien préavis. Par ailleurs, Oracle Corporation ne garantit pas qu'elles soient exemptes
Andy Fotunak d'erreurs et vous invite, le cas échéant, à lui en faire part par écrit à l'adresse
suivante : Oracle University, 500 Oracle Parkway, Redwood Shores, California 94065
Gerlinde Frenzen USA.
Steve Friedberg
Restrictions applicables au gouvernement américain :
Joel Goodman Restricted Rights Notice
Oracle University and OMNIDATA. use only

Vimala Jacob If this documentation is delivered to the United States Government or anyone using
Dominique Jeunot the documentation on behalf of the United States Government, the following notice is
applicable:
Pete Jones
Fukue Kawabe U.S. GOVERNMENT RIGHTS
The U.S. Government’s rights to use, modify, reproduce, release, perform, display, or
Donna Keesling disclose these training materials are restricted by the terms of the applicable Oracle
Sean Kim license agreement and/or the applicable U.S. Government contract.
Achiel Langers Marques

Gwen Lazenby Oracle est une marque déposée d'Oracle Corporation et/ou de ses filiales. Tout autre
Essi Parast nom de produit ou de société peut être une marque de son propriétaire.
Randy Richeson
Joe Roch
Hilda Simon
Ira Singer
James Spiller
Supithran Thananayagam
Branislav Valny
Manju Varrier
Rédacteurs
Raj Kumar
Daniel Milne
Concepteur graphique
Rajiv Chandrabhanu
Editeurs
Jobi Varghese
Veena Narasimhan
Table des matières
Préface
I Introduction
Objectifs du cours I-2
Planning recommandé I-3
Produits et services Oracle I-4
Oracle Database 11g : "g" signifie "grid" I-5
Grid Infrastructure for Single-Instance I-7

1 Architecture d'une base de données Oracle
Objectifs 1-2
Base de données Oracle 1-3
Se connecter à un serveur 1-4
Architecture d'un serveur de base de données Oracle : Présentation 1-6
Instance : Configurations de base de données 1-7
Connexion à une instance de base de données 1-8
Structures mémoire d'une base de données Oracle 1-9
Zone de mémoire partagée 1-11
Cache de tampons de la base de données 1-13
Tampon de journalisation 1-14
Zone de mémoire LARGE POOL 1-15
Zones de mémoire Java et Streams 1-16
Mémoire PGA (Program Global Area) 1-17
Quiz 1-18
Architecture des processus 1-20
Structure des processus 1-21
Processus DBWn (Database Writer) 1-23
Processus LGWR (Log Writer) 1-25
Processus CKPT (Checkpoint) 1-27
Processus SMON (System Monitor) 1-28
Processus PMON (Process Monitor) 1-29
Processus RECO (Recoverer) 1-30
Processus ARCn (Archiver) 1-31
Séquence de démarrage des processus 1-32
Architecture de stockage de la base de données 1-33
Structures logiques et physiques d'une base de données 1-35
iii
Segments, extents et blocs 1-37
Tablespaces et fichiers de données 1-38
Tablespaces SYSTEM et SYSAUX 1-39
Automatic Storage Management (ASM) 1-40
Composants de stockage ASM 1-41
Interagir avec une base Oracle : Mémoire, processus et stockage 1-42
Quiz 1-44
Synthèse 1-46
Exercice 1 : Présentation 1-47
2 Installer le logiciel Oracle

Objectifs 2-2

Tâches d'un administrateur de base de données Oracle 2-3
Outils utilisés pour administrer une base de données Oracle 2-4
Planifier l'installation 2-6
Installation d'Oracle Grid Infrastructure et d'Oracle Database : Configuration système
requise 2-8
Préparer le système d'exploitation 2-9
Définir les variables d'environnement 2-10
Vérifier la configuration système requise 2-11
Oracle Universal Installer (OUI) 2-12
Exemple de scénario d'installation 2-13
Partie 1 : Installer Oracle Grid Infrastructure pour un serveur autonome 2-14
Sélectionner les langues du produit 2-15
Créer un groupe de disques ASM 2-16
Définir les mots de passe ASM 2-17
Définir les groupes du système d'exploitation dotés de privilèges 2-18
Indiquer l'emplacement d'installation 2-19
Créer l'inventaire 2-20
Effectuer les vérifications de prérequis 2-21
Vérifier les données récapitulatives de l'installation 2-22
Surveiller la progression de l'installation 2-23
Exécuter les scripts de configuration root 2-24
Exécuter les assistants de configuration 2-25
Terminer l'installation 2-26
Configurer le groupe de disques FRA 2-27
Quiz 2-28
Partie 2 : Installer le logiciel Oracle Database 2-30
Choisir un type d'installation 2-31
Choisir les options d'installation de Grid Infrastructure 2-32
Choisir les paramètres de langue 2-33
iv
Choisir l'édition de la base de données 2-34
Indiquer l'emplacement d'installation 2-35
Choisir des groupes du système d'exploitation 2-36
Effectuer les vérifications de prérequis 2-37
Page récapitulative de l'installation 2-38
Page Install Product 2-39
Installation terminée 2-40
Option d'installation : Mode automatique 2-41
Quiz 2-42
Synthèse 2-44
Présentation de l'exercice 2 : Préparer l'environnement de base
de données 2-45

3 Créer une base de données Oracle à l'aide de DBCA
Objectifs 3-2
Planification de la base de données 3-3
Bases de données : Exemples 3-4
Choisir le jeu de caractères approprié 3-5
Utilisation des jeux de caractères 3-7
Problèmes à éviter 3-8
Assistant DBCA 3-9
Utiliser DBCA pour créer une base de données 3-10
Récapitulatif de la base de données à créer 3-16
Gestion des mots de passe 3-17
Créer un modèle de conception de base de données 3-18
Utiliser DBCA pour supprimer une base de données 3-19
Autres tâches effectuées via l'assistant DBCA 3-21
Quiz 3-22
Synthèse 3-24
Présentation de l'exercice 3 : Utiliser l'assistant DBCA 3-25
4 Gérer l'instance de base de données

Objectifs 4-2
Structure de gestion 4-3
Démarrer et arrêter Database Control 4-4
Oracle Enterprise Manager 4-5
Page d'accueil de la base de données 4-7
Autres outils Oracle 4-8
Utiliser SQL*Plus 4-9
Appeler SQL*Plus à partir d'un script shell 4-10
Appeler un script SQL à partir de SQL*Plus 4-11
Fichiers de paramètres d'initialisation 4-12
Paramètres d'initialisation simplifiés 4-14
Paramètres d'initialisation : Exemples 4-15
Paramètres d'initialisation : Exemples 4-16
Utiliser SQL*Plus pour afficher les paramètres 4-19
Modifier les valeurs des paramètres d'initialisation 4-21
Modifier les valeurs des paramètres : Exemples 4-23
Quiz 4-24
Démarrage et arrêt de la base de données : Informations d'identification et
de connexion 4-26
Démarrer une instance de base de données Oracle 4-27
Démarrer une instance de base de données Oracle : NOMOUNT 4-28

Démarrer une instance de base de données Oracle : MOUNT 4-29
Démarrer une instance de base de données Oracle : OPEN 4-30
Options de démarrage : Exemples 4-31
Arrêter une instance de base de données Oracle 4-32
Modes d'arrêt 4-33
Options d'arrêt 4-34
Options d'arrêt : Exemples 4-37
Afficher le fichier d'alertes 4-38
Utiliser les fichiers trace 4-40
Vues dynamiques des performances 4-42
Vues dynamiques des performances : Exemples d'utilisation 4-43
Vues dynamiques des performances : Remarques 4-44
Dictionnaire de données : Présentation 4-45
Vues du dictionnaire de données 4-46
Dictionnaire de données : Exemples d'utilisation 4-48
Quiz 4-49
Synthèse 4-51
Présentation de l'exercice 4 : Gérer l'instance Oracle 4-52
5 Gérer l'instance ASM

Objectifs 5-2
Avantages d'ASM pour les administrateurs 5-3
Instance ASM 5-4
Composants d'une instance ASM : Processus principaux 5-6
Paramètres d'initialisation d'une instance ASM 5-7
Interaction entre les instances de base de données et ASM 5-9
Instance ASM : Vues dynamiques des performances 5-10
Privilèges système ASM 5-11
vi
Utiliser Enterprise Manager pour gérer les utilisateurs ASM 5-12
Démarrer et arrêter des instances ASM à l'aide de SQL*Plus 5-13
Démarrer et arrêter des instances ASM à l'aide de srvctl 5-15
Démarrer et arrêter des instances ASM à l'aide de l'utilitaire asmcmd 5-16
Présentation des groupes de disques 5-17
Disques ASM 5-18
Unités d'allocation 5-19
Fichiers ASM 5-20
Topographie des extents 5-21
Niveau de détail du striping 5-22
Striping fin 5-23
Groupes d'échec ASM 5-25

Striping et mise en miroir : Exemple 5-26
Exemple de panne de disque 5-27
Gérer les groupes de disques 5-28
Créer et supprimer des groupes de disques à l'aide de SQL*Plus 5-29
Ajouter des disques à un groupe 5-30
Commandes ALTER 5-31
Gérer ASM à l'aide d'Enterprise Manager 5-32
Compatibilité des groupes de disques ASM 5-33
Attributs des groupes de disques ASM 5-35
Modifier les attributs des groupes de disques à l'aide d'Enterprise Manager 5-36
Extraire des métadonnées ASM 5-37
Présentation de la fonctionnalité ASM Fast Mirror Resync 5-38
Quiz 5-39
Synthèse 5-41
Présentation de l'exercice 5 : Gérer l'instance ASM 5-42
6 Configurer l'environnement réseau Oracle

Objectifs 6-2
Services Oracle Net 6-3
Processus d'écoute Oracle Net 6-4
Etablir des connexions réseau 6-5
Etablir une connexion 6-6
Sessions utilisateur 6-7
Outils de configuration et de gestion de l'environnement réseau Oracle 6-8
Utilitaire de contrôle des processus d'écoute 6-10
Syntaxe de l'utilitaire de contrôle de processus d'écoute 6-11
Utiliser SRVCTL pour démarrer et arrêter le processus d'écoute 6-13
Page d'accueil du processus d'écoute 6-14
vii
Page Net Services Administration 6-15
Créer un processus d'écoute 6-16
Ajouter des adresses de processus d'écoute 6-17
Enregistrement d'un service de base de données 6-18
Méthodes de résolution de noms 6-20
Easy Connect 6-21
Résolution locale de noms 6-22
Résolution de noms d'annuaire 6-23
Méthode de résolution de noms externe 6-24
Configurer des alias de service 6-25
Options de connexion avancées 6-26
Tester la connectivité Oracle Net 6-28

Sessions utilisateur : Processus serveur dédiés 6-29
Sessions utilisateur : Processus serveur partagés 6-30
Mémoire SGA et mémoire PGA 6-31
Serveur partagé : Concentration des connexions 6-32
Dans quels cas ne pas utiliser de serveur partagé ? 6-33
Configurer la communication entre bases de données 6-34
Se connecter à une autre base de données 6-35
Quiz 6-36
Synthèse 6-38
Présentation de l'exercice 6 : Utiliser les composants réseau Oracle 6-39
7 Gérer les structures de stockage de base de données

Objectifs 7-2
Mode de stockage des données d'une table 7-3
Bloc de base de données : Contenu 7-4
Explorer la structure de stockage 7-5
Créer un tablespace 7-6
Stockage des tablespaces 7-8
Tablespaces de la base de données préconfigurée 7-10
Modifier un tablespace 7-12
Actions sur les tablespaces 7-14
Supprimer des tablespaces 7-16
Afficher les informations relatives aux tablespaces 7-17
Afficher le contenu d'un tablespace 7-18
Oracle-Managed Files (OMF) 7-19
Etendre la base de données 7-21
Quiz 7-22
Synthèse 7-24
Présentation de l'exercice 7 : Gérer les structures de stockage d'une base
viii
de données 7-25
8 Administrer la sécurité utilisateur

Objectifs 8-2
Comptes utilisateur de base de données 8-3
Comptes d'administration prédéfinis 8-5
Créer un utilisateur 8-6
Authentification des utilisateurs 8-7
Authentification des administrateurs 8-9
Déverrouiller un compte utilisateur et redéfinir le mot de passe 8-11
Privilèges 8-12

Privilèges système 8-13
Privilèges objet 8-15
Révoquer des privilèges système accordés avec ADMIN OPTION 8-16
Révoquer des privilèges objet accordés avec GRANT OPTION 8-17
Avantages des rôles 8-18
Affecter des privilèges à des rôles et des rôles à des utilisateurs 8-19
Rôles prédéfinis 8-20
Créer un rôle 8-21
Rôles sécurisés 8-22
Affecter des rôles aux utilisateurs 8-23
Quiz 8-24
Profils et utilisateurs 8-26
Implémenter des fonctionnalités de sécurité utilisant des mots de passe 8-28
Créer un profil de mot de passe 8-30
Fonction prédéfinie de vérification des mots de passe :
VERIFY_FUNCTION_11G 8-31
Affecter des quotas aux utilisateurs 8-32
Appliquer le principe du moindre privilège 8-34
Protéger les comptes dotés de privilèges 8-36
Quiz 8-37
Synthèse 8-39
Présentation de l'exercice 8 : Administrer les utilisateurs 8-40
9 Gérer les accès simultanés aux données

Objectifs 9-2
Verrous externes 9-3
Mécanisme de verrouillage 9-4
Simultanéité d'accès aux données 9-5
ix
Verrous LMD 9-7
Mécanisme de mise en file d'attente 9-8
Conflits de verrouillage 9-9
Causes possibles des conflits de verrouillage 9-10
Détecter les conflits de verrouillage 9-11
Résoudre les conflits de verrouillage 9-12
Résoudre les conflits de verrouillage à l'aide d'instructions SQL 9-13
"Verrous mortels" 9-14
Quiz 9-15
Synthèse 9-17
Présentation de l'exercice 9 : Gérer les données et la simultanéité d'accès
aux données 9-18

10 Gérer les données d'annulation
Objectifs 10-2
Données d'annulation 10-3
Transactions et données d'annulation 10-5
Stockage des informations d'annulation 10-6
Données d'annulation et données de journalisation 10-7
Gérer les informations d'annulation 10-8
Configurer la période de conservation des informations d'annulation 10-9
Garantir la période de conservation des informations d'annulation 10-11
Passer à un tablespace d'annulation de taille fixe 10-12
Gestion des annulations : Informations générales 10-13
Utiliser Undo Advisor 10-14
Afficher l'activité du système 10-15
Quiz 10-16
Synthèse 10-18
Présentation de l'exercice 10 : Gérer les segments d'annulation 10-19
11 Implémenter l'audit de la base de données Oracle

Objectifs 11-2
Séparation des responsabilités 11-3
Sécurité de la base de données 11-4
Surveiller la conformité aux règles de sécurité 11-6
Audit de base de données standard 11-7
Configurer la trace d'audit 11-8
Traces d'audit uniformes 11-9
Définir les options d'audit 11-10
Audit par défaut 11-11
Page Audit Settings d'Enterprise Manager 11-12
Utiliser et gérer les informations d'audit 11-13
Audit basé sur les données 11-14
Audit détaillé 11-16
Stratégie d'audit détaillé 11-17
Instruction LMD auditée : Eléments à prendre en compte 11-19
Règles relatives à l'audit détaillé 11-20
Audit des activités de SYSDBA 11-21
Gérer la trace d'audit 11-22
Oracle Audit Vault 11-23
Quiz 11-24
Synthèse 11-26
Présentation de l'exercice 11 : Implémenter la sécurité de la base

de données Oracle 11-27
12 Maintenance de la base de données

Objectifs 12-2
Maintenance de la base de données 12-3
Afficher l'historique des alertes 12-4
Terminologie 12-5
Présentation de l'optimiseur Oracle 12-6
Statistiques destinées à l'optimiseur 12-7
Utiliser la page Manage Optimizer Statistics 12-8
Collecter manuellement les statistiques destinées à l'optimiseur 12-9
Préférences relatives à la collecte des statistiques 12-11
Référentiel AWR 12-13
Infrastructure du référentiel AWR 12-14
Lignes de base AWR 12-15
Enterprise Manager et référentiel AWR 12-16
Gérer le référentiel AWR 12-17
Niveaux de statistiques 12-18
Moniteur ADDM 12-19
Résultats ADDM 12-20
Recommandations ADDM 12-21
Infrastructure de conseil 12-22
Enterprise Manager et les fonctions de conseil 12-24
Package DBMS_ADVISOR 12-25
Quiz 12-26
Tâches de maintenance automatisées 12-27
Configuration des tâches de maintenance automatisées 12-29
Alertes générées par le serveur 12-30
Définir des seuils 12-31
xi
Créer et tester une alerte 12-32
Notification des alertes 12-33
Réagir aux alertes 12-35
Types d'alerte et effacement des alertes 12-36
Quiz 12-37
Synthèse 12-38
Présentation de l'exercice 12 : Maintenance proactive 12-39
13 Gestion des performances

Objectifs 13-2
Surveiller les performances 13-3
Page Performance d'Enterprise Manager 13-4

Analyser une catégorie particulière d'événements Wait 13-5
Page Performance : Onglet Throughput 13-6
Surveiller les performances : Option Top Sessions 13-7
Surveiller les performances : Option Top Services 13-8
Gérer les composants de mémoire 13-9
Activer la gestion automatique de la mémoire (AMM) 13-10
Activer la gestion automatique de la mémoire partagée (ASMM) 13-11
Fonction de conseil ASMM 13-12
Statistiques dynamiques des performances 13-13
Vues de résolution des problèmes et de réglage 13-15
Objets non valides et inutilisables 13-16
Quiz 13-18
Synthèse 13-20
Présentation de l'exercice 13 : Surveiller et optimiser les performances 13-21
14 Concepts de sauvegarde et de récupération

Objectifs 14-2
Missions du DBA 14-3
Catégories de pannes 14-5
Echec d'une instruction 14-6
Echec d'un processus utilisateur 14-7
Défaillance réseau 14-8
Erreur utilisateur 14-9
Technologie Flashback 14-10
Echec d'une instance 14-12
Récupération d'instance : Processus de point de reprise (CKPT) 14-13
Récupération d'instance : Fichiers de journalisation et processus Log Writer 14-15
Comprendre la récupération d'instance 14-16
Phases de la récupération d'instance 14-17
xii
Régler la récupération d'instance 14-18
Utiliser MTTR Advisor 14-19
Défaillance physique 14-20
Configurer la base de données afin d'optimiser la possibilité
de récupération 14-21
Configurer la zone de récupération rapide 14-23
Multiplexer les fichiers de contrôle 14-24
Fichiers de journalisation 14-26
Multiplexer le fichier de journalisation 14-27
Fichiers de journalisation archivés 14-28
Processus d'archivage (ARCn) 14-29
Fichier de journalisation archivé : Appellation et destinations 14-30

Activer le mode ARCHIVELOG 14-31
Quiz 14-32
Synthèse 14-34
Présentation de l'exercice 14 : Configurer la base de données afin d'optimiser
la capacité de récupération 14-35
15 Effectuer des sauvegardes de la basede données

Objectifs 15-2
Solutions de sauvegarde : Présentation 15-3
Oracle Secure Backup 15-4
Sauvegarde gérée par l'utilisateur 15-5
Terminologie 15-6
Recovery Manager (RMAN) 15-8
Configurer les paramètres de sauvegarde 15-9
Planifier des sauvegardes : Stratégie 15-11
Planifier des sauvegardes : Options 15-12
Planifier des sauvegardes : Paramètres 15-13
Planifier des sauvegardes : Planification 15-14
Planifier des sauvegardes : Récapitulatif 15-15
Sauvegarder le fichier de contrôle dans un fichier trace 15-16
Gérer les sauvegardes 15-17
Afficher les états de sauvegarde 15-18
Surveiller la zone de récupération rapide 15-19
Utiliser la ligne de commande RMAN 15-20
Quiz 15-21
Synthèse 15-22
Présentation de l'exercice 15 : Créer des sauvegardes de la base
de données 15-23
xiii
16 Procéder à une récupération de la base de données
Objectifs 16-2
Ouvrir une base de données 16-3
Maintenir une base de données ouverte 16-5
Data Recovery Advisor 16-6
Perte d'un fichier de contrôle 16-8
Perte d'un fichier de journalisation 16-9
Perte d'un fichier de données en mode NOARCHIVELOG 16-11
Perte d'un fichier de données non essentiel en mode ARCHIVELOG 16-12
Perte d'un fichier de données essentiel pour le système en mode
ARCHIVELOG 16-13
Défaillances de données : Exemples 16-14

Data Recovery Advisor 16-15
Evaluer les défaillances 16-16
Défaillances de données 16-17
Afficher la liste des défaillances de données 16-18
Obtenir un conseil de réparation 16-19
Exécuter les réparations 16-20
Vues de la fonction de conseil Data Recovery Advisor 16-21
Quiz 16-22
Synthèse 16-24
Présentation de l'exercice 16 : Procéder à une récupération de la base
de données 16-25
17 Déplacer des données

Objectifs 17-2
Déplacer des données : Architecture générale 17-3
Oracle Data Pump : Présentation 17-4
Oracle Data Pump : Avantages 17-5
Objets répertoire pour Data Pump 17-7
Créer des objets répertoire 17-8
Clients Data Pump Export et Data Pump Import : Présentation 17-9
Utilitaire Data Pump : Interfaces et modes 17-10
Procédure d'export Data Pump à l'aide de Database Control 17-11
Exemple d'export Data Pump : Options de base 17-12
Exemple d'export Data Pump : Options avancées 17-13
Exemple d'export Data Pump : Fichiers 17-14
Exemple d'export Data Pump : Planification 17-16
Exemple d'export Data Pump : Récapitulatif 17-17
Exemple d'import Data Pump : impdp 17-18
xiv
Data Pump Import : Transformations 17-19
Utiliser Enterprise Manager pour surveiller les travaux Data Pump 17-20
Migration à l'aide du mode propriétaire de Data Pump 17-21
Mode propriétaire de Data Pump 17-22
Gérer les emplacements de fichier 17-24
SQL*Loader : Présentation 17-25
Charger des données avec SQL*Loader 17-27
Fichier de contrôle SQL*Loader 17-28
Méthodes de chargement 17-30
Tables externes 17-31
Avantages des tables externes 17-32
Définir une table externe avec ORACLE_LOADER 17-33

Remplissage d'une table externe avec ORACLE_DATAPUMP 17-34
Utiliser des tables externes 17-35
Dictionnaire de données 17-36
Quiz 17-37
Synthèse 17-39
Présentation de l'exercice 17 : Déplacer des données 17-40
18 Utiliser le support technique

Objectifs 18-2
Utiliser l'outil Support Workbench 18-3
Afficher les alertes d'erreur critique dans Enterprise Manager 18-4
Afficher des détails sur les problèmes 18-5
Afficher des détails sur les incidents : Fichiers dump 18-6
Afficher des détails sur les incidents : Résultats des vérifications 18-7
Créer une "Service Request" (SR) 18-8
Préparer les données de diagnostic et les envoyer au support
technique Oracle 18-9
Effectuer le suivi de la "Service Request" (SR) et implémenter les solutions 18-10
Fermer des incidents et des problèmes 18-12
Configuration du packaging des incidents 18-13
Support Workbench pour Oracle ASM 18-14
Utiliser le support technique Oracle 18-15
Intégration de My Oracle Support 18-16
Utiliser My Oracle Support 18-17
Rechercher des informations sur un problème 18-19
Soumettre une "Service Request" (SR) 18-21
Gérer les patches 18-23
Appliquer un patch logiciel 18-24
Utiliser Patch Advisor 18-25
xv
Utiliser l'assistant pour patches 18-26
Appliquer un patch 18-27
Mettre un patch en zone de stockage temporaire 18-28
Application à chaud de patches : Présentation 18-29
Installer à chaud un patch en ligne 18-30
Avantages de l'application à chaud de patches 18-31
Patches conventionnels et patches en ligne 18-32
Considérations relatives aux patches en ligne 18-33
Quiz 18-35
Synthèse 18-36
Présentation de l'exercice 18 : Utiliser les outils EM pour les alertes et
les patches 18-37

Annexe A: Exercices et solutions
Annexe B: Commandes de base de Linux et vi
Annexe C: Syntaxe des instructions SQL
Annexe D: Processus Oracle en arrière-plan
Annexe E: Acronymes and termes
F Oracle Restart
Objectifs F-2
Oracle Restart F-3
Démarrage des processus Oracle Restart F-5
Contrôler Oracle Restart F-6
Choisir l'utilitaire SRVCTL approprié F-8
Configuration Oracle Restart F-9
Utiliser SRVCTL F-10
Obtenir de l'aide sur l'utilitaire SRVCTL F-11
Démarrer des composants à l'aide de SRVCTL F-12
Arrêter des composants à l'aide de SRVCTL F-13
Afficher le statut des composants F-14
Afficher la configuration Oracle Restart d'un composant F-15
Ajouter manuellement des composants à la configuration Oracle Restart F-16
Quiz F-17
Synthèse F-18
G Suite de la formation et autres lectures conseillées
xvi
Que faire maintenant ? G-2
Ressources de formation G-3
Oracle University G-4
Poursuivre la formation G-5
Domaines spécialisés en matière de base de données G-6
Oracle Real Application Clusters G-7
Oracle Data Guard G-8
Présentation d'Oracle Streams G-9
Oracle Technology Network G-11
Sécurité G-12
Oracle by Example G-13
Oracle Magazine G-14

Communauté Oracle Applications G-15
Site de support technique My Oracle Support G-16
Page relative au produit Oracle Database G-17
Remerciements G-18
xvii
Introduction

Copyright © 2009, Oracle. Tous droits réservés.
Objectifs du cours
A la fin de ce cours, vous pourrez :

• installer, créer et administrer Oracle Database 11g Release 2
• configurer la base de données pour une application
• utiliser les procédures élémentaires de contrôle
• implémenter une stratégie de sauvegarde et de récupération
• déplacer des données entre des bases et des fichiers

Objectifs du cours
Dans ce cours, vous allez installer le logiciel Oracle Database 11g Release 2 Enterprise
Edition, créer une base de données et apprendre à administrer celle-ci.
Vous allez également configurer la base pour la prise en charge d'une application, et effectuer
des opérations telles que la création d'utilisateurs, la définition de structures de stockage et la
configuration de la sécurité. Ce cours utilise une application fictive sur laquelle vous
effectuerez toutes les tâches fondamentales nécessaires à une application réelle.
L'administration d'une base de données ne se limite pas à sa seule configuration. Vous devez
également apprendre à protéger la base en élaborant une stratégie de sauvegarde et de
récupération, et à la surveiller pour vous assurer de son bon fonctionnement.
Oracle Database 11g : Administration Workshop I - 2

Planning recommandé
Jour Chapitres Jour Chapitres
1 1. Examiner l'architecture de la base 3 9. Gérer les accès simultanés aux

de données Oracle données
2. Préparer l'environnement de la base 10. Gérer les données d'annulation
de données 11. Implémenter l'audit de la base de
3. Créer une base de données Oracle données Oracle
4. Administrer des instances de base
de données 4 12. Maintenance de la base de données
13. Gestion des performances
2 5. Administrer des instances ASM 14. Concepts de sauvegarde et de
6. Configurer l'environnement réseau récupération

Oracle
7. Gérer les structures de stockage 5 15. Procéder à des sauvegardes de la
de base de données base de données
8. Administrer la sécurité utilisateur 16. Procéder à une récupération de la
base de données
17. Déplacer des données
18. Utiliser le support technique

Produits et services Oracle
• Oracle Database
• Oracle WebLogic Application Server
• Oracle Applications
• Oracle Collaboration Suite
• Oracle Developer Suite
• Oracle Services

Produits et services Oracle

• Oracle Database : La base de données Oracle est la première base de données conçue
pour le grid computing (calcul distribué) d'entreprise, qui est le moyen le plus flexible et
le moins coûteux pour gérer les informations et les applications.
• Oracle WebLogic Application Server : Le serveur Oracle certifié J2EE (Java 2
Enterprise Edition) intègre tous les éléments nécessaires au développement et au
déploiement des applications basées sur le Web. Le serveur d'applications déploie les
portails e-business, les services Web et les applications transactionnelles, telles que les
applications PL/SQL, Oracle Forms et Java EE.
• Oracle Applications : Oracle E-Business Suite est un ensemble complet d'applications
métier pour la gestion et l'automatisation des processus au sein d'une organisation.
• Oracle Collaboration Suite : Oracle Collaboration Suite est un système intégré unique
pour toutes les données de communication d'une organisation (voix, email, fax, sans fil,
informations calendaires et fichiers).
• Oracle Developer Suite : Oracle Developer Suite est un environnement complet et
intégré qui associe des outils de développement d'applications et des outils décisionnels.
• Oracle Services : Les services tels qu'Oracle Consulting et Oracle University fournissent
l'expertise dont vous avez besoin pour vos projets Oracle. Pour obtenir des liens d'accès à
différentes ressources utiles, reportez-vous à l'annexe intitulée "Etapes suivantes :
Poursuivre la formation".

Oracle Database 11g :
"g" signifie "grid"
• Open Grid Forum (OGF)
• Infrastructure de grid d'Oracle :
– Coût faible
– Qualité de service élevée
– Facilité de gestion
Grid de Grid de base Grid Grid

stockage de données d'application Control

Automatic Real Application Enterprise
Storage Application Server Manager
Management Clusters Clusters Grid Control
Oracle Database 11g : "g" signifie "grid"

Open Grid Forum (OGF) est un organisme de normalisation dans le domaine du grid
computing (calcul distribué). Il comprend un ensemble de comités et de groupes de travail qui
s'attachent à différents aspects du grid computing. Ces comités et groupes de travail sont
composés d'universitaires, de chercheurs et (de plus en plus) de sociétés commerciales. Vous
pouvez vous rendre sur le site Web de l'OGF, à l'adresse suivante : http://www.ogf.org.
Oracle a développé un logiciel d'infrastructure de grid computing capable d'équilibrer tous les
types de charge globale entre différents serveurs, ces derniers pouvant ainsi être gérés comme
un même système complet. Le grid computing peut offrir le même niveau élevé de fiabilité
que les systèmes utilisant des mainframes, car tous les composants sont clusterisés.
Cependant, contrairement aux mainframes et aux gros serveurs SMP (multitraitement
symétrique) UNIX, un grid peut être construit à l'aide de technologies de systèmes ouverts,
telles que les processeurs Intel et le système d'exploitation Linux, et ce à un coût très réduit.
La technologie de grid computing d'Oracle comprend les éléments suivants :
• Automatic Storage Management (ASM)
• Real Application Clusters (RAC)
• Application Server Clusters
• Enterprise Manager Grid Control

Oracle Database 11g : "g" signifie "grid" (suite)
Automatic Storage Management (ASM) propage les données de la base sur tous les disques, crée et
gère un grid de stockage, et fournit un débit d'E/S optimal pour un coût de gestion minimal. Lors de
l'ajout ou de la suppression de disques, ASM redistribue automatiquement les données. (Il est inutile
d'utiliser un gestionnaire de volumes logiques pour gérer le système de fichiers.) La disponibilité des
données augmente avec la fonction de mise en miroir facultative, et vous pouvez ajouter ou
supprimer des disques en ligne. Pour plus d'informations, reportez-vous au chapitre intitulé "Gérer les
structures de stockage de la base de données".
L'application Real Application Clusters (RAC) d'Oracle exécute et répartit toutes les charges
globales d'application sur un cluster de serveurs. Elle offre également les fonctionnalités suivantes :
• Clusterware intégré : Il inclut notamment les fonctions de connectivité des clusters, d'envoi de
messages et de verrouillage, de contrôle des clusters et de récupération. Cette fonctionnalité est
disponible sur toutes les plates-formes prises en charge par Oracle Database 10g et les versions
ultérieures.

• Gestion automatique de la charge globale : Vous pouvez définir des règles afin d'allouer
automatiquement des ressources de traitement à chaque service, à la fois au cours des opérations
standard et en réponse à des échecs. Ces règles peuvent être modifiées de manière dynamique
afin de répondre à des besoins métier en constante évolution. Cette fonction d'allocation de
ressources dynamique au sein d'un grid de base de données est propre à Oracle RAC.
• Notification automatique des événements auprès du niveau intermédiaire (middle tier) : Le
niveau intermédiaire peut s'adapter immédiatement à la défaillance d'une instance ou à la mise à
disposition d'une nouvelle instance. Ainsi, lorsqu'un incident survient dans une instance, les
utilisateurs peuvent poursuivre leurs tâches, sans avoir à subir les délais d'attente réseau
habituels. Lorsqu'une nouvelle instance est disponible, le niveau intermédiaire assure
immédiatement le rééquilibrage des connexions. Les pilotes JDBC (Java Database Connectivity)
d'Oracle Database 10g et des versions ultérieures sont dotés de la fonction FCF (Fast Connection
Failover) qui peut être activée automatiquement afin de gérer ce type d'événement.
Oracle WebLogic Application Grid est compatible avec tous les serveurs d'applications, y compris
Oracle WebLogic Server, IBM WebSphere Application Server et JBoss Application Server, mais il
peut aussi être utilisé seul. Ses principaux atouts sont une grande évolutivité et des performances à la
fois élevées et prévisibles des applications. Comme il adapte la capacité à la demande, il peut gérer
des infrastructures middleware comprenant quelques serveurs ou des milliers. Etant donné qu'il s'agit
d'une solution de grid en mémoire, les données utilisées fréquemment sont accessibles rapidement.
Par ailleurs, les fonctionnalités de grid permettent d'effectuer des calculs en parallèle, ce qui
augmente les performances des applications.
Enterprise Manager Grid Control gère les opérations réalisées au niveau du grid. Il assure
notamment la gestion de l'ensemble du logiciel, l'approvisionnement d'utilisateurs, le clonage des
bases de données et la gestion des patches. Grâce à lui, vous pouvez contrôler les performances de
toutes les applications en vous plaçant du point de vue de l'utilisateur final. Grid Control affiche les
performances et la disponibilité de l'infrastructure de grid. Pour cela, il considère l'infrastructure
comme une entité et non comme un ensemble d'unités de stockage, de bases de données et de
serveurs d'applications distincts. Vous pouvez regrouper les serveurs d'applications, les bases de
données et les noeuds matériels dans des entités logiques uniques et gérer un groupe de cibles comme
s'il s'agissait d'une seule et même unité.
Remarque : Dans ce cours, Enterprise Manager Database Console n'est utilisé que pour une seule
base de données.

Grid Infrastructure for Single-Instance
Grid Infrastructure for Single-Instance est une nouveauté
introduite par Oracle Database 11g Release 2.
• Installé à partir des supports de clusterware, distincts de ceux
du logiciel de base de données
• Contient Automatic Storage Management (ASM)
• Contient la solution de haute disponibilité Oracle Restart
(réservée aux bases de données non clusterisées)
– Oracle Restart peut surveiller et redémarrer les composants
suivants :
— Instances de base de données

— Processus d'écoute Oracle Net
— Services de base de données
— Instances ASM (Automatic Storage Management)
— Groupes de disques ASM
— Oracle Notification Services (ONS/eONS) pour Data Guard
Grid Infrastructure for Single-Instance

Grid Infrastructure for Single-Instance est une nouvelle fonctionnalité d'Oracle Database 11g
Release 2 qui n'est pas installée avec le logiciel de base de données Oracle, mais à partir des
supports du logiciel de cluster (clusterware). Elle comprend Oracle Automatic Storage
Management (ASM) et une nouveauté : Oracle Restart.
Oracle Restart vise à améliorer la disponibilité de la base de données Oracle en implémentant
une solution de haute disponibilité applicable uniquement aux environnements mono-
instances (non clusterisés). Pour les environnements Oracle Real Application Cluster (RAC),
la fonctionnalité de redémarrage automatique des composants est fournie par le clusterware.
Oracle Restart peut surveiller le fonctionnement des composants suivants et les redémarrer
automatiquement :
• Instances de base de données
• Processus d'écoute Oracle Net
• Services de base de données
• Instances ASM
• Groupes de disques ASM
• Oracle Notification Services (ONS/eONS) pour Data Guard
Oracle Restart tient compte des dépendances entre composants pour démarrer ceux-ci dans
l'ordre adéquat. Si un composant doit être arrêté, il veille à arrêter les composants dépendants
au préalable. Oracle Restart s'exécute à l'extérieur du répertoire d'origine Oracle Home
d'Oracle Grid Infrastructure, lui-même installé en dehors des répertoires d'origine de la base
de données Oracle.

Architecture d'une base de données Oracle

Objectifs
A la fin de ce chapitre, vous pourrez :

• énumérer les principaux composants de l'architecture
d'une base de données Oracle
• décrire les structures mémoire
• décrire les processus en arrière-plan
• définir la relation entre les structures de stockage logiques
et physiques
• décrire les composants de stockage ASM

Objectifs
Ce chapitre décrit en détail l'architecture d'une base de données Oracle. Il présente les
structures physiques et logiques, ainsi que les divers composants de la base.
Oracle Database 11g : Administration Workshop I 1 - 2

Base de données Oracle
Le système de gestion de base de données relationnelle

(SGBDR) Oracle fournit une approche ouverte, complète et
intégrée de la gestion des informations.

Base de données Oracle

Une base de données est un ensemble de données traitées comme une seule et même unité.
Elle sert principalement à stocker et à extraire des informations connexes.
Le système de gestion de base de données relationnelle (SGBDR) d'Oracle est capable de
gérer de manière fiable une grande quantité de données dans un environnement
multiutilisateur, permettant ainsi à de nombreux utilisateurs d'accéder simultanément aux
mêmes données tout en bénéficiant de performances élevées. En outre, il empêche les accès
non autorisés et fournit des solutions efficaces pour la récupération des données après
incident.

Se connecter à un serveur
Client Niveau Serveur

intermédiaire
Architecture multiniveau
Se connecter à un serveur
Un utilisateur de base de données peut se connecter à un serveur Oracle de trois manières :
• L'utilisateur se connecte au système d'exploitation qui exécute l'instance Oracle et
démarre une application ou un outil qui accède à la base de données stockée sur ce
système. La voie de communication est établie à l'aide des mécanismes de
communication interprocessus disponibles dans le système d'exploitation hôte.
• L'utilisateur démarre l'application ou l'outil sur un ordinateur local, et il se connecte via
un réseau à l'ordinateur qui exécute la base Oracle. Dans cette configuration (appelée
client/serveur), un logiciel réseau est utilisé pour la communication entre l'utilisateur et
le serveur de base de données.
L'architecture client/serveur comprend une partie frontale (client) et une partie dorsale
(serveur) connectées via un réseau. La communication entre l'utilisateur et le serveur
Oracle est assurée par un logiciel réseau.
- Le client est une application de base de données qui lance une demande pour
effectuer une opération sur le serveur de base de données. Il demande, traite et
présente les données gérées par le serveur. Le poste de travail client peut être
optimisé pour sa fonction. Par exemple, il n'a pas forcément besoin d'une grande
capacité de disque, ou encore il peut avoir besoin de fonctionnalités graphiques.
Le client est souvent exécuté sur un ordinateur différent du serveur de base de
données. Plusieurs clients peuvent accéder simultanément à un même serveur.

Se connecter à un serveur (suite)
- Le serveur exécute le logiciel Oracle Database et gère les fonctions permettant des accès
simultanés aux données partagées. Le serveur reçoit et traite les demandes en provenance
des applications client. L'ordinateur qui fait office de serveur peut être optimisé pour ses
fonctions. Par exemple, il peut être doté d'une grande capacité de disque et de processeurs
rapides.
• L'utilisateur accède à un serveur d'applications à l'aide d'un outil (navigateur Web, par exemple)
exécuté sur l'ordinateur local (client). Le serveur d'applications interagit alors avec un serveur de
base de données back-end pour le compte du client.
Une architecture à plusieurs niveaux (multi-tiers) classique comprend les composants suivants :
• Un processus client ou initiateur qui démarre une opération.
• Un ou plusieurs serveurs d'applications qui effectuent différentes parties de l'opération. Un
serveur d'applications contient une grande partie de la logique applicative, permet au client
d'accéder aux données et traite certaines interrogations, ce qui allège la charge du serveur de

base de données. En outre, il peut servir d'interface entre les clients et plusieurs serveurs de base
de données, apportant ainsi un niveau de sécurité supplémentaire.
• Un serveur final ou serveur de base de données qui héberge la plus grande partie des données
utilisées pour l'opération effectuée.
Cette architecture permet d'utiliser un serveur d'applications pour les tâches suivantes :
• Validation des informations d'identification et de connexion (credentials) d'un client (navigateur
Web, par exemple)
• Connexion à un serveur Oracle Database
• Exécution de l'opération demandée pour le compte du client

Architecture d'un serveur de base de données
Oracle : Présentation
Instance
PGA
Processus
serveur Structures mémoire
(mémoire SGA)
Serveur
Structures de processus

Processus
utilisateur
Base de données (structures de stockage)

Client
Architecture d'un serveur de base de données Oracle

L'architecture d'un serveur de base de données Oracle comprend trois principaux types de
structure : structures mémoire, structures de processus et structures de stockage. Un système
de base de données Oracle élémentaire est constitué d'une base Oracle et d'une instance de
cette base.
La base de données est constituée de structures physiques et de structures logiques. Celles-ci
étant distinctes, il est possible de gérer le stockage physique des données sans affecter l'accès
aux structures de stockage logiques.
Une instance se compose de structures mémoire et de processus en arrière-plan. A chaque
démarrage d'une instance, une zone de mémoire partagée appelée mémoire SGA (System
Global Area) est allouée et les processus en arrière-plan sont lancés. Le terme "processus"
désigne les travaux qui s'exécutent dans la mémoire des ordinateurs. Un processus peut être
défini comme un "thread de contrôle" ou comme un mécanisme du système d'exploitation
capable d'exécuter un ensemble d'étapes. Lorsqu'une instance est démarrée, le logiciel Oracle
l'associe à une base de données précise. Ce processus est appelé montage de la base de
données. La base peut alors être ouverte et mise à la disposition des utilisateurs autorisés.
Remarque : Oracle Automatic Storage Management (ASM) utilise la notion d'instance pour
les composants de la mémoire et des processus, mais elle n'est pas associée à une base de
données spécifique.

Instance : Configurations de base de données
Système non clusterisé Système clusterisé
I1
I1 I2 I3
I2
D1

D2
Espace de D
stockage local
Espace de stockage
partagé
Instance : Configurations de base de données

Chaque instance de base de données est associée à une seule base. S'il existe plusieurs bases
sur le même serveur, il existe une instance distincte pour chacune. Une instance de base de
données ne peut pas être partagée. Une base de données Real Applications Cluster (RAC)
présente généralement plusieurs instances sur des serveurs distincts pour la même base
partagée. Dans ce modèle, la base est associée à chaque instance RAC, ce qui répond à
l'obligation d'avoir au plus une base de données associée à une instance.

Connexion à une instance de base de données
• Connexion : Communication entre un processus utilisateur

et une instance
• Session : Connexion spécifique d'un utilisateur à une
instance via un processus utilisateur

Processus Processus
SQL> Select … utilisateur serveur
Utilisateur Session
Connexion
Session
Connexion à une instance de base de données

Les concepts de connexion et de session sont étroitement liés aux processus utilisateur, mais
ils correspondent à des notions très différentes.
Une connexion est une voie de communication entre un processus utilisateur et une instance
Oracle Database. Elle est établie à l'aide des mécanismes de communication interprocessus
disponibles (sur un ordinateur qui exécute à la fois le processus utilisateur et Oracle Database)
ou via un logiciel réseau (lorsque différents ordinateurs exécutent l'application de base de
données et Oracle Database en communiquant via un réseau).
Une session représente l'activité d'un utilisateur spécifique connecté à l'instance de base de
données. Par exemple, quand un utilisateur démarre SQL*Plus, il doit fournir un nom
utilisateur et un mot de passe valides. Une session est alors établie spécialement pour lui. Une
session commence au moment où l'utilisateur se connecte et se termine lorsqu'il se déconnecte
ou quitte l'application de base de données.
Plusieurs sessions peuvent être créées et exister simultanément pour un même utilisateur de la
base de données Oracle et sous le même nom utilisateur. Ainsi, un utilisateur peut se
connecter plusieurs fois à la même instance Oracle Database avec le nom utilisateur HR et le
mot de passe HR.

Structures mémoire d'une base de données Oracle
Mémoire PGA
(Program Global Area) PGA
Espace Mémoire Espace Mémoire
de pile UGA (User de pile UGA (User
Global Global
Area) Area)
Processus Processus
serveur 1 serveur 2
Cache de Espace de tampons

Zone de Tampon
tampons de à conserver
mémoire de journa-
la base
partagée lisation Espace de tampons
de données

à recycler
Zone de Zone de
Zone de Cache de tampons de
mémoire mémoire
mémoire blocs de taille nK
LARGE Streams
POOL Java
Mémoire SGA (System Global Area)
Structures mémoire d'une base de données Oracle

Oracle Database crée et utilise des structures mémoire à des fins diverses. La mémoire
contient, par exemple, le code des programmes en cours d'exécution, les données partagées
entre utilisateurs et des zones de données privées pour chaque utilisateur connecté.
Deux structures mémoire élémentaires sont associées à une instance :
• Mémoire SGA (System Global Area) : Groupe de structures mémoire partagées
(appelées composants SGA) qui contiennent les données et les informations de contrôle
correspondant à une instance Oracle Database. La mémoire SGA est partagée par les
processus serveur et par les processus en arrière-plan. Elle contient notamment les blocs
de données en mémoire cache et les zones SQL partagées.
• Mémoire PGA (Program Global Area) : Région de la mémoire qui contient des
données et des informations de contrôle pour un processus serveur ou un processus en
arrière-plan. Il s'agit d'une mémoire non partagée qui est créée par Oracle Database au
démarrage d'un processus serveur ou d'un processus en arrière-plan. Seul ce processus a
accès à sa zone de mémoire PGA. Chaque processus serveur ou d'arrière-plan a sa propre
mémoire PGA.

Structures mémoire d'une base de données Oracle (suite)
La mémoire SGA contient des informations de contrôle et des données relatives à l'instance. Elle
contient les structures de données suivantes :
• Zone de mémoire partagée : Elle met en mémoire cache diverses structures pouvant être
partagées par les utilisateurs.
• Cache de tampons (buffer cache) de la base de données : Il met en mémoire cache les blocs
de données extraits de la base.
• Espace de tampons à conserver : Type particulier de cache de tampons qui est configuré pour
le stockage de blocs de données pendant de longues périodes.
• Espace de tampons à recycler : Type particulier de cache de tampons qui est configuré pour un
recyclage ou une suppression rapide de blocs.
• Cache de tampons de blocs de taille nK : Type particulier de cache de tampons conçu pour le
stockage des blocs qui présentent une taille différente de la taille de bloc par défaut de la base de
données.
• Tampon de journalisation : Il met en mémoire cache les informations de journalisation

(utilisées pour la récupération d'instance) jusqu'à ce qu'elles puissent être écrites dans les fichiers
de journalisation (fichiers redo log) physiques stockés sur le disque.
• Zone de mémoire LARGE POOL : Il s'agit d'une zone facultative qui fournit des espaces
importants d'allocation de mémoire à des processus volumineux, tels que les opérations de
sauvegarde et de récupération Oracle et les processus serveur d'E/S.
• Zone de mémoire Java : Elle est utilisée pour l'ensemble du code Java et des données propres à
la session, dans la JVM (Java Virtual Machine).
• Zone de mémoire Streams : Elle est utilisée par Oracle Streams pour stocker les informations
nécessaires aux opérations de capture et d'application des modifications.
Lorsque vous démarrez l'instance via Enterprise Manager ou SQL*Plus, la quantité de mémoire
allouée à la SGA est affichée.
Une mémoire PGA (Program Global Area) est une zone de mémoire contenant des données et des
informations de contrôle pour chaque processus serveur. Un processus serveur Oracle traite les
demandes d'un client. Chaque processus serveur dispose de sa propre zone de mémoire PGA privée,
qui est créée lors de son démarrage. L'accès à la mémoire PGA est exclusivement réservé à ce
processus serveur, qui peut lire le contenu de la mémoire et écrire dans celle-ci par l'intermédiaire du
code Oracle. La mémoire PGA est divisée en deux zones principales : l'espace de pile et la mémoire
UGA (User Global Area).
Grâce à l'infrastructure dynamique de la mémoire SGA, il est possible de modifier la taille du cache
de tampons de la base de données, de la zone de mémoire partagée, de la zone de mémoire LARGE
POOL, de la zone de mémoire Java et de la zone de mémoire Streams sans arrêter l'instance.
La base de données Oracle utilise des paramètres d'initialisation pour créer et gérer les structures
mémoire. La manière la plus simple de gérer la mémoire est de laisser la base de données le faire
automatiquement. Pour cela, il suffit (sur la plupart des plates-formes) de définir les paramètres
d'initialisation MEMORY_TARGET et MEMORY_MAX_TARGET.

Zone de mémoire partagée
• Portion de la mémoire SGA
• Contenu :
– Cache "library"
— Zone SQL partagée Zone SQL
Cache du dictionnaire
de données
– Cache du dictionnaire partagée
de données Zone de mémoire fixe

– Structures de contrôle
Cache Autres
"library"
Zone de Cache de Tampon Espace de tampons
mémoire tampons de la de journa- à conserver
base de données lisation

partagée
Espace de tampons
à recycler
Zone de Zone de Zone de
mémoire mémoire mémoire Cache de tampons
LARGE POOL Java Streams de blocs de taille nK
Zone de mémoire partagée

La zone de mémoire partagée est une portion de la mémoire SGA qui contient le cache
"library", le cache du dictionnaire de données, le cache des résultats d'interrogations SQL, le
cache des résultats de fonctions PL/SQL, des mémoires tampons pour les messages
d'exécution en parallèle et des structures de contrôle.
Le dictionnaire de données est un ensemble de tables et de vues de la base de données. Il
présente des informations de référence concernant la base, ses structures et ses utilisateurs.
Oracle Database accède fréquemment au dictionnaire de données lors de l'analyse des
instructions SQL. Cet accès est essentiel pour un fonctionnement continu.
Comme le dictionnaire fait l'objet d'accès très fréquents, deux emplacements spécifiques sont
prévus en mémoire pour contenir ses données. L'un de ces emplacements est le cache du
dictionnaire de données, également appelé cache de lignes (row cache) parce que les données
y sont organisées en lignes, et non en tampons (qui contiennent des blocs entiers de données).
L'autre zone de mémoire qui contient les données du dictionnaire est le cache "library". Tous
les processus utilisateur d'Oracle Database partagent ces deux caches pour accéder aux
informations du dictionnaire.
Chaque instruction SQL exécutée par Oracle Database est représentée par une zone SQL
partagée (plus une zone SQL privée en mémoire PGA). Si la même instruction est exécutée
par un autre utilisateur, Oracle Database réutilise la même zone SQL partagée.

Zone de mémoire partagée (suite)
Une zone SQL partagée contient l'arborescence de l'analyse (parse) et le plan d'exécution pour une
instruction SQL donnée. Oracle Database économise de l'espace mémoire en utilisant une seule zone
SQL partagée pour les instructions SQL lancées plusieurs fois, ce qui est souvent le cas lorsque
plusieurs utilisateurs exécutent la même application.
Quand une nouvelle instruction SQL est analysée, Oracle Database lui alloue de la mémoire à partir
de la zone de mémoire partagée afin de la stocker dans la zone SQL partagée. La taille de cette
mémoire dépend de la complexité de l'instruction.
Les unités de programme PL/SQL (procédures, fonctions, packages, blocs anonymes et déclencheurs
de base de données) sont traitées quasiment de la même manière que les instructions SQL
individuelles. Oracle Database alloue une zone partagée pour contenir la forme analysée et compilée
d'une unité de programme. Une zone privée est allouée pour les valeurs propres à la session qui
exécute l'unité de programme, à savoir les variables locales, les variables globales et les variables de
package (on parle d'instanciation de package), ainsi que les tampons pour l'exécution du code SQL.

Si plusieurs utilisateurs exécutent la même unité de programme, ils utilisent tous la même zone
partagée, mais ils gèrent des copies distinctes de leur zone SQL privée contenant les valeurs
spécifiques à leur session.
Les instructions SQL contenues dans une unité de programme PL/SQL sont traitées de la même
manière que les autres instructions SQL. Bien qu'elles proviennent d'une unité de programme
PL/SQL, elles utilisent une zone partagée contenant leurs représentations analysées et une zone
privée pour chaque session exécutant l'instruction.
Le cache des résultats d'interrogations SQL et le cache des résultats de fonctions PL/SQL sont de
nouvelles structures mémoire fournies par Oracle Database 11g. Ces caches partagent la même
infrastructure, ils apparaissent dans les mêmes vues dynamiques des performances ($V) et ils sont
administrés à l'aide du même package (fourni avec le produit).
Les résultats des interrogations et des fragments d'interrogation peuvent être placés dans le cache des
résultats d'interrogations SQL. La base de données peut ensuite les utiliser pour répondre aux
nouvelles exécutions de ces interrogations et fragments d'interrogation. En effet, il est plus rapide
d'extraire des résultats du cache que de réexécuter une interrogation. La mise en cache des résultats
peut donc optimiser considérablement les performances des interrogations exécutées fréquemment.
Une fonction PL/SQL est parfois utilisée pour renvoyer le résultat d'un calcul dont les données
d'entrée sont une ou plusieurs interrogations paramétrées et exécutées par la fonction. Dans certains
cas, ces interrogations accèdent à des données qui ne sont que très rarement modifiées par rapport à
la fréquence d'appel de la fonction. Vous pouvez inclure dans le texte source d'une fonction PL/SQL
une syntaxe qui demande la mise en mémoire cache de ses résultats dans le cache de résultats de
fonctions PL/SQL et déclenche la purge du cache (dans un souci d'exactitude) lorsque les tables d'une
liste font l'objet d'une opération LMD.
La zone fixe de la zone de mémoire partagée représente la surcharge liée au démarrage de la
mémoire SGA. Elle est très petite par rapport à une zone de mémoire partagée ou à une SGA de taille
standard.

Cache de tampons de la base de données
• Fait partie de la mémoire SGA
• Contient les copies de blocs de données lues dans les
fichiers de données
• Est partagé par tous les utilisateurs simultanés
Cache de Tampon Espace de tampons à

tampons de de conserver
Zone de
la base journa-
mémoire Espace de tampons à
de données lisation
partagée recycler
Cache de tampons de

mémoire blocs de taille nK
mémoire mémoire
LARGE Java Streams
POOL
Cache de tampons de la base de données

Le cache de tampons (buffer cache) de la base de données est la partie de la mémoire SGA
qui contient les images de blocs lues à partir des fichiers de données ou construites
dynamiquement pour satisfaire au modèle de cohérence en lecture. Son accès est partagé par
tous les utilisateurs connectés simultanément à l'instance.
La première fois qu'un processus utilisateur Oracle Database a besoin de données
particulières, il va les chercher dans le cache de tampons. S'il les trouve dans le cache (succès
en mémoire cache), il peut les lire directement à partir de la mémoire. S'il ne les trouve pas
(échec en mémoire cache), il doit les copier depuis un fichier de données sur disque vers un
tampon du cache afin de pouvoir y accéder. L'accès aux données est plus rapide lorsqu'elles se
trouvent déjà dans le cache.
Les tampons du cache sont gérés par un algorithme complexe qui utilise une combinaison de
listes LRU (Least Recently Used) et de nombres d'accès (touch count). Le mécanisme LRU
permet de garantir que les blocs les plus récemment utilisés restent en mémoire afin de limiter
les accès disque.
L'espace de tampons à conserver et l'espace de tampons à recycler sont utilisés pour des
ajustements particuliers du pool de tampons. L'espace de tampons à conserver permet de
conserver des tampons en mémoire pendant une période plus longue que celle normalement
autorisée par le mécanisme LRU. L'espace de tampons à recycler sert à supprimer des
tampons de la mémoire plus rapidement que la normale.
Il est possible de configurer des caches de tampons supplémentaires pour stocker les blocs qui
ont une taille différente de la taille de bloc standard.

Tampon de journalisation
• Mémoire tampon réutilisable située dans la mémoire SGA
• Contient des informations sur les modifications apportées à
la base de données
• Contient des entrées de journalisation dont les informations
permettent d'annuler les modifications effectuées par des
opérations LMD et LDD
Tampon Espace de tampons

de à conserver
Zone
Cachedede tampons de la base de données
journa-
mémoire Espace de tampons
lisation

partagée
Zone de à recycler
mémoire Zone de Zone de
LARGE mémoire mémoire Cache de tampons
POOL Java Streams de blocs de taille nK
Tampon de journalisation
Le tampon de journalisation (redo log buffer) est une mémoire tampon réutilisable située dans
la mémoire SGA qui contient des informations sur les modifications effectuées dans la base.
Ces informations sont stockées sous la forme d'entrées de journalisation. Celles-ci contiennent
les informations nécessaires à l'annulation (redo) des modifications apportées à la base par des
opérations LMD (langage de manipulation de données), LDD (langage de définition de
données) ou internes. Elles sont utilisées pour la récupération de la base.
Lorsque le processus serveur effectue des modifications dans le cache de tampons, des entrées
de journalisation sont générées et écrites dans le tampon de journalisation de la mémoire
SGA. Elles occupent un espace séquentiel continu dans le tampon. Le processus LGWR (Log
Writer) en arrière-plan écrit le tampon de journalisation dans le fichier de journalisation ou le
groupe de fichiers de journalisation qui est actif sur le disque.

Zone de mémoire LARGE POOL
Elle fournit des allocations de mémoire de grande taille pour
les éléments suivants :
• Mémoire de session pour le serveur partagé et l'interface
Oracle XA
• Processus serveur d'E/S
• Opérations de sauvegarde et de restauration d'Oracle
Database
Cache Tampon Espace de
Zone de
de tampons de tampons à
mémoire
de la base journa- conserver
Tampon Mémoire Environnement
partagée Cache de
Espace de
de données lisation d'E/S disponible Parallel Query

tamponsà
tampons
Zone de Zone de File d'attente
de blocs File d'attente
recycler Advanced
Zone de mémoire mémoire de réponses
de taille de demandes Queuing
mémoire
LARGE POOL Java nK
Streams
Zone de mémoire
LARGE POOL
Zone de mémoire LARGE POOL

L'administrateur de base de données peut configurer une zone de mémoire facultative appelée
LARGE POOL pour allouer des zones de mémoire de grande taille aux éléments suivants :
• Mémoire de session pour le serveur partagé et l'interface Oracle XA (lorsque les
transactions interagissent avec plusieurs bases de données)
• Processus serveur d'E/S
• Opérations de sauvegarde et de restauration d'Oracle Database
• Opérations Parallel Query
• Mémoire Advanced Queuing
En allouant de l'espace mémoire de session à partir de la mémoire LARGE POOL
(configuration avec serveur partagé, Oracle XA ou mémoires tampons d'interrogations en
parallèle), Oracle Database peut réserver la zone de mémoire partagée à la mise en cache des
interrogations SQL partagées. Cela évite la perte de performances causée par la réduction du
cache SQL partagé.
Par ailleurs, la mémoire destinée aux opérations de sauvegarde et de restauration d'Oracle
Database, aux processus serveur d'E/S et aux tampons d'exécution en parallèle est allouée par
tampons de quelques centaines de kilo-octets (Ko). La zone de mémoire LARGE POOL est
plus apte que la zone de mémoire partagée à répondre à des besoins aussi importants.
La zone de mémoire LARGE POOL n'est pas gérée par une liste LRU (Least Recently Used).

Zones de mémoire Java et Streams
• La zone de mémoire Java est utilisée pour l'ensemble du
code Java et des données propres à la session dans la
JVM (Java Virtual Machine).
• La zone de mémoire Streams est utilisée exclusivement par
Oracle Streams :
– Stockage des messages de la file d'attente tampon
– Fourniture de mémoire pour les processus Oracle Streams
Zone de Cache de Tampon Espace de tampons

mémoire tampons de de à conserver
partagée la base journa-
de données lisation Espace de tampons

Zone de à recycler
mémoire Zone de Zone de
LARGE mémoire mémoire Cache de tampons
POOL Java Streams de blocs de taille nK
Zone de Zone de mémoire

mémoire Java Streams
Zones de mémoire Java et Streams

La zone de mémoire Java est utilisée pour l'ensemble du code Java et des données propres à la
session dans la JVM (Java Virtual Machine). Elle est utilisée de différentes manières, en
fonction du mode d'exécution d'Oracle Database.
La zone de mémoire Streams est utilisée par Oracle Streams exclusivement. Elle contient les
messages en file d'attente tampon et fournit la mémoire nécessaire aux processus Oracle
Streams de capture et d'application des modifications.
La taille de la zone de mémoire Streams est initialement égale à zéro (sauf configuration
spécifique). Elle augmente dynamiquement en fonction des besoins quand Oracle Streams est
utilisé.
Remarque : Ce cours ne traite pas en détail de la programmation Java ni d'Oracle Streams.

Mémoire PGA (Program Global Area)
PGA Etat du Zone de tri Zone de
curseur hachage
Mémoire
UGA Zone de création d'index
Espace (User bitmap
de pile Données de
Global
session
Area) Zone de fusion d'index
utilisateur
Processus bitmap
serveur 1
Zones de travail SQL
Cache de Tampon Espace de tampons

Zone de
tampons de de à conserver
mémoire
la base journa-

partagée Espace de tampons
à recycler
Mémoire PGA (Program Global Area)

La mémoire PGA (Program Global Area) est une zone de mémoire contenant des données et
des informations de contrôle pour un processus serveur. Chaque processus serveur dispose de
sa propre mémoire PGA privée, qui ne peut être lue que par le code Oracle agissant pour son
compte. Cette mémoire n'est pas disponible pour le code du développeur.
Chaque PGA contient un espace de pile. Dans un environnement avec serveur dédié, chaque
utilisateur qui se connecte à l'instance de base de données comporte un processus serveur
distinct. Pour ce type de connexion, la mémoire PGA contient une subdivision de mémoire
connue sous le nom de zone UGA (User Global Area). La mémoire UGA comprend les
éléments suivants :
• Une zone de curseurs pour stocker les informations d'exécution sur les curseurs.
• Une zone de mémoire de session utilisateur pour des informations concernant une session.
• Des zones de travail SQL pour le traitement des instructions SQL :
- Une zone de tri pour les fonctions qui classent les données telles que ORDER BY et
GROUP BY.
- Une zone de hachage pour exécuter les jointures de hachage entre les tables.
- Une zone de création d'index bitmap commune aux data warehouses utilisée pour la
création d'index bitmap.
- Une zone de fusion d'index bitmap utilisée pour définir les plans d'exécution basés sur
un index bitmap.
Dans un environnement avec serveur partagé, plusieurs clients partagent un même processus
serveur. Dans ce modèle, la mémoire UGA est transférée dans la mémoire SGA (dans la zone
de mémoire partagée ou dans la zone de mémoire LARGE POOL si elle est configurée), de
sorte que la mémoire PGA contient uniquement l'espace de pile.
Quiz
Quel est le nom de la zone de mémoire contenant des données

et des informations de contrôle pour un processus serveur ou
un processus en arrière-plan :
1. Zone de mémoire partagée
2. PGA
3. Cache de tampons
4. Données de session utilisateur

Réponse : 2

Quiz
Quels éléments sont lus dans les fichiers de données et placés

dans le cache de tampons de la base ?
1. Lignes
2. Modifications
3. Blocs
4. Instructions SQL

Réponse : 3

Architecture des processus
• Processus utilisateur
– Application ou outil qui se connecte à la base de données
Oracle
• Processus de base de données
– Processus serveur : Se connecte à l'instance Oracle et
démarre lorsqu'un utilisateur ouvre une session
– Processus en arrière-plan : Démarrés en même temps qu'une
instance Oracle
• Démon / processus applicatifs

– Processus d'écoute réseau
– Démons de l'infrastructure de grid
Architecture des processus

Les processus d'un système Oracle Database peuvent être classés en trois grandes catégories :
• Processus utilisateur qui exécutent le code des applications ou des outils Oracle.
• Processus Oracle Database qui exécutent le code du serveur de base de données Oracle
(y compris les processus serveur et les processus en arrière-plan).
• Démons et processus d'application Oracle non spécifiques à une seule base de données.
Lorsqu'une application ou un outil Oracle (SQL*Plus, par exemple) est lancé par un
utilisateur, il constitue un processus utilisateur. Ce processus ne se trouve pas nécessairement
sur l'ordinateur du serveur de base de données. Oracle Database crée également un processus
serveur pour exécuter les commandes émises par le processus utilisateur. En outre, le serveur
Oracle crée, pour une instance donnée, un ensemble de processus en arrière-plan qui
interagissent les uns avec les autres d'une part, et avec le système d'exploitation d'autre part,
afin de gérer les structures mémoire, d'effectuer des opérations d'E/S asynchrones pour écrire
des données sur le disque, et de réaliser les autres tâches requises. La structure des processus
varie d'une configuration Oracle Database à une autre. Elle dépend du système d'exploitation
et des options choisies pour Oracle Database. Le code associé aux utilisateurs connectés peut
être configuré pour une utilisation avec un serveur dédié ou un serveur partagé.
• Serveur dédié : Pour chaque session, l'application de base de données est exécutée par
un processus utilisateur qui est desservi par un processus serveur dédié exécutant le code
serveur de la base Oracle.
• Serveur partagé : Cette configuration évite d'avoir un processus serveur dédié pour
chaque connexion. Un processus répartiteur dirige les différentes demandes de session
réseau entrantes vers un pool de processus serveur partagés. Un processus serveur partagé
peut traiter n'importe quelle demande client.

Structure des processus
Instances (ASM et base de données à part)

PGA
Processus Processus en arrière-plan
serveur
Obligatoires : DBWn CKPT LGWR SMON PMON RECO
Processus Facultatifs : ARCn ASMB RBAL Autres

d'écoute
Processus d'Oracle Grid Infrastructure

(ASM et Oracle Restart)
Processus ohas ocssd diskmon
utilisateur
orarootagent oraagent cssdagent
Structure des processus

Processus serveur
Oracle Database crée des processus serveur pour gérer les demandes des processus utilisateur
connectés à l'instance. Un processus utilisateur représente une application ou un outil qui se
connecte à la base de données Oracle. Il peut être sur la même machine que la base, ou il peut
exister sur un client distant et utiliser un réseau pour accéder à la base. Le processus
utilisateur communique d'abord avec un processus d'écoute (listener) qui crée un processus
serveur dans un environnement dédié.
Les processus serveur créés pour le compte de chaque application utilisateur peuvent effectuer
une ou plusieurs des tâches suivantes :
• Analyse (parse) et exécution des instructions SQL émises via l'application.
• Lecture des blocs de données nécessaires à partir des fichiers de données sur disque et
écriture dans des tampons de base de données partagés de la mémoire SGA (si ces blocs
ne figurent pas déjà dans la SGA).
• Renvoi des résultats de telle sorte que l'application puisse traiter les informations.
Processus en arrière-plan
Pour optimiser les performances et prendre en charge un grand nombre d'utilisateurs, un
système Oracle Database multiprocessus utilise des processus Oracle Database
supplémentaires appelés processus en arrière-plan. Une instance Oracle Database peut
comprendre un grand nombre de processus en arrière-plan.
Database peut comprendre un grand nombre de processus en arrière-plan.

Structure des processus (suite)
Dans les environnements qui n'utilisent ni RAC (Real Application Clusters), ni ASM (Automatic
Storage Management), les processus en arrière-plan les plus courants sont les suivants :
• DBWn (Database Writer)
• LGWR (Log Writer)
• CKPT (processus de point de reprise)
• SMON (System Monitor)
• PMON (Process Monitor)
• RECO (processus de récupération)
• CJQ0 (coordonnateur de file d'attente de travaux)
• Jnnn (processus esclaves de travail)
• ARCn (processus d'archivage)
• QMNn (processus de surveillance de file d'attente)
D'autres processus en arrière-plan sont disponibles pour les configurations plus avancées (RAC, par

exemple). Pour plus d'informations, consultez la vue V$BGPROCESS.
Certains processus en arrière-plan sont créés automatiquement lorsqu'une instance est démarrée,
tandis que d'autres sont lancés en cas de besoin.
D'autres structures de processus ne sont pas propres à une base de données unique, mais peuvent être
partagées par plusieurs bases hébergées sur le même serveur. Il s'agit notamment des processus de
l'infrastructure de grille et des processus réseau.
Sur les systèmes Linux et UNIX, les processus Oracle Grid Infrastructure comprennent :
• ohasd : Démon Oracle High Availability Service qui est chargé de démarrer Oracle
Clusterware.
• ocssd : Démon Cluster Synchronization Service.
• diskmon : Démon Disk Monitor qui est chargé d'isoler les entrées et les sorties pour le serveur
HP Oracle Exadata Storage Server.
• cssdagent : Démarre et arrête le démon CSS (ocssd) et vérifie son statut.
• oraagent : Etend le clusterware pour la prise en charge d'exigences Oracle spécifiques et de
ressources complexes.
• orarootagent : Agent Oracle spécialisé qui permet de gérer les ressources appartenant à
l'utilisateur root, telles que le réseau.
Remarque : Pour une liste plus détaillée des processus en arrière-plan, consultez l'annexe Processus
en arrière-plan Oracle de ce cours ou le manuel Oracle Database Reference.

Processus DBWn (Database Writer)
Il écrit sur le disque les tampons qui ont été modifiés ("dirty")
dans le cache de tampons de la base de données :
• de manière asynchrone pendant l'exécution d'autres
traitements
• pour faire avancer le point de reprise

DBWn
Cache de tampons Processus Database Fichiers de données

de la base de Writer
données
Processus DBWn (Database Writer)

Les processus Database Writer écrivent le contenu des tampons dans des fichiers de données.
Ils sont chargés de transférer sur disque le contenu des tampons modifiés ("dirty") du cache de
tampons de la base de données. Un seul processus Database Writer (DBW0) est suffisant pour
la plupart des systèmes, mais vous pouvez en configurer d'autres (DBW1 à DBW9 et DBWa à
DBWz) pour optimiser les performances d'écriture dans un système qui modifie les données
de manière intensive. Ces processus DBWn supplémentaires ne sont pas nécessaires sur les
systèmes dotés d'un seul processeur.
Quand un tampon du cache de la base de données est modifié, il est désigné comme "dirty" et
ajouté en tête de la file d'attente des points de reprise, laquelle est triée par numéro SCN
(System Change Number). L'ordre des tampons dans la file d'attente correspond donc à l'ordre
dans lequel les informations de journalisation (redo) sont écrites dans les journaux pour ces
tampons modifiés. Lorsque le nombre de tampons disponibles dans le cache est inférieur à un
seuil interne (au point que les processus serveur ont du mal à obtenir des tampons
disponibles), le processus DBWn écrit les tampons rarement utilisés dans les fichiers de
données en commençant par la fin de la liste LRU (Least Recently Used), afin que les
processus puissent remplacer des tampons en cas de besoin. Par ailleurs, DBWn écrit à partir
de la fin de la file d'attente des points de reprise pour faire avancer le point de reprise.

Processus DBWn (Database Writer) (suite)
La mémoire SGA contient une structure mémoire qui inclut l'adresse RBA (Redo Block Address)
indiquant la position (dans le flux de données de journalisation) à partir de laquelle la récupération
doit commencer en cas d'échec de l'instance. Cette structure joue le rôle de pointeur dans les
informations de journalisation. Elle est consignée dans le fichier de contrôle par le processus CKPT
toutes les trois secondes. Comme le processus DBWn écrit les tampons "dirty" dans l'ordre des
numéros SCN (System Change Number), il fait avancer le pointeur en mémoire SGA à chaque fois
qu'il écrit des tampons de la liste LRUW. De la sorte, si une récupération d'instance est nécessaire,
elle lira les informations de journalisation à partir d'un emplacement approximativement correct,
évitant ainsi des E/S inutiles. On parle de points de reprise incrémentiels.
Remarque : Il existe d'autres cas dans lesquels le processus DBWn peut effectuer des opérations
d'écriture (par exemple, lorsque des tablespaces deviennent accessibles en lecture seule ou sont mis
hors ligne). Dans de tels cas, aucune gestion de point de reprise incrémentiel n'a lieu parce que les
tampons "dirty" appartenant aux fichiers de données correspondants sont écrits dans la base sans tenir

compte du numéro SCN.
L'algorithme LRU conserve dans le cache de tampons les blocs faisant l'objet d'accès fréquents afin
de limiter le nombre de lectures sur disque. Une option CACHE peut être définie sur les tables pour
conserver les blocs encore plus longtemps dans la mémoire.
Le paramètre d'initialisation DB_WRITER_PROCESSES précise le nombre de processus DBWn. Le
nombre maximal de processus DBWn est 36. S'il n'est pas précisé par l'utilisateur au démarrage,
Oracle Database détermine sa valeur en fonction du nombre de CPU et de groupes de processeurs.
Le processus DBWn écrit les tampons "dirty" sur disque dans les cas suivants :
• Quand un processus serveur ne trouve pas de tampon réutilisable "clean" après avoir passé en
revue un nombre seuil de tampons, il demande au processus DBWn de transférer des tampons
sur disque. DBWn écrit les tampons "dirty" de manière asynchrone tout en effectuant d'autres
traitements.
• DBWn transfère périodiquement sur disque les données des tampons afin de faire avancer le
point de reprise, qui détermine le point de départ d'une récupération d'instance dans le fichier de
journalisation (redo log). Ce point correspond au plus ancien tampon "dirty" du cache de
tampons.
Dans tous les cas, DBWn effectue des opérations d'écriture (multiblocs) en mode batch pour plus
d'efficacité. Le nombre de blocs écrits par ce type d'opération est variable d'un système d'exploitation à
un autre.

Processus LGWR (Log Writer)
• Il écrit le tampon de journalisation dans un fichier de
journalisation sur le disque.
• Les opérations d'écriture ont lieu dans les cas suivants :
– Quand un processus utilisateur valide une transaction.
– Quand un tiers du tampon de journalisation est plein.
– Avant qu'un processus DBWn écrive des tampons modifiés
sur le disque.
– Toutes les 3 secondes.

LGWR
Tampon de Processus Log Fichiers de

journalisation Writer journalisation
Processus LGWR (Log Writer)

Le processus Log Writer (LGWR) est chargé de gérer la mémoire tampon de journalisation
(redo log buffer) en écrivant ses entrées dans un fichier de journalisation sur le disque. Il écrit
toutes les entrées de journalisation qui ont été copiées dans le tampon depuis la dernière
opération d'écriture.
Le tampon de journalisation est réutilisable. Une fois que le processus LGWR a écrit son
contenu dans un fichier de journalisation sur le disque, il peut recevoir de nouvelles données
provenant des processus serveur. Normalement, la vitesse d'écriture du processus LGWR est
suffisante pour que le tampon comporte toujours suffisamment d'espace pour de nouvelles
entrées, même lorsque le fichier de journalisation fait l'objet de nombreux accès. LGWR écrit
sur le disque une seule portion contiguë du tampon.
LGWR effectue une opération d'écriture :
• Quand un processus utilisateur valide une transaction.
• Quand un tiers du tampon de journalisation est plein.
• Avant qu'un processus DBWn écrive des tampons modifiés sur le disque (si nécessaire).
• Toutes les trois secondes.

Processus LGWR (LogWriter) (suite)
Pour que le processus DBWn puisse écrire un tampon modifié ("dirty"), il faut que tous les
enregistrements de journalisation associés aux modifications soient écrits sur le disque (protocole
d'écriture anticipée). Si DBWn détecte des enregistrements de journalisation qui n'ont pas encore été
écrits sur le disque, il le signale au processus LGWR et attend que ce dernier ait terminé l'opération
d'écriture pour vider les tampons de données. LGWR écrit dans le groupe de journaux en cours. Si
l'un des fichiers du groupe est défectueux ou indisponible, LGWR continue d'écrire dans d'autres
fichiers du groupe et consigne une erreur dans le fichier trace LGWR ainsi que dans le fichier
d'alertes système. Si tous les fichiers du groupe sont endommagés, ou si le groupe n'est pas
disponible parce qu'il n'a pas été archivé, le fonctionnement de LGWR est interrompu.
Quand un utilisateur lance une instruction COMMIT, LGWR place un enregistrement de validation
dans le tampon de journalisation et l'écrit immédiatement sur le disque avec les entrées de
journalisation de la transaction. L'écriture des modifications apportées aux blocs de données est
différée jusqu'au moment opportun. On parle de mécanisme de validation rapide. L'écriture atomique

de l'entrée de journalisation contenant l'enregistrement de validation de la transaction est le seul
événement qui indique si la transaction a été validée. Oracle Database renvoie un code de succès
pour la transaction en cours de validation même si les tampons de données n'ont pas encore été écrits
sur le disque.
Si le processus LGWR a besoin de plus d'espace de mémoire tampon, il écrit parfois les entrées de
journalisation avant que la transaction ne soit validée. Ces entrées ne deviennent permanentes que si
la transaction est validée ultérieurement. Lorsqu'un utilisateur valide une transaction, celle-ci reçoit
un numéro SCN (System Change Number) qui est enregistré par Oracle Database avec les entrées de
journalisation associées à la transaction dans le fichier de journalisation. Les numéros SCN sont
enregistrés dans le fichier de journalisation pour permettre la synchronisation des opérations de
récupération dans les environnements Real Application Clusters et les bases de données distribuées.
Dans les périodes de forte activité, le processus LGWR peut écrire dans le fichier de journalisation
via des validations groupées. Supposons, par exemple, qu'un utilisateur valide une transaction.
LGWR doit écrire les entrées de journalisation associées à la transaction sur le disque. Pendant ce
temps, d'autres utilisateurs lancent des instructions COMMIT. LGWR ne peut pas consigner ces
transactions dans le fichier de journalisation tant qu'il n'a pas terminé l'opération d'écriture
précédente. Une fois que les entrées relatives à la première transaction ont été écrites dans le fichier
de journalisation, la liste complète des entrées relatives aux transactions en attente (pas encore
validées) peut être écrite sur le disque en une seule opération, ce qui représente moins d'E/S qu'avec
une gestion individuelle des transactions. De cette façon, Oracle Database réduit les E/S disque et
augmente les performances du processus LGWR. Si les demandes de validation se succèdent à un
rythme élevé, chaque opération d'écriture (par LGWR) à partir du tampon de journalisation peut
contenir plusieurs enregistrements de validation.

Processus CKPT (Checkpoint)
• Il enregistre les informations de point de reprise

– dans le fichier de contrôle
– dans l'en-tête de chaque fichier de données
CKPT Fichier de
contrôle

Processus
CKPT
Fichiers de
données
Processus CKPT (Checkpoint)

Un point de reprise (checkpoint) est une structure de données qui définit un numéro SCN
(System Change Number) dans le thread de journalisation d'une base. Les points de reprise
sont enregistrés dans le fichier de contrôle et dans chaque en-tête de fichier de données. Ils
sont essentiels pour le processus de récupération.
Quand un point de reprise est créé, Oracle Database doit mettre à jour les en-têtes de tous les
fichiers de données pour actualiser les informations correspondantes. Cette opération est
effectuée par le processus CKPT. En revanche, celui-ci n'écrit pas les blocs sur le disque.
C'est le rôle du processus DBWn. Les numéros SCN enregistrés dans les en-têtes de fichier
garantissent que toutes les modifications apportées aux blocs de base de données avant un
numéro SCN spécifique ont été écrites sur le disque.

Processus SMON (System Monitor)
• Il effectue les opérations de récupération au démarrage

de l'instance.
• Il nettoie les segments temporaires inutilisés.
Instance
SMON

Processus SMON
Segment
temporaire
Processus SMON (System Monitor)

Si nécessaire, le processus SMON (System Monitor) se charge d'effectuer la récupération des
données au démarrage de l'instance. Il assure également le nettoyage des segments
temporaires qui ne sont plus utilisés. Si des transactions terminées ont été ignorées pendant la
récupération d'instance à cause d'erreurs liées aux fichiers ou d'erreurs de mise hors ligne
(offline), le processus SMON les récupère quand le tablespace ou le fichier correspondant est
remis en ligne (online).
SMON vérifie régulièrement s'il a besoin d'intervenir. Les autres processus peuvent appeler
SMON s'ils en détectent la nécessité.

Processus PMON (Process Monitor)
• Il assure la récupération des processus utilisateur qui ont
échoué.
– Nettoyage du cache de tampons de la base de données
– Libération des ressources utilisées par le processus
utilisateur en échec
• Il surveille les sessions pour détecter tout dépassement
du délai d'inactivité.
• Il enregistre dynamiquement les services de base de
données dans les processus d'écoute.
Processus
serveur

PMON
Utilisateur
tnslsnr Cache de tampons de
Processus utilisateur Processus PMON
en échec la base de données
Processus PMON (Process Monitor)

Le processus PMON assure la récupération des processus utilisateur qui ont échoué. Il est
chargé de nettoyer le cache de tampons de la base de données et de libérer les ressources
bloquées par les processus utilisateur en échec. Par exemple, il réinitialise le statut de la table
des transactions actives, libère les verrous externes (locks) et supprime l'ID du processus en
échec de la liste des processus actifs.
PMON vérifie périodiquement le statut des processus répartiteur et des processus serveur, et
les redémarre s'ils se sont arrêtés (sauf ceux qui ont été arrêtés volontairement par Oracle
Database). PMON utilise par ailleurs le processus d'écoute réseau pour enregistrer les
informations relatives à l'instance et aux processus répartiteur.
A l'instar du processus SMON, PMON vérifie régulièrement s'il doit intervenir. En outre, un
autre processus peut l'appeler s'il en détecte la nécessité.

Processus RECO (Recoverer)
• Il intervient dans une configuration de base de données
distribuée.
• Il se connecte automatiquement aux autres bases
impliquées dans des transactions distribuées équivoques.
• Il résout automatiquement toutes les transactions
équivoques.
• Il supprime toutes les lignes correspondant à des
transactions équivoques.

RECO
Processus RECO dans Transaction équivoque

la base A dans la base B
Processus RECO (Recoverer)

RECO (Recoverer) est un processus en arrière-plan qui est utilisé dans une configuration de
base de données distribuée pour résoudre automatiquement les échecs impliquant des
transactions distribuées. Le processus RECO d'une instance se connecte automatiquement aux
autres bases de données impliquées dans une transaction distribuée équivoque. Quand le
processus RECO rétablit la connexion entre les serveurs de base de données concernés, il
résout automatiquement les transactions équivoques et supprime de chaque table de
transactions en attente les lignes correspondant aux transactions équivoques résolues.
Si le processus RECO ne parvient pas à se connecter à un serveur distant, il effectue une
nouvelle tentative au bout d'un certain temps. Le délai d'attente avant reconnexion croît de
manière exponentielle.

Processus ARCn (Archiver)
• Il copie les fichiers de journalisation sur le périphérique de

stockage désigné après un changement de fichier de
journalisation.
• Il peut collecter des données de journalisation sur les
transactions et les transmettre à des destinations de
secours.

ARCn
Processus d'archivage Copies des fichiers Destination de l'archive

de journalisation
archivés
Processus ARCn (Archiver)

Les processus d'archivage ARCn copient les fichiers de journalisation (fichiers redo log) sur
le périphérique de stockage désigné après un changement de fichier de journalisation. Ils
interviennent uniquement lorsque la base de données est en mode ARCHIVELOG et que
l'archivage automatique est activé.
Si vous prévoyez une charge d'archivage importante (un chargement de données en masse, par
exemple), vous pouvez augmenter le nombre maximal de processus d'archivage via le
paramètre d'initialisation LOG_ARCHIVE_MAX_PROCESSES. Par ailleurs, il peut y avoir
plusieurs destinations de fichiers de journalisation archivés. Il est recommandé d'avoir au
moins un processus d'archivage par destination. La valeur par défaut est d'avoir quatre
processus d'archivage.

Séquence de démarrage des processus
• Oracle Grid Infrastructure est démarré par le démon init du
système d'exploitation.
Démon d'initialisation
du système Script wrapper Démons et processus
d'exploitation Grid Infrastructure Grid Infrastructure
init ohasd.bin Instance ASM
init.ohasd oraagent.bin Processus
(root) d'écoute
orarootagent.bin
Instance de BdD
diskmon.bin
Applications
cssdagent définies par
ocssd.bin l'utilisateur
• L'installation d'Oracle Grid Infrastructure modifie le fichier

/etc/inittab pour garantir le démarrage chaque fois que
l'ordinateur est démarré dans le niveau d'exécution
correspondant.
# cat /etc/inittab
..
h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
Séquence de démarrage des processus

Au cours de l'installation d'Oracle Grid Infrastructure, une entrée permettant de démarrer un
script wrapper est placée dans le fichier du système d'exploitation /etc/inittab. Ce
script est chargé de configurer les variables d'environnement avant de démarrer les démons et
les processus d'Oracle Grid Infrastructure.
Lorsqu'une commande est utilisée pour arrêter Grid Infrastructure, les démons sont arrêtés,
mais le processus wrapper continue de s'exécuter.
Le format du fichier UNIX /etc/inittab est le suivant :
id : niveaux d'exécution : action : processus et paramètres
Le script wrapper est démarré avec l'action respawn afin qu'il soit redémarré chaque fois qu'il
prend fin.
Après cette opération, certains des démons Oracle Grid Infrastructure s s'exécutent pour le
compte de l'utilisateur root avec une priorité en temps réel, tandis que d'autres s'exécutent
pour le compte du propriétaire d'Oracle Grid Infrastructure avec des priorités correspondant
au mode utilisateur. Sur une plate-forme Windows, les services du système d'exploitation sont
utilisés à la place des scripts d'initialisation wrapper et les démons sont des fichiers binaires
exécutables.
Remarque : L'exécution directe du script wrapper n'est pas prise en charge.

Architecture de stockage de la base de données
Fichiers de Fichiers de Fichiers de

contrôle données journalisation en ligne
Fichier de Fichiers de Fichiers de

paramètres sauvegarde journalisation

archivés
Fichier de mots Fichiers trace et fichier

de passe d'alertes
Architecture de stockage de la base de données

Les fichiers constituant une base de données Oracle sont organisés de la façon suivante :
• Fichiers de contrôle : Ils contiennent des données sur la base elle-même (informations
sur sa structure physique). Ces fichiers sont d'une importance capitale pour la base. Sans
eux, vous ne pouvez pas ouvrir les fichiers de données de la base. Ils peuvent également
contenir des métadonnées relatives aux sauvegardes.
• Fichiers de données : Ils contiennent les données utilisateur ou les données des
applications, ainsi que des métadonnées et le dictionnaire de données.
• Fichiers de journalisation en ligne (online redo logs) : Ils permettent la récupération
d'une instance de base de données. Si le serveur de base de données connaît une
défaillance et qu'aucun fichier de données n'est perdu, l'instance peut récupérer la base à
l'aide des informations contenues dans ces fichiers.
Les fichiers indiqués ci-dessous sont également essentiels au bon fonctionnement de la base
de données :
• Fichier de paramètres : Il est utilisé pour définir la façon dont l'instance est configurée
au démarrage.
• Fichier de mots de passe : Il permet aux utilisateurs sysdba, sysoper et sysasm de
se connecter à distance à la base de données et d'effectuer des tâches d'administration.
• Fichiers de sauvegarde : Ils sont utilisés pour la récupération de la base de données. Les
fichiers de sauvegarde sont généralement restaurés lorsqu'une défaillance physique ou
une erreur utilisateur a endommagé ou supprimé les fichiers d'origine.

Architecture de stockage de la base de données (suite)
• Fichiers de journalisation archivés : Ils contiennent l'historique complet des modifications de
données (informations de journalisation) générées par l'instance. Vous pouvez, à l'aide de ces
fichiers et d'une sauvegarde de la base, restaurer un fichier de données perdu. En d'autres termes,
les fichiers de journalisation archivés permettent de récupérer des fichiers de données restaurés.
• Fichiers trace : Chaque processus serveur ou en arrière-plan peut écrire dans un fichier trace
associé. Lorsqu'un processus détecte une erreur interne, il effectue un dump des informations sur
l'erreur dans son fichier trace. Certaines de ces informations sont destinées à l'administrateur de
base de données, et d'autres au support technique Oracle.
• Fichier d'alertes : Il contient des entrées de trace spéciales. Le fichier d'alertes d'une base de
données est un journal chronologique des messages et des erreurs. Oracle recommande de le
consulter régulièrement.
Remarque : Les fichiers de paramètres, de mots de passe, d'alertes et de trace seront traités dans
d'autres chapitres.

Structures logiques et physiques
d'une base de données
Structures logiques Structures physiques
Base de données
Fichier de
Tablespace
données
Segment
Système de stockage
• SAN • NFS

Extent
• NAS • ASM
• Exadata • RAW
Bloc de
données Oracle • Système de fichiers
Structures logiques et physiques d'une base de données

Une base de données comprend des structures logiques et des structures physiques.
Bases de données, tablespaces et fichiers de données
La diapositive ci-dessus illustre les relations qui existent entre une base de données, ses
tablespaces et ses fichiers de données. Chaque base est divisée d'un point de vue logique en
plusieurs tablespaces. Des fichiers de données sont créés explicitement pour chaque
tablespace afin de stocker physiquement les données de tous les segments. Si le tablespace est
de type TEMPORARY, il n'est pas associé à un fichier de données mais à un fichier temporaire.
Le fichier de données d'un tablespace peut être stocké physiquement sur n'importe quelle
technologie de stockage prise en charge.
Tablespaces
Une base de données est divisée en unités de stockage logiques appelées tablespaces, qui
regroupent des structures logiques ou des fichiers de données connexes. Par exemple, les
tablespaces regroupent généralement tous les objets d'une application afin de simplifier
certaines opérations d'administration.
Blocs de données
Au niveau de détail le plus élevé, les données d'une base Oracle sont stockées dans les blocs
de données. Un bloc de données correspond à un nombre d'octets spécifique d'espace
physique sur le disque. La taille des blocs est définie lors de la création de chaque tablespace.
La base de données utilise et alloue l'espace disponible dans les blocs de données Oracle.

Structures logiques et structures physiques d'une base de données (suite)
Extents
Le terme extent (ensemble de blocs contigus) désigne le niveau suivant de l'organisation logique
d'une base de données. Un extent consiste en un nombre précis de blocs de données contigus
(obtenus dans le cadre d'une allocation unique) qui permettent de stocker un type d'information
particulier. Les blocs de données d'un extent Oracle sont contigus d'un point de vue logique, mais ils
peuvent être répartis physiquement sur le disque en raison du striping RAID et de l'implémentation
du système de fichiers.
Segments
On appelle segment le niveau logique venant immédiatement au-dessus de l'extent. Un segment est
un ensemble d'extents alloués à une structure logique spécifique. Exemples :
• Segments de données : Chaque table qui ne fait pas partie d'un cluster et n'est pas organisée en
index comprend un segment de données, à l'exception des tables internes, des tables temporaires
globales et des tables partitionnées qui comprennent chacune un ou plusieurs segments. Toutes

les données de la table sont stockées dans les extents du segment de données correspondant.
Dans le cas d'une table partitionnée, chaque partition a son propre segment de données. Par
ailleurs, chaque cluster comporte un segment de données, qui contient les données de toutes les
tables incluses dans le cluster.
• Segments d'index : Chaque index comporte un segment d'index dans lequel sont stockées toutes
ses données. Dans le cas d'un index partitionné, chaque partition a son propre segment d'index.
• Segments d'annulation : Un tablespace UNDO est créé pour chaque instance de base de
données. Ce tablespace contient un grand nombre de segments qui stockent temporairement les
informations d'annulation. Les informations contenues dans un segment d'annulation permettent
de générer des informations de base de données cohérentes en lecture et, lors de la récupération
de la base, d'annuler les transactions non validées pour les utilisateurs.
• Segments temporaires : Les segments temporaires sont créés par la base de données Oracle
lorsque l'exécution d'une instruction SQL requiert une zone de travail temporaire. Une fois
l'exécution de l'instruction terminée, les extents du segment temporaire sont rendus à l'instance
en vue d'une utilisation ultérieure. Indiquez un tablespace temporaire par défaut pour chaque
utilisateur, ou un tablespace global à l'échelle de la base de données.
Remarque : Il existe d'autres types de segment non mentionnés ci-dessus. Il existe également des
objets de schéma, tels que les vues, les packages, les déclencheurs, qui ne sont considérés comme des
segments bien qu'il s'agisse d'objets de base de données. Un segment dispose d'un espace disque qui
lui est propre. Les autres objets existent en tant que lignes stockées dans un segment de métadonnées
du système.
Le serveur de base de données Oracle alloue de l'espace de manière dynamique. Lorsque les extents
existants d'un segment sont pleins, d'autres sont ajoutés. Etant donné que les extents sont alloués en
fonction des besoins, ils ne sont pas nécessairement contigus sur le disque. Par ailleurs, ils peuvent
provenir de différents fichiers de données appartenant au même tablespace.

Segments, extents et blocs
• Les segments existent dans un tablespace.

• Les segments sont des ensembles d'extents.
• Les extents sont des ensembles de blocs de données
contigus.
• Les blocs de données sont mis en correspondance avec
des blocs du disque.

Segment Extents Blocs de Blocs du disque
données (stockage dans
le système de
fichiers)
Segments, extents et blocs

Les objets de base de données tels que les tables et les index sont stockés dans les tablespaces
sous forme de segments. Chaque segment contient un ou plusieurs extents. Un extent est
constitué de blocs de données contigus, ce qui signifie qu'il ne peut se trouver que dans un
seul fichier de données. Les blocs de données constituent la plus petite unité d'E/S de la base.
Lorsqu'un ensemble de blocs de données est demandé par la base au système d'exploitation,
ce dernier assure la correspondance avec un bloc réel du système de fichiers ou du disque sur
le périphérique de stockage. Par conséquent, vous n'avez pas besoin de connaître l'adresse
physique des données de la base. Cela signifie également qu'un fichier de données peut être
réparti (striped) ou mis en miroir sur plusieurs disques.
La taille des blocs de données peut être définie lors de la création de la base. La taille par
défaut (8 Ko) convient généralement. Toutefois, si votre base de données prend en charge une
application de data warehouse qui comporte des tables et des index volumineux, il peut être
judicieux de choisir une taille de bloc plus importante.
A l'inverse, si votre base est utilisée avec une application transactionnelle dans laquelle les
lectures et écritures sont aléatoires, vous avez intérêt à définir une taille de bloc inférieure. La
taille maximale des blocs dépend du système d'exploitation utilisé. La taille minimale des
blocs Oracle est de 2 Ko, mais cette valeur est rarement utilisée (voire jamais).
Vous pouvez utiliser des tablespaces présentant une taille de bloc non standard. Pour plus
d'informations, reportez-vous au manuel Oracle Database Administrator's Guide.

Tablespaces et fichiers de données
Tablespace 1 Tablespace 2 (Bigfile)
Fichier de Fichier de Fichier de

données 1 données 2 données 3
8 Ko 8 Ko 8 Ko 8 Ko 8 Ko
8 Ko 8 Ko 8 Ko 8 Ko 8 Ko
Un seul fichier de
8 Ko 8 Ko 8 Ko 8 Ko 8 Ko données autorisé
8 Ko 8 Ko 8 Ko 8 Ko 8 Ko <= 128 To
Extent Extent

64 Ko 96 Ko
Segment
160 Ko
Tablespaces et fichiers de données

Une base de données est divisée en unités de stockage logiques, appelées tablespaces, qui
peuvent être utilisées pour regrouper des structures logiques liées. Chaque base est divisée
logiquement en plusieurs tablespaces : le tablespace SYSTEM et les tablespaces SYSAUX.
Des fichiers de données sont créés explicitement pour chaque tablespace afin de stocker
physiquement les données de toutes les structures logiques.
Le graphique de la diapositive ci-dessus illustre un tablespace comprenant deux fichiers de
données. Un segment de 160 ko composé de deux extents couvre les deux fichiers de données.
Le premier extent de 64 Ko se trouve dans le premier fichier, tandis que le second extent de
96 Ko est dans le deuxième fichier. Les deux extents sont formés de blocs Oracle contigus de
8 Ko.
Remarque : Vous pouvez également créer des tablespaces bigfile comprenant un seul fichier
(de très grande taille en général). La taille de ce fichier n'est limitée que par l'architecture des
row ID (adresses de ligne). La taille maximale est égale à la taille des blocs du tablespace
multipliée par 236, soit 128 To pour des blocs de 32 Ko. Les tablespaces smallfile
traditionnels (utilisés par défaut) contiennent généralement plusieurs fichiers de données,
mais ces fichiers ne peuvent pas être aussi volumineux. Pour plus d'informations sur les
tablespaces bigfile, reportez-vous au manuel Oracle Database Administrator's Guide.

Tablespaces SYSTEM et SYSAUX
• Les tablespaces SYSTEM et SYSAUX sont obligatoires. Ils

sont créés en même temps que la base de données. Ils
doivent être en ligne.
• Le tablespace SYSTEM est utilisé pour les fonctionnalités
principales (les tables du dictionnaire de données, par
exemple).
• Le tablespace auxiliaire SYSAUX sert aux composants de
base de données supplémentaires (tels que le référentiel
Enterprise Manager).

• Il est déconseillé d'utiliser les tablespaces SYSTEM et
SYSAUX pour stocker les données des applications.
Tablespaces SYSTEM et SYSAUX

Chaque base de données Oracle doit contenir un tablespace SYSTEM et un tablespace
SYSAUX. Ceux-ci sont créés automatiquement en même temps que la base. Par défaut, le
système crée un tablespace smallfile. Vous pouvez également créer des tablespaces bigfile
afin de permettre à la base Oracle de gérer des fichiers très volumineux.
Un tablespace peut être en ligne (accessible) ou hors ligne (non accessible). Le tablespace
SYSTEM reste toujours en ligne (online) lorsque la base de données est ouverte. Il stocke les
tables qui prennent en charge les fonctionnalités principales de la base, telles que les tables du
dictionnaire de données.
SYSAUX est un tablespace auxiliaire du tablespace SYSTEM. Il stocke de nombreux
composants de base de données et doit donc être en ligne pour que tous ceux-ci fonctionnent
correctement. Il est déconseillé d'utiliser les tablespaces SYSTEM et SYSAUX pour stocker les
données des applications. Il est préférable de créer des tablespaces supplémentaires.
Remarque : Il est possible de mettre le tablespace SYSAUX hors ligne (offline) à des fins de
récupération, mais cela est impossible pour le tablespace SYSTEM. Aucun des deux ne peut
être configuré pour un accès en lecture seule.

Automatic Storage Management (ASM)
• Il s'agit d'un système de fichiers clusterisé portable aux
performances élevées.
• Il gère les fichiers de base Base de
de données Oracle. Application données
Oracle
• Il gère les fichiers des applications
à l'aide du système de fichiers ACFS
(ASM Cluster File System). Système de
Fichiers
fichiers
ASM pour
• Il répartit les données entre ACFS la base
les différents disques Gestionnaire de
pour équilibrer la charge. de volumes données

dynamiques Oracle
• Il effectue une mise en miroir des ASM
données pour éviter les pertes Automatic Storage Management
en cas d'incident.
Système d'exploitation
• Il facilite la gestion du stockage.
Automatic Storage Management (ASM)

La fonctionnalité Automatic Storage Management (ASM) assure une intégration verticale du
système de fichiers et du gestionnaire de volumes pour les fichiers de base de données Oracle.
ASM permet la gestion d'ordinateurs SMP (multitraitement symétrique) ou de plusieurs
noeuds d'un cluster, afin d'assurer la prise en charge d'Oracle Real Application Clusters
(RAC).
ACFS (Oracle ASM Cluster File System) est un système de fichiers évolutif multi-plateforme
offrant une technologie de gestion du stockage qui étend ASM afin de prendre en charge les
fichiers d'application extérieurs à la base Oracle tels que les exécutables, les états, les objets
BFILE, les fichiers audio, vidéo et texte, les images, etc.
ASM distribue la charge d'entrée/sortie (E/S) entre toutes les ressources disponibles. Il
optimise ainsi les performances et rend inutile le réglage manuel des E/S. Grâce à ASM, les
administrateurs de base de données (DBA) peuvent gérer l'environnement de base de données
de manière dynamique. En effet, ils peuvent augmenter la taille de la base sans avoir à fermer
celle-ci pour ajuster l'allocation de l'espace de stockage.
ASM permet de gérer des copies redondantes des données afin d'assurer la tolérance de panne.
Il peut également être associé à des mécanismes de stockage fiables fournis par les fabricants.
La gestion des données est effectuée en sélectionnant les caractéristiques de fiabilité et de
performances souhaitées pour les différentes classes de données, et non par le biais d'une
interaction humaine fichier par fichier.
Les fonctionnalités ASM permettent aux DBA de gagner du temps grâce à l'automatisation du
stockage. Ces derniers peuvent ainsi gérer des bases de données à la fois plus volumineuses et
plus nombreuses.

Composants de stockage ASM
ASM
Fichier de
Groupe
base de
Fichier ASM de disques
données
ASM
Oracle
Extent ASM
Système

de fichiers
ou Unité
Disque ASM
raw device d'allocation ASM
Composants de stockage ASM

ASM ne supprime aucune des fonctionnalités de base de données précédentes. Les bases
continuent de fonctionner comme avant. Vous pouvez créer les nouveaux fichiers en tant que
fichiers ASM et conserver l'ancienne méthode d'administration pour les fichiers existants, ou
migrer ces derniers vers ASM.
Le schéma de la diapositive ci-dessus illustre les relations entre un fichier de données de la
base Oracle et les composants de stockage ASM. Les connexions en patte d'oie représentent
des relations 1 à n. Un fichier de base de données Oracle présente une relation un à un avec un
fichier du système d'exploitation (stocké dans le système de fichiers) ou avec un fichier ASM.
Un groupe de disques Oracle ASM est un ensemble d'un ou plusieurs disques Oracle ASM
gérés comme une unité logique. Les structures de données d'un groupe de disques sont
autonomes et utilisent une partie de l'espace pour les métadonnées. Les disques ASM Oracle
sont des périphériques de stockage fournis à un groupe de disques ASM qui peuvent être des
disques ou des partitions physiques, une unité logique de stockage (LUN), un volume logique
(LV) ou un fichier réseau. Chaque disque ASM est divisé en plusieurs unités d'allocation
ASM, qui constituent les plus petites quantités d'espace disque contigu pouvant être allouées
par ASM. Lorsque vous créez un groupe de disques ASM, vous pouvez définir la taille de
l'unité d'allocation ASM à 1, 2, 4, 8, 16, 32 ou 64 Mo en fonction du niveau de compatibilité
du groupe de disques. Un extent ASM est composé d'une ou plusieurs unités d'allocation
ASM. Il représente le stockage raw utilisée pour stocker le contenu d'un fichier ASM Oracle.
Un fichier ASM Oracle est constitué d'un ou de plusieurs extents. Des tailles d'extent
variables de 1, 4 ou 16 unités d'allocation sont utilisées pour les fichiers très volumineux.

Interagir avec une base Oracle :
Mémoire, processus et stockage
Instance

Zone de
tampons de à conserver
mémoire
PGA de la base journa-
Processus à recycler
serveur Zone de Zone de Zone de
Processus
d'écoute
DBWn CKPT LGWR SMON PMON RECO ARCn Autres

Processus
utilisateur
Utilisateur
Interagir avec une base de données Oracle

L'exemple suivant décrit le niveau le plus élémentaire des interactions avec la base de
données Oracle. Il utilise une configuration de base de données dans laquelle l'utilisateur et le
processus serveur associé se trouvent sur des ordinateurs distincts connectés via un réseau.
1. Une instance a été démarrée sur un noeud où Oracle Database est installé. Ce noeud est
souvent appelé hôte ou serveur de base de données.
2. Un utilisateur démarre une application qui lance un processus utilisateur. L'application
essaie d'établir une connexion au serveur. (Il peut s'agir d'une connexion locale,
client/serveur ou d'une connexion à trois niveaux (3-tiers) fournie par un niveau
intermédiaire.)
3. Le serveur exécute un processus d'écoute (listener) qui contient le gestionnaire Oracle
Net Services approprié. Le serveur détecte la demande de connexion émise par
l'application et crée un processus serveur dédié pour le compte du processus utilisateur.
4. L'utilisateur exécute une instruction SQL de type LMD (langage de manipulation de
données) et valide la transaction. Par exemple, il change l'adresse d'un client dans une
table et valide la modification dans la base.
5. Le processus serveur reçoit l'instruction et recherche dans la zone de mémoire partagée
(composant SGA) une zone SQL partagée contenant une instruction SQL semblable. S'il
trouve cette zone SQL partagée, le processus serveur vérifie les privilèges de l'utilisateur
pour l'accès aux données demandées et utilise la zone SQL partagée existante pour traiter
l'instruction. A défaut, une nouvelle zone SQL partagée est allouée à l'instruction pour
que celle-ci puisse être analysée et traitée.

Interagir avec une base de données Oracle (suite)
6. Le processus serveur extrait les valeurs de données nécessaires, à partir du fichier de données
réel (table) ou à partir du cache de tampons de la base.
7. Le processus serveur modifie les données dans la mémoire SGA. Comme la transaction est
validée, le processus Log Writer (LGWR) enregistre immédiatement la transaction dans le
fichier de journalisation (fichier redo log). Le processus Database Writer (DBWn) écrit les blocs
modifiés sur le disque au moment opportun.
8. Si la transaction réussit, le processus serveur envoie un message à l'application via le réseau. Si
elle échoue, un message d'erreur est transmis.
9. Tout au long de cette procédure, les autres processus en arrière-plan s'exécutent pour détecter les
conditions nécessitant leur intervention. Par ailleurs, le serveur de base de données gère les
transactions des autres utilisateurs et empêche les problèmes de contention entre les transactions
qui demandent les mêmes données.

Quiz
Processus PMON (Process Monitor) :

1. Il effectue les opérations de récupération au démarrage de
l'instance.
2. Il assure la récupération des processus utilisateur qui ont
échoué.
3. Il résout automatiquement toutes les transactions
équivoques.
4. Il écrit le tampon de journalisation dans un fichier de
journalisation.

Réponse : 2

Quiz
Quels types d'instance accèdent aux fichiers ASM ?

1. Instances SGBDR uniquement
2. Instances ASM uniquement
3. Instances SGBDR et ASM

Réponse : 3

Synthèse
Ce chapitre vous a permis d'apprendre à :

• énumérer les principaux composants de l'architecture d'une
base de données Oracle
• décrire les structures mémoire
• décrire les processus en arrière-plan
• définir la relation entre les structures de stockage logiques
et physiques
• décrire les composants de stockage ASM


Exercice 1 : Présentation
Cet exercice consiste à répondre sur papier à des questions

concernant les sujets suivants :
• Architecture de la base de données
• Mémoire
• Processus
• Structures de fichiers


Installer le logiciel Oracle

Objectifs

• expliquer votre rôle en tant qu'administrateur de base de
données (DBA) et décrire les outils et les tâches que vous
utilisez
• planifier une installation du logiciel Oracle
• installer Oracle Grid Infrastructure pour un serveur
autonome
• installer le logiciel de base de données Oracle Database


Tâches d'un administrateur de base
de données Oracle
L'approche générale adoptée pour la conception, l'implémentation
et la maintenance d'une base de données Oracle comprend
différentes tâches :
1. Evaluer le matériel du serveur de base de données
2. Installer le logiciel Oracle
3. Elaborer une stratégie pour la base de données et la sécurité
4. Créer, migrer et ouvrir la base de données
5. Sauvegarder la base de données
6. Inscrire les utilisateurs système et définir leur accès Oracle

Network
7. Implémenter la conception de la base
de données
8. Récupérer la base de données suite à une panne
9. Surveiller les performances de la base de données
Tâches d'un administrateur de base de données Oracle

Un administrateur de base de données (DBA) est principalement chargé de l'installation du
logiciel Oracle et de la création de la base.
A ce titre, vous pouvez être responsable de la création des structures de stockage telles que les
tablespaces. Vous pouvez également être amené à créer le schéma ou l'ensemble des objets
contenant les données de l'application.
Vous devez vous assurer que la base de données est disponible pour les utilisateurs. Pour cela,
vous devez démarrer la base de données, la sauvegarder régulièrement et contrôler ses
performances. Ces tâches doivent être intégrées dans une stratégie de sécurité.
Vous apprendrez à effectuer chacune de ces opérations au fil des chapitres du cours. Vous
pouvez également vous reporter au manuel Oracle Database Administrator's Guide pour plus
d'informations sur les tâches mentionnées dans la diapositive ci-dessus.
Dans ce chapitre, nous nous intéresserons à la phase d'installation. Cette tâche essentielle
requiert les sous-tâches suivantes :
• Comprendre la place qu'occupe la phase d'installation dans l'architecture technique
globale d'une organisation
• Revoir (et mettre à jour) la planification de la capacité
• Choisir le logiciel de base de données (version et options requises)
• S'assurer que les éléments choisis respectent les exigences système

Outils utilisés pour administrer
une base de données Oracle
• Oracle Universal Installer
• Database Configuration Assistant
• Database Upgrade Assistant
• Oracle Net Manager
• Oracle Net Configuration Assistant
• Oracle Enterprise Manager
• Server Control Utility
• SQL*Plus

• Recovery Manager
• Data Pump
• SQL*Loader
Outils utilisés pour administrer une base de données Oracle

Les outils suivants vous permettent de réaliser les tâches d'installation et de mise à niveau :
• Oracle Universal Installer (OUI) installe le logiciel Oracle et ses options. Il peut lancer
automatiquement Database Configuration Assistant pour créer une base de données.
• Database Configuration Assistant (DBCA) crée une base de données à partir de
modèles fournis par Oracle, ce qui vous permet de copier une base préconfigurée. (Vous
pouvez également créer vos propres modèles et votre propre base.)
• Database Upgrade Assistant (DBUA) vous guide tout au long de la mise à niveau d'une
base Oracle existante vers une nouvelle version.
• Oracle Net Manager (netmgr) permet de configurer la connectivité réseau des bases
de données et applications Oracle.
• Oracle Net Configuration Assistant (NetCA) est un outil graphique de type assistant
qui permet de configurer et de gérer des configurations Oracle Network.

Outils utilisés pour administrer une base de données Oracle (suite)
Les outils suivants vous permettent de gérer l'instance et la base de données Oracle :
• Oracle Enterprise Manager (EM) associe une console graphique, des agents, des services
communs et des outils, fournissant ainsi une plate-forme de gestion système complète et intégrée
pour la gestion des produits Oracle. Une fois le logiciel Oracle installé, la base de données créée
ou mise à niveau et le réseau configuré, vous pouvez utiliser Enterprise Manager comme
interface unique pour gérer votre base. En plus de son interface utilisateur Web qui permet
d'exécuter des commandes SQL, Enterprise Manager fournit une interface avec les autres
composants Oracle utilisés pour administrer la base de données (Recovery Manager et
Scheduler, par exemple).
• Les principaux outils Enterprise Manager utilisés pour administrer une base de données Oracle
sont les suivants :
- Enterprise Manager Database Console pour administrer une seule base de données.
- Enterprise Manager Grid Control pour administrer simultanément plusieurs bases de
données.

• Server Control Utility (srvctl) est une interface de ligne de commande standard qui peut
être utilisée pour démarrer et arrêter la base de données et les instances, gérer des instances
ASM, et déplacer ou supprimer des instances et des services. Vous pouvez également ajouter des
services et gérer les informations de configuration à l'aide de SRVCTL.
• SQL*Plus est une interface de ligne de commande standard permettant de gérer la base de
données.
• Recovery Manager (RMAN) est une solution Oracle complète pour les opérations de
sauvegarde, de restauration et de récupération de l'ensemble de la base de données ou de fichiers
spécifiques.
• Data Pump permet le transfert à grande vitesse de données entre deux bases (par exemple, vous
pouvez avoir besoin d'exporter une table et de l'importer dans une autre base).
• SQL*Loader permet de charger les données d'un fichier externe dans une base Oracle. Vous
pouvez l'utiliser pour charger des données dans des tables de base de données.
• Outils en mode ligne de commande :
- Pour administrer Enterprise Manager :
emctl start | status | stop dbconsole
- Pour administrer le processus d'écoute (listener) :
lsnrctl start | status | stop

Planifier l'installation
• Quel logiciel Oracle allez-vous installer ?

• Le matériel disponible est-il conforme à la configuration
minimale requise ?
• Si vous installez plusieurs produits, un ordre d'installation
particulier est-il conseillé ?
• Existe-t-il des étapes préalables qui doivent être effectuées
par une personne autre que le DBA ?

Planifier l'installation
Avant de commencer à installer un logiciel Oracle, vous devez vous poser les questions
suivantes pour planifier l'installation :
• Quel logiciel Oracle allez-vous installer ?
Ce cours suppose que vous installez la base de données Oracle Database. Oracle
recommande d'utiliser la technologie de stockage ASM (Automatic Storage
Management). Cela implique que vous installiez Oracle Grid Infrastructure à partir des
supports du logiciel de cluster pour disposer à la fois des composants requis pour ASM et
d'Oracle Restart.
• Le matériel disponible est-il conforme à la configuration minimale requise ?
Identifiez tous les équipements impliqués dans le processus d'installation et assurez-vous
qu'ils répondent aux spécifications minimales suggérées.
• Si vous installez plusieurs produits, un ordre d'installation particulier est-il
conseillé ?
Dans la mesure du possible, il est recommandé d'installer Oracle Grid Infrastructure
avant le logiciel Oracle Database. Ainsi, la base de données créée peut être configurée
pour l'utilisation de groupes de disques ASM et elle est enregistrée automatiquement
dans Oracle Restart. Si Oracle Grid Infrastructure est installé après la base de données
Oracle, des étapes de configuration manuelles sont nécessaires pour enregistrer la base
dans Oracle Restart. Si vous voulez que la base de données existante utilise des groupes
de disques ASM comme système de stockage, vous devrez procéder à des opérations de
migration.

Planifier l'installation (suite)
• Existe-t-il des étapes préalables qui doivent être effectuées par une personne autre que le
DBA ?
Selon le principe de séparation des responsabilités, l'administrateur de base de données (DBA)
n'est généralement pas tenu de configurer les équipements et les périphériques de stockage à
utiliser pour l'installation. Certaines tâches de configuration à effectuer avant l'installation
d'Oracle Grid Infrastructure incombent à un administrateur du stockage. Pour plus
d'informations, reportez-vous au manuel Oracle Database Installation Guide.

Installation d'Oracle Grid Infrastructure et d'Oracle
Database : Configuration système requise
• Mémoire :
– 1 Go pour l'instance de base de données avec Oracle
Enterprise Manager Database Control
– 1,5 Go pour l'instance ASM et Oracle Restart
• Espace disque :
– 3 Go d'espace de swap (avec 2 Go de RAM)
– 1 Go d'espace disque dans le répertoire /tmp
– 3,8 Go pour le logiciel Oracle Database
– 4,5 Go pour le logiciel Grid Infrastructure

– 1,7 Go pour la base de données préconfigurée (facultatif)
– 3,4 Go pour la zone de récupération rapide (facultatif)
• Système d'exploitation (voir la documentation)
Installation d'Oracle Grid Infrastructure et d'Oracle Database : Configuration

système requise
• Vous pouvez réaliser une installation standard de la base de données sur un ordinateur
disposant d'au moins 1 Go de RAM et 1,5 Go d'espace de swap. Une installation standard
d'Oracle Grid Infrastructure pour serveur autonome nécessite également 1,5 Go de
mémoire RAM au minimum.
• L'espace de swap requis dépend de la quantité de RAM (par exemple, 3 Go pour 2 Go de
RAM). Reportez-vous au manuel d'installation correspondant à votre système
d'exploitation pour plus de détails.
• L'installation standard du logiciel de base de données Oracle prend 20 minutes au plus,
en fonction du taux d'activité de l'ordinateur cible.
• Voici quelques détails relatifs à l'installation :
- Oracle Database 11g fournit deux modèles de base de données d'origine.
- Les fichiers en double sont supprimés.
- Vous pouvez installer de nombreux autres produits et démonstrations à partir de CD-
ROM supplémentaires.
Le matériel indiqué dans la diapositive ci-dessus correspond à la configuration minimale
requise pour toutes les plates-formes. Votre installation peut cependant nécessiter une
configuration supérieure (notamment en termes d'espace disque).
Remarque : Le terme "installation standard" correspond à une installation Enterprise Edition
qui inclut une base de données d'origine standard.

Préparer le système d'exploitation
Créez les utilisateurs et les groupes du système d'exploitation :
• Groupes :
– oinstall
– dba
– Groupes facultatifs (en cas de séparation des
responsabilités entre plusieurs utilisateurs) :
— oper
— asmdba
— asmoper
— asmadmin

• Utilisateurs :
– Propriétaire du logiciel (généralement oracle)
– Possibilité de créer plusieurs utilisateurs pour installer
plusieurs produits
Préparer le système d'exploitation

Certaines étapes doivent être effectuées par l'administrateur système du matériel que vous
utilisez pour l'installation du logiciel Oracle. Ce cours n'indique pas tous les détails et toutes
les commandes de la configuration du système d'exploitation, d'autant plus que chaque
système d'exploitation a des exigences spécifiques pour le logiciel Oracle. Nous allons
simplement passer en revue quelques points généraux, mais nous vous recommandons de
vous référer à la documentation d'installation correspondant à votre système.
L'une des étapes nécessaires consiste à créer les groupes et les utilisateurs du système
d'exploitation qui sont indispensables pour effectuer l'installation. Les deux groupes
obligatoires sont oinstall et dba. Si vous implémentez la séparation des tâches entre
plusieurs comptes utilisateur, les autres groupes à créer sont oper, asmdba, asmoper et
asmadmin. Vous avez besoin au minimum d'un utilisateur du système d'exploitation pour
jouer le rôle de propriétaire de l'installation Oracle. Dans la plupart des cas, l'utilisateur
oracle est configuré à cet effet. Si vous souhaitez une véritable séparation des fonctions,
vous pouvez avoir des propriétaires distincts pour vos différents produits Oracle.

Définir les variables d'environnement
Variables d'environnement Oracle :
• ORACLE_BASE : Base de la structure de répertoires Oracle.
Il est recommandé de définir cette variable avant
l'installation.
• ORACLE_HOME : Environnement dans lequel les produits
Oracle s'exécutent. Variable non requise avant l'installation
si ORACLE_BASE est définie.
• ORACLE_SID : Cette variable n'est pas nécessaire avant
l'installation, mais elle est utile ensuite pour faciliter
l'interaction avec une instance particulière.

• NLS_LANG : Variable d'environnement facultative qui
contrôle les paramètres relatifs à la langue,
au territoire et au jeu de caractères client.
Définir les variables d'environnement

Un environnement Oracle est défini par de nombreuses variables. Celles qui sont mentionnées
ci-après sont importantes pour une installation réussie et une utilisation efficace d'une base de
données Oracle. Leur définition n'est pas nécessaire mais permet d'éviter des problèmes
ultérieurement.
• ORACLE_BASE : Base de la structure de répertoires Oracle pour l'architecture OFA
(Optimal Flexible Architecture) recommandée par le Support technique Oracle. Cette
variable est facultative, mais elle facilite les mises à niveau et les installations ultérieures.
Sa valeur est un chemin de répertoires, comme l'illustre l'exemple suivant :
/u01/app/oracle
• ORACLE_HOME : Environnement dans lequel les produits Oracle s'exécutent. Il n'est pas
nécessaire de définir cette variable avant l'installation si ORACLE_BASE est définie.
L'outil OUI peut utiliser cette dernière pour déterminer la variable ORACLE_HOME
recommandée pour votre installation. Cette variable d'environnement facilite la
maintenance et la gestion du logiciel Oracle. Sa valeur est un chemin de répertoires,
comme l'illustre l'exemple suivant :
/u01/app/oracle/product/11.2.0/dbhome_1
• ORACLE_SID : Identificateur système associé à une instance Oracle, par exemple orcl
pour une base de données ou +ASM pour une instance ASM. Cette variable n'est pas
nécessaire avant l'installation, mais elle est utile ensuite pour faciliter l'interaction avec
une instance particulière.
• NLS_LANG : Variable d'environnement facultative qui contrôle les paramètres définissant
la langue, le territoire et le jeu de caractères client, par exemple :
AMERICAN_DENMARK.WE8MSWIN1252
Pour plus d'informations sur les langues, territoires et jeux de caractères valides, ainsi que
sur la prise en charge des langues, reportez-vous au manuel Oracle Database
Globalization Support Guide.

Vérifier la configuration système requise
• Espace temporaire
approprié
• 64 bits ou 32 bits
• Système d'exploitation
correct
• Niveau de patch du système d'exploitation
• Packages système
• Paramètres système et paramètres du noyau

• Permissions liées à XServer
• Espace de swap suffisant
• Définition de la variable ORACLE_HOME
Vérifier la configuration système requise

L'outil Oracle Universal Installer automatise la plupart des contrôles de prérequis pour vérifier
les points suivants :
• Espace temporaire minimal pour l'installation et la configuration. Ces exigences sont
validées pendant le processus d'installation.
• Les installations de type 64 bits ne peuvent pas être effectuées dans des répertoires
d'origine Oracle Home dans lesquels des logiciels 32 bits sont déjà installés, et vice-
versa.
• Oracle Grid Infrastructure 11g et Oracle Database 11g sont compatibles avec plusieurs
versions Linux, mais aussi avec d'autres plates-formes.
• Tous les patches requis par le système d'exploitation sont installés.
• Tous les paramètres requis pour le noyau et le système sont correctement définis.
• La variable d'environnement DISPLAY est définie et l'utilisateur possède les
autorisations correspondantes.
• Le système dispose d'un espace de swap suffisant.
• Le répertoire d'origine Oracle Home associé à la nouvelle installation est vide, ou il
correspond à l'une des versions par-dessus lesquelles Oracle Database 11g peut être
installé. Le processus d'installation vérifie également que ces versions sont enregistrées
dans l'inventaire Oracle.

Oracle Universal Installer (OUI)

Oracle Universal Installer (OUI)

Oracle Universal Installer (OUI) est une application Java qui effectue des installations au
niveau composant et permet également de réaliser des installations à différents niveaux de
groupes de logiciels intégrés ou de suites, des installations Web ou encore l'installation d'une
logique complexe via un package unique. Le moteur d'installation est portable sur toutes les
plates-formes Java et les problèmes propres à la plate-forme peuvent être encapsulés à part
dans le processus d'installation global.
OUI fournit les fonctionnalités suivantes pour la gestion et la distribution des logiciels :
• Résolution automatique des dépendances et traitement automatique de la logique
complexe
• Installation à partir du Web
• Installation de composants et de suites
• Désinstallation implicite
• Prise en charge de plusieurs répertoires d'origine Oracle Home
• Prise en charge de la globalisation (fonctionnalités NLS)
• Prise en charge des installations distribuées
• Installations automatiques sans assistance, par l'intermédiaire de fichiers de réponses

Exemple de scénario d'installation
Le scénario d'installation présenté dans ce chapitre est divisé

en deux parties :
• Partie 1 : Installer Oracle Grid Infrastructure pour un
serveur autonome
• Partie 2 : Installer le logiciel Oracle Database

Exemple de scénario d'installation

Le scénario d'installation présenté dans ce chapitre est divisé en deux parties :
• Partie 1 : Installer Oracle Grid Infrastructure pour un serveur autonome
• Partie 2 : Installer le logiciel Oracle Database
Lors de l'installation d'Oracle Grid Infrastructure, les étapes de la configuration des groupes
de disques ASM sont présentées et Oracle Restart est configuré. Oracle Grid Infrastructure est
installé en premier pour que la base de données créée après l'installation du logiciel Oracle
Database soit en mesure d'utiliser les groupes de disques ASM et soit automatiquement
enregistrée dans Oracle Restart.

Partie 1 : Installer Oracle Grid Infrastructure pour
un serveur autonome

Partie 1 : Installer Oracle Grid Infrastructure pour un serveur autonome

Pour installer le logiciel Oracle Grid Infrastructure à l'aide de l'installeur OUI, connectez-vous
à l'ordinateur en tant que membre du groupe d'administration qui est autorisé à installer le
logiciel Oracle, mais aussi à créer et gérer la base de données. Insérez le CD-ROM de
distribution du logiciel de cluster (clusterware) dans le lecteur de CD-ROM ou accédez à
l'emplacement de stockage intermédiaire du clusterware Oracle. Entrez ./runInstaller
pour démarrer l'installeur. Dans la page Installation Option qui apparaît, sélectionnez l'option
Install and Configure Grid Infrastructure for a Standalone Server et cliquez sur Next.

Sélectionner les langues du produit

Sélectionner les langues du produit

La page "Select Product Languages" s'affiche. Pour ajouter une langue à l'installation, cliquez
dessus pour la mettre en évidence, puis utilisez le bouton représentant une flèche vers la droite
pour la déplacer vers la liste "Selected Languages". Vous pouvez sélectionner plusieurs
langues en maintenant la touche Ctrl enfoncée pendant que vous cliquez sur chaque langue.
Cliquez sur Next pour poursuivre l'installation.
Les langues actuellement disponibles sont Arabic, Bengali, Brazilian Portuguese, Bulgarian,
Canadian French, Catalan, Croatian, Czech, Danish, Dutch, Egyptian, English (United
Kingdom), Estonian, Finnish, French, German, Greek, Hebrew, Hungarian, Icelandic,
Indonesian, Italian, Japanese, Korean, Latin American Spanish, Latvian, Lithuanian, Malay,
Mexican Spanish, Norwegian, Polish, Portuguese, Romanian, Russian, Simplified Chinese,
Slovak, Slovenian, Spanish, Swedish, Thai, Traditional Chinese, Turkish, Ukrainian et
Vietnamese.
Remarque : Cette liste est susceptible de subir des modifications.

Créer un groupe de disques ASM

Créer un groupe de disques ASM

La page Create ASM Disk Group est affichée. Oracle Grid Infrastructure comprend la prise en
charge de la technologie de stockage ASM (Automatic Storage Management) et d'Oracle
Restart. L'outil OUI attend pour poursuivre que vous définissiez un groupe de disques ASM.
Dans le champ "Disk Group Name", saisissez le nom du premier groupe à créer. Si la section
"Add Disks" ne contient pas les disques disponibles, cliquez sur le bouton "Change Discovery
Path", puis entrez le chemin d'accès aux disques ASM.
Pour la plupart des environnements, Oracle recommande de créer deux groupes de disques,
mais l'installeur ne peut en créer qu'un à ce stade. Vous pourrez créer le second groupe de
disques ASM après l'installation, à l'aide de l'utilitaire ASM Configuration Assistant (asmca)
ou de SQL*Plus. Cliquez sur le bouton Next pour continuer l'installation.
Remarque : La liste de disques n'est pas vide dans l'exemple illustré ci-dessus car le pilote
ASMLib est configuré. Ce pilote s'applique uniquement aux plates-formes Linux. Sur les
autres plates-formes, il peut être nécessaire d'utiliser le bouton Change Discovery Path.

Définir les mots de passe ASM

Définir les mots de passe ASM

La page Specify ASM Password est affichée. Vous devez fournir un mot de passe pour deux
comptes : SYS et ASMSNMP. Vous avez la possibilité d'utiliser les mêmes valeurs pour les
deux. Contrairement à une base de données, une instance ASM ne contient pas de dictionnaire
de données. Les seules méthodes d'authentification sont donc l'authentification par le système
d'exploitation et l'authentification par fichier de mots de passe. Le compte SYS est ajouté au
fichier de mots de passe (orapw+ASM sous Linux) et se voit accorder les privilèges
SYSDBA, SYSOPER et SYSASM. Le compte ASMSNMP est lui-aussi ajouté au fichier de mots
de passe et obtient uniquement le privilège SYSDBA. Après avoir entré les mots de passe
appropriés, cliquez sur le bouton Next pour continuer l'installation.

Définir les groupes du système d'exploitation
dotés de privilèges

Définir les groupes du système d'exploitation dotés de privilèges

La page "Privileged Operating System Groups" s'affiche. Pour certains groupes du système
d'exploitation, l'utilitaire OUI propose les noms par défaut suivants si l'utilisateur en est un
membre :
• Groupe des administrateurs de base de données (OSDBA) – asmdba
• Groupe des opérateurs d'instance ASM (OSOPER) : asmoper
• Groupe des administrateurs d'instance ASM (OSASM) : asmadmin
Comme cette installation s'applique à un serveur autonome, la pratique courante consiste à
utiliser le même groupe OS pour les trois groupes, tel que dba (voir la diapositive ci-dessus).
Cliquez sur le bouton Next pour continuer l'installation. Cliquez sur Yes en réponse à
l'avertissement qui s'affiche parce que vous utilisez le même groupe du système d'exploitation
pour OSDBA, OSOPER et OSASM.

Indiquer l'emplacement d'installation


La page Specify Installation Location est affichée. Dans le champ Oracle Base, entrez la
valeur de la variable ORACLE_BASE correspondant au propriétaire du logiciel. La valeur par
défaut est /u01/app/oracle. Dans le champ Software Location, entrez la valeur de la
variable ORACLE_HOME correspondant au logiciel Grid Infrastructure. La valeur par défaut
est /u01/app/oracle/product/11.2.0/grid. Cliquez sur le bouton Next pour
continuer l'installation.

Créer l'inventaire

Créer l'inventaire
S'il n'existe pas encore d'inventaire Oracle sur l'ordinateur hôte, la page Create Inventory
s'affiche. Dans le champ Iventory Directory, indiquez l'emplacement où vous souhaitez créer
le répertoire oraInventory. L'emplacement recommandé est
/u01/app/oraInventory. Le répertoire oraInventory doit être situé un niveau au-
dessus du répertoire ORACLE_BASE. Dans la liste de sélection, choisissez le nom du groupe
oraInventory. Le nom recommandé est oinstall. Cliquez sur le bouton Next pour
continuer l'installation.

Effectuer les vérifications de prérequis


La page Perform Prerequisite Checks est affichée. Aucune action n'est requise dans cette
page, à moins que les vérifications ne génèrent des erreurs. Dans ce cas, vous devez corriger
celles-ci pour que le processus puisse se poursuivre. Dans l'exemple ci-dessus, les
vérifications préalables ont rejeté certains paramètres du noyau. Un message vous indique que
vous devez exécuter un script pour corriger ces paramètres, puis effectuer à nouveau les
vérifications. S'il est impossible de résoudre une erreur, vous devez soit corriger le problème
manuellement, soit choisir l'option Ignore All et poursuivre l'installation (si la vérification
ayant échoué n'est pas de niveau critique).
Remarque : Le script runfixup.sh généré par l'outil OUI ne peut pas résoudre toutes les
défaillances. Dans ce cas, une intervention manuelle est nécessaire avant de tenter à nouveau
l'installation.

Vérifier les données récapitulatives de
l'installation

Vérifier les données récapitulatives de l'installation

La page Summary est affichée. Elle récapitule les choix d'installation que vous avez effectués
dans les pages précédentes. Elle propose un bouton permettant de sauvegarder les questions et
réponses relatives à l'installation interactive dans un fichier de réponses. Ce fichier pourra être
utilisé pour effectuer une installation en mode silencieux. Il s'agit d'un fichier texte. Il est
possible de le modifier à l'aide d'un outil d'édition pour l'adapter à différentes installations.
Cliquez sur Finish pour poursuivre l'installation.

Surveiller la progression de l'installation

Surveiller la progression de l'installation

La page Setup permet de suivre la progression de l'installation. Elle indique le statut des
différentes étapes, à savoir la préparation, la copie des fichiers, la liaison des bibliothèques et
la création de fichiers d'installation. Aucune action n'est requise dans cette page, à moins que
l'installation ne génère des erreurs. Dans ce cas, vous devez corriger celles-ci pour que le
processus puisse se poursuivre.

Exécuter les scripts de configuration root

Exécuter les scripts de configuration root

La boîte de dialogue Execute Configuration Scripts s'affiche pour indiquer les scripts de
configuration qui doivent être exécutés en tant qu'utilisateur root. Le script
orainstRoot.sh modifie la permission associée au répertoire Oracle Central Inventory en
octroyant au groupe des droits en lecture et écriture et en supprimant les droits en lecture,
écriture et exécution accordés à world. Le script root.sh copie des fichiers dans le
répertoire /usr/local/bin, crée le fichier /etc/oratab, crée les clés OCR (Oracle
Cluster Repository) pour l'utilisateur grid, lance le démon ohasd et modifie le fichier
/etc/inittab pour qu'il démarre automatiquement le démon ohasd au démarrage de
l'ordinateur. Après avoir exécuté les scripts root, cliquez sur le bouton OK pour retourner à
la page Setup et continuer l'installation.

Exécuter les assistants de configuration

Exécuter les assistants de configuration

Oracle Net Configuration Assistant (NETCA) est appelé via une méthode d'installation
silencieuse pour créer les fichiers de configuration réseau, suivi par Automatic Storage
Management Configuration Assistant (ASMCA) pour créer le groupe de disques ASM et
enregistrer les composants ASM auprès d'Oracle Restart.

Terminer l'installation

Terminer l'installation
La page "Finish" est affichée à la fin de l'installation. Cliquez sur le bouton Close pour fermer
l'utilitaire OUI.

Configurer le groupe de disques FRA

Configurer le groupe de disques FRA

Comme vous ne pouvez configurer qu'un seul groupe de disques lors de l'installation d'Oracle
Grid Infrastructure, vous devez définir manuellement les groupes de disques supplémentaires.
Dans le scénario considéré, le groupe de disques FRA est utilisé pour la zone de récupération
rapide de la base de données. L'utilitaire ASM Configuration Assistant (asmca) fournit une
interface graphique intuitive qui permet de créer ou de supprimer facilement des groupes de
disques ASM.

Quiz
L'installeur OUI effectue toute la configuration requise pour

installer un logiciel Oracle.
1. Vrai
2. Faux

Réponse : 2
Commentaire
Par exemple, les utilisateurs et les groupes du système d'exploitation doivent être créés sous
UNIX et Linux avant l'installation du logiciel.

Quiz
Pendant l'installation de Grid Infrastructure, il est possible de :

1. préciser l'emplacement exact des fichiers de données pour
l'instance ASM
2. créer un seul groupe de disques
3. préciser la taille de la mémoire SGA pour l'instance ASM
4. créer plusieurs groupes de disques

Réponse : 2

Partie 2 : Installer le logiciel Oracle Database

Partie 2 : Installer le logiciel Oracle Database

Examinons à présent les étapes d'installation du logiciel Oracle Database. Comme
précédemment, connectez-vous à votre ordinateur en tant que membre du groupe
d'administration autorisé à installer le logiciel Oracle, mais aussi à créer et gérer la base de
données. Insérez le CD-ROM de distribution de la base de données dans le lecteur de CD-
ROM ou accédez à l'emplacement de stockage intermédiaire de la base. Entrez
./runInstaller à partir de cet emplacement pour démarrer l'installeur OUI (Oracle
Universal Installer). Si vous le souhaitez, indiquez l'adresse e-mail à laquelle vous voulez être
informé des problèmes de sécurité. Si vous voulez recevoir les mises à jour concernant la
sécurité via le site My Oracle Support, indiquez également votre mot de passe pour ce site. Si
vous n'entrez pas votre adresse e-mail, un message d'avertissement vous demande de
confirmer que vous ne voulez pas être informé des problèmes critiques de votre configuration.
Répondez en cliquant sur Yes pour poursuivre l'installation.

Choisir un type d'installation

Choisir un type d'installation

Dans la page Select Installation Option, choisissez l'un des types d'installation suivants et
cliquez sur Next.
• Create and Configure a Database : Cette option crée une base de données une fois le
produit installé.
• Install Database Software Only : Cette option installe uniquement les fichiers binaires
d'Oracle Database.
• Upgrade an Existing Database : Cette option permet de mettre à niveau une base de
données d'une version antérieure.

Choisir les options d'installation de Grid
Infrastructure

Choisir les options d'installation de Grid Infrastructure

Dans la page Grid Installation Option, indiquez si vous voulez installer une base de données
mono-instance ou une base de données RAC (Real Application Cluster). Cliquez sur Next
pour continuer.

Choisir les paramètres de langue

Choisir les paramètres de langue

Dans la page Select Product Languages, sélectionnez toutes les langues dans lesquelles le
produit s'exécutera. L'anglais est la langue par défaut. Elle ne peut être supprimée de la liste
Selected Languages. Cliquez sur Next pour continuer.

Choisir l'édition de la base de données

Choisir l'édition de la base de données

Dans la page Select Database Edition, sélectionnez l'une des trois éditions décrites ci-après :
• Enterprise Edition : Cette édition contient une base de données auto-gérée qui allie
performances, évolutivité, sécurité et fiabilité pour les installations composées de
serveurs en clusters ou d'un seul serveur. Elle comprend des fonctionnalités complètes
permettant de gérer facilement les applications les plus exigeantes, qu'il s'agisse de
traitement de transactions, d'analyse décisionnelle ou de gestion de contenus.
• Standard Edition : Cette édition fournit une base de données aux fonctionnalités
complètes pour les serveurs comptant jusqu'à quatre sockets. Elle inclut Oracle Real
Application Clusters pour une disponibilité accrue, et fournit des fonctions de gestion des
performances et de la sécurité à l'échelle de l'entreprise. Elle est simple à gérer et peut
facilement évoluer en fonction de la demande. Elle fournit une compatibilité descendante
avec la version Enterprise Edition.
• Standard Edition One : Cette édition fournit une base de données aux fonctionnalités
complètes pour des serveurs comprenant jusqu'à deux sockets. Elle fournit des fonctions
de gestion des performances et de la sécurité à l'échelle de l'entreprise qui peuvent
facilement évoluer en fonction de la demande. Elle fournit une compatibilité descendante
avec les autres versions de base de données.
Cliquez sur le bouton Select Options pour poursuivre la personnalisation des composants à
installer. Une fois les sélections terminées, cliquez sur Next.



Dans la page Installation Location, un chemin Oracle Base par défaut est affiché, mais vous
pouvez le modifier si nécessaire. Dans la section Software Location, vous pouvez accepter les
valeurs par défaut ou entrer le nom et le chemin du répertoire d'origine Oracle Home dans
lequel vous souhaitez installer les composants Oracle. Ce dernier ne doit pas contenir
d'espaces. Cliquez sur Next pour poursuivre le processus d'installation.

Choisir des groupes du système d'exploitation

Choisir des groupes du système d'exploitation

Dans la page Privileged Operating System Groups, choisissez le groupe du système
d'exploitation approprié pour les privilèges OSDBA et OSOPER. Par défaut, les privilèges
OSDBA et OSOPER sont respectivement affectés aux groupes dba et oper. Dans l'exemple
considéré, le groupe dba est utilisé dans les deux cas car il s'agit d'une installation autonome
qui n'implémente pas la séparation des tâches. Cliquez sur Next pour continuer.



Dans la page Perform Prerequisite Checks, OUI effectue différentes vérifications requises
avant l'installation. Lorsque toutes les vérifications sont terminées, il renvoie les informations
relatives aux éventuelles erreurs détectées. Aucune action n'est requise dans cette page, à
moins que les vérifications ne génèrent des erreurs. Si certaines vérifications échouent, vous
obtenez une page dans laquelle vous pouvez cliquer sur Fix & Check Again pour que
l'installeur génère un script qui corrige toutes les erreurs réparables. Si une erreur n'est pas
réparable par l'installeur, vous devez soit la corriger manuellement, soit sélectionner Ignore
All et poursuivre l'installation (à condition que le problème ne soit pas critique).

Page récapitulative de l'installation

Page récapitulative de l'installation

La page Summary présente les informations associées aux réponses d'installation fournies
dans les fenêtres précédentes. Elle propose un bouton permettant de sauvegarder les questions
et réponses relatives à l'installation interactive dans un fichier de réponses. Ce fichier pourra
être utilisé pour effectuer une installation en mode silencieux similaire à celle que vous venez
d'effectuer. Il s'agit d'un fichier texte. Il est possible de le modifier à l'aide d'un outil d'édition
pour l'adapter à différentes installations. Cliquez sur Finish pour poursuivre l'installation.

Page Install Product

Page Install Product

A ce stade, le processus d'installation est suspendu. Il vous invite à exécuter un script de
configuration supplémentaire en tant qu'utilisateur root. Ouvrez une fenêtre de terminal et
entrez les commandes suivantes :
$ su
# password: oracle <mot de passe root, n'apparaît pas dans la fenêtre>
# /u01/app/oracle/product/11.2.0/dbhome_1/root.sh
Lors d'une installation Linux ou UNIX, acceptez le répertoire bin local par défaut. Lorsque
l'exécution des scripts est terminée, quittez le compte root et fermez la fenêtre, puis cliquez
sur OK dans la boîte de dialogue Execute Configuration scripts pour permettre à l'installation
de se conclure.

Installation terminée

Installation terminée
Lorsque toutes les étapes d'installation sont terminées, la page Finish s'affiche. Cliquez sur le
bouton Close pour fermer l'utilitaire OUI.

Option d'installation : Mode automatique
Pour installer et configurer des produits Oracle en mode

automatique à l'aide d'OUI, effectuez les opérations suivantes :
1. Préparez un fichier de réponses :
– en utilisant l'un des modèles de fichier fournis avec
le logiciel Oracle
– en enregistrant vos réponses pendant une procédure

d'installation dans OUI, à l'aide du bouton Save Response File
de la page Summary
2. Exécutez OUI en mode automatique ou semi-automatique.
./runInstaller –silent –responsefile <filename>
Si nécessaire, exécutez NetCA et DBCA en mode automatique.
Option d'installation : Mode automatique

Pour installer et configurer des produits Oracle en utilisant OUI en mode automatique ou
semi-automatique :
1. Préparez un fichier de réponses. Pour cela, vous disposez des modèles de fichier fournis
pour chaque produit et type d'installation (enterprise.rsp, standard.rsp ou
netca.rsp, par exemple). Si ces modèles ne sont pas adaptés à votre scénario, vous
pouvez exécuter OUI en mode interactif et enregistrer un fichier de réponses que vous
pouvez ensuite modifier et réutiliser pour effectuer des installations en mode automatique
ou semi-automatique. Pour créer un fichier de réponses pendant une installation
interactive, cliquez sur le bouton Save Response File dans la page Summary de
l'installeur OUI.
2. Exécutez OUI en mode automatique ou semi-automatique. Exécutez
$ORACLE_BASE/oraInventory/orainstRoot.sh et
$ORACLE_HOME/root.sh à la fin de l'installation. Si vous avez effectué une
installation de type "logiciel seul", exécutez Oracle Net Configuration Assistant (NetCA)
et Database Configuration Assistant (DBCA) en mode automatique ou non interactif, si
cela s'avère nécessaire.
Pour plus d'informations, reportez-vous au manuel Oracle Database Installation Guide propre
à votre système d'exploitation.

Quiz
Choisissez la définition correcte d'un fichier de réponses.

1. Fichier binaire qui peut être modifié à l'aide d'un
programme d'édition approprié
2. Fichier binaire qui peut être créé par le programme
d'installation
3. Fichier texte créé par le programme d'installation qui ne
peut pas être édité
4. Fichier texte qui peut être modifié dans un éditeur de texte

Réponse : 4

Quiz
Quels groupes pouvez-vous affecter pendant l'installation du

logiciel Oracle Database ?
1. osoper
2. osasm
3. osdba
4. osadmin

Réponses : 1, 3

Synthèse

• expliquer votre rôle en tant qu'administrateur de base de
données (DBA) et décrire les outils et les tâches que vous
utilisez
• planifier une installation du logiciel Oracle
• installer Oracle Grid Infrastructure pour un serveur
autonome
• installer le logiciel de base de données Oracle


Présentation de l'exercice 2 :
Préparer l'environnement de base de données
Cet exercice traite de l'installation du logiciel Oracle à l'aide
d'Oracle Universal Installer (OUI).
Remarque : Vous devez absolument effectuer cet exercice

avant d'aborder les exercices des chapitres suivants.


Créer une base de données Oracle à l'aide
de DBCA

Objectifs

• créer une base de données à l'aide de l'assistant DBCA
(Database Configuration Assistant)
• générer des scripts de création de base de données avec
l'assistant DBCA
• gérer les modèles de conception de base de données à
l'aide de DBCA
• effectuer d'autres tâches avec DBCA


Planification de la base de données
En tant qu'administrateur de base de données, vous devez

planifier les éléments suivants :
• La structure de stockage logique de la base et son
implémentation physique :
– De combien de disques disposez-vous ? Quel type de
stockage est utilisé ?
– De combien de fichiers de données aurez-vous besoin ?
(prévoir l'expansion de la base de données)
– Combien de tablespaces utiliserez-vous ?
– Quels types d'informations seront stockés ?

– Etes-vous confronté à des exigences de stockage
particulières en termes de type ou de taille ?
• La conception globale de la base de données
• La stratégie de sauvegarde de la base de données
Planification de la base de données

Il est essentiel de prévoir la manière dont la structure de stockage logique de la base de
données affectera les performances du système et les différentes opérations de gestion de la
base. Par exemple, avant de créer des tablespaces dans la base, vous devez identifier le
nombre de fichiers de données qui composeront chaque tablespace, le type d'information
stocké dans chaque tablespace, ainsi que les disques sur lesquels stocker physiquement les
fichiers de données. Les informations relatives à la disponibilité du stockage NAS (Network
Attached Storage) et à la bande passante nécessaire au réseau de stockage privé sont
importantes. Si vous prévoyez d'utiliser des réseaux de stockage (SAN), il est utile de
connaître la configuration des volumes logiques et la taille des stripes.
Lors de la planification du stockage logique global de la structure de base de données, tenez
compte de l'incidence que pourra avoir cette structure lorsque la base sera créée et en cours
d'exécution. Certains objets peuvent présenter des exigences de stockage particulières, en
termes de type ou de taille.
Dans les environnements de base de données distribués, cette phase de planification est
extrêmement importante. L'emplacement physique des données auxquelles les utilisateurs
accèdent fréquemment affecte de manière considérable les performances des applications.
Pendant la phase de planification, élaborez une stratégie de sauvegarde de la base. Vous
pouvez modifier la structure de stockage logique ou la conception de la base de données de
manière à accroître l'efficacité des opérations de sauvegarde. Les stratégies de sauvegarde
seront abordées dans un autre chapitre.

Bases de données : Exemples
• Bases généralistes ou transactionnelles :

– Système OLTP (traitement des transactions en ligne) tel que
le système de facturation d'une société de services ou d'une
crèche
• Bases personnalisées :
– Base de données plurifonctionnelle (combinaison de
fonctionnalités OLTP et de data warehouse, par exemple)
• Data warehouse :
– Recherche et marketing

– Impôts et taxes
– Listes de professionnels agréés (médecins, infirmières, etc.)
Bases de données : Exemples

Les différents types de base de données disposent de leur propre instance et imposent leurs
exigences particulières en matière de stockage. Le logiciel Oracle Database fournit des
modèles permettant la création de ces différents types de base. Ces modèles sont les suivants :
• General purpose : Bases généralistes ou transactionnelles permettant par exemple de
traiter des transactions et de les stocker pour une durée moyenne.
• Custom : Bases personnalisées qui ne correspondent à aucun des modèles General
purpose et Data warehouse.
• Data warehouse : Stockage des données sur le long terme et extraction des données lors
d'opérations de lecture.
Les informations de cette page et de la page précédente présentent des considérations qui vous
intéressent en tant qu'administrateur de base de données (DBA). Ce cours est entièrement
conçu pour vous aider à les analyser.

Choisir le jeu de caractères approprié
• La base de données Oracle prend en charge différentes

classes de système d'encodage de caractères :
– Jeux de caractères mono-octets
— 7 bits
— 8 bits
– Jeux de caractères multioctets, tels que Unicode
• Le jeu de caractères est sélectionné lors de la création de
la base de données. Sélectionnez le jeu de caractères qui
répond le mieux à vos besoins métier présents et à venir,

car il peut être difficile de le modifier ultérieurement.
• En règle générale, Unicode est recommandé car il s'agit du
jeu de caractères le plus souple.
Choisir le jeu de caractères approprié

Lorsque les systèmes informatiques traitent les caractères, ils utilisent des codes numériques
plutôt que la représentation graphique du caractère. Un jeu de caractères encodé met en
correspondance des codes numériques avec des caractères qu'un ordinateur ou un terminal
peut afficher et recevoir. Différents jeux de caractères prennent en charge différents
répertoires de caractères. Etant donné que les jeux de caractères sont généralement basés sur
un système d'écriture particulier, ils peuvent prendre en charge plusieurs langues. Cependant,
les jeux de caractères basés sur une écriture sont limités aux groupes de langues présentant
des similitudes. Les jeux de caractères universels englobent la plupart des systèmes d'écriture
modernes et offrent une solution plus intéressante pour la prise en charge multilingue. Pour
plus d'informations sur Unicode, consultez le site Web http:www.unicode.org.
La base de données Oracle prend en charge trois classes de systèmes d'encodage : mono-octet,
multioctet de longueur variable et universel. Sélectionnez le jeu de caractères qui répond le
mieux à vos besoins métier présents et à venir, car il peut être difficile de le modifier
ultérieurement. Pour obtenir les meilleures performances, choisissez un jeu qui n'entraîne pas
de conversion et qui utilise l'encodage le plus efficace par rapport aux langues souhaitées. Les
jeux de caractères mono-octets fournissent de meilleures performances que les jeux
multioctets et ils ont besoin de moins d'espace. En revanche, ils prennent en charge un
nombre de langues limité. Pour choisir un jeu de caractères approprié, évaluez vos besoins
métier actuels et futurs, ainsi que les impératifs techniques (par exemple, les standards XML
et Java requièrent un encodage Unicode). En règle générale, Oracle recommande l'utilisation
du jeu de caractères Unicode pour toutes les nouvelles bases de données, car il est le plus
souple et évite les conversions ultérieures.

Choisir le jeu de caractères approprié (suite)
Jeux de caractères mono-octets
Dans un jeu de caractères mono-octet, chaque caractère occupe un octet. Les systèmes d'encodage
mono-octets à 7 bits peuvent définir jusqu'à 128 (27) caractères et ceux à 8 bits peuvent définir
jusqu'à 256 (28) caractères.
Exemples de jeux de caractères mono-octets
Jeux de caractères à 7 bits :
• American Standard Code for Information Interchange (ASCII) 7-bit American (US7ASCII)
Jeux de caractères à 8 bits :
• International Organization for Standards (ISO) 8859-1 West European (WE8ISO8859P1)
• DEC 8-bit West European (WE8DEC)
• Extended Binary Coded Decimal Interchange Code (EBCDIC) Code Page 1144 8-bit Italian
(I8EBCDIC1144)

Jeux de caractères multioctets
Dans un jeu de caractères multioctet de longueur variable, un caractère est représenté par un ou
plusieurs octets. Les jeux de caractères multioctets sont couramment utilisés pour les langues
asiatiques. Certains systèmes d'encodage multioctets utilisent la valeur du bit de poids fort pour
indiquer si un octet représente à lui seul un caractère ou s'il fait partie d'une série d'octets représentant
un caractère. D'autres systèmes distinguent les caractères mono-octets des caractères multioctets. Un
code de contrôle spécial, envoyé par un périphérique, indique que les octets suivants sont des
caractères à deux octets, jusqu'à ce qu'un code spécial soit rencontré. Les systèmes d'encodage
prenant en charge les codes de contrôle sont utilisés essentiellement sur les plates-formes IBM.
Unicode est un jeu de caractères encodé universel permettant le stockage des informations de
n'importe quelle langue avec un jeu unique. Il associe à chaque caractère un code unique qui ne
dépend ni de la plate-forme, ni du programme, ni de la langue.
La norme Unicode a été adoptée par de nombreux fournisseurs de logiciels et de matériels. Elle est
désormais prise en charge par de nombreux systèmes d'exploitation et navigateurs. XML, Java,
JavaScript, LDAP et WML exigent le jeu de caractères Unicode, lequel est également synchronisé
avec la norme ISO/IEC 10646.
Exemples de jeux multioctets de longueur variable
• Shift-JIS 16-bit Japanese (JA16SJIS)
• MS Windows Code Page 950 with Hong Kong Supplementary Character Set HKSCS-2001
(ZHT16HKSCS)
• Unicode 4.0 UTF-8 Universal character set (AL32UTF8) - Type d'encodage à longueur variable
et sur-ensemble strict d'ASCII.
• Unicode (ALl16UTF16 - Encodage Unicode sur 16 bits utilisé par Microsoft Windows 2000 et
Windows XP.

Utilisation des jeux de caractères
• Oracle Net compare le paramètre NLS_LANG du client au

jeu de caractères défini sur le serveur.
• Si nécessaire, la conversion a lieu de façon automatique et
transparente.
NLS_LANG

Oracle Net
Client Serveur
Utilisation des jeux de caractères

Le paramètre NLS_LANG définit le système d'encodage des caractères utilisé sur un terminal
client. Différents clients peuvent utiliser différents systèmes d'encodage. Les données
échangées entre le client et le serveur sont converties automatiquement d'un système à un
autre. Le système d'encodage de la base de données doit être un sur-ensemble (ou un
équivalent) de tous les systèmes d'encodage des clients. La conversion est transparente pour
l'application client.
Lorsque le jeu de caractères de la base et celui du client sont identiques, la base suppose que
les données envoyées et reçues utilisent le même jeu. Par conséquent, aucune validation ou
conversion n'est effectuée.
Une conversion de jeu de caractères peut être requise dans un environnement client/serveur si
une application client réside sur une plate-forme différente du serveur et si les plates-formes
n'utilisent pas les mêmes systèmes d'encodage de caractères. Les données alphanumériques
transmises entre le client et le serveur doivent être converties d'un système d'encodage à
l'autre. La conversion de caractères a lieu de façon automatique et transparente via Oracle
Net.

Problèmes à éviter
Exemple :
NLS_LANG
AL32UTF8 Oracle Net
Client Serveur
Windows US Jeu de caractères
Page de codes : WE8MSWIN1252 de la base de données :
AL32UTF8

Aucune conversion n'a lieu car cela ne semble pas nécessaire.
Problème : Des données non valides sont entrées dans la
base.
Problèmes à éviter
L'insertion de données non valides dans une base de données résulte généralement d'une
configuration incorrecte du paramètre NLS_LANG sur le client. La valeur de ce paramètre
doit refléter l'encodage des données entrantes.
• Lorsque le paramètre NLS_LANG est défini correctement, la base peut convertir
automatiquement les données entrantes provenant du système d'exploitation du client.
• Lorsque le paramètre NLS_LANG n'est pas défini correctement, les données entrées dans
la base ne sont pas converties de façon appropriée.
Par exemple, supposons que le jeu de caractères de la base de données soit AL32UTF8, que
le client utilise le système d'exploitation Windows en langue anglaise (page de
code WE8MSWIN1252) et que la valeur du paramètre NLS_LANG du client soit AL32UTF8.
Les données envoyées par le client sont donc encodées en WE8MSWIN1252, mais la base ne
les convertit pas car la valeur de NLS_LANG correspond à son jeu de caractères. La base
Oracle considère par conséquent que la conversion n'est pas nécessaire et il se peut que des
données non valides y soient introduites.

Assistant DBCA

Assistant DBCA
L'assistant DBCA (Database Configuration Assistant) vous aide à effectuer différentes
opérations. Vous pouvez l'utiliser pour créer une base de données, modifier sa configuration
ou la supprimer. Vous pouvez créer une base de données à partir d'une liste de modèles
prédéfinis, ou utiliser comme modèle une base de données existante pour créer une autre base
ou un autre modèle.
DBCA fournit plusieurs options pour vous permettre de créer une base de données adaptée à
vos besoins. Il affiche une série de pages où vous entrez les informations de configuration. La
plupart de ces pages proposent des paramètres par défaut que vous pouvez accepter ou
modifier. La procédure à suivre pour créer une base de données à l'aide de DBCA est décrite
ci-après.
1. Connectez-vous à l'ordinateur en tant que membre du groupe d'administrateurs système
(DBA) autorisés à installer le logiciel Oracle. Si nécessaire, définissez des variables
d'environnement et entrez dbca pour appeler l'assistant DBCA. Dans la page d'accueil
principale qui apparaît, cliquez sur Next pour continuer.
2. Choisissez l'action que vous voulez effectuer. Sélectionnez Create a Database, puis
cliquez sur Next pour commencer l'opération.

Utiliser DBCA pour créer une base de données


3. Database Templates : Sélectionnez le type de modèle à utiliser pour la création de la
base. Vous avez à votre disposition trois modèles (General Purpose or Transaction
Processing, Custom Database et Data Warehouse), qui copient une base préconfigurée
avec ses fichiers de données. Ces fichiers de données comprennent des fichiers de
contrôle, des fichiers de journalisation (redo log) et des fichiers de données propres aux
différents tablespaces inclus. Cliquez sur Show Details afin de voir la configuration de
chaque type de base de données.
Pour les environnements plus complexes, vous pouvez choisir l'option Custom Database.
4. Database Identification : Dans le champ Global Database Name, entrez le nom global
de base de données sous la forme database_name.domain_name. Dans le champ
SID, indiquez l'identificateur du système. Par défaut, le SID est le nom de la base de
données et il identifie de manière unique l'instance associée à la base.

Permet de configurer des
tâches de maintenance
automatiques telles que la
collecte de statistiques pour
5 l'optimiseur et la génération
d'états proactifs par des
fonctions de conseil.

La configuration
d'Enterprise Manager pour
votre base de données
nécessite la configuration
d'un processus d'écoute.
Utiliser DBCA pour créer une base de données (suite)

5. Management Options : Dans cette page, configurez la base de données de manière à
pouvoir la gérer avec Oracle Enterprise Manager. Sélectionnez l'option par défaut
"Configure the Database with Enterprise Manager". De manière facultative, vous pouvez
configurer des notifications d'alertes et des propriétés quotidiennes de sauvegarde sur
disque. L'option Register with Grid Control est grisée si l'assistant DBCA ne détecte pas
d'agent Enterprise Manager Grid Control avec lequel il peut communiquer.
Remarque : Le gestionnaire de configuration d'Enterprise Manager pour la base de
données a besoin qu'un processus d'écoute soit configuré (pour le cours, il a été configuré
lors de l'installation d'Oracle Grid Infrastructure).
6. Database Credentials : Dans cette page, indiquez les mots de passe des comptes
d'administration, tels que SYS et SYSTEM. Dans le cadre de ce cours, utilisez
oracle_4U comme mot de passe pour tous les comptes d'administration.

Vous avez le choix
entre le système de
fichiers et ASM (si
ASM est disponible). 7
Créez plusieurs
copies des fichiers de
journalisation et
fichiers de contrôle si
vous le souhaitez. 8

Ajustez les variables de localisation des
fichiers (ORACLE_BASE,
ORACLE_HOME, DB_NAME,
DB_UNIQUE_NAME, SID) si nécessaire.

7. Database File Locations : Dans le champ Storage Type, sélectionnez le type de
mécanisme de stockage que doit utiliser la base de données, à savoir Automatic Storage
Management (ASM) ou File System. Dans la zone Storage Locations, choisissez l'option
correspondant à vos besoins. Dans l'exemple, il s'agit de Oracle-Managed Files (OMF)
car ASM est le mécanisme de stockage utilisé. Le bouton Browse vous permet de
visualiser les groupes de disques disponibles et de sélectionner le plus approprié
(+DATA est sélectionné dans l'exemple de la diapositive ci-dessus). Ensuite, vous êtes
invité à fournir le mot de passe ASMSNMP correspondant à ASM. Oracle Managed Files
(OMF) peut également être utilisé avec le stockage dans le système de fichiers. Cela
évite d'avoir à gérer directement les fichiers du système d'exploitation dans une base de
données Oracle. Si vous le souhaitez, vous pouvez créer des copies supplémentaires des
fichiers de journalisation et des fichiers de contrôle en cliquant sur le bouton Multiplex
Redo Logs and Control Files. Le bouton File Location Variables permet d'ajuster les
variables définissant l'emplacement des fichiers : ORACLE_BASE, ORACLE_HOME,
DB_NAME, DB_UNIQUE_NAME et SID.



8. Recovery Configuration : Choisissez les options de récupération de votre base de
données. Pour configurer la zone de récupération rapide, cochez la case Specify Flash
Recovery Area et indiquez l'emplacement et la taille de cette zone. Dans l'exemple ci-
dessus, la zone de récupération rapide utilise le groupe de disques ASM +FRA et sa taille
est de 4452 Mo. Il est recommandé que la taille de la zone de récupération rapide soit
supérieure à celle de la base de données. Enfin, vous pouvez configurer l'archivage et les
paramètres liés à l'archivage à partir de cet écran.
Remarque : La zone de récupération rapide est désormais appelée "fast recovery area"
en anglais, mais vous pouvez encore trouver l'ancien nom "flash recovery area" dans les
écrans de certains produits Oracle.
9. Database Content : Cette page fournit des options permettant de sélectionner des
composants tels que les exemples de schéma (Sample Schemas), ainsi qu'un onglet
Custom Scripts dans lequel vous pouvez indiquer les scripts personnalisés à exécuter
après la création de la base de données.

10
B

Afficher et modifier les
paramètres d'initialisation

10. Initialization Parameters : Dans les différents onglets de cette page, vous pouvez
modifier les paramètres par défaut de la base de données :
- Memory : Utilisez cette page pour définir les paramètres d'initialisation qui
contrôlent l'utilisation de la mémoire. Vous avez le choix entre une allocation de
mémoire standard ou personnalisée : (A) Typical ou (B) Custom.
- Sizing : Pour indiquer la taille des blocs, entrez une taille en octets ou acceptez la
valeur par défaut.
- Character Sets : Cette page permet de définir les jeux de caractères de la base de
données.
- Recommandation : Oracle Corporation recommande (lorsque cela est possible)
d'utiliser Unicode comme jeu de caractères de base de données. En effet, ce système
de codage fournit une souplesse optimale pour la prise en charge des technologies
Web et de nombreuses langues.
- Connection Mode : Sélectionnez Dedicated ou Shared Server Mode. Pour plus
d'informations, reportez-vous au chapitre intitulé "Configurer l'environnement
réseau Oracle".
• Cliquez sur le bouton All Initialization Parameters pour afficher tous les paramètres
d'initialisation en vue de les modifier éventuellement.
Remarque : Plusieurs paramètres d'initialisation sont configurés une seule fois et sont
applicables pour toute la durée de vie de la base, par exemple DB_BLOCK_SIZE.

11
12


11. Database Storage : Vérifiez les paramètres de stockage de la base de données et
modifiez-les si nécessaire. Si vous avez sélectionné l'un des modèles préconfigurés,
vous ne pouvez pas ajouter ni supprimer des fichiers de contrôle ou des fichiers de
données.
12. Creation Options : Vous pouvez choisir de créer la base de données immédiatement,
d'enregistrer la définition de base de données en tant que modèle ou de générer des
scripts. Si vous sélectionnez toutes ces options et cliquez sur Finish, l'assistant DBCA
commence par enregistrer le modèle de base de données. Il génère ensuite les scripts
dans le répertoire de destination et crée enfin la base de données.

Récapitulatif de la base de données à créer
13

Récapitulatif de la base de données à créer

13. Lorsque vous cliquez sur Finish, vous accédez à une page de confirmation qui vous
permet de vérifier la configuration de la base de données avant sa création. Cliquez sur
OK pour quitter cette page et lancer la création de la base.
Remarque : Vous pouvez enregistrer la définition de base de données dans un fichier
HTML pour pouvoir vous y référer facilement.

Gestion des mots de passe
14

Gestion des mots de passe

14. Une fois les étapes de l'assistant DBCA terminées, notez les informations suivantes afin
de vous y référer ultérieurement :
- Emplacement des fichiers journaux d'installation
- Nom global de la base de données
- Identificateur du système (SID)
- Nom et emplacement du fichier de paramètres serveur
- URL d'Enterprise Manager
Cliquez sur Password Management pour déverrouiller les comptes de base de données
que vous prévoyez d'utiliser. Lorsque vous déverrouillez un compte, fournissez un mot
de passe. Les comptes que vous ne déverrouillez pas à ce stade pourront l'être
ultérieurement si nécessaire.

Créer un modèle de conception de base de données

Créer un modèle de conception de base de données

Un modèle est une définition de base de données pré-enregistrée que vous utilisez comme
point de départ pour créer une nouvelle base. Si vous ne créez pas de modèle dans le cadre du
processus de création de base de données, vous pouvez le faire à tout moment en appelant
l'assistant DBCA et en choisissant l'opération Manage Templates.
Vous pouvez créer un modèle de trois manières :
• A partir d'un modèle existant
• A partir d'une base de données existante (structure uniquement)
• A partir d'une base de données existante (structure et données)
L'assistant DBCA vous guide tout au long du processus de création d'un modèle de base de
données.
Si vous n'avez plus besoin d'un certain modèle, vous pouvez le supprimer à l'aide de l'option
"Delete a database template" dans la page Template Management de l'assistant DBCA.
Remarque : Les modèles que vous avez définis s'affichent dans la liste Database Templates
lorsque vous créez une autre base de données à l'aide de DBCA.

Utiliser DBCA pour supprimer une base de données

Utiliser DBCA pour supprimer une base de données

Démarrez l'assistant DBCA en entrant dbca dans une fenêtre de terminal, puis cliquez sur
Next dans la page Welcome. Pour supprimer une base de données, procédez de la manière
suivante :
1. Dans la page Operations, sélectionnez Delete a Database, puis cliquez sur Next.
2. Sélectionnez la base de données à supprimer (hist dans l'exemple ci-dessus), puis
cliquez sur Finish.
3. Cliquez sur Yes pour confirmer la suppression.
4. Lorsque la suppression est terminée, vous êtes invité à indiquer si vous souhaitez
effectuer une autre opération. Sélectionnez la réponse de votre choix.
Remarque : La base de données à supprimer doit être active afin que l'assistant DBCA puisse
s'y connecter pour déterminer l'emplacement des fichiers.

Utiliser l'assistant DBCA pour supprimer une base de données (suite)
Lorsque vous supprimez une base de données, vous supprimez également ses fichiers de données, ses
fichiers de journalisation (fichiers redo log), ses fichiers de contrôle et ses fichiers de paramètres
d'initialisation. Vous pouvez également supprimer une base de données manuellement à l'aide de
l'instruction SQL DROP DATABASE. En effet, cette instruction supprime tous les fichiers de
contrôle, ainsi que tous les autres fichiers de base de données répertoriés dans ceux-ci. Pour que
l'instruction DROP DATABASE s'exécute correctement, toutes les conditions suivantes doivent être
satisfaites :
• La base de données doit être montée et fermée.
• La base de données doit être montée en mode exclusif (et non en mode partagé).
• La base de données doit avoir démarré en mode RESTRICT.
Exemple d'instruction DROP DATABASE :
STARTUP RESTRICT FORCE MOUNT;
DROP DATABASE;

L'instruction DROP DATABASE n'a aucune incidence sur les fichiers de journalisation archivés, ni sur
les copies ou les sauvegardes de la base de données. Il est préférable d'utiliser Recovery Manager
(RMAN) pour supprimer ces fichiers. Si la base de données se trouve sur des disques bruts (raw), les
fichiers spéciaux de ces disques ne sont pas supprimés.

Autres tâches effectuées via l'assistant DBCA

Autres tâches effectuées via l'assistant DBCA

Vous pouvez utiliser DBCA pour configurer des options de base de données (comme Oracle
Label Security ou Oracle Database Vault). Certaines options ne sont pas installées par défaut
lors de l'installation du logiciel de base de données. Dans ce cas, vous devez les installer avant
de configurer la base pour leur utilisation.
Remarque
• Pour plus d'informations sur Oracle Label Security, reportez-vous au manuel Oracle
Label Security Administrator's Guide.
• Pour plus d'informations sur Oracle Database Vault, reportez-vous au manuel Oracle
Database Vault Administrator's Guide.

Quiz
Le paramètre DB_BLOCK_SIZE est défini pour toute la durée

de vie d'une base de données et ne peut pas être modifié.
1. Vrai
2. Faux

Réponse : 1

Quiz
Pour pouvoir être supprimée à l'aide de la commande DROP

DATABASE, une base de données doit être :
1. ouverte en mode RESTRICT
2. montée exclusivement en mode RESTRICT
3. arrêtée avec l'option immediate

Réponse : 2

Synthèse

• créer une base de données à l'aide de l'assistant DBCA
(Database Configuration Assistant)
• générer des scripts de création de base de données avec
l'assistant DBCA
• gérer les modèles de conception de base de données à
l'aide de DBCA
• effectuer d'autres tâches avec DBCA


Utiliser l'assistant DBCA
Dans cet exercice, vous allez :

• créer la base de données ORCL à l'aide de l'assistant DBCA
• déverrouiller le schéma HR
Remarque : Vous devez impérativement créer la base de
données et déverrouiller le schéma HR avant d'aborder les
exercices des chapitres suivants.
• créer le modèle de conception de base de données ORCL
à l'aide de DBCA

• créer des scripts de création de base de données à l'aide
de DBCA

Gérer l'instance de base de données

Objectifs

• démarrer et arrêter la base de données et les composants
Oracle
• utiliser Oracle Enterprise Manager
• accéder à une base de données à l'aide de SQL*Plus
• modifier les paramètres d'initialisation d'une base de
données
• décrire les étapes du démarrage d'une base de données

• décrire les options d'arrêt d'une base de données
• afficher le fichier d'alertes
• accéder aux vues dynamiques des performances

Structure de gestion
Composants de la structure de gestion d'Oracle Database 11g

Release 2 :
• Instance de base de données
• Processus d'écoute
• Interface de gestion :
– Database Control
– Agent de gestion (lors de l'utilisation de Grid Control)

Agent de ou
gestion
Database Processus
Control d'écoute
Interface de gestion
Structure de gestion
Les trois principaux composants de la structure de gestion de base de données Oracle sont les
suivants :
• Instance de base de données à gérer.
• Processus d'écoute (listener) permettant les connexions à la base de données.
• Interface de gestion, qu'il s'agisse d'un agent de gestion qui s'exécute sur le serveur de
base de données (et le connecte à Oracle Enterprise Manager Grid Control) ou de
l'interface Oracle Enterprise Manager Database Control autonome. Cette interface est
également appelée Database Console.
Vous devez démarrer chacun de ces composants pour pouvoir utiliser ses services. Vous
devez également fermer chacun d'eux correctement lorsque vous arrêtez le serveur qui
héberge la base Oracle.

Démarrer et arrêter Database Control
$ . oraenv
ORACLE_SID = [orcl] ? orcl
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_home1
is /u01/app/oracle
$ emctl start dbconsole
Oracle Enterprise Manager 11g Database Control Release 11.2.0.1.0
Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved.
http://host01.example.com:1158/em/console/aboutApplication
Starting Oracle Enterprise Manager 11g Database Control ........started.
----------------Logs are generated in directory
/u01/app/oracle/product/11.2.0/db_home1/host01.example.com_orcl/sysman/
log

$ emctl stop dbconsole
Oracle Enterprise Manager 11g Database Control Release 11.2.0.1.0
Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved.
https://host01.example.com:1158/em/console/aboutApplication
Stopping Oracle Enterprise Manager 11g Database Control ...
... Stopped.
Démarrer et arrêter Database Control

Pour les bases de données qui ne sont pas connectées à la structure Grid Control, Oracle
fournit une console de gestion autonome appelée Database Control. Chaque base de données
gérée à l'aide de cette console comprend une installation Database Control distincte. A partir
d'une console Database Control, vous ne pouvez gérer qu'une seule base. Avant d'utiliser
Database Control, assurez-vous qu'un processus dbconsole est démarré.
Commande de démarrage du processus dbconsole :
emctl start dbconsole
Commande d'arrêt du processus dbconsole :
emctl stop dbconsole
Commande permettant d'afficher le statut du processus dbconsole :
emctl status dbconsole
Remarque : Il se peut que vous deviez accéder à votre répertoire $ORACLE_HOME/bin si
celui-ci ne se trouve pas dans le chemin du système d'exploitation. Si Grid Infrastructure est
installé, il existe deux emplacements $ORACLE_HOME contenant chacun l'utilitaire emctl.
Cet utilitaire doit toujours être appelé à partir du répertoire $ORACLE_HOME de la base de
données Oracle (et non du répertoire $ORACLE_HOME de Grid Infrastructure). Database
Control utilise un processus agent côté serveur. Celui-ci démarre et s'arrête automatiquement
en même temps que le processus dbconsole.

Oracle Enterprise Manager

Oracle Enterprise Manager

Lorsque vous installez le logiciel Oracle Database, l'installeur OUI (Oracle Universal
Installer) installe également Oracle Enterprise Manager. Son interface Database Control basée
sur le Web constitue l'outil principal de gestion de la base Oracle. Enterprise Manager fournit
une interface graphique permettant d'effectuer presque toutes les tâches dont vous êtes chargé
en tant qu'administrateur de base de données (DBA). Grâce à Enterprise Manager, vous
pouvez notamment afficher des récapitulatifs d'alertes et des graphiques de performances,
créer et modifier des objets et effectuer des opérations de sauvegarde et de récupération. Dans
la plupart des cas, il suffit de cliquer sur des liens dans Enterprise Manager pour accéder à des
informations plus détaillées sur le contenu d'une page.
Remarque : Dans Oracle Database 11g Release 2, l'URL d'accès à Enterprise Manager utilise
le protocole HTTPS (au lieu de HTTP) pour garantir la sécurité de la connexion. Pour accéder
à dbconsole, vous devez donc entrer une URL de la forme suivante :
https://machine_name:port/em
Pour la première base de données que vous créez sur un ordinateur, l'accès à Enterprise
Manager Database Control utilise par défaut le port 1158, mais vous pouvez indiquer un
numéro différent, notamment si le même hôte héberge plusieurs bases. Pour déterminer le
numéro de port à indiquer, consultez le fichier portlist.ini situé dans le répertoire
$ORACLE_HOME/install, qui répertorie les ports correspondant à quelques applications
Oracle Database.

Oracle Enterprise Manager (suite)
Lorsque vous entrez l'URL d'Enterprise Manager, le contenu qui s'affiche dépend du statut de la base
de données :
• Si la base de données est en service (Up), Enterprise Manager affiche la page Database Control
Login.
Connectez-vous à la base via un nom utilisateur autorisé à accéder à Database Control. Il s'agit
initialement de SYS, SYSMAN ou SYSTEM. Utilisez le mot de passe que vous avez indiqué pour
ce compte pendant l'installation de la base. Dans le champ Connect As, sélectionnez soit
Normal, soit SYSDBA pour vous connecter à la base avec des privilèges d'administration
spéciaux.
• Si la base de données est hors service (Down), Enterprise Manager affiche la page
"Startup/Shutdown and Perform Recovery". Dans ce cas, cliquez sur le bouton
Startup/Shutdown. Vous êtes alors invité à indiquer le nom utilisateur et le mot de passe de
connexion aux bases de données hôte et cible.

Remarque : Si vous rencontrez des difficultés pour démarrer Enterprise Manager, vérifiez qu'un
processus d'écoute (listener) est démarré.

Page d'accueil de la base de données
Pages de propriétés

Page d'accueil de la base de données

La page d'accueil de la base de données montre l'état général en cours de la base à l'aide de
diverses mesures de performances. Cliquez sur les différents onglets pour accéder aux pages
de propriétés Performance, Availability, Server, Schema, Data Movement et Software and
Support afin de gérer votre base.
La page d'accueil de la base de données fournit les informations de performances et de statut
suivantes pour l'instance de base de données :
• Nom de l'instance, version de la base de données, emplacement du répertoire d'origine
Oracle Home, options de restauration physique et autres données pertinentes relatives à
l'instance
• Disponibilité de l'instance en cours
• Alertes en suspens
• Informations de performances relatives aux sessions et aux instructions SQL
• Principales mesures d'utilisation de l'espace
• Liens avec hiérarchisation descendante (par exemple, LISTENER_<host_name>)
fournissant des informations de plus en plus détaillées

Composants
Autres outils Oracle > SQL*Plus
Param. d'init.
Démarrage BdD
Arrêt BdD
• SQL*Plus fournit à votre base de données Fichier d'alertes
Vues de perf.
une interface supplémentaire qui vous permet
d'effectuer les tâches suivantes :
– Effectuer des opérations de gestion de base de données
– Exécuter des commandes SQL pour interroger la base de
données ou pour insérer, mettre à jour et supprimer des
données dans la base
• SQL Developer :
– Interface graphique permettant d'accéder à votre instance

Oracle Database
– Prise en charge du développement en SQL et PL/SQL
– Disponible dans l'installation par défaut d'Oracle Database
Autres outils Oracle

Outre Enterprise Manager, vous pouvez utiliser SQL*Plus et SQL Developer pour exécuter
des instructions SQL. Ces outils vous permettent d'effectuer un grand nombre d'opérations de
gestion de base de données, ainsi que de sélectionner, d'insérer, de mettre à jour ou de
supprimer des données dans la base.
SQL*Plus est un programme en mode ligne de commande qui permet d'exécuter des
instructions SQL et PL/SQL sur une base de données Oracle. Vous pouvez soumettre ces
instructions en mode interactif ou sous la forme de scripts SQL*Plus. SQL*Plus est installé
avec la base de données et se trouve dans le répertoire $ORACLE_HOME/bin.
Vous pouvez démarrer SQL*Plus à partir d'une ligne de commande ou du menu Démarrer
(Start) sur un client Windows.
SQL Developer est une interface graphique qui vous permet d'accéder à votre instance Oracle
Database. Elle prend en charge les langages de développement SQL et PL/SQL. Elle est
disponible dans l'installation par défaut d'Oracle Database.
SQL Developer vous permet de parcourir les objets de la base de données, d'exécuter des
instructions et des scripts SQL, de modifier et de déboguer des instructions PL/SQL. Vous
avez également la possibilité d'exécuter des états prédéfinis, ou de créer et d'enregistrer vos
propres états.
Remarque : Ce cours utilise Enterprise Manager et SQL*Plus.

Utiliser SQL*Plus
SQL*Plus est :
• un outil en mode ligne de commande
• utilisé en mode interactif ou en mode batch
$ sqlplus hr
SQL*Plus: Release 11.2.0.1.0 - Production on Thu Jun 18 05:04:49 2009

Copyright (c) 1982, 2009, Oracle. All rights reserved.
Enter Password: *******
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining

and Real Application Testing options
SQL> select last_name from employees;

LAST_NAME
-------------------------
Abel
Ande
…
Utiliser SQL*Plus
Vous pouvez utiliser l'interface en mode ligne de commande de SQL*Plus pour exécuter des
commandes SQL*Plus, SQL et PL/SQL afin d'effectuer les tâches suivantes :
• Entrer, modifier, exécuter, stocker, extraire et enregistrer des commandes SQL et des
blocs PL/SQL.
• Mettre en forme, calculer, stocker et afficher les résultats des interrogations.
• Répertorier les définitions des colonnes d'une table.
• Envoyer des messages à un utilisateur final et accepter les réponses de cet utilisateur.
• Administrer la base de données.
Pour démarrer SQL*Plus :
1. Ouvrez une fenêtre sur un terminal.
2. A l'invite de commande, entrez la commande SQL*Plus suivante :
$ sqlplus <userid>/<pwd> or /nolog
3. Si vous utilisez l'option NOLOG, vous devez entrer la commande CONNECT suivie du
nom utilisateur avec lequel vous voulez vous connecter.
SQL> connect <username>
4. Lorsque vous y êtes invité, entrez le mot de passe de l'utilisateur. SQL*Plus démarre et
établit une connexion à la base de données par défaut.

Appeler SQL*Plus à partir d'un script shell
$ ./batch_sqlplus.sh

Connected to:
Sortie
# Name of this file: batch_sqlplus.sh
SQL> # Count employees and give raise.
COUNT(*) sqlplus hr/hr <<EOF
---------- select count(*) from employees;
107 update employees set salary = salary*1.10;
SQL> commit;

107 rows updated. quit
SQL> EOF
Commit complete.
SQL> Disconnected from Oracle Database 11g Enterprise Edition Release
11.2.0.1.0 - Production
$
Appeler SQL*Plus à partir d'un script shell

Vous pouvez appeler SQL*Plus à partir d'un script shell ou d'un fichier BAT. Pour cela, vous
devez appeler sqlplus et utiliser la syntaxe de génération de script du système
d'exploitation pour transmettre les paramètres.
Dans l'exemple de la diapositive ci-dessus, les instructions SELECT, UPATE et COMMIT sont
exécutées avant que SQL*Plus ne redonne le contrôle au système d'exploitation.

Appeler un script SQL à partir de SQL*Plus
script.sql select * from departments where location_id = 1400;

quit
Sortie
$ sqlplus hr/hr @script.sql

Connected to:

DEPARTMENT_ID DEPARTMENT_NAME MANAGER_ID LOCATION_ID
------------- ------------------------------ ---------- -----------
60 IT 103 1400
Disconnected from Oracle Database 11g Enterprise Edition Release

11.2.0.1.0 - Production
Appeler un script SQL à partir de SQL*Plus

Vous pouvez appeler un fichier script SQL existant à partir de SQL*Plus. Cette opération peut
être effectuée sur la ligne de commande, lorsque vous appelez SQL*Plus pour la première fois
(voir la diapositive ci-dessus). Elle peut également être réalisée depuis une session SQL*Plus,
en entrant simplement l'opérateur "@". Par exemple, la commande suivante exécute le script à
partir d'une session SQL*Plus déjà établie :
SQL> @script.sql
Remarque : Les fichiers script SQL ont par défaut l'extension .sql. Quand un script est
enregistré à partir de SQL*Plus à l'aide de la commande save, cette extension est fournie
automatiquement. Vous pouvez exécuter ces scripts sans préciser l'extension dans la
commande d'exécution. Par exemple :
SQL> @script

Composants
Fichiers de paramètres d'initialisation SQL*Plus
> Param. d’init.
Démarrage BdD
Arrêt BdD
Fichier d'alertes
Vues de perf.

spfileorcl.ora
ou
initorcl.ora
Fichiers de paramètres d'initialisation

Lorsque vous démarrez l'instance, un fichier de paramètres d'initialisation est lu. Il existe deux
types de fichier de paramètres :
• Fichier de paramètres serveur (SPFILE) : Il s'agit du type de fichier de paramètres
d'initialisation préféré. Ce fichier binaire est accessible en lecture et en écriture par le
serveur de base de données et il ne doit pas être modifié manuellement. Il se trouve sur le
serveur où l'instance Oracle s'exécute et il est conservé lorsque l'instance est arrêtée puis
redémarrée. Le nom par défaut de ce fichier (recherché automatiquement au démarrage)
est spfile<SID>.ora.
• Fichier de paramètres d'initialisation au format texte : Ce type de fichier de
paramètres d'initialisation peut être lu par le serveur de base de données, mais il n'est pas
accessible en écriture par le serveur. Pour être persistantes suite aux opérations d'arrêt et
de démarrage, les valeurs des paramètres d'initialisation doivent être définies et modifiées
manuellement à l'aide d'un éditeur de texte. Le nom par défaut de ce fichier (recherché
automatiquement au démarrage si aucun fichier SPFILE n'est trouvé) est
init<SID>.ora.
Il est recommandé de créer un fichier SPFILE pour pouvoir gérer les paramètres
d'initialisation de manière dynamique.
Remarque : Sous Linux, la base de données Oracle recherche les fichiers d'initialisation dans
le répertoire $ORACLE_HOME/dbs. Avec ASM, le fichier SPFILE est souvent stocké sur un
groupe de disques ASM. Dans ce cas, il doit exister dans le répertoire $ORACLE_HOME/dbs
un fichier init<SID>.ora qui indique l'emplacement du fichier SPFILE.

Fichiers de paramètres d'initialisation (suite)
Types de valeur des paramètres d'initialisation
Le serveur de base de données Oracle reconnaît les types de valeur suivants pour les paramètres
d'initialisation :
• Boolean
• String
• Integer
• Parameter file
• Reserved
• Big Integer
Valeurs des paramètres dérivés
Certains paramètres d'initialisation sont dérivés, c'est-à-dire que leurs valeurs sont calculées à partir
des valeurs d'autres paramètres. Normalement, vous ne devez pas modifier les valeurs des paramètres
dérivés.

Si vous le faites, la valeur que vous indiquez remplace la valeur calculée.
Par exemple, la valeur par défaut du paramètre SESSIONS est dérivée du paramètre PROCESSES.
Si la valeur de PROCESSES change, la valeur par défaut du paramètre SESSIONS change
également, sauf si vous imposez une autre valeur.
Valeurs des paramètres dépendants du système d'exploitation
Les valeurs ou fourchettes de valeurs valides de certains paramètres d'initialisation dépendent du
système d'exploitation hôte. Par exemple, le paramètre DB_FILE_MULTIBLOCK_READ_COUNT
définit le nombre maximal de blocs lus en une seule opération d'E/S pendant une analyse
séquentielle. Sa valeur dépend de la plate-forme utilisée. La taille de ces blocs (définie par le
paramètre DB_BLOCK_SIZE) a une valeur par défaut qui dépend du système d'exploitation.
Définir les valeurs des paramètres
Les paramètres d'initialisation constituent le moyen le plus puissant pour optimiser les performances
du système. Certains paramètres définissent des limites de capacité sans affecter les performances.
Ainsi, lorsque le paramètre OPEN_CURSORS a la valeur 10, un processus utilisateur qui essaie
d'ouvrir son onzième curseur reçoit un message d'erreur. D'autres paramètres ont une incidence sur
les performances, mais n'imposent pas de limites absolues. Par exemple, une valeur inférieure du
paramètre OPEN_CURSORS peut réduire les performances des travaux, mais n'empêche pas leur
exécution.
En augmentant les valeurs de ces paramètres, vous pouvez optimiser les performances du système.
Cependant, cela entraîne également l'extension de la zone de mémoire partagée (SGA). Or, une telle
extension peut optimiser les performances de la base jusqu'à un certain point. Dans les systèmes
d'exploitation qui utilisent de la mémoire virtuelle, une zone partagée SGA surdimensionnée peut
nuire aux performances en cas d'opérations de swap. Les paramètres du système d'exploitation qui
contrôlent les zones de mémoire virtuelle actives doivent être configurés en fonction de la taille de la
mémoire SGA. La configuration du système d'exploitation peut également limiter la taille maximale
de la mémoire SGA.

Paramètres d'initialisation simplifiés
Paramètres de base Paramètres avancés
CONTROL_FILES DB_CACHE_SIZE

DB_BLOCK_SIZE DB_FILE_MULTIBLOCK
PROCESSES _READ_COUNT
UNDO_TABLESPACE SHARED_POOL_SIZE
… …
Paramètres d'initialisation simplifiés

Les paramètres d'initialisation sont de deux types : paramètres de base et paramètres avancés.
Dans la plupart des cas, il suffit de définir et régler les 30 paramètres de base pour obtenir des
performances satisfaisantes de la base de données. Dans de rares cas, il peut s'avérer
nécessaire de modifier les paramètres avancés pour obtenir des performances optimales. Il
existe environ 314 paramètres avancés.
Le terme "paramètre de base" désigne un paramètre que vous pouvez avoir à définir pour
assurer les bonnes performances de la base de données. Tous les autres paramètres sont
considérés comme des paramètres avancés.
Exemples de paramètres de base :
• Définir le nom global de la base de données : DB_NAME et DB_DOMAIN
• Indiquer une zone de récupération rapide et sa taille : DB_RECOVERY_FILE_DEST et
DB_RECOVERY_FILE_DEST_SIZE
• Définir la taille totale de tous les composants de la mémoire SGA : SGA_TARGET
• Indiquer la méthode de gestion du tablespace d'annulation : UNDO_TABLESPACE
• Paramètre d'initialisation COMPATIBLE et compatibilité irréversible
Remarque : Les pages suivantes décrivent quelques-uns des paramètres d'initialisation. Vous
trouverez la liste complète dans le manuel Oracle Database Reference.

Paramètres d'initialisation : Exemples
Paramètre Signification
CONTROL_FILES Un ou plusieurs noms de fichier de contrôle
DB_FILES Nombre maximal de fichiers de base de données
PROCESSES Nombre maximal de processus utilisateur du

système d'exploitation pouvant se connecter
simultanément
DB_BLOCK_SIZE Taille de bloc de base de données standard

utilisée par tous les tablespaces
DB_CACHE_SIZE Taille du cache de tampons de bloc standard

Le paramètre CONTROL_FILES définit un ou plusieurs noms de fichier de contrôle. Oracle
recommande vivement de multiplexer et de mettre en miroir les fichiers de contrôle. Plage de
valeurs : un à huit noms de fichier (avec chemin d'accès). La valeur par défaut dépend du
Le paramètre DB_FILES définit le nombre maximal de fichiers de base de données qui
peuvent être ouverts pour la base. La plage de valeurs dépend du système d'exploitation.
Valeur par défaut : 200.
Le paramètre PROCESSES définit le nombre maximal de processus utilisateur du système
d'exploitation qui peuvent se connecter simultanément à un serveur Oracle. Cette valeur doit
être suffisante pour tous les processus en arrière-plan et processus utilisateur. Plage de
valeurs : entre 6 et une valeur maximale qui varie en fonction du système d'exploitation.
Valeur par défaut : 100.
Le paramètre DB_BLOCK_SIZE définit la taille (en octets) d'un bloc de base de données
Oracle. Cette valeur est définie lors de la création de la base et ne peut pas être modifiée
ultérieurement. Elle indique la taille de bloc standard de la base de données. Il s'agit de la
taille utilisée par défaut pour tous les tablespaces. Plage de valeurs : 2048 à 32768 (en
fonction du système d'exploitation). Valeur par défaut : 8192.
Le paramètre DB_CACHE_SIZE définit la taille du cache de tampons (buffer cache) de bloc
standard. Plage de valeurs : au moins 16 Mo. Valeur par défaut : 0 si le paramètre
SGA_TARGET est défini, sinon la plus grande des deux valeurs 48 et 4*cpu_count.

Espace Espace
de pile Mémoire de pile Mémoire
UGA UGA
PGA PGA

Zone de
tampons de de à conserver
mémoire
la base journa-
à recycler
Zone de Zone de
Zone de mémoire

mémoire mémoire Cache de tampons
LARGE POOL de blocs de taille nK
Java Streams
SGA_TARGET (taille totale de tous les composants SGA)

MEMORY_TARGET (mémoire totale utilisable à l'échelle du système)
Paramètres d'initialisation : Exemples (suite)

SGA_TARGET définit la taille totale de tous les composants de la mémoire SGA (System
Global Area). Si sa valeur est précisée, les zones de mémoire suivantes sont dimensionnées
automatiquement :
• Cache de tampons (DB_CACHE_SIZE)
• Zone de mémoire partagée (SHARED_POOL_SIZE)
• Zone de mémoire LARGE POOL (LARGE_POOL_SIZE)
• Zone de mémoire Java (JAVA_POOL_SIZE)
• Zone de mémoire Streams (STREAMS_POOL_SIZE)
Si ces zones de mémoire dimensionnées automatiquement ont une taille différente de zéro,
cette taille est utilisée comme valeur minimale par la gestion automatique de la mémoire
partagée (ASMM - Automatic Shared Memory Management). Vous définissez des valeurs
minimales si un composant d'application a besoin d'un minimum de mémoire pour
fonctionner correctement.
ASMM n'a aucune incidence sur les zones suivantes qui sont dimensionnées manuellement :
• Tampon de journalisation (redo log buffer)
• Autres caches de tampons, tels que KEEP et RECYCLE, et autres tailles de bloc
• Mémoire SGA fixe et autres allocations internes
La mémoire allouée à ces zones est déduite de la mémoire totale disponible pour
SGA_TARGET quand ASMM est activé.
Remarque : Pour prendre en charge ASMM, le processus MMON (Manageability Monitor)
calcule les valeurs des zones de mémoire réglées automatiquement.

MEMORY_TARGET indique la mémoire utilisable à l'échelle du système Oracle. La base de données
assure le réglage en fonction de cette valeur, réduisant ou augmentant les zones SGA et PGA en
conséquence.
Dans un fichier de paramètres d'initialisation de type texte, si vous omettez MEMORY_MAX_TARGET
et indiquez une valeur pour MEMORY_TARGET, la base de données affecte automatiquement cette
valeur à MEMORY_MAX_TARGET. Si vous omettez la ligne de MEMORY_TARGET et indiquez une
valeur pour MEMORY_MAX_TARGET, le paramètre MEMORY_TARGET prend par défaut la valeur
zéro. Après le démarrage, vous pouvez affecter dynamiquement à MEMORY_TARGET une valeur
différente de zéro, à condition qu'elle ne dépasse pas la valeur de MEMORY_MAX_TARGET. Vous
modifiez MEMORY_TARGET à l'aide de la commande ALTER SYSTEM. Les valeurs possibles sont
comprises entre 152 Mo et MEMORY_MAX_TARGET.

Paramètre Signification
PGA_AGGREGATE_TARGET Quantité de mémoire PGA allouée à tous les

processus serveur
SHARED_POOL_SIZE Taille de la zone de mémoire partagée (en octets)
UNDO_MANAGEMENT Mode de gestion du volume d'annulation à utiliser


Le paramètre PGA_AGGREGATE_TARGET indique la quantité de mémoire PGA (Program
Global Area) allouée à tous les processus serveur liés à l'instance. Cette mémoire ne réside
pas dans la mémoire SGA (System Global Area). La base de données utilise ce paramètre
pour définir la quantité cible de mémoire PGA à utiliser. Lorsque vous le définissez,
soustrayez la mémoire SGA de la quantité de mémoire totale du système disponible pour
l'instance Oracle. La valeur de ce paramètre est un nombre entier suivi de la lettre K, M ou G
indiquant si la limite est exprimée en kilo-octets, en mégaoctets ou en gigaoctets. La valeur
minimale est 10 Mo, la valeur maximale est (4096 Go - 1). La valeur par défaut est 10 Mo ou
20 % de la taille de la mémoire SGA si ce pourcentage est supérieur à 10 Mo.
Le paramètre SHARED_POOL_SIZE définit la taille de la zone de mémoire partagée, en
octets. Cette zone contient des objets tels que les curseurs partagés, les procédures stockées,
les structures de contrôle et les mémoires tampons des messages d'exécution en parallèle. La
plage de valeurs dépend du système d'exploitation. Valeur par défaut : 0 si le paramètre
SGA_TARGET est défini, sinon 128 Mo en 64 bits et 48 Mo en 32 bits.
Le paramètre UNDO_MANAGEMENT indique le mode de gestion du volume d'annulation que
le système doit utiliser. Si ce paramètre a la valeur AUTO, l'instance est démarrée en mode de
gestion automatique des annulations (AUM - Automatic Undo Management). Sinon, elle est
démarrée en mode RBU (Rollback Undo). En mode RBU, le volume d'annulation est alloué
de manière externe sous forme de segments d'annulation (rollback segments). En mode AUM,
le volume d'annulation est alloué de manière externe sous forme de tablespaces d'annulation.
Plage de valeurs : AUTO ou MANUAL. Si le paramètre UNDO_MANAGEMENT est omis lors du
démarrage de la première instance, la valeur par défaut AUTO est utilisée.

Utiliser SQL*Plus pour afficher les paramètres
SQL> SELECT name , value FROM V$PARAMETER;
NAME VALUE
------------ ----------
lock_name_space 2
processes 150
sessions 247
timed_statistics TRUE
timed_os_statistics 0
…
SQL>SHOW PARAMETER SHARED_POOL_SIZE

NAME TYPE VALUE
------------------------------------ ----------- ---------------------
shared_pool_size big integer 0
SQL> show parameter para

NAME TYPE VALUE
------------------------------------ ----------- ---------------------
fast_start_parallel_rollback string LOW
parallel_adaptive_multi_user boolean TRUE
parallel_automatic_tuning boolean FALSE
parallel_execution_message_size integer 16384
parallel_instance_group string
…
Utiliser SQL*Plus pour afficher les paramètres

La diapositive ci-dessus présente quelques exemples utilisant SQL*Plus pour afficher des
paramètres. Vous pouvez interroger la vue du dictionnaire de données V$PARAMETER pour
obtenir les valeurs des différents paramètres. V$PARAMETER affiche la valeur des paramètres
dans la session en cours. Vous pouvez également entrer la commande SHOW PARAMETER
suivie d'une chaîne pour afficher les paramètres contenant cette chaîne.
L'interrogation ci-après demande le nom et la valeur des paramètres. Utilisez une clause
WHERE pour appliquer l'interrogation à des paramètres spécifiques :
SQL> SELECT name, value FROM V$PARAMETER WHERE name LIKE
'%pool%';
NAME VALUE
------------------------- ----------
shared_pool_size 0
large_pool_size 0
java_pool_size 0
streams_pool_size 0
shared_pool_reserved_size 8808038
buffer_pool_keep
…
9 rows selected.

Utiliser SQL*Plus pour afficher les paramètres (suite)
Description de la vue :
SQL> desc V$parameter
Name Null? Type
---------------------------------------- ------- -------------
NUM NUMBER
NAME VARCHAR2(80)
TYPE NUMBER
VALUE VARCHAR2(4000)
DISPLAY_VALUE VARCHAR2(4000)
ISDEFAULT VARCHAR2(9)
ISSES_MODIFIABLE VARCHAR2(5)
ISSYS_MODIFIABLE VARCHAR2(9)
ISINSTANCE_MODIFIABLE VARCHAR2(5)
ISMODIFIED VARCHAR2(10)
ISADJUSTED VARCHAR2(5)
ISDEPRECATED VARCHAR2(5)

ISBASIC VARCHAR2(5)
DESCRIPTION VARCHAR2(255)
UPDATE_COMMENT VARCHAR2(255)
HASH NUMBER
L'exemple ci-après présente l'utilisation de la commande SQL*Plus SHOW PARAMETER pour
afficher les valeurs de paramètres. Vous pouvez également utiliser cette commande pour trouver tous
les paramètres contenant une chaîne de texte. Par exemple, vous pouvez trouver tous les noms de
paramètre comprenant la chaîne db à l'aide de la commande suivante :
SQL> show parameter db
NAME TYPE VALUE
------------------------------------ ----------- ----------
…
db_8k_cache_size big integer 0
db_block_buffers integer 0
db_block_checking string FALSE
db_block_checksum string TYPICAL
db_block_size integer 8192
db_cache_advice string ON
db_cache_size big integer 0
…
Autres vues contenant des informations sur les paramètres
• V$SPPARAMETER affiche des informations sur le contenu du fichier de paramètres serveur. Si
aucun fichier de paramètres serveur n'a été utilisé pour démarrer l'instance, chaque ligne de la
vue contient la valeur FALSE dans la colonne ISSPECIFIED.
• V$PARAMETER2 affiche des informations sur les paramètres d'initialisation actuellement en
vigueur pour la session, chaque valeur correspondant à une ligne de la vue. Une nouvelle session
hérite des valeurs de paramètres de niveau instance affichées dans la vue
V$SYSTEM_PARAMETER2.
• V$SYSTEM_PARAMETER affiche des informations sur les paramètres d'initialisation
actuellement en vigueur pour l'instance.

Modifier les valeurs des paramètres d'initialisation
• Paramètres statiques :
– Ils ne peuvent être modifiés que dans le fichier de paramètres.
– Un redémarrage de l'instance est nécessaire pour que les
modifications prennent effet.
– Il en existe environ 110.
• Paramètres dynamiques :
– Ils peuvent être modifiés tant que la base de données est en ligne.
– Les modifications peuvent être effectuées à deux niveaux :
— Niveau session
— Niveau système

– Ils sont valides pour la durée de la session ou dans les limites
établies par le paramètre SCOPE.
– Les modifications sont effectuées à l'aide des commandes ALTER
SESSION et ALTER SYSTEM.
– Il en existe environ 234.
Modifier les valeurs des paramètres d'initialisation

Les paramètres d'initialisation sont de deux types :
Les paramètres statiques affectent l'instance ou la base de données entière et ne peuvent être
modifiés que dans init.ora ou le fichier SPFILE. Pour qu'ils prennent effet, vous devez
arrêter et redémarrer la base de données. Vous ne pouvez pas les modifier pour l'instance en
cours.
Les paramètres dynamiques peuvent être modifiés pendant que la base de données est en
ligne. Ils agissent à deux niveaux :
• Les paramètres de niveau session affectent uniquement une session utilisateur. Ils
comprennent notamment des paramètres NLS (National Language Support) qui peuvent
être utilisés pour définir des paramètres de langue supplémentaires pour les tris, les dates,
etc. Ils s'appliquent à une session donnée et expirent à la fin de celle-ci.
• Les paramètres de niveau système affectent l'ensemble de la base de données et toutes les
sessions. Dans ce cadre, vous pouvez par exemple modifier la valeur de SGA_TARGET et
définir les destinations des journaux archivés. Ces paramètres restent en vigueur
conformément à la spécification SCOPE. Pour qu'ils deviennent permanents, vous devez
les ajouter au fichier SPFILE en précisant l'option SCOPE=BOTH ou en modifiant
manuellement le fichier de paramètres.
Vous pouvez modifier les paramètres dynamiques à l'aide des commandes ALTER
SESSION et ALTER SYSTEM.

Modifier les valeurs des paramètres d'initialisation (suite)
Utilisez la clause SET de l'instruction ALTER SYSTEM pour définir ou modifier les valeurs des
paramètres d'initialisation. La clause SCOPE facultative précise la portée d'une modification, de la
manière suivante :
• SCOPE=SPFILE : La modification est appliquée uniquement dans le fichier de paramètres
serveur. Aucune modification n'est apportée à l'instance en cours. Pour les paramètres
dynamiques et statiques, la modification prend effet au démarrage suivant et devient persistante.
Il s'agit de la seule définition de SCOPE autorisée pour les paramètres statiques.
• SCOPE=MEMORY : La modification est appliquée uniquement dans la mémoire. Elle concerne
l'instance en cours et prend effet immédiatement. Pour les paramètres dynamiques, l'effet est
immédiat, mais il n'est pas persistant puisque le fichier de paramètres serveur n'est pas mis à
jour. Pour les paramètres statiques, cette spécification n'est pas autorisée.
• SCOPE=BOTH : La modification est appliquée dans le fichier de paramètres serveur et dans la
mémoire. Elle concerne l'instance en cours et prend effet immédiatement. Pour les paramètres
dynamiques, l'effet est persistant puisque le fichier de paramètres serveur est mis à jour. Pour les

paramètres statiques, cette spécification n'est pas autorisée.
Il est incorrect de spécifier SCOPE=SPFILE ou SCOPE=BOTH si l'instance n'a pas démarré avec un
fichier de paramètres serveur. La spécification par défaut est SCOPE=BOTH si un fichier de
paramètres serveur a été utilisé pour démarrer l'instance, et SCOPE=MEMORY si un fichier de
paramètres d'initialisation a été utilisé pour démarrer l'instance.
Pour certains paramètres dynamiques, vous pouvez également indiquer le mot-clé DEFERRED pour
que la modification ne s'applique qu'aux sessions futures. Il s'agit des paramètres suivants :
• backup_tape_io_slaves
• recyclebin
• audit_file_dest
• object_cache_optimal_size
• object_cache_max_size_percent
• sort_area_size
• sort_area_retained_size
• olap_page_pool_size
Lorsque vous utilisez l'option SPFILE ou BOTH dans la clause SCOPE, une clause COMMENT
supplémentaire vous permet d'associer une chaîne de texte à la mise à jour. Ce commentaire est
enregistré dans le fichier de paramètres serveur.

Modifier les valeurs des paramètres : Exemples
SQL> ALTER SESSION
SET NLS_DATE_FORMAT ='mon dd yyyy';
Session altered.
SQL> SELECT SYSDATE FROM dual;
SYSDATE
-----------
jun 18 2009

SQL> ALTER SYSTEM SET
SEC_MAX_FAILED_LOGIN_ATTEMPTS=2 COMMENT='Reduce
from 10 for tighter security.' SCOPE=SPFILE;
System altered.
Modifier les valeurs des paramètres : Exemples

La première instruction de la diapositive ci-dessus modifie un paramètre de niveau session.
L'utilisateur définit le format de date mon dd yyyy pour la session. Toutes les interrogations
portant sur des dates afficheront donc les dates dans ce format. Les paramètres de niveau
session peuvent également être définis dans les applications à l'aide de code PL/SQL.
La deuxième instruction présentée modifie le nombre maximal de tentatives de connexion
infructueuses au bout duquel la connexion est abandonnée. Elle comprend un commentaire et
indique explicitement que la modification ne doit être effectuée que dans le fichier de
paramètres serveur. Lorsque le nombre d'échecs de connexion précisé est atteint, la connexion
est automatiquement abandonnée par le processus serveur. Comme il ne s'agit pas d'un
paramètre dynamique, sa modification ne prend effet qu'après le redémarrage de l'instance de
base de données Oracle.

Quiz
Enterprise Manager Database Control peut être utilisé pour

gérer plusieurs bases de données simultanément.
1. Vrai
2. Faux

Réponse : 2

Quiz
Les paramètres de la base de données sont en majorité

dynamiques et vous pouvez les modifier sans arrêter l'instance.
1. Vrai
2. Faux

Réponse : 1

Composants
Démarrage et arrêt de la base SQL*Plus
> Param. D’init.
de données : Informations Démarrage BdD
Arrêt BdD
d'identification et de connexion Fichier d'alertes
Vues de perf.
o 1
u

2
Démarrage et arrêt de la base de données : Informations d'identification et de

connexion
Lorsque vous cliquez sur Startup ou Shutdown, vous êtes invité à saisir les informations
d'identification et de connexion (credentials) qui sont utilisées pour la connexion à l'hôte
(c'est-à-dire l'ordinateur sur lequel réside la base de données) et à la base proprement dite.
Vous devez indiquer un compte de base de données doté du privilège SYSDBA.
Après avoir entré les informations d'identification et de connexion, vous êtes invité à indiquer
la méthode de démarrage ou d'arrêt. Si nécessaire, vous pouvez ensuite cliquer sur Advanced
Options pour modifier les options de démarrage ou le mode d'arrêt. Vous pouvez également
cliquer sur Show SQL pour afficher les instructions SQL utilisées pour le démarrage ou pour
l'arrêt.
Remarque : Pour arrêter la base à l'aide d'Enterprise Manager, l'option par défaut est
IMMEDIATE. Si vous utilisez la commande SQL*Plus SHUTDOWN, l'option par défaut est
NORMAL.

Démarrer une instance
de base de données Oracle
2
1

5
4
Démarrer une instance de base de données Oracle

Si la base de données n'est pas démarrée lorsque vous accédez à la page Enterprise Manager
Database Control, cliquez sur Startup. Entrez les informations d'identification et de connexion
(credentials) de l'hôte et sélectionnez éventuellement le mode de démarrage. Si la base Oracle
a été enregistrée dans Oracle Restart, une boîte de dialogue vous invite à préciser si vous
voulez recourir à l'utilitaire Server Control (SRVCTL) ou SQL*Plus pour démarrer l'instance.
SRVCTL est l'utilitaire recommandé avec Oracle Restart car il est capable de démarrer les
ressources dépendantes nécessaires.

Démarrer une instance de base de données
Oracle : NOMOUNT
OPEN
STARTUP
MOUNT
NOMOUNT
Instance

démarrée
SHUTDOWN
Démarrer une instance de base de données Oracle : NOMOUNT

Lorsque vous démarrez une instance de base de données, sélectionnez son état initial. Les
scénarios qui suivent décrivent les différentes étapes du démarrage d'une instance.
En règle générale, une instance est démarrée uniquement en mode NOMOUNT au cours de la
création de la base de données, pendant la régénération des fichiers de contrôle ou dans
certains scénarios de sauvegarde et de récupération.
Le démarrage d'une instance inclut les opérations suivantes :
• Recherche dans $ORACLE_HOME/dbs d'un fichier portant un nom particulier, dans
l'ordre suivant :
1. Recherchez spfile<SID>.ora.
2. Si spfile<SID>.ora est introuvable, recherchez spfile.ora.
3. Si spfile.ora est introuvable, recherchez init<SID>.ora.
Il s'agit du fichier qui contient les paramètres d'initialisation de l'instance. Le fait de
définir le paramètre PFILE avec STARTUP modifie le comportement par défaut.
• Allocation de la mémoire SGA
• Démarrage des processus en arrière-plan
• Ouverture du fichier alert_<SID>.log et des fichiers trace
Remarque : SID est l'ID système qui identifie l'instance (par exemple, ORCL).

Démarrer une instance de base de données Oracle :
MOUNT
OPEN
STARTUP
MOUNT
Fichier de
contrôle ouvert
NOMOUNT pour cette
instance
Instance

démarrée
SHUTDOWN
Démarrer une instance de base de données Oracle : MOUNT

Le montage d'une base de données inclut les opérations suivantes :
• Associer une base de données à une instance démarrée précédemment.
• Localiser et ouvrir tous les fichiers de contrôle indiqués dans le fichier de paramètres.
• Lire les fichiers de contrôle pour obtenir les noms et les statuts des fichiers de données et
des fichiers de journalisation en ligne (mais l'existence de ces fichiers n'est pas vérifiée à
ce stade).
Pour effectuer des opérations de maintenance particulières, démarrez une instance et montez
une base de données, mais n'ouvrez pas cette dernière.
Par exemple, la base doit être montée (mounted) mais pas ouverte pour les opérations
suivantes :
• Renommer des fichiers de données (les fichiers de données d'un tablespace hors ligne
(offline) peuvent être renommés lorsque la base de données est ouverte).
• Activer et désactiver les options d'archivage des fichiers de journalisation en ligne.
• Procéder à une récupération complète de la base de données.
Remarque : Une base de données peut rester en mode MOUNT même si une demande OPEN a
été effectuée. Cela peut s'expliquer par le fait que la base doit être récupérée d'une manière ou
d'une autre. Si une récupération est effectuée lorsque la base est à l'état MOUNT, les fichiers de
journalisation sont ouverts pour les opérations de lecture. En outre, les fichiers de données
sont ouverts pour permettre la lecture des blocs à récupérer et, si nécessaire, l'écriture des
blocs récupérés.

Démarrer une instance de base de données Oracle :
OPEN
OPEN
STARTUP Tous les fichiers sont
ouverts, conformément à la
description du fichier de
MOUNT
contrôle pour cette instance
Fichier de contrôle
ouvert pour cette
NOMOUNT instance
Instance

démarrée
SHUTDOWN
Démarrer une instance de base de données Oracle : OPEN

Lorsqu'une base de données est en mode de fonctionnement normal, une instance est
démarrée, et la base est montée et ouverte. N'importe quel utilisateur valide peut se connecter
à celle-ci et effectuer des opérations standard d'accès aux données.
L'ouverture de la base de données inclut les opérations suivantes :
• Ouverture des fichiers de données
• Ouverture des fichiers de journalisation en ligne (online redo logs)
Si certains fichiers de données ou fichiers de journalisation en ligne sont absents lorsque vous
tentez d'ouvrir la base, le serveur Oracle renvoie une erreur.
Au cours de cette étape finale, le serveur Oracle vérifie que tous les fichiers de données et
fichiers de journalisation en ligne peuvent être ouverts, et il vérifie la cohérence de la base. Si
nécessaire, le processus SMON (System Monitor) en arrière-plan lance la récupération
d'instance.
Vous pouvez démarrer une instance de base de données en mode d'accès restreint, de sorte
qu'elle soit accessible uniquement aux utilisateurs disposant de privilèges d'administration.
Pour cela, sélectionnez l'option "Restrict access to database" dans la page Advanced Startup
Options.

Options de démarrage : Exemples
• A l'aide de l'utilitaire sqlplus :

SQL> startup 1
SQL> startup nomount 2
SQL> alter database mount; 3
SQL> alter database open; 4

• A l'aide de l'utilitaire srvctl avec Oracle Restart :
$ srvctl start database –d orcl –o mount
Options de démarrage : Exemples

La diapositive ci-dessus présente la syntaxe SQL*Plus qui démarre la base de données.
1. Cette commande démarre l'instance, lui associe les fichiers de base de données, puis
monte et ouvre la base.
2. Cette commande démarre l'instance, mais sans monter la base de données.
3. Cette commande monte une base de données à partir de l'état NOMOUNT.
4. Cette commande ouvre une base de données à partir de l'état MOUNT.
Si la base est enregistrée dans Oracle Restart, l'utilitaire srvctl peut être utilisé pour
démarrer l'instance. L'avantage de srvctl est qu'il peut aussi démarrer toutes les ressources
dépendantes qui sont nécessaires : instance ASM, groupes de disques ASM et processus
d'écoute notamment.
Remarque : L'utilitaire srvctl se trouve à la fois dans le répertoire $ORACLE_HOME/bin
du logiciel Oracle Grid Infrastructure et dans le répertoire $ORACLE_HOME/bin du logiciel
Oracle Database. Vous devez utiliser le second lorsque vous démarrez la base Oracle et le
premier lorsque vous démarrez l'instance ASM ou le processus d'écoute.

Arrêter une instance de base de données Oracle

3
Arrêter une instance de base de données Oracle

Si l'instance est déjà démarrée lorsque vous accédez à la page Enterprise Manager Database
Control, cliquez sur le bouton Shutdown pour l'arrêter. Vous êtes alors invité à vérifier ou à
entrer les informations d'identification et de connexion pour l'hôte (Host Credentials) et pour
la base de données (Database Credentials). Cliquez sur OK pour afficher la boîte de dialogue
Startup/Shutdown: Confirmation. Si vous cliquez ensuite sur le bouton Advanced Options,
vous pouvez sélectionner le mode d'arrêt : NORMAL, TRANSACTIONAL, IMMEDIATE ou
ABORT.

Modes d'arrêt
Modes d'arrêt A I T N
Autorise les nouvelles connexions Non Non Non Non
Attend la fin des sessions en cours Non Non Non Oui
Attend la fin des transactions en cours Non Non Oui Oui
Force un point de reprise et ferme les fichiers Non Oui Oui Oui
Modes d'arrêt :

• A = ABORT
• I = IMMEDIATE
• T = TRANSACTIONAL
• N = NORMAL
Modes d'arrêt
Les modes d'arrêt ci-dessous sont classés selon leur adaptation à l'activité en cours (du moins
adapté au plus adapté) :
• Le mode ABORT effectue des tâches minimales avant l'arrêt. Il requiert une opération de
récupération avant le démarrage. Ne l'utilisez donc qu'en cas de nécessité. Ce mode est
généralement utilisé lorsqu'aucun autre mode d'arrêt ne fonctionne, lorsque le démarrage
de l'instance se révèle problématique, ou lorsque vous avez besoin d'arrêter l'instance
immédiatement en raison d'un événement imminent (tel que l'annonce d'une coupure de
courant dans les secondes qui suivent).
• IMMEDIATE est l'option utilisée le plus fréquemment. Les transactions non validées sont
annulées (rollback).
• Le mode TRANSACTIONAL laisse les transactions en cours se terminer, mais empêche
le démarrage de nouvelles transactions.
• Le mode NORMAL attend la déconnexion des sessions.
Du point de vue du temps nécessaire pour effectuer l'arrêt, ABORT est le mode le plus rapide,
et NORMAL, le plus lent. Les modes d'arrêt NORMAL et TRANSACTIONAL peuvent être longs,
en fonction du nombre de sessions et de transactions en cours.

Options d'arrêt
Vers le bas : Options : Vers le haut :

• Les modifications • Pas de
SHUTDOWN
non validées sont NORMAL récupération
annulées pour ou d'instance
IMMEDIATE SHUTDOWN
TRANSACTIONAL
• Le cache de
ou
tampons de la base SHUTDOWN
de données est IMMEDIATE
écrit dans les

fichiers de données
• Les ressources
sont libérées
Base de données cohérente
Options d'arrêt
SHUTDOWN NORMAL
NORMAL est le mode d'arrêt utilisé par défaut quand aucun mode n'est précisé. Un arrêt
"normal" de la base de données a lieu dans les conditions suivantes :
• Aucune nouvelle connexion ne peut être établie.
• Le serveur Oracle attend que tous les utilisateurs se déconnectent avant de procéder à
l'arrêt.
• Les tampons de la base de données et les tampons de journalisation (redo log buffers)
sont écrits sur le disque.
• Les processus en arrière-plan sont arrêtés et la mémoire SGA est libérée.
• Le serveur Oracle ferme et démonte la base de données avant d'arrêter l'instance.
• Le démarrage suivant ne nécessite pas de récupération d'instance.
SHUTDOWN TRANSACTIONAL
Un arrêt en mode TRANSACTIONAL évite aux clients de perdre des données, notamment les
résultats des activités en cours. Un arrêt TRANSACTIONAL de la base de données
s'accompagne des conditions suivantes :
• Aucun client ne peut démarrer de nouvelle transaction sur cette instance particulière.
• Un client est déconnecté lorsqu'il termine la transaction en cours.
• Lorsque toutes les transactions sont terminées, l'arrêt a lieu immédiatement.

Options d'arrêt (suite)
SHUTDOWN IMMEDIATE
Un arrêt en mode IMMEDIATE de la base de données s'accompagne des conditions suivantes :
• Les instructions SQL en cours de traitement par la base de données Oracle ne sont pas
terminées.
• Le serveur Oracle n'attend pas que les utilisateurs actuellement connectés à la base de données
se déconnectent.
• Le serveur Oracle annule (rollback) les transactions actives et déconnecte tous les utilisateurs
connectés.
• Le serveur Oracle ferme et démonte la base de données avant d'arrêter l'instance.
Remarque : IMMEDIATE est le mode d'arrêt par défaut avec Enterprise Manager.

Options d'arrêt
Vers le bas : Vers le haut :
• Les mémoires Options : • Les fichiers de
tampons modifiées journalisation en
SHUTDOWN ABORT
ne sont pas écrites ou
ligne sont utilisés
dans les fichiers de Echec d'instance pour réappliquer
données ou les modifications
STARTUP FORCE
• Les modifications • Les segments
non validées ne d'annulation sont
sont pas annulées utilisés pour
annuler les

modifications non
validées
• Les ressources
Base de données sont libérées
incohérente
Options d'arrêt (suite)

SHUTDOWN ABORT
Si les modes d'arrêt NORMAL, TRANSACTIONAL et IMMEDIATE ne fonctionnent pas, vous
pouvez abandonner l'instance de base de données en cours. L'abandon d'une instance
s'accompagne des conditions suivantes :
• Les instructions SQL en cours de traitement par le serveur Oracle sont immédiatement
interrompues.
• Le serveur Oracle n'attend pas que les utilisateurs actuellement connectés à la base de
données se déconnectent.
• Les mémoires tampons de la base de données et les tampons de journalisation (redo log
buffers) ne sont pas écrits sur le disque.
• Les transactions non validées ne sont pas annulées (rollback).
• L'instance est arrêtée sans fermeture des fichiers.
• La base de données n'est ni fermée, ni démontée.
• Le démarrage suivant nécessite au préalable la récupération de l'instance, qui a lieu
automatiquement.
Remarque : Il n'est pas recommandé de sauvegarder une base de données qui se trouve dans
un état incohérent.

Options d'arrêt : Exemples
• A l'aide de SQL*Plus :
SQL> shutdown 1
SQL> shutdown transactional 2
SQL> shutdown immediate 3
SQL> shutdown abort 4

• A l'aide de l'utilitaire SRVCTL avec Oracle Restart :
$ srvctl stop database –d orcl –o abort
Options d'arrêt : Exemples

La diapositive ci-dessus présente les commandes SQL*Plus et SRVCTL permettant d'arrêter
la base de données.
1. Cette commande lance un arrêt de la base en mode "normal". La base attend que tous les
utilisateurs se soient déconnectés pour s'arrêter.
2. Cette commande lance un arrêt de la base en mode transactional. La base attend
que toutes les transactions en cours soient terminées pour s'arrêter.
3. Cette commande lance un arrêt de la base en mode immediate. Les transactions non
validées sont annulées (rollback).
4. Cette commande lance un arrêt de la base en mode abort.
Si la base de données utilise Oracle Restart, elle peut être arrêtée à l'aide de l'utilitaire
SRVCTL.
Remarque : L'utilitaire SRVCTL se trouve à la fois dans le répertoire
$ORACLE_HOME/bin du logiciel Oracle Grid Infrastructure et dans le répertoire
$ORACLE_HOME/bin du logiciel Oracle Database. Vous devez utiliser le second lorsque
vous démarrez la base de données Oracle, et le premier lorsque vous démarrez l'instance ASM
ou le processus d'écoute.

Composants
Afficher le fichier d'alertes SQL*Plus
Param. d'init.
Démarrage BdD
Arrêt BdD
Page d'accueil de la base de données > > Fichier d’alertes
Région Related Links > Alert Log Content Vues de perf.

Afficher le fichier d'alertes

Chaque base de données comporte un fichier alert_<sid>.log. Ce fichier se trouve sur
le serveur de base de données, par défaut dans le dossier
$ORACLE_BASE/diag/rdbms/<db_name>/<SID>/trace si $ORACLE_BASE est
défini.
Le fichier d'alertes d'une base de données est un journal chronologique de messages signalant
notamment les points suivants :
• Tout paramètre d'initialisation qui n'est pas un paramètre par défaut et qui est utilisé au
démarrage.
• L'ensemble des erreurs internes (ORA-600), des erreurs de corruption de bloc (ORA-
1578) et des erreurs de "verrou mortel" (deadlock) (ORA-60) qui se sont produites.
• Les opérations d'administration, telles que les instructions SQL CREATE, ALTER, DROP
DATABASE et TABLESPACE et les instructions Enterprise Manager ou SQL*Plus
STARTUP, SHUTDOWN, ARCHIVE LOG et RECOVER.
• Divers messages et erreurs liés aux fonctions des processus de serveur partagé et aux
processus répartiteur.
• Les erreurs survenues au cours de la régénération automatique d'une vue matérialisée.
Oracle Database utilise le fichier d'alertes pour conserver une trace de ces événements au lieu
de les afficher sur la console d'un opérateur. (De nombreux systèmes affichent également ces
informations sur la console.) Si une opération d'administration se déroule correctement, elle
est consignée dans le fichier d'alertes avec le statut "completed" et un horodatage.

Afficher le fichier d'alertes (suite)
Enterprise Manager surveille le fichier d'alertes et vous informe des erreurs critiques. Vous pouvez
également afficher ce fichier afin de voir les erreurs non critiques et les messages d'information. Le
fichier d'alertes pouvant atteindre une taille impossible à gérer, vous pouvez le sauvegarder
périodiquement et supprimer le fichier en cours. Lorsque la base de données tente d'écrire à nouveau
dans le fichier d'alertes, elle en crée un nouveau.
Remarque : Il existe une version XML du fichier d'alertes dans le répertoire
$ORACLE_BASE/diag/rdbms/<db_name>/<SID>/alert.
Pour déterminer l'emplacement du fichier d'alertes à l'aide de SQL*Plus :
• Connectez-vous à la base de données à l'aide de SQL*Plus (ou un autre outil d'interrogation tel
que SQL Developer).
• Interrogez la vue V$DIAG_INFO.
Pour afficher le fichier d'alertes au format texte, sans les balises XML :
• Dans les résultats de l'interrogation de la vue V$DIAG_INFO, notez le chemin correspondant à

l'entrée Diag Trace. Accédez au répertoire indiqué dans le chemin.
• Ouvrez le fichier alert_SID.log à l'aide d'un éditeur de texte.
Pour afficher le fichier d'alertes au format XML :
• Dans les résultats de l'interrogation de la vue V$DIAG_INFO, notez le chemin correspondant à
l'entrée Diag Alert. Accédez au répertoire indiqué dans le chemin.
• Ouvrez le fichier log.xml à l'aide d'un éditeur de texte.

Utiliser les fichiers trace
• Chaque processus serveur ou en arrière-plan peut écrire

dans un fichier trace associé.
• Les informations relatives aux erreurs sont consignées
dans le fichier trace correspondant.
• Référentiel ADR (Automatic Diagnostic Repository)
– Référentiel central de trace et de journalisation pour
l'ensemble du système
– Il contient des données de diagnostic de la base de données,
notamment :

— Fichiers trace
— Fichiers d'alertes
— Rapports sur l'état du système
Utiliser les fichiers trace

Chaque processus serveur ou en arrière-plan peut écrire dans un fichier trace associé.
Lorsqu'un processus détecte une erreur interne, il effectue un dump des informations relatives
à cette erreur vers son fichier trace. Si une erreur interne se produit et que des informations
sont consignées dans un fichier trace, l'administrateur doit contacter le Support technique
Oracle.
Tous les noms de fichier et fichiers trace associés à un processus en arrière-plan contiennent
le nom du processus qui les a générés. Les seules exceptions sont les fichiers trace qui sont
générés par les processus de gestion des files d'attente de travaux (Jnnn).
D'autres informations consignées dans les fichiers trace peuvent donner des indications pour
le réglage des applications ou d'une instance. Les processus en arrière-plan écrivent toujours
ces informations dans un fichier trace le cas échéant.
Oracle Database 11g introduit une infrastructure avancée qui permet de prévenir, détecter,
diagnostiquer et résoudre les problèmes. Les problèmes visés sont notamment les erreurs
critiques que peuvent causer des bugs dans le code de la base de données, ainsi que la
corruption des métadonnées ou des données client.

Utiliser les fichiers trace (suite)
Quand une erreur critique se produit, un numéro d'incident lui est affecté. Les données de diagnostic
concernant cette erreur (fichiers trace notamment) sont immédiatement capturées et marquées de ce
numéro. Ces données sont ensuite stockées dans le référentiel de diagnostic automatique (ADR -
Automatic Diagnostic Repository). Il s'agit d'un fichier extérieur à la base de données d'où vous
pouvez ensuite extraire les informations qui vous intéressent par numéro d'incident afin de les
analyser.
Le référentiel ADR est un référentiel central de trace et de journalisation à l'échelle du système. Il
contient les données de diagnostic relatives à la base (traces, fichier d'alertes, rapports sur l'état du
système, etc.).
Le répertoire racine de ce référentiel est appelé base ADR. Son emplacement est défini par le
paramètre d'initialisation DIAGNOSTIC_DEST. Si ce paramètre est omis ou n'est pas défini, la base
de données le configure au démarrage selon les règles suivantes :
• Si la variable d'environnement ORACLE_BASE est définie, le répertoire désigné devient

l'emplacement DIAGNOSTIC_DEST.
• Si la variable d'environnement ORACLE_BASE n'est pas définie, l'emplacement
DIAGNOSTIC_DEST est ORACLE_HOME/log.
Le chemin d'un répertoire d'origine ADR est le suivant, à partir du répertoire de la base ADR :
./diag/product_type/db_id/instance_id

Composants
Vues dynamiques des performances SQL*Plus
Param. d'init.
Démarrage BdD
Elles permettent d'accéder à Arrêt BdD
Fichier d'alertes
des informations relatives aux > Vues de perf.
changements d'état des
structures mémoire de Données de session
l'instance. Evénements Wait
Allocations mémoire
Code SQL exécuté
Cache de Espace de Utilisation des
Zone de
tampons de Tampon de tampons à données d'annulation
mémoire
la base journalisation conserver Curseurs ouverts
partagée Espace de
de données
tampons à Utilisation des données

Zone de Zone de recycler de journalisation
Zone de mémoire mémoire mémoire Cache de ...etc.
LARGE POOL Java Streams tampons
de blocs
de taille
Mémoire SGA (System Global Area) nK
Vues dynamiques des performances

La base de données Oracle gère également un ensemble plus dynamique de données relatives
aux opérations et aux performances de l'instance. Ces vues dynamiques des performances
reposent sur des tables virtuelles qui sont construites à partir des structures mémoire au sein
du serveur de base de données. Autrement dit, il ne s'agit pas de tables conventionnelles
résidant dans une base de données. C'est pourquoi certaines d'entre elles sont disponibles
avant le montage ou l'ouverture d'une base.
Les vues dynamiques des performances contiennent des informations sur les éléments
suivants :
• Sessions
• Etat des fichiers
• Progression des travaux et des tâches
• Verrous externes (locks)
• Statut de sauvegarde
• Utilisation et allocation de mémoire
• Paramètres système et paramètres de session
• Exécution d'instructions SQL
• Statistiques et mesures de performances
Remarque : Les vues DICT et DICT_COLUMNS contiennent le nom de ces vues dynamiques
des performances. Il existe plus de 590 vues dynamiques des performances, dont le nom
commence par le préfixe v$.

Vues dynamiques des performances :
Exemples d'utilisation
SQL> SELECT sql_text, executions FROM v$sql

1
WHERE cpu_time > 200000;
2 SQL> SELECT * FROM v$session WHERE machine =

'EDRSR9P1' and logon_time > SYSDATE - 1;

SQL> SELECT sid, ctime FROM v$lock
3
WHERE block > 0;
Vues dynamiques des performances : Exemples d'utilisation

Les vues dynamiques des performances sont essentiellement utilisées par Enterprise Manager,
mais les utilisateurs peuvent également les interroger en cas de besoin. Les trois exemples
présentés dans la diapositive ci-dessus répondent aux questions suivantes :
1. Quelles sont les instructions SQL (et le nombre d'exécutions associées) pour lesquelles le
temps CPU consommé est supérieur à 200 000 microsecondes ?
2. Quelles sont les sessions qui se sont connectées à partir de l'ordinateur EDRSR9P1 au
cours des dernières 24 heures ?
3. Quels sont les ID des sessions qui contiennent actuellement un verrou externe (lock)
bloquant un autre utilisateur, et depuis combien de temps ces verrous sont-ils appliqués ?

Vues dynamiques des performances : Remarques
• Ces vues appartiennent à l'utilisateur SYS.

• Des vues différentes sont disponibles à des moments
différents :
– L'instance a été démarrée.
– La base de données est montée.
– La base de données est ouverte.
• Vous pouvez interroger la table V$FIXED_TABLE afin
d'afficher le nom de toutes les vues.

• Ces vues sont souvent appelées "vues V$".
• La cohérence en lecture n'est pas garantie sur ces vues car
les données sont dynamiques.
Vues dynamiques des performances : Remarques

Certaines vues dynamiques contiennent des données qui ne s'appliquent pas à tous les états
d'une instance ou d'une base de données. Par exemple, si une instance vient d'être démarrée
mais qu'aucune base n'est montée, vous pouvez interroger la vue V$BGPROCESS pour
afficher la liste des processus en arrière-plan en cours d'exécution. En revanche, vous ne
pouvez pas interroger la vue V$DATAFILE pour afficher le statut des fichiers de données
d'une base. En effet, c'est le montage d'une base qui entraîne la lecture du fichier de contrôle
et la recherche des fichiers de données associés.
Certaines vues dynamiques (V$) contiennent des informations similaires à celles des vues
DBA_ correspondantes. Par exemple, V$DATAFILE est semblable à DBA_DATA_FILES.
Notez que les noms des vues V$ sont généralement au singulier, et ceux des vues DBA_ au
pluriel.

Schéma
Dictionnaire de données : Présentation Contraintes
Index
Vues
Séquences
Tables temp.
> Dict. de données
Tables
Index
Tablespace système
Vues
Utilisateurs
Schémas
Procédures
Métadonnées
...etc.

SELECT * FROM dictionary;
Dictionnaire de données : Présentation

Le dictionnaire de données Oracle sert à stocker les métadonnées de la base. Il contient les
noms et les attributs de tous les objets de celle-ci. Lors de la création ou de la modification
d'un objet, il est mis à jour afin de refléter les changements opérés. Les informations du
dictionnaire sont stockées dans les tables de base gérées par la base de données Oracle. Vous
ne lisez pas directement ces tables mais vous y accédez par le biais de vues prédéfinies.
Caractéristiques du dictionnaire de données :
• Il est utilisé par le serveur de base de données Oracle pour la recherche d'informations sur
les utilisateurs, les objets, les contraintes et le stockage.
• Il est mis à jour par le serveur de base de données Oracle lorsque des définitions ou des
structures d'objet sont modifiées.
• Il peut être employé par n'importe quel utilisateur pour la recherche d'informations sur la
base.
• Il appartient à l'utilisateur SYS.
• Il ne doit jamais être modifié directement à l'aide d'une instruction SQL.
Remarque : La vue DICTIONARY du dictionnaire de données (ou le synonyme DICT
correspondant) contient le nom et la description de toutes les tables et vues du dictionnaire.
Utilisez la vue DICT_COLUMNS pour afficher les colonnes des vues et leur définition. Pour
obtenir la définition complète de chaque vue, reportez-vous à la documentation Oracle
Database Reference. Il existe plus de 1000 vues correspondant à des centaines de tables de
base de données.

Vues du dictionnaire de données
Personnes Contenu Sous- Remarques

autorisées ensemble
à interroger de
DBA_ DBA Tout N/A Peut comporter des
colonnes supplémentaires
destinées au DBA
uniquement
ALL_ Tous Tous les Vues DBA_ Objets qui appartiennent à

éléments que l'utilisateur ou que
l'utilisateur est l'utilisateur est autorisé à voir
autorisé à voir

USER_ Tous Tous les Vues ALL_ Normalement identique à la
éléments dont vue ALL_, mais sans la
l'utilisateur est colonne OWNER (certaines
le propriétaire vues comprennent des noms
abrégés comme synonymes
PUBLIC)
Vues du dictionnaire de données

Le préfixe de chaque nom de vue indique le type et la quantité de données qu'un utilisateur est
autorisé à voir.
La vue globale (tous contenus), identifiée par le préfixe DBA_, n'est accessible qu'aux
utilisateurs disposant de privilèges DBA.
Le niveau suivant de privilèges correspond au préfixe ALL_, qui représente tous les objets
que l'utilisateur exécutant l'interrogation est autorisé à voir, qu'il en soit le propriétaire ou non.
Par exemple, si l'utilisateur USER_A est autorisé à accéder à une table dont USER_B est le
propriétaire, USER_A voit cette table dans toutes les vues ALL_ concernant les noms de
table.
Le préfixe USER_ correspond à la visibilité la plus restreinte. Les vues de ce type affichent
uniquement les objets dont l'utilisateur exécutant l'interrogation est propriétaire (c'est-à-dire
les objets présents dans le schéma de cet utilisateur).
D'une manière générale, chaque ensemble de vues est un sous-ensemble de l'ensemble de vues
nécessitant des privilèges supérieurs, au niveau des lignes et des colonnes. Toutefois, les vues
d'un ensemble donné n'ont pas toutes leur pendant dans les autres ensembles de vues.
Cela dépend de la nature des informations contenues dans la vue. Ainsi, il existe une vue
DBA_LOCK mais pas de vue ALL_LOCK. En effet, seul un administrateur de base de données
(DBA) est intéressé par les données relatives aux verrous externes (locks). Assurez-vous de
choisir l'ensemble de vues adapté à vos besoins. Même si vous êtes autorisé à accéder aux
vues DBA, vous pouvez parfois interroger la version USER d'une vue parce que les résultats
fournissent des informations sur les objets dont vous êtes propriétaire et que vous ne voulez
pas d'informations sur les autres objets dans l'ensemble de résultats.

Vues du dictionnaire de données (suite)
Les vues DBA_ ne peuvent être interrogées que par les utilisateurs disposant du privilège SYSDBA ou
SELECT ANY DICTIONARY.
Les vues du dictionnaire n'ont pas toutes un nom commençant par le préfixe DBA_, ALL_ ou
USER_. Voici quelques exceptions :
• AUDIT_ACTIONS
• CAT
• CHANGE_PROPAGATIONS
• CHANGE_PROPAGATION_SETS
• CHANGE_SETS
• CHANGE_SOURCES
• CHANGE_TABLES
• CLIENT_RESULT_CACHE_STATS$
• CLU

• COLS
• COLUMN_PRIVILEGES
• DATABASE_COMPATIBLE_LEVEL
• DBMS_ALERT_INFO
• DBMS_LOCK_ALLOCATED
• DICT
• DICTIONARY
• DICT_COLUMNS
• DUAL
• GLOBAL_NAME
• IND
• INDEX_HISTOGRAM
• INDEX_STATS
• LOGSTDBY_UNSUPPORTED_TABLES
• NLS_DATABASE_PARAMETERS
• NLS_INSTANCE_PARAMETERS
• NLS_SESSION_PARAMETERS
• OBJ
• RECYCLEBIN
• RESOURCE_COST
• ROLE_ROLE_PRIVS
• ROLE_SYS_PRIVS
• ROLE_TAB_PRIVS
• SEQ
• SESSION_PRIVS
• SESSION_ROLES
• SM$VERSION
• SYN
• TABLE_PRIVILEGES
• TABS

Dictionnaire de données : Exemples d'utilisation
SELECT table_name, tablespace_name

1
FROM user_tables;
SELECT sequence_name, min_value, max_value,

2 increment_by
FROM all_sequences
WHERE sequence_owner IN ('MDSYS','XDB');
SELECT USERNAME, ACCOUNT_STATUS

3 FROM dba_users
WHERE ACCOUNT_STATUS = 'OPEN';
4 DESCRIBE dba_indexes
Dictionnaire de données : Exemples d'utilisation

Les exemples présentés dans la diapositive ci-dessus répondent aux questions suivantes :
1. Quel est le nom des tables qui ont été créées dans votre schéma (et quel est le nom du
tablespace dans lequel elles résident) ?
2. A quelles informations importantes relatives aux séquences de la base de données avez-
vous accès ?
3. Quels utilisateurs de la base sont actuellement autorisés à se connecter ?
4. Quelles sont les colonnes de la vue DBA_INDEXES ? Cette interrogation permet de
connaître les informations que vous pouvez consulter au sujet de tous les index de la base
de données. Voici un exemple de sortie partielle résultant de l'exécution de cette
commande :
SQL> DESCRIBE dba_indexes
Name Null? Type
--------------- -------- -------------
OWNER NOT NULL VARCHAR2(30)
INDEX_NAME NOT NULL VARCHAR2(30)
INDEX_TYPE VARCHAR2(27)
TABLE_OWNER NOT NULL VARCHAR2(30)
TABLE_NAME NOT NULL VARCHAR2(30)

Quiz
Quand Oracle Restart est utilisé, le démarrage et l'arrêt d'une

instance de base de données ne peuvent se faire qu'avec
l'utilitaire Server Control (srvctl).
1. Vrai
2. Faux

Réponse : 2

Quiz
Quelle vue du dictionnaire de données permet de trouver le

nom de toutes les tables de la base ?
1. USER_TABLES
2. ALL_TABLES
3. DBA_TABLES
4. ANY_TABLES

Réponse : 3

Synthèse

• démarrer et arrêter la base de données et les composants
Oracle
• utiliser Oracle Enterprise Manager
• accéder à une base de données à l'aide de SQL*Plus
• modifier les paramètres d'initialisation d'une base de
données
• décrire les étapes du démarrage d'une base de données

• décrire les options d'arrêt d'une base de données
• afficher le fichier d'alertes
• accéder aux vues dynamiques des performances

Gérer l'instance Oracle

• naviguer dans Enterprise Manager
• afficher et modifier les paramètres d'initialisation
• arrêter et démarrer l'instance de base de données
• consulter le fichier d'alertes
• vous connecter à la base de données à l'aide de SQL*Plus


Gérer l'instance ASM

Objectifs

• décrire les avantages de la technologie de stockage ASM
• gérer l'instance ASM
• créer et supprimer des groupes de disques ASM
• étendre des groupes de disques ASM
• extraire les métadonnées relatives à ASM à l'aide de divers
utilitaires

Objectifs
Ce chapitre fournit une présentation détaillée de l'instance ASM et explique comment la gérer
avec différents utilitaires.

Avantages d'ASM pour les administrateurs
ASM épargne aux administrateurs ASM apporte des allègements

les tâches suivantes : importants dans les domaines
• Réglage des performances suivants :
des E/S • Gestion des unités logiques
• Déplacement et de stockage (LUN)
réorganisation des fichiers de – Unités de plus grande taille
données mais moins nombreuses
• Gestion des noms de fichier • Dépendance du DBA par
• Gestion des volumes logiques rapport à l'administrateur
système

• Gestion des systèmes de
fichiers • Risques d'erreur liés aux
tâches de maintenance
• Gestion des systèmes de manuelles
fichiers clusterisés
• Gestion des raw devices
Avantages d'ASM pour les administrateurs

La technologie de stockage ASM (Automatic Storage Management) épargne aux
administrateurs les tâches suivantes :
• Réglage des performances des E/S : Grâce à la stratégie SAME (Stripe and Mirror
Everything) d'ASM et aux opérations de rééquilibrage automatiques, il n'est plus
nécessaire de régler les performances des E/S pour équilibrer l'utilisation des disques et
éliminer les points d'accès uniques.
• Déplacement et réorganisation des fichiers de données : Il n'est plus nécessaire de
jongler avec les emplacements des fichiers de données pour répondre aux exigences de
performances et aux contraintes d'espace.
• Gestion des noms de fichier : Il n'est plus nécessaire de définir et d'appliquer une
stratégie concernant les noms de fichier.
• Gestion des volumes logiques, des systèmes de fichiers, des systèmes de fichiers
clusterisés et des raw devices : Ces éléments de stockage ne sont plus nécessaires.
ASM allège en outre le travail des administrateurs dans des domaines importants :
• La gestion des unités logiques de stockage (LUN) est allégée car ASM utilise
généralement un nombre réduit d'unités de grande taille.
• Il y a moins de dépendances entre l'administrateur de base de données et l'administrateur
système. Par exemple, ce dernier n'a pas à intervenir pour ajouter un nouveau fichier de
données ou pour déplacer des disques d'un groupe à un autre.
• La probabilité d'erreurs liées aux tâches de maintenance manuelles est nettement réduite.
Par exemple, dans un système de fichiers conventionnel, un fichier de données créé
manuellement peut ne pas respecter les conventions de dénomination. Il n'est alors pas
sauvegardé avec le reste de la base.

Instance ASM
Une instance ASM est une combinaison des composants de

mémoire et des processus requis pour l'exécution d'ASM.
Zone de Zone de Mémoire Mémoire

mémoire mémoire cache disponible
partagée LARGE ASM
POOL
Processus – Composants de la CPU

RBAL ARBn GMON Onnn PZ9n
MARK
Autres processus divers
Instance ASM
Instance ASM
A chaque démarrage d'ASM ou d'une base de données, une zone de mémoire partagée appelée
SGA (System Global Area) est allouée et des processus en arrière-plan sont lancés. La
combinaison de ces processus et de la mémoire SGA est appelée instance ASM ou instance de
base de données Oracle. Une instance représente les composants de CPU et de RAM d'un
environnement d'exécution ASM.
La mémoire SGA associée à une instance ASM est différente de la mémoire SGA utilisée
pour une instance de base de données. Elle est divisée en quatre zones principales :
• La zone de mémoire partagée est utilisée pour les métadonnées.
• La zone de mémoire LARGE POOL est utilisée pour les opérations en parallèle.
• La mémoire cache ASM est utilisée pour la lecture et l'écriture des blocs pendant les
opérations de rééquilibrage.
• La mémoire disponible est la mémoire existante qui n'a pas été allouée.
La quantité de mémoire minimale recommandée pour une instance ASM est 256 Mo. La
gestion automatique de la mémoire est activée par défaut pour chaque instance ASM. Elle
règle dynamiquement la taille des différents composants de la mémoire SGA. La quantité de
mémoire qui est nécessaire pour une instance ASM dépend de la quantité d'espace disque
gérée par ASM.
Une instance ASM comprend par ailleurs des processus en arrière-plan. Ceux-ci peuvent être
nombreux, mais ils ne sont pas toujours présents.

Instance ASM (suite)
Les processus en arrière-plan propres à la fonctionnalité ASM sont décrits dans la diapositive
suivante. Certains sont obligatoires tandis que d'autres sont facultatifs. Voici quelques exemples :
• ARCn : Archiver (archivage)
• CKPT : Checkpoint (point de reprise)
• DBWn : Database Writer (écriture dans la base de données)
• DIAG : Diagnostic
• Jnnn : Job queue (gestion de file d'attente de travaux)
• LGWR : Log Writer (écriture dans les journaux)
• PMON : Process Monitor (surveillance de processus)
• PSP0 : Process Spawner (génération dynamique de processus)
• QMNn : Queue Monitor (surveillance de file d'attente)
• RECO : Recoverer (récupération)
• SMON : System Monitor (surveillance du système)
• VKTM: Virtual keeper of time (compteur temps virtuel)

• MMAN : Memory Manager (gestionnaire de mémoire)
La liste ci-dessus n'est pas exhaustive. Pour une instance ASM, ces processus n'effectuent pas
toujours les mêmes tâches que pour une instance de base de données. Par exemple, le processus
LGWR d'une instance de base de données est chargé de copier les modifications stockées dans le
tampon de journalisation de la SGA vers les fichiers de journalisation en ligne figurant sur le disque.
Pour sa part, une instance ASM n'a pas de tampon de journalisation dans la mémoire SGA, et elle
n'utilise pas de fichiers de journalisation en ligne. Son processus LGWR copie les informations de
journalisation sur un groupe de disques ASM.
Si l'instance ASM est clusterisée, elle utilise des processus supplémentaires liés à la gestion de
cluster : Voici quelques exemples :
• LMON : Global Enqueue Service Monitor
• LMDn : Global Enqueue Service Daemon
• LMSn : Global Cache Service
• LCKn : Lock

Composants d'une instance ASM :
Processus principaux
Les principaux processus d'une instance ASM sont
responsables des activités ASM.
Processus Description
RBAL Ouvre tous les fichiers de périphérique dans le cadre du processus de
repérage et coordonne l'activité de rééquilibrage
ARBn Un ou plusieurs processus esclaves qui assurent l'activité de rééquilibrage
GMON Gère les activités de niveau disque telles que la suppression ou la mise
hors ligne, ou la modification du niveau de compatibilité d'un groupe de
disques ASM
MARK Marque les unités d'allocation ASM comme étant obsolètes le cas échéant

Onnn Un ou plusieurs processus esclaves ASM formant un pool de connexions à
l'instance ASM pour l'échange de messages
PZ9n Un ou plusieurs processus esclaves en parallèle utilisés pour extraire des
données à partir de vues GV$ dans une installation ASM clusterisée
Composants d'une instance ASM : Processus principaux

L'instance ASM utilise des processus en arrière-plan dédiés pour la majeure partie de ses
fonctionnalités. Le processus RBAL (Rebalance) coordonne l'activité de rééquilibrage entre
les groupes de disques de l'instance. Il effectue une ouverture globale de tous les disques
ASM. Les mouvements de rééquilibrage réels entre les extents de données de l'instance sont
assurés par les processus ARBn. Plusieurs processus ARBn peuvent opérer en même temps. Ils
sont nommés ARB0, ARB1, et ainsi de suite. Le processus GMON gère les membres des
groupes de disques ASM. Le processus MARK définit comme obsolètes les unités d'allocation
ASM pour lesquelles l'écriture sur un disque hors ligne a échoué. Les processus Onnn
représentent le côté serveur d'une connexion client/serveur. Ils apparaissent au démarrage de
l'instance et disparaissent ensuite. Ils constituent un pool de connexions à l'instance ASM pour
l'échange de messages et n'apparaissent qu'en cas de nécessité. Les processus PZ9n
correspondent à un ou plusieurs processus esclaves en parallèle qui sont utilisés pour extraire
des données lorsqu'ASM s'exécute dans une configuration clusterisée sur plusieurs ordinateurs
simultanément.

Paramètres d'initialisation d'une instance ASM
Une instance ASM n'utilise qu'un petit sous-ensemble des

paramètres d'une instance Oracle Database.
INSTANCE_TYPE = ASM
ASM_POWER_LIMIT = 1
ASM_DISKSTRING = '/dev/sda1','/dev/sdb*'
ASM_DISKGROUPS = DATA2, FRA
ASM_PREFERRED_READ_FAILURE_GROUPS = DATA.FailGroup2
DIAGNOSTIC_DEST = /u01/app/oracle
LARGE_POOL_SIZE = 12M

REMOTE_LOGIN_PASSWORDFILE = EXCLUSIVE
Paramètres d'initialisation d'une instance ASM

De même qu'une instance de base de données classique, une instance ASM est contrôlée par
un fichier de paramètres. En général, les paramètres suivants sont définis :
• INSTANCE_TYPE est le seul paramètre obligatoire. Il doit avoir la valeur ASM pour les
instances ASM, alors qu'il a la valeur RDBMS pour les instances de base de données.
• ASM_POWER_LIMIT contrôle la vitesse des opérations de rééquilibrage. Les valeurs
possibles sont comprises entre 1 et 11, cette dernière représentant la vitesse la plus
élevée. La valeur par défaut est 1.
• ASM_DISKSTRING est une valeur dépendant du système d'exploitation qui est utilisée
pour limiter l'ensemble de disques pris en compte par le repérage (discovery). La valeur
par défaut est une chaîne vide, qui convient dans la plupart des cas. Une valeur plus
restrictive (comme dans l'exemple ci-dessus) peut accélérer le repérage et donc améliorer
le temps de montage des groupes de disques.
• ASM_DISKGROUPS répertorie les groupes de disques devant être montés par une
instance ASM au démarrage ou lors de l'exécution de la commande ALTER
DISKGROUP ALL MOUNT. Oracle Restart peut monter les groupes de disques définis
en tant que dépendances, même s'ils ne sont pas indiqués dans le paramètre
ASM_DISKGROUPS. Ce paramètre n'a pas de valeur par défaut.
• ASM_PREFERRED_READ_FAILURE_GROUPS indique les groupes d'échec contenant
le disque à privilégier pour la lecture. Cela est utile dans les bases de données clusterisées
étendues présentant des copies miroir des données, dont une à proximité du serveur.

Paramètres d'initialisation d'une instance ASM (suite)
• DIAGNOSTIC_DEST définit l'emplacement du répertoire d'origine ADR (Automatic
Diagnostic Repository). Ce répertoire contient les fichiers trace, les fichiers d'alertes, les dumps
noyau (core dumps) et les dumps d'incident. La valeur par défaut de ce paramètre est dérivée de
la valeur du paramètre ORACLE_BASE.
• LARGE_POOL_SIZE indique la taille (en octets) de la portion de mémoire LARGE POOL qui
est utilisée dans les systèmes à serveur partagé pour la mémoire des sessions, par les exécutions
en parallèle pour les tampons de messages et par les processus de sauvegarde pour les tampons
d'E/S disque. Etant donné que l'instance ASM se sert de la gestion automatique de la mémoire,
ce paramètre définit la taille minimale que peut prendre la zone de mémoire LARGE POOL.
• REMOTE_LOGIN_PASSWORDFILE indique si le logiciel Oracle vérifie l'existence d'un fichier
de mots de passe. La valeur par défaut est EXCLUSIVE.
Les huit paramètres répertoriés dans la diapositive ci-dessus sont les seuls paramètres autres que les
paramètres par défaut créés pour une instance ASM. Les paramètres d'une base de données ne sont

pas tous valides pour une instance ASM. Sur 344, seuls 74 environ peuvent être utilisés avec une
instance ASM. Les paramètres non mentionnés dans la diapositive ci-dessus peuvent être définis en
fonction des besoins, mais leurs valeurs par défaut conviennent pour la plupart des installations.
Remarque : La gestion automatique de la mémoire est activée par défaut sur les instances ASM,
même si le paramètre MEMORY_TARGET n'est pas défini explicitement. Il s'agit du seul paramètre
que vous devez définir pour la gestion de la mémoire ASM. Oracle Corporation recommande
fortement d'utiliser la gestion automatique de la mémoire pour ASM.

Interaction entre les instances de base de
données et ASM
Instance ASM
Mémoire SGA
Instance de base de données Création de
fichier
Mémoire SGA 1 Zone de Zone de
Mémoire
3 mémoire
partagée
mémoire
LARGE
cache
Zone de Zone de ASM
Cache de Topographie POOL
mémoire mémoire
tampons des extents
partagée LARGE Processus
POOL
GMON
Processus Validation RBAL PZ9n
ARBn
SMON 5 6 MARK
Onnn
Autres
PMON CKPT
DBWR Fermeture
LGWR Autres
Snnn 2

4
Initialisation Allocation
Stockage
ASM
Interaction entre les instances de base de données et ASM

Le processus de création de fichier illustre bien les interactions qui ont lieu entre les instances
de base de données et l'instance ASM. Il se déroule de la manière suivante :
1. La base de données demande la création d'un fichier.
2. Un processus en avant-plan ASM crée une entrée COD (Continuing Operation Directory)
et alloue de l'espace pour le nouveau fichier dans le groupe de disques.
3. Le processus de base de données ASMB reçoit une topographie d'extents pour le nouveau
fichier.
4. Le fichier est désormais ouvert et le processus de base de données l'initialise directement.
5. Après l'initialisation, le processus de base de données demande que la création du fichier
soit validée dans la base de données. Le processus en avant-plan ASM supprime alors
l'entrée d'annuaire COD et marque le fichier comme étant créé.
6. Le fichier est implicitement fermé une fois sa validation confirmée. L'instance de base de
données devra le rouvrir pour les nouvelles E/S.
Cet exemple souligne deux aspects importants de l'architecture ASM :
• L'instance de base de données et l'instance ASM s'exécutent de manière coordonnée. Une
instance de base de données doit interagir avec ASM pour mettre en correspondance les
fichiers de base de données et les extents ASM. Elle reçoit un flux incessant de messages
liés aux opérations ASM (telles que le rééquilibrage des groupes de disques) qui peuvent
verrouiller ou déplacer des extents ASM.
• Les E/S de base de données ne passent pas par l'instance ASM. En fait, la base de
données effectue les opérations d'E/S directement sur les fichiers ASM, comme illustré
dans l'étape 4 de la diapositive ci-dessus.

Instance ASM : Vues dynamiques des
performances
L'instance ASM héberge les tables de métadonnées implantées
en mémoire et les présente sous forme de vues dynamiques
des performances.
• Ces vues sont employées par les utilitaires ASM pour
extraire des informations sur les métadonnées à l'aide
d'instructions SQL.
• Il existe plusieurs vues dédiées à ASM, notamment :
V$ASM_ALIAS V$ASM_ATTRIBUTE V$ASM_CLIENT

V$ASM_DISK V$ASM_DISK_IOSTAT V$ASM_DISK_STAT
V$ASM_DISKGROUP V$ASM_DISKGROUP_STAT V$ASM_FILE
V$ASM_OPERATION V$ASM_TEMPLATE
Instance ASM : Vues dynamiques des performances

L'une des fonctions principales d'une instance est le stockage des tables de métadonnées
implantées en mémoire. Ces tables ont un nom commençant par le préfixe X$ et ne sont
généralement pas documentées. Des vues dynamiques des performances commençant par le
préfixe V$ sont utilisées pour afficher une présentation personnalisée des données contenues
dans les tables X$ en mémoire. Ces informations sont présentées en mode lecture seule et sont
réservées aux administrateurs disposant de privilèges. Elles sont extraites d'ASM à l'aide
d'instructions SQL. La diapositive ci-dessus répertorie les principales vues dynamiques des
performances contenant des métadonnées liées à ASM. Il existe plusieurs centaines d'autres
vues dynamiques des performances, mais elles sont en majorité vides car elles nécessitent
qu'une instance de base de données monte un fichier de contrôle. Cette opération n'est pas
effectuée par les instances ASM. Vous trouverez la liste complète des vues dynamiques des
performances dans le manuel Oracle Database Reference 11g Release 2 (11.2).

Privilèges système ASM
• Une instance ASM n'a pas de dictionnaire de données. Le
seul moyen de s'y connecter est le recours aux privilèges
système ci-après.
Privilège ASM Groupe de Privilège
privilèges
(suggéré)
SYSASM OSASM Privilège d'administration totale
(asmadmin)
SYSDBA OSDBA Accès aux données stockées dans ASM, et
(asmdba) privilèges SYSASM dans la version en cours

SYSOPER OSOPER Privilèges limités pour démarrer et arrêter
(asmoper) l'instance ASM avec des commandes non
destructives ALTER DISKGROUP
• L'utilisateur SYS est créé automatiquement avec le privilège

SYSASM.
Privilèges système ASM

Une instance ASM n'a pas de dictionnaire de données. Le seul moyen de s'y connecter est le
recours aux privilèges système SYSASM, SYSDBA et SYSOPER.
• SYSASM : Ce privilège accorde des droits d'administration complets sur l'instance ASM.
• SYSDBA : Ce privilège donne accès aux données stockées dans ASM et, dans la version
actuelle, accorde le privilège d'administration SYSASM.
• SYSOPER : Ce privilège permet de démarrer et d'arrêter une instance ASM avec des
commandes non destructives ALTER DISKGROUP. Il n'autorise pas d'autres
commandes, telles que CREATE DISKGROUP.
Quand ASM est installé, des groupes du système d'exploitation sont utilisés pour authentifier
les privilèges SYSASM, SYSDBA et SYSOPER. Ces groupes sont respectivement appelés
OSASM, OSDBA et OSOPER par l'utilitaire Oracle Universal Installer (OUI). Ainsi, OSASM est
le groupe du système d'exploitation qui bénéficie du privilège SYSASM. Les noms suggérés
pour les groupes OSASM, OSDBA et OSOPER sont respectivement asmadmin, asmdba et
asmoper. En d'autres termes, SYSASM est le nom utilisé par la base de données, OSASM est
le nom utilisé par l'utilitaire OUI et asmadmin est le nom utilisé par le système
d'exploitation. Tous ces noms font référence au même groupe d'utilisateurs. Lorsqu'une
instance ASM est créée, les seuls utilisateurs ASM définis sont sys et asmsnmp.

Utiliser Enterprise Manager pour gérer
les utilisateurs ASM

Utiliser Enterprise Manager pour gérer les utilisateurs ASM

Enterprise Manager permet de gérer les utilisateurs qui accèdent à l'instance ASM via une
connexion à distance (avec authentification par fichier de mots de passe). Ces utilisateurs sont
réservés exclusivement à l'instance ASM.
Vous ne bénéficiez de cette fonctionnalité que lorsque vous êtes connecté en tant
qu'utilisateur SYSASM. Elle est masquée si vous vous connectez en tant qu'utilisateur
SYSDBA ou SYSOPER.
• Lorsque vous cliquez sur le bouton Create, la page Create User s'affiche.
• Lorsque vous cliquez sur le bouton Edit, la page Edit User s'affiche.
• Vous pouvez supprimer des utilisateurs en cliquant sur le bouton Delete.
Remarque : Pour vous connecter à l'instance ASM avec le rôle SYSASM, cliquez sur le lien
Preferences situé en haut de la page, puis sur le lien Preferred Credentials. Vous voyez alors
ASM dans la liste des types de cible. Cliquez sur l'icône Set Credentials en regard du type de
cible ASM pour définir un compte et un mot de passe bénéficiant du privilège SYSASM. Vous
pouvez être amené à vous déconnecter de Database Control puis à vous reconnecter pour que
la modification soit prise en compte.

Démarrer et arrêter des instances ASM
à l'aide de SQL*Plus
Le démarrage et l'arrêt d'instances ASM à l'aide de SQL*Plus est
similaire au démarrage et à l'arrêt d'instances de base de données.
$ . oraenv
ORACLE_SID = [orcl] ? +ASM
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.2.0/grid is
/u01/app/oracle
$ sqlplus / AS SYSASM
SQL*Plus: Release 11.2.0.1.0 - Production on Wed Jul 8 20:46:46 2009
Connected to an idle instance.
SQL> startup
ASM instance started

Total System Global Area 284565504 bytes
Fixed Size 1336028 bytes
Variable Size 258063652 bytes
ASM Cache 25165824 bytes
ASM diskgroups mounted
ASM diskgroups volume enabled
SQL> shutdown abort
Démarrer et arrêter des instances ASM à l'aide de SQL*Plus

Avec SQL*Plus, vous démarrez une instance ASM à l'aide de la commande STARTUP,
comme vous le feriez pour une instance de base de données Oracle. Vous devez tenir compte
des points suivants :
• Pour vous connecter à une instance ASM à l'aide de SQL*Plus, affectez à la variable
d'environnement ORACLE_SID le SID ASM. Par défaut, il s'agit de +ASM pour une
base de données à instance unique. Pour un noeud Oracle RAC, il s'agit de
+ASMnode_number, node_number correspondant au numéro du noeud. Le script
oraenv définit les variables ORACLE_BASE, ORACLE_SID, ORACLE_HOME et
PATH.
• Le fichier de paramètres d'initialisation doit contenir l'entrée suivante :
INSTANCE_TYPE = ASM
Ce paramètre indique que l'instance en cours de démarrage est une instance ASM et non
une instance de base de données.
• Lorsque vous exécutez la commande STARTUP au lieu d'essayer de monter et d'ouvrir la
base de données, elle tente de monter les groupes de disques indiqués par le paramètre
d'initialisation ASM_DISKGROUPS. Si vous n'avez pas affecté de valeur à ce paramètre,
vous pouvez ultérieurement monter un groupe de disques à l'aide de la commande
ALTER DISKGROUP...MOUNT.

Démarrer et arrêter des instances ASM à l'aide de SQL*Plus (suite)
La liste suivante décrit les paramètres de la commande STARTUP relatifs à ASM.
• FORCE : Applique une commande SHUTDOWN ABORT à l'instance ASM avant de la
redémarrer.
• MOUNT ou OPEN : Monte les groupes de disques indiqués par le paramètre d'initialisation
ASM_DISKGROUPS. Il s'agit de l'action par défaut si aucun paramètre de commande n'est
défini.
• NOMOUNT : Démarre l'instance ASM sans monter aucun groupe de disques.
• RESTRICT : Démarre une instance en mode d'accès restreint. La clause RESTRICT peut être
combinée aux clauses MOUNT, NOMOUNT et OPEN.
En mode d'accès restreint, les instances de base de données ne peuvent pas utiliser les groupes
de disques. Autrement dit, les bases de données ne peuvent pas ouvrir les fichiers du groupe. Par
ailleurs, si un groupe de disques est monté par une instance en mode restreint, il ne peut être
monté par aucune autre instance du cluster. Le mode restreint permet d'effectuer des tâches de
maintenance sur un groupe de disques sans être gêné par les accès client. Lorsque vous effectuez

des opérations de rééquilibrage pendant qu'un groupe de disques est en mode d'accès restreint,
vous évitez les messages de verrouillage et de déverrouillage qui sont générés entre les instances
ASM dans un environnement clusterisé. Cela améliore leurs performances. A la fin de la période
de maintenance, vous devez démonter le groupe de disques explicitement puis le remonter en
mode normal.
Le processus d'arrêt d'une instance ASM est lancé lorsque vous exécutez la commande SHUTDOWN
dans SQL*Plus. Au préalable, assurez-vous que les variables d'environnement ORACLE_SID et
ORACLE_HOME sont définies afin que vous puissiez vous connecter à l'instance ASM.
Avant d'arrêter une instance ASM, il est fortement recommandé d'arrêter toutes les instances de base
de données qui l'utilisent.
La liste suivante décrit les paramètres de la commande STARTUP relatifs à ASM.
• NORMAL : ASM attend la fin des instructions SQL en cours pour démonter tous les groupes de
disques et arrêter l'instance ASM. ASM attend également que tous les utilisateurs se
déconnectent de l'instance. Si plusieurs instances de base de données sont connectées à l'instance
ASM, la commande SHUTDOWN renvoie une erreur et laisse l'instance ASM s'exécuter NORMAL
est le mode d'arrêt par défaut.
• IMMEDIATE ou TRANSACTIONAL : ASM attend la fin des instructions SQL en cours pour
démonter tous les groupes de disques et arrêter l'instance ASM. En revanche, il n'attend pas que
les utilisateurs actuellement connectés à l'instance soient déconnectés. Si plusieurs instances de
base de données sont connectées à l'instance ASM, la commande SHUTDOWN renvoie une erreur
et laisse l'instance ASM s'exécuter
• ABORT : L'instance ASM est arrêtée immédiatement sans que les groupes de disques soient
démontés de manière ordonnée. Dans ce cas, la récupération a lieu au démarrage suivant d'ASM.
Si une instance de base de données est connectée à l'instance ASM, elle est abandonnée.
Remarque : Les modes NORMAL, IMMEDIATE ou TRANSACTIONAL de l'arrêt ne s'appliquent pas
lorsqu'il existe des instances de SGBDR connectées. Le message d'erreur suivant est renvoyé :
ORA-15097: cannot SHUTDOWN ASM instance with connect RDBMS
instance

à l'aide de srvctl
L'utilitaire Server Control (srvctl) peut être utilisé pour
démarrer et arrêter des instances ASM.
$ . oraenv
The Oracle base for
ORACLE_HOME=/u01/app/oracle/product/11.2.0/grid is
/u01/app/oracle
$ srvctl start asm -o mount
$ srvctl stop asm -f

L'utilitaire Server Control (srvctl) peut être utilisé pour vérifier
le statut d'instances ASM.
$ srvctl status asm
ASM is running on edrsr25p1
Démarrer et arrêter des instances ASM à l'aide de srvctl

L'utilitaire Server Control (srvctl) peut être utilisé pour démarrer et arrêter des instances
ASM ainsi que d'autres ressources gérées par Grid Infrastructure. Il se trouve dans le répertoire
ORACLE_HOME/bin de Grid Infrastructure et d'Oracle Database. Vous devez utiliser la
version située à l'emplacement ORACLE_HOME de Grid Infrastructure pour gérer les instances
ASM, les processus d'écoute (listeners) ou les opérations Oracle Restart. srvctl permet de
contrôler ASM de plusieurs manières :
• Pour démarrer une instance ASM :
srvctl start asm [-o <start_option>]
<start_option> désigne l'une des options (facultatives) de démarrage
d'instance valides
(FORCE, MOUNT, OPEN, NOMOUNT ou RESTRICT)
• Pour arrêter une instance ASM :
srvctl stop asm [-o <stop_option>] -f
<start_option> désigne l'une des options (facultatives) d'arrêt d'instance
valides
(NORMAL, IMMEDIATE, TRANSACTIONAL ou ABORT)
-f est l'option de forçage
• Pour obtenir le statut d'une instance ASM :
srvctl status asm

à l'aide de l'utilitaire asmcmd
L'utilitaire asmcmd fournit une interface de ligne de commande
qui permet de gérer ASM sans utiliser le langage SQL.
$ . oraenv
/u01/app/oracle
$ asmcmd
ASMCMD> startup
ASM instance started
Total System Global Area 284565504 bytes

Fixed Size 1336028 bytes

Variable Size 258063652 bytes
ASM Cache 25165824 bytes
ASM diskgroups mounted
ASM diskgroups volume enabled
ASMCMD> shutdown --abort
ASM instance shut down
Démarrer et arrêter des instances ASM à l'aide de l'utilitaire asmcmd

Les métadonnées ASM destinées à l'administration se trouvent dans les vues dynamiques des
performances contenues dans l'instance ASM. Vous accédez généralement à ces vues à l'aide
d'un utilitaire ASM qui utilise le langage SQL. Or l'apprentissage de SQL n'est généralement
pas inclus dans le cursus d'un administrateur système ou d'un administrateur de stockage.
L'utilitaire asmcmd fournit un environnement qui ressemble à un interpréteur de commandes
et qui accepte une syntaxe de type UNIX pour les tâches courantes d'administration d'ASM.
Vous pouvez l'utiliser pour gérer les instances ASM, les groupes de disques, le contrôle
d'accès aux fichiers pour les groupes de disques, les fichiers et répertoires stockés dans les
groupes de disques, les modèles de groupe de disques et les volumes.
Par exemple, vous pouvez démarrer et arrêter votre instance ASM à l'aide d'asmcmd. Les
options de démarrage suivantes sont prises en charge :
--nomount démarre l'instance ASM sans monter aucun groupe de disques.
--restrict démarre l'instance ASM et limite l'utilisation de la base de
données.
--pfile <pfile.ora> démarre l'instance ASM avec un fichier de
paramètres personnalisé.
Les options d'arrêt suivantes sont prises en charge :
--immediate effectue un arrêt immédiat.
--abort abandonne toutes les opérations existantes.

Screen reader h int: T his
slide conta ins a d iagra m that
is exp lain ed in t he sp eaker
notes.
Présentation des groupes de disques

Instance Instance Instance Instance Instance
Oracle Oracle Oracle Oracle Oracle
Database Database Database Database Database
Instance ASM Instance ASM Instance ASM Instance ASM Instance ASM
Serveurs
Oracle RAC
Base de Base de Base de
données données données

Pool de stockage ASM clusterisé
Disque 1 Disque 2 Disque 3 Disque 4 Disque 5 Disque 6

Fichier 3 Fichier 4
Fichier 1 Fichier 2
Groupe de disques A Groupe de disques B
Présentation des groupes de disques

Un groupe de disques est un regroupement logique de disques gérés collectivement par ASM.
Chaque groupe contient ses propres métadonnées. Vous pouvez rapprocher ce concept de
celui de volume logique dans un réseau de stockage (SAN) standard.
L'espace disponible au sein d'un groupe de disques est alloué aux fichiers. Le contenu des
fichiers est réparti équitablement entre les disques du groupe (striping) pour éliminer les
points d'accès unique et obtenir des performances uniformes. Chaque fichier ASM est
entièrement stocké dans un seul groupe de disques. En revanche, un groupe de disques peut
comporter des fichiers qui appartiennent à plusieurs bases de données, et une même base de
données peut utiliser des fichiers provenant de plusieurs groupes de disques.
La redondance est un attribut clé des groupes de disques. Elle peut être de trois niveaux :
• Redondance externe : ASM n'assure aucune mise en miroir et les disques sont supposés
hautement fiables.
• Redondance normale : ASM prend en charge la mise en miroir bidirectionnelle par défaut
afin d'assurer l'intégrité des données pour les périphériques de stockage moins fiables.
• Redondance élevée : ASM prend en charge la mise en miroir tridirectionnelle par défaut
pour garantir encore mieux l'intégrité des données.
Vous pouvez créer jusqu'à 63 groupes de disques ASM, mais quelques-uns suffisent pour la
plupart des installations.

Disques ASM
Caractéristiques des disques ASM :
• Ce sont les périphériques de stockage constituant les groupes
de disques ASM.
• Ils sont accessibles via les interfaces normales des systèmes
d'exploitation.
• Ils doivent être accessibles en lecture et en écriture au
propriétaire d'ASM.
• Ils doivent être accessibles à tous les noeuds d'un cluster.
• Ils peuvent avoir des noms ou des chemins d'accès OS différents
sur différents noeuds.

• Il peut s'agir des éléments suivants :
– Disque physique entier ou partition d'un disque physique
– Disque ou partition d'une unité de stockage
– Volume logique (LV) ou unité logique (LUN)
– Fichier réseau (NFS)
Disques ASM
Un groupe de disques ASM contient un ou plusieurs disques ASM.
Ceux-ci doivent être accessibles en lecture et en écriture au propriétaire d'ASM à partir de
tous les noeuds du cluster.
Un disque ASM peut être une partition de disque, mais Oracle déconseille fortement de
partager les disques physiques utilisés par ASM avec d'autres applications. En effet, pour que
la stratégie de striping et de mise en miroir fonctionne au mieux, les performances d'E/S des
disques ASM doivent être similaires et cohérentes au sein du groupe, ce qui est difficile à
garantir lorsque les disques sont utilisés par d'autres applications.
Il n'est pas nécessaire que les noms générés par le système d'exploitation pour les disques
ASM soient identiques sur les différents noeuds d'un cluster. ASM identifie les membres d'un
groupe en lisant les en-têtes des disques ASM.
En général, les disques ASM sont des unités logiques de stockage (LUN) "raw" provenant
d'une unité de stockage présentée à ASM. Il peut également s'agir de fichiers situés sur un
serveur de fichiers NFS distant.

Unités d'allocation
Les disques ASM sont divisés en unités d'allocation.

• La taille des unités d'allocation peut être configurée lors de
la création du groupe de disques.
• La taille par défaut est de 1 Mo :
– Assez petite pour la mise en mémoire cache par la base de
données et assez grande pour un accès séquentiel efficace
• Tailles prises en charge :
– 1, 2, 4, 8, 16, 32 et 64 Mo

– Les unités d'allocation de grande taille peuvent être utiles
pour les bases de données très volumineuses (VLDB) ou un
matériel de stockage spécialisé.
Unités d'allocation
L'espace disponible sur un disque ASM est divisé en unités d'allocation. La taille par défaut
des unités d'allocation est de 1 Mo, ce qui est assez faible pour éviter les points d'accès
uniques, mais assez important pour assurer un accès séquentiel efficace. Vous pouvez définir
la taille des unités d'allocation lorsque vous créez un groupe de disques. Il est impossible de
changer cette valeur ultérieurement. Il peut être utile de définir des unités d'allocation de
grande taille dans les scénarios incluant une base de données très volumineuse (VLDB) ou un
matériel de stockage spécialisé. Lorsqu'une unité d'allocation fait l'objet d'accès répétés, le
noyau de la base de données la met en mémoire cache pour plus d'efficacité.

Fichiers ASM
Caractéristiques des fichiers ASM :
• Ce sont des collections d'extents ASM composés d'unités
d'allocation.
– Les extents de taille variable prennent en charge les fichiers de grande
taille.
• Ils apparaissent comme des fichiers normaux pour le noyau de la
base de données.
• Leur nom de fichier commence par le signe +
– Exemple : +DATA/orcl/datafile/system.256.689832921
• Ils peuvent être associés à un alias de nom de fichier (facultatif)
– Exemple : +DATA/dbfiles/mydb/system01.dbf

• Ils sont répartis équitablement entre les membres d'un groupe de
disques.
• Ils sont mis en miroir conformément aux stratégies définies dans le
groupe de disques.
Fichiers ASM
ASM met un ensemble de fichiers à la disposition de ses clients. Un fichier ASM est constitué
d'unités d'allocations et apparaît comme un fichier standard pour le noyau de la base de
données.
Chaque fichier ASM a un nom unique généré par le système. La diapositive ci-dessus donne
un exemple de nom de fichier ASM entièrement qualifié. Ce nom représente une hiérarchie
qui commence par le signe plus (+) concaténé avec le nom du groupe de disques. Les
éléments suivants de la hiérarchie sont le nom de la base de données et le type de fichier. Le
dernier élément comprend un nom de balise, un numéro de fichier et un numéro de version. Il
est possible de créer un alias pour avoir une référence plus conviviale au fichier.
Les fichiers sont répartis équitablement entre les membres d'un groupe de disques ASM selon
la stratégie SAME (Stripe And Mirror Everything).
ASM prend en charge la plupart des types de fichier de base de données (fichiers de données,
fichiers journaux, fichiers de contrôle, sauvegardes RMAN, etc.). Avant la version Oracle
Database 11g Release 2, il ne prenait en charge que les fichiers de base de données Oracle et
ne pouvait pas être utilisé pour stocker et gérer les fichiers trace et les fichiers d'alertes ASCII,
les fichiers binaires Oracle, le registre OCR (Oracle Cluster Registry) et le disque votant d'un
cluster. Oracle Database 11g Release 2 élimine cette restriction en permettant d'exécuter un
système de fichier généraliste sur ASM.

Topographie des extents
Groupe de
disques
Fichier ASM
Disque A
1
5
Topographie
des extents Disque B
2
6
Disque C

7
Disque D
Extent du
fichier 4
8
Topographie des extents

ASM mémorise la répartition d'un fichier à l'aide de métadonnées décrivant la topographie
des extents (ensembles de blocs contigus). Celle-ci est une table de correspondance entre les
extents de données d'un fichier et les unités d'allocation des disques.
La mise en relation entre les extents des fichiers et les unités d'allocation s'effectue comme
suit :
• 1 unité d'allocation par extent pour les 20 000 premiers extents (0-19999)
• 4 unités d'allocation par extent pour les 20 000 extents suivants (20000-39999)
• 16 unités d'allocation par extent au-delà de 40 000 extents
Pour prendre en charge les fichiers ASM très volumineux, il est possible d'utiliser des extents
de taille variable avec des unités d'allocation de grande taille.

Niveau de détail du striping
Dans ASM, le striping a deux objectifs : équilibrer la charge et

réduire les temps d'attente liés aux entrées/sorties.
• Le striping grossier concatène des unités d'allocation à des
fins d'équilibrage de la charge.
– Exemple :

Groupe de disques ASM
Niveau de détail du striping

Dans la technologie ASM, la répartition des données entre les disques (striping) répond à
deux préoccupations majeures :
• Equilibrer la charge d'E/S entre les membres d'un groupe de disques
• Améliorer les temps d'attente liés aux entrées-sorties
Un striping grossier répartit les unités d'allocation entre les disques d'un groupe dans le but
d'équilibrer la charge. ASM répartit les unités d'allocation d'un fichier uniformément entre
tous les disques du groupe. La répartition de départ n'est pas toujours parfaitement équitable,
mais elle évolue dans le temps vers une quasi égalité. Le graphique ci-dessus représente un
fichier qui comprend cinq unités d'allocation réparties entre cinq disques d'un groupe à
redondance externe constitué de huit disques au total.
Pour les 20 000 premiers extents, la taille de l'extent est égale à la taille de l'unité d'allocation.
Entre 20 000 et 40 000 extents, les extents sont alloués par jeux de 8, avec une taille égale à 4
unités d'allocation. Si la taille de l'unité d'allocation est de 1 Mo, cela veut dire que le fichier
ASM croît de 32 Mo à la fois (8*4*1 Mo). Si le fichier est réparti selon un striping grossier,
ces jeux de 8 extents sont divisés en stripes d'une unité d'allocation chacun. Le striping n'est
pas effectué au niveau des extents, mais au niveau des unités d'allocation. Ainsi, quelle que
soit sa taille, un fichier réparti selon un striping grossier a chacune de ses unités d'allocation
sur un disque différent de la précédente. Au-delà de 40 000, les extents sont toujours alloués
par jeux de 8, mais avec une taille égale à 16 unités d'allocation.

Striping fin
Le striping fin répartit des unités de 128 Ko entre les groupes
d'unités d'allocation pour réduire l'attente liée aux entrées/sorties.
• Groupe de 8 disques avec redondance externe
• Unités d'allocation de 1 Mo (taille par défaut)
• Premier extent de 1 Mo écrit en stripes de 128 Ko dans 8
unités d'allocation

Striping fin
Le striping fin fractionne les extents de données en portions (stripes) de 128 Ko, ce qui
améliore les performances des entrées-sorties pour certains types de fichier en distribuant la
charge associée à chaque extent entre plusieurs disques. Ce type de striping est utilisé par
défaut pour les fichiers de contrôle et les fichiers de journalisation en ligne.
Le diagramme ci-dessus illustre le fonctionnement du striping fin. Dans cet exemple, le
premier extent (1 Mo) d'un nouveau fichier finit par occuper les premiers 128 Ko de 8 unités
d'allocation distinctes réparties entre les huit membres du groupe de disques. Une opération de
lecture ou d'écriture d'un méga-octet fait donc intervenir huit disques au lieu d'un seul.

Striping fin
Exemple :
• Groupe de 8 disques avec redondance externe
• Unités d'allocation de 1 Mo (taille par défaut)
• Extent suivant de 1 Mo réparti par fractions (stripes) de
128 Ko entre les 8 mêmes unités d'allocation jusqu'à leur
saturation

Striping fin (suite)

Reprenons l'exemple précédent et considérons l'extent suivant. Les tronçons de 128 Ko
correspondants sont placés à la suite des précédents dans les mêmes unités d'allocation. Ce
processus continue jusqu'à ce que le premier ensemble d'unités d'allocation soit saturé, puis
recommence avec un nouveau jeu d'unités d'allocation.

Groupes d'échec ASM
• Un groupe d'échec est un ensemble de disques partageant
une ressource dont les pannes doivent être tolérées.
• Les copies miroir des extents sont stockées dans des
groupes d'échec distincts.
• Les limites des groupes d'échec dépendent des unités de
stockage.
– Exemple basé sur les contrôleurs de disque :

Groupes d'échec ASM

Les membres d'un groupe de disques peuvent être organisés en groupes d'échec. Ceux-ci
permettent à l'administrateur du stockage ou de la base de données de définir les limites
matérielles de la mise en miroir ASM.
Par exemple, tous les disques rattachés à un contrôleur de disque peuvent être inclus dans un
même groupe d'échec. Dans ce cas, la mise en miroir des extents des fichiers est effectuée sur
des disques rattachés à des contrôleurs distincts. Par ailleurs, un administrateur peut
configurer ASM pour qu'il utilise la stratégie par défaut, qui consiste à définir chaque disque
dans son propre groupe d'échec.
Vous pouvez utiliser le critère de votre choix pour définir les groupes d'échec, en fonction des
éléments à protéger : disques, contrôleurs, composants réseau d'E/S ou système de stockage
complet. Les administrateurs analysent généralement leur environnement de stockage pour
concevoir des groupes d'échec adaptés à des scénarios de panne prévisibles.
Il incombe à l'administrateur de la base de données ou du stockage de déterminer la meilleure
configuration des groupes de stockage pour une installation donnée.

Striping et mise en miroir : Exemple
Groupe de disques à redondance normale composé de

8 disques répartis en deux groupes d'échec

Striping et mise en miroir : Exemple

La diapositive ci-dessus illustre un exemple de striping et de mise en miroir dans un groupe
de disques à redondance normale. Les pavés rouges représentent un fichier dont les cinq
extents sont répartis entre cinq des huit membres du groupe de disques. Les pavés bleus
représentent les copies miroir de ces extents. Notez que chaque extent a une copie miroir dans
chaque groupe d'échec quelle que soit la répartition entre les différents disques et groupes
d'échec.
Lors de l'allocation d'un fichier, les extents principaux sont alloués dans un souci de
performances, et les copies secondaires, dans un souci d'intégrité. C'est pourquoi toutes les
opérations de lecture de la base de données utilisent par défaut les extents principaux.

Exemple de panne de disque
Si le disque H tombe en panne, les extents qu'il contenait sont
régénérés à partir des copies miroir stockées sur d'autres
disques.

Exemple de panne de disque

Reprenons la configuration de la diapositive précédente et supposons que toutes les données
du disque H deviennent inaccessibles à cause d'une panne. Tous les extents de ce disque
doivent donc être récupérés et copiés sur un autre disque.
Les copies survivantes des extents 3 et 5 sont transférées dans une région libre d'un autre
disque du même groupe d'échec. Dans l'exemple ci-dessus, l'extent 5 est copié du disque B
vers le disque F, et l'extent 3 est copié du disque C vers le disque G.
Pour finir, ASM supprime le disque en panne du groupe de disques.
La suppression d'un disque déclenche à peu près la même procédure, avec une étape préalable
qui consiste à copier ailleurs les extents stockés sur le disque.

Gérer les groupes de disques
CREATE DISKGROUP
Instance ASM DROP DISKGROUP

Instance de
base de données
ALTER DISKGROUP
Gérer les groupes de disques

Les instances ASM servent essentiellement à gérer les groupes de disques et à protéger leurs
données. Par ailleurs, elles communiquent l'emplacement des fichiers aux instances de base de
données. Ces dernières peuvent ainsi accéder directement aux fichiers stockés dans les
groupes de disques.
Il existe plusieurs commandes pour l'administration des groupes de disques. Toutes
nécessitent le privilège SYSASM ou SYSDBA et doivent être exécutées à partir d'une instance
ASM.
Vous pouvez notamment créer et supprimer des groupes de disques, ou modifier des groupes
existants en ajoutant ou supprimant des disques.

Créer et supprimer des groupes de disques
à l'aide de SQL*Plus
$ . oraenv
/u01/app/oracle
$ sqlplus / AS SYSASM
SQL*Plus: Release 11.2.0.1.0 - Production on Wed Jul 8 20:46:46 2009
..
SQL> CREATE DISKGROUP dgroupA NORMAL REDUNDANCY
FAILGROUP controller1 DISK
'/devices/A1' NAME diskA1 SIZE 120G FORCE,
'/devices/A2',

FAILGROUP controller2 DISK
'/devices/B1',
'/devices/B2';
SQL> DROP DISKGROUP dgroupA INCLUDING CONTENTS;
Créer et supprimer des groupes de disques

Supposons que le repérage des disques ASM a identifié les disques A1, A2, B1 et B2 dans le
répertoire /dev. Supposons en outre que les disques A1 et A2 ne dépendent pas du même
contrôleur que les disques B1 et B2. Le premier exemple de la diapositive ci-dessus montre
comment configurer un groupe de disques nommé DGROUPA avec deux groupes d'échec :
CONTROLLER1 et CONTROLLER2.
Il utilise pour ce groupe l'attribut de redondance par défaut NORMAL REDUNDANCY. Il n'est
pas obligatoire de préciser le nom et la taille des disques. Si vous n'indiquez pas ces
informations, ASM crée un nom par défaut et tente de déterminer la taille du disque. S'il n'y
parvient pas, une erreur est renvoyée. La clause FORCE indique que le disque doit être ajouté
au groupe indiqué même s'il est déjà formaté en tant que membre d'un groupe de disques
ASM. L'utilisation de cette option pour un disque non formaté en tant que membre d'un
groupe de disques ASM renvoie une erreur.
La deuxième instruction de la diapositive supprime un groupe de disques et tous les fichiers
qui y sont stockés. Pour éviter les suppressions accidentelles, l'option INCLUDING
CONTENTS doit être précisée si le groupe de disques contient encore des fichiers autres que
les métadonnées ASM internes. Un groupe de disques ne peut être supprimé que s'il est
monté. ASM vérifie qu'aucun des fichiers du groupe de disques n'est ouvert, puis supprime le
groupe et tous ses membres. L'en-tête de chaque disque est alors remplacé par un en-tête sans
informations de formatage ASM.

Ajouter des disques à un groupe
ALTER DISKGROUP dgroupA ADD DISK

'/dev/sde1' NAME A5,
'/dev/sdf1' NAME A6,
'/dev/sdg1' NAME A7,
'/dev/sdh1' NAME A8;
ALTER DISKGROUP dgroupA ADD DISK '/devices/A*';

Formatage de disque
Rééquilibrage du groupe de disques
Ajouter des disques à un groupe

La diapositive ci-dessus illustre l'ajout de disques à un groupe à l'aide de la commande
ALTER DISKGROUP ADD DISK. La première instruction ajoute quatre disques au groupe
DGROUPA.
La seconde instruction met en évidence les interactions entre chaînes de repérage.
Considérons la configuration suivante :
/devices/A1 est membre du groupe de disques DGROUPA.
/devices/A4 est un disque candidat.
La deuxième commande ajoute A4 au groupe de disques DGROUPA. Elle ignore les autres
disques (bien qu'ils correspondent à la chaîne de repérage) parce qu'ils font déjà partie du
groupe DGROUPA. Lorsque vous ajoutez un disque à un groupe, l'instance ASM vérifie qu'il
est accessible et utilisable, puis elle le formate et rééquilibre le groupe. Le processus de
rééquilibrage prend du temps car il doit transférer vers le nouveau disque des extents
provenant de tous les fichiers.
Remarque : Le rééquilibrage ne bloque aucune opération de base de données. Il ne fait
qu'augmenter la charge d'E/S sur le système. Plus le rééquilibrage est important, moins il reste
de bande passante pour les E/S de la base de données.

Commandes ALTER
Supprimer un disque du groupe dgroupA :
ALTER DISKGROUP dgroupA DROP DISK A5;
Ajouter et supprimer un disque en une seule commande :
ALTER DISKGROUP dgroupA

DROP DISK A6
ADD FAILGROUP controller3
DISK '/dev/sdi1' NAME A9;

Annuler une opération de suppression de disque :
ALTER DISKGROUP dgroupA UNDROP DISKS;
Commandes ALTER
La première instruction de la diapositive ci-dessus supprime un membre du groupe de disques
DGROUPA. La deuxième instruction cumule une suppression et un ajout de disque. L'avantage
est que le rééquilibrage ne commence que lorsque les deux opérations ont été effectuées. La
troisième instruction annule la suppression d'un disque. La commande UNDROP opère
uniquement sur les suppressions de disque en attente. Elle n'a pas d'effet sur les suppressions
déjà effectuées.
L'instruction suivante rééquilibre le groupe de disques DGROUPB, si nécessaire :
ALTER DISKGROUP dgroupB REBALANCE POWER 5;
Cette commande n'est généralement pas nécessaire, car elle est exécutée automatiquement
lorsque des disques sont ajoutés, supprimés ou redimensionnés. Elle est toutefois utile si vous
souhaitez indiquer la clause POWER pour remplacer la vitesse par défaut définie par le
paramètre d'initialisation ASM_POWER_LIMIT. Vous pouvez modifier la vitesse d'une
opération de rééquilibrage en cours en entrant cette commande avec une autre valeur de
POWER. La valeur 0 interrompt l'opération de rééquilibrage jusqu'à ce que la commande
REBALANCE soit à nouveau lancée (implicitement ou explicitement). L'instruction suivante
démonte le groupe de disques DGROUPA :
ALTER DISKGROUP dgroupA DISMOUNT;
Les options MOUNT et DISMOUNT permettent de contrôler les groupes de disques mis à la
disposition des instances de base de données. La possibilité de monter et démonter
manuellement les groupes de disques est utile dans un environnement ASM clusterisé qui
prend en charge une seule instance, lorsque cette instance change de noeud suite à une panne.

Gérer ASM à l'aide d'Enterprise Manager

Gérer ASM à l'aide d'Enterprise Manager

Oracle Enterprise Manager (EM) est une famille d'outils pour la gestion de bases de données,
de middleware, d'applications, de réseaux, d'infrastructures informatiques, etc. Il fournit un
environnement de type navigateur qui permet d'effectuer les tâches courantes d'administration
de l'environnement ASM à l'aide de la souris.

Compatibilité des groupes de disques ASM
• Le niveau de compatibilité peut être contrôlé individuellement
pour chaque groupe de disques :
– La compatibilité ASM concerne la structure des métadonnées ASM
sur disque.
– La compatibilité RDBMS contrôle la version minimale des clients
utilisateurs.
– La compatibilité ADVM indique si un groupe de disques peut
contenir des volumes Oracle ASM.
• Une fois définie, la compatibilité d'un groupe de disques ne peut
plus être modifiée.
Instance Groupe de Instance

de BdD disques ASM
ASM
COMPATIBLE >= COMPATIBLE.RDBMS
<=
COMPATIBLE.ASM <= COMPATIBLE
>=
COMPATIBLE.ADVM
Compatibilité des groupes de disques ASM

Trois types de compatibilité s'appliquent aux groupes de disques ASM. Ils concernent les
structures de données persistantes qui décrivent un groupe de disques, les fonctionnalités des
clients (utilisateurs des groupes de disques) et la possibilité de placer des volumes dans un
groupe de disques. Les attributs de compatibilité correspondants sont respectivement ASM,
RDBMS et ADVM. Le niveau de compatibilité est contrôlé individuellement pour chaque
groupe de disques. Cela permet d'avoir des environnements hétérogènes comprenant des
groupes de disques Oracle Database 10g et Oracle Database 11g. Pour chaque groupe de
disques ASM, vous pouvez définir les trois attributs de compatibilité suivants :
• La compatibilité RDBMS définit la version minimale de la base de données qui permet à
une instance de monter le groupe de disques. Ce paramètre détermine le format des
messages échangés entre l'instance ASM et l'instance de base de données. Une instance
ASM est capable de prendre en charge divers clients de base de données s'exécutant avec
des niveaux de compatibilité différents. Le niveau de compatibilité d'une instance de base
de données doit être supérieur ou égal au niveau de compatibilité RDBMS de tous les
groupes de disques utilisés par la base. Les instances de base de données sont
généralement exécutées à partir d'un répertoire d'origine Oracle Home différent de celui
de l'instance ASM. Cela implique que l'instance de base de données et l'instance ASM
peuvent exécuter des versions de logiciel différentes. Quand une instance de base de
données se connecte pour la première fois à une instance ASM, elle négocie la version
maximale que les deux instances peuvent prendre en charge.

Compatibilité des groupes de disques ASM (suite)
Le paramètre de compatibilité de la base de données, la version du logiciel de base de données et
le paramètre de compatibilité RDBMS du groupe de disques déterminent si l'instance de base de
données peut monter le groupe de disques considéré.
• La compatibilité ASM est le paramètre de compatibilité persistant qui contrôle le format des
structures de métadonnées ASM sur disque. Le niveau de compatibilité ASM d'un groupe de
disques doit toujours être supérieur ou égal au niveau de compatibilité RDBMS de ce groupe. La
compatibilité ASM concerne uniquement le format des métadonnées ASM. Le format du
contenu des fichiers est déterminé par l'instance de base de données. Par exemple, un groupe de
disques peut avoir l'attribut de compatibilité ASM 11.0 et l'attribut de compatibilité
RDBMS 10.1. Cela signifie que ce groupe ne peut être géré que par une version du logiciel ASM
égale ou supérieure à 11.0, mais qu'il peut être utilisé par tout client de base de données de
version 10.1 ou supérieure.
• L'attribut de compatibilité ADVM indique si un groupe de disques peut contenir des volumes
Oracle ASM. Sa valeur doit être égale ou supérieure à 11.2. Avant de définir cet attribut, vous

devez vous assurer que l'attribut COMPATIBLE.ASM a une valeur égale ou supérieure à 11.2 et
que les pilotes de volume ADVM sont chargés.
Il n'est nécessaire d'augmenter le niveau de compatibilité d'un groupe de disques qu'en cas de
modification des structures de disque persistantes ou du protocole d'échange de messages. Notez bien
qu'il s'agit d'un processus irréversible. Vous pouvez définir la compatibilité d'un groupe de disques à
l'aide des commandes CREATE DISKGROUP ou ALTER DISKGROUP.
Remarque : En plus des attributs de compatibilité des groupes de disques, le paramètre compatible
(version compatible de la base de données) détermine les fonctionnalités activées. Il s'applique à
l'instance de base de données ou à l'instance ASM, en fonction du paramètre instance_type. S'il a la
valeur 10.1 par exemple, il interdit l'utilisation des fonctionnalités introduites par Oracle
Database 11g (disque en ligne/hors ligne, extents de taille variable, etc.).

Attributs des groupes de disques ASM
Nom Commande Valeurs Description

au_size Create, Alter 1|2|4|8|16|32|64MB Taille des unités d'allocation dans le groupe
de disques
compatible.rdbms Create, Alter Version de base de Format des messages échangés entre la
données valide BdD et ASM
compatible.asm Create, Alter Version d'instance ASM Format des structures de métadonnées ASM
valide sur disque
compatible.advm Create, Alter Version d'instance ASM Autorise le stockage de volumes Oracle
valide ASM dans le groupe de disques
disk_repair_time Create, Alter 0 M à 232 D Délai au bout duquel un disque mis hors
ligne est supprimé
template.tname. Alter UNPROTECT|MIRROR|HIGH Niveau de redondance du modèle considéré
redundancy
COARSE|FINE

template.tname. Alter Niveau de striping du modèle considéré
stripe
CREATE DISKGROUP DATA2 NORMAL REDUNDANCY

DISK '/dev/sda1','/dev/sdb1'
ATTRIBUTE 'compatible.asm'='11.2';
Attributs des groupes de disques ASM

Lorsque vous créez ou modifiez un groupe de disques ASM, vous avez la possibilité de
changer ses attributs à l'aide de la nouvelle clause ATTRIBUTE des commandes CREATE
DISKGROUP et ALTER DISKGROUP. Ces attributs sont décrits brièvement dans le tableau
ci-dessus.
• ASM permet d'utiliser différentes tailles d'unité d'allocation que vous précisez lorsque
vous créez un groupe de disques, à savoir 1, 2, 4, 8, 16, 32 ou 64 Mo.
• Attribut compatible.rdbms : Voir la section "Compatibilité des groupes de disques
ASM" pour plus d'informations.
• Attribut compatible.asm : Voir la section "Compatibilité des groupes de disques
ASM" pour plus d'informations.
• Vous pouvez définir DISK_REPAIR_TIME en minutes (M), en heures (H) ou en jours
(D). L'unité par défaut est H. La valeur par défaut de cet attribut est 3.6H. Pour la
remplacer par une autre valeur, utilisez l'instruction ALTER DISKGROUP ... DISK
OFFLINE.
• Vous pouvez définir l'attribut de redondance du modèle indiqué.
• Vous pouvez également définir l'attribut de striping du modèle indiqué.
Remarque : Vous pouvez consulter les attributs de chaque groupe de disques défini dans la
vue V$ASM_ATTRIBUTE.

Modifier les attributs des groupes de disques
à l'aide d'Enterprise Manager

Modifier les attributs des groupes de disques à l'aide d'Enterprise Manager

Enterprise Manager fournit un moyen simple d'enregistrer et d'extraire les paramètres
d'environnement relatifs aux groupes de disques.
Vous pouvez définir les attributs de compatibilité dans les pages Create Disk Group et Edit
Disk Group Advanced Attributes. L'attribut disk_repair_time n'apparaît que dans la
page Edit Disk Group Advanced Attributes.
Remarque : Pour les instances ASM antérieures à la version 11g, les deux attributs de
compatibilité ASM Compatibility et Database Compatibility ont par défaut la valeur 10.1.
Pour les instances ASM 11g, ASM Compatibility a par défaut la valeur 11.2 et Database
Compatibility a par défaut la valeur 10.1.

Extraire des métadonnées ASM
• A l'aide de SQL*Plus :
SQL> SELECT f.type, f.redundancy, f.striped, f.modification_date,
a.system_created, a.name FROM v$asm_alias a, v$asm_file f WHERE
a.file_number = f.file_number and a.group_number = f.group_number
and type='DATAFILE';
TYPE REDUND STRIPE MODIFICAT S NAME
-------- ------ ------ --------- - ---------------------
DATAFILE MIRROR COARSE 08-JUL-09 Y SYSTEM.256.689832921
DATAFILE MIRROR COARSE 08-JUL-09 Y SYSAUX.257.689832923
..
• A l'aide de l'utilitaire asmcmd :

ASMCMD> ls -l +DATA/orcl/datafile
Type Redund Striped Time Sys Name
DATAFILE MIRROR COARSE JUL 08 21:00:00 Y SYSTEM.256.689832921
DATAFILE MIRROR COARSE JUL 08 21:00:00 Y SYSAUX.257.689832923
..
Extraire des métadonnées ASM

L'instance ASM héberge les tables de métadonnées implantées en mémoire et les présente
sous forme de vues dynamiques des performances. Vous pouvez interroger ces tables à l'aide
de SQL*Plus, de l'utilitaire asmcmd ou d'Enterprise Manager.
SQL*Plus nécessite une bonne connaissance du langage SQL et peut impliquer des jointures
de vues pour extraire les informations voulues. Dans le premier exemple de la diapositive, les
vues v$asm_file et v$asm_alias sont jointes pour fournir les métadonnées concernant
les fichiers de données d'une base. Si cette interrogation est appliquée à l'instance ASM, elle
peut extraire les fichiers de données de plusieurs bases en fonction de la syntaxe utilisée.
Vous devez ajouter des filtres pour limiter les résultats à une seule base.
L'avantage de l'utilitaire asmcmd est qu'il permet d'extraire des métadonnées d'une instance
ASM sans connaître le langage SQL. Il utilise une syntaxe semblable à la notation UNIX. Le
deuxième exemple présenté ci-dessus extrait les mêmes métadonnées que le premier, mais en
utilisant asmcmd. L'autre avantage est que les résultats sont limités aux fichiers de données
d'une seule base car le chemin mentionné contient le nom de base de données orcl et le type
de fichier datafile. Pour obtenir le même filtrage dans SQL, il faudrait ajouter une clause
WHERE.
Remarque : Dans Enterprise Manager Database Control, vous pouvez afficher la plupart des
métadonnées ASM en accédant simplement aux diverses pages Web relatives à ASM.

Présentation de la fonctionnalité
ASM Fast Mirror Resync
1 Utilisation de la redondance ASM 2 Echec d'un accès disque
secondaire
principal
Extent
Extent
Oracle Database 11g

4 Le disque est à nouveau
3 Temps de panne
accessible ; il suffit de resynchroniser
< DISK_REPAIR_TIME
les extents modifiés
Présentation de la fonctionnalité ASM Fast Mirror Resync

La resynchronisation rapide de disque miroir ASM (ASM Fast Mirror Resync) réduit
considérablement le temps nécessaire à la resynchronisation après une panne de disque
momentanée. Lorsqu'un disque est mis hors ligne à cause d'une défaillance passagère, ASM
assure le suivi des extents qui sont modifiés pendant la panne. Ainsi, lorsque la panne est
réparée, ASM peut très vite effectuer une resynchronisation en la limitant aux extents
modifiés.
Cette fonctionnalité suppose que le contenu des disques ASM concernés n'a pas été
endommagé ni modifié par la panne.
Quand un accès à un disque ASM échoue, ce disque est mis hors ligne, mais il n'est pas
supprimé si vous avez défini l'attribut DISK_REPAIR_TIME pour le groupe de disques
correspondant. Cet attribut détermine la durée d'indisponibilité tolérée par ASM pour pouvoir
garantir la resynchronisation une fois la réparation terminée.
Remarque : Le mécanisme de suivi utilise un bit pour chaque unité d'allocation modifiée, ce
qui le rend très efficace.

Quiz
Quel paramètre est obligatoire pour une instance ASM ?

1. INSTANCE_TYPE
2. ASM_DISKGROUPS
3. LARGE_POOL_SIZE
4. Aucun des paramètres ci-dessus

Réponse : 1

Quiz
Quels sont les deux types de fichier pour lesquels le striping fin
est utilisé par défaut ?
1. Fichiers de données
2. Fichiers de contrôle
3. Fichiers temporaires
4. Fichiers de journalisation en ligne
5. SPFILE

Réponses : 2, 4

Synthèse

• gérer une instance ASM à l'aide de SQL*plus, de l'utilitaire
asmcmd et d'Enterprise Manager
• créer et supprimer des groupes de disques ASM
• définir les attributs de compatibilité ASM
• étendre des groupes de disques ASM
• comparer les méthodes d'extraction de métadonnées ASM


Gérer l'instance ASM
• créer un groupe de disques ASM à l'aide de l'utilitaire
asmcmd
• supprimer un groupe de disques ASM à l'aide d'Enterprise
Manager
• examiner les métadonnées ASM


Configurer l'environnement réseau Oracle

Objectifs

• utiliser Enterprise Manager pour :
– créer des processus d'écoute supplémentaires
– créer des alias de service Oracle Net
– configurer la gestion des incidents de connexion
– contrôler le processus d'écoute Oracle Net
• utiliser tnsping pour tester la connectivité Oracle Net
• déterminer quand utiliser des serveurs partagés et quand

utiliser des serveurs dédiés
Ressources
• Oracle Database Net Services Administrator’s Guide
• Oracle Database Net Services Reference

Services Oracle Net
Application RDBMS
Oracle Net Réseau Oracle Net

Client ou TCP/IP
Processus Serveur de base
niveau
d'écoute de données
intermédiaire

Fichiers de configuration Fichiers de configuration
Oracle Net Oracle Net
Services Oracle Net

Oracle Net Services permet les connexions réseau d'un client ou d'une application de niveau
intermédiaire (middle tier) au serveur Oracle. Après l'établissement d'une session réseau,
Oracle Net joue le rôle de transporteur de données pour l'application client et le serveur de
base de données. Il est responsable de l'établissement et de la maintenance de la connexion
entre l'application client et le serveur de base de données, ainsi que de l'échange des messages
entre eux. Oracle Net ou une simulation telle que JDBC (Java Database Connectivity), réside
sur chaque ordinateur qui doit communiquer avec le serveur de base de données.
Sur l'ordinateur client, Oracle Net est un composant en arrière-plan pour les applications qui
se connectent à la base de données.
Sur le serveur de base de données, Oracle Net comprend un processus actif appelé processus
d'écoute Oracle Net qui est chargé de coordonner les connexions entre la base de données et
les applications externes.
L'utilisation la plus courante d'Oracle Net Services est l'autorisation des connexions de base
de données entrantes. Vous pouvez configurer des services supplémentaires pour autoriser
l'accès aux bibliothèques de code externes (EXTPROC) et pour la connexion de l'instance
Oracle à des sources de données non Oracle, par exemple Sybase, Informix, DB2 ou SQL
Server, via les services hétérogènes (Heterogeneous Services) Oracle.

Processus d'écoute Oracle Net
Enterprise Processus d'écoute

Manager
Database
Control Bases de données
Oracle

Fichiers de configuration
Oracle Net
<Grid_home>/network/admin/listener.ora
./sqlnet.ora
Processus d'écoute Oracle Net

Le processus d'écoute Oracle Net (ou simplement le processus d'écoute) est la passerelle vers
l'instance Oracle pour toutes les connexions utilisateur non locales. Un même processus
d'écoute peut gérer plusieurs instances de base de données et des milliers de connexions
client.
Enterprise Manager est l'un des moyens permettant d'accéder à ce processus. Vous pouvez
contrôler la configuration du processus d'écoute proprement dit, ainsi que des paramètres
généraux tels que la protection par mot de passe et l'emplacement des fichiers journaux.
Les administrateurs chevronnés peuvent également configurer Oracle Net Services en éditant
manuellement les fichiers de configuration (si nécessaire) à l'aide d'un éditeur de texte
standard du système d'exploitation tel que vi ou gedit.
Remarque : Lors de l'installation de Grid Infrastructure for Standalone Server, le processus
d'écoute Oracle Net est lancé à partir du répertoire d'installation du logiciel <Grid_home>.
L'exécution d'un processus d'écoute à partir de cette installation est nécessaire pour permettre
la connexion à l'instance ASM. Ce processus est également utilisé par défaut pour surveiller
toutes les instances de base de données installées sur le même serveur.

Etablir des connexions réseau
Pour établir une connexion avec le client ou le niveau

intermédiaire, Oracle Net a besoin que le client connaisse les
informations suivantes :
• Hôte sur lequel le processus d'écoute s'exécute
• Port surveillé par le processus d'écoute
• Protocole utilisé par le processus d'écoute
• Nom du service géré par le processus d'écoute

Résolution
de noms
Etablir des connexions réseau

Pour qu'une application puisse se connecter à un service via un processus d'écoute Oracle Net,
elle doit connaître certaines informations sur ce service, notamment l'adresse ou l'hôte sur
lequel il réside, le protocole accepté et le port surveillé. Une fois le processus d'écoute
localisé, l'information finale dont l'application a besoin est le nom du service auquel elle doit
se connecter.
La résolution de noms Oracle Net est le processus qui consiste à déterminer ces informations
de connexion.

Etablir une connexion

Demande de
connexion entrante
Processus d'écoute
Etablir une connexion

Une fois la résolution de noms Oracle Net terminée, une demande de connexion est transmise
de l'utilisateur ou de l'application de niveau intermédiaire (le processus utilisateur) au
processus d'écoute. Ce dernier reçoit un paquet CONNECT et vérifie qu'il demande un nom de
service Oracle Net valide.
Si aucun nom de service n'est indiqué (comme dans le cas d'une demande tnsping), le
processus d'écoute accuse réception de la demande de connexion et ne fait rien de plus. Si un
nom de service non valide est demandé, le processus d'écoute transmet un code d'erreur au
processus utilisateur.

Sessions utilisateur
Processus
serveur
Session utilisateur PGA
Processus
utilisateur

Processus d'écoute
Sessions utilisateur
Si le paquet CONNECT demande un nom de service valide, le processus d'écoute crée un
nouveau processus afin de traiter la connexion. Ce nouveau processus est appelé processus
serveur. Le processus d'écoute s'y connecte et lui transmet les informations d'initialisation,
notamment l'adresse du processus utilisateur. A ce stade, le processus d'écoute ne gère plus la
connexion et tout le travail est transmis au processus serveur.
Le processus serveur vérifie les informations d'identification et de connexion de l'utilisateur
(généralement un mot de passe). Si elles sont valides, une session utilisateur est créée.
Processus serveur dédié : Une fois la session établie, le processus serveur joue le rôle
d'agent de l'utilisateur sur le serveur. Le processus serveur est responsable des opérations
suivantes :
• Analyse (parse) et exécution des instructions SQL exécutées par l'intermédiaire de
l'application.
• Examen du cache de tampons de la base pour rechercher les blocs de données requis pour
exécuter les instructions SQL.
• Lecture des blocs nécessaires à partir des fichiers de données sur disque dans la partie
cache de tampons de la base de données de la mémoire SGA, si les blocs ne sont pas déjà
présents dans celle-ci.
• Gestion de toutes les activités de tri. La zone de tri est une zone de mémoire qui est
utilisée pour les tris. Elle se trouve dans une portion de la mémoire associée à la mémoire
PGA (Program Global Area).
• Renvoi des résultats au processus utilisateur de sorte que l'application puisse traiter les
informations.
• Lecture des options d'audit et envoi d'un état sur les processus utilisateur à la destination
d'audit.
Outils de configuration et de gestion
de l'environnement réseau Oracle
• Page Net Services Administration d'Enterprise Manager

• Oracle Net Manager
• Oracle Net Configuration Assistant
• Ligne de commande

Outils de configuration et de gestion de l'environnement réseau Oracle

Vous disposez des outils ou applications ci-après pour gérer la configuration réseau Oracle :
• Enterprise Manager : Environnement intégré pour la configuration et la gestion
d'Oracle Net Services. Utilisez Enterprise Manager pour configurer Oracle Net Services
pour n'importe quel répertoire d'origine Oracle Home sur plusieurs systèmes de fichiers
et pour gérer les processus d'écoute.
• Oracle Net Manager : Interface utilisateur graphique qui permet de configurer Oracle
Net Services pour un répertoire d'origine Oracle Home sur un client local ou un hôte
serveur. Oracle Net Manager permet de configurer Oracle Net Services pour un
répertoire d'origine Oracle Home sur un client local ou un hôte serveur. Vous pouvez
utiliser Oracle Net Manager pour configurer les composants réseau suivants :
- Noms : Définissez des noms et des identificateurs de connexion simples, puis
mettez-les en correspondance avec des descripteurs de connexion afin de définir
l'emplacement et l'identification d'un service au sein du réseau. Oracle Net Manager
prend en charge la configuration d'identificateurs de connexion dans les fichiers
tnsnames.ora locaux ou un service d'annuaire centralisé.
- Méthodes de résolution des noms : Configurez les différentes manières de résoudre
les identificateurs de connexion en descripteurs de connexion.
- Profils : Configurez des préférences pour activer et configurer les fonctionnalités
Oracle Net sur le client ou le serveur.
- Processus d'écoute : Créez et configurez des processus d'écoute pour recevoir les
connexions client.

Outils de configuration et de gestion de l'environnement réseau Oracle (suite)
• Oracle Net Configuration Assistant : Assistant lancé par Oracle Universal Installer lors de
l'installation du logiciel Oracle. Il permet de configurer l'adresse du protocole d'écoute et les
informations relatives aux services pour une base de données Oracle. Pendant une installation
standard, Oracle Net Configuration Assistant configure automatiquement un processus d'écoute
nommé LISTENER qui comprend une adresse d'écoute TCP/IP pour la base de données. Si vous
effectuez une installation personnalisée, Oracle Net Configuration Assistant vous invite à
configurer le nom et l'adresse de votre choix pour le processus d'écoute. Utilisez Oracle Net
Configuration Assistant pour effectuer la configuration initiale du réseau après avoir installé la
base. Vous pouvez ensuite utiliser Oracle Enterprise Manager et Oracle Net Manager pour
configurer et administrer vos réseaux.
• Ligne de commande : Permet de démarrer le processus d'écoute, de l'arrêter et d'afficher son
statut. C'est un utilisateur du système d'exploitation (oracle dans ce cours) qui démarre ou
arrête le processus d'écoute. Si le processus d'écoute n'est pas démarré, vous ne pouvez pas
utiliser Enterprise Manager.

Utilitaire de contrôle des processus d'écoute
Les processus d'écoute Oracle Net peuvent être contrôlés à
l'aide de l'utilitaire en mode ligne de commande lsnrctl
(ou à partir d'Enterprise Manager).
$ . oraenv
$ lsnrctl
LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 30-JUN-2009 00:47:01
Welcome to LSNRCTL, type "help" for information.
LSNRCTL> help
The following operations are available

An asterisk (*) denotes a modifier or extended command:
start stop status
services version reload
save_config trace spawn
change_password quit exit
set* show*
Utilitaire de contrôle des processus d'écoute

Lorsqu'une instance démarre, un processus d'écoute établit une voie de communication vers la
base de données Oracle. Ce processus peut alors accepter les demandes de connexion à la
base.
Vous pouvez contrôler le processus d'écoute à l'aide de l'utilitaire lsnrctl. Celui-ci permet
les opérations suivantes :
• Démarrer le processus d'écoute
• Arrêter le processus d'écoute
• Vérifier le statut du processus d'écoute
• Réinitialiser le processus d'écoute à partir des paramètres du fichier de configuration
• Configurer dynamiquement plusieurs processus d'écoute
• Changer le mot de passe du processus d'écoute
La syntaxe de base de la commande de cet utilitaire est la suivante :
LSNRCTL> command [listener_name]
Lorsqu'une commande lsnrctl est exécutée, elle agit sur le processus d'écoute par défaut
(nommé LISTENER), sauf si le nom d'un autre processus d'écoute est indiqué ou s'il s'agit de
la commande SET CURRENT_LISTENER. Si le nom du processus d'écoute est LISTENER,
l'argument listener_name peut être omis. Les commandes valides pour lsnrctl sont
indiquées dans la diapositive ci-dessus.
Remarque : L'utilitaire lsnrctl se trouve dans les répertoires d'origine Oracle Home de
Grid Infrastructure et d'Oracle Database. Avant de l'utiliser, il est important de définir les
variables d'environnement pour le répertoire d'origine correct.

Syntaxe de l'utilitaire de contrôle
de processus d'écoute
Les commandes de l'utilitaire de contrôle de processus
d'écoute peuvent être exécutées à partir de la ligne de
commande ou de l'invite LSNRCTL.
• Ligne de commande :
$ lsnrctl <command name>
$ lsnrctl start
$ lsnrctl status
• Invite de l'utilitaire :

LSNRCTL> <command name>
LSNRCTL> start
LSNRCTL> status
Syntaxe de l'utilitaire de contrôle de processus d'écoute

Les commandes lsnrctl peuvent être exécutées à partir de l'invite de l'utilitaire ou à partir
de la ligne de commande. Les deux commandes suivantes ont le même effet, mais l'une est
exécutée à partir de la ligne de commande, et l'autre, à partir de l'invite de l'utilitaire :
Ligne de commande :
$ lsnrctl start
Invite de l'utilitaire :
$ lsnrctl
LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 30-
JUN-2009 01:00:01
Welcome to LSNRCTL, type "help" for information.
LSNRCTL> start
En général, la ligne de commande est utilisée pour exécuter des commandes individuelles ou
des scripts. Pour lancer plusieurs commandes lsnrctl consécutives, l'invite de l'utilitaire
est plus efficace. Notez que l'argument listener_name est omis. La commande STOP
affecterait donc le processus d'écoute nommé LISTENER. Vous devez nécessairement passer
par l'invite de l'utilitaire si le processus d'écoute est protégé par un mot de passe.

Syntaxe de l'utilitaire de contrôle du processus d'écoute (suite)
Rappelez-vous que si le processus d'écoute porte un nom autre que LISTENER, vous devez soit
inclure ce nom dans la commande, soit utiliser la commande SET CURRENT_LISTENER.
Supposons que le processus d'écoute soit nommé custom_lis. Voici deux exemples qui arrêtent le
processus custom_lis à partir de l'invite de l'utilitaire :
LSNRCTL> stop custom_lis
Connecting to
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host01)(PORT=5521)))
The command completed successfully
La syntaxe qui suit génère le même résultat :
LSNRCTL> set cur custom_lis
Current Listener is custom_lis
LSNRCTL> stop
Connecting to

Remarque : Dans la syntaxe précédente, current_listener a été abrégé en cur.
Il est possible d'obtenir les mêmes résultats à partir de la ligne de commande :
$ lsnrctl stop custom_lis
LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 30-JUN-2009
01:01:53
Connecting to

Utiliser SRVCTL pour démarrer
et arrêter le processus d'écoute
Si Oracle Restart est configuré pour surveiller votre processus
d'écoute, vous devez gérer ce dernier à l'aide de l'utilitaire
SRVCTL.
• Exemples :
$ srvctl -h
$ srvctl start listener
$ srvctl stop listener
$ srvctl start listener –l mylistener

$ srvctl status listener
Utiliser SRVCTL pour démarrer et arrêter le processus d'écoute

Vous devez utiliser SRVCTL pour démarrer un processus d'écoute géré par Oracle Restart,
pour l'arrêter et pour afficher son statut. Exemples :
• Pour afficher l'aide relative aux commandes disponibles dans SRVCTL, exécutez
srvctl –h
• Pour démarrer le processus d'écoute par défaut, exécutez srvctl start listener
• Pour arrêter le processus d'écoute par défaut, exécutez srvctl stop listener
• Pour démarrer un processus d'écoute nommé mylistener, exécutez srvctl start
listener –l mylistener
• Pour afficher le statut du processus d'écoute par défaut, exécutez srvctl status
listener

Page d'accueil du processus d'écoute

Page d'accueil du processus d'écoute

Pour accéder à la page d'accueil du processus d'écoute à partir d'Enterprise Manager, cliquez
sur le lien Listener dans la page d'accueil de la base de données.
Cette page fournit les informations suivantes :
• Statut et disponibilité du processus d'écoute au cours des dernières 24 heures
• Version et répertoire d'origine du processus d'écoute
• Première adresse surveillée par le processus d'écoute
• Emplacement des fichiers de configuration utilisés pour démarrer le processus d'écoute
• Heure de démarrage du processus d'écoute et informations relatives à l'hôte
• Statut d'Oracle Restart
Pour démarrer le processus d'écoute, accédez à la page d'accueil de l'instance de base de
données et cliquez sur le nom du processus d'écoute afin d'ouvrir la page d'accueil
correspondante. Cliquez sur Stop pour arrêter le processus d'écoute s'il est en cours
d'exécution, ou sur Start pour le démarrer. Connectez-vous à l'hôte sous le nom de l'utilisateur
du système d'exploitation qui peut démarrer et arrêter le processus d'écoute.

Page Net Services Administration

Page Net Services Administration

La page Net Services Administration permet de configurer Oracle Net Services pour
n'importe quel répertoire d'origine Oracle Home sur plusieurs systèmes de fichiers. Elle
fournit également des fonctions d'administration courantes pour les processus d'écoute. Vous
pouvez l'utiliser pour configurer et administrer les éléments suivants :
• Processus d'écoute : Vous pouvez ajouter, supprimer, démarrer et arrêter un processus
d'écoute, ou encore modifier les options de trace et de journalisation associées. Vous
pouvez également consulter l'état généré par le contrôle d'un processus d'écoute.
• Résolution de noms d'annuaire : Définissez des noms et des identificateurs de
connexion simples, puis mettez-les en correspondance avec des descripteurs de
connexion afin d'indiquer l'emplacement et l'identification d'un service au sein du réseau.
Enregistrez les services de base de données, les services réseau et les alias de service
réseau dans un service d'annuaire centralisé.
• Résolution locale de noms : Enregistrez les noms de service réseau dans le fichier
tnsnames.ora.
• Profils : Configurez les paramètres du fichier sqlnet.ora.
• Emplacement de fichier : Modifiez l'emplacement des fichiers de configuration des
services réseau.

Créer un processus d'écoute
1 2

4
Créer un processus d'écoute

Pour créer un processus d'écoute Oracle Net, sélectionnez Net Services Administration dans la
région Related Links de la page de propriétés du processus d'écoute. Procédez ensuite de la
façon suivante :
1. Sélectionnez Listeners dans la liste déroulante Administer et cliquez sur Go.
2. Si vous n'avez pas enregistré d'informations d'identification et de connexion dans les
préférences de l'hôte, la page Host Login apparaît. Entrez le nom utilisateur et le mot de
passe, puis cliquez sur Login.
3. Cliquez sur Create.
4. Indiquez le nom du processus d'écoute. Ce nom doit être unique sur le serveur. Cliquez
sur Add pour ajouter une adresse de processus d'écoute. Chaque processus d'écoute doit
avoir au moins une adresse.

Ajouter des adresses de processus d'écoute
8
5
6 9
7

10
Ajouter des adresses de processus d'écoute

La procédure de création d'un processus d'écoute se poursuit avec la définition d'une adresse :
5. Sélectionnez le protocole réseau. Le protocole TCP/IP est sélectionné par défaut. Il
s'agit du protocole le plus couramment utilisé. Les autres options sont IPC (Internal
Process Communication), généralement utilisé pour la connexion à des applications
locales (résidant sur le serveur de base de données), des bibliothèques de code externes
(EXTPROC) et TCP/IP avec SSL.
Remarque : Le protocole EXTPROC est configuré via l'onglet Other Services.
6. Indiquez le port que doit surveiller le processus d'écoute. Le numéro de port par défaut
d'Oracle Net est 1521. Si vous optez pour un autre port, des opérations de configuration
supplémentaires sont nécessaires pour le processus d'écoute ou pour l'instance.
7. Entrez le nom ou l'adresse IP du serveur sur lequel le processus d'écoute va s'exécuter.
8. Toutes les autres étapes de configuration sont facultatives pour le processus d'écoute.
Cliquez sur OK pour enregistrer l'adresse. Les seuls paramètres devant obligatoirement
être configurés sont l'adresse d'écoute et le nom du processus.
9. Dans la page Create Listener, vérifiez l'adresse que vous avez créée et cliquez sur OK
pour enregistrer vos modifications.
10. Pour démarrer le nouveau processus d'écoute, sélectionnez Start/Stop dans la liste
déroulante Actions et cliquez sur Go.

Enregistrement d'un service de base de données

Enregistrement d'un service de base de données

Pour qu'un processus d'écoute transmette des connexions client à une instance, il doit
connaître le nom de l'instance et savoir où se trouve le répertoire d'origine ORACLE_HOME
correspondant. Il peut trouver ces informations de deux façons :
• Enregistrement dynamique de services : Les instances Oracle8i et ultérieures
s'enregistrent automatiquement auprès du processus d'écoute par défaut lors du
démarrage de la base de données. Aucune configuration supplémentaire n'est requise
pour le processus d'écoute par défaut.
• Enregistrement statique de services : Les versions antérieures de la base Oracle ne
s'enregistrent pas automatiquement auprès du processus d'écoute. Il faut donc que la liste
de tous les services de base de données gérés par le processus d'écoute figure dans le
fichier de configuration de celui-ci. Par ailleurs, vous pouvez être amené à utiliser
l'enregistrement statique de services avec les versions récentes de la base dans les cas
suivants :
- Le processus d'écoute n'utilise pas le port par défaut 1521 et vous ne souhaitez pas
configurer l'instance pour l'enregistrement avec un port autre que celui par défaut.
- L'application nécessite un enregistrement statique de service.
Pour ajouter un service de base de données statique, cliquez sur Static Database Registration
dans la page Edit Listener et cliquez sur le bouton Add. Entrez le nom du service (identique
au nom global de base de données <DB_NAME>.<DB_DOMAIN>), le chemin du répertoire
d'origine ORACLE_HOME et le SID (identique au nom de l'instance). Cliquez sur OK. Pour
que les modifications prennent effet, vous devez recharger le processus d'écoute (à l'aide de la
commande RELOAD) ou le redémarrer.

Enregistrement d'un service de base de données (suite)
Noms des services
Le paramètre d'initialisation SERVICE_NAMES définit un ou plusieurs noms permettant aux clients
de se connecter à l'instance. Celle-ci enregistre ses noms de service auprès du processus d'écoute.
Quand un client demande un service, le processus d'écoute détermine les instances capables de
répondre à la demande et oriente le client en conséquence.
Vous pouvez indiquer plusieurs noms de service pour faire la distinction entre différentes utilisations
de la même base de données. Par exemple :
SERVICE_NAMES = sales.example.com, eurosales.example.com
Vous pouvez également utiliser plusieurs noms de service pour identifier un seul service accessible à
partir de deux bases de données différentes par voie de réplication.
Si vous ne qualifiez pas les noms de service par un nom de domaine dans le paramètre
SERVICE_NAMES, Oracle utilise le nom de domaine indiqué par le paramètre DB_DOMAIN. Si
DB_DOMAIN n'est pas défini, aucun nom de domaine ne vient qualifier les valeurs

SERVICE_NAMES.
Lorsque le processus d'écoute traite une demande de connexion client, il essaie de mettre en
correspondance la valeur de ce paramètre avec celle du paramètre SERVICE_NAME défini dans le
descripteur de connexion client.
Si le descripteur de connexion client utilise le paramètre SID, le processus d'écoute ne tente aucune
mise en correspondance. La valeur de ce paramètre est généralement une combinaison des
paramètres DB_NAME et DB_DOMAIN figurant dans le fichier de paramètres d'initialisation
(DB_NAME.DB_DOMAIN). Elle peut néanmoins contenir tout nom valide utilisé par les clients pour
identifier le service.

Méthodes de résolution de noms
Oracle Net prend en charge plusieurs méthodes de résolution
des informations de connexion :
• La résolution de noms Easy Connect utilise une chaîne
de connexion TCP/IP.
• La résolution locale de noms utilise un fichier de
configuration local.
• La résolution de noms d'annuaire utilise un serveur de
services annuaire LDAP centralisé.
• La résolution de noms externe utilise un service de noms
non Oracle pris en charge.

Client/serveur d'applications
Oracle Net
Fichiers de configuration
Oracle Net
Méthodes de résolution de noms

Oracle Net prend en charge les méthodes de résolution de noms suivantes :
• Résolution de noms Easy Connect : Cette méthode permet aux clients de se connecter à
un serveur de base de données Oracle à l'aide d'une chaîne de connexion TCP/IP
composée d'un nom d'hôte, et éventuellement d'un port et d'un nom de service, comme
suit :
CONNECT username/password@host[:port][/service_name]
Cette méthode ne requiert aucune configuration.
• Résolution locale de noms : Cette méthode stocke les descripteurs de connexion,
identifiés par leur nom de service réseau, dans un fichier de configuration local nommé
tnsnames.ora sur le client.
• Résolution de noms d'annuaire : Cette méthode stocke les identificateurs de connexion
sur un serveur de services annuaire LDAP (Lightweight Directory Access Protocol)
centralisé pour l'accès à un service de base de données.
• Résolution de noms externe : Cette méthode stocke les noms de service réseau dans un
service de noms non Oracle pris en charge. Les services tiers pris en charge sont les
suivants :
- Résolution de noms externe dans l'environnement NIS (Network Information
Service)
- CDS (Cell Directory Services) dans l'environnement DCE (Distributed Computing
Environment)

Easy Connect
• Est activé par défaut
• Ne nécessite aucune configuration côté client
• Ne reconnaît que le protocole TCP/IP (pas SSL)
• Ne prend pas en charge les options de connexion
avancées :
– Gestion des incidents de connexion
– Routage source
– Equilibrage de la charge
SQL> CONNECT hr/hr@db.us.oracle.com:1521/dba11g

Pas de fichiers de configuration
Oracle Net
Easy Connect
Avec Easy Connect, vous fournissez toutes les informations requises pour la connexion
Oracle Net dans la chaîne de connexion. Les chaînes de connexion Easy Connect présentent
la forme suivante :
<username>/<password>@<hostname>:<listener port>/<service name>
Le numéro de port du processus d'écoute (listener port) et le nom du service (service name)
sont facultatifs. Si le port du processus d'écoute n'est pas précisé, Oracle Net utilise le port par
défaut (1521). Si le nom du service est omis, Oracle Net suppose qu'il est identique au nom
d'hôte (hostname) fourni dans la chaîne de connexion.
En supposant que le processus d'écoute utilise le protocole TCP pour écouter sur le port 1521
et que les paramètres d'instance SERVICE_NAMES=db et DB_DOMAIN=us.oracle.com
sont définis, la chaîne de connexion illustrée dans la diapositive ci-dessus peut être abrégée de
la façon suivante :
SQL> connect hr/hr@db.us.oracle.com
Remarque : Le paramètre d'initialisation SERVICE_NAMES accepte plusieurs valeurs
séparées par des virgules. Il suffit qu'une seule de ces valeurs soit égale à db pour que ce
scénario fonctionne.

Résolution locale de noms
• Nécessite un fichier de résolution de noms côté client

• Prend en charge tous les protocoles Oracle Net
• Prend en charge les options de connexion avancées :
– Gestion des incidents de connexion
– Routage source
– Equilibrage de la charge
SQL> CONNECT hr/hr@orcl

Fichiers de
configuration
Oracle Net
Résolution locale de noms

Avec la résolution locale de noms, l'utilisateur fournit un alias pour le service Oracle Net.
Oracle Net vérifie l'alias par rapport à une liste locale de services connus et, s'il trouve une
correspondance, il convertit l'alias en un nom indiquant l'hôte, le protocole, le port et le
service.
L'un des avantages de la résolution locale de noms est qu'il suffit pour les utilisateurs de base
de données de mémoriser un alias court, plutôt que la chaîne de connexion longue requise par
Easy Connect.
La liste locale des services connus est stockée dans le fichier texte de configuration suivant :
<oracle_home>/network/admin/tnsnames.ora
Il s'agit de l'emplacement par défaut du fichier tnsnames.ora, mais il est possible
d'indiquer un autre emplacement à l'aide de la variable d'environnement TNS_ADMIN.
L'option de résolution locale de noms est appropriée pour les organisations dans lesquelles la
configuration des services Oracle Net ne change pas souvent.

Résolution de noms d'annuaire
• Nécessite un annuaire LDAP incluant les informations de

résolution de noms Oracle Net :
– Oracle Internet Directory
– Microsoft Active Directory Services
• Prend en charge tous les protocoles Oracle Net
• Prend en charge les options de connexion avancées

Annuaire LDAP
SQL> CONNECT hr/hr@orcl
Fichiers de
configuration
Oracle Net
Résolution de noms d'annuaire

Avec la résolution de noms d'annuaire, l'utilisateur fournit un alias pour le service Oracle Net.
Oracle Net vérifie l'alias par rapport à une liste externe de services connus et, s'il trouve une
correspondance, il convertit l'alias en un nom indiquant l'hôte, le protocole, le port et le nom
de service. Comme dans le cas de la résolution locale de noms, il suffit pour les utilisateurs de
base de données de mémoriser un alias court.
L'un des avantages de cette méthode est que les utilisateurs peuvent se connecter à un
nouveau service dès que son nom est ajouté à l'annuaire LDAP. Avec la résolution locale de
noms, l'administrateur de base de données (DBA) doit d'abord distribuer les fichiers
tnsnames.ora mis à jour contenant les noms des services modifiés pour que les
utilisateurs puissent se connecter à ces services.
La résolution de noms d'annuaire est appropriée pour les organisations dans lesquelles la
configuration des services Oracle Net change souvent.

Méthode de résolution de noms externe
• Utilise un service de noms non Oracle pris en charge

• Inclut les services suivants :
– Résolution de noms externe dans l'environnement NIS
(Network Information Service)
– CDS (Cell Directory Services) dans l'environnement DCE
(Distributed Computing Environment)
Service de noms
non Oracle

Oracle Net
Méthode de résolution de noms externe

La méthode de résolution de noms externe stocke les noms de service réseau dans un service
de noms non Oracle pris en charge. Les services tiers pris en charge sont les suivants :
• Résolution de noms externe dans l'environnement NIS (Network Information Service)
• CDS (Cell Directory Services) dans l'environnement DCE (Distributed Computing
Environment)
D'un point de vue conceptuel, la résolution de noms externe est similaire à la résolution de
noms d'annuaire.

Configurer des alias de service

Configurer des alias de service

Pour créer un alias de service Oracle Net local, sélectionnez Local Naming dans la liste
déroulante Administer de la page Net Services Administration et cliquez sur Go, puis cliquez
sur Create.
Vous pouvez configurer des alias de service pour la résolution de noms d'annuaire en
sélectionnant Directory Naming plutôt que Local Naming.
Remarque : Si la résolution de noms d'annuaire n'a pas encore été configurée, vous ne
pouvez pas sélectionner l'option Directory Naming. La résolution de noms d'annuaire est
étudiée dans le cours Oracle Enterprise Identity Management ainsi que dans le manuel Oracle
Advanced Security Administration.
Dans la page Create Net Service Name, entrez un nom unique dans le champ Net Service
Name. (Il s'agit du nom que les utilisateurs saisissent lorsqu'ils veulent utiliser cet alias.)
Entrez le nom du service de base de données auquel vous souhaitez vous connecter, ou le SID
de la base, puis cliquez sur le bouton Add afin d'entrer l'adresse associée.
Comme adresse, entrez le protocole, le port et l'hôte utilisés par le processus d'écoute pour le
service auquel vous souhaitez vous connecter.

Options de connexion avancées
Oracle Net prend en charge les options de connexion avancées
suivantes avec la résolution locale de noms et la résolution de
noms d'annuaire :
• Gestion des incidents • Routage source
de connexion
• Equilibrage de la charge

Options de connexion avancées

Quand un service de base de données est accessible via plusieurs adresses de protocole
d'écoute, vous pouvez indiquer l'ordre d'utilisation de ces adresses. Elles peuvent être
sélectionnées aléatoirement ou séquentiellement. Quand plusieurs processus d'écoute sont
disponibles, par exemple dans les configurations RAC (Real Application Clusters), Oracle
Net peut tirer parti des fonctionnalités de gestion des incidents de connexion et d'équilibrage
de la charge, ainsi que du routage source Oracle Connection Manager.
Lorsque la gestion des incidents de connexion (connect-time failover) est activée, plusieurs
adresses de processus d'écoute sont répertoriées pour l'alias. Si la première adresse n'est pas
disponible, la deuxième est testée. Oracle Net continue d'essayer les adresses dans l'ordre
indiqué jusqu'à ce qu'il parvienne à un processus d'écoute qui fonctionne ou jusqu'à ce que
toutes les adresses aient été testées et aient échoué. La gestion transparente des incidents de
connexion (TAF - Transparent Application Failover) est une fonctionnalité client qui permet
la reconnexion aux bases de données disponibles en cas de panne d'une instance. Le serveur
utilise des notifications pour déclencher les rappels TAF côté client.
Lorsque l'équilibrage de la charge (load balancing) est activé, Oracle Net sélectionne une
adresse aléatoire dans la liste des adresses. La fonctionnalité d'équilibrage de la charge au
moment de l'exécution optimise les performances de connexion en distribuant équitablement
les connexions actives entre plusieurs répartiteurs. Dans un environnement RAC, l'équilibrage
de la charge dans un pool de connexions permet également de répartir les connexions actives
entre plusieurs instances.

Options de connexion avancées (suite)
Le routage source (source routing) est utilisé avec Oracle Connection Manager, qui sert de serveur
proxy pour le trafic Oracle Net et sécurise ce dernier via un pare-feu. Oracle Net traite les adresses
comme une liste de relais, en se connectant à la première adresse, puis en demandant le passage de la
première à la deuxième jusqu'à ce que la destination soit atteinte. Ce comportement diffère de la
gestion des incidents ou de l'équilibrage de la charge, en ce sens que toutes les adresses sont utilisées
chaque fois qu'une connexion est établie.
Option Fonctionnalité avancée
Essayer chaque adresse dans l'ordre, jusqu'à ce Gestion des incidents

que l'une d'elles fonctionne.
Essayer chaque adresse dans un ordre aléatoire, Gestion des incidents

jusqu'à ce que l'une d'elles fonctionne. Equilibrage de la charge
Essayer une adresse, sélectionnée de façon Equilibrage de la charge
aléatoire.
Utiliser chaque adresse dans l'ordre, jusqu'à ce Routage source
que la destination soit atteinte.
Utiliser uniquement la première adresse. Aucune

Tester la connectivité Oracle Net
L'utilitaire tnsping qui teste les alias de service Oracle Net :

• assure la connectivité entre le client et le processus
d'écoute Oracle Net
• ne vérifie pas que le service demandé est disponible
• prend en charge la résolution de noms Easy Connect :
tnsping host01.example.com:1521/orcl
• prend en charge la résolution locale de noms et la

résolution de noms d'annuaire :

tnsping orcl
Tester la connectivité Oracle Net

L'utilitaire tnsping est l'équivalent Oracle Net de l'utilitaire ping du protocole TCP/IP. Il
permet de vérifier rapidement le chemin réseau vers une destination spécifique. Par exemple,
entrez tnsping orcl dans une fenêtre de ligne de commande.
L'utilitaire vérifie que le nom d'hôte, le port et le protocole atteignent un processus d'écoute.
En revanche, il ne vérifie pas si le processus d'écoute traite le nom de service. tnsping
révèle également l'emplacement des fichiers de configuration. Cela peut s'avérer utile dans un
système avec plusieurs emplacements ORACLE_HOME.

Sessions utilisateur : Processus serveur dédiés
Sessions
utilisateur
Processus
serveur
Processus
serveur

Processus
serveur
Processus d'écoute
Sessions utilisateur : Processus serveur dédiés

Avec les processus serveur dédiés, il existe un rapport de un à un entre processus serveur et
processus utilisateur. Chaque processus serveur utilise des ressources système, notamment des
cycles CPU et de la mémoire.
Dans un système très sollicité, les ressources mémoire et CPU utilisées par les processus
serveur dédiés peuvent être excessives et affecter de manière négative l'évolutivité du
système. Si l'architecture "serveur dédié" sollicite trop de ressources système, vous avez le
choix entre deux solutions :
• Augmenter les ressources système en ajoutant de la capacité mémoire et CPU
• Utiliser l'architecture Oracle à processus serveur partagé

Sessions utilisateur : Processus serveur partagés
Processus serveur
Processus serveur
Processus serveur

Sessions Répartiteurs
utilisateur
Processus
d'écoute
Sessions utilisateur : Processus serveur partagés

Chaque service inclus dans une architecture avec processus serveur partagés comporte au
moins un processus répartiteur (et généralement plusieurs). Lorsqu'une demande de connexion
arrive, le processus d'écoute ne crée pas de processus serveur dédié. En revanche, il tient à
jour une liste indiquant les répartiteurs disponibles pour chaque nom de service, ainsi que la
charge de connexion correspondante (nombre de connexions simultanées).
Les demandes de connexion sont acheminées vers le répartiteur qui est le moins chargé pour
le service sollicité. Les utilisateurs restent connectés au même répartiteur pendant toute la
durée d'une session.
Contrairement aux processus serveur dédiés, un répartiteur peut gérer des centaines de
sessions utilisateur.
Les répartiteurs n'assurent pas eux-mêmes le traitement des demandes utilisateur. Ils
transmettent celles-ci à une file d'attente commune située dans la zone partagée de la mémoire
SGA.
Les processus serveur partagés effectuent en grande partie le même travail que les processus
serveur dédiés. Ils extraient les demandes de la file d'attente et les traitent en totalité.
Etant donné que les demandes d'une même session utilisateur peuvent être traitées par
plusieurs processus serveur partagés, la plupart des structures mémoire généralement stockées
dans la mémoire PGA doivent résider dans un emplacement de mémoire partagée (par défaut,
dans la zone de mémoire partagée). Toutefois, si la zone de mémoire LARGE POOL est
configurée ou si SGA_TARGET est défini pour la gestion automatique de la mémoire, ces
structures mémoire sont stockées dans la zone LARGE POOL de la mémoire SGA.

Mémoire SGA et mémoire PGA
Oracle Shared Server : Les données de la session utilisateur
sont conservées dans la mémoire SGA.
Mémoire SGA
Mémoire PGA
Zone Zone de
Etat du de tri hachage
curseur
Espace
Zone de création
de pile
d'index bitmap
Données de
session Zone de fusion
utilisateur d'index bitmap

Mémoire UGA
Lors du dimensionnement de la mémoire SGA, pensez à

prendre en compte la mémoire nécessaire pour les serveurs
partagés.
Mémoire SGA et mémoire PGA

La mémoire SGA et la mémoire PGA n'ont pas le même contenu dans un système avec
serveurs dédiés et dans un système avec serveurs partagés :
• Le code source SQL et son analyse sont conservés dans la mémoire SGA.
• Le curseur contient des valeurs d'exécution pour l'instruction SQL, par exemple les lignes
extraites.
• Les données relatives à la session utilisateur incluent des informations relatives à la
sécurité et à l'utilisation des ressources.
• L'espace de pile contient les variables locales du processus.
Remarque technique
La modification de la mémoire SGA et de la mémoire PGA est transparente pour l'utilisateur.
Cependant, si vous voulez prendre en charge un grand nombre d'utilisateurs, vous devez
augmenter la valeur du paramètre d'initialisation LARGE_POOL_SIZE. Chaque processus
serveur partagé doit accéder aux espaces de données de toutes les sessions, de sorte que
chaque serveur puisse traiter les demandes de n'importe quelle session. De l'espace est alloué
dans la mémoire SGA pour l'espace de données de chaque session. Vous limitez la quantité
d'espace pouvant être allouée par une session en définissant la limite de ressource
PRIVATE_SGA dans la région Database Services de la page General du profil de l'utilisateur.

Serveur partagé : Concentration des connexions
La durée d'inactivité de l'application

client dépasse le délai indiqué et un
client entrant demande une connexion.
Client
inactif
Client
actif
Serveur de Le nombre

Nouveau base de Maximal de
client données connexions
est 255.
Cette connexion client est la 256ème
connexion au serveur. La concentration
des connexions étant activée, cette
connexion peut être acceptée.
Serveur partagé : Concentration des connexions

La fonction de concentration des connexions permet au serveur de base de données
d'appliquer un mécanisme de temporisation à une session inactive et d'utiliser la connexion
pour une session active. La session logique inactive reste ouverte et la connexion physique est
automatiquement rétablie lorsque la demande suivante provient de cette session. Les
applications Web peuvent ainsi satisfaire un plus grand nombre d'utilisateurs simultanés avec
le matériel existant. La concentration des connexions est configurable via le serveur partagé.
Dans l'exemple de la diapositive, le serveur de base de données Oracle a été configuré avec
255 connexions. La durée d'inactivité de l'un des clients dépasse le délai indiqué. La
concentration des connexions met cette connexion à la disposition d'une connexion client
entrante, qui est la 256ème connexion. Lorsque le client inactif doit à nouveau effectuer des
tâches, la connexion inactive d'un autre client lui est affectée.

Dans quels cas ne pas utiliser de serveur partagé ?
Certains travaux de base de données ne doivent pas être

effectués à l'aide de serveurs partagés :
• Administration de base de données
• Opérations de sauvegarde et de récupération
• Traitement par lots et opérations de chargement en masse
• Opérations de data warehouse

Répartiteur Processus
serveur dédié
Dans quels cas ne pas utiliser de serveur partagé ?

L'architecture Oracle Shared Server est un modèle efficace d'utilisation des processus et de la
mémoire, mais il n'est pas adapté à toutes les connexions. En raison de la file d'attente
commune des demandes et du fait que de nombreux utilisateurs peuvent partager une file
d'attente de réponses de répartiteur, les serveurs partagés n'offrent pas de performances
satisfaisantes avec les opérations qui doivent traiter d'importants jeux de données, telles que
les interrogations de data warehouses ou le traitement par lots.
Les sessions de sauvegarde et de récupération qui utilisent Oracle Recovery Manager
(étudiées dans des chapitres ultérieurs) traitent également des jeux de données très
volumineux et doivent utiliser des connexions dédiées.
De nombreuses tâches d'administration ne doivent (et ne peuvent) pas être effectuées à l'aide
de connexions serveur partagées. Il s'agit notamment du démarrage et de l'arrêt de l'instance,
de la création de tablespaces ou de fichiers de données, de la maintenance d'index et de tables,
de l'analyse de statistiques, et de nombreuses autres tâches couramment effectuées par le
DBA. Toutes les sessions DBA doivent utiliser des serveurs dédiés.

Configurer la communication
entre bases de données
• L'envoi de données ou de messages entre sites nécessite
une configuration réseau sur les deux sites.
• Vous devez configurer les éléments suivants :
– Connectivité réseau (TNSNAMES.ora, par exemple)
– Liens de base de données
CREATE DATABASE LINK <remote_global_name>

CONNECT TO <user> IDENTIFIED BY <pwd>

USING '<connect_string_for_remote_db>';
Configurer la communication entre bases de données

Un lien de base de données est un objet du schéma d'une base qui permet d'accéder aux objets
d'une autre base. Cette autre base n'est pas forcément un système de base de données Oracle.
Pour accéder à des systèmes tiers, vous devez passer par les services hétérogènes
(Heterogeneous Services) Oracle.
La création d'un lien de base de données privé nécessite le privilège système CREATE
DATABASE LINK. La création d'un lien de base de données public nécessite le privilège
système CREATE PUBLIC DATABASE LINK. Le privilège système CREATE SESSION
sur la base de données Oracle distante est également requis.
Quand une application utilise un lien de base de données pour accéder à une base distante,
Oracle Database établit une session sur la base de données distante pour répondre à la
demande locale. La clause CONNECT TO utilisée pour créer le lien détermine la manière
d'établir la connexion à la base distante. Vous pouvez créer des liens de base de données avec
utilisateur fixe, utilisateur courant ou utilisateur connecté. Les liens de base de données avec
utilisateur courant ne sont disponibles qu'avec l'option Oracle Advanced Security. L'exemple
de la diapositive illustre la syntaxe qui permet de créer un lien de base de données avec
utilisateur fixe.
Une fois que vous avez créé ce lien, vous pouvez l'utiliser pour faire référence aux tables et
aux vues de l'autre base de données. Dans les instructions SQL, vous avez la possibilité de
pointer vers une table ou une vue de l'autre base de données en ajoutant @dblink au nom de
la table ou de la vue. Vous pouvez interroger les tables et les vues de la base distante ou leur
appliquer des instructions INSERT, UPDATE, DELETE ou LOCK TABLE.

Se connecter à une autre base de données
REMOTE_ORCL = tnsnames.ora
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)
(HOST = host02.example.com)
(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl.example.com)
)
)
CONNECT hr/hr@orcl; SQL*Plus

CREATE DATABASE LINK remote
CONNECT TO HR IDENTIFIED BY HR
USING 'REMOTE_ORCL';
SELECT * FROM employees@remote
Se connecter à une autre base de données

La diapositive ci-dessus présente l'entrée qui doit être incluse dans tnsnames.ora avant la
création d'un lien de base de données.
Cet exemple utilise un lien de base de données avec utilisateur fixe (nommé REMOTE) qui se
connecte à l'utilisateur HR à l'aide de la chaîne de connexion REMOTE_ORCL. Une fois que
vous avez créé ce lien, vous pouvez l'utiliser pour faire référence aux tables et aux vues de
l'autre base de données.
Voici la description de la vue :
SQL> DESC DBA_DB_LINKS
Name Null? Type
-------------------- -------- ----------------------------
OWNER NOT NULL VARCHAR2(30)
DB_LINK NOT NULL VARCHAR2(128)
USERNAME VARCHAR2(30)
HOST VARCHAR2(2000)
CREATED NOT NULL DATE
SQL> select owner, db_link, username from dba_db_links;
OWNER DB_LINK USERNAME

----------- ------------------- ---------
HR REMOTE.EXAMPLE.COM HR

Quiz
Quels fichiers de configuration servent à configurer le

processus d'écoute ?
1. listener.ora
2. listener.conf
3. tnsnames.ora
4. tnsnames.conf
5. sqlnet.ora
6. sqlnet.conf

Réponses : 1, 5

Quiz
Lorsqu'une architecture à processus serveur partagés est

utilisée, la mémoire PGA est transférée dans la mémoire SGA.
1. Vrai
2. Faux

Réponse : 2

Synthèse

• utiliser Enterprise Manager pour :
– créer des processus d'écoute supplémentaires
– créer des alias de service Oracle Net
– configurer la gestion des incidents de connexion
– contrôler le processus d'écoute Oracle Net
• utiliser tnsping pour tester la connectivité Oracle Net
• déterminer quand utiliser des serveurs partagés et quand

utiliser des serveurs dédiés

Utiliser les composants réseau Oracle
• configurer la résolution locale de noms pour la connexion à
une autre base de données
• créer un deuxième processus d'écoute pour la gestion des
incidents de connexion


Gérer les structures de stockage
de base de données

Objectifs

• décrire le stockage des données des lignes de table sous la
forme de blocs
• créer et gérer des tablespaces
• obtenir des informations sur les tablespaces


Mode de stockage des données d'une table
Colonnes Blocs
Table A Table B
Lignes
Segment Segment
Table
Tablespace

Morceau de ligne Extent
Mode de stockage des données d'une table

Lorsqu'une table est créée, un segment est généré pour le stockage de ses données. Un
tablespace contient un ensemble de segments.
D'un point de vue logique, une table contient des lignes contenant les valeurs de colonnes.
Enfin, une ligne est stockée dans un bloc de base de données sous la forme d'un morceau de
ligne. On parle de morceau de ligne car, dans certaines conditions, une ligne n'est pas stockée
intégralement dans le même emplacement. C'est le cas lorsqu'une ligne insérée est trop
volumineuse pour tenir dans un bloc unique (ligne chaînée) ou lorsque, suite à une mise à
jour, la taille d'une ligne existante dépasse l'espace disponible dans le bloc en cours (ligne
migrée). Des morceaux de ligne sont également utilisés quand une table comprend plus de
255 colonnes. Le cas échéant, les morceaux peuvent se trouver dans le même bloc (chaînage
intra-bloc) ou répartis dans plusieurs blocs.

Bloc de base de données : Contenu
En-tête de bloc
Croissance
Espace libre

Données des lignes
Bloc de base de données : Contenu

• En-tête de bloc : L'en-tête d'un bloc contient le type de segment (table ou index, par
exemple), l'adresse du bloc, le répertoire des tables, le répertoire des lignes, et des
espaces de transaction d'environ 23 octets chacun, utilisés lors de la modification des
lignes du bloc. Il croît du haut vers le bas.
• Données des lignes : Cet espace assure le stockage des données réelles des lignes
contenues dans le bloc. Il augmente du bas vers le haut.
• Espace disponible : Il se situe au milieu du bloc et permet l'extension des espaces d'en-
tête et de données si nécessaire. Les données des lignes occupent l'espace libre à mesure
que de nouvelles lignes sont insérées ou que des colonnes sont mises à jour avec des
valeurs plus importantes dans les lignes existantes.
Exemples d'événements entraînant l'extension de l'en-tête :
- Répertoires de lignes nécessitant davantage d'entrées de ligne
- Besoin d'un nombre d'espaces de transaction supérieur à celui configuré initialement
A l'origine, l'espace libre d'un bloc est d'un seul tenant. Ensuite, cet espace peut être
fragmenté en raison des suppressions et mises à jour effectuées. L'espace libre du bloc est
fusionné par le serveur Oracle lorsque cela s'avère nécessaire.

Explorer la structure de stockage

Cliquez sur les liens
pour afficher des
informations détaillées.
Explorer la structure de stockage

Les structures de données logiques sont stockées dans les fichiers physiques de la base. Vous
pouvez visualiser celles-ci dans Enterprise Manager. Cliquez sur les liens apparaissant dans la
région Storage de la page Server pour obtenir des informations détaillées sur chaque structure.

Créer un tablespace

1. Cliquez sur l'onglet Server, puis sur le lien Tablespaces sous l'en-tête Storage.
2. Cliquez sur Create.
Remarque : Si vous souhaitez créer un tablespace semblable à un tablespace existant,
sélectionnez le tablespace existant de votre choix, puis cliquez sur Create Like dans le
menu Actions. Cliquez sur Go.
La page Create Tablespace apparaît.
3. Entrez le nom du tablespace.
4. Sous l'en-tête Extent Management, sélectionnez Locally Managed.
Les extents (ensembles de blocs contigus) d'un tablespace administré localement sont
gérés de manière efficace par le serveur de base de données Oracle. Dans le cas d'un
tablespace géré au moyen du dictionnaire, vous êtes plus sollicité pour la gestion des
extents, et vous devez disposer d'un accès au dictionnaire de données pour le suivi.
L'option de tablespace géré au moyen du dictionnaire est fournie pour des raisons de
compatibilité avec les versions antérieures, mais Oracle déconseille son utilisation.
5. Sous l'en-tête Type, sélectionnez Permanent.
Les tablespaces permanents contiennent les objets de base de données permanents créés
par le système ou par les utilisateurs.
6. Sous l'en-tête Status, sélectionnez Read Write.
Ce statut indique que les utilisateurs disposent d'un droit d'accès en lecture et en écriture
sur le tablespace, une fois ce dernier créé. Il s'agit de l'option par défaut.
7. Dans la région Datafiles de la page, cliquez sur Add pour ajouter des fichiers de données
au tablespace.

Sélectionnez le type de
stockage approprié.

Créer un tablespace (suite)

Chaque tablespace doit comporter au moins un fichier. Choisissez le type de stockage approprié,
en fonction de votre environnement. Les tablespaces bigfile sont utilisés avec les bases de
données très volumineuses dans lesquelles la fonctionnalité ASM (Automatic Storage
Management) ou d'autres gestionnaires de volumes logiques assurent la prise en charge du
striping ou de la technologie RAID, ainsi que celle des volumes logiques extensibles de manière
dynamique.
8. Dans la page Add Datafiles, sélectionnez le type de stockage désiré et entrez les
informations requises. Pour le type de stockage ASM, choisissez un groupe de disques.
Pour le type de stockage File System, indiquez le nom du fichier de données et son
emplacement (répertoire).
9. Entrez la taille de fichier de votre choix.
10. Dans la région Storage, sélectionnez l'option "Automatically extend datafile when full
(AUTOEXTEND)" et indiquez une valeur dans le champ Increment. Cela permet au fichier
de données de croître automatiquement chaque fois qu'il manque d'espace. La taille du
fichier est toutefois limitée par le support physique sur lequel réside le fichier. Conservez
la valeur Unlimited du champ Maximum File Size ou entrez une taille maximale. Cliquez
sur Continue pour retourner à la page Create Tablespace.
12. A partir de la page Create Tablespace, vous pouvez cliquer sur l'onglet Storage pour
modifier les options de stockage du tablespace si vous le souhaitez. Dans la plupart des cas,
vous pouvez accepter toutes les valeurs par défaut de la page Storage. Cliquez sur OK pour
créer le tablespace.
Remarque : La procédure qui précède permet de créer rapidement un tablespace dans la plupart
des situations. Vous pouvez être amené à modifier certaines options pour des besoins
particuliers.
Stockage des tablespaces

Stockage des tablespaces

Extent Allocation : Les extents d'un tablespace géré localement peuvent être alloués de deux
façons :
• Automatic : Dans ce mode (également appelé AUTOALLOCATE), la taille des extents du
tablespace est gérée par le système. Vous ne pouvez pas utiliser ce mode pour un
tablespace temporaire.
• Uniform : Dans ce mode, le tablespace est géré à l'aide d'extents uniformes, dont vous
définissez la taille. La taille par défaut est de 1 Mo. Tous les extents des tablespaces
temporaires sont uniformes. Vous ne pouvez pas définir ce mode pour un tablespace
d'annulation.
Segment Space Management : Dans un tablespace géré localement, la gestion de l'espace
des segments peut être effectuée selon deux modes :
• Automatic : La base de données Oracle utilise des bitmaps pour gérer l'espace libre dans
les segments. Le bitmap décrit le statut de chaque bloc de données d'un segment, en
fonction de la quantité d'espace disponible dans le bloc pour l'insertion de lignes. Le
statut indiqué dans le bitmap est actualisé à mesure que l'espace disponible dans un bloc
de données augmente ou diminue. Grâce aux bitmaps, la base de données Oracle gère
l'espace libre de manière plus automatisée. Cette forme de gestion de l'espace est appelée
gestion automatique de l'espace dans les segments (ASSM – Automatic Segment Space
Management).

Stockage des tablespaces (suite)
• Manual : Sélectionnez ce mode lorsque vous souhaitez utiliser des listes de blocs libres pour la
gestion de l'espace libre dans les segments. Ces listes répertorient les blocs de données qui
contiennent de l'espace disponible pour l'insertion de lignes. On parle de gestion manuelle de
l'espace dans les segments, en raison de la nécessité de définir et de régler les paramètres de
stockage PCTUSED, FREELISTS et FREELIST GROUPS pour les objets de schéma créés dans
le tablespace. Ce mode de gestion reste pris en charge à des fins de compatibilité descendante,
mais il est recommandé d'utiliser la gestion automatique de l'espace dans les segments (ASSM).
Compression Options : Par défaut, la compression des segments de données est désactivée. Cette
fonctionnalité peut réduire l'utilisation de l'espace disque, l'utilisation de la mémoire dans le cache de
tampons (buffer cache) et le temps d'exécution des interrogations lors des opérations de lecture. Elle
a toutefois un coût en ressources CPU lors du chargement des données et du traitement des
instructions LMD (Langage de manipulation de données). La compression est particulièrement utile
dans les systèmes OLAP (traitement analytique en ligne) qui traitent des opérations de lecture seule

volumineuses, mais elle peut également être utilisée dans les systèmes OLTP (traitement des
transactions en ligne).
Pour plus d'informations sur les conditions d'utilisation de la compression, reportez-vous au manuel
Oracle Database Administrator's Guide.
Enable Logging : La clause de journalisation s'applique à tout segment créé dans le tablespace. Les
modifications apportées aux objets contenus dans le tablespace sont consignées dans le fichier de
journalisation (redo log). Lorsque la journalisation n'est pas activée, les chargements par chemin
direct via SQL*Loader ou l'instruction INSERT ne sont pas consignés dans le fichier de
journalisation. Les objets ne peuvent donc pas être récupérés en cas de perte de données. Ainsi,
lorsque vous créez un objet sans activer la journalisation, vous devez le sauvegarder pour pouvoir le
récupérer. La décision de ne pas activer la journalisation doit être prise avec précaution car elle peut
avoir des conséquences considérables sur les possibilités ultérieures de récupérer les objets. Pour plus
d'informations sur la clause de journalisation, reportez-vous au manuel Oracle Database SQL
Reference.
Remarque : Si le mode FORCE LOGGING est en vigueur pour l'ensemble de la base de données, il
est prioritaire sur le paramètre de journalisation des tablespaces. Vous pouvez définir le mode
FORCE LOGGING au moment de la création de la base de données, ou ultérieurement à l'aide de la
commande alter database force logging.
Block Information : Cette région indique la taille de bloc utilisée pour le tablespace en cours de
création. Il s'agit d'une valeur en lecture seule. Toutefois, si vous avez défini d'autres paramètres
d'initialisation de la taille de bloc (DB_nK_CACHE_SIZE), les valeurs correspondantes sont
proposées en option.
Pour plus d'informations sur la définition d'autres tailles de bloc, reportez-vous au manuel Oracle
Database Administrator's Guide.

Tablespaces de la base de données
préconfigurée
• SYSTEM • UNDOTBS1
• SYSAUX • USERS
• TEMP • EXAMPLE (facultatif)

Tablespaces de la base de données préconfigurée

La base de données préconfigurée utilisée dans ce cours comprend les tablespaces suivants :
• SYSTEM : Le tablespace SYSTEM est utilisé par le serveur Oracle pour gérer la base.
Il contient le dictionnaire de données et les tables comprenant les informations
d'administration sur la base. Tous ces éléments sont contenus dans le schéma SYS. Ils ne
sont accessibles que par l'utilisateur SYS ou par les autres administrateurs dotés du
privilège approprié.
• SYSAUX : Il s'agit d'un tablespace auxiliaire du tablespace SYSTEM. Certains
composants et produits qui utilisaient le tablespace SYSTEM ou leurs propres tablespaces
dans les versions antérieures d'Oracle Database utilisent désormais le tablespace
SYSAUX. Depuis la version 10g, toute base de données Oracle Database doit comprendre
un tablespace SYSAUX.
Dans Enterprise Manager, vous pouvez afficher le contenu de ce tablespace sous la forme
d'un graphique à secteurs. Pour ce faire, cliquez sur Tablespaces dans la page
Administration. Sélectionnez SYSAUX, puis cliquez sur Edit. Cliquez ensuite sur l'onglet
Occupants. Une fois le tablespace SYSAUX créé, vous pouvez surveiller l'espace utilisé
par ses occupants à l'aide d'Enterprise Manager. Si vous constatez qu'un composant prend
trop d'espace dans le tablespace SYSAUX, ou si vous prévoyez que cela risque de se
produire, vous pouvez déplacer ce composant vers un autre tablespace. Pour ce faire,
sélectionnez-le, puis cliquez sur Change Tablespace.

Tablespaces de la base de données préconfigurée (suite)
• TEMP : Le tablespace temporaire est utilisé lorsque vous exécutez une instruction SQL qui
requiert la création de segments temporaires (par exemple, une opération de tri volumineuse ou
la création d'un index). Un tablespace par défaut est affecté à chaque utilisateur pour le stockage
des objets de données créés. De même, chaque utilisateur se voit attribuer un tablespace
temporaire. Il est recommandé de définir un tablespace temporaire par défaut pour la base de
données. Sauf indication contraire, ce tablespace est affecté à chaque utilisateur nouvellement
créé. Dans la base de données préconfigurée, le tablespace TEMP est désigné comme tablespace
temporaire par défaut. Il est affecté aux comptes utilisateur pour lesquels aucun tablespace
temporaire n'est indiqué lors de la phase de création.
• UNDOTBS1 : Il s'agit du tablespace d'annulation utilisé par le serveur de base de données pour le
stockage des informations d'annulation. Si une base utilise la gestion automatique des
annulations (AUM), elle ne peut utiliser qu'un seul tablespace d'annulation à un moment donné.
Ce tablespace est créé en même temps que la base.
• USERS : Ce tablespace est utilisé pour le stockage des données et des objets utilisateur. Si aucun

tablespace par défaut n'est indiqué lors de la création d'un utilisateur, USERS devient le
tablespace par défaut pour tous les objets créés par cet utilisateur. Pour les utilisateurs SYS et
SYSTEM, le tablespace permanent par défaut est SYSTEM.
• EXAMPLE : Ce tablespace contient les exemples de schéma pouvant être installés lors de la
création de la base de données. Ceux-ci fournissent une plate-forme commune pour les
exemples. La documentation et les cours Oracle contiennent des exemples basés sur ces
schémas.
Remarque : Pour simplifier l'administration, il est fréquent de réserver un tablespace aux index.

Modifier un tablespace

Modifier un tablespace
Une fois créé, un tablespace peut être modifié de différentes façons, en fonction de l'évolution
du système.
Modification du nom : Entrez un nouveau nom pour le tablespace et cliquez sur Apply.
Modification du statut : Un tablespace peut présenter trois statuts (ou états) différents. Les
statuts disponibles dépendent du type de tablespace :
• Read Write : Le tablespace est en ligne (online) et peut faire l'objet d'opérations de
lecture et d'écriture.
• Read Only : Cette option place le tablespace en mode lecture seule. Les transactions
existantes peuvent être terminées au moyen d'une validation (commit) ou d'une
annulation (rollback), mais aucune autre opération LMD (langage de manipulation de
données) n'est autorisée sur les objets du tablespace. Le tablespace est en ligne tout en
étant en mode lecture seule. Vous ne pouvez pas affecter ce mode aux tablespaces
SYSTEM et SYSAUX.
Remarque : Le tablespace d'annulation et le tablespace temporaire ne peuvent pas être
placés en mode lecture seule.

Modifier un tablespace (suite)
• Offline : Vous pouvez mettre hors ligne (offline) un tablespace qui est en ligne (online), afin que
cette partie de la base soit temporairement indisponible pour une utilisation générale. Le reste de la
base est ouvert et permet aux utilisateurs d'accéder aux données. Lorsque vous placez un
tablespace hors ligne, vous disposez des options suivantes :
- Normal : Un tablespace peut être mis hors ligne en mode normal s'il n'existe aucune
condition d'erreur pour aucun de ses fichiers de données. Oracle Database veille à ce que
toutes les données soient écrites sur le disque en définissant un point de reprise (checkpoint)
pour tous les fichiers de données du tablespace à mesure qu'ils sont mis hors ligne.
- Temporary : Un tablespace peut être mis hors ligne temporairement, même s'il existe des
conditions d'erreur pour un ou plusieurs de ses fichiers. Oracle Database met hors ligne les
fichiers de données (qui ne le sont pas déjà), en créant un point de reprise sur chacun d'eux. Si
vous sélectionnez le mode Temporary alors qu'aucun fichier n'est hors ligne, il est inutile de
recourir à une restauration physique pour remettre le tablespace en ligne. En revanche, si un
ou plusieurs fichiers du tablespace sont hors ligne suite à des erreurs d'écriture et que vous

placez temporairement le tablespace hors ligne, ce dernier nécessite une récupération avant
d'être remis en ligne.
- Immediate : Un tablespace peut être mis hors ligne immédiatement, sans qu'Oracle Database
ne crée de point de reprise sur ses fichiers de données. Lorsque vous indiquez le mode
Immediate, la restauration physique du tablespace est nécessaire pour sa remise en ligne.
Vous ne pouvez pas mettre un tablespace hors ligne en mode Immediate si la base de données
fonctionne en mode NOARCHIVELOG.
- For Recover : Le mode FOR RECOVER est en phase d'abandon. Il reste toutefois pris en
charge pour des raisons de compatibilité descendante.
Remarque : Il n'est pas possible de mettre les tablespaces système hors ligne.
Modification de la taille : Vous pouvez ajouter de l'espace à un tablespace existant en ajoutant des
fichiers de données ou en modifiant la taille d'un fichier de données existant.
• Pour ajouter un nouveau fichier de données au tablespace, cliquez sur Add, puis indiquez les
informations appropriées dans la page Add Datafile.
Remarque : Vous ne pouvez pas ajouter de fichiers de données aux tablespaces bigfile.
• Pour modifier la taille d'un fichier de données existant, cliquez sur le nom du fichier dans la région
Datafiles de la page Edit Tablespace, ou sélectionnez le fichier et cliquez sur Edit. Dans la page
Edit Datafile, vous pouvez alors modifier la taille du fichier de données. Il est possible
d'augmenter ou de réduire la taille du tablespace. En revanche, vous ne pouvez pas réduire la taille
d'un fichier de données en deçà de l'espace utilisé dans le fichier. Si vous tentez cette opération,
vous recevez l'erreur suivante :
ORA-03297: file contains used data beyond requested RESIZE value
Options de stockage : Cliquez sur Storage pour modifier les options de journalisation du tablespace.
Seuils : Cliquez sur Thresholds pour modifier les pourcentages d'utilisation du tablespace
correspondant au niveau d'avertissement et au niveau critique. Vous avez le choix entre trois options :
• Use Database Default Thresholds : Sélectionnez cette option pour utiliser les valeurs par défaut
prédéfinies, que vous pouvez modifier.
• Specify Thresholds : Cette option vous permet de définir des seuils spécifiques pour le tablespace.
• Disable Thresholds : Cette option désactive les alertes relatives à l'utilisation de l'espace du
tablespace.
Remarque : Par défaut, l'utilisation de l'espace est vérifiée toutes les 10 minutes. L'enregistrement
d'une alerte associée à un seuil peut donc prendre quelques minutes.

Actions sur les tablespaces

Actions sur les tablespaces

Le menu Actions vous permet d'effectuer différentes opérations sur les tablespaces.
Sélectionnez un tablespace, puis l'action que vous souhaitez réaliser :
• Add Datafile : Ajoute un fichier de données au tablespace, ce qui a pour effet
d'augmenter la taille de ce dernier.
• Create Like : Crée un tablespace en utilisant un autre tablespace comme modèle.
• Generate DDL : Génère l'instruction LDD (langage de définition de données) qui crée le
tablespace. Cette instruction peut ensuite être copiée dans un fichier texte afin d'être
utilisée en tant que script ou à des fins de documentation.
• Make Locally Managed : Si le tablespace est actuellement géré au moyen du
dictionnaire, il est converti en tablespace géré localement. Cette conversion est
irréversible. Vous ne pouvez pas revenir à un tablespace géré au moyen du dictionnaire.
Le package PL/SQL
DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_FROM_LOCAL permet la
conversion en tablespace géré au moyen du dictionnaire si nécessaire.
• Make Readonly : Arrête toutes les opérations d'écriture dans le tablespace. Les
transactions en cours peuvent se terminer, mais aucune nouvelle instruction LMD ni
aucune autre activité d'écriture n'est autorisée à démarrer sur le tablespace. Cette option
n'est proposée que si le tablespace n'est pas actuellement en mode lecture seule.
• Make Writable : Permet le lancement d'instructions LMD et d'autres activités d'écriture
sur les objets du tablespace. Cette option n'est proposée que si le tablespace n'est pas
actuellement accessible en écriture.

Actions sur les tablespaces (suite)
• Place Online : Remet en ligne (online) un tablespace actuellement hors ligne (offline).
• Reorganize : Démarre l'assistant Reorganization Wizard, qui permet de déplacer des objets dans
le tablespace afin de récupérer de l'espace inutilisé. Cette tâche doit être réalisée à un moment où
les objets du tablespace sont peu utilisés.
• Run Segment Advisor : Démarre Segment Advisor, qui vous aide à déterminer si un objet
comporte de l'espace disponible pouvant être récupéré, en fonction du niveau de fragmentation
de l'espace dans l'objet. Au niveau tablespace, un conseil est généré pour chaque segment.
• Show Dependencies : Affiche les objets dont le tablespace dépend ou les objets qui dépendent
du tablespace.
• Show Tablespace Contents : Affiche des informations relatives à l'ensemble des segments du
tablespace, notamment une représentation graphique de tous les extents.
• Take Offline : Rend inaccessible un tablespace actuellement en ligne. Le tablespace n'est
toutefois pas supprimé.

Supprimer des tablespaces

Supprimer des tablespaces

Vous pouvez supprimer de la base de données un tablespace et son contenu (c'est-à-dire les
segments inclus dans le tablespace) s'ils ne sont plus nécessaires. Vous devez pour cela
disposer du privilège système DROP TABLESPACE.
Lorsque vous supprimez un tablespace, les pointeurs du fichier de contrôle de la base associée
sont supprimés. Si vous utilisez Oracle Managed Files (OMF), les fichiers du système
d'exploitation sous-jacents sont également supprimés. Si vous n'utilisez pas OMF, vous
pouvez demander au serveur Oracle de supprimer les fichiers du système d'exploitation
(fichiers de données) qui constituaient le tablespace supprimé. Si vous ne demandez pas au
serveur Oracle de supprimer les fichiers de données en même temps que le tablespace, vous
pourrez supprimer ces fichiers ultérieurement, si vous le souhaitez, au moyen des commandes
appropriées du système d'exploitation.
Vous ne pouvez pas supprimer un tablespace contenant des segments actifs. Par exemple, si
une table du tablespace est en cours d'utilisation ou que le tablespace contient des données
d'annulation (undo) nécessaires pour annuler (rollback) des transactions non validées, vous ne
pouvez pas supprimer le tablespace. Le tablespace peut être en ligne (online) ou hors ligne
(offline), mais il est préférable de le placer hors ligne avant de le supprimer.

Afficher les informations relatives
aux tablespaces

Afficher les informations relatives aux tablespaces

Cliquez sur View pour afficher les informations relatives au tablespace sélectionné. Dans la
page View Tablespace, vous pouvez également cliquer sur Edit afin de modifier le tablespace.
Les informations relatives aux tablespaces et aux fichiers de données peuvent aussi être
obtenues via l'interrogation des vues suivantes :
• Informations relatives aux tablespaces :
- DBA_TABLESPACES
- V$TABLESPACE
• Informations relatives aux fichiers de données :
- DBA_DATA_FILES
- V$DATAFILE
Remarque : La vue V$DBFILE affiche tous les fichiers de données de la base. Elle est
conservée pour des raisons de compatibilité historique, mais il est recommandé d'utiliser la
vue V$DATAFILE.
• Informations relatives aux fichiers temporaires :
- DBA_TEMP_FILES
- V$TEMPFILE

Afficher le contenu d'un tablespace

Afficher le contenu d'un tablespace

A partir de la page principale Tablespaces ou de la page associée à un tablespace particulier,
sélectionnez Show Tablespace Contents dans la liste déroulante Actions et cliquez sur Go. La
page Show Tablespace Contents fournit des informations détaillées sur le tablespace,
notamment la liste des segments du tablespace, le type et la taille de chaque segment, et le
nombre d'extents composant chaque segment. Vous pouvez trier la liste en fonction de l'un de
ces quatre éléments, en cliquant sur l'en-tête de colonne souhaité, ou filtrer la liste en entrant
des valeurs dans la région Search. Dans le cas d'un tablespace géré au moyen du dictionnaire,
des colonnes supplémentaires apparaissent :
• Max Extents
• Next
• Percent Increase
Pour afficher la liste des extents d'un tablespace, cliquez sur le lien correspondant dans la
colonne Extents.
Pour représenter les extents sous forme graphique, développez le lien "Extent map" et amenez
le curseur sur chaque extent. Les informations suivantes apparaissent :
• Nom du segment auquel l'extent appartient
• ID de l'extent
• ID du bloc
• Taille de l'extent en termes de blocs
• Fichier de données dans lequel l'extent est stocké

Oracle-Managed Files (OMF)
Permet de définir les opérations sur les fichiers en termes
d'objets de base de données plutôt qu'en termes de noms de
fichier.
Paramètre Description
DB_CREATE_FILE_DEST Définit l'emplacement du répertoire par défaut

du système de fichiers destiné aux fichiers de
données et aux fichiers temporaires
DB_CREATE_ONLINE_LOG_DEST_n Indique l'emplacement des fichiers de
journalisation et l'emplacement de création du
fichier de contrôle
DB_RECOVERY_FILE_DEST Emplacement par défaut de la zone de

récupération rapide
Exemple :
SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST = '+DATA';
SQL> CREATE TABLESPACE tbs_1;
Oracle-Managed Files (OMF)

Grâce à Oracle-Managed Files (OMF), vous n'avez plus besoin de gérer directement les
fichiers du système d'exploitation d'une base de données Oracle. Vous définissez les
opérations en termes d'objets de base de données plutôt qu'en termes de noms de fichier. La
base utilise en interne les interfaces standard du système de fichiers afin de créer et de
supprimer des fichiers, selon les besoins, pour les structures suivantes :
• Tablespaces
• Fichiers de journalisation
• Fichiers de contrôle
• Fichiers de journalisation archivés
• Fichiers de suivi des modifications de bloc
• Journaux Flashback
• Sauvegardes RMAN
Une base de données peut être constituée de fichiers pris en charge par OMF et de fichiers
non pris en charge. Le répertoire du système de fichiers indiqué par l'un ou l'autre des
paramètres indiqués dans la diapositive doit exister. Il n'est pas créé par la base de données.
Les droits définis sur ce répertoire doivent permettre à la base de créer des fichiers dans
celui-ci.
Comme le montre l'exemple de la diapositive, lorsque le paramètre DB_CREATE_FILE_DEST
est défini, la clause DATAFILE peut être omise dans une instruction CREATE TABLESPACE.
Le fichier de données est créé à l'emplacement indiqué par DB_CREATE_FILE_DEST. Quand
vous créez un tablespace de cette manière, des valeurs par défaut sont affectées à tous les
paramètres.

Oracle-Managed Files (OMF) (suite)
Il existe un format de nom de fichier spécifique pour les fichiers OMF. Dans les systèmes Linux et
Unix, le format suivant est utilisé :
<destination_prefix>/o1_mf_%t_%u_.dbf
Ne renommez pas un fichier OMF car la base de données l'identifie grâce à son nom. Si vous
changez le nom d'un fichier OMF, la base ne le reconnaît plus en tant que fichier OMF et ne le traite
donc pas comme tel.
L'exemple de code suivant définit l'emplacement par défaut /u01/oradata pour les fichiers de
données créés ultérieurement, puis crée un tablespace tbs_1 avec un fichier de données à cet
emplacement.
SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST = '/u01/oradata';
SQL> CREATE TABLESPACE tbs_1;
Par défaut, les fichiers OMF ont une taille de 100 Mo avec possibilité d'auto-extension (y compris
ceux des tablespaces SYSTEM et SYSAUX).

Remarque : ASM (Automatic Storage Management) utilise par défaut des fichiers OMF. Toutefois,
si vous précisez un alias pour un fichier de données ASM lors de la création d'un tablespace ou de
l'ajout d'un fichier de données ASM à un tablespace existant, ce fichier n'est pas de type OMF.

Etendre la base de données
Vous pouvez étendre la base de données de différentes façons :
• En créant un tablespace
• En ajoutant un fichier de données à un tablespace smallfile
existant
• En augmentant la taille d'un fichier de données
• En permettant la croissance dynamique d'un fichier de
données
Base de données

Tablespace Tablespace
SYSTEM INVENTORY
Etendre la base de données

Vous pouvez réaliser les activités indiquées dans la diapositive via Enterprise Manager ou par
le biais d'instructions SQL. La taille de la base de données correspond à la somme de tous ses
tablespaces.

Quiz
Une base de données peut être constituée de fichiers pris en

charge par OMF et de fichiers non pris en charge.
1. Vrai
2. Faux

Réponse : 1

Quiz
Un tablespace bigfile doit comprendre 1 fichier d'au moins 100 Mo.

1. Vrai
2. Faux

Réponse : 2

Synthèse

• décrire le stockage des données des lignes de table sous la
forme de blocs
• créer et gérer des tablespaces
• obtenir des informations sur les tablespaces


Gérer les structures de stockage
d'une base de données
• créer des tablespaces
• collecter des informations sur les tablespaces


Administrer la sécurité utilisateur

Objectifs

• créer et gérer des comptes utilisateur de base de données :
– authentifier les utilisateurs
– affecter des zones de stockage par défaut (tablespaces)
• accorder et révoquer des privilèges
• créer et gérer des rôles
• créer et gérer des profils :
– implémenter des fonctionnalités standard de sécurité utilisant

des mots de passe
– contrôler l'utilisation des ressources par les utilisateurs
Objectifs
Les termes suivants, qui ont trait à l'administration des utilisateurs de base de données, vous
aideront à comprendre les objectifs du chapitre :
• Un compte utilisateur de base de données constitue un moyen d'organiser l'appartenance
des objets de base de données et l'accès à ces objets.
• Un mot de passe est un mode d'authentification par la base de données Oracle.
• On nomme privilège le droit d'exécuter un type particulier d'instruction SQL ou d'accéder
à l'objet d'un autre utilisateur.
• Un rôle est un groupe nommé de privilèges liés qui sont accordés à des utilisateurs ou à
d'autres rôles.
• Un profil impose un ensemble nommé de limites concernant l'utilisation de la base de
données et les ressources des instances. Il permet de gérer le statut des comptes et les
règles relatives aux mots de passe.
• Un quota est une allocation d'espace dans un tablespace donné. Il constitue l'un des
moyens permettant de contrôler l'utilisation des ressources par les utilisateurs.

Comptes utilisateur de base de données
Chaque compte utilisateur de base de données comporte :

• un nom utilisateur unique
• une méthode d'authentification
• un tablespace par défaut
• un tablespace temporaire
• un profil utilisateur
• un groupe de consommateurs de ressources initial
• un statut de compte

Un schéma :
• est un ensemble d'objets de base de données appartenant
à un utilisateur de la base
• présente le même nom que le compte utilisateur
Comptes utilisateur de base de données

Pour accéder à la base de données, un utilisateur doit indiquer un compte utilisateur valide et
s'authentifier. A chaque utilisateur de la base est associé un compte unique.
Cette méthode est recommandée par Oracle car elle permet d'éviter toute faille dans la
sécurité et fournit des données significatives pour certaines activités d'audit. Il peut toutefois
arriver que des utilisateurs partagent un même compte de base de données. Dans ces cas assez
rares, le système d'exploitation et les applications doivent sécuriser la base de données de
manière suffisante. Chaque compte utilisateur comporte les éléments suivants :
• Un nom utilisateur unique : Les noms utilisateur ne peuvent pas dépasser 30 octets, ne
doivent pas contenir de caractères spéciaux et doivent commencer par une lettre.
• Une méthode d'authentification : La méthode la plus courante est l'authentification par
mot de passe, mais Oracle Database 11g prend en charge des méthodes d'authentification
globales et externes (notamment par biométrie, par certificat et par système tiers).
• Un tablespace par défaut : Il s'agit de l'emplacement dans lequel l'utilisateur crée des
objets s'il n'indique pas un autre tablespace. Notez que le fait qu'un utilisateur dispose
d'un tablespace par défaut n'implique pas qu'il bénéficie du privilège permettant de créer
des objets dans ce tablespace, ni qu'il dispose d'un quota d'espace dans ce tablespace. En
effet, les privilèges et les quotas sont accordés séparément.
• Un tablespace temporaire : Il s'agit de l'emplacement dans lequel l'instance crée les
objets temporaires (tris ou tables) pour le compte de l'utilisateur. Aucun quota n'est
appliqué aux tablespaces temporaires.

Comptes utilisateur de base de données (suite)
• Un profil utilisateur : Il s'agit d'un ensemble de restrictions concernant les ressources et les
mots de passe qui est affecté à l'utilisateur.
• Un groupe de consommateurs de ressources initial : Il est utilisé par le gestionnaire de
ressources.
• Un statut de compte : Les utilisateurs n'ont accès qu'aux comptes "ouverts". account_status
accepte diverses combinaisons des statuts "verrouillé" et "expiré".
Schémas : Un schéma est un ensemble d'objets de base de données appartenant à un utilisateur de la
base. Les objets de schéma correspondent aux structures logiques qui font directement référence aux
données de la base. Ils incluent des structures telles que des tables, des vues, des séquences, des
procédures stockées, des synonymes, des index, des clusters et des liens de base de données. En règle
générale, les objets de schéma comprennent tous les éléments que votre application crée dans la base
de données.
Remarque : Un utilisateur de base de données n'est pas forcément une personne. Il est courant de

créer un utilisateur qui possède les objets de base de données d'une application particulière (HR - par
exemple). L'utilisateur de base de données peut être un périphérique, une application ou simplement
une entité regroupant des objets à des fins de sécurité. Les informations d'identification personnelle
ne sont pas nécessaires pour un utilisateur de base de données.

Comptes d'administration prédéfinis
• Caractéristiques du compte SYS :
– Il bénéficie du rôle d'administrateur de base de données (DBA)
et de plusieurs autres rôles.
– Il dispose de tous les privilèges associés à ADMIN OPTION.
– Il est requis pour les opérations de démarrage et d'arrêt, ainsi
que pour certaines commandes de maintenance.
– Il est propriétaire du dictionnaire de données et du référentiel
AWR (Automatic Workload Repository).
• Le compte SYSTEM reçoit les rôles DBA, MGMT_USER et
AQ_ADMINISTRATOR_ROLE.
• Le compte DBSNMP reçoit le rôle OEM_MONITOR.

• Le compte SYSMAN reçoit les rôles MGMT_USER, RESOURCE
et SELECT_CATALOG_ROLE.
• Ces comptes ne sont pas utilisés pour les opérations de
routine.
Comptes d'administration prédéfinis

Le rôle d'administrateur de base de données (DBA) est affecté par défaut aux comptes SYS et
SYSTEM. Le compte SYS dispose en plus de tous les privilèges associés à ADMIN OPTION et
il est propriétaire du dictionnaire de données. Pour vous connecter au compte SYS, vous
devez utiliser la clause AS SYSDBA pour une instance de base de données et la clause AS
SYSASM pour une instance ASM (Automatic Storage Management). Tout utilisateur qui
dispose du privilège SYSDBA peut se connecter au compte SYS à l'aide de la clause AS
SYSDBA. Seuls les utilisateurs bénéficiant du privilège SYSDBA, SYSOPER ou SYSASM sont
autorisés à démarrer et arrêter les instances. Le compte SYSTEM n'est pas doté du privilège
SYSDBA, mais il a les rôles AQ_ADMINISTRATOR_ROLE et MGMT_USER. Les comptes
SYS et SYSTEM sont obligatoires dans la base de données. Il n'est pas possible de les
supprimer.
Le compte DBSNMP est utilisé par l'agent de gestion d'Enterprise Manager pour surveiller et
gérer la base de données, tandis que le compte SYSMAN permet d'effectuer des tâches
d'administration dans Oracle Enterprise Manager. Ces deux comptes ne sont pas dotés du
privilège SYSDBA.
Recommandation : Selon le principe du moindre privilège, ces comptes ne sont pas utilisés
pour les opérations de routine. Les utilisateurs qui ont besoin des privilèges de DBA disposent
de comptes distincts auxquels sont affectés les privilèges requis. Ainsi, Jim peut avoir un
compte jim ayant peu de privilèges et un compte jim_dba doté de privilèges élevés. Cette
méthode permet d'appliquer le principe du moindre privilège. Elle évite d'avoir à partager des
comptes et permet de réaliser des audits sur des actions individuelles.

Créer un utilisateur

Sélectionnez Server > Users, puis cliquez sur le bouton Create.
Créer un utilisateur
Dans la page Users d'Enterprise Manager, vous pouvez gérer les utilisateurs de base de
données autorisés à accéder à la base actuelle. Cette page vous permet de créer, supprimer et
modifier les paramètres d'un utilisateur.
Pour créer un utilisateur de base de données :
1. Dans Enterprise Manager Database Control, cliquez sur l'onglet Server puis cliquez sur
Users dans la section Security.
2. Cliquez sur le bouton Create.
Fournissez les informations requises. Les éléments obligatoires sont signalés par un astérisque
(*), par exemple le champ Name. Le nom indiqué dans ce champ obéit aux mêmes règles que
les noms des objets de base de données. Les pages suivantes fournissent davantage
d'informations sur l'authentification. Les profils seront traités plus loin dans ce chapitre.
Affectez un tablespace par défaut et un tablespace temporaire à chaque utilisateur. Si les
utilisateurs n'indiquent pas de tablespace quand ils créent un objet, cet objet est créé dans le
tablespace par défaut affecté au propriétaire de l'objet. Vous pouvez ainsi contrôler
l'emplacement des nouveaux objets. Si vous n'indiquez pas de tablespace par défaut, c'est le
tablespace permanent par défaut défini par le système qui est utilisé. Il en va de même pour le
tablespace temporaire. Si vous ne le définissez pas, le tablespace temporaire défini par le
système est utilisé.
Remarque : Cliquez sur Show SQL pour afficher la syntaxe SQL sous-jacente. Pour plus
d'informations sur la syntaxe SQL utilisée pour créer des utilisateurs, reportez-vous au manuel
Oracle® Database SQL Language Reference.

Authentification des utilisateurs
• Password
• External
• Global

Authentification des utilisateurs

L'authentification consiste à vérifier l'identité d'une entité (utilisateur, périphérique ou autre)
qui souhaite utiliser des données, des ressources ou des applications. La validation de cette
identité établit une relation de confiance pour les interactions ultérieures. L'authentification
permet également la responsabilisation, car elle établit le lien entre les accès et les actions et
des identités spécifiques. Après l'authentification d'une entité, le processus d'autorisation peut
autoriser ou restreindre les accès et les actions associés à celle-ci.
Lorsque vous créez un utilisateur, vous devez décider de la technique d'authentification à
utiliser, laquelle pourra être modifiée ultérieurement :
Password : L'authentification par mot de passe est aussi appelée authentification par la base
de données Oracle. Chaque utilisateur créé reçoit un mot de passe qu'il devra saisir lors de
chaque connexion. Lorsque vous définissez un mot de passe, vous pouvez le configurer afin
qu'il expire immédiatement, ce qui oblige l'utilisateur à le changer lors de la première
connexion. Dans ce cas, assurez-vous que les utilisateurs ont la possibilité de changer le mot
de passe. Certaines applications n'offrent pas cette possibilité. Tous les mots de passe créés
dans Oracle Database 11g sont sensibles à la casse. Ils peuvent contenir des caractères
multioctets et sont limités à 30 octets. Les mots de passe créés dans une base de données qui
est mise à niveau vers Oracle Database 11g restent insensibles à la casse jusqu'à ce qu'ils
soient modifiés.
Les mots de passe sont toujours cryptés de manière automatique et transparente à l'aide d'un
algorithme AES (Advanced Encryption Standard) lors des connexions réseau (client/serveur
et serveur/serveur), et ce avant d'être envoyés sur le réseau.

Authentification des utilisateurs (suite)
External : Cette option utilise une méthode d'authentification extérieure à la base de données
(système d'exploitation, Kerberos ou Radius). L'option Oracle Advanced Security (ASO) est requise
pour les méthodes Kerberos et Radius. Les utilisateurs peuvent se connecter à la base de données
Oracle sans fournir de nom utilisateur ou de mot de passe. L'option ASO (authentification forte)
permet l'identification des utilisateurs via un système biométrique, des certificats x509 et des
systèmes tiers. Avec le mode d'authentification External, la base utilise le système d'exploitation
sous-jacent, le service d'authentification réseau ou un service d'authentification externe pour limiter
l'accès aux comptes de base de données. Aucun mot de passe de base de données n'est utilisé pour ce
type de connexion. Si le système d'exploitation ou le service réseau le permet, vous pouvez le
configurer pour l'authentification des utilisateurs. Dans ce cas, définissez le paramètre d'initialisation
OS_AUTHENT_PREFIX et utilisez ce préfixe dans les noms utilisateur Oracle. Ce paramètre définit
le préfixe qui est ajouté par la base de données Oracle au début du nom de compte du système
d'exploitation de chaque utilisateur. La valeur par défaut de ce paramètre est OPS$ (pour des raisons
de compatibilité descendante avec les versions antérieures du logiciel Oracle). Lorsqu'un utilisateur

tente de se connecter, la base de données Oracle compare le nom utilisateur doté du préfixe avec les
noms utilisateur Oracle de la base de données. Par exemple, supposons que le paramètre
OS_AUTHENT_PREFIX soit défini comme suit :
OS_AUTHENT_PREFIX=OPS$
Si un utilisateur doté d'un compte de système d'exploitation nommé tsmith doit se connecter à une
base de données Oracle et être authentifié par le système d'exploitation, la base vérifie s'il existe un
utilisateur de base de données OPS$tsmith correspondant et, si tel est le cas, elle autorise
l'utilisateur à se connecter. Toutes les références à un utilisateur authentifié par le système
d'exploitation doivent inclure le préfixe, comme dans OPS$tsmith.
Remarque : Dans certains systèmes d'exploitation, la valeur du paramètre d'initialisation
OS_AUTHENT_PREFIX est sensible à la casse. Reportez-vous à la documentation Oracle propre à
votre système d'exploitation pour plus d'informations sur ce paramètre.
Global : Avec l'option Oracle Advanced Security, ce mode d'authentification permet d'identifier les
utilisateurs via Oracle Internet Directory.
Pour plus d'informations sur les méthodes d'authentification avancées, reportez-vous au cours Oracle
Database : Sécurité.

Authentification des administrateurs
Sécurité au niveau du système d'exploitation :
• Les administrateurs de base de données doivent disposer des
privilèges de création et de suppression de fichiers au niveau du
• Les utilisateurs de base de données ne bénéficient normalement pas
des privilèges de création ou de suppression de fichiers de base de
données au niveau du système d'exploitation.
Sécurité au niveau de l'administrateur :
• Pour les connexions en tant que SYSDBA, SYSOPER et SYSASM :
– Audit du nom utilisateur du DBA pour les méthodes d'authentification
fortes et par fichier de mots de passe
– Audit du nom de compte du système d'exploitation pour l'authentification

par le système d'exploitation
– Priorité de l'authentification par le système d'exploitation sur
l'authentification par fichier de mots de passe pour les utilisateurs ayant
des privilèges
– Utilisation de mots de passe sensibles à la casse
Authentification des administrateurs

Sécurité au niveau du système d'exploitation : Sous UNIX et Linux, les DBA appartiennent
par défaut au groupe oinstall du système d'exploitation, qui bénéficie des privilèges requis
pour la création et la suppression des fichiers de base de données.
Sécurité au niveau de l'administrateur : Les connexions des utilisateurs dotés de privilèges
SYSBA, SYSOPER et SYSASM ne sont autorisées qu'après une vérification basée sur le fichier
de mots de passe ou sur les privilèges et permissions définis au niveau du système
d'exploitation. Lorsque vous utilisez l'authentification par le système d'exploitation, la base de
données n'utilise pas le nom utilisateur et le mot de passe fournis. Ce type d'authentification est
appliqué dans les cas suivants : si aucun fichier de mots de passe n'est présent, si le nom
utilisateur et le mot de passe fournis ne figurent pas dans le fichier de mots de passe, ou si aucun
nom utilisateur ni mot de passe n'est fourni. Par défaut, le fichier de mots de passe créé dans
Oracle Database 11g respecte la casse.
Quoi qu'il en soit, si l'authentification par le biais du fichier de mots de passe réussit, la
connexion est établie via le nom utilisateur. Si c'est l'authentification par le biais du système
d'exploitation qui aboutit, une connexion CONNECT / est établie et cette dernière n'enregistre
pas l'utilisateur concerné.
Remarque : Si vous êtes membre du groupe OSDBA ou OSOPER propre au système
d'exploitation et que vous vous connectez en tant que SYSDBA ou SYSOPER, vous êtes
connecté avec les privilèges d'administration associés, quels que soient le nom utilisateur et le
mot de passe indiqués. Pour se connecter en tant que SYSASM, il ne faut pas préciser de nom
utilisateur ni de mot de passe (par exemple, sqlplus / as SYSASM).

Authentification des administrateurs (suite)
Dans Oracle Database 11g, un utilisateur ayant des privilèges peut utiliser des méthodes
d'authentification fortes : Kerberos, SSL (Secure Sockets Layer) ou service d'annuaire avec une
licence ASO (Oracle Advanced Security).

Déverrouiller un compte utilisateur et
redéfinir le mot de passe

Sélectionnez l'utilisateur et cliquez sur Unlock
User, puis cliquez sur Go.
Déverrouiller un compte utilisateur et redéfinir le mot de passe

Au cours de l'installation et de la création d'une base de données, vous pouvez déverrouiller
plusieurs des comptes utilisateur définis par Oracle et redéfinir les mots de passe associés.
Vous pouvez aussi effectuer ces opérations ultérieurement. Il suffit de sélectionner un
utilisateur dans la page Users, de cliquer sur Unlock User dans la liste Actions, puis de cliquer
sur Go. Cette action n'a aucun impact sur le mot de passe. Si le mot de passe a expiré au
moment où vous déverrouillez le compte utilisateur, il conserve l'état "expired" tant que vous
ne modifiez pas l'utilisateur pour changer son mot de passe.
Pour déverrouiller l'utilisateur et redéfinir son mot de passe, utilisez la page Edit User :
1. Entrez le nouveau mot de passe dans les champs Enter Password et Confirm Password.
2. Cochez la case Unlocked.
3. Cliquez sur Apply pour redéfinir le mot de passe et déverrouiller le compte utilisateur.

Privilèges
Il existe deux types de privilège utilisateur :
• Un privilège système permet d'effectuer des actions
particulières dans la base de données.
• Un privilège objet permet d'accéder à un objet spécifique
et de le manipuler.
HR_DBA

Privilège objet : Privilège système :
Mettre à jour
les employés Créer une session
Privilèges
On nomme privilège le droit d'exécuter un type particulier d'instruction SQL ou d'accéder à
l'objet d'un autre utilisateur. La base de données Oracle vous permet de contrôler les
opérations que les utilisateurs peuvent effectuer ou non au sein de la base.
Les privilèges sont répartis en deux catégories :
• Privilèges système : Chaque privilège système autorise un utilisateur à effectuer une
certaine opération de base de données ou une certaine classe d'opérations. Par exemple,
le privilège permettant de créer des tablespaces est un privilège système. Les privilèges
système peuvent être accordés par l'administrateur ou par quelqu'un à qui la permission
d'administrer ces privilèges a été accordée explicitement. Il existe plus de 170 privilèges
système différents. Un grand nombre d'entre eux contiennent la clause ANY.
• Privilèges objet : Les privilèges objet permettent à un utilisateur d'effectuer une action
particulière sur un objet spécifique, tel qu'une table, une vue, une séquence, une
procédure, une fonction ou un package. Sans permission spécifique, les utilisateurs ne
peuvent accéder qu'à leurs propres objets. Les privilèges objet peuvent être octroyés par
le propriétaire d'un objet, par l'administrateur, ou par un utilisateur auquel la permission
d'accorder des privilèges sur l'objet a été attribuée explicitement.

Privilèges système

Privilèges système
Pour accorder des privilèges système, cliquez sur l'onglet System Privileges de la page Edit
User. Sélectionnez les privilèges appropriés dans la liste des privilèges disponibles, puis
déplacez-les vers la liste Selected System Privileges en cliquant sur le bouton Move.
Les privilèges contenant la clause ANY s'étendent au-delà des limites du schéma. Par exemple,
le privilège CREATE TABLE vous permet de créer une table, mais uniquement dans votre
propre schéma. Avec le privilège SELECT ANY TABLE, vous pouvez effectuer une opération
SELECT dans des tables appartenant à d'autres utilisateurs. L'utilisateur SYS et les utilisateurs
dotés du rôle DBA disposent de tous les privilèges ANY. Ils peuvent donc effectuer n'importe
quelle opération sur tous les objets de données. La portée des privilèges système ANY peut
être contrôlée à l'aide de l'option Oracle Database Vault.
Cochez la case Admin Option pour autoriser l'utilisateur à administrer le privilège et à
l'accorder à d'autres utilisateurs.
La syntaxe SQL suivante est exécutée pour accorder un privilège système :
GRANT <system_privilege> TO <grantee clause> [WITH ADMIN
OPTION]
Tenez bien compte des exigences de sécurité avant d'octroyer des permissions système.
Certains privilèges système sont généralement réservés aux administrateurs :
• RESTRICTED SESSION : Ce privilège autorise son détenteur à se connecter même si la
base de données a été ouverte en mode d'accès restreint.

Privilèges système (suite)
• SYSDBA et SYSOPER : Ces privilèges permettent d'arrêter et de démarrer la base de données,
mais aussi d'effectuer des opérations de récupération et d'autres tâches d'administration. Le
privilège SYSOPER permet d'effectuer des tâches opérationnelles de base, mais pas de voir les
données utilisateur. Il inclut les privilèges système suivants :
- STARTUP et SHUTDOWN
- CREATE SPFILE
- ALTER DATABASE OPEN/MOUNT/BACKUP
- ALTER DATABASE ARCHIVELOG
- ALTER DATABASE RECOVER (Récupération complète uniquement. Pour toute forme de
récupération incomplète, telle que UNTIL TIME|CHANGE|CANCEL|CONTROLFILE, le
privilège SYSDBA est nécessaire.)
- RESTRICTED SESSION
Le privilège système SYSDBA autorise en outre les opérations de récupération incomplète et la

suppression d'une base de données. En fait, il permet de se connecter en tant qu'utilisateur SYS.
• SYSASM : Ce privilège permet de démarrer, d'arrêter et d'administrer une instance ASM.
• DROP ANY object : Le privilège DROP ANY permet de supprimer des objets appartenant à
d'autres utilisateurs du schéma.
• CREATE, MANAGE, DROP et ALTER TABLESPACE : Ces privilèges permettent les opérations
d'administration des tablespaces (création, suppression et modification d'attributs).
• CREATE LIBRARY : La base de données Oracle permet aux développeurs de créer et d'appeler
du code externe (par exemple, une bibliothèque C) à partir de PL/SQL. La bibliothèque doit être
nommée via un objet LIBRARY de la base de données. Le privilège CREATE LIBRARY
permet à l'utilisateur de créer une bibliothèque de code arbitraire qui peut être exécutée à partir
de PL/SQL.
• CREATE ANY DIRECTORY : Pour des raisons de sécurité, le répertoire du système
d'exploitation dans lequel le code réside doit être lié à un objet de répertoire Oracle virtuel. Avec
le privilège CREATE ANY DIRECTORY, vous pouvez potentiellement appeler des objets de
code non sécurisés.
Le privilège CREATE ANY DIRECTORY permet à un utilisateur de créer un objet répertoire
(Directory) avec un accès en lecture et en écriture pour tous les répertoires auxquels le
propriétaire du logiciel Oracle a accès. Cela signifie que l'utilisateur peut accéder aux procédures
externes figurant dans ces répertoires. Il peut tenter d'effectuer des opérations de lecture et
d'écriture directement dans un fichier de base de données (fichier de données, fichier de
journalisation et journal d'audit, par exemple). Assurez-vous que votre organisation dispose
d'une stratégie de sécurité qui évite toute mauvaise utilisation de privilèges puissants tels que
celui-ci.
• GRANT ANY OBJECT PRIVILEGE : Ce privilège permet à l'utilisateur qui en est doté
d'accorder des permissions sur des objets qui ne lui appartiennent pas.
• ALTER DATABASE et ALTER SYSTEM : Très puissants, ces privilèges autorisent leur détenteur
à modifier la base de données et l'instance Oracle. Ils permettent notamment de renommer un
fichier de données ou de vider le cache de tampons.

Privilèges objet
2
Pour accorder des privilèges
objet : Recherchez et
sélectionnez
• Sélectionnez le type

des objets.
d'objet.
• Sélectionnez les objets. 3
• Sélectionnez les
privilèges.
Privilèges objet
Pour accorder des privilèges objet, cliquez sur l'onglet Object Privileges de la page Edit User.
Sélectionnez le type d'objet sur lequel vous voulez octroyer des privilèges, puis cliquez sur le
bouton Add. Indiquez les objets sous la forme <nom_utilisateur.nom_objet> ou
sélectionnez-les dans la liste.
Sélectionnez ensuite les privilèges appropriés dans la liste Available Privileges, puis cliquez
sur le bouton Move. Une fois les privilèges sélectionnés, cliquez sur OK.
Dans la page Edit User, cochez la case Grant pour autoriser l'utilisateur à octroyer le même
accès à d'autres utilisateurs.
La syntaxe SQL suivante est exécutée pour accorder un privilège objet :
GRANT <object_privilege> ON <object> TO <grantee clause>
[WITH GRANT OPTION]

Révoquer des privilèges système
accordés avec ADMIN OPTION
DBA Joe Emily
Utilisateur
GRANT
Privilège
Objet
DBA Joe Emily

REVOKE

REVOKE CREATE
TABLE FROM joe;
Révoquer des privilèges système accordés avec ADMIN OPTION

Les privilèges système qui ont été octroyés directement à l'aide de la commande GRANT
peuvent être révoqués via l'instruction SQL REVOKE. Les utilisateurs disposant de l'option
ADMIN OPTION pour un privilège système peuvent révoquer ce privilège pour tout autre
utilisateur de la base de données. La révocation peut être effectuée par un utilisateur différent
de celui qui a initialement octroyé le privilège.
Aucune répercussion en cascade ne se produit lorsqu'un privilège système est révoqué, que
celui-ci ait été ou non accordé avec l'option ADMIN OPTION.
La syntaxe SQL suivante est exécutée pour révoquer un privilège système :
REVOKE <system_privilege> FROM <grantee clause>
La diapositive ci-dessus illustre la situation suivante :
Scénario
1. Le DBA octroie le privilège système CREATE TABLE à Joe avec l'option ADMIN
OPTION.
2. Joe crée une table.
3. Joe accorde le privilège système CREATE TABLE à Emily.
4. Emily crée une table.
5. Le DBA révoque le privilège système CREATE TABLE pour Joe.
Résultat
La table créée par Joe existe toujours, mais Joe ne peut plus en créer d'autres. La table d'Emily
existe toujours et Emily conserve le privilège système CREATE TABLE.

Révoquer des privilèges objet
accordés avec GRANT OPTION
Bob Joe Emily

GRANT
REVOKE Bob Joe Emily

Révoquer des privilèges objet accordés avec GRANT OPTION

Des effets en cascade peuvent être observés lors de la révocation d'un privilège système lié à
une opération LMD (langage de manipulation de données). Par exemple, si le privilège
SELECT ANY TABLE est octroyé à un utilisateur et que ce dernier a créé des procédures qui
utilisent la table concernée, toutes les procédures contenues dans le schéma de l'utilisateur
doivent être recompilées pour pouvoir être réemployées.
La révocation de privilèges objet accordés avec l'option GRANT OPTION produit également
des effets en cascade. En tant qu'utilisateur, vous ne pouvez révoquer que les privilèges que
vous avez vous-même accordés. Ainsi, Bob ne peut pas révoquer le privilège objet que Joe a
accordé à Emily. Un privilège objet ne peut être révoqué que par son bénéficiaire ou par un
utilisateur doté du privilège GRANT ANY OBJECT PRIVILEGE.
Scénario
1. Joe reçoit le privilège objet SELECT sur la table EMPLOYEES, avec l'option GRANT
OPTION.
2. Joe accorde à Emily le privilège SELECT sur la table EMPLOYEES.
3. Le privilège SELECT de Joe est révoqué. Cette révocation est répercutée sur Emily.

Avantages des rôles
• Gestion plus facile des privilèges

• Gestion dynamique des privilèges
• Disponibilité sélective des privilèges

Avantages des rôles

• Gestion simplifiée des privilèges : Utilisez des rôles pour simplifier la gestion des
privilèges. Au lieu d'accorder le même ensemble de privilèges à plusieurs utilisateurs,
vous pouvez accorder ces privilèges à un rôle, puis octroyer ce rôle à des utilisateurs
individuels.
• Gestion dynamique des privilèges : Si les privilèges associés à un rôle sont modifiés,
tous les utilisateurs auxquels ce rôle est accordé bénéficient automatiquement et
immédiatement des privilèges modifiés.
• Disponibilité sélective des privilèges : Les rôles peuvent être activés et désactivés afin
d'activer ou de désactiver temporairement les privilèges correspondants. Cela permet de
contrôler les privilèges de l'utilisateur dans une situation donnée.

Affecter des privilèges à des rôles et
des rôles à des utilisateurs
Utilisateurs
Jenny David Rachel
Rôles HR_MGR HR_CLERK

Privilèges Supprimer Mettre à jour
Créer un travail
des employés des employés
Insérer des Sélectionner

employés des employés
Affecter des privilèges à des rôles et des rôles à des utilisateurs

Dans la plupart des systèmes, le processus consistant à accorder individuellement les
privilèges nécessaires à chaque utilisateur prend beaucoup de temps et peut générer des
erreurs. Le logiciel Oracle permet la gestion facile et contrôlée des privilèges par
l'intermédiaire de rôles. Les rôles sont des groupes nommés de privilèges liés qui sont
accordés aux utilisateurs ou à d'autres rôles. Ils facilitent l'administration des privilèges dans
la base de données, et améliorent donc la sécurité.
Caractéristiques des rôles
• Les privilèges sont accordés aux rôles (et révoqués) comme si le rôle était un utilisateur.
• Les rôles sont accordés aux utilisateurs ou à d'autres rôles (et révoqués de la même
manière) comme s'il s'agissait de privilèges système.
• Un rôle peut être constitué de privilèges système et objet.
• Un rôle peut être activé ou désactivé pour chaque utilisateur auquel il est accordé.
• L'activation d'un rôle peut nécessiter un mot de passe.
• Les rôles n'appartiennent à personne et ne résident dans aucun schéma.
L'exemple de la diapositive ci-dessus accorde les privilèges SELECT et UPDATE sur la table
employees, ainsi que le privilège système CREATE JOB au rôle HR_CLERK. Les
privilèges DELETE et INSERT sur la table employees et le rôle HR_CLERK sont accordés
au rôle HR_MGR.
Le rôle HR_MGR est accordé au manager qui peut ensuite effectuer des sélections, des
suppressions, des insertions et des mises à jour dans la table employees.

Rôles prédéfinis
Rôle Privilèges inclus
CONNECT CREATE SESSION
RESOURCE CREATE CLUSTER, CREATE INDEXTYPE, CREATE

OPERATOR, CREATE PROCEDURE, CREATE
SEQUENCE, CREATE TABLE, CREATE TRIGGER,
CREATE TYPE
SCHEDULER_ ADMIN CREATE ANY JOB, CREATE EXTERNAL JOB, CREATE
JOB, EXECUTE ANY CLASS, EXECUTE ANY
PROGRAM, MANAGE SCHEDULER
DBA La plupart des privilèges système et plusieurs autres

rôles. Ce rôle ne doit pas être accordé aux utilisateurs
qui ne sont pas administrateurs.
SELECT_ Aucun privilège système, mais le rôle HS_ADMIN_ROLE
CATALOG_ROLE et plus de 1 700 privilèges objet sur le dictionnaire de
données
Rôles prédéfinis
Il existe plusieurs rôles qui sont définis automatiquement pour les bases de données Oracle
lorsque vous exécutez les scripts de création de la base. Le rôle CONNECT est accordé
automatiquement à tout utilisateur créé avec Enterprise Manager. Pour des raisons de sécurité,
le rôle CONNECT n'inclut que le privilège CREATE SESSION depuis la version 10.2.0
d'Oracle Database.
Remarque : Lorsque vous octroyez le rôle RESOURCE, vous devez également accorder le
privilège UNLIMITED TABLESPACE.
Rôles fonctionnels
D'autres rôles permettant l'administration de fonctions spéciales sont créés lors de
l'installation des fonctions correspondantes. Par exemple, le rôle XDBADMIN dispose des
privilèges requis pour administrer XML Database si cette fonctionnalité est installée. Le rôle
AQ_ADMINISTRATOR_ROLE fournit les privilèges permettant d'administrer Advanced
Queuing. Le rôle HS_ADMIN_ROLE inclut les privilèges requis pour administrer les services
hétérogènes (Heterogeneous Services).
Vous ne devez pas modifier les privilèges accordés à ces rôles fonctionnels sans l'assistance
du Support technique Oracle, car vous risqueriez de désactiver par inadvertance des
fonctionnalités nécessaires.

Créer un rôle
Ajoutez des privilèges et

Sélectionnez Server > Roles. des
des rôles
rôles à
à l'aide
l'aide des
des
onglets appropriés.
Cliquez sur OK
lorsque vous
avez terminé.

Créer un rôle
Un rôle est un groupe nommé de privilèges liés qui sont accordés à des utilisateurs ou à
d'autres rôles. Un administrateur de base de données (DBA) gère les privilèges via des rôles.
Pour créer un rôle, procédez de la manière suivante :
1. Dans Enterprise Manager Database Control, sélectionnez l'onglet Server, puis cliquez sur
Roles dans la section Security.
2. Cliquez sur le bouton Create.
3. Dans l'onglet General, entrez le nom du rôle.
4. Si vous le souhaitez, ajoutez au rôle des privilèges système et objet, voire d'autres rôles.
Vous pourrez modifier ce rôle ultérieurement si nécessaire.
5. Cliquez sur OK lorsque vous avez terminé.

Rôles sécurisés
• Il est possible de configurer un rôle pour qu'il ne soit pas
activé par défaut, mais à la demande.
SET ROLE vacationdba;
• Les rôles peuvent être

protégés via l'authentification.

• Les rôles peuvent également être sécurisés par
programmation.
CREATE ROLE secure_application_role
IDENTIFIED USING <security_procedure_name>;
Rôles sécurisés
Les rôles sont généralement activés par défaut. Par conséquent, lorsqu'un rôle est accordé à un
utilisateur, celui-ci peut exercer les privilèges correspondants. Des rôles par défaut sont
affectés aux utilisateurs au moment de leur connexion.
Vous pouvez effectuer les opérations suivantes :
• Empêcher un rôle d'être activé par défaut. Lorsque le rôle est affecté à un utilisateur,
désélectionnez la case DEFAULT. L'utilisateur devra activer explicitement le rôle pour
pouvoir exercer les privilèges correspondants.
• Configurer un rôle afin qu'il nécessite une authentification supplémentaire.
L'authentification par défaut d'un rôle est None, mais il est possible de configurer le rôle
afin qu'il ne puisse être activé qu'après authentification.
• Créer des rôles applicatifs sécurisés qui ne peuvent être activés que via l'exécution d'une
procédure PL/SQL. La procédure PL/SQL peut vérifier des éléments tels que l'adresse
réseau de l'utilisateur, le programme exécuté par l'utilisateur, l'heure, ou tout autre
élément nécessaire pour sécuriser correctement un groupe de permissions.
• Administrer plus facilement les rôles à l'aide de l'option Oracle Database Vault. Cette
option simplifie l'administration des rôles sécurisés et permet de limiter les rôles
standard.

Affecter des rôles aux utilisateurs

Affecter des rôles aux utilisateurs

Vous pouvez utiliser les rôles pour administrer les privilèges de base de données. Vous
pouvez ajouter des privilèges à un rôle, puis accorder le rôle à un utilisateur. L'utilisateur peut
alors activer le rôle et exercer les privilèges octroyés par ce rôle. Un rôle contient tous les
privilèges qui lui ont été accordés, ainsi que tous les privilèges des autres rôles qui lui sont
affectés.
Par défaut, Enterprise Manager accorde automatiquement le rôle CONNECT aux nouveaux
utilisateurs. Ces derniers peuvent ainsi se connecter à la base de données et créer des objets
dans leur propre schéma.
Pour affecter un rôle à un utilisateur, procédez de la manière suivante :
1. Dans Enterprise Manager Database Control, cliquez sur l'onglet Server, puis cliquez sur
Users dans la section Security.
2. Sélectionnez l'utilisateur et cliquez sur le bouton Edit.
3. Cliquez sur l'onglet Roles, puis sur le bouton Edit List.
4. Sélectionnez le rôle souhaité dans la zone Available Roles et déplacez-le dans la zone
Selected Roles.
5. Une fois que vous avez affecté tous les rôles appropriés, cliquez sur le bouton OK.

Quiz
Par défaut, les mots de passe créés dans Oracle Database 11g
ne sont pas sensibles à la casse.
1. Vrai
2. Faux

Réponse : 2

Quiz
Sélectionnez les caractéristiques d'un rôle de base de

données :
1. Il peut être activé ou désactivé.
2. Il peut se composer de privilèges systèmes et de privilèges
objet.
3. Il appartient à l'utilisateur qui le crée.
4. Il ne peut pas être protégé par un mot de passe.

Réponses : 1, 2

Profils et utilisateurs
Un seul profil est affecté à

un utilisateur à un instant
donné.
Les profils :
• contrôlent la
consommation des
ressources
• gèrent le statut des
comptes et l'expiration

des mots de passe
Remarque : Les profils ne peuvent imposer des limites sur les ressources
que si le paramètre RESOURCE_LIMIT est défini avec la valeur TRUE.
Profils et utilisateurs
Les profils imposent un ensemble nommé de limites concernant l'utilisation de la base de
données et les ressources des instances. Par ailleurs, ils gèrent le statut des comptes et
imposent des restrictions sur les mots de passe des utilisateurs (longueur, délai d'expiration,
etc.). Chaque utilisateur se voit affecter un profil et ne peut appartenir qu'à un seul profil à la
fois. Si des utilisateurs sont connectés lorsque vous modifiez leur profil, le changement ne
prend effet que lors de leur prochaine connexion.
Le profil DEFAULT sert de base pour tous les autres profils. Comme l'illustre la diapositive
ci-dessus, les limitations associées à un profil peuvent être définies implicitement
(CPU/Session), être illimitées (CPU/Call) ou faire référence à un paramètre du profil
DEFAULT (Connect Time, par exemple).
Les profils ne peuvent imposer des limitations de ressources aux utilisateurs que si la valeur
TRUE est affectée au paramètre d'initialisation RESOURCE_LIMIT. Si RESOURCE_LIMIT
a la valeur par défaut FALSE , les limitations de ressources liées aux profils sont ignorées.
Les mots de passe des profils sont toujours appliqués.
Les profils permettent à l'administrateur de contrôler les ressources système suivantes :
• CPU : Les ressources CPU peuvent être limitées par session ou par appel. Avec une
limite CPU/Session de 1 000, une session qui utilise ce profil et qui consomme plus de
10 secondes de temps CPU (les limites de temps CPU étant exprimées en centièmes de
seconde) reçoit une erreur et est déconnectée :
ORA-02392: exceeded session limit on CPU usage, you are
being logged off

Profils et utilisateurs (suite)
Une limitation par appel a le même effet, mais au lieu de limiter la session globale de l'utilisateur,
elle empêche chaque commande de consommer trop de temps CPU. Si le temps CPU par appel
(CPU/Call) est limité et que l'utilisateur dépasse cette limite, l'exécution de la commande est
abandonnée. L'utilisateur reçoit alors un message d'erreur de type :
ORA-02393: exceeded call limit on CPU usage
• Network/Memory : Chaque session de base de données consomme des ressources mémoire du
système et (si la session est ouverte par un utilisateur qui ne se trouve pas en local sur le serveur)
des ressources réseau. Vous pouvez définir les éléments suivants :
- Connect Time : Indique le nombre de minutes pendant lesquelles un utilisateur peut rester
connecté avant d'être automatiquement déconnecté.
- Idle Time : Définit le nombre de minutes pendant lesquelles la session d'un utilisateur peut
rester inactive avant d'être automatiquement déconnectée. Le temps d'inactivité est calculé
pour le processus serveur uniquement. Il ne tient pas compte de l'activité des applications.
La limite IDLE_TIME n'est pas affectée par les interrogations longues et les autres

opérations.
- Concurrent Sessions : Indique le nombre de sessions simultanées pouvant être créées à
l'aide d'un compte utilisateur de base de données.
- Private SGA : Limite la quantité d'espace consommé dans la mémoire SGA (System
Global Area) pour le tri, la fusion de bitmaps, etc. Cette restriction ne prend effet que si la
session utilise un serveur partagé. (Les serveurs partagés sont traités dans le chapitre intitulé
"Configurer l'environnement réseau Oracle".)
• Disk I/O : Cette option limite la quantité de données qu'un utilisateur peut lire, par session ou
par appel. Les options Reads/Session et Reads/Call limitent le nombre total de lectures réalisées
à partir de la mémoire et du disque. Elles permettent de s'assurer, par exemple, qu'aucune
instruction consommant beaucoup d'E/S n'utilise trop intensément la mémoire et les disques.
Les profils autorisent également une limite composite, basée sur une combinaison pondérée des
limites CPU/Session, Reads/Session, Connect Time et Private SGA. Les limites composites sont
étudiées plus en détail dans le manuel Oracle Database Security Guide.
Pour créer un profil, cliquez sur l'onglet Server, puis cliquez sur Profiles dans la section Security.
Dans la page Profiles, cliquez sur le bouton Create.
Remarque : Vous pouvez également utiliser Resource Manager à la place de la plupart des
paramètres de profil. Pour plus d'informations sur Resource Manager, reportez-vous au manuel
Oracle Database Administrator's Guide.

Implémenter des fonctionnalités
de sécurité utilisant des mots de passe
Vérification de la
Historique des complexité des
mots de passe mots de passe
Utilisateur Configuration
des profils

Durée de vie Verrouillage
et expiration des comptes
des mots de passe
Remarque : N'utilisez pas de profils qui entraînent l'expiration des mots

de passe SYS, SYSMAN et DBSNMP et le verrouillage de ces comptes.
Implémenter des fonctionnalités de sécurité utilisant des mots de passe

La gestion des mots de passe Oracle est implémentée par l'intermédiaire de profils utilisateur.
Les profils peuvent fournir de nombreuses fonctionnalités de sécurité standard.
Verrouillage des comptes : Permet le verrouillage automatique des comptes pour une durée
définie lorsque les utilisateurs ne parviennent pas à se connecter au système après un nombre
déterminé de tentatives.
• Le paramètre FAILED_LOGIN_ATTEMPTS indique le nombre d'échecs de connexion
autorisés avant le verrouillage du compte.
• Le paramètre PASSWORD_LOCK_TIME définit le nombre de jours pendant lesquels le
compte est verrouillé, une fois le nombre d'échecs de connexion atteint.
Durée de vie et expiration des mots de passe : Permet de définir la durée de vie des mots de
passe utilisateur. Au terme de cette durée, ils expirent et doivent être modifiés.
• Le paramètre PASSWORD_LIFE_TIME détermine la durée de vie du mot de passe (en
nombre de jours). Au terme de cette durée, le mot de passe expire.
• Le paramètre PASSWORD_GRACE_TIME définit la période de grâce (en nombre de
jours) permettant de changer le mot de passe après la première connexion réussie suite à
l'expiration du mot de passe.
Remarque : L'utilisation de la fonction d'expiration des mots de passe et de verrouillage des
comptes SYS, SYSMAN et DBSNMP entrave le bon fonctionnement d'Enterprise Manager. Les
applications doivent récupérer le message d'avertissement "password expired" et gérer la
modification du mot de passe. Si elles n'y parviennent pas, la période de grâce expire et
l'utilisateur subit une déconnexion et un verrouillage sans en connaître la raison.

Implémenter des fonctionnalités de sécurité utilisant des mots de passe (suite)
Historique des mots de passe : Vérifie le nouveau mot de passe afin de garantir qu'il n'est pas
réutilisé pendant une durée déterminée ou avant un certain nombre de changements de mot de passe.
Ces vérifications peuvent être implémentées via l'un des paramètres suivants :
• PASSWORD_REUSE_TIME : Indique qu'un utilisateur ne peut pas réutiliser un mot de passe
pendant un nombre déterminé de jours.
• PASSWORD_REUSE_MAX : Indique le nombre de changements de mot de passe requis avant
réutilisation du mot de passe actuel.
Rappelons que les valeurs des paramètres de profil sont soit définies, soit héritées du profil
DEFAULT.
Si les deux paramètres d'historique des mots de passe ont pour valeur UNLIMITED, Oracle Database
les ignore. L'utilisateur peut à tout moment réutiliser un mot de passe, ce qui n'est pas recommandé
pour la sécurité.
Si les deux paramètres sont définis, la réutilisation d'un mot de passe est autorisée dans les conditions

précisées. L'utilisateur doit avoir modifié son mot de passe un certain nombre de fois et il doit s'être
écoulé un certain délai (en jours) depuis la dernière utilisation de l'ancien mot de passe.
Prenons l'exemple de l'utilisateur ALFRED dont le profil est défini de la manière suivante : la valeur
10 est affectée au paramètre PASSWORD_REUSE_MAX, et la valeur 30 au paramètre
PASSWORD_REUSE_TIME. L'utilisateur ALFRED ne peut donc réutiliser un ancien mot de passe
que s'il a défini au moins 10 mots de passe différents depuis et qu'un délai de 30 jours s'est écoulé.
Si une valeur est affectée à l'un des deux paramètres et que l'autre est défini comme UNLIMITED,
l'utilisateur ne peut jamais réutiliser un mot de passe.
Vérification de la complexité des mots de passe : Effectue une vérification de complexité du mot
de passe afin de garantir qu'il respecte certaines règles. La vérification doit permettre de garantir que
le mot de passe est suffisamment complexe pour offrir une protection contre les intrus qui tenteraient
de pénétrer dans le système en le devinant.
Le paramètre PASSWORD_VERIFY_FUNCTION nomme une fonction PL/SQL qui effectue une
vérification de complexité avant l'affectation d'un mot de passe. Les fonctions de vérification des
mots de passe doivent appartenir à l'utilisateur SYS et renvoyer une valeur booléenne (TRUE ou
FALSE). Le script utlpwdmg.sql fournit une fonction de vérification de mot de passe. Vous le
trouverez dans les répertoires suivants :
• Plates-formes Unix et Linux : $ORACLE_HOME/rdbms/admin
• Plates-formes Windows : %ORACLE_HOME%\rdbms\admin

Créer un profil de mot de passe

Créer un profil de mot de passe

Pour créer un profil de mot de passe, cliquez sur l'onglet Server, puis cliquez sur Profiles dans
la section Security. Dans la page Profiles, cliquez sur le bouton Create. Cliquez sur l'onglet
Password pour définir les limites du mot de passe.
Vous pouvez choisir les valeurs courantes de chaque paramètre dans une liste de valeurs (en
cliquant sur l'icône représentant une torche), ou entrer une valeur personnalisée.
Toutes les périodes sont exprimées en jours, mais elles peuvent également être indiquées sous
forme de fractions. Une journée comptant 1 440 minutes, 5/1 440 représente cinq minutes.
Vous pouvez également utiliser Enterprise Manager pour modifier des profils de mot de passe
existants.
Si le script utlpwdmg.sql a été exécuté, les fonctions VERIFY_FUNCTION et
VERIFY_FUNCTION_11G sont disponibles. Si vous avez créé votre propre fonction de
complexité, entrez son nom. Le nom de la fonction n'apparaît pas dans la liste Select. Si la
fonction produit des erreurs au moment de l'exécution, l'utilisateur n'a pas la possibilité de
modifier le mot de passe.
Supprimer un profil de mot de passe
Dans Enterprise Manager, vous ne pouvez pas supprimer un profil dont se servent des
utilisateurs. Toutefois, si vous supprimez un profil à l'aide de l'option CASCADE (par
exemple, dans SQL*Plus), tous les utilisateurs dotés de ce profil se voient affecter
automatiquement le profil DEFAULT.

Fonction prédéfinie de vérification des mots
de passe : VERIFY_FUNCTION_11G
La fonction VERIFY_FUNCTION_11G garantit les
caractéristiques suivantes du mot de passe :
• Il comprend au moins huit caractères.
• Il est différent du nom utilisateur, de ce nom inversé
ou de ce nom assorti d'un nombre.
• Il est différent du nom de base de données ou de ce nom
assorti d'un nombre.
• C'est une chaîne de caractères contenant au moins
un caractère alphabétique et un caractère numérique.

• Il doit comporter au moins trois lettres différentes
du précédent mot de passe.
Conseil : Utilisez cette fonction comme modèle pour
la création d'une fonction personnalisée de vérification
des mots de passe.
Fonction prédéfinie de vérification des mots de passe : VERIFY_FUNCTION_11G

Le serveur Oracle fournit deux fonctions de vérification de la complexité des mots de passe :
VERIFY_FUNCTION et VERIFY_FUNCTION_11g. Ces fonctions sont créées à l'aide du
script <oracle_home>/rdbms/admin/utlpwdmg.sql. La fonction
VERIFY_FUNCTION est destinée aux personnes qui préfèrent la fonction de mot de passe
qui était fournie avec les versions précédentes. La fonction de vérification de la complexité
des mots de passe doit être créée dans le schéma SYS. Elle peut servir de modèle pour la
définition d'une fonction de vérification personnalisée.
En plus de créer la fonction VERIFY_FUNCTION, le script utlpwdmg change le profil
DEFAULT via la commande ALTER PROFILE suivante :
ALTER PROFILE default LIMIT
PASSWORD_LIFE_TIME 180
PASSWORD_GRACE_TIME 7
PASSWORD_REUSE_TIME UNLIMITED
PASSWORD_REUSE_MAX UNLIMITED
FAILED_LOGIN_ATTEMPTS 10
PASSWORD_LOCK_TIME 1
PASSWORD_VERIFY_FUNCTION verify_function_11g;
Rappelez-vous que lorsque les utilisateurs sont créés, le profil DEFAULT leur est affecté, sauf
si un autre profil est indiqué.

Affecter des quotas aux utilisateurs
Les utilisateurs qui ne disposent pas du privilège système
UNLIMITED TABLESPACE doivent recevoir un quota pour
pouvoir créer des objets dans un tablespace.
Les quotas peuvent être les suivants :
• Une valeur précise exprimée en mégaoctets ou en kilo-octets
• La valeur Unlimited

Affecter des quotas aux utilisateurs

Un quota est une allocation d'espace dans un tablespace donné. Par défaut, un utilisateur ne
dispose d'aucun quota sur aucun des tablespaces. Trois options vous permettent d'affecter un
quota à un utilisateur sur un tablespace.
• Unlimited : Cette option permet à l'utilisateur d'employer tout l'espace disponible dans le
tablespace.
• Value : Une partie de l'espace est mise à la disposition de l'utilisateur, exprimée en kilo-
octets ou en mégaoctets. Cette valeur ne garantit cependant pas que l'espace est réservé
pour l'utilisateur. Elle peut être supérieure ou inférieure à l'espace actuellement
disponible dans le tablespace.
• Privilège système UNLIMITED TABLESPACE : Remplace chaque quota de tablespace
et accorde à l'utilisateur un quota illimité sur tous les tablespaces, y compris SYSTEM et
SYSAUX. Ce privilège doit être accordé avec précaution.
Remarque : Lorsque vous octroyez le rôle RESOURCE, le privilège UNLIMITED
TABLESPACE est inclus.
Vous ne devez pas accorder de quota aux utilisateurs sur les tablespaces SYSTEM et SYSAUX.
En général, seuls les utilisateurs SYS et SYSTEM peuvent créer des objets dans ces
tablespaces.
Vous n'avez pas besoin de quota pour un tablespace temporaire qui vous est affecté ni pour un
tablespace d'annulation, ni pour insérer, mettre à jour et supprimer des données dans une base
Oracle. Les seuls utilisateurs qui ont besoin de quotas sont les comptes propriétaires des
objets de base de données. En règle générale, ces comptes sont créés par le programme
d'installation de l'application. Seuls ces comptes nécessitent un quota. Les autres utilisateurs
de la base de données peuvent être autorisés à utiliser les objets sans quota.

Affecter des quotas aux utilisateurs (suite)
• L'instance Oracle vérifie le quota quand un utilisateur crée ou étend un segment.
• En ce qui concerne les activités affectées à un schéma utilisateur, seules celles qui utilisent de
l'espace dans un tablespace sont comptabilisées dans le quota. Les activités qui n'utilisent pas
l'espace disponible dans le tablespace désigné n'ont pas d'impact (par exemple, la création de
vues ou l'utilisation de tablespaces temporaires).
• Le quota est renouvelé lorsque les objets dont l'utilisateur est propriétaire sont supprimés à l'aide
de la clause PURGE ou purgés de la corbeille.

Appliquer le principe du moindre privilège
• Protégez le dictionnaire de données :

O7_DICTIONARY_ACCESSIBILITY=FALSE
• Révoquez les privilèges non nécessaires dans PUBLIC.

• Utilisez des listes de contrôle d'accès (ACL) pour contrôler
l'accès au réseau.
• Limitez les répertoires accessibles par les utilisateurs.
• Limitez les utilisateurs dotés de privilèges d'administration.
• Limitez l'authentification à distance auprès de la base de

données :
REMOTE_OS_AUTHENT=FALSE
Appliquer le principe du moindre privilège

Le principe du moindre privilège consiste à n'accorder à un utilisateur que les privilèges dont
il a réellement besoin pour effectuer une tâche de manière efficace. Cela réduit ses possibilités
d'afficher ou de modifier (involontairement ou par malveillance) des données qu'il n'est pas
autorisé à voir ou à modifier.
Protégez le dictionnaire de données : Le paramètre O7_DICTIONARY_ACCESSIBILITY
a par défaut la valeur FALSE. Vous ne devez pas autoriser sa modification sans une très
bonne raison car il empêche les utilisateurs dotés des privilèges système ANY TABLE
d'accéder aux tables de base du dictionnaire de données. Il garantit également que seul
l'utilisateur SYS peut se connecter en tant que SYSDBA.
Révoquez les privilèges non nécessaires dans PUBLIC : Plusieurs packages sont
extrêmement utiles pour les applications qui en ont besoin, mais ils nécessitent une
configuration appropriée pour être utilisés en toute sécurité. PUBLIC a le droit d'exécuter les
packages suivants : UTL_SMTP, UTL_TCP, UTL_HTTP et UTL_FILE. Dans Oracle
Database 11g, l'accès réseau est contrôlé par une liste de contrôle d'accès (ACL) qui peut être
configurée pour autoriser certains utilisateurs à accéder à des services réseau spécifiques. Par
défaut, l'accès réseau est refusé. Il ne peut être accordé que via la création d'une liste de
contrôle d'accès. L'accès aux fichiers via UTL_FILE est contrôlé à deux niveaux : au niveau
du système d'exploitation, à l'aide de permissions sur les fichiers et les répertoires, et au
niveau de la base de données, à l'aide d'objets DIRECTORY qui permettent d'accéder à des
répertoires spécifiques du système de fichiers. Un accès en lecture ou en lecture/écriture peut
être accordé à un utilisateur pour un objet DIRECTORY particulier. Les privilèges d'exécution
sur les autres packages PL/SQL doivent être contrôlés avec soin.

Appliquer le principe du moindre privilège (suite)
Les packages les plus puissants pouvant être utilisés à des fins malveillantes sont les suivants :
• UTL_SMTP : Permet d'envoyer des messages électroniques arbitraires en utilisant la base de
données en tant que serveur de messagerie SMTP (Simple Mail Transfer Protocol). Utilisez la
liste de contrôle d'accès (ACL) pour contrôler les ordinateurs accessibles par les différents
utilisateurs.
• UTL_TCP : Permet au serveur de base de données d'établir des connexions réseau sortantes vers
n'importe quel service réseau destinataire ou en attente. Par conséquent, des données arbitraires
peuvent être échangées entre le serveur de base de données et n'importe quel service réseau en
attente. Utilisez la liste ACL pour contrôler les accès.
• UTL_HTTP : Permet au serveur de base de données de demander et d'extraire des données via
HTTP. L'octroi de ce package à un utilisateur peut autoriser l'envoi de données à un site Web
malveillant par l'intermédiaire de panneaux HTML. Limitez l'accès à l'aide de la liste ACL.
• UTL_FILE : Si ce package est configuré de manière incorrecte, il permet l'accès au niveau texte
à n'importe quel fichier du système d'exploitation. S'il est configuré correctement, l'accès est

limité à des répertoires spécifiques.
Limitez l'accès aux répertoires du système d'exploitation : L'objet DIRECTORY de la base de
données permet aux DBA d'établir une correspondance entre des répertoires et des chemins de
système d'exploitation, et d'accorder à des utilisateurs des privilèges sur ces répertoires.
Limitez les utilisateurs dotés de privilèges d'administration : N'accordez pas aux utilisateurs de
base de données plus de privilèges que nécessaire. Vous ne devez pas accorder le rôle DBA aux
utilisateurs qui ne sont pas administrateurs. Pour implémenter le principe du moindre privilège,
limitez les types de privilège suivants :
• Octroi des privilèges système et objet
• Connexions dotées de privilèges SYS sur la base de données, tels que SYSDBA et SYSOPER
• Autres privilèges de type DBA, tels que DROP ANY TABLE
Limitez l'authentification à distance auprès de la base de données : Le paramètre
REMOTE_OS_AUTHENT a par défaut la valeur FALSE. Il ne doit pas être modifié, sauf s'il est
certain que tous les clients assurent une authentification appropriée des utilisateurs. Avec
l'introduction de la banque de mots de passe externe sécurisée (fournie avec Oracle Database 10g
version 2), rares sont les bonnes raisons d'autoriser l'authentification par les systèmes d'exploitation
distants.
Dans le processus d'authentification à distance :
• L'utilisateur de base de données est authentifié en externe.
• Le système distant authentifie l'utilisateur.
• L'utilisateur se connecte à la base de données sans authentification complémentaire.
Remarque : Veillez à tester vos applications complètement après avoir révoqué des privilèges.

Protéger les comptes dotés de privilèges
Méthodes permettant de protéger les comptes dotés de

privilèges :
• Utiliser un fichier de mots de passe sensibles à la casse
• Activer l'authentification forte pour les rôles d'administrateur

SYSDBA
Protéger les comptes dotés de privilèges

Les utilisateurs dotés de privilèges SYSDBA, SYSOPER ou SYSASM doivent
systématiquement être authentifiés. Lorsqu'il se connecte localement, l'utilisateur est
authentifié par le système d'exploitation local en tant que membre d'un groupe doté de
privilèges. S'il se connecte à distance, un fichier de mots de passe est utilisé pour authentifier
les utilisateurs dotés de privilèges. Si le fichier de mots de passe est configuré, il est vérifié en
premier lieu. Dans Oracle Database 11g, ces mots de passe sont sensibles à la casse. Oracle
Database 11g fournit d'autres méthodes qui rendent l'authentification des administrateurs à
distance plus sûre et qui centralisent l'administration de ces utilisateurs dotés de privilèges.
Quand une base de données est créée à l'aide de Database Configuration Assistant (DBCA), le
fichier de mots de passe respecte la casse. Si vous effectuez une mise à niveau depuis des
versions antérieures de la base de données, n'oubliez pas de configurer cette caractéristique
pour les connexions à distance :
orapwd file=orapworcl entries=5 ignorecase=N
Si vous pensez que le fichier de mots de passe risque d'être vulnérable ou que la maintenance
de plusieurs fichiers de mots de passe est une charge trop lourde, vous pouvez implémenter
une méthode d'authentification forte. L'option Oracle Advanced Security (ASO) est
obligatoire si vous voulez utiliser une authentification forte. Pour plus d'informations sur
l'authentification forte, reportez-vous au manuel Oracle Database Advanced Security
Administrator's Guide.

Quiz
Le principe du moindre privilège n'est pas suffisant pour

protéger la base de données Oracle.
1. Vrai
2. Faux

Réponse : 1

Quiz
Lorsque RESOURCE_LIMIT a la valeur par défaut FALSE,

les limites liées aux mots de passe des profils sont ignorées.
1. Vrai
2. Faux

Réponse : 2

Synthèse

• créer et gérer des comptes utilisateur de base de données :
– authentifier les utilisateurs
– affecter des zones de stockage par défaut (tablespaces)
• accorder et révoquer des privilèges
• créer et gérer des rôles
• créer et gérer des profils :
– implémenter des fonctionnalités standard de sécurité utilisant

des mots de passe
– contrôler l'utilisation des ressources par les utilisateurs

Administrer les utilisateurs
• créer un profil afin de limiter la consommation des
ressources
• créer deux rôles :
– HRCLERK
– HRMANAGER
• créer quatre utilisateurs :
– un manager et deux opérateurs

– un utilisateur de schéma pour l'exercice suivant

Gérer les accès simultanés aux données

Objectifs

• décrire le mécanisme de verrouillage et la gestion par
Oracle des accès simultanés aux données
• surveiller et résoudre les conflits de verrouillage


Verrous externes
• Les verrous externes empêchent plusieurs sessions de

modifier les mêmes données en même temps.
• Ils sont obtenus automatiquement au niveau le plus bas
possible pour une instruction donnée.
• Il n'y a pas d'escalade.

Transaction 1 Transaction 2
SQL> UPDATE employees SQL> UPDATE employees
2 SET salary=salary+100 2 SET salary=salary*1.1
3 WHERE employee_id=100; 3 WHERE employee_id=100;
Verrous externes
Avant que la base n'autorise une session à modifier des données, la session doit d'abord
verrouiller ces données. Un verrou externe (lock) accorde à la session le contrôle exclusif des
données, de sorte qu'aucune autre transaction ne puisse faire de modification jusqu'à la
libération du verrou.
Les transactions peuvent verrouiller certaines lignes de données, plusieurs lignes ou même des
tables entières. Oracle Database prend en charge le verrouillage manuel et le verrouillage
automatique. Les verrous activés automatiquement choisissent toujours le niveau de
verrouillage le plus bas possible, afin de limiter les conflits potentiels avec d'autres
transactions.
Remarque : L'instance Oracle utilise des verrous externes de plusieurs types pour maintenir
la cohérence interne. Ce cours s'intéresse uniquement au verrouillage qui permet de protéger
les lignes et les tables.

Mécanisme de verrouillage
• Haut niveau de simultanéité d'accès aux données :
– Verrous au niveau ligne pour les insertions, les mises à jour et
les suppressions
– Aucun verrou externe nécessaire pour les interrogations
• Gestion automatique des files d'attente
• Verrous détenus jusqu'à la fin de la transaction (avec
l'opération COMMIT ou ROLLBACK)
Exemple
Supposons que les lignes correspondant aux valeurs 100 et 101 de
employee_id résident dans le même bloc :

2 SET salary=salary+100 2 SET salary=salary*1.1
3 WHERE employee_id=100; 3 WHERE employee_id=101;
Mécanisme de verrouillage
Le mécanisme de verrouillage est conçu pour fournir le degré maximal de simultanéité
d'accès aux données dans la base. Les transactions qui modifient des données acquièrent des
verrous externes (locks) au niveau ligne plutôt qu'au niveau bloc ou table. Les modifications
portant sur des objets (telles que les déplacements de tables) obtiennent des verrous externes
au niveau objet, plutôt qu'au niveau de la base de données complète ou du schéma.
Les interrogations de données ne nécessitent pas de verrous externes. Une interrogation
réussit même si quelqu'un a verrouillé les données, et elle renvoie toujours la valeur originale
avant verrouillage, régénérée à partir des informations d'annulation.
Lorsque plusieurs transactions doivent verrouiller la même ressource, le verrou externe est
obtenu par la première transaction qui en fait la demande. Les autres transactions attendent
jusqu'à la fin de la première transaction. Le mécanisme de mise en file d'attente est
automatique et ne nécessite aucune intervention de l'administrateur.
Tous les verrous externes sont libérés lorsque les transactions sont terminées (c'est-à-dire
lorsqu'une opération COMMIT ou ROLLBACK est exécutée). Si une transaction échoue, le
processus en arrière-plan qui annule automatiquement les modifications apportées par celle-ci
libère également tous les verrous qu'elle détient.

Simultanéité d'accès aux données
Heure : Transaction 1 UPDATE hr.employees

SET salary=salary+100
WHERE employee_id=100;
Transaction 2 UPDATE hr.employees

09:00:00 Transaction 3 UPDATE hr.employees

... ...
Transaction x UPDATE hr.employees
WHERE employee_id=xxx;
Simultanéité d'accès aux données

Le mode de verrouillage par défaut est un verrouillage détaillé au niveau ligne. Différentes
transactions peuvent mettre à jour différentes lignes de la même table sans interférer les unes
avec les autres.
Mais Oracle Database prend également en charge le verrouillage manuel à des niveaux
supérieurs, si nécessaire :
SQL> LOCK TABLE employees IN EXCLUSIVE MODE;
Table(s) Locked.
Avec l'instruction ci-dessus, toute autre transaction qui tente de mettre à jour une ligne dans la
table verrouillée doit attendre que la transaction ayant généré la demande de verrouillage soit
terminée. L'option EXCLUSIVE correspond au mode de verrouillage le plus strict. Vous
disposez également des modes de verrouillage suivants :
• ROW SHARE : Permet des accès simultanés à la table verrouillée, mais empêche les
sessions de verrouiller l'ensemble de la table pour un accès exclusif.
• ROW EXCLUSIVE : Identique au mode ROW SHARE, mais empêche également le
verrouillage en mode partagé (SHARE). Les verrous externes ROW EXCLUSIVE sont
obtenus automatiquement lors de la mise à jour, de l'insertion ou de la suppression de
données. Ils autorisent plusieurs processus de lecture, mais un seul processus d'écriture.
• SHARE : Permet les interrogations simultanées, mais empêche les mises à jour de la table
verrouillée. Un verrou SHARE est nécessaire (et automatiquement demandé) pour la
création d'un index sur une table. La création d'index en ligne nécessite toutefois un
verrou ROW SHARE qui est utilisé lors de la construction de l'index.

Simultanéité d'accès aux données (suite)
Les verrous externes de type Share autorisent plusieurs processus de lecture, mais aucun
processus d'écriture. Ils sont également utilisés de manière transparente lors de la suppression ou
de la mise à jour de lignes dans une table parent qui possède une table enfant avec des
contraintes de clé étrangère sur la table parent.
• SHARE ROW EXCLUSIVE : Permet l'interrogation d'une table entière et autorise d'autres
utilisateurs à interroger des lignes de la table, mais empêche les autres utilisateurs de verrouiller
la table en mode SHARE ou de mettre à jour des lignes.
• EXCLUSIVE : Autorise les interrogations sur la table verrouillée, mais empêche toute autre
activité sur cette table. Un verrou externe EXCLUSIVE est nécessaire pour supprimer une table.
Comme pour n'importe quelle demande de verrou externe, les instructions de verrouillage manuel
attendent que toutes les sessions détenant déjà des verrous (ou ayant précédemment demandé des
verrous) aient libéré ces derniers. La commande LOCK accepte un argument spécial qui contrôle le
comportement d'attente NOWAIT.

L'argument NOWAIT vous redonne immédiatement le contrôle si la table désignée est déjà
verrouillée par une autre session.
SQL> LOCK TABLE hr.employees IN SHARE MODE NOWAIT;
LOCK TABLE hr.employees IN SHARE MODE NOWAIT
*
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified
Il est généralement inutile de verrouiller manuellement des objets. Le mécanisme de verrouillage
automatique fournit la simultanéité d'accès aux données nécessaires pour la plupart des applications.
Oracle recommande d'éviter le recours aux verrous manuels, notamment lors du développement
d'applications. Des niveaux de verrouillage inutilement élevés peuvent entraîner une réduction
importante des performances.

Verrous LMD
2 SET salary=salary*1.1 2 SET salary=salary*1.1
3 WHERE employee_id= 107; 3 WHERE employee_id= 106;
1 row updated. 1 row updated.
Chaque transaction LMD doit acquérir deux verrous :

• Un verrou sur ligne de type EXCLUSIVE pour les lignes
mises à jour

• Un verrou sur table (TM) en mode ROW EXCLUSIVE (RX)
pour la table contenant les lignes mises à jour
Verrous LMD
Chaque transaction LMD acquiert deux verrous :
• Un verrou sur ligne de type EXCLUSIVE pour les lignes mises à jour.
• Un verrou sur table (TM) en mode ROW EXCLUSIVE (RX) pour la table mise à jour.
Cela permet d'empêcher une autre session de verrouiller la table entière (par exemple,
pour la supprimer ou la vider) pendant que la modification est apportée. Ce mode est
également appelé "subexclusive" (SX).
Le verrou ROW EXCLUSIVE sur la table empêche les commandes LDD de modifier les
métadonnées du dictionnaire au milieu d'une transaction non validée. Cela préserve l'intégrité
du dictionnaire et la cohérence en lecture pendant toute la durée d'une transaction.

Mécanisme de mise en file d'attente
Le mécanisme de mise en file d'attente effectue le suivi :

• des sessions en attente de verrous externes
• du mode de verrouillage demandé
• de l'ordre dans lequel les sessions ont demandé le verrou

Mécanisme de mise en file d'attente

Les demandes de verrous externes (locks) sont automatiquement mises en file d'attente. Dès
que la transaction détenant un verrou est terminée, la session suivante de la file reçoit le
verrou.
Le mécanisme de mise en file d'attente effectue le suivi de l'ordre dans lequel les verrous sont
demandés, ainsi que le suivi du mode de verrouillage demandé.
Les sessions qui détiennent déjà un verrou peuvent demander la conversion de ce verrou sans
retourner à la fin de la file d'attente. Par exemple, supposons qu'une session détienne un
verrou sur table de type SHARE. Elle peut demander la conversion de ce verrou en un verrou
de type EXCLUSIVE. Si aucune autre transaction ne détient de verrou de type EXCLUSIVE
ou SHARE sur la table, elle obtient un verrou de type EXCLUSIVE sans avoir à patienter de
nouveau dans la file d'attente.
Remarque : Le mécanisme de mise en file d'attente distingue deux catégories de session en
attente de verrou : les sessions en attente sans propriété partagée et les sessions en attente avec
propriété partagée dont l'élévation du niveau de verrouillage n'est pas souhaitée. Les sessions
appartenant à cette dernière catégorie sont appelées convertisseurs. Elles priment toujours sur
les sessions en attente normales même si elles attendent depuis moins longtemps.

Conflits de verrouillage
Transaction 1 Heure Transaction 2
UPDATE employees SET 9:00:00 UPDATE employees SET
salary=salary+100 WHERE salary=salary+100 WHERE
employee_id=100; employee_id=101;
1 row updated. 1 row updated.
UPDATE employees SET 9:00:05 SELECT sum(salary) FROM
COMMISION_PCT=2 WHERE employees;
employee_id=101; SUM(SALARY)
La session patiente en file -----------
d'attente en raison d'un conflit 692634
de verrouillage.
La session est toujours en Nombreuses opérations de

attente. 16:30:00 sélection, d'insertion, de mise à
jour et de suppression au cours
des dernières 7,5 heures, mais
pas de validation ni d'annulation.
1 row updated. 16:30:01 commit;
La session se poursuit.
Conflits de verrouillage
Les conflits de verrouillage sont fréquents, mais ils sont généralement résolus avec le temps
ou via le mécanisme de mise en file d'attente. Dans de rares cas, un conflit de verrouillage
peut nécessiter l'intervention de l'administrateur. Dans l'exemple de la diapositive ci-dessus, la
transaction 2 obtient un verrou externe sur une ligne unique à 9:00:00 et l'utilisateur oublie de
valider la transaction, laissant ainsi le verrou en place. A 9:00:05, la transaction 1 tente de
mettre à jour la table entière, opération qui nécessite un verrou sur toutes les lignes. La
transaction 1 est bloquée par la transaction 2 jusqu'à la validation de cette dernière, à
16:30:01.
L'utilisateur qui tente d'effectuer la transaction 1 est amené à demander l'aide de
l'administrateur, qui doit détecter et résoudre le conflit.

Causes possibles des conflits de verrouillage
• Modifications non validées

• Transactions longues
• Niveaux de verrouillage inutilement élevés

Causes possibles des conflits de verrouillage

Le plus souvent, les conflits de verrouillage sont dus à une modification non validée, mais il
existe d'autres causes possibles :
• Transactions longues : De nombreuses applications utilisent le traitement par lots pour
effectuer des mises à jour en masse. Ces traitements batch sont généralement planifiés
pendant une période de faible activité des utilisateurs (ou sans activité), mais il peut
arriver qu'ils ne soient pas terminés à l'issue de cette période. Les conflits de verrouillage
se produisent fréquemment lorsque le traitement des transactions et le traitement par lots
sont effectués simultanément.
• Niveaux de verrouillage inutilement élevés : Les bases de données n'admettent pas
toutes le verrouillage au niveau ligne (Oracle a inclus la prise en charge des verrous au
niveau ligne en 1988, dans la version 6). Certaines bases nécessitent donc toujours un
verrouillage au niveau page ou au niveau table. Les développeurs qui écrivent des
applications destinées à s'exécuter sur de nombreuses bases différentes appliquent
souvent des niveaux de verrouillage très élevés qui forcent Oracle Database à se
comporter de la même façon que les systèmes de base de données les moins performants.
En outre, les développeurs qui débutent sur Oracle écrivent parfois du code avec des
niveaux de verrouillage plus élevés que ne l'exige Oracle Database.

Détecter les conflits de verrouillage
Sélectionnez Blocking Sessions dans la page Performance.

Cliquez sur le lien Session ID afin d'afficher des informations
sur la session qui a provoqué le verrouillage, y compris
l'instruction SQL concernée.
Détecter les conflits de verrouillage

Utilisez la page Blocking Sessions d'Enterprise Manager pour localiser les conflits de
verrouillage. Les demandes de verrous externes qui provoquent des conflits sont indiquées de
façon hiérarchique. La session détenant le verrou figure en haut. Elle est suivie des sessions
qui attendent ce verrou.
Pour chaque session impliquée dans le conflit, le nom utilisateur, l'ID de session et la durée
d'attente de la session (en secondes) sont indiqués. Procédez à une hiérarchisation
descendante sur l'ID de session afin de voir les instructions SQL actuellement exécutées ou
demandées par la session.
Par ailleurs, le moniteur ADDM (Automatic Database Diagnostic Monitor) détecte
automatiquement les conflits de verrouillage et peut vous informer des verrouillages
inefficaces.

Résoudre les conflits de verrouillage
Pour résoudre un conflit de verrouillage :

• Provoquez la validation ou l'annulation de la transaction par
la session détenant le verrou.
• Mettez fin à la session détenant le verrou (en dernier
recours).


La résolution d'un conflit de verrouillage passe par la libération du verrou détenu par la
session. Le meilleur moyen d'y parvenir consiste à contacter l'utilisateur et à lui demander de
mettre fin à la transaction.
En cas d'urgence, l'administrateur peut mettre fin à la session détenant le verrou en cliquant
sur le bouton Kill Session. N'oubliez pas que lorsqu'une session est fermée, tout le travail de
la transaction en cours est perdu (la transaction est annulée (roll back)). Un utilisateur dont la
session est fermée doit se reconnecter et effectuer de nouveau tout le travail réalisé depuis la
dernière validation (commit) de la session.
Les utilisateurs dont les sessions ont été fermées reçoivent l'erreur suivante lors de leur
tentative suivante d'exécution d'une instruction SQL :
ORA-03135: connection lost contact
Remarque : La fonction PMON d'arrêt de session peut fermer automatiquement les sessions
qui ont dépassé le délai d'inactivité, par le biais de profils ou de Resource Manager.

à l'aide d'instructions SQL
Il est possible de déterminer la session bloquante et de la

fermer à l'aide d'instructions SQL.
SQL> select SID, SERIAL#, USERNAME

1 from V$SESSION where SID in
(select BLOCKING_SESSION from V$SESSION)
Résultat :

2 SQL> alter system kill session '144,8982' immediate;
Résoudre les conflits de verrouillage à l'aide d'instructions SQL

Les manipulations de session, comme la plupart des tâches réalisées dans Enterprise Manager,
peuvent également s'effectuer par le biais d'instructions SQL. La table V$SESSION contient
des détails sur toutes les sessions connectées. La valeur de BLOCKING_SESSION est l'ID de
la session bloquante. Si vous exécutez une interrogation afin d'obtenir les valeurs SID et
SERIAL# (où SID correspond à un ID de session bloquante), vous disposerez des
informations nécessaires pour réaliser l'opération kill session.
Remarque : Vous pouvez utiliser Database Resource Manager pour déconnecter
automatiquement les sessions qui en bloquent d'autres et qui sont inactives.

"Verrous mortels"
UPDATE employees UPDATE employees

SET salary = salary x 1.1 9:00 SET manager = 1342
WHERE employee_id = 1000; WHERE employee_id = 2000;
UPDATE employees UPDATE employees
SET salary = salary x 1.1 9:15 SET manager = 1342
WHERE employee_id = 2000; WHERE employee_id = 1000;

ORA-00060:
Deadlock detected while 9:16
waiting for resource
"Verrous mortels"
Un "verrou mortel" (deadlock) est un type particulier de conflit de verrouillage. Il se produit
lorsque plusieurs sessions attendent des données verrouillées par l'une d'elles. Etant donné que
chaque session attend l'autre, aucune d'entre elles ne peut terminer la transaction afin de
résoudre le conflit.
Oracle Database détecte automatiquement les "verrous mortels" et met fin à l'instruction en
générant une erreur. En réponse à cette erreur, il convient de réaliser une opération de
validation (commit) ou d'annulation (rollback), ce qui a pour effet de libérer tous les verrous
de la session et de permettre à l'autre session de poursuivre sa transaction.
Dans l'exemple de la diapositive ci-dessus, la transaction 1 doit être validée ou annulée pour
résoudre l'erreur "deadlock detected". Si elle est validée, la deuxième mise à jour devra être
soumise à nouveau pour terminer la transaction. Si elle est annulée, les deux instructions
devront être soumises à nouveau pour effectuer la transaction.

Quiz
Le mode de verrouillage par défaut est un verrouillage détaillé

au niveau ligne.
1. Vrai
2. Faux

Réponse : 1

Quiz
Lorsqu'un "verrou mortel" (deadlock) se produit, la base de

données Oracle effectue automatiquement les actions suivantes :
1. Elle attend 300 secondes avant de mettre fin aux deux
sessions.
2. Elle met fin à une instruction avec un message d'erreur dans
une seule session.
3. Elle met fin aux instructions avec un message d'erreur dans
les deux sessions.
4. Elle ne fait rien par défaut et laisse le DBA traiter le

problème.
Réponse : 2

Synthèse

• décrire le mécanisme de verrouillage et la gestion par
Oracle des accès simultanés aux données
• surveiller et résoudre les conflits de verrouillage


Gérer les données et la simultanéité
d'accès aux données
• identifier les conflits de verrouillage
• résoudre les conflits de verrouillage


Gérer les données d'annulation

Objectifs

• décrire les instructions LMD et les données d'annulation
• surveiller et administrer les données d'annulation
• décrire les différences entre les données d'annulation et les
données de journalisation
• configurer la période de conservation des informations
d'annulation
• garantir la conservation des informations d'annulation

• utiliser la fonction de conseil Undo Advisor

Données d'annulation
Les données d'annulation :
• sont une copie des données d'origine avant une
modification
• sont capturées pour toute transaction qui modifie des
données
• sont conservées au minimum jusqu'à la fin de la transaction
• permettent :
– les opérations d'annulation
– des interrogations cohérentes en lecture

– les opérations Oracle Flashback Query,
Oracle Flashback Transaction et Oracle
Flashback Table
– la récupération suite à l'échec
de transactions Utilisateur
Données d'annulation (undo)

La base de données Oracle enregistre les anciennes valeurs (données d'annulation) lorsqu'un
processus modifie des données. Ces données sont stockées telles qu'elles étaient avant leur
modification. La capture des données d'annulation permet d'annuler (rollback) les données qui
ne sont pas validées (commit). Les données d'annulation permettent la prise en charge des
interrogations cohérentes en lecture et des interrogations flashback. Elles peuvent également
être utilisées pour effectuer des flashbacks de transactions et de tables.
Les interrogations cohérentes en lecture fournissent des résultats qui sont conformes aux
données telles qu'elles apparaissaient au début de l'interrogation. Pour qu'une interrogation
cohérente en lecture réussisse, les informations d'origine doivent être présentes sous forme
d'informations d'annulation. Si les données d'origine ne sont plus disponibles, vous recevez un
message d'erreur "Snapshot too old" (ORA-01555). Tant que ces informations sont
conservées, la base Oracle peut recréer les données pour répondre aux interrogations
cohérentes en lecture.
Les interrogations flashback demandent, dans un but précis, une version des données telles
qu'elles apparaissaient à un instant passé. Tant que les informations d'annulation
correspondant à cet instant sont conservées, les interrogations flashback peuvent être
exécutées. Oracle Flashback Transaction utilise les données d'annulation pour créer des
transactions de compensation en vue d'annuler une transaction et ses transactions
dépendantes. Oracle Flashback Table permet de récupérer une table dans l'état qu'elle
présentait à un moment précis du passé.

Données d'annulation (suite)
Les données d'annulation sont également utilisées pour la récupération suite à l'échec de transactions.
Une transaction échoue lorsqu'une session utilisateur se termine de façon anormale (suite à des
erreurs réseau ou à la défaillance de l'ordinateur client, par exemple), avant que l'utilisateur ait décidé
de valider ou d'annuler la transaction. Les transactions peuvent également échouer suite à une
défaillance de l'instance ou à l'exécution d'une commande SHUTDOWN ABORT.
En cas d'échec d'une transaction, le comportement le plus sûr est adopté. La base de données Oracle
supprime toutes les modifications effectuées par un utilisateur et restaure ainsi les données d'origine.
Les informations d'annulation (undo) sont conservées pour chaque transaction, au moins jusqu'à la
fin de la transaction, laquelle se produit de l'une des manières suivantes :
• L'utilisateur annule la transaction.
• L'utilisateur termine la transaction.
• L'utilisateur exécute une instruction LDD telle que CREATE, DROP, RENAME ou ALTER. Si la
transaction en cours contient des instructions LMD, la base de données commence par la valider

(commit), puis elle exécute et valide l'instruction LDD en tant que nouvelle transaction.
• La session utilisateur se termine de façon anormale (transaction annulée).
• La session utilisateur se termine de façon normale et l'utilisateur quitte la session (transaction
validée).
La quantité de données d'annulation conservées et leur durée de conservation dépendent du degré
d'activité et de la configuration de la base.
Remarque : Oracle Flashback Transaction tire parti des fichiers de journalisation en ligne (online
redo logs) pour extraire les instructions SQL d'annulation appropriées à exécuter. Cette fonctionnalité
utilise les informations d'annulation à titre de limite temporelle artificielle uniquement, en vue de
déterminer le moment du début d'extraction des informations de journalisation pour la transaction
cible si aucune heure de début de transaction n'est fournie dans l'appel de la transaction Flashback.

Transactions et données d'annulation
Segment
d'annulation
Données Données "anciennes"
du cache
du tablespace d'annulation
de tampons
Opérations LMD Tampon de Informations nouvelles sur

UPDATE journa-
les modifications dans
Fichiers de
lisation journalisation
les fichiers de journalisation

• Chaque transaction est affectée à un seul segment
d'annulation.
• Un segment d'annulation peut être utilisé par plusieurs
transactions simultanément.
Transactions et données d'annulation

Lorsqu'une transaction commence, elle est affectée à un segment d'annulation. Pendant sa
durée de vie, lorsque des données sont modifiées, les valeurs d'origine (avant modification)
sont copiées dans le segment d'annulation. Vous pouvez déterminer quelles transactions sont
affectées à quels segments d'annulation en examinant la vue dynamique des performances
V$TRANSACTION.
Les segments d'annulation sont des segments spécialisés créés automatiquement par l'instance
pour la prise en charge des transactions. Comme n'importe quel segment, ils sont constitués
d'extents (ensembles de blocs contigus), eux-mêmes composés de blocs de données. La taille
des segments d'annulation augmente et diminue automatiquement. Les segments d'annulation
jouent ainsi le rôle de mémoire tampon (buffer) de stockage réutilisable pour les transactions
qui leur sont affectées.
Les transactions insèrent les extents dans les segments d'annulation jusqu'à la fin de la
transaction ou jusqu'à ce que tout l'espace soit consommé. Si un extent est rempli et que
davantage d'espace est nécessaire, la transaction utilise l'espace de l'extent suivant du
segment. Une fois tous les extents consommés, la transaction revient au premier extent ou
demande à ce qu'un nouvel extent soit alloué au segment d'annulation.
Remarque : Les opérations LDD et LMD en parallèle peuvent forcer une transaction à
utiliser plusieurs segments d'annulation. Pour plus d'informations sur l'exécution d'instructions
LMD en parallèle, reportez-vous au manuel Oracle Database Administrator's Guide.

Stockage des informations d'annulation
Les informations d'annulation sont stockées dans des

segments d'annulation, lesquels sont à leur tour stockés dans
un tablespace d'annulation. Les tablespaces d'annulation :
• sont utilisés uniquement pour les segments d'annulation
• présentent des exigences particulières en termes de
récupération
• sont associés à une seule instance
• nécessitent qu'un seul tablespace d'annulation soit
accessible en écriture pour une instance donnée à un

instant précis
Stockage des informations d'annulation

Les segments d'annulation ne peuvent exister que dans une forme particulière de tablespace,
appelée tablespace d'annulation. (Vous ne pouvez pas créer d'autres types de segment, tels que
des tables, dans le tablespace d'annulation.)
L'assistant DBCA (Database Configuration Assistant) crée automatiquement un tablespace
d'annulation smallfile, mais vous pouvez également créer un tablespace d'annulation bigfile.
Toutefois, dans un environnement OLTP (Traitement de transactions en ligne) volumineux
traitant simultanément un grand nombre de transactions courtes, il peut y avoir contention au
niveau de l'en-tête de fichier. Un tablespace d'annulation stocké dans plusieurs fichiers de
données peut résoudre ce problème potentiel.
Une base de données peut comporter plusieurs tablespaces d'annulation mais, à un instant donné,
un seul d'entre eux peut être désigné comme le tablespace d'annulation en cours pour une
instance.
Les segments d'annulation sont créés automatiquement et appartiennent toujours à l'utilisateur
SYS. Etant donné que les segments d'annulation jouent le rôle de mémoire tampon réutilisable,
chaque segment comprend au minimum deux extents (ensembles de blocs contigus). Le nombre
maximal d'extents par défaut dépend de la taille des blocs de base de données, mais il est très
élevé (32 765 pour une taille de bloc de 8 Ko).
Les tablespaces d'annulation sont des tablespaces permanents gérés localement, avec allocation
automatique d'extents. Ils sont gérés automatiquement par la base de données.
Comme les données d'annulation sont nécessaires pour la récupération suite à l'échec d'une
transaction (par exemple en cas de défaillance d'une instance), les tablespaces d'annulation ne
peuvent être récupérés que lorsque l'instance est en mode MOUNT. Pour consulter les remarques
relatives à la récupération des tablespaces d'annulation, reportez-vous au chapitre intitulé
"Procéder à une récupération de la base de données".
Données d'annulation et données de journalisation
Annulation Données de journalisation
Enregistrement de Mode d'annulation d'une Mode de reproduction

modification d'une modification
Utilisation pour Annulation, cohérence en Réimplémentation des
lecture, flashback modifications de la base
de données
Stockage dans Segments d'annulation Fichiers de journalisation
Protection contre Lectures incohérentes Pertes de données
dans les systèmes
multiutilisateurs

Segment
d'annulation
Fichiers de
journalisation
Données d'annulation et données de journalisation

Les données d'annulation (undo) et les données de journalisation (redo) sont semblables à
première vue, mais elles remplissent des fonctions différentes. Les données d'annulation
permettent, si nécessaire, d'annuler une modification. C'est ce qui se produit pour les
opérations de cohérence en lecture et d'annulation (rollback). Les données de journalisation
permettent, quant à elles, d'appliquer à nouveau les modifications qui ont été perdues pour une
raison quelconque. Les modifications des blocs d'annulation sont également consignées dans
le fichier de journalisation (redo log).
Le processus de validation (commit) impose de vérifier que les modifications apportées dans
la transaction ont été écrites dans le fichier de journalisation. Ce fichier constitue un
emplacement de stockage persistant sur le disque (contrairement à la mémoire). En outre, il
est généralement multiplexé. Il existe donc plusieurs copies des données de journalisation sur
le disque. Même si les modifications n'ont pas encore été écrites dans les fichiers de données
où les blocs de la table sont effectivement stockés, leur écriture dans le fichier de
journalisation garantit la cohérence de la base.
Si une coupure de courant se produit juste avant l'écriture des modifications validées dans les
fichiers de données, cela ne pose aucun problème puisque la transaction a été validée
(commit). Lorsque le système redémarre, il peut réimplémenter les enregistrements de
journalisation qui n'avaient pas encore été répercutés dans les fichiers de données au moment
de la coupure.

Gérer les informations d'annulation
Gestion automatique des annulations :
• Gestion complètement automatisée des données et du volume
d'annulation dans un tablespace d'annulation dédié
• Utilisation dans toutes les sessions
• Réglage automatique dans les tablespaces en auto-extension
(AUTOEXTEND) pour les besoins des interrogations de longue
durée
• Réglage automatique dans les tablespaces de taille fixe pour une
conservation optimale
Tâches du DBA pour la prise en charge des opérations Flashback :

• Configurer la période de conservation des informations
d'annulation
• Passer à un tablespace d'annulation de taille fixe
• Eviter la consommation excessive d'espace et les erreurs
"Snapshot too old"
Gérer les informations d'annulation

La base de données Oracle assure la gestion automatique des annulations (AUM) : un
mécanisme complètement automatisé permet de gérer les informations et le volume
d'annulation dans un tablespace d'annulation dédié pour toutes les sessions. Le système se
règle automatiquement pour fournir une conservation optimale des informations d'annulation.
Plus précisément, la période de conservation des informations d'annulation pour les
tablespaces en auto-extension est réglée sur une durée légèrement supérieure à celle de
l'interrogation active la plus longue. Pour les tablespaces d'annulation de taille fixe, la base de
données effectue un réglage dynamique en vue d'assurer une conservation optimale.
La gestion automatique des annulations est l'option par défaut dans Oracle Database 11g (et
les versions postérieures). La gestion manuelle des annulations est prise en charge pour des
raisons de compatibilité descendante avec Oracle8i et les versions antérieures, mais elle
nécessite davantage d'interventions du DBA. En mode manuel, le volume d'annulation n'est
pas géré via un tablespace d'annulation, mais au moyen de segments d'annulation (rollback
segments).
Remarque : Oracle recommande fortement d'utiliser la gestion automatique des annulations.
Bien que la base de données Oracle utilise par défaut la gestion automatique des données et
du volume d'annulation, vous pouvez avoir besoin d'intervenir manuellement si votre base fait
appel à des opérations Flashback. L'administration des informations d'annulation doit éviter la
consommation excessive d'espace et les erreurs "Snapshot too old".

Configurer la période de conservation
des informations d'annulation
Le paramètre UNDO_RETENTION indique (en secondes) la durée

de conservation des informations d'annulation déjà validées. Vous
ne devez configurer ce paramètre que dans les cas suivants :
• L'option AUTOEXTEND du tablespace d'annulation est activée.
• Vous souhaitez définir la période de conservation des
informations d'annulation pour les objets LOB.
• Vous souhaitez garantir la conservation des données.

DBA
Configurer la période de conservation des informations d'annulation

Le paramètre d'initialisation UNDO_RETENTION indique (en secondes) la valeur minimale
de la période de conservation des informations d'annulation. Pour un tablespace d'annulation
en auto-extension, définissez une valeur égale à la durée de l'opération Flashback la plus
longue envisagée. Pour ce type de tablespace, le système conserve les informations
d'annulation pendant une durée au moins égale à la valeur de ce paramètre. Il règle
automatiquement la période de conservation de manière à répondre aux besoins des
interrogations en matière d'annulation. Il peut toutefois arriver que cette période de
conservation réglée automatiquement ne soit pas suffisante pour vos opérations Flashback.
Pour les tablespaces d'annulation de taille fixe, le système adopte automatiquement une
période de conservation optimale en fonction de la taille du tablespace et de l'historique
d'utilisation. Il ignore le paramètre UNDO_RETENTION, sauf si la fonction de garantie de la
période de conservation des informations d'annulation est activée. En résumé, le paramètre
UNDO_RETENTION est utilisé pour la gestion automatique des annulations dans les trois cas
mentionnés dans la diapositive ci-dessus.
Dans tous les autres cas, ce paramètre est ignoré.

Configurer la période de conservation des informations d'annulation (suite)
Les informations d'annulation (undo) sont divisées en trois catégories :
• Informations d'annulation non validées (actives) : Elles correspondent à une transaction en
cours d'exécution. Elles sont nécessaires au cas où l'utilisateur souhaiterait annuler (rollback) la
transaction ou en cas d'échec de celle-ci. Les informations d'annulation non validées ne sont
jamais écrasées par d'autres.
• Informations d'annulation validées (non expirées) : Ces informations ne sont plus nécessaires
pour une transaction en cours d'exécution, mais elles le sont pour la prise en charge de la période
de conservation. Elles sont également appelées informations d'annulation "non expirées". Les
informations d'annulation validées sont conservées dès lors que cela n'entraîne pas l'échec d'une
transaction active en raison d'un manque d'espace.
• Informations d'annulation expirées : Ces informations ne sont plus nécessaires pour une
transaction en cours d'exécution. Elles sont remplacées lorsqu'une transaction active a besoin
d'espace.

Garantir la période de conservation des
informations d'annulation
SQL> ALTER TABLESPACE undotbs1 RETENTION GUARANTEE;
Période garantie :
15 minutes
Données d'annulation
stockées dans le
tablespace d'annulation

Les instructions SELECT Une transaction échoue si elle génère
dont l'exécution prend 15 minutes trop d'informations d'annulation
ou moins sont toujours satisfaites. par rapport à l'espace disponible.
Remarque : Cet exemple se fonde sur un paramètre UNDO_RETENTION
de 900 secondes (15 minutes).
Garantir la période de conservation des informations d'annulation

Le comportement par défaut consiste à écraser les informations d'annulation des transactions
validées qui n'ont pas encore expiré dès lors qu'il faut éviter l'échec d'une transaction en raison
d'un manque d'espace.
Ce comportement peut toutefois être modifié via la garantie de la période de conservation.
Lorsque la période de conservation des informations d'annulation est garantie, les paramètres
de conservation sont appliqués même si cela entraîne l'échec d'une transaction.
RETENTION GUARANTEE est un attribut de tablespace et non un paramètre d'initialisation. Il
ne peut être modifié que par le biais d'instructions SQL exécutées à partir de la ligne de
commande. La syntaxe permettant de modifier un tablespace d'annulation afin de garantir la
période de conservation des informations d'annulation est la suivante :
SQL> ALTER TABLESPACE undotbs1 RETENTION GUARANTEE;
Pour rétablir le comportement par défaut, utilisez la commande suivante :
SQL> ALTER TABLESPACE undotbs1 RETENTION NOGUARANTEE;
La garantie de la période de conservation des informations d'annulation s'applique
uniquement aux tablespaces d'annulation. Toute tentative d'appliquer cette fonction à un autre
type de tablespace provoque l'erreur suivante :
SQL> ALTER TABLESPACE example RETENTION GUARANTEE;
ERROR at line 1:
ORA-30044: 'Retention' can only specified for undo
tablespace

Passer à un tablespace d'annulation
de taille fixe
Raisons :
• Prendre en charge les opérations
Flashback
• Limiter l'extension du tablespace
d'annulation
Workflow :
1. Exécutez une charge globale normale.
2. Le mécanisme de réglage automatique établit la taille
minimale requise.

3. (Facultatif) Utilisez Undo Advisor pour calculer la taille
requise en prévision de l'extension future.
4. (Facultatif) Configurez le tablespace d'annulation avec
une taille fixe.
Passer à un tablespace d'annulation de taille fixe

Vous pouvez être amené à passer à un tablespace d'annulation de taille fixe pour deux
raisons : prendre en charge les opérations Flashback (si vous prévoyez l'utilisation future des
informations d'annulation) ou empêcher le tablespace d'atteindre une taille excessive.
Si vous prenez cette décision, vous devez choisir une taille assez grande pour éviter les deux
erreurs suivantes :
• Echec d'instructions LMD (dû à un manque d'espace pour les données d'annulation des
nouvelles transactions)
• Erreurs "Snapshot too old" (dues à l'insuffisance des données d'annulation pour la
cohérence en lecture)
Oracle recommande d'exécuter l'intégralité d'une charge globale normale pour permettre au
tablespace d'annulation d'atteindre la taille minimale requise. Les statistiques collectées
automatiquement comprennent la durée de l'interrogation la plus longue à s'exécuter et le taux
de génération des informations d'annulation. Il est conseillé de calculer la taille minimale du
tablespace d'annulation en fonction de ces statistiques pour un système sans opérations
Flashback ou pour un système qui n'est pas censé exécuter d'interrogations de longue durée
dans le futur.
La fonction de conseil Undo Advisor vous permet de préciser la période de conservation des
informations d'annulation qui vous semble souhaitable pour les interrogations de longue durée
et les opérations Flashback.

Gestion des annulations : Informations générales

Taille de tablespace
actuelle
Gestion des annulations : Informations générales

Dans Enterprise Manager, sélectionnez Server > Automatic Undo Management.
Vous pouvez afficher deux pages : General et System Activity. La partie supérieure de la page
General comprend une section sur les paramètres de conservation des informations
d'annulation (Undo Retention Settings) et une section relative au tablespace d'annulation
associé à l'instance (Undo Tablespace for this Instance).

Utiliser Undo Advisor

Utiliser Undo Advisor

La page General comprend également une section qui concerne votre accès à la fonction de
conseil Undo Advisor. Elle fournit une estimation de l'espace requis dans le tablespace
d'annulation pour satisfaire une période de conservation donnée.
La région d'analyse d'Undo Advisor affiche la taille que doit avoir le tablespace pour prendre
en charge la période indiquée. Vous pouvez cliquer sur un point du graphique afin de voir la
taille requise correspondante.
Cliquez sur le bouton Edit Undo Tablespace, puis cliquez sur Edit dans la section Datafile
pour passer à un tablespace de taille fixe.

Afficher l'activité du système
3
2

Afficher l'activité du système

La partie supérieure de la page System Activity présente l'activité du système pendant la
période sélectionnée.
Elle permet d'afficher trois graphiques :
1. Undo Tablespace Usage : Evolution de la taille du tablespace (en Mo) au jour le jour,
pour le mois indiqué.
2. Undo Retention Auto-Tuning : Réglage de la période de conservation des informations
d'annulation au jour le jour (en minutes), pour le mois indiqué.
3. Undo Generation Rate : Taux de génération des informations d'annulation au jour le
jour (en Ko par seconde), pour le mois indiqué.

Quiz
Pour garantir que toutes les interrogations de moins de

15 minutes trouvent les données d'annulation requises par la
cohérence en lecture, il suffit de configurer le paramètre
UNDO_RETENTION avec une durée de 15 minutes.
1. Vrai
2. Faux

Réponse : 2

Quiz
Quelle affirmation ne s'applique pas aux données d'annulation ?

1. Elles indiquent comment annuler une modification.
2. Elles sont utilisées pour les annulations (rollbacks),
la cohérence en lecture et les opérations Flashback.
3. Elles ne sont pas écrites sur disque, mais seulement
stockées en mémoire.
4. Elles offrent une protection contre les lectures incohérentes
dans un système multiutilisateur.

Réponse : 3

Synthèse

• décrire les instructions LMD et les données d'annulation
• surveiller et administrer les données d'annulation
• décrire les différences entre les données d'annulation et les
données de journalisation
• configurer la période de conservation des informations
d'annulation
• garantir la conservation des informations d'annulation

• utiliser la fonction de conseil Undo Advisor

Gérer les segments d'annulation

• examiner l'activité du système
• calculer la taille du tablespace d'annulation pour prendre en
charge une période de conservation de 48 heures
• modifier un tablespace d'annulation pour prendre en charge
une période de conservation de 48 heures


Implémenter l'audit de la base de données
Oracle

Objectifs

• décrire les responsabilités du DBA en matière de sécurité et
d'audit
• activer l'audit de base de données standard
• définir les options d'audit
• examiner les informations d'audit
• gérer la trace d'audit

Objectifs
Le présent chapitre constitue un point de départ pour l'étude des fonctionnalités Oracle
relatives à la sécurité. Pour plus d'informations, reportez-vous aux manuels suivants :
• Oracle Database Concepts
• Oracle Database Administrator’s Guide
• Oracle Database Security Guide
Les cours suivants fournissent une formation complémentaire :
• Oracle Database 11g : Administration Workshop II
• Oracle Database 11g : Sécurité

Séparation des responsabilités
• Les utilisateurs disposant des privilèges de DBA doivent

être des personnes de confiance.
– Faire attention aux abus de confiance
– Mettre en place des traces d'audit pour protéger les
personnes dignes de confiance
• Les responsabilités de DBA doivent être partagées.
• Les comptes ne doivent jamais être partagés.
• Le DBA et l'administrateur système doivent être des
personnes différentes.

• Séparez les responsabilités Opérateur et DBA.
Séparation des responsabilités

La diapositive ci-dessus indique les principes à respecter pour obtenir une séparation
satisfaisante des fonctions.
Les DBA doivent être des personnes de confiance : Il est difficile de restreindre les droits
d'un administrateur de base de données (DBA). Pour faire son travail, le DBA a besoin de
privilèges de haut niveau. Il occupe un poste critique et les informations personnelles le
concernant doivent être vérifiées avec soin. Même s'il s'agit d'une personne de confiance, il
est nécessaire d'assurer le suivi de ses activités. Envisagez les précautions suivantes :
• Faire attention aux abus de confiance : Un DBA peut utiliser à des fins malveillantes
les mots de passe cryptés dans la vue DBA_USERS.
• Mettre en place des traces d'audit pour protéger les personnes dignes de confiance :
Une fois l'audit soigneusement implémenté dans le respect des règles établies, la trace
d'audit peut montrer qu'une personne donnée n'a pas enfreint de procédures ni commis
d'acte préjudiciable. Des traces d'audit bien conçues permettent de détecter les actions
effectuées par un utilisateur malveillant pour tenter de jeter un doute sur un utilisateur
digne de confiance.
Oracle Database Vault : Il est intéressant d'utiliser l'option Oracle Database Vault dans les
situations où la séparation des fonctions doit être appliquée au niveau de la base de données
ou lorsque le DBA n'est pas autorisé à afficher les données de certains schémas ou de tous les
schémas de la base.

Sécurité de la base de données
Un système sécurisé garantit la confidentialité des données

qu'il contient. La sécurité englobe plusieurs aspects :
• Limiter l'accès aux données et aux services
• Authentifier les utilisateurs
• Surveiller les activités suspectes

Sécurité de la base de données

Oracle Database 11g offre le meilleur environnement possible pour un système sécurisé. Pour
que cet environnement soit efficace, il faut toutefois que le DBA respecte les
recommandations et surveille en permanence l'activité de la base de données.
Limiter l'accès aux données et aux services
Les utilisateurs ne doivent pas tous avoir accès à toutes les données. Selon les données
stockées dans la base, un accès restreint peut s'avérer nécessaire pour diverses raisons :
exigences métier, attentes des clients ou encore (de plus en plus souvent) restrictions légales.
Les informations confidentielles telles que les informations relatives aux cartes bancaires, à la
santé et à l'identité doivent être protégées contre tout accès non autorisé. La base Oracle
fournit des contrôles d'autorisation de niveau très fin pour limiter les accès. Pour la définition
des accès, il convient d'appliquer le principe du moindre privilège.

Sécurité de la base de données (suite)
Authentifier les utilisateurs
Pour appliquer les contrôles d'accès aux données sensibles, le système doit d'abord savoir qui tente
d'accéder aux données. Une authentification incorrecte peut rendre inutiles toutes les autres
précautions de sécurité. La forme la plus élémentaire d'authentification consiste à demander à
l'utilisateur d'indiquer quelque chose qu'il connaît, par exemple un mot de passe. Vous pouvez
accroître considérablement la sécurité du système en imposant le respect de règles simples
concernant les mots de passe. Les méthodes d'authentification renforcées consistent à demander à
l'utilisateur de fournir quelque chose qu'il possède, par exemple un jeton (token) ou un certificat de
clé publique (PKI). Une forme encore plus renforcée d'authentification consiste à identifier les
utilisateurs via une caractéristique biométrique unique, telle qu'une empreinte digitale, l'iris de l'oeil,
la morphologie, etc. La base de données Oracle prend en charge des techniques d'authentification
avancées (telles que l'identification par jeton, biométrie ou certificat) via l'option ASO (Oracle
Advanced Security). Les comptes utilisateur qui ne sont pas employés doivent être verrouillés afin
d'éviter toute tentative de compromission de l'authentification.

Surveiller les activités suspectes
Même autorisés et authentifiés, les utilisateurs peuvent parfois compromettre le système.
L'identification d'une activité de base de données inhabituelle (par exemple, un employé qui
commence soudain à interroger de grandes quantités d'informations de carte bancaire, de résultats de
recherche ou d'autres informations sensibles) peut être la première étape de la détection d'un vol
d'informations. La base de données Oracle offre un ensemble complet d'outils d'audit permettant le
suivi des activités des utilisateurs et l'identification de manoeuvres suspectes.

Surveiller la conformité aux règles de sécurité
La surveillance ou l'audit doit faire partie intégrante des

procédures de sécurité.
Déterminez les types d'audit appropriés parmi les suivants :
• Audit obligatoire
• Audit de base de données standard
• Audit basé sur les données
• Audit détaillé (FGA)
• Audit de SYSDBA (et SYSOPER)

Surveiller la conformité aux règles de sécurité

L'audit consiste à capturer et à stocker les informations relatives à ce qui se passe dans le
système. Cette opération accroît la quantité de travail que le système doit réaliser. Elle doit
donc être ciblée de telle sorte que seuls les événements présentant un intérêt soient capturés.
Un audit correctement ciblé présente un impact minimal sur les performances du système. En
revanche, un audit ciblé de manière incorrecte peut affecter les performances de manière
significative.
• Audit obligatoire : Toutes les bases de données Oracle auditent certaines actions
indépendamment des options ou des paramètres d'audit. En effet, la base doit enregistrer
certaines activités telles que les connexions d'utilisateurs dotés de privilèges.
• Audit de base de données standard : Ce type d'audit est activé au niveau du système à
l'aide du paramètre d'initialisation AUDIT_TRAIL. Après avoir activé l'audit,
sélectionnez les objets et les privilèges à auditer, et définissez les propriétés d'audit à
l'aide de la commande AUDIT.
• Audit basé sur les données : Cet audit est une extension de l'audit de base de données
standard qui enregistre non seulement la survenue de l'événement audité, mais également
les valeurs insérées, mises à jour ou supprimées. Il est implémenté par l'intermédiaire de
déclencheurs (triggers) de base de données.
• Audit détaillé (FGA - fine-grained auditing) : Cet audit est une extension de l'audit de
base de données standard qui capture l'instruction SQL exécutée, et pas uniquement le
fait que l'événement s'est produit.
• Audit de SYSDBA (et SYSOPER) : Cet audit répartit les tâches d'audit entre le DBA et
un auditeur ou administrateur de sécurité qui surveille les activités du DBA via une trace
d'audit au niveau du système d'exploitation.

Audit de base de données standard
1 Activer l'audit de
base de données
Fichier de Utilisateur
DBA
paramètres
Exécute une
2 Définir les options d'audit commande
Base de données
Processus
serveur
Options
Générer la
d'audit
trace d'audit

3 Examiner les
informations d'audit
Trace
d'audit Trace
4 Gérer la trace d'audit d'audit OS
ou XML
Audit de base de données standard

Pour utiliser l'audit de base de données, vous devez d'abord définir le paramètre statique
AUDIT_TRAIL afin qu'il pointe vers l'emplacement de stockage des enregistrements d'audit.
L'audit de base de données est ainsi activé. Une fois que vous avez activé l'audit et indiqué les
options associées (événements de connexion, utilisation de privilèges système et de privilèges
objet, utilisation d'instructions SQL), la base commence à collecter les informations d'audit.
Si le paramètre AUDIT_TRAIL a la valeur OS, les enregistrements d'audit sont stockés dans
le système d'audit du système d'exploitation. Dans un environnement Windows, il s'agit du
journal des événements. Dans un environnement UNIX ou Linux, les enregistrements d'audit
sont stockés dans le fichier indiqué par le paramètre AUDIT_FILE_DEST.
Si le paramètre AUDIT_TRAIL a la valeur DB ou DB, EXTENDED, vous pouvez consulter
les enregistrements d'audit dans la vue DBA_AUDIT_TRAIL du schéma SYS.
Si le paramètre AUDIT_TRAIL a la valeur XML ou XML,EXTENDED, les enregistrements
d'audit sont écrits dans des fichiers XML, dans le répertoire désigné par le paramètre
AUDIT_FILE_DEST. Vous pouvez consulter tous les fichiers XML de ce répertoire dans la
vue V$XML_AUDIT_TRAIL.
La maintenance de la trace d'audit est une tâche d'administration importante. Selon le ciblage
des options d'audit, cette trace peut avoir une taille qui augmente très rapidement. En
l'absence d'une maintenance appropriée, elle peut créer un tel nombre d'enregistrements
qu'elle affecte les performances du système. La surcharge est directement liée à la quantité
d'enregistrements d'audit.

Configurer la trace d'audit
Utilisez AUDIT_TRAIL pour activer l'audit de base de données.

Valeurs possibles de
AUDIT_TRAIL :
• NONE
• OS
• DB
• DB, EXTENDED
• XML
• XML, EXTENDED

ALTER SYSTEM SET AUDIT_TRAIL='XML' SCOPE=SPFILE;
Redémarrez la base de données après avoir modifié ce

paramètre d'initialisation statique.
Configurer la trace d'audit

Vous pouvez définir le paramètre AUDIT_TRAIL à l'aide d'Enterprise Manager (à partir de la
page Initialization Parameters) ou à l'aide de la commande ALTER SYSTEM SET dans
SQL*Plus. Comme ce paramètre est statique, vous devez redémarrer la base de données pour
que la modification prenne effet. Si vous avez créé la base à l'aide de DBCA (Database
Configuration Assistant), audit_trail a par défaut la valeur DB. Lorsque AUDIT_TRAIL
est défini avec la valeur DB, le comportement par défaut consiste à enregistrer la trace d'audit
dans la table AUD$ de la base. Pour la plupart des sites, cet audit n'a pas un impact important
sur les performances de la base. Oracle recommande d'utiliser les fichiers de trace d'audit du
système d'exploitation. Si vous avez créé la base manuellement (à l'aide de la commande
CREATE DATABASE), AUDIT_TRAIL a par défaut la valeur NONE.

Traces d'audit uniformes
STATEMENTID,
AUDIT_TRAIL=DB, EXTENDED
ENTRYID
DBA_AUDIT_TRAIL DBA_FGA_AUDIT_TRAIL
EXTENDED_TIMESTAMP,
PROXY_SESSIONID, GLOBAL_UID,

INSTANCE_NUMBER, OS_PROCESS, TRANSACTIONID,
SCN, SQL_BIND, SQL_TEXT
DBA_COMMON_AUDIT_TRAIL
Traces d'audit uniformes

La base de données Oracle effectue le suivi des mêmes champs pour l'audit standard et pour
l'audit détaillé, ce qui facilite l'analyse de ses activités. Pour cela, la trace d'audit standard et la
trace d'audit détaillé ont chacune des attributs complémentaires.
Les informations supplémentaires collectées par l'audit standard sont les suivantes :
• Le numéro SCN (System Change Number) associé à chaque modification apportée au
système.
• Le texte exact de l'instruction SQL exécutée par l'utilisateur et les variables attachées
(bind variables) associées. Ces colonnes apparaissent uniquement si vous avez indiqué
AUDIT_TRAIL=DB, EXTENDED.
Les informations supplémentaires collectées par l'audit détaillé sont les suivantes :
• Un numéro de série pour chaque enregistrement d'audit.
• Un numéro d'instruction qui lie plusieurs entrées d'audit provenant d'une instruction
unique.
Les attributs communs sont les suivants :
• Un horodatage global au format UTC (temps universel coordonné). Ce champ est utile
pour la surveillance de serveurs situés à des emplacements géographiques distincts dans
des fuseaux horaires différents.
• Un numéro d'instance unique pour chaque instance RAC (Real Application Clusters).
• Un identificateur de transaction qui vous aide à regrouper les enregistrements d'audit
correspondant à une même transaction.
La vue DBA_COMMON_AUDIT_TRAIL combine les enregistrements de l'audit standard et de
l'audit détaillé.

Définir les options d'audit
• Audit des instructions SQL :

AUDIT table;
• Audit des privilèges système (non ciblé et ciblé) :
AUDIT select any table, create any trigger;

AUDIT select any table BY hr BY SESSION;

• Audit des privilèges objet (non ciblé et ciblé) :
AUDIT ALL on hr.employees;
AUDIT UPDATE,DELETE on hr.employees BY ACCESS;
Définir les options d'audit

Audit des instructions SQL : L'instruction de la diapositive ci-dessus audite toute instruction
LDD (langage de définition de données) qui affecte une table, notamment CREATE TABLE,
DROP TABLE, TRUNCATE TABLE, etc. L'audit peut être ciblé en fonction d'un nom
utilisateur, ou en fonction de la réussite ou de l'échec de l'instruction :
SQL> AUDIT TABLE BY hr WHENEVER NOT SUCCESSFUL;
Audit des privilèges système : Il peut être utilisé pour auditer l'utilisation de n'importe quel
privilège système (tel que DROP ANY TABLE). Il peut être ciblé en fonction d'un nom
utilisateur, ou en fonction de la réussite ou de l'échec de l'opération. Par défaut, l'audit est de
type BY ACCESS. Chaque fois qu'un privilège système audité est utilisé, un enregistrement
d'audit est généré. Vous pouvez choisir de regrouper les enregistrements avec la clause BY
SESSION de sorte qu'un seul enregistrement soit généré par session. (De cette façon, si un
utilisateur exécute plusieurs instructions de mise à jour sur une table appartenant à un autre
utilisateur, un seul enregistrement d'audit est collecté.) Envisagez l'utilisation de la clause BY
SESSION pour limiter l'impact de l'audit des privilèges système sur le stockage et les
performances.
Audit des privilèges objet : Il peut être utilisé pour auditer les actions sur les tables, les vues,
les procédures, les séquences, les répertoires et les types de données définis par l'utilisateur.
Ce type d'audit peut être ciblé en fonction de la réussite ou de l'échec de l'opération. Les
enregistrements peuvent être générés par session ou par accès. Par défaut, ils sont regroupés
par session, contrairement à ce qui se passe avec l'audit des privilèges système. Vous devez
indiquer explicitement BY ACCESS si vous souhaitez un enregistrement d'audit distinct pour
chaque action.

Audit par défaut
Privilèges audités par défaut

ALTER ANY PROCEDURE CREATE ANY LIBRARY GRANT ANY PRIVILEGE
ALTER ANY TABLE CREATE ANY PROCEDURE GRANT ANY ROLE
ALTER DATABASE CREATE ANY TABLE DROP ANY PROCEDURE
ALTER PROFILE CREATE EXTERNAL JOB DROP ANY TABLE
ALTER SYSTEM CREATE PUBLIC DATABASE LINK DROP PROFILE
ALTER USER CREATE SESSION DROP USER
AUDIT SYSTEM CREATE USER EXEMPT ACCESS POLICY
CREATE ANY JOB GRANT ANY OBJECT PRIVILEGE
Instructions auditées par défaut

SYSTEM AUDIT BY ACCESS
ROLE BY ACCESS
Audit par défaut

Quand l'audit est activé dans Oracle Database 11g, certains privilèges et instructions très
importants pour la sécurité sont audités par défaut. Ces privilèges et instructions (répertoriés
dans la diapositive ci-dessus) sont audités pour tous les utilisateurs, en cas de succès comme
d'échec, et pour chaque accès.

Page Audit Settings d'Enterprise Manager

Page Audit Settings d'Enterprise Manager

Vous pouvez accéder à la page Audit Settings à partir de la page d'accueil de Database
Control, en cliquant sur l'onglet Server, puis sur le lien Audit Settings dans la région Security.
La page Audit Settings contient les régions suivantes :
• Configuration : Affiche les valeurs en cours des paramètres de configuration et contient
des liens permettant de modifier ces valeurs.
• Audit Trails : Permet d'accéder facilement aux informations d'audit collectées.
Utilisez les onglets suivants pour définir ou annuler les options d'audit :
• Audited Privileges : Affiche les privilèges audités.
• Audited Objects : Affiche les objets audités.
• Audited Statements : Affiche les instructions auditées.

Utiliser et gérer les informations d'audit
Désactivez les options d'audit si vous ne les utilisez pas.

Utiliser et gérer les informations d'audit

Recommandation
L'impact de l'activité d'audit sur les performances est proportionnel au nombre d'opérations
d'écriture dans la trace d'audit. Pour adapter les options d'audit aux besoins de votre site,
activez uniquement les options qui sont nécessaires pour appliquer la stratégie de sécurité que
vous avez choisie. Ciblez l'audit pour réduire le nombre d'entrées dans la trace d'audit.

Audit basé sur les données
Un utilisateur Le déclencheur Un enregistrement

effectue une s'exécute. d'audit est créé
modification. par le déclencheur.

La modification Un enregistrement
de l'utilisateur d'audit est inséré
est effectuée. dans une table de
trace d'audit.
Audit basé sur les données

L'audit de base de données enregistre le fait que des opérations d'insertion, de mise à jour ou
de suppression ont été effectuées dans les objets audités, mais il ne capture pas les valeurs qui
ont changé. L'audit basé sur les données étend cette fonction en utilisant des déclencheurs de
base de données (structures PL/SQL basées sur les événements) pour capturer les valeurs
modifiées.
Lorsqu'un utilisateur insère, met à jour ou supprime des données dans une table, le
déclencheur associé à celle-ci s'exécute en arrière-plan afin de copier les informations d'audit
dans la table appropriée. L'audit basé sur les données a généralement un impact plus
important que l'audit de base de données standard sur les performances, car le code du
déclencheur d'audit doit être exécuté chaque fois qu'une opération d'insertion, de mise à jour
ou de suppression a lieu. Le degré de dégradation dépend de l'efficacité du code du
déclencheur. L'audit basé sur les données ne doit être utilisé que lorsque les informations
capturées par l'audit standard sont insuffisantes.
Il est implémenté par l'utilisateur ou par un code tiers. La base de données Oracle fournit les
structures PL/SQL permettant de créer de tels systèmes d'audit.

Audit basé sur les données (suite)
L'élément clé de l'audit basé sur les données est le déclencheur d'audit. Il s'agit simplement d'un
déclencheur PL/SQL conçu pour capturer des informations d'audit.
Exemple de déclencheur d'audit :
CREATE OR REPLACE TRIGGER system.hrsalary_audit
AFTER UPDATE OF salary
ON hr.employees
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
IF :old.salary != :new.salary THEN
INSERT INTO system.audit_employees
VALUES (sys_context('userenv','os_user'), sysdate,
sys_context('userenv','ip_address'),
:new.employee_id ||

' salary changed from '||:old.salary||
' to '||:new.salary);
END IF;
END;
/
Ce déclencheur cible l'audit sur la capture des modifications apportées à la colonne salary de la
table hr.employees. Lorsqu'une ligne est mise à jour, le déclencheur examine la colonne
salary. Si l'ancien salaire est différent du nouveau, le déclencheur insère un enregistrement d'audit
dans la table audit_employees (laquelle est créée via une opération distincte dans le schéma
SYSTEM). L'enregistrement d'audit inclut le nom utilisateur, l'adresse IP de l'ordinateur à partir
duquel la modification a été effectuée, la clé primaire identifiant l'enregistrement qui a changé, et les
valeurs de salaire qui ont changé.
Il est aussi possible d'utiliser des déclencheurs de base de données pour capturer des informations sur
les connexions utilisateur, au cas où l'audit de base de données standard ne collecterait pas
suffisamment d'informations. Avec des déclencheurs de connexion (login triggers), l'administrateur
peut capturer des données identifiant l'utilisateur qui se connecte à la base. Exemples :
• Adresse IP de la personne qui se connecte
• 48 premiers caractères du nom du programme utilisé pour la connexion à l'instance
• Nom du terminal utilisé pour la connexion à l'instance
Pour obtenir la liste complète des paramètres utilisateur, reportez-vous à la section intitulée
"SYS_CONTEXT" du manuel Oracle Database SQL Reference.
Les déclencheurs basés sur les données ont été supplantés dans de nombreux cas par la fonctionnalité
d'audit détaillé (FGA).

Audit détaillé
• Surveille l'accès aux données en fonction du contenu

• Audite SELECT, INSERT, UPDATE, DELETE et MERGE
• Peut être lié à une ou plusieurs colonnes d'une table ou
d'une vue
• Peut exécuter une procédure
• Est administré via le package DBMS_FGA
Stratégie : AUDIT_EMPS_SALARY

SELECT name, salary
FROM employees
WHERE
department_id = 10; employees
Audit détaillé
L'audit de base de données enregistre le fait qu'une opération a eu lieu, mais ne capture pas
d'informations sur l'instruction ayant provoqué cette opération. L'audit détaillé (FGA - Fine-
grained auditing) étend cette fonctionnalité en permettant de capturer les instructions SQL qui
interrogent ou manipulent les données.
Il permet également un ciblage plus précis que l'audit standard ou l'audit basé sur les données.
Les options d'audit détaillé peuvent être ciblées sur des colonnes individuelles d'une table ou
d'une vue. Elles peuvent aussi être conditionnelles, de sorte que les informations d'audit ne
soient capturées que si certaines conditions définies par l'administrateur sont réunies. Une
stratégie d'audit détaillé peut être associée à plusieurs colonnes d'intérêt. Par défaut, si l'une de
ces colonnes est présente dans l'instruction SQL, elle est auditée. Deux packages,
DBMS_FGA.ALL_COLUMNS et DBMS_FGA.ANY_COLUMNS, permettent de baser l'audit
sur l'utilisation de toutes les colonnes d'intérêt dans l'instruction ou sur l'utilisation de l'une
quelconque d'entre elles.
Utilisez le package PL/SQL DBMS_FGA pour créer une stratégie d'audit sur la table ou sur la
vue cible. Si certaines des lignes renvoyées par un bloc d'interrogation correspondent à la
colonne auditée et satisfont à la condition d'audit indiquée, un événement d'audit entraîne la
création d'un enregistrement d'audit et son stockage dans la trace d'audit. L'événement d'audit
peut éventuellement exécuter une procédure. L'audit détaillé cible automatiquement le niveau
instruction. Une instruction SELECT qui renvoie des milliers de lignes génère donc un seul
enregistrement d'audit.

Stratégie d'audit détaillé
• Définit : dbms_fga.add_policy (
object_schema => 'HR',
– les critères object_name => 'EMPLOYEES',
d'audit policy_name => 'audit_emps_salary',
audit_condition=> 'department_id=10',
– l'action d'audit audit_column => 'SALARY,COMMISSION_PCT',
• Est créée via handler_schema => 'secure',
DBMS_FGA handler_module => 'log_emps_salary',
enable => TRUE,
.ADD_POLICY statement_types => 'SELECT,UPDATE');
SELECT name, job_id

FROM employees

WHERE
department_id = 20; Non audité
SELECT name, salary

FROM employees SECURE.LOG_EM
WHERE PS_SALARY
department_id = 10; employees
Stratégie d'audit détaillé

L'exemple de la diapositive crée une stratégie d'audit détaillé à l'aide de la procédure
DBMS_FGA.ADD_POLICY qui accepte les arguments suivants.
Nom de la stratégie
Vous affectez un nom à chaque stratégie d'audit détaillé lors de sa création. L'exemple de la
diapositive nomme la stratégie AUDIT_EMPS_SALARY, à l'aide de l'argument suivant :
policy_name => 'audit_emps_salary'
Condition d'audit
La condition d'audit est un prédicat SQL qui définit à quel moment l'événement d'audit doit
être déclenché. Dans l'exemple de la diapositive, toutes les lignes du département 10 sont
auditées à l'aide de l'argument de condition suivant :
audit_condition => 'department_id = 10'
Remarque : L'audit détaillé examine l'ensemble de résultats de l'interrogation. Dans
l'exemple de la diapositive, les interrogations qui renvoient des lignes conformes aux
spécifications de la stratégie entraînent la création d'un enregistrement d'audit. Par exemple,
dans l'interrogation "select * from employees", toutes les lignes peuvent être
renvoyées, y compris celles où department_id contient la valeur 10, de sorte qu'une ligne
d'audit est créée.

Stratégie d'audit détaillé (suite)
Colonne d'audit
La colonne d'audit définit les données auditées. Un événement d'audit se produit si cette colonne est
incluse dans l'instruction SELECT ou si la condition d'audit autorise la sélection. L'exemple de la
diapositive audite deux colonnes, à l'aide de l'argument suivant :
audit_column => 'SALARY,COMMISION_PCT'
Cet argument est facultatif. S'il n'est pas indiqué, seul l'argument AUDIT_CONDITION détermine si
un événement d'audit doit se produire.
Objet
L'objet est la table ou la vue auditée. Il est transmis sous la forme de deux arguments :
• Le schéma contenant l'objet
• Le nom de l'objet
L'exemple de la diapositive audite la table hr.employees, à l'aide des arguments suivants :

object_schema => 'hr'
object_name => 'employees'
Gestionnaire
Un gestionnaire d'événements (facultatif) est une procédure PL/SQL qui définit les actions
supplémentaires qui doivent être effectuées au cours de l'audit. Par exemple, le gestionnaire
d'événements peut envoyer une page d'alerte à l'administrateur. S'il n'est pas défini, une entrée
d'événement d'audit est insérée dans la trace d'audit. Si un gestionnaire d'événements d'audit est
défini, l'entrée d'audit est insérée dans la trace d'audit et le gestionnaire d'événements d'audit est
exécuté.
L'entrée d'événement d'audit inclut la stratégie d'audit détaillé ayant provoqué l'événement,
l'utilisateur qui exécute l'instruction SQL, ainsi que l'instruction SQL et ses variables attachées (bind
variables).
Le gestionnaire d'événements est transmis sous la forme de deux arguments :
• Le schéma contenant l'unité de programme PL/SQL
• Le nom de l'unité de programme PL/SQL
L'exemple de la diapositive exécute la procédure SECURE.LOG_EMPS_SALARY, à l'aide des
arguments suivants :
handler_schema => 'secure'
handler_module => 'log_emps_salary'
Par défaut, la trace d'audit écrit toujours le texte SQL et les informations de liaison SQL dans des
objets LOB (Large Object). Il est possible de modifier ce comportement par défaut (par exemple, en
cas de risque d'une dégradation des performances du système).
Statut
Le statut indique si la stratégie d'audit détaillé est activée ou non. Dans l'exemple de la diapositive,
l'argument suivant active la stratégie :
enable => TRUE

Instruction LMD auditée :
Eléments à prendre en compte
• Les enregistrements sont audités si le prédicat d'audit
détaillé est satisfait et que les colonnes d'intérêt sont
référencées.
• Les instructions DELETE sont auditées
quelles que soient les colonnes indiquées. Cette instruction n'est pas
• Les instructions MERGE sont auditées avec auditée car aucun des
enregistrements impliqués ne
les instructions sous-jacentes INSERT, concerne le département 10.
UPDATE et DELETE générées.

UPDATE hr.employees

SET salary = 1000
WHERE commission_pct = .2;
UPDATE hr.employees
SET salary = 1000
WHERE employee_id = 200;
Instruction LMD auditée : Eléments à prendre en compte

Lorsqu'une stratégie d'audit détaillé est définie pour des instructions LMD, une instruction
LMD est auditée si les lignes de données (nouvelles et anciennes) manipulées satisfont aux
critères du prédicat de la stratégie.
Toutefois, dans le cas où les colonnes d'intérêt sont également indiquées dans la définition de
la stratégie, l'instruction est auditée si les données satisfont au prédicat de la stratégie d'audit
détaillé et que l'instruction référence les colonnes d'intérêt définies.
Pour les instructions DELETE, il est inutile d'indiquer les colonnes d'intérêt lors de la
définition de la stratégie car les instructions de ce type touchent l'ensemble des colonnes d'une
table. Par conséquent, une instruction DELETE est toujours auditée, quelles que soient les
colonnes d'intérêt.
Les instructions MERGE sont prises en charge par l'audit détaillé. Les instructions INSERT,
UPDATE et DELETE sous-jacentes sont auditées si elles satisfont aux stratégies d'audit
détaillé INSERT, UPDATE ou DELETE définies.
Avec la stratégie d'audit détaillé précédemment définie, la première instruction n'est pas
auditée alors que la seconde l'est. En effet, aucun des employés du département 10 ne reçoit
de commission, alors que la condition employee_id=200 désigne un employé du
département 10.

Règles relatives à l'audit détaillé
• Pour auditer toutes les lignes, utilisez une condition
d'audit null.
• Pour auditer toutes les colonnes, utilisez une colonne
d'audit null.
• Les noms des stratégies doivent être uniques.
• La table ou la vue auditée doit déjà exister lorsque
vous créez la stratégie.
• Si la syntaxe de la condition d'audit n'est pas valide, une
erreur ORA-28112 est générée lors de l'accès à l'objet audité.
• Si la colonne auditée n'existe pas dans la table, aucune ligne

n'est auditée.
• Si le gestionnaire d'événements n'existe pas, aucune erreur
n'est renvoyée et l'enregistrement d'audit est quand même
créé.
Règles relatives à l'audit détaillé

Pour les instructions SELECT, l'audit détaillé capture l'instruction, pas les lignes réelles.
Toutefois, lorsque l'audit détaillé est combiné à Flashback Query, les lignes peuvent être
regénérées telles qu'elles étaient à un point spécifique dans le temps.
Pour plus d'informations sur Flashback Query, reportez-vous au chapitre intitulé "Procéder à
un flashback de la base de données".
Pour plus d'informations sur le package DBMS_FGA, reportez-vous au manuel Oracle
Database PL/SQL Packages and Types Reference.

Audit des activités de SYSDBA
Les utilisateurs dotés des privilèges SYSDBA ou SYSOPER

peuvent se connecter lorsque la base de données est fermée.
• La trace d'audit doit être stockée à l'extérieur de la base.
• Les connexions en tant que SYSDBA ou SYSOPER sont
toujours auditées.
• Vous pouvez activer l'audit complémentaire des actions
SYSDBA ou SYSOPER avec AUDIT_SYS_OPERATIONS.
• Vous pouvez contrôler la trace d'audit avec
AUDIT_FILE_DEST.

Audit des activités de SYSDBA

Les utilisateurs SYSDBA et SYSOPER possèdent les privilèges permettant de démarrer et
d'arrêter la base de données. Etant donné qu'ils peuvent apporter des modifications pendant
que la base est fermée, la trace d'audit de ces privilèges doit être stockée à l'extérieur de celle-
ci. La base Oracle capture automatiquement les événements de connexion générés par les
utilisateurs SYSDBA et SYSOPER. Il s'agit d'une méthode intéressante de suivi des actions
SYSDBA et SYSOPER autorisées et non autorisées, mais elle n'est utile que si la trace d'audit
du système d'exploitation est examinée.
La base de données Oracle capture toujours les événements de connexion générés par les
utilisateurs dotés de privilèges. Les autres actions sont capturées si l'audit de DBA est activé
explicitement. Activez l'audit des utilisateurs SYSDBA et SYSOPER en définissant le
paramètre d'initialisation :
AUDIT_SYS_OPERATIONS=TRUE (La valeur par défaut est FALSE.)
Si les opérations SYS sont auditées, le paramètre d'initialisation AUDIT_FILE_DEST
contrôle l'emplacement de stockage des enregistrements d'audit. Sur une plate-forme
Windows, la trace d'audit est enregistrée par défaut dans le journal des événements. Sur les
plates-formes UNIX et Linux, les enregistrements d'audit sont stockés à l'emplacement
désigné par AUDIT_FILE_DEST.

Gérer la trace d'audit
Gérez la trace d'audit en tenant compte des recommandations

suivantes :
• Recherchez les enregistrements anciens et stockez-les.
• Evitez les problèmes de stockage.
• Evitez la perte d'enregistrements.

Gérer la trace d'audit

Il est nécessaire d'assurer la maintenance de chaque type de trace d'audit. Il faut au minimum
examiner les enregistrements d'audit et supprimer les plus anciens de la base de données ou
du système d'exploitation. Les traces d'audit peuvent croître jusqu'à occuper tout l'espace de
stockage disponible. Si le système de fichiers est plein, une panne ou des problèmes de
performances peuvent se produire. Si la trace d'audit de base de données occupe tout le
tablespace, les actions auditées ne s'exécutent pas. Si la trace d'audit occupe tout le tablespace
SYSTEM, les performances des autres opérations sont affectées et les opérations d'audit sont
interrompues.
La trace d'audit standard est stockée dans la table AUD$. La trace d'audit détaillé est stockée
dans la table FGA_LOG$. Par défaut, ces deux tables sont créées dans le tablespace SYSTEM.
Vous pouvez les déplacer vers un autre tablespace à l'aide des utilitaires d'export et d'import
de Data Pump.
Remarque : Le déplacement des tables d'audit hors du tablespace SYSTEM n'est pas pris en
charge.
Le processus de suppression d'enregistrements des tables d'audit peut entraîner la perte
d'enregistrements d'audit.
Recommandation
Procédez à un export basé sur un horodatage, puis supprimez des lignes de la trace d'audit en
fonction du même horodatage.

Oracle Audit Vault
• Consolidation et sécurisation
des données d'audit
– Oracle 9i Release 2 et versions
supérieures
– SQL Server 2000, 2005
– IBM DB2 UDB 8.5 & 9.2
– Sybase ASE 12.5 - 15.0
– Sécurité et évolutivité
– Nettoyage des données d'audit
Oracle source
• Génération centralisée d'états
– Interface de génération d'états mise
à jour utilisant Oracle Application
Express Sybase

– Etats standard fournis à des fins ASE
de conformité réglementaire
– Nouveaux états personnalisés
• Alertes relatives aux menaces IBM
concernant la sécurité Oracle DB2
Database Microsoft
– Détecter et signaler les événements SQL Server
intéressant la sécurité
Oracle Audit Vault

Les principaux avantages d'Oracle Audit Vault sont décrits ci-après :
• Oracle Audit Vault collecte et consolide de manière transparente les données d'audit des
bases suivantes : Oracle9i Database Release 2 et versions ultérieures, Microsoft SQL
Server 2000 et 2005, IBM DB2 Unix, Linux, Windows 8.2 et 9.5, Sybase
ASE versions 12.5 à 15.0.
• Oracle Audit Vault permet aux organisations de simplifier la génération des documents
de vérification de conformité à l'aide d'états prédéfinis et personnalisés. Il fournit en outre
un schéma de data warehouse d'audit auquel il est possible d'accéder à partir d'Oracle BI
Publisher, d'Oracle Application Express et d'autres outils de reporting tiers.
• Oracle Audit Vault permet de détecter et d'éviter les menaces internes en signalant les
activités suspectes.
• Au coeur d'Oracle Audit Vault se trouve un data warehouse d'audit sécurisé et évolutif,
basé sur la technologie de data warehouse d'Oracle et protégé à l'aide des produits de
sécurité de la base de données Oracle tels qu'Oracle Database Vault et Oracle Advanced
Security. Oracle Audit Vault inclut Oracle Partitioning pour une plus grande facilité de
gestion et de meilleures performances.
• Oracle Audit Vault permet de réduire les coûts informatiques grâce à une gestion
centralisée des paramètres d'audit (stratégies) des bases de données qui facilite le travail
des responsables de la sécurité des systèmes d'informations et des auditeurs internes.
Pour plus d'informations, reportez-vous à la documentation consacrée à Oracle Audit Vault.

Quiz
L'audit de base de données standard capture les états avant et

après une transaction LMD.
1. Vrai
2. Faux

Réponse : 2

Quiz
L'audit des activités de SYSDBA et SYSOPER est activé par défaut.

1. Vrai
2. Faux

Réponse : 2

Synthèse

• décrire les responsabilités du DBA en matière de sécurité et
d'audit
• définir les options d'audit


Implémenter la sécurité de la base de données Oracle
• définir des options d'audit pour la table HR.JOBS
• mettre à jour la table


Maintenance de la base de données

Objectifs

• gérer les statistiques destinées à l'optimiseur
• gérer le référentiel AWR (Automatic Workload Repository)
• utiliser le moniteur ADDM (Automatic Database Diagnostic
Monitor)
• décrire et utiliser l'infrastructure de conseil
• définir des seuils d'alerte
• utiliser des alertes générées par le serveur

• utiliser des tâches automatisées

Automatique Tâches Proactive Réactive

automatisées
Infrastructure Alertes Erreurs

de conseil serveur critiques
Référentiel Référentiel
AWR ADR
Efficace

Data warehouse Collecte automatique Accès direct à
de la base des statistiques la mémoire
de données importantes

La maintenance proactive est facilitée par l'infrastructure sophistiquée de la base de données
Oracle, notamment par les éléments suivants :
• AWR (Automatic Workload Repository) est un référentiel intégré dans chaque base
Oracle.
A intervalles réguliers, le serveur de base de données Oracle prend un cliché (snapshot)
de l'ensemble des statistiques essentielles et des informations relatives à la charge
globale, et stocke ces données dans le référentiel AWR. Les données capturées peuvent
faire l'objet d'une analyse, par vous-même et/ou par la base.
• Les tâches automatisées permettent à la base d'effectuer des opérations de maintenance
de routine telles que les sauvegardes régulières, l'actualisation des statistiques destinées à
l'optimiseur et les vérifications de l'état de la base.
La maintenance réactive traite les erreurs et conditions critiques détectées par les vérificateurs
d'intégrité de la base de données :
• Pour les problèmes ne pouvant pas être résolus automatiquement et nécessitant une
notification aux administrateurs (par exemple, un manque d'espace), le serveur de la base
de données Oracle génère des alertes serveur. Le serveur de base de données Oracle se
surveille lui-même par défaut et envoie des alertes pour vous informer des problèmes.
Les alertes fournissent souvent des recommandations sur la manière de résoudre le
problème signalé.
• Ces recommandations sont générées par différentes fonctions de conseil (advisors)
chargées chacune d'un sous-système (la mémoire, les segments ou les instructions SQL,
par exemple).

Afficher l'historique des alertes

Afficher l'historique des alertes

La page Alert History contient un graphique qui présente l'historique des alertes de la base de
données en cours, réparti en segments de temps que vous définissez. Une alerte signale un
problème potentiel : dépassement du seuil d'avertissement ou du seuil critique d'une mesure
surveillée, cible qui n'est plus disponible. Cliquez sur le nom de la mesure qui vous intéresse
dans la page Alert History pour obtenir des statistiques détaillées, des graphiques et des
horodatages réels relatifs à chaque alerte. Vous disposez également d'une zone pour entrer des
commentaires sur l'alerte et notamment sur sa résolution.

Terminologie
• Référentiel AWR (Automatic Workload Repository) :
Infrastructure utilisée pour la collecte et l'analyse de
données, et pour la génération de recommandations.
• Ligne de base AWR : Ensemble de clichés AWR servant
de référence pour la comparaison des performances.
• Mesure de performances : Taux de variation d'une
statistique cumulée.
• Statistiques : Ensembles de données qui fournissent des
détails sur la base de données et ses objets.
– Les statistiques destinées à l'optimiseur sont utilisées

par l'optimiseur d'instructions.
– Les statistiques de la base de données sont utilisées
pour la surveillance des performances.
• Seuil : Valeur limite à laquelle sont comparées
les mesures de performances.
Terminologie
Le référentiel AWR (Automatic Workload Repository) fournit aux composants internes du
serveur Oracle des services de collecte, de traitement, de maintenance et d'utilisation de
statistiques de performances pour la détection des problèmes et le réglage automatique (self-
tuning). L'historique des sessions actives (ASH - Active Session History), stocké dans le
référentiel AWR, répertorie les activités récentes des sessions.
Les statistiques sont des ensembles de données qui fournissent davantage de détails sur la
base et ses objets. Les statistiques destinées à l'optimiseur sont utilisées par ce dernier pour
choisir le meilleur plan d'exécution pour chaque instruction SQL. Les statistiques de la base
de données fournissent des informations pour la surveillance des performances.
Les clichés (snapshots) AWR contiennent des statistiques et des mesures relatives à la base de
données, des statistiques sur les applications (volumes de transactions, temps de réponse), des
statistiques sur le système d'exploitation et d'autres indicateurs. Une ligne de base (baseline)
AWR est un ensemble de clichés AWR collectés pendant une certaine période. La ligne de
base est utilisée pour comparer les performances : comparaison des performances actuelles
par rapport à la ligne de base ou comparaison entre lignes de base.
Par défaut, les données de la ligne de base glissante du système (System Moving Window
Baseline) sont collectées dans Oracle Database 11g. Il s'agit d'un jeu de clichés évolutif qui
inclut par défaut les clichés des huit derniers jours. Cette ligne de base devient valide quand
les données collectées sont suffisantes et que les calculs de statistiques ont été effectués. Par
défaut, les calculs de statistiques ont lieu tous les samedis à minuit.

Présentation de l'optimiseur Oracle
L'optimiseur Oracle détermine le plan d'exécution le plus

efficace et constitue l'étape la plus importante dans le
traitement d'une instruction SQL.
Il effectue les tâches suivantes :
• Evaluer les expressions et les conditions
• Utiliser les statistiques relatives aux objets et au système
• Déterminer la manière d'accéder aux données
• Déterminer la manière de joindre les tables

• Déterminer l'itinéraire le plus efficace
Présentation de l'optimiseur Oracle

L'optimiseur est la partie de la base de données Oracle qui crée le plan d'exécution d'une
instruction SQL. La détermination du plan d'exécution constitue une étape importante dans le
traitement d'une instruction SQL. Elle peut avoir un impact considérable sur la durée
d'exécution.
Le plan d'exécution est une série d'opérations effectuées successivement pour exécuter
l'instruction. L'optimiseur tient compte de plusieurs facteurs liés aux objets référencés et aux
conditions indiquées dans l'interrogation. L'optimiseur a besoin des informations suivantes :
• Statistiques collectées pour le système (E/S, CPU, etc.) et pour les objets de schéma
(nombre de lignes, index, etc.)
• Informations stockées dans le dictionnaire
• Qualificateurs de la clause WHERE
• Conseils fournis par le développeur
Lorsque vous utilisez les outils de diagnostic EXPLAIN PLAN d'Enterprise Manager et
AUTOTRACE de SQL*Plus, vous pouvez examiner le plan d'exécution choisi par l'optimiseur.
Remarque : L'optimiseur Oracle est désigné par deux noms, selon la fonction remplie :
optimiseur d'instructions ou optimiseur ATO (Automatic Tuning Optimizer).

Statistiques destinées à l'optimiseur
Les statistiques destinées à l'optimiseur sont :

• collectées dans un cliché correspondant à un moment donné
• conservées lorsque l'instance est arrêtée puis redémarrée
• collectées automatiquement
SQL> SELECT COUNT(*) FROM hr.employees;
COUNT(*)
----------
214

SQL> SELECT num_rows FROM dba_tables
2 WHERE owner='HR' AND table_name = 'EMPLOYEES';
NUM_ROWS
----------
107
Statistiques destinées à l'optimiseur

Les statistiques destinées à l'optimiseur incluent des données sur les tables, sur les colonnes,
sur les index et sur le système. Les statistiques concernant les tables et les index sont stockées
dans le dictionnaire de données. Ces statistiques ne sont pas destinées à fournir des données en
temps réel. Elles fournissent un cliché (snapshot) statistiquement correct du stockage et de la
répartition des données, que l'optimiseur peut utiliser pour prendre des décisions concernant le
mode d'accès aux données.
Statistiques collectées :
• Taille de la table ou de l'index, en blocs de base de données
• Nombre de lignes
• Taille moyenne des lignes et nombre moyen de chaînages (tables uniquement)
• Hauteur et nombre de lignes feuille supprimées (index uniquement)
Ces faits changent à mesure que des données sont insérées, supprimées et modifiées. La
maintenance en temps réel de statistiques concernant la répartition des données a un coût
prohibitif. Les données sont donc mises à jour via la collecte périodique de statistiques sur les
tables et les index.
Les statistiques destinées à l'optimiseur sont collectées automatiquement par une tâche de
maintenance qui s'exécute dans des fenêtres de maintenance prédéfinies (par défaut, une fois
par jour). L'optimiseur utilise également des statistiques système qui décrivent des
caractéristiques du système d'exploitation. Les statistiques système ne sont pas collectées
automatiquement. Pour plus d'informations, reportez-vous au manuel Oracle Database
Performance Tuning Guide.
Les statistiques destinées à l'optimiseur sont différentes des statistiques sur les performances de
la base de données qui sont collectées dans le cliché AWR (Automatic Workload Repository).

Utiliser la page
Manage Optimizer Statistics

Utiliser la page Manage Optimizer Statistics

Pour gérer les statistiques destinées à l'optimiseur dans Enterprise Manager, cliquez sur
l'onglet Server, puis cliquez sur Manage Optimizer Statistics dans la section Query Optimizer.
Dans cette page, vous pouvez effectuer les opérations suivantes sur les statistiques :
• Collecter manuellement des statistiques destinées à l'optimiseur.
• Restaurer jusqu'à un point dans le temps les statistiques destinées à l'optimiseur. Le point
dans le temps choisi doit être compris dans la période de conservation des statistiques,
qui est par défaut de 30 jours.
• Verrouiller les statistiques destinées à l'optimiseur afin d'éviter la suppression des
informations concernant certains objets. Cela est utile si des statistiques ont été calculées
pour une table à un moment où elle contenait des données particulièrement
représentatives et que vous souhaitez toujours disposer de ces statistiques. Lorsque des
statistiques sont verrouillées, elles ne sont affectées par aucune des fluctuations se
produisant dans la table.
• Déverrouiller des statistiques destinées à l'optimiseur précédemment verrouillées.
• Supprimer des statistiques destinées à l'optimiseur.
Recommandation
Utilisez les tâches de maintenance automatique pour collecter les statistiques destinées à
l'optimiseur. Pour activer la collecte des statistiques destinées à l'optimiseur, vous devez
vérifier que le paramètre d'initialisation STATISTICS_LEVEL a pour valeur TYPICAL ou
ALL.

Collecter manuellement les statistiques
destinées à l'optimiseur

Collecter manuellement les statistiques destinées à l'optimiseur

Vous pouvez être amené à collecter des statistiques manuellement dans certaines situations,
par exemple quand le contenu d'une table a subi tellement de modifications entre deux
collectes automatiques que les statistiques ne sont plus représentatives de la table. Cette
situation est courante pour les tables de grande taille qui sont modifiées à plus de 10 % sur
une période de 24 heures.
Recommandation : Collectez les statistiques assez souvent pour que les modifications
n'atteignent jamais, entre deux collectes, plus de 10 % de la table. Cela peut nécessiter des
collectes manuelles ou des fenêtres de maintenance supplémentaires.
La collecte manuelle de statistiques peut être effectuée à l'aide d'Enterprise Manager ou du
package DBMS_STATS. Pour les statistiques système, vous êtes obligé d'utiliser le package
DBMS_STATS. Les statistiques système décrivent les caractéristiques matérielles du système
qui intéressent l'optimiseur d'instructions, notamment les performances et l'utilisation des
ressources d'E/S et de CPU.
L'option de menu Gather Optimizer Statistics démarre un assistant qui permet de sélectionner
la portée, les objets, les options et le planning d'une tâche de collecte de statistiques destinées
à l'optimiseur. Cet assistant lance une tâche DBMS_STATS.GATHER_*_STATS avec la
portée indiquée (table, schéma ou base de données). Il permet de définir des préférences pour
les valeurs par défaut utilisées par le package DBMS_STATS et de planifier la date et l'heure
d'exécution de la tâche.

Collecter manuellement les statistiques destinées à l'optimiseur (suite)
Il n'est pas recommandé de collecter manuellement les statistiques de routine. En effet, la collecte
automatique effectuée dans les fenêtres de maintenance est plus efficace et perturbe moins les
utilisateurs. Vous pouvez être amené à soumettre une tâche manuelle si la tâche automatique a
échoué ou a été désactivée.
Vous pouvez collecter les statistiques destinées à l'optimiseur via le package DBMS_STATS
directement :
SQL> EXEC dbms_stats.gather_table_stats('HR','EMPLOYEES');
SQL> SELECT num_rows FROM dba_tables
2 WHERE owner='HR' AND table_name = 'EMPLOYEES';
NUM_ROWS
----------
214
Notez que le nombre de lignes reflète désormais correctement les données qui se trouvaient dans la
table au moment de la collecte des statistiques. DBMS_STATS permet également la collecte

manuelle de statistiques pour un schéma entier, voire pour l'ensemble de la base de données.
Les statistiques système ne changent que si la charge globale varie de manière significative. Ces
statistiques ne nécessitent donc pas de réajustements fréquents. La procédure
DBMS_STATS.GATHER_SYSTEM_STATS collecte les statistiques système sur une période
spécifique, mais vous pouvez lancer la collecte et l'arrêter manuellement lorsque vous le désirez.
Recommandation : Utilisez la commande suivante lorsque vous créez une base de données :
SQL> EXEC dbms_stats.gather_system_stats('NOWORKLOAD');
L'option NOWORKLOAD augmente de quelques minutes le temps de traitement de l'instruction (en
fonction de la taille de la base de données). Elle capture des estimations de caractéristiques d'E/S
telles que le temps moyen de recherche en lecture et le taux de transfert des E/S.

Préférences relatives à la collecte des statistiques
PORTEE
INSTRUCTION
PREFERENCES
TABLE
CASCADE
SCHEMA DEGREE
Tâche de collecte
des statistiques BASE DE DONNEES ESTIMATE_PERCENT
destinées à l'optimiseur
NO_INVALIDATE
GLOBALE
METHOD_OPT

GRANULARITY
INCREMENTAL
DBA PUBLISH
DBMS_STATS
set | get | delete | export | import STALE_PERCENT
exec dbms_stats.set_table_prefs('SH','SALES','STALE_PERCENT','13');
Préférences relatives à la collecte des statistiques

Les procédures DBMS_STATS.GATHER_*_STATS peuvent être appelées à différents
niveaux pour collecter les statistiques relatives à l'ensemble d'une base de données ou à des
objets précis (tels que des tables). Dans les appels de procédures GATHER_*_STATS,
plusieurs paramètres admettent souvent des valeurs par défaut. Ces valeurs par défaut sont
correctes pour la plupart des objets de la base, mais elles doivent être modifiées pour certains.
Pour vous éviter d'exécuter des tâches manuelles pour chacun de ces objets, Oracle
Database 11g permet de définir des valeurs (appelées préférences) associées aux différents
objets, schémas ou bases de données, mais aussi de modifier les valeurs par défaut à l'aide
d'une commande globale.
Les préférences définissent des paramètres transmis aux procédures de collecte. Les
procédures SET_*_PREFS créent des valeurs de préférence pour les objets qui
n'appartiennent ni à SYS, ni à SYSTEM. Elles permettent au DBA de définir des préférences
globales pour tous les paramètres qui concernent l'ensemble de la base. Ces préférences seront
appliquées à tous les paramètres qui acceptent une valeur par défaut.
La procédure SET_DATATBASE_PREFS s'exécute de manière répétitive sur toutes les tables
et tous les schémas de la base de données pour établir la préférence spécifiée. La procédure
SET_SCHEMA_PREFS s'exécute uniquement sur les tables du schéma indiqué. La procédure
SET_TABLE_PREFS s'applique à une seule table.
Toutes les préférences sur les objets (qu'elles soient définies au niveau de la base de données,
d'un schéma ou d'une table) sont stockées dans une seule table. Si vous modifiez des
préférences au niveau schéma, elles remplacent celles définies précédemment au niveau table.

Préférences relatives à la collecte des statistiques (suite)
Lorsque les différentes procédures de collecte s'exécutent, elles extraient les préférences qui ont été
définies au niveau de chaque objet. Pour consulter les préférences définies au niveau des objets,
utilisez la vue DBA_TAB_STAT_PREFS. Les préférences qui ne sont pas définies au niveau des
objets seront de niveau global. Vous pouvez consulter les préférences de niveau global en appelant la
procédure DBMS_STATS.GET_PREFS.
Ces préférences peuvent être définies, extraites, supprimées, exportées et importées à chaque niveau :
table, schéma, base de données, global. Les valeurs des préférences sont en principe définies du
niveau global au niveau table, de sorte qu'elles s'appliquent au groupe le plus restreint en dernier lieu.
Préférences Oracle Database 11g :
• CASCADE indique si les statistiques d'index sont collectées avec les statistiques sur les tables.
• DEGREE définit le degré de parallélisme utilisé pour collecter les statistiques.
• PUBLISH permet de publier les statistiques dans le dictionnaire ou de les stocker dans une zone
privée. La seconde solution permet au DBA de valider les statistiques avant de les publier dans

le dictionnaire de données à l'aide de la procédure PUBLISH_PENDING_STATS.
• STALE_PERCENT permet de déterminer le seuil à partir duquel les statistiques relatives à un
objet sont obsolètes. La valeur de cette préférence correspond au pourcentage de lignes
modifiées depuis la dernière collecte de statistiques. L'exemple présenté dans la diapositive
remplace la valeur par défaut (10 %) par 13 % pour SH.SALES.
• INCREMENTAL permet de collecter des statistiques globales sur des tables partitionnées, de
manière incrémentielle.
• METHOD_OPT détermine les colonnes et les paramètres d'histogramme qui sont utilisés pour
collecter les statistiques relatives aux colonnes.
• GRANULARITY détermine le niveau de détail des statistiques à collecter (pour les tables
partitionnées uniquement).
• NO_INVALIDATE détermine si les curseurs doivent être invalidés.
• ESTIMATE_PERCENT permet de déterminer le nombre de lignes à échantillonner pour obtenir
des statistiques représentatives. Il s'agit d'un pourcentage du nombre de lignes de la table.
Remarque : Pour plus d'informations sur ces préférences, reportez-vous à la documentation relative
à DBMS_STATS dans le manuel Oracle Database PL/SQL Packages and Types Reference.
Vous pouvez supprimer des préférences au niveau d'une table, d'un schéma ou d'une base de données
en utilisant des procédures DBMS_STATS.DELETE_*_PREFS. La procédure
DBMS_STATS.RESET_PARAM_DEFAULTS permet de réinitialiser les préférences globales pour
qu'elles reprennent leurs valeurs par défaut.

Référentiel AWR
• Référentiel intégré pour les informations relatives aux

performances
• Clichés des mesures de performances de la base de
données pris toutes les 60 minutes et conservés pendant
8 jours
• Base de toutes les fonctions de gestion automatique

Statistiques 60 minutes
en mémoire MMON Clichés
SGA
AWR
Référentiel AWR
Le référentiel AWR (Automatic Workload Repository) est l'infrastructure qui fournit aux
composants d'Oracle Database 11g des services de collecte, de maintenance et d'utilisation de
statistiques pour la détection des problèmes et le réglage automatique (self-tuning). Il peut
être considéré comme un data warehouse dans lequel sont stockées les statistiques relatives à
la base de données, les mesures de performances, etc.
Toutes les 60 minutes (par défaut), la base capture automatiquement des informations
statistiques à partir de la mémoire SGA et les place dans le référentiel AWR sous la forme de
clichés (snapshots). Les clichés sont enregistrés sur disque par un processus en arrière-plan
nommé MMON (Manageability Monitor). Par défaut, les clichés sont conservés pendant huit
jours. Vous pouvez modifier l'intervalle de capture et la période de conservation des clichés.
Le référentiel AWR contient des centaines de tables, appartenant toutes au schéma SYSMAN
et stockées dans le tablespace SYSAUX. Oracle recommande d'utiliser Enterprise Manager ou
le package DBMS_WORKLOAD_REPOSITORY pour travailler avec le référentiel AWR.
L'exécution directe d'instructions LMD (langage de manipulation de données) sur les tables
du référentiel n'est pas prise en charge.

Infrastructure du référentiel AWR
Clients externes
EM SQL*Plus …
SGA
Collecte V$ DBA_*
efficace de Clichés
statistiques AWR
en mémoire MMON

Composant … Composant
Clients internes ADDM à réglage à réglage
automatique automatique
Infrastructure du référentiel AWR

Les principaux éléments de l'infrastructure du référentiel AWR (Automatic Workload
Repository) sont les suivants :
• Une fonction de collecte de statistiques en mémoire utilisée par les composants d'Oracle
Database 11g. Ces statistiques sont stockées en mémoire pour des raisons de
performances. Elles sont accessibles par l'intermédiaire des vues dynamiques des
performances (V$).
• Les clichés (snapshots) AWR qui représentent la partie persistante de la fonction. Ils sont
accessibles via les vues du dictionnaire de données et Enterprise Manager Database
Control.
Les statistiques sont placées dans la zone de stockage persistant pour plusieurs raisons :
• Elles ne doivent pas être perdues en cas de panne d'une instance.
• Certaines analyses nécessitent des données historiques pour les comparaisons avec une
ligne de base (baseline).
• Un débordement de mémoire peut se produire. Lorsque des anciennes statistiques sont
remplacées par de nouvelles en raison d'un manque de mémoire, les données remplacées
peuvent être stockées en vue d'une utilisation ultérieure.
La version en mémoire des statistiques est transférée régulièrement sur le disque par le
processus en arrière-plan MMON. Grâce au référentiel AWR, la base Oracle permet de capturer
automatiquement des données statistiques historiques sans l'intervention du DBA.

Lignes de base AWR
Période d'intérêt
dans le passé

DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE ( -
start_snap_id IN NUMBER,
end_snap_id IN NUMBER,
baseline_name IN VARCHAR2);
Lignes de base AWR

Une ligne de base AWR (Automatic Workload Repository) est un jeu de clichés AWR. Il
s'agit généralement d'un ensemble de données capturées pour une période importante qui est
identifié et conservé dans le référentiel AWR. Une ligne de base est définie par une paire de
clichés. Ces derniers sont identifiés par leur numéro de séquence (snap_id) ou par un
horodatage de début et de fin. Chaque jeu comprend tous les clichés compris entre un cliché
de début et un cliché de fin. Les jeux de clichés sont utilisés pour conserver les données de
clichés. Les clichés appartenant à un jeu sont donc conservés jusqu'à la suppression de ce
dernier. Vous pouvez définir la durée de conservation (en jours) des clichés.
Une ligne de base est identifiée par un nom fourni par l'utilisateur. Pour créer une ligne de
base à partir d'un ensemble de clichés, exécutez la procédure CREATE_BASELINE et
indiquez un nom et deux identificateurs de cliché. La nouvelle ligne de base reçoit un
identificateur unique (dont l'unicité est garantie pendant la durée de vie de la base de
données). En règle générale, vous définissez les lignes de base pour des périodes passées
représentatives en vue de comparaisons avec le comportement actuel du système. Vous
pouvez également configurer des alertes basées sur des seuils en utilisant des lignes de base à
partir de Database Control. Cette procédure permet de définir un délai d'expiration en jours.
Sa valeur par défaut est NULL et signifie "n'expire jamais".
Vous pouvez obtenir les numéros de séquence (snap_id) directement à partir de
DBA_HIST_SNAPSHOT ou à l'aide de Database Control.
Remarque : Pour plus d'informations sur le package DBMS_WORKLOAD_REPOSITORY,
reportez-vous au manuel Oracle Database PL/SQL Packages and Types Reference.

Enterprise Manager et référentiel AWR

Enterprise Manager et référentiel AWR

Cliquez sur l'onglet Server, puis sur l'option Automatic Workload Repository dans la section
Statistics Management. Dans la page Automatic Workload Repository, cliquez sur Edit pour
modifier les paramètres.
Dans la page Automatic Workload Repository, vous pouvez effectuer les opérations
suivantes :
• Modifier les paramètres du référentiel de charge globale (Workload Repository)
• Consulter les informations détaillées sur les clichés créés et créer manuellement d'autres
clichés
• Créer des lignes de base AWR
• Générer un état AWR

Gérer le référentiel AWR
• Période de conservation
– Durée par défaut : Huit jours
– Tenez compte des besoins
en termes de stockage
• Intervalle de collecte
– Toutes les 60 minutes
par défaut
– Tenez compte des besoins
en termes de stockage et
de l'impact sur les performances

• Niveau de collecte
– Basic (désactive la plupart des fonctionnalités ADDM)
– Typical (niveau recommandé)
– All (ajoute aux clichés des informations complémentaires de
réglage des instructions SQL)
Gérer le référentiel AWR

Les paramètres AWR incluent la période de conservation, l'intervalle de collecte et le niveau
de collecte. N'oubliez pas que la diminution de la valeur de l'un ou l'autre de ces paramètres
influe sur le fonctionnement des composants qui dépendent du référentiel AWR, notamment
les fonctions de conseil.
L'augmentation de la valeur des paramètres peut améliorer l'efficacité des recommandations
des fonctions de conseil, mais cela a un coût en ce qui concerne l'espace requis pour les
clichés et les ressources consacrées à la collecte des clichés.
Vous pouvez utiliser le niveau de collecte ALL lors du réglage (tuning) d'une nouvelle
application. Cette valeur entraîne la collecte de plans d'exécution SQL et de statistiques
temporelles qui améliorent les recommandations des fonctions de conseil SQL. Une fois le
réglage terminé, rétablissez la valeur TYPICAL.

Niveaux de statistiques
STATISTICS_LEVEL
BASIC TYPICAL ALL

Statistiques
Fonctionnalités de réglage Valeur par défaut supplémentaires pour
automatique désactivées recommandée le diagnostic manuel
d'instructions SQL
Niveaux de statistiques
Le paramètre d'initialisation STATISTICS_LEVEL contrôle la capture de diverses
statistiques et des fonctions de conseil, notamment les tâches de maintenance automatique.
Celles-ci comprennent la collecte des statistiques destinées à l'optimiseur. Le paramètre
STATISTICS_LEVEL admet les valeurs suivantes :
• BASIC : Le calcul des statistiques et des mesures de performances AWR est désactivé.
La collecte automatique des statistiques destinées à l'optimiseur est désactivée, de même
que toutes les fonctions de conseil et les alertes générées par le serveur.
• TYPICAL : Les principales statistiques nécessaires à la gestion automatique de la base
de données sont collectées. Il s'agit des statistiques nécessaires pour surveiller le
comportement de la base Oracle. Cette collecte automatique réduit la probabilité
d'obtenir des instructions SQL mal optimisées en raison de statistiques obsolètes ou non
valides.
• ALL : Toutes les statistiques possibles sont capturées. Ce niveau de capture inclut les
statistiques temporelles du système d'exploitation et les statistiques d'exécution des plans.
Ces statistiques sont la plupart du temps inutiles, sauf pour certains tests de diagnostic
bien précis. Il est préférable de ne pas les collecter pour préserver les performances.
Oracle recommande de conserver la valeur par défaut TYPICAL du paramètre
STATISTICS_LEVEL. En effet, le niveau BASIC désactive la collecte automatique des
statistiques destinées à l'optimiseur.

Moniteur ADDM
• Exécution après chaque cliché AWR

• Surveillance de l'instance et détection des goulets
d'étranglement
• Stockage des résultats dans le référentiel AWR
Clichés

Enterprise ADDM
Manager Résultats ADDM
AWR
Moniteur ADDM
Contrairement aux autres fonctions de conseil, le moniteur ADDM (Automatic Database
Diagnostic Monitor) s'exécute automatiquement après chaque cliché AWR. Chaque fois qu'un
cliché est pris, il procède à l'analyse de la période correspondant aux deux derniers clichés. Le
moniteur ADDM surveille l'instance de manière proactive et détecte les goulets
d'étranglement avant qu'ils ne posent un réel problème.
Dans de nombreux cas, le moniteur ADDM recommande des solutions pour les problèmes
détectés. Il quantifie même les avantages induits par les recommandations.
Voici quelques-uns des problèmes courants détectés par le moniteur ADDM :
• Goulets d'étranglement au niveau CPU
• Gestion inefficace des connexions Oracle Net
• Contention liée à un verrou
• Capacité d'entrée/sortie (E/S)
• Sous-dimensionnement des structures mémoire Oracle
• Instructions SQL à forte consommation de ressources
• Temps PL/SQL et Java élevés
• Nombreux points de reprise (checkpoints) et cause (par exemple, des fichiers journaux
trop petits)
Les résultats de chaque analyse ADDM sont stockés dans le référentiel AWR. Ils sont
également accessibles via Enterprise Manager.

Résultats ADDM

3
Résultats ADDM
La page Automatic Database Diagnostic Monitor (ADDM) affiche les résultats détaillés de la
dernière exécution du moniteur ADDM. Database Time représente le temps d'activité total
des sessions dans la base de données au cours de la période d'analyse. Un pourcentage
d'impact spécifique est indiqué pour chacun des résultats. L'impact représente le temps
consommé par le problème par rapport au temps d'activité de la base de données au cours de
la période d'analyse.
La diapositive ci-dessus appelle les remarques suivantes :
1. Le graphique indique que le nombre moyen d'utilisateurs actifs a énormément augmenté
à ce stade. En outre, le problème principal était un problème de type Wait.
2. L'icône indique que la sortie ADDM affichée au bas de la page correspond à ce point
dans le temps. Vous pouvez remonter dans le passé (pour consulter des analyses
antérieures) en cliquant sur les autres icônes.
3. Les résultats fournissent un bref récapitulatif des zones réglables trouvées par le moniteur
ADDM. Si vous cliquez sur un problème particulier, vous accédez à la page Performance
Finding Details.
Cliquez sur le bouton View Report pour obtenir des détails sur l'analyse de performances sous
la forme d'un état au format texte.

Recommandations ADDM

Recommandations ADDM
Dans la page Performance Finding Details, des recommandations indiquent comment
résoudre les problèmes détectés. Ces recommandations sont regroupées en différentes
catégories : Schema, SQL Tuning, Database Configuration et beaucoup d'autres. La colonne
Benefit (%) indique le gain maximal qui pourrait être obtenu sur le temps d'exécution de
la base de données suite à l'implémentation de la recommandation.
Le moniteur ADDM (Automatic Database Diagnostic Monitor) étudie diverses modifications
du système et ses recommandations peuvent porter sur les points suivants :
• Modifications matérielles : Ajout de CPU ou modification de la configuration du sous-
système d'E/S.
• Configuration de la base de données : Modification de la valeur de certains paramètres
d'initialisation.
• Modifications au niveau schéma : Partitionnement par hachage d'une table ou d'un
index, ou utilisation de la gestion automatique de l'espace dans les segments.
• Modifications au niveau application : Utilisation de l'option de mise en cache pour les
séquences ou utilisation de variables attachées (bind variables).
• Utilisation d'autres fonctions de conseil : Exécution de SQL Tuning Advisor pour les
instructions SQL à forte consommation de ressources ou exécution de Segment Advisor
pour les objets qui utilisent beaucoup d'espace.

Infrastructure de conseil
SQL Tuning Buffer Cache

ADDM
Advisor PGA Advisor
Advisor
SQL Access Shared Pool
Advisor Advisor
Memory Java Pool

Advisor SGA Advisor
Advisor
Streams Pool
Advisor

Segment Advisor
Espace
Undo Advisor
Sauvegarde MTTR Advisor
Infrastructure de conseil
Les fonctions de conseil (advisors) fournissent des informations sur l'utilisation des ressources
et sur les performances des composants qu'elles analysent. Par exemple, Memory Advisor
propose une valeur recommandée pour le paramètre d'initialisation MEMORY_TARGET qui
contrôle la quantité de mémoire totale utilisée par l'instance Oracle Database.
En se fondant sur les données capturées dans le référentiel AWR (Automatic Workload
Repository), le moniteur ADDM permet à la base de données Oracle d'établir un diagnostic
sur ses propres performances et de déterminer la façon dont les problèmes identifiés peuvent
être résolus. Le moniteur ADDM s'exécute automatiquement après chaque capture de
statistiques AWR. Il peut éventuellement appeler d'autres fonctions de conseil.
Les avantages principaux fournis par l'infrastructure de conseil sont les suivants :
• Toutes les fonctions de conseil utilisent une même interface.
• Toutes les fonctions de conseil ont une zone de stockage commune pour leurs données
source et pour leurs résultats : le référentiel de charge globale (Workload Repository).
La diapositive ci-dessus ne répertorie pas toutes les fonctions de conseil (par exemple, elle ne
mentionne pas Data Recovery Advisor et SQL Repair Advisor).
Moniteur ADDM
Le moniteur ADDM (Automatic Database Diagnostic Monitor) est un outil d'analyse hébergé
sur le serveur qui examine les performances de la base de données toutes les 60 minutes. Son
but est de détecter de manière précoce les goulets d'étranglement du système et de
recommander des correctifs avant toute dégradation perceptible des performances.

Infrastructure de conseil (suite)
Memory Advisor
Memory Advisor est en fait un ensemble de plusieurs fonctions qui permettent de déterminer les
réglages les plus efficaces pour la mémoire totale utilisée par l'instance de base de données. La mémoire
SGA (System Global Area) comprend un ensemble de fonctions de conseil pour la zone de mémoire
partagée, le cache de tampons (buffer cache) de la base de données, la zone de mémoire Java et la zone
de mémoire Streams. Les fonctions de conseil des zones de mémoire Java et Streams ne sont pas
affichées dans la page Memory Advisor d'Enterprise Manager. Il existe une fonction de conseil pour la
mémoire PGA (Program Global Area) qui offre un point de contrôle central pour la zone de mémoire
LARGE POOL et la zone de mémoire Java.
MTTR Advisor
MTTR Advisor vous permet de définir le temps nécessaire à la récupération de la base de données
(MTTR - Mean Time To Recover) suite à une panne de l'instance.
Segment Advisor

Cette fonction de conseil recherche les tables et les index qui consomment plus d'espace que nécessaire.
Elle recherche toute consommation inutile d'espace au niveau tablespace ou schéma et génère des scripts
permettant de réduire cette consommation lorsque cela s'avère possible.
SQL Access Advisor
Cette fonction de conseil analyse toutes les instructions SQL exécutées au cours d'une période donnée et
suggère la création d'index ou de vues matérialisées supplémentaires qui permettront d'optimiser les
performances.
SQL Tuning Advisor
Cette fonction de conseil analyse une instruction SQL individuelle et fournit des recommandations pour
l'optimisation de ses performances. Les recommandations peuvent inclure des actions telles que la
réécriture de l'instruction, la modification de la configuration de l'instance, ou encore l'ajout d'index. La
fonction de conseil SQL Tuning Advisor n'est pas appelée directement. Elle est appelée à partir d'autres
outils (tels que Top SQL ou Top Sessions) pour optimiser les instructions SQL qui consomment le plus.
Undo Management Advisor
Undo Management Advisor vous permet de déterminer la taille que doit avoir le tablespace d'annulation
pour la prise en charge d'une période de conservation donnée. La gestion des annulations et l'utilisation
de cette fonction de conseil sont étudiées dans le chapitre "Gérer les données d'annulation".
Data Recovery Advisor
Cette fonction de conseil effectue automatiquement le diagnostic de panne pour les données persistantes,
propose des options de réparation et exécute les réparations demandées par l'utilisateur. Son but est de
réduire la durée moyenne de récupération (MTTR) et de fournir un outil centralisé pour la réparation
automatisée des données.
SQL Repair Advisor
Vous exécutez SQL Repair Advisor après l'échec d'une instruction SQL avec une erreur critique qui
génère un problème dans le référentiel ADR (Automatic Diagnostic Repository). Cette fonction de
conseil analyse l'instruction et recommande la plupart du temps un patch pour la réparer. Si vous
implémentez la réparation recommandée, le patch SQL appliqué évite l'échec de l'instruction en forçant
l'optimiseur d'instructions à choisir un autre plan d'exécution à l'avenir. L'instruction SQL elle-même
n'est pas modifiée.

Enterprise Manager et les fonctions de conseil

Enterprise Manager et les fonctions de conseil

La page Advisor Central est la page principale de toutes les fonctions de conseil (advisors).
Pour y accéder, cliquez sur le lien Advisor Central dans la liste Related Links de la page
d'accueil Database Control. Toutefois, les fonctions de conseil peuvent également être
appelées depuis d'autres emplacements dans Database Control. Il est aussi possible d'y
accéder dans certains contextes spécifiques.
L'onglet Advisors de la page Advisor Central répertorie toutes les tâches de conseil qui sont
enregistrées au niveau du référentiel de charge globale (Workload Repository). Vous pouvez
filtrer cette liste par type de fonction de conseil et pour des périodes prédéfinies.
L'onglet Checkers de la page Advisor Central permet de programmer divers vérificateurs
d'intégrité de la base. Vous pouvez afficher tous les vérificateurs exécutés par nom, par type
ou par période.
Certaines fonctions de conseil sont décrites plus en détail dans les chapitres "Gérer les
données d'annulation", "Gérer les performances" et "Concepts de sauvegarde et de
récupération".
Remarque : Utilisez la page Change Default Parameters pour modifier le délai d'expiration
par défaut (en jours) pour toutes les tâches futures. Vous pouvez également utiliser cette page
pour modifier les paramètres de certaines fonctions de conseil importantes.

Package DBMS_ADVISOR
Procédure Description
CREATE_TASK Crée une tâche dans le référentiel
DELETE_TASK Supprime une tâche du référentiel
EXECUTE_TASK Lance l'exécution d'une tâche
INTERRUPT_TASK Suspend une tâche en cours d'exécution
GET_TASK_REPORT Crée et renvoie un état au format texte

pour la tâche indiquée
RESUME_TASK Entraîne la reprise d'une tâche suspendue
UPDATE_TASK_ATTRIBUTES Met à jour les attributs de tâche

SET_TASK_PARAMETER Modifie un paramètre de tâche
MARK_RECOMMENDATION Marque une ou plusieurs recommandations
comme acceptées, rejetées ou ignorées
GET_TASK_SCRIPT Crée un script permettant d'implémenter
toutes les recommandations acceptées
Package DBMS_ADVISOR
Le package DBMS_ADVISOR contient l'ensemble des constantes et des déclarations de
procédure qui s'appliquent aux modules de conseil. Vous pouvez l'utiliser pour exécuter des
tâches à partir de la ligne de commande.
Pour exécuter des procédures de conseil, vous devez disposer du privilège ADVISOR. Ce
privilège offre un accès complet aux procédures et aux vues des fonctions de conseil.
Remarque : Pour plus d'informations sur toutes les procédures du package DBMS_ADVISOR,
reportez-vous au manuel Oracle Database PL/SQL Packages and Types Reference.

Quiz
La statistique num_rows destinée à l'optimiseur reflète toujours

le nombre de lignes réel d'une table.
1. Vrai
2. Faux

Réponse : 2

Tâches de maintenance automatisées
Processus de maintenance automatisé :
1. La fenêtre de maintenance s'ouvre.
2. Un processus en arrière-plan planifie les tâches.
3. Le planificateur lance les tâches.
4. Resource Manager limite l'impact des tâches automatisées
sur les performances.
Tâches de maintenance automatisées par défaut :
• Collecte des statistiques destinées à l'optimiseur
(Optimizer Statistics Gathering)

• Gestion automatique des segments (Segment Advisor)
• Réglage automatique des instructions SQL
(Automatic SQL Tuning)

En analysant les informations stockées dans le référentiel AWR, la base de données peut
déterminer s'il est nécessaire d'effectuer des tâches de maintenance de routine, telles que la
régénération des statistiques destinées à l'optimiseur. L'infrastructure d'automatisation des
tâches de maintenance permet à la base Oracle d'effectuer automatiquement ces opérations.
Elle utilise le planificateur pour exécuter ces tâches dans des fenêtres de maintenance
prédéfinies.
Par défaut, les fenêtres de maintenance commencent à 22 heures les jours ouvrés et durent
4 heures. Le samedi et le dimanche, la fenêtre de maintenance commence à 6 heures du matin
et dure 20 heures. Tous les attributs des fenêtres de maintenance sont personnalisables,
notamment les heures de début et de fin, la fréquence, les jours de la semaine, etc. Par
ailleurs, il est possible de limiter l'impact des tâches de maintenance automatisées sur le
fonctionnement normal de la base en associant un plan d'allocation de ressources Database
Resource Manager à la fenêtre de maintenance.
Exemples de tâches de maintenance :
• Les statistiques destinées à l'optimiseur sont régénérées automatiquement à l'aide de
l'infrastructure d'automatisation des tâches de maintenance.
• La fonction de conseil de segmentation automatique (Segment Advisor) comporte des
tâches par défaut qui sont exécutées dans la fenêtre de maintenance.
• Lorsque vous créez une base de données avec DBCA, vous pouvez lancer des
sauvegardes régulières de celle-ci.


Tâches de maintenance automatisées (suite)

Lorsque vous cliquez sur Automated Maintenance Tasks dans la section Scheduler de la page
Server, vous accédez à la page Automated Maintenance Task dans laquelle vous pouvez
consulter le planning des tâches de maintenance automatisées et un historique récent. Vous
avez ensuite la possibilité d'effectuer une analyse descendante pour voir les détails de
certaines tâches. Cliquez sur Configure pour atteindre la page Automated Maintenance Tasks
Configuration. Une tâche s'exécute dans une fenêtre. Le graphique indique la dernière fenêtre
dans laquelle une tâche a été exécutée, ainsi que la fenêtre suivante pour la prochaine
exécution planifiée.
Remarque : La diapositive affiche les fenêtres par défaut. A la fin de la fenêtre de
maintenance, le planificateur arrête par défaut la collecte des statistiques destinées à
l'optimiseur. Les objets restants sont traités au cours de la fenêtre de maintenance suivante.

Configuration des tâches
de maintenance automatisées

Configuration des tâches de maintenance automatisées

Dans la page Automated Maintenance Tasks Configuration, vous pouvez activer et désactiver
les tâches de maintenance automatiques, soit toutes à la fois, soit une par une, soit par fenêtre
de maintenance. Vous pouvez également configurer les paramètres utilisés pour la collecte
des statistiques destinées à l'optimiseur et les paramètres de contrôle des tâches pour la
fonction de conseil automatique SQL Tuning Advisor.
Sélectionnez le nom de la fenêtre pour laquelle vous voulez afficher ou modifier la
planification des fenêtres.
Cliquez sur Edit Window Group pour ajouter ou supprimer des fenêtres dans le groupe.

Alertes générées par le serveur
Enterprise Manager
File d'attente
des alertes
Instance serveur

Oracle
La mesure de performances
dépasse le seuil.
Référentiel AWR
Alertes générées par le serveur

Les alertes sont des notifications qui vous sont envoyées quand une base de données présente
un état indésirable et nécessite votre attention. Par défaut, la base Oracle fournit des alertes
via Enterprise Manager Database Control. Enterprise Manager peut être configuré pour
envoyer à l'administrateur des messages électroniques concernant les problèmes, et pour
afficher des informations d'alerte sur la console.
Vous pouvez également définir des seuils pour de nombreuses mesures de performances
importantes du système. Oracle Database 11g vous informe de manière proactive si les
valeurs mesurées pour la base s'écartent des valeurs normales au point d'atteindre ces seuils.
Une notification précoce des problèmes potentiels vous permet de réagir rapidement. Souvent,
vous pouvez résoudre les problèmes avant même que les utilisateurs ne les remarquent.
Soixante mesures environ sont surveillées par défaut, parmi lesquelles :
• Broken Job Count
• Database Time Spent Waiting (%)
• Dump Area Used (%)
• SQL Response Time (%) par rapport à la ligne de base (baseline)
• Tablespace Used (%)
• Generic Incident
Quelques mesures de performances permettent une notification précoce des problèmes :
• Average File Read Time (en centièmes de seconde)
• Response Time (par transaction)
• Wait Time (%)

Définir des seuils

Définir des seuils

Pour définir ou modifier un seuil concernant l'ensemble de la base de données, sélectionnez
"Metric and Policy Settings" dans la région Related Links de la page d'accueil de la base de
données. Entrez les valeurs de votre choix pour les seuils d'avertissement (Warning) et
critique (Critical). Les alertes appropriées apparaissent lorsque la base de données atteint les
valeurs indiquées.
Les seuils déjà définis s'affichent dans la liste "Metrics with thresholds". Par défaut, 60
mesures de performances environ présentent des seuils prédéfinis, que vous pouvez modifier
au besoin. La liste "All metrics" répertorie les mesures pour lesquelles aucun seuil n'est défini.
Cliquez sur l'une des icônes Edit pour accéder à une page dans laquelle vous pouvez indiquer
des actions correctives supplémentaires pour les seuils d'avertissement ou critiques.
Cliquez sur un lien Collection Schedule et modifiez l'intervalle de collecte planifié.
Souvenez-vous que chaque planning affecte un groupe de mesures.

Créer et tester une alerte
1. Indiquez un seuil.
2. Créez un scénario
de test.
3. Recherchez une alerte. 1

3
Créer et tester une alerte

Vous pouvez également définir des seuils pour un objet spécifique.
Exemple
Vous décidez que vous avez besoin de recevoir une alerte critique si l'espace utilisé dans le
tablespace INVENTORY dépasse 75 %. (Ce tablespace n'autorise pas l'extension automatique
de ses fichiers de données.) Pour créer et tester l'alerte, procédez comme suit :
1. Dans Enterprise Manager, accédez à la page "Metrics and Policy Settings", puis cliquez
sur l'icône Edit correspondant au seuil Tablespace Used (%). Définissez le seuil de votre
choix pour le tablespace.
2. Dans l'onglet Schema de la page Tables, créez une table pour tester l'alerte. Utilisez
l'action "Define using SQL" pour dupliquer une table existante. La valeur initiale (8 Mo)
de la clause STORAGE oblige la table à allouer immédiatement 80 % du tablespace
INVENTORY de 10 Mo.
3. Lorsque vous recevez une erreur indiquant que cette table ne peut pas être étendue,
consultez la page d'accueil de la base de données pour visualiser l'alerte générée. La
mesure Tablespace Space Used (%) est collectée toutes les 10 minutes par défaut.
La plupart des alertes contiennent le nom d'une fonction de conseil associée que vous pouvez
appeler pour obtenir des recommandations plus détaillés. Dans Database Control, le lien
associé à chaque message d'alerte permet d'appeler la fonction de conseil appropriée.

Notification des alertes

Notification des alertes

Le mécanisme de notification utilise l'interface Enterprise Manager. Il est basé sur le concept
d'une règle de notification qui établit le mécanisme de notification approprié pour un
ensemble d'alertes à venir.
Vous pouvez modifier les règles de notification à partir de Database Control. Dans la page
d'accueil, cliquez sur le lien Preferences pour afficher la page General dans laquelle vous
pouvez indiquer l'adresse électronique de réception des notifications.
Dans cette même page, cliquez sur le lien Rules dans la région Notification. Sélectionnez la
règle "Database Availability and Critical States", puis cliquez sur le bouton Edit. Vous
accédez à la page "Edit Notification Rule Database Availability and Critical States" dans
laquelle vous pouvez sélectionner l'onglet Metrics et modifier les mesures de performances
pour lesquelles vous souhaitez recevoir des notifications.

Notification des alertes (suite)
Vous pouvez éventuellement demander qu'Enterprise Manager vous informe directement lorsque des
alertes spécifiques se produisent. Par exemple, si vous indiquez que vous souhaitez recevoir une
notification par courrier électronique pour les alertes critiques et que vous avez défini un seuil
critique concernant le temps de réponse du système pour chaque mesure de performances appelée,
vous pouvez envoyer un courrier électronique contenant un message de type :
Host Name=mydb.us.mycompany.com
Metric=Response Time per Call
Timestamp=08-NOV-2005 10:10:01 (GMT -7:00)
Severity=Critical
Message=Response time per call has exceeded the threshold. See
the latest ADDM analysis.
Rule Name= Rule
Owner=SYSMAN

Le courrier électronique contient un lien menant au nom d'hôte et à la dernière analyse ADDM.
Par défaut, les alertes correspondant à un état critique (telles que DB Down, Generic Alert Log Error
Status et Tablespace Used) sont associées à une notification. Toutefois, pour recevoir ces
notifications, vous devez effectuer la configuration suivante :
1. Dans n'importe quelle page de Database Control, cliquez sur le lien Setup dans l'en-tête et dans
le pied de page.
2. Dans la page Setup, sélectionnez Notification Methods.
3. Entrez les informations requises dans la région Mail Server de la page Notifications Methods.
Il existe d'autres méthodes de notification, notamment les scripts et les interruptions SNMP
(Simplified Network Management Protocol). Ces dernières peuvent être utilisées pour communiquer
avec des applications tierces.
Pour recevoir les notifications :
1. Dans n'importe quelle page de Database Control, cliquez sur le lien Preferences dans l'en-tête et
dans le pied de page.
2. Dans la page Preferences, sélectionnez General. Entrez votre adresse électronique dans la région
E-mail Addresses.
3. Vous pouvez éventuellement modifier les règles de notification (par exemple, vous pouvez
modifier le niveau de gravité déclenchant la notification). Pour cela, cliquez sur Notification
Rules. La page Notification Rules apparaît.
Remarque : Pour plus d'informations sur la configuration des règles de notification, reportez-
vous au manuel Oracle Enterprise Manager Advanced Configuration.

Réagir aux alertes
• Si nécessaire, rassemblez davantage d'informations (par

exemple, en exécutant le moniteur ADDM ou une autre
fonction de conseil).
• Examinez les erreurs critiques.
• Prenez les mesures correctives appropriées.
• Accusez réception des alertes qui ne sont pas effacées
automatiquement.

Réagir aux alertes

Lorsque vous recevez une alerte, suivez les recommandations qu'elle fournit. Vous pouvez
également exécuter le moniteur ADDM (ou une autre fonction de conseil plus appropriée)
pour obtenir des informations de diagnostic plus détaillées sur le comportement du système ou
des objets impliqués.
Les erreurs critiques génèrent des alertes et des incidents. La plupart du temps, elles génèrent
des incidents qui sont collectés en tant que problèmes. Vous utilisez la page Support
Workbench pour examiner le problème et le soumettre éventuellement au Support technique
Oracle.
La plupart des alertes (par exemple "Out of Space") sont effacées automatiquement lorsque la
cause du problème disparaît. Certaines (telles que "Generic Alert Log Error") vous sont
envoyées pour notification et vous devez en accuser réception. Après avoir pris les mesures
correctives nécessaires, vous pouvez accuser réception d'une alerte en l'effaçant ou en la
purgeant. Lorsque vous effacez une alerte, celle-ci est incluse dans l'historique des alertes,
visible à partir de la page d'accueil sous Related Links. Lorsque vous purgez une alerte, celle-
ci est supprimée de l'historique des alertes.
Pour effacer une alerte telle que "Generic Alert Log Error", cliquez sur le lien Alert Log dans
la section Diagnostic Summary de la page d'accueil. La page Alert Log Errors apparaît.
Sélectionnez l'alerte à effacer, puis cliquez sur Clear. Pour purger une alerte, sélectionnez-la
et cliquez sur Purge. Vous pouvez également effacer ou purger toutes les alertes à l'aide des
boutons Clear Every Open Alert et Purge Every Alert.

Types d'alerte et effacement des alertes
Basées sur des mesures
de performances
Alertes avec seuil 97 % : Seuil critique Effacées

(avec conservation
de statut) 85 % : Avertissement Effacées
MMON
DBA_OUTSTANDING_ALERTS DBA_ALERT_HISTORY
Resumable Recovery Area

Snapshot Session Low On
Too Old Suspended Free Space
Alertes sans seuil
(sans conservation
de statut)
Alerte
Basées sur des événements
Types d'alerte et effacement des alertes

Le serveur génère des alertes de deux types : alertes avec seuil et alertes sans seuil.
La plupart des alertes générées par le serveur sont configurées par la définition d'un seuil
d'avertissement et d'un seuil critique pour des mesures de performances de la base de données.
Vous pouvez définir des seuils pour plus de 120 mesures de performances, notamment :
• Physical Reads Per Sec
• User Commits Per Sec
• SQL Service Response Time
Toutes les mesures de performances sont liées aux instances, à l'exception de la mesure
Tablespace Space Usage, qui est liée à la base de données. Les alertes avec seuil sont
également appelées alertes avec conservation de statut (stateful). Elles sont effacées
automatiquement lorsque leur cause disparaît. Les alertes avec conservation de statut
apparaissent dans la vue DBA_OUTSTANDING_ALERTS. Une fois effacées, elles sont
transférées vers DBA_ALERT_HISTORY.
Les autres alertes générées par le serveur correspondent à des événements propres à la base de
données, par exemple les erreurs ORA-*, "Snapshot Too Old", "Recovery Area Low On Free
Space" et "Resumable Session Suspended". Il s'agit d'alertes sans seuil, également appelées
alertes sans conservation de statut (stateless). Ces alertes vont directement dans la table
d'historique. L'effacement des alertes sans conservation de statut n'est pertinent que dans
l'environnement Database Control, car ce dernier stocke ces alertes dans son propre
référentiel.

Quiz
Les alertes sans conservation de statut (stateless) telles que

SNAPSHOT TOO OLD peuvent être consultées dans la vue
DBA_OUTSTANDING_ALERTS du dictionnaire.
1. Vrai
2. Faux

Réponse : 2

Synthèse

• gérer les statistiques destinées à l'optimiseur
• gérer le référentiel AWR (Automatic Workload Repository)
• utiliser le moniteur ADDM (Automatic Database Diagnostic
Monitor)
• décrire et utiliser l'infrastructure de conseil
• définir des seuils d'alerte
• utiliser des alertes générées par le serveur

• utiliser des tâches automatisées

Maintenance proactive
Dans cet exercice, vous allez effectuer des tâches de gestion
proactive de la base de données à l'aide du moniteur ADDM,
et notamment :
• configurer un problème pour analyse
• examiner les performances de la base de données
• implémenter une solution


Gestion des performances

Objectifs

• utiliser Enterprise Manager pour surveiller les performances
• utiliser la gestion automatique de la mémoire (AMM -
Automatic Memory Management)
• utiliser Memory Advisor pour dimensionner les mémoires
tampons
• consulter les vues dynamiques des performances
• résoudre les problèmes concernant des objets non valides

et inutilisables

Surveiller les performances
Problèmes
d'allocation
de mémoire
Contention des Contention

périphériques des
d'entrée/sortie ressources
?
DBA

Problèmes liés Goulets
au code des d'étranglement
applications réseau
Surveiller les performances

Pour administrer une base de données Oracle Database 11g et garantir son bon
fonctionnement, le DBA doit surveiller régulièrement ses performances afin de localiser les
goulets d'étranglement et corriger les problèmes.
Le DBA peut examiner des centaines d'indicateurs de performances, allant des performances
réseau au temps passé sur les opérations individuelles des applications, en passant par la
vitesse d'entrée/sortie (E/S) des disques. Ces indicateurs de performances sont généralement
appelés mesures de performances de la base de données.
Remarque : Pour plus d'informations sur les performances de la base de données Oracle,
reportez-vous au cours Oracle Database 11g : Tuning.

Page Performance d'Enterprise Manager

Page Performance d'Enterprise Manager

La page Performance d'Enterprise Manager est le portail menant à un ensemble d'outils de
réglage (tuning) et de surveillance des performances. La première série de graphiques de cette
page indique les processus en cours et l'activité de la session active. Le graphique Average
Active Sessions indique le niveau d'utilisation de la CPU, ainsi que les ressources qui
déclenchent le plus grand nombre d'événements Wait.
Dans l'écran de la diapositive ci-dessus, vous constatez une augmentation récente des
événements Wait de type Concurrency et Other. Chacun de ces pics était accompagné d'une
légère hausse de l'utilisation des E/S système et de la CPU. Vous pouvez cliquer sur ces
catégories pour afficher des détails sur les événements Wait correspondants. Les données
d'E/S sont réparties par type (par exemple, lecture du fichier journal, écriture dans le fichier
de contrôle, etc.)

Analyser une catégorie particulière
d'événements Wait

Analyser une catégorie particulière d'événements Wait

Lorsque vous effectuez une analyse descendante sur une catégorie d'événements Wait
particulière, vous pouvez afficher les détails correspondant à un intervalle spécifique de cinq
minutes. De même, vous obtenez les listes Top Working SQL et Top Working Sessions
associées à l'événement Wait pour l'intervalle considéré. Vous pouvez ainsi réaliser une
analyse a posteriori des ralentissements du système et en déterminer les causes potentielles.
L'exemple présenté ci-dessus illustre les résultats d'une analyse descendante sur la catégorie
Concurrency à partir du graphique Active Sessions de la diapositive précédente.

Page Performance : Onglet Throughput
Faites défiler la page Performance vers le bas.

Page Performance : Onglet Throughput

Dans la page Performance, vous pouvez cliquer sur les onglets Throughput et I/O pour
afficher respectivement les graphiques Instance Throughput Rate et Instance Disk I/O. Dans
la diapositive ci-dessus, l'onglet Throughput est sélectionné.

Surveiller les performances :
Option Top Sessions

Surveiller les performances : Option Top Sessions

Si vous cliquez sur Top Consumers dans la section Additional Monitoring Links, vous
accédez à la page Top Consumers.
La page Top Consumers Overview affiche sous forme graphique les informations suivantes :
• Principaux services consommateurs
• Principaux modules consommateurs (par service)
• Principales actions consommatrices (par service et par module)
• Principaux clients consommateurs
Cliquez sur l'onglet Top Sessions dans la page Top Consumers pour afficher des statistiques
critiques sur les sessions qui consomment le plus de ressources :
• CPU
• PGA Memory
• Logical Reads
• Physical Reads
• Hard Parses
• Disk Sorts
Cliquez sur le nom d'une colonne pour trier les résultats selon les valeurs de cette colonne.
Dans la diapositive ci-dessus, les sessions sont triées en fonction du nombre de lectures
logiques (colonne Logical Reads). Vous constatez que c'est l'utilisateur INVENTORY de la
session 36 qui génère le plus grand nombre de lectures logiques à cet instant particulier.

Surveiller les performances : Option Top Services

Surveiller les performances : Option Top Services

Dans les systèmes à plusieurs niveaux (multi-tiers), dans lesquels un serveur d'applications
regroupe les connexions de base de données, la consultation de la liste des sessions ne vous
fournit pas toujours les informations dont vous avez besoin pour analyser les performances.
Le regroupement des sessions par nom de service vous permet de surveiller plus précisément
les performances.
L'exemple présenté dans la diapositive ci-dessus mentionne quatre services : SYS$USERS,
SYS$BACKGROUND, SH et SERV1. Dès lors qu'une connexion est établie via l'un de ces
services, les données de performances de la session sont capturées sous ce nom de service,
quelle que soit la session utilisée pour la demande. Sur les deux services (SH et SERV1) pris
en compte dans la diapositive, c'est le service SH qui a été le plus actif au cours de la période
de cinq minutes considérée.

Gérer les composants de mémoire
• Gestion automatique de la mémoire (AMM)

– Permet de préciser la quantité totale de mémoire allouée à
l'instance (mémoires SGA et PGA comprises)
• Gestion automatique de la mémoire partagée (ASMM)
– Permet d'indiquer la mémoire SGA totale via un seul paramètre
d'initialisation
– Permet au serveur Oracle de gérer la quantité de mémoire
allouée au cache de tampons, à la zone de mémoire partagée,
ainsi qu'aux zones de mémoire Java, Streams et LARGE POOL

• Gestion manuelle de la mémoire partagée
– Dimensionne les composants par l'intermédiaire de plusieurs
paramètres d'initialisation
– Utilise la fonction de conseil Memory Advisor appropriée pour
émettre des recommandations
Gérer les composants de mémoire

Oracle Database 11g vous permet de préciser l'allocation totale de mémoire pour une instance
donnée. Cette allocation est ensuite répartie dynamiquement entre les mémoires SGA (System
Global Area) et PGA (Program Global Area), en fonction des besoins. On parle alors de gestion
automatique de la mémoire (AMM - Automatic Memory Management). Il s'agit d'une méthode
qui simplifie la gestion de la mémoire, disponible uniquement sur les plates-formes qui prennent
en charge l'allocation dynamique de mémoire.
Il existe des fonctions de conseil pour la gestion de la mémoire qui vous permettent de définir les
paramètres d'initialisation à différents niveaux. Diverses fonctions sont disponibles, selon le
niveau auquel vous définissez les paramètres de mémoire. Si vous activez la gestion automatique
de la mémoire (AMM), seule la fonction de conseil Memory Size Advisor est disponible.
La gestion automatique de la mémoire partagée (ASMM - Automatic Shared Memory
Management) permet de gérer l'ensemble de la mémoire SGA.
Celle-ci comporte plusieurs composants dont la taille est ajustée dynamiquement pour garantir
les meilleures performances tout en respectant les limites des paramètres d'initialisation. Si vous
optez pour la gestion automatique de la mémoire (AMM), l'option ASMM est automatiquement
activée. En revanche, si vous activez uniquement ASMM (sans AMM), la fonction de conseil
SGA Size Advisor est disponible.
Vous pouvez également gérer la taille de chaque composant manuellement en définissant le
paramètre d'initialisation associé à chacun d'eux. Si le serveur Oracle vous signale un problème
de performances lié à la taille d'un composant SGA ou PGA, vous pouvez utiliser la fonction de
conseil Memory Advisor correspondant à ce composant pour déterminer des paramètres mieux
appropriés. Memory Advisor peut modéliser l'incidence des modifications de paramètres.

Activer la gestion automatique de la mémoire (AMM)
Cliquez sur Enable pour

activer la gestion
automatique de la mémoire.

Utilisez la fonction Memory Size Advisor.
Activer la gestion automatique de la mémoire (AMM)

Si vous n'avez pas activé la gestion automatique de la mémoire (AMM - Automatic Memory
Management) lors de la configuration de la base de données, vous pouvez le faire en procédant
comme suit :
1. Dans la page d'accueil de la base de données, cliquez sur l'onglet Server.
2. Dans la région Database Configuration, cliquez sur Memory Advisors.
La page Memory Advisors apparaît alors.
3. Cliquez sur Enable en regard de l'option Automatic Memory Management.
La page Enable Automatic Memory Management s'affiche.
4. Indiquez les valeurs des paramètres Total Memory Size et Maximum Memory Size pour la
gestion automatique de la mémoire.
Remarque : Si vous changez la valeur du champ Maximum Memory Size, vous devez
redémarrer l'instance.
5. Cliquez sur OK.
Vous pouvez augmenter la taille de la mémoire ultérieurement en incrémentant la valeur du
champ Total Memory Size ou du paramètre d'initialisation MEMORY_TARGET. Vous devez
toutefois respecter la limite fixée par le champ Maximum Memory Size ou le paramètre
MEMORY_MAX_TARGET. Pour plus d'informations, reportez-vous au manuel Oracle Database
Une fois que vous avez activé la gestion automatique de la mémoire (AMM), vous disposez de
la fonction de conseil Memory Size Advisor pour ajuster les paramètres de taille de la mémoire.
Remarque : Oracle recommande d'utiliser AMM pour simplifier les tâches de gestion de la
mémoire.

Activer la gestion automatique
de la mémoire partagée (ASMM)
Cliquez sur Enable pour

activer la gestion automatique
de la mémoire partagée.

Activer la gestion automatique de la mémoire partagée (ASMM)

La gestion automatique de la mémoire partagée (ASMM - Automatic Shared Memory
Management) est activée automatiquement si vous avez sélectionné la gestion automatique de
la mémoire (AMM - Automatic Memory Management). Si vous n'avez pas activé l'option
AMM, ou si vous n'avez pas activé l'option ASMM lors de la configuration de la base de
données, procédez de la manière suivante :
1. Dans la page d'accueil de la base de données, cliquez sur l'onglet Server.
2. Dans la région Database Configuration, cliquez sur Memory Advisors.
La page Memory Advisors apparaît alors.
3. Faites défiler la page jusqu'à la section SGA. Cliquez sur Enable en regard de l'option
Automatic Shared Memory Management.
La page Enable Automatic Shared Memory Management s'affiche.
4. Indiquez la taille totale de la mémoire SGA. Cliquez sur OK.
Vous pouvez augmenter la taille de la mémoire partagée ultérieurement en incrémentant la
valeur du champ Total SGA Size ou du paramètre d'initialisation SGA_TARGET. Vous devez
toutefois respecter la limite fixée par le champ Maximum SGA Size ou le paramètre
SGA_MAX_SIZE. Pour plus d'informations, reportez-vous au manuel Oracle Database
Quand l'option AMM est désactivée, la fonction de conseil relative à la mémoire PGA
(Program Global Area) est accessible. Il est recommandé d'utiliser cette fonction pour définir la
taille de la mémoire PGA. Cliquez sur l'onglet PGA pour accéder à la page de propriétés
correspondante. Cliquez sur Advice pour appeler PGA Advisor.
Remarque : Oracle recommande d'utiliser ASMM pour simplifier les tâches de gestion de la
mémoire.
Fonction de conseil ASMM

Fonction de conseil ASMM

Lorsque la gestion automatique de la mémoire partagée (ASMM) est activée, vous ne devez
pas définir les paramètres d'initialisation des composants de mémoire gérés par cette
fonctionnalité. Vous disposez de la fonction de conseil SGA Size Advisor pour choisir la
taille idéale de la mémoire SGA.
Avant d'activer ASMM, vous devez supprimer du fichier SPFILE les paramètres concernant
les zones de mémoire individuelles car ils risquent d'imposer des restrictions à ASMM. Si,
après avoir constaté les effets de l'allocation de mémoire effectuée par ASMM, vous décidez
d'ajuster la mémoire allouée à certains composants, vous pouvez indiquer des valeurs pour ces
derniers. Si les valeurs que vous indiquez sont inférieures aux valeurs en cours, elles sont
considérées comme des tailles minimales pour les composants concernés. Si vous indiquez
des valeurs supérieures aux valeurs en cours, les composants de mémoire sont redimensionnés
conformément à vos choix tant qu'il reste de la mémoire disponible. Cette opération limite la
quantité de mémoire susceptible d'être ajustée automatiquement, mais elle peut être utile si
votre environnement requiert un dimensionnement spécial non satisfait par ASMM.
Les paramètres d'initialisation concernés sont les suivants :
• SHARED_POOL_SIZE
• LARGE_POOL_SIZE
• JAVA_POOL_SIZE
• DB_CACHE_SIZE
• STREAMS_POOL_SIZE
Pour définir ces paramètres lorsque la fonction ASMM est activée, vous devez utiliser la
commande ALTER SYSTEM.

Statistiques dynamiques des performances
Niveau système Niveau session Niveau service

V$SYSSTAT V$SESSTAT V$SERVICE_STATS
• statistic# • sid • service_name_hash
• name • statistic# • service_name
• class • value • stat_id
• value • stat_name
• stat_id • value
V$SYSTEM_EVENT V$SESSION_EVENT V$SERVICE_EVENT

• event • sid • service_name
• total_waits • event • service_name_hash
• total_timeouts • total_waits • event

• time_waited • total_timeouts • event_id
• average_wait • time_waited • total_waits
• time_waited_micro • average_wait • total_timeouts
• max_wait • time_waited
Statistiques cumulées • time_waited_micro • average_wait
• event_id • time_waited_micro
Evénements Wait
Statistiques dynamiques des performances

Vous devez disposer de statistiques pour pouvoir analyser les problèmes de performances.
Le serveur Oracle génère différents types de statistiques à différents niveaux de détail.
Aux niveaux système, session et service, il calcule les événements Wait et des statistiques
cumulées. Sur la diapositive ci-dessus, les vues du haut présentent les statistiques cumulées.
Les vues du bas présentent les événements Wait.
Lorsque vous analysez un problème de performances à l'un de ces trois niveaux, vous évaluez
généralement l'évolution des statistiques (différentiel) sur la période considérée. Tous les
événements Wait possibles sont catalogués dans la vue V$EVENT_NAME tandis que toutes les
statistiques sont répertoriées dans la vue V$STATNAME. Environ 480 statistiques sont
disponibles dans Oracle Database.

Statistiques dynamiques des performances (suite)
Afficher les statistiques au niveau système
Exemple :
SQL> SELECT name, class, value FROM v$sysstat;
NAME CLASS VALUE
------------------------------- ------ ----------
...
table scans (short tables) 64 135116
table scans (long tables) 64 250
table scans (rowid ranges) 64 0
table scans (cache partitions) 64 3
table scans (direct read) 64 0
table scan rows gotten 64 14789836
table scan blocks gotten 64 558542
...

Les statistiques au niveau système sont classées en fonction du type de réglage (tuning) et de
l'objectif du débogage. Les différentes classes concernent l'activité générale de l'instance, l'activité du
tampon de journalisation (redo log buffer), le verrouillage, l'activité du cache de tampons (buffer
cache) de la base de données, etc.

Vues de résolution des problèmes et de réglage
Instance/Base de données Disque

V$DATABASE V$DATAFILE
V$INSTANCE V$FILESTAT
V$PARAMETER V$LOG
V$SPPARAMETER V$LOG_HISTORY
V$SYSTEM_PARAMETER V$DBFILE
V$PROCESS V$TEMPFILE
V$BGPROCESS V$TEMPSEG_USAGE
V$PX_PROCESS_SYSSTAT V$SEGMENT_STATISTICS
V$SYSTEM_EVENT

Contention
Mémoire V$LOCK
V$BUFFER_POOL_STATISTICS V$UNDOSTAT
V$LIBRARYCACHE V$WAITSTAT
V$SGAINFO V$LATCH
V$PGASTAT
Vues de résolution des problèmes et de réglage

La diapositive ci-dessus répertorie certaines des vues qui peuvent vous aider à déterminer la
cause de problèmes de performances ou à analyser le statut en cours de la base de données.
Pour obtenir une description complète de ces vues, reportez-vous au manuel Oracle Database
Reference.

Objets non valides et inutilisables
Incidence sur les performances :

• Les objets de code PL/SQL sont recompilés.
• Les index sont reconstruits.

Objets non valides et inutilisables

Les objets PL/SQL non valides et les index inutilisables affectent les performances. Un objet
PL/SQL non valide doit être recompilé pour pouvoir être utilisé. Outre la tentative d'accès au
package, à la procédure ou à la fonction PL/SQL, il faut compter le temps nécessaire à
l'exécution de la recompilation. Si la recompilation du code PL/SQL n'aboutit pas, une erreur
est générée. Les index inutilisables sont ignorés par l'optimiseur. Si les performances d'une
instruction SQL dépendent d'un index signalé comme inutilisable, elles restent dégradées tant
que cet index n'a pas été reconstruit.
Objets PL/SQL non valides : Vous pouvez consulter le statut des objets PL/SQL en
interrogeant le dictionnaire de données. Pour rechercher les objets PL/SQL non valides :
SELECT object_name, object_type FROM DBA_OBJECTS
WHERE status = 'INVALID';
Par défaut, la mesure Owner's Invalid Object Count est vérifiée toutes les 24 heures. Si, pour
un même propriétaire, cette valeur est supérieure à 2, une alerte est générée.
Si vous trouvez des objets PL/SQL dont le statut est INVALID, la première question à vous
poser est de savoir si cet objet a déjà présenté le statut VALID. Il est fréquent que le
développeur d'une application néglige de nettoyer le code qui ne fonctionne pas. Si l'objet
PL/SQL est non valide en raison d'une erreur de code, vous n'avez guère d'autre option que
d'attendre que l'erreur soit résolue. Si la procédure a été valide par le passé mais qu'elle a
cessé de l'être récemment, vous avez deux moyens de résoudre le problème :

Objets non valides et inutilisables (suite)
• Ne rien faire. La plupart des objets PL/SQL sont au besoin recompilés automatiquement
lorsqu'ils sont appelés. Les utilisateurs perçoivent simplement un léger ralentissement dû à la
recompilation des objets. (Dans la plupart des cas, ce ralentissement n'est même pas
perceptible.)
• Recompiler manuellement l'objet non valide.
Les objets PL/SQL non valides peuvent être recompilés manuellement via Enterprise Manager ou par
l'intermédiaire de commandes SQL :
ALTER PROCEDURE HR.add_job_history COMPILE;
La recompilation manuelle de packages PL/SQL se fait en deux étapes :
ALTER PACKAGE HR.maintainemp COMPILE;
ALTER PACKAGE HR.maintainemp COMPILE BODY;
Index inutilisables : Vous pouvez rechercher les index non valides en interrogeant la vue
DBA_INDEXES du dictionnaire de données :

SELECT index_name, table_name FROM DBA_INDEXES
WHERE status = 'UNUSABLE';
Le statut des index partitionnés est stocké dans la vue DBA_IND_PARTITIONS.
Les index inutilisables sont rendus valides via une reconstruction qui recalcule les pointeurs. Cette
opération recrée l'index dans un nouvel emplacement, l'index inutilisable étant par la suite supprimé.
Elle peut être effectuée via Enterprise Manager ou par l'intermédiaire de commandes SQL :
ALTER INDEX HR.emp_empid_pk REBUILD;
ALTER INDEX HR.emp_empid_pk REBUILD ONLINE;
ALTER INDEX HR.email REBUILD TABLESPACE USERS;
Si la clause TABLESPACE est omise, l'index est reconstruit dans le même tablespace. La clause
REBUILD ONLINE permet aux utilisateurs de continuer à mettre à jour la table d'index pendant sa
reconstruction. (Sans le mot-clé ONLINE, les utilisateurs doivent attendre la fin de la reconstruction
pour effectuer une opération LMD sur la table concernée. Si l'index est inutilisable, il n'est pas
exploité lors de sa reconstruction, même si le mot-clé ONLINE est utilisé.)
Enterprise Manager utilise l'action Reorganize pour réparer un index UNUSABLE.
Remarque : Vous devez libérer de l'espace pour pouvoir reconstruire un index. Assurez-vous donc
que l'espace libre est suffisant avant de procéder à cette opération. Enterprise Manager vérifie
automatiquement les besoins en termes d'espace.

Quiz
La gestion automatique de la mémoire (AMM) permet à

l'instance Oracle de réallouer à la mémoire SGA de l'espace
pris sur _______.
1. la zone de mémoire LARGE POOL
2. le tampon de journalisation (redo log buffer)
3. la mémoire PGA
4. la zone de mémoire Streams

Réponse : 3

Quiz
SGA_TARGET ne peut pas avoir une taille supérieure

à __________.
1. LOG_BUFFER
2. SGA_MAX_SIZE
3. STREAMS_POOL_SIZE
4. PGA_AGGREGATE_TARGET

Réponse : 2

Synthèse

• utiliser Enterprise Manager pour surveiller les performances
• utiliser la gestion automatique de la mémoire
(AMM - Automatic Memory Management)
• utiliser Memory Advisor pour dimensionner les mémoires
tampons
• consulter les vues dynamiques des performances
• résoudre les problèmes concernant des objets non valides

et inutilisables

Surveiller et optimiser les performances

• détecter et réparer les index inutilisables
• utiliser la page Performance d'Enterprise Manager



D50102FR20 sg1

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

D50102FR20 sg1

Transféré par

Droits d'auteur :

Formats disponibles

Oracle University and OMNIDATA.

Manuel du stagiaire - Volume I

Deirdre Matishak Avertissement

Oracle University and OMNIDATA. use only

Achiel Langers Marques

Oracle University and OMNIDATA. use only

2 Installer le logiciel Oracle

Oracle University and OMNIDATA. use only

Oracle University and OMNIDATA. use only

4 Gérer l'instance de base de données

Oracle University and OMNIDATA. use only

5 Gérer l'instance ASM

Oracle University and OMNIDATA. use only

6 Configurer l'environnement réseau Oracle

Oracle University and OMNIDATA. use only

7 Gérer les structures de stockage de base de données

8 Administrer la sécurité utilisateur

Oracle University and OMNIDATA. use only

9 Gérer les accès simultanés aux données

Oracle University and OMNIDATA. use only

11 Implémenter l'audit de la base de données Oracle

Oracle University and OMNIDATA. use only

12 Maintenance de la base de données

13 Gestion des performances

Oracle University and OMNIDATA. use only

14 Concepts de sauvegarde et de récupération

Oracle University and OMNIDATA. use only

15 Effectuer des sauvegardes de la basede données

Oracle University and OMNIDATA. use only

17 Déplacer des données

Oracle University and OMNIDATA. use only

18 Utiliser le support technique

Oracle University and OMNIDATA. use only

Annexe B: Commandes de base de Linux et vi

Annexe C: Syntaxe des instructions SQL

Annexe D: Processus Oracle en arrière-plan

Annexe E: Acronymes and termes

G Suite de la formation et autres lectures conseillées

Oracle University and OMNIDATA. use only

Oracle University and OMNIDATA. use only

A la fin de ce cours, vous pourrez :

Oracle University and OMNIDATA. use only

Oracle Database 11g : Administration Workshop I - 2

Jour Chapitres Jour Chapitres

1 1. Examiner l'architecture de la base 3 9. Gérer les accès simultanés aux

Oracle University and OMNIDATA. use only

Copyright © 2009, Oracle. Tous droits réservés.

Oracle Database 11g : Administration Workshop I - 3

Oracle University and OMNIDATA. use only

Produits et services Oracle

Oracle Database 11g : Administration Workshop I - 4

Grid de Grid de base Grid Grid

Oracle University and OMNIDATA. use only

Copyright © 2009, Oracle. Tous droits réservés.

Oracle Database 11g : "g" signifie "grid"

Oracle Database 11g : Administration Workshop I - 5

Oracle University and OMNIDATA. use only

Oracle Database 11g : Administration Workshop I - 6

Oracle University and OMNIDATA. use only

Copyright © 2009, Oracle. Tous droits réservés.

Grid Infrastructure for Single-Instance

Oracle Database 11g : Administration Workshop I - 7

Oracle University and OMNIDATA. use only