Administration Workshop I V2

Oracle Database 10g :
Administration Workshop I
Volume II - Manuel du stagiaire
D17090FR30
Edition 3.0
Mai 2006
D42059
Unauthorized reproduction or distribution prohibitedฺ Copyright© 2009, Oracle and/or its affiliatesฺ
Auteurs Copyright © 2005, Oracle. Tous droits réservés.
Tom Best Avertissement
M.J. Billings 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 d'utilisation personnelle
Révisions et lors de la participation à une formation dispensée par Oracle. Le document ne peut être
contributions techniques 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 d'auteur, vous ne pouvez
Anthony Woodell pas utiliser, partager, télécharger, copier, imprimer, afficher, exécuter, reproduire, publier,
Barry Trute breveter, diffuser, transmettre ou distribuer ce document, en partie ou en totalité, sans
l'autorisation expresse d'Oracle.
Celia Antonio
Les informations fournies dans ce document sont susceptibles de modification sans
Christine Jeal préavis. Par ailleurs, Oracle Corporation ne garantit pas qu'elles soient exemptes
Donna Keesling 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 USA.
Howard Bradley
James Spiller Restrictions applicables au gouvernement américain :
Restricted Rights Notice
Janet Stern
If this documentation is delivered to the United States Government or anyone using the
Jean-Francois Verrier documentation on behalf of the United States Government, the following notice is
Joel Goodman applicable:
John Hibbard U.S. GOVERNMENT RIGHTS
Larry Baumann The U.S. Government’s rights to use, modify, reproduce, release, perform, display, or
disclose these training materials are restricted by the terms of the applicable Oracle
Magnus Isaksson license agreement and/or the applicable U.S. Government contract.
M.J. Bryksa
Marques
Paul Needham
Oracle, JD Edwards et PeopleSoft sont des marques déposées d'Oracle Corporation
Pierre Labrousse et/ou de ses filiales. Tout autre nom de produit ou de société peut être une marque de
Raza Siddiqui son propriétaire.
Sandra Cheevers
Stefan Lindblad
Stella Kister
Steve Friedberg
Steven Karam
Sushma Jagannath
Tammy Bednar
Rédacteurs
Navratan Singh
Nita Pavitran
Raj Kumar
Concepteur graphique
Satish Bettegowda
Steve Elwood
Editeur
Joseph Fernandez
Table des matières
Préface
1 Introduction
Objectifs du cours 1-2
Planification recommandée 1-3
Objectifs du chapitre 1-4
Produits et services Oracle 1-5
Oracle Database 10g : "g" signifie "grid" 1-6
Architecture de base de données Oracle 1-9
Structures de base de données 1-10
Structures mémoire Oracle 1-11
Structures de processus 1-13
Gestion des instances Oracle 1-14
Processus serveur et cache de tampons de base de données 1-15
Structure de base de données physique 1-16
Tablespaces et fichiers de données 1-18
Tablespaces SYSTEM et SYSAUX 1-19
Segments, extents et blocs 1-20
Structures de base de données logiques et physiques 1-21
Exemples du cours : Le schéma HR 1-23
Architecture de la base de données : Récapitulatif des
composants structurels 1-24
Synthèse 1-25
2 Installer le logiciel de base de données 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
Installation : Configuration système requise 2-6
Vérifier la configuration système requise 2-7
Architecture OFA (Optimal Flexible Architecture) 2-8
Utiliser l'architecture OFA 2-9
Définir les variables d'environnement 2-11
Oracle Universal Installer (OUI) 2-13
Installer le logiciel Oracle 2-14
Options de configuration de la base de données 2-15
Exécuter des scripts de configuration 2-16
Terminer l'installation 2-17
Options d'installation avancées 2-18
Option d'installation : Mode automatique 2-19
Synthèse 2-20
Présentation de l'exercice : Installer le logiciel Oracle 2-21
iii
3 Créer une base de données Oracle
Objectifs 3-2
Planification de la base de données 3-3
Bases de données : Exemples 3-4
Assistant Database Configuration Assistant (DBCA) 3-5
Utiliser l'assistant DBCA pour créer une base de données 3-6
Gestion des mots de passé 3-12
Créer un modèle de conception de base de données 3-13
Utiliser l'assistant DBCA pour supprimer une base de données 3-14
Synthèse 3-16
Présentation de l'exercice : Utiliser l'assistant DBCA 3-17
4 Gérer l'instance Oracle

Objectifs 4-2
Structure de gestion 4-3
Démarrer et arrêter Database Control 4-4
Oracle Enterprise Manager 4-5
Accéder à Oracle Enterprise Manager 4-6
Page d'accueil de la base de données 4-7
Utiliser SQL*Plus et iSQL*Plus pour accéder à la base de données 4-8
Utiliser iSQL*Plus 4-9
Configurer iSQL*Plus pour des accès SYSDBA et SYSOPER 4-10
Utiliser SQL*Plus 4-12
Appeler SQL*Plus à partir d'un script shell 4-13
Appeler un script SQL à partir de SQL*Plus 4-14
Fichiers de paramètres d'initialisation 4-15
Paramètres d'initialisation simplifiés 4-16
Afficher et modifier les paramètres d'initialisation 4-18
Démarrer et arrêter la base de données 4-19
Démarrer une instance de base de données Oracle 4-20
Démarrer une instance de base de données Oracle : NOMOUNT 4-21
Démarrer une instance de base de données Oracle : MOUNT 4-22
Démarrer une instance de base de données Oracle : OPEN 4-23
Arrêter une instance de base de données Oracle 4-24
Modes d'arrêt 4-25
Options SHUTDOWN 4-26
Utiliser SQL*Plus pour les opérations de démarrage et d'arrêt 4-29
Afficher le fichier d'alertes 4-30
Afficher l'historique des alertes 4-31
Vues dynamiques des performances 4-32
iv
Vues dynamiques des performances : Exemples d'utilisation 4-33
Vues dynamiques des performances : Considérations 4-34
Synthèse 4-35
Présentation de l'exercice : Gérer l'instance Oracle 4-36
5 Gérer les structures de stockage de base de données
Objectifs 5-2
Structures de stockage 5-3
Mode de stockage des données d’une table 5-4
Anatomie d'un bloc de base de données 5-5
Tablespaces et fichiers de données 5-6
Oracle Managed Files (OMF) 5-7
Gestion de l'espace dans les tablespaces 5-8
Explorer la structure de stockage 5-9
Créer un tablespace 5-10
Gestion du stockage dans les tablespaces gérés localement 5-12
Tablespaces de la base de données préconfigurée 5-14
Modifier un tablespace 5-16
Actions sur les tablespaces 5-19
Supprimer des tablespaces 5-21
Afficher les informations relatives aux tablespaces 5-22
Collecter des informations sur les tablespaces 5-23
Afficher le contenu d'un tablespace 5-24
Etendre la base de données 5-25
Automatic Storage Management : Présentation 5-26
ASM : Fonctionnalités clés et principaux avantages 5-27
ASM : Concepts 5-28
Synthèse 5-29
Présentation de l'exercice : Gérer les structures de stockage
de base de données 5-30
6 Administrer la sécurité utilisateur
Objectifs 6-2
Comptes utilisateur de base de données 6-3
Comptes prédéfinis : SYS et SYSTEM 6-5
Créer un utilisateur 6-6
Authentification des utilisateurs 6-7
Authentification de l'administrateur 6-9
Déverrouiller un compte utilisateur et redéfinir le mot de passe 6-10
Privilèges 6-11
Privilèges système 6-12
Privilèges objet 6-14
Révoquer des privilèges système accordés avec ADMIN OPTION 6-15
Révoquer des privilèges objet accordés avec GRANT OPTION 6-16
Avantages des rôles 6-17
Affecter des privilèges à des rôles et des rôles à des utilisateurs 6-18
Rôles prédéfinis 6-19
Créer un rôle 6-20
Rôles sécurisés 6-21
Affecter des rôles aux utilisateurs 6-22
Profils et utilisateurs 6-23
Implémenter des fonctionnalités de sécurité utilisant des mots de passe 6-25
Créer un profil de mot de passe 6-27
Fonction de vérification des mots de passe fournie : VERIFY_FUNCTION 6-28
Affecter des quotas aux utilisateurs 6-29
Synthèse 6-31
Présentation de l'exercice : Administrer les utilisateurs 6-32
7 Gérer les objets de schéma

Objectifs 7-2
Qu'est-ce qu'un schéma ? 7-3
Accéder aux objets de schema 7-5
Nommer les objets de base de données 7-6
Définir des types de données pour les tables 7-8
Créer et modifier des tables 7-11
Comprendre l'intégrité des données 7-13
Définir des contraintes 7-15
Violations de contrainte 7-16
Etats possibles d'une contrainte 7-17
Vérification des contraintes 7-19
Créer des contraintes via des instructions SQL : Exemples 7-20
Afficher les colonnes d'une table 7-21
Afficher le contenu d'une table 7-22
Actions sur les tables 7-23
Supprimer une table 7-24
Vider une table 7-25
Index 7-26
Types d'index 7-27
Index B-Tree 7-28
Index bitmap 7-30
Options relatives aux index 7-32
Créer des index 7-34
vi
Qu'est-ce qu'une vue ? 7-35
Créer des vues 7-36
Séquences 7-37
Créer une séquence 7-38
Utiliser une séquence 7-40
Tables temporaires 7-41
Tables temporaires : Utilisation 7-43
Dictionnaire de données : Présentation 7-44
Vues du dictionnaire de données 7-45
Dictionnaire de données : Exemples d'utilisation 7-47
Synthèse 7-48
Présentation de l'exercice : Administrer les objets de schéma 7-49
8 Gérer les données et la simultanéité d'accès aux données

Objectifs 8-2
Manipuler les données par l'intermédiaire du langage SQL 8-3
Commande INSERT 8-4
Commande UPDATE 8-5
Commande DELETE 8-6
Commande MERGE 8-7
Commandes COMMIT et ROLLBACK 8-9
Langage PL/SQL 8-10
Administrer les objets PL/SQL 8-12
Objets PL/SQL 8-13
Fonctions 8-14
Procédures 8-15
Packages 8-16
Spécification et corps d’un package 8-17
Packages intégrés 8-18
Déclencheurs 8-19
Evénements déclencheurs 8-20
Verrous externes 8-21
Mécanisme de verrouillage 8-22
Simultanéité d'accès aux données 8-23
Verrous LMD 8-25
Mécanisme de mise en file d'attente 8-26
Conflits de verrouillage 8-27
Causes possibles des conflits de verrouillage 8-28
Détecter les conflits de verrouillage 8-29
Résoudre les conflits de verrouillage 8-30
vii
Résoudre les conflits de verrouillage à l'aide d'instructions SQL 8-31
"Verrous mortels" 8-32
Synthèse 8-33
Présentation de l'exercice : Gérer le données et la simultanéité
d'accès aux données 8-34
9 Gérer les données d'annulation
Objectifs 9-2
Manipulation des données 9-3
Données d'annulation 9-4
Transactions et données d'annulation 9-6
Stockage des informations d'annulation 9-7
Données d'annulation et données de journalisation 9-8
Surveiller les informations d'annulation 9-9
Administrer les informations d'annulation 9-11
Configurer la période de conservation des informations d'annulation 9-12
Garantir la période de conservation des informations d'annulation 9-14
Dimensionner le tablespace d'annulation 9-15
Utiliser Undo Advisor 9-16
Synthèse 9-17
Présentation de l'exercice : Gérer les segments d'annulation 9-18
10 Implémenter la sécurité de la base de données Oracle

Objectifs 10-2
Obligations en matière de sécurité dans les entreprises 10-3
Séparation des responsabilités 10-5
Sécurité de la base de données 10-6
Principe du moindre privilège 10-8
Appliquer le principe du moindre privilège 10-9
Surveiller les activités suspectes 10-11
Audit de base de données standard 10-12
Activer l'audit 10-13
Traces d'audit uniformes 10-14
Page Audit Settings d'Enterprise Manager 10-16
Définir les options d'audit 10-17
Utiliser et gérer les informations d'audit 10-18
Audit base sur les données 10-19
Audit détaillé 10-21
Stratégie d'audit détaillé 10-22
Instruction LMD auditée : Eléments à prendre en compte 10-24
Règles relatives à l'audit détaillé 10-25
Audit de DBA 10-26
viii
Gérer la trace d'audit 10-27
Mises à jour de sécurité 10-28
Appliquer des patches de sécurité 10-29
Synthèse 10-30
Présentation de l'exercice : Implémenter la sécurité
de la base de données Oracle 10-31
11 Configurer l'environnement réseau Oracle
Objectifs 11-2
Services Oracle Net 11-3
Processus d'écoute Oracle Net 11-4
Etablir des connexions réseau 11-5
Etablir une connexion 11-6
Sessions utilisateur 11-7
Outils de configuration et de gestion de l'environnement réseau Oracle 11-9
Utilitaire de contrôle du processus d'écoute 11-10
Syntaxe de l'utilitaire de contrôle du processus d'écoute 11-11
Page d'accueil Listener 11-13
Pages Net Services Administration 11-14
Créer un processus d'écoute 11-15
Ajouter des adresses de processus d'écoute 11-16
Enregistrement d'un service de base de données 11-17
Méthodes de résolution de noms 11-18
Easy Connect 11-19
Résolution locale de noms 11-20
Résolution de noms d'annuaire 11-21
Méthode de résolution de noms externes 11-22
Configurer des alias de service 11-23
Options de connexion avancées 11-24
Tester la connectivité Oracle Net 11-26
Sessions utilisateur : Serveurs dédiés 11-27
Sessions utilisateur : Serveurs partagés 11-28
Mémoire SGA et mémoire PGA 11-29
Serveur partagé : Concentration des connexions 11-30
Dans quel cas ne pas utiliser de serveur partagé ? 11-31
Synthèse 11-32
Présentation de l'exercice : Utiliser les composants réseau Oracle 11-33
12 Maintenance proactive
Objectifs 12-2
Maintenance proactive 12-3
Terminologie 12-4
ix
Statistiques destinées à l'optimiseur 12-5
Utiliser la page Manage Optimizer Statistics 12-7
Niveaux de statistiques 12-9
Référentiel AWR (Automatic Workload Repository) 12-10
Infrastructure du référentiel AWR 12-11
Jeux de clichés AWR 12-12
Enterprise Manager et référentiel AWR 12-13
Gérer le référentiel AWR 12-14
Moniteur ADDM (Automatic Database Diagnostic Monitor) 12-15
Résultats ADDM 12-16
Recommandations ADDM 12-17
Infrastructure de conseil 12-18
Enterprise Manager et les fonctions de conseil 12-20
Package DBMS_ADVISOR 12-21
Alertes générées par le serveur 12-22
Alertes par défaut générées par le serveur 12-23
Définir des seuils 12-24
Créer et tester une alerte 12-25
Notification des alertes 12-26
Réagir aux alertes 12-28
Types d'alerte et effacement des alertes 12-29
Tâches de maintenance automatisées 12-30
Synthèse 12-31
Présentation de l'exercice : Maintenance proactive 12-32
13 Gestion des performances

Objectifs 13-2
Surveillance des performances 13-3
Surveillance des performances : Option Top Sessions 13-7
Surveillance des performances : Option Top Services 13-8
SQL Tuning Advisor : Présentation 13-9
SQL Tuning Advisor : Options et recommandations 13-10
Utiliser SQL Tuning Advisor 13-11
Utiliser SQL Tuning Advisor : Exemple 13-12
SQL Tuning Advisor : Statistiques sur une instruction SQL 13-13
SQL Tuning Advisor : Identifier les instructions SQL en double 13-14
Utiliser SQL Access Advisor 13-15
Gérer les composants de mémoire 13-17
Activer la gestion automatique de la mémoire partagée 13-18
Gérer manuellement la mémoire partagée 13-20
Utiliser Memory Advisor 13-21
Statistiques dynamiques de performances 13-22
Vues de résolution des problèmes et de réglage 13-24
Options non valides et inutilisables 13-25
Synthèse 13-27
Présentation de l'exercice : Surveiller et améliorer les performances 13-28
14 Concepts de sauvegarde et de récupération
Objectifs 14-2
Partie de votre travail 14-3
Catégories de panne 14-4
Echec d'une instruction 14-5
Echec d'un processus utilisateur 14-6
Défaillance réseau 14-7
Erreur utilisateur 14-8
Echec d'une instance 14-10
Processus en arrière-plan et récupération : Point de reprise (CKPT) 14-11
Processus en arrière-plan et récupération : Fichiers de journalisation
et LogWriter 14-13
Processus en arrière-plan et récupération : Processus d'archivage (ARCn) 14-14
Récupération d'instance 14-15
Phases de la récuperation d'instance 14-16
Régler la récupération d'instance 14-17
Utiliser MTTR Advisor 14-18
Défaillance physique 14-19
Configurer la base de données afin d'optimiser la possibilité
de récupération 14-20
Fichiers de contrôle 14-22
Fichiers de journalisation 14-23
Multiplexer le fichier de journalisation 14-24
Fichiers de journalisation archivés 14-25
Fichier de journalisation archivé : Appellation et destinations 14-26
Mode ARCHIVELOG 14-28
Synthèse 14-29
Présentation de l'exercice : Configurer la base de données afin d'optimiser
la possibilité de récupération 14-30
15 Procéder à des sauvegardes de la base de 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
xi
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-18
Zone de récupération rapide 15-19
Synthèse 15-20
Présentation de l'exercice : Créer des sauvegardes
de la base de données 15-21
16 Procéder à une récupération de la base de données
Objectifs 16-2
Ouvrir une base de données 16-3
Modifier le statut d'une instance 16-5
Maintenir une base de données ouverte 16-6
Perte d'un fichier de contrôle 16-7
Perte d'un fichier de journalisation 16-8
Perte d'un fichier de données en mode NOARCHIVELOG 16-9
Perte d'un fichier de données non essentiel en mode ARCHIVELOG 16-10
Perte d'un fichier de données essentiel pour le système
en mode ARCHIVELOG 16-11
Synthèse 16-12
Présentation de l'exercice : Procéder à une récupération
de la base de données 16-13
17 Procéder à un flashback de la base de données
Objectifs 17-2
Avantages de la technologie Flashback 17-3
Dans quel cas utiliser la technologie Flashback ? 17-4
Procéder à un flashback suite à une erreur 17-5
Flashback Database : Présentation 17-6
Flashback Database : Réduction de la durée de restauration 17-7
Flashback Database : Eléments à prendre en compte 17-8
Flashback Database : Limitations 17-9
Activer Flashback Database 17-10
Flashback Table : Présentation 17-11
Flashback Table 17-12
Activer le déplacement de lignes (row movement) dans une table 17-13
Procéder au flashback d'une table 17-14
Flashback Table : Eléments à prendre en compte 17-16
Flashback Drop : Présentation 17-17
xii
Procéder à un flashback de tables supprimées via Enterprise Manager 17-18
Flashback Drop : Eléments à prendre en compte 17-19
Navigation temporelle grâce aux fonctionnalités Flashback 17-20
Flashback Query : Présentation 17-21
Flashback Query : Exemple 17-22
Flashback Versions Query : Présentation 17-23
Flashback Versions Query via Enterprise Manager 17-24
Flashback Versions Query : Eléments à prendre en compte 17-25
Flashback Transaction Query : Présentation 17-26
Flashback Transaction Query via Enterprise Manager 17-27
Flashback Transaction Query : Eléments à prendre en compte 17-28
Synthèse 17-29
Présentation de l'exercice : Utiliser Flashback 17-30
18 Déplacer des données

Objectifs 18-2
Déplacer des données : Architecture générale 18-3
Objet répertoire : Présentation 18-5
Créer des objets répertoire 18-6
SQL*Loader : Présentation 18-7
Charger des données avec SQL*Loader 18-9
Fichier de contrôle SQL*Loader 18-10
Méthodes de chargement 18-12
Data Pump : Présentation 18-14
Data Pump : Avantages 18-16
Data Pump Export et Data Pump Import : Présentation 18-17
Utilitaire Data Pump : Interfaces et modes 18-18
Sélection fine d'objets 18-19
Fonctionnalité avancée : Echantillonnage 18-20
Options d'export : Fichiers 18-21
Emplacement des fichiers Data Pump 18-22
Planifier et exécuter un travail 18-24
Nom et taille des fichiers Data Pump 18-25
Data Pump Import 18-26
Data Pump Import : Transformations 18-27
Data Pump : Considérations relatives aux performances 18-29
Paramètres d'initialisation des performances 18-30
Chemin direct Data Pump : Considérations 18-31
Utiliser Enterprise Manager pour surveiller les travaux Data Pump 18-32
Remplissage de tables externes 18-33
xiii
Utiliser des tables externes 18-34
Remplissage d'une table externe avec ORACLE_DATAPUMP 18-35
Remplissage d'une table externe avec ORACLE_LOADER 18-36
Dictionnaires de données 18-37
Synthèse 18-38
Présentation de l'exercice : Déplacer des données 18-39
Annexe A : Exercices
Annexe B : Solutions
Annexe C : Commandes de base de Linux et vi
Annexe D : Syntaxe des instructions SQL
Annexe E : Acronymes et termes
Annexe F : Etapes suivantes : Poursuivre la formation
Index
xiv
Implémenter la sécurité de la base
de données Oracle
Copyright © 2005, Oracle. Tous droits réservés.
Objectifs
A la fin de ce chapitre, vous pourrez :

• décrire les responsabilités du DBA en matière
de sécurité
• appliquer le principe du moindre privilège
• 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 10g Release 2 (10.2)
• Oracle Database Administrator’s Guide 10g Release 2 (10.2)
• Oracle Database Security Guide 10g Release 2 (10.2)
Les cours suivants fournissent une formation complémentaire :
• Oracle Database 10g : Administration Workshop II (D17092FR30)
• Oracle Database 10g : Sécurité (D17499FR10)
Oracle Database 10g : Administration Workshop I 10-2
> Obligations
Obligations en matière de sécurité Moindre privilège
Audit
dans les entreprises .
Basé sur
les données
FGA
DBA
• Lois : Mises à jour
sécurité
– Sarbanes-Oxley Act (SOX)
– Health Information Portability and Accountability
Act (HIPAA)
– California Breach Law
– UK Data Protection Act
• Audit
Obligations en matière de sécurité dans les entreprises

Les exigences en matière de sécurité étaient encore récemment l'affaire de chaque entreprise.
Il existait peu d'obligations légales, excepté dans le domaine public ou militaire. Cette
situation est en train d'évoluer rapidement. Différentes lois ont été votées pour imposer les
principes de confidentialité et d'exactitude des données. Ces lois s'accompagnent d'une
obligation d'audit sur les mesures de sécurité en vigueur.
Lois : Chacune des lois répertoriées ci-après implique des exigences spécifiques. Cette liste
est représentative de nombreuses autres lois en cours d'adoption à travers le monde. Bien
entendu, les lois en matière de sécurité varient d'un pays à l'autre.
• La loi Sarbanes-Oxley Act (SOX) impose aux entreprises cotées de renforcer et de
documenter les contrôles internes afin d'empêcher quiconque de commettre des actes
frauduleux qui risqueraient de compromettre la situation financière d'une organisation
ou l'exactitude de ses résultats financiers. Le président directeur général et le directeur
financier doivent attester de l'adéquation des contrôles internes et de l'exactitude des
résultats financiers publiés. En cas de reporting frauduleux, ils encourent des amendes et
des peines d'emprisonnement. La loi SOX exige également la communication des
informations utilisées pour le reporting et de la documentation relative aux contrôles
internes employés pour assurer l'intégrité des informations financières.
Obligations en matière de sécurité dans les entreprises (suite)
• La loi Health Information Portability and Accountability Act (HIPAA) vise à
protéger les informations personnelles d'ordre médical contre toute divulgation ou
utilisation abusive. Les détenteurs de telles informations doivent fournir des traces
d'audit qui répertorient tous les accès aux données.
• La loi UK Data Protection Act est destinée à protéger la vie privée en limitant
l'accès aux données à caractère personnel. Elle comporte huit points, dont l'un exige
la conservation sécurisée des données.
• Autres lois :
- La loi Family Educational Rights and Privacy Act (FERPA) concerne les
informations personnelles et médicales détenues par les établissements
scolaires.
- La loi California Breach Law impose aux entreprises détenant des
informations personnelles (par exemple, numéros de carte de crédit, de permis
de conduire ou de sécurité sociale) de protéger ces informations. Si des
informations ont fait l'objet d'accès non autorisés, l'organisation doit en
informer toutes les personnes concernées. Deux lois, CA-SB-1386 et CA-AB-
1950, s'appliquent aux organisations détenant des renseignements personnelles.
- La loi Federal Information Security Management Act (FISMA) fournit des
lignes directrices et des normes de sécurité dans les publications FIPS (Federal
Information Processing Standard), gérées par l'organisme de normalisation
NIST (National Institute of Standards). Ces normes s'appliquent aux
organisations qui traitent des informations pour le gouvernement américain.
Audit : Un grand nombre des lois qui précèdent contiennent des dispositions exigeant un
audit régulier des plans de sécurité (contrôles internes). Les obligations de la loi SOX sont
floues et font l'objet d'interprétations diverses par les responsables des organisations. Les
caractéristiques de leur implémentation peuvent varier considérablement, en fonction du
niveau de détail demandé par les responsables. Même si la loi SOX est imprécise, les
peines encourues sont sévères et il est donc important de protéger votre société. Il faut
évaluer le coût des mesures de sécurité par rapport aux risques. Personne ne pourra
garantir que vous présentez une sécurité totale. Le consensus constitue une très bonne
solution. Si vous respectez les règles de sécurité minimales et que vous avez effectué les
vérifications préalables, vous êtes normalement protégé contre les peines les plus sévères
prévues par la loi. Pour connaître les pratiques standard mises en oeuvre dans les
entreprises, vous pouvez notamment vous référer à l'Institut SAN (SysAdmin, Audit,
Network, Security), au CERT/CC géré par la Carnegie Mellon University pour le
ministère américain de la défense et à la norme de certification ISO-17799 :
http://www.sans.org/index.php
http://www.cert.org/nav/index.html
http://www.iso17799software.com/
La norme de certification internationale ISO-17799 constitue un code de bonnes pratiques
en matière de sécurité. Elle inclut des recommandations, des certifications et des
évaluations de risques. Elle couvre une vaste gamme de problèmes et inclut des stratégies
préétablies.
Séparation des responsabilités
• Les utilisateurs disposant des privilèges DBA

doivent être des personnes de confiance.
Précautions à prendre :
– Eviter les abus de confiance
– Mettre en place des traces d'audit pour protéger
les personnes dignes de confiance
• Les responsabilités 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 d'opérateur et de DBA.
Séparation des responsabilités

La diapositive 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 :
• Eviter les 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.
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 10g offre le meilleur environnement possible pour un système sécurisé. Mais
pour que cet environnement soit efficace, le DBA doit respecter les recommandations et
surveiller 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 relatives aux cartes bancaires, à la santé, à l'identité, etc. 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)
Authentification des 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 compromise 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 "token" (sème) 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 "token", biométrie ou certificat, via l'option ASO (Advanced
Security Option). 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
tendances suspectes.
Obligations
> Moindre privilège
Principe du moindre privilège . Audit
Basé sur
les données
FGA
DBA
Mises à jour
• Installez uniquement les logiciels requis sécurité
sur l'ordinateur.
• Activez uniquement les services requis sur
l'ordinateur.
• N'accordez l'accès au système d'exploitation et à
la base de données qu'aux utilisateurs qui en ont
besoin.
• Limitez l'accès au compte root ou administrateur.
• Limitez l'accès aux comptes SYSDBA et SYSOPER.
• Limitez l'accès des utilisateurs aux objets de base
de données nécessaires à la réalisation de leur
travail.
Principe du moindre privilège

Appliquez le principe du moindre privilège à chaque niveau, en partant des niveaux inférieurs. Il
existe toujours de nouvelles exploitations de faille de sécurité ("exploit") impossibles à anticiper.
L'application de ce principe permet de réduire les risques de telles exploitations et de limiter les
dommages.
• Installez uniquement les logiciels requis sur l'ordinateur : En réduisant le nombre de
packages logiciels, vous réduisez la maintenance, les mises à niveau, les possibilités de
brèches de sécurité et les conflits logiciels.
• Activez uniquement les services requis sur l'ordinateur : Un nombre réduit de services
implique moins de ports ouverts et moins de vecteurs d'attaque.
• N'accordez l'accès au système d'exploitation et à la base de données qu'aux utilisateurs
qui en ont besoin : Un nombre réduit d'utilisateurs signifie moins de mots de passe et de
comptes. Le nombre de comptes ouverts ou obsolètes est ainsi limité. Plus le nombre de
comptes est faible, plus il est facile pour l'administrateur de les tenir à jour.
• Limitez l'accès au compte root ou administrateur : Le compte administrateur doit être
soigneusement protégé et audité. Il ne doit en aucun cas être partagé.
• Limitez l'accès aux comptes SYSDBA et SYSOPER : Les utilisateurs ayant besoin d'accéder
à ces rôles doivent tous posséder leur propre compte et ces comptes doivent faire l'objet d'un
audit.
• Limitez l'accès des utilisateurs aux objets de base de données nécessaires à la réalisation
de leur travail : Les utilisateurs qui peuvent accéder à de nombreux objets et services sans
que cela soit nécessaire ont plus d'opportunités de commettre un acte malveillant.
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 de PUBLIC :

REVOKE EXECUTE ON UTL_SMTP, UTL_TCP, UTL_HTTP,
UTL_FILE FROM PUBLIC;
• 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. Il court ainsi moins de
risques de modifier, involontairement ou par malveillance, des données qu'il n'est pas autorisé
à 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 de PUBLIC : Les packages indiqués ci-après sont
extrêmement utiles pour les applications qui en ont besoin, mais ils nécessitent une utilisation
sécurisée de la configuration appropriée. Révoquez le privilège EXECUTE de PUBLIC et
accordez-le à des rôles pour les packages suivants lorsque cela est nécessaire : UTL_SMTP,
UTL_TCP, UTL_HTTP et UTL_FILE.
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). L'octroi de ce package à PUBLIC peut permettre l'échange non autorisé
de messages électroniques.
• UTL_TCP : Permet l'établissement par le serveur de base de données de 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.
• 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 à PUBLIC peut autoriser l'envoi de
données à un site Web malveillant par l'intermédiaire de panneaux HTML.
• 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. Même lorsqu'il est
configuré correctement, ce package ne distingue pas les applications qui l'appellent.
Autrement dit, une application disposant d'un accès à UTL_FILE peut écrire des
données arbitraires dans le même emplacement qu'une autre application.
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.
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.
Obligations
Moindre privilège
Surveiller les activités suspectes > Audit .
Basé sur
les données
FGA
DBA
Mises à jour
La surveillance ou l'audit doit faire partie sécurité
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 DBA
Surveiller les activités suspectes

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 paramètres d'audit. Cela vient du fait que la base doit
enregistrer des activités telles que le démarrage et l'arrêt du système.
• Audit de base de données standard : Ce type d'audit est défini 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.
• Audit basé sur les données : Il s'agit d'une extension de l'audit de base de données standard
qui capture non seulement la survenue de l'événement audité, mais également les valeurs
insérées, mises à jour ou supprimées. L'audit basé sur les données est implémenté par
l'intermédiaire de déclencheurs (triggers) de base de données.
• Audit détaillé (FGA – fine-grained auditing) : Il s'agit d'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'action a eu lieu.
• Audit de DBA : Répartissez 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 Active l'audit
de base Fichier de
DBA de données Utilisateur
paramètres
Exécute une
commande
2 Définit
les options
Base de données
d'audit
Processus
serveur
Options
Génère la
d'audit
3 Examine les trace d'audit
informations
d'audit
Trace
d'audit Trace d'audit
4 Gère la trace
OS ou XML
d'audit
Audit de base de données standard

Une fois que vous avez activé l'audit de la base de données et indiqué les options d'audit
(événements de connexion, utilisation de privilèges système et de privilèges objet, ou
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 un fichier. L'emplacement de ce fichier est indiqué par le paramètre
AUDIT_FILE_DEST.
Si le paramètre AUDIT_TRAIL a la valeur DB, vous pouvez consulter les enregistrements
d'audit dans la vue DBA_AUDIT_TRAIL faisant partie 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 administrative importante. Selon le ciblage
des options d'audit, la taille de la trace d'audit peut augmenter très rapidement. En l'absence
d'une maintenance appropriée, la trace d'audit peut consommer tant d'espace qu'elle affecte les
performances du système.
Activer l'audit
ALTER SYSTEM SET audit_trail="XML" SCOPE=SPFILE;
Redémarrez la base de données après la modification

d'un paramètre d'initialisation statique.
Activer l'audit
Vous devez activer l'audit de base de données avant de définir des paramètres d'audit.
Traces d'audit uniformes
Utilisez AUDIT_TRAIL pour activer l'audit de base

de données
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

Pour utiliser l'audit de base de données, vous devez d'abord définir le paramètre non
dynamique 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é.
Oracle Database 10g effectue le suivi des mêmes champs pour l'audit standard et l'audit
détaillé. Vous pouvez ainsi analyser facilement les activités de la base de données. Pour cela,
la trace d'audit standard et la trace d'audit détaillé ont 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 dans votre fichier de paramètres d'initialisation.
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.
Traces d'audit uniformes (suite)
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 des enregistrements de l'audit standard
et de l'audit détaillé.
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 Administration, puis sur le lien Audit Settings dans la région
Users & Privileges.
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.
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 met à jour
100 000 enregistrements dans 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 donc indiquer
explicitement BY ACCESS si vous souhaitez un enregistrement d'audit distinct pour chaque action.
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'audit sollicite fortement le système. Par conséquent, désactivez les
options que vous n'utilisez pas.
Obligations
Moindre privilège
Audit basé sur Audit
> Basé sur
les données les données
FGA
DBA
Mises à jour
sécurité
Un utilisateur Un déclencheur Un enregistrement

apporte une s'exécute. d'audit est créé par
modification. le déclencheur.
La modification Un enregistrement d'audit

de l'utilisateur est inséré dans une table
est effectuée. 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 l'audit de base de données en capturant les
valeurs modifiées. Il utilise pour cela des déclencheurs (triggers) de base de données
(structures PL/SQL basées sur les événements).
Lorsqu'un utilisateur insère, met à jour ou supprime des données dans une table à laquelle le
déclencheur approprié est associé, le déclencheur s'exécute en arrière-plan afin de copier les
informations d'audit dans la table destinée au stockage des informations d'audit. 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
que l'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.
Audit basé sur les données (suite)
La clé de l'audit basé sur les données est le déclencheur d'audit. Un déclencheur d'audit
typique se présente de la manière suivante :
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é.
Les déclencheurs de base de données peuvent également être utilisés pour capturer des
informations sur les connexions utilisateur, au cas où l'audit de base de données standard
ne collecterait pas suffisamment de données. Avec des déclencheurs de connexion (login
triggers), l'administrateur peut capturer des données identifiant l'utilisateur qui se connecte
à la base de données. Exemples :
• L'adresse IP de la personne qui se connecte.
• Les 48 premiers caractères du nom du programme utilisé pour la connexion à
l'instance.
• Le 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.
Obligations
Moindre privilège
Audit détaillé Audit
Basé sur
les données
> FGA
• Surveille l'accès aux données en DBA
Mises à jour
fonction du contenu sécurité
• Audite SELECT, INSERT, UPDATE, DELETE

et MERGE
• Peut être lié à une table ou à une vue,
à une ou à plusieurs colonnes
• 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é l'opération. L'audit détaillé (FGA - fine-
grained auditing) étend cette fonctionnalité en autorisant la capture des instructions SQL qui
interrogent ou manipulent les données. Il permet également un ciblage plus précis que l'audit
détaillé ou l'audit basé sur les données.
Les options d'audit détaillé peuvent être ciblées par colonnes individuelles d'une table ou
d'une vue et peuvent même ê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 l'audit au
niveau instruction, de sorte qu'une instruction SELECT qui renvoie des milliers de lignes
génère un seul enregistrement d'audit.
Stratégie d'audit détaillé
dbms_fga.add_policy (
object_schema => 'HR',
object_name => 'EMPLOYEES',
• Définit : policy_name => 'audit_emps_salary',
– les critères audit_condition => 'department_id=10',
audit_column => 'SALARY',
d'audit handler_schema => 'secure',
– l'action d'audit handler_module => 'log_emps_salary',
enable => TRUE,
• Est créée via statement_types => 'SELECT' );
DBMS_FGA
.ADD_POLICY
SELECT name, job_id
FROM employees;
SELECT name, salary

FROM employees SECURE.LOG_
WHERE EMPS_SALARY
department_id = 10; employees
Stratégie d'audit détaillé

L'exemple de la diapositive ci-dessus illustre la création d'une stratégie d'audit détaillé via la
procédure DBMS_FGA.ADD_POLICY. La procédure 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, avec 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'
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 le programme PL/SQL
• Le nom du 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 d'attachement
SQL dans des objets LOB. 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.
• Les instructions MERGE sont auditées avec les
instructions INSERT ou UPDATE sous-jacentes générées.
UPDATE hr.employees
SET salary = 10
WHERE commission_pct = 90;
UPDATE hr.employees
SET salary = 10
WHERE employee_id = 111;
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 ou
UPDATE sous-jacentes sont auditées si elles satisfont à une stratégie d'audit détaillé INSERT
ou UPDATE définie.
Avec la stratégie d'audit détaillé précédemment définie, la première instruction est auditée
alors que la seconde ne l'est pas.
Règles relatives à l'audit détaillé
• Pour auditer toutes les instructions, utilisez

une condition 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 et non les lignes. Toutefois,
lorsque l'audit détaillé est combiné à Flashback Query, les lignes peuvent être reconstruites
telles qu'elles étaient à ce point 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.
Obligations
Moindre privilège
Audit de DBA Audit
Basé sur
les données
FGA
> DBA
Mises à jour
sécurité
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 de données.
• 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 de DBA
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 de données est fermée, la trace d'audit de ces privilèges doit être stockée à
l'extérieur de la base de données. 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 ne capture rien d'autre si l'audit n'est pas explicitement activé.
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
détermine le lieu 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 dans
$ORACLE_HOME/rdbms/audit.
Gérer la trace d'audit
Il est nécessaire d'assurer la maintenance de la trace

d'audit. Respectez les 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. La gestion de base
consiste à examiner les enregistrements d'audit, et à supprimer les enregistrements les plus
anciens de la base de données ou du système d'exploitation. Les traces d'audit peuvent grossir
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.
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 risque d'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 sur la base du même horodatage.
Obligations
Moindre privilège
Mises à jour de sécurité Audit
Basé sur
les données
FGA
DBA
> Mises à jour
sécurité
• Oracle publie les alertes de sécurité
sur le site Web Oracle Technology Network,
à l'adresse suivante :
http://www.oracle.com/technology/deploy/security/alerts.htm
• Les administrateurs de base de données et les
développeurs Oracle peuvent également s'abonner
afin d'être informés par e-mail des alertes de sécurité,
en cliquant sur le lien "Subscribe to Security Alerts Here".
Mises à jour de sécurité

Les alertes de sécurité Oracle contiennent une brève description de la vulnérabilité, une
évaluation du risque et du degré d'exposition associés à la vulnérabilité, ainsi que les solutions
ou patches applicables. Avec Enterprise Manager, vous pouvez gérer vos patches. Oracle
indique la personne ou l'organisation l'ayant informé de la vulnérabilité.
Les alertes de sécurité sont publiées sur le site Web Oracle Technology Network et sur Oracle
MetaLink (MetaLink). Bien que les alertes de sécurité puissent être consultées librement, seuls
les clients disposant d'un numéro CSI (Customer Support Identification) peuvent télécharger
les patches.
Oracle apprécie votre coopération concernant la sécurité de ses produits et permet une
notification rapide, complète et confidentielle des vulnérabilités potentielles. Si vous
découvrez une faille de sécurité concernant un produit Oracle, merci d'en informer Oracle en
soumettant une "Service Request" (SR) via MetaLink ou en envoyant un message électronique
à l'adresse secalert_us@oracle.com.
Appliquer des patches de sécurité
• Employez le processus Critical Patch Update.

• Appliquez l'ensemble des patches de sécurité
et des solutions de contournement.
• Contactez l'équipe des produits de sécurité Oracle.
Appliquer des patches de sécurité

Processus Critical Patch Update (CPU)
En janvier 2005, Oracle a lancé le processus Critical Patch Update (CPU). Il s'agit d'un
regroupement de patches critiques distribué avec une périodicité trimestrielle. Ce programme
remplace les éditions de patches Security Alert. Ces patches cumulatifs incluent les patches
fréquemment demandés et les patches prérequis nécessaires. L'édition trimestrielle de patches
est accompagnée d'une matrice d'évaluation des risques qui vous permet de déterminer
l'impact de ces patches pour votre site et les risques liés à la sécurité. Reportez-vous à la note
MetaLink 290738.1 : "Oracle Critical Patch Update Program General FAQ". Pour recevoir ces
mises à jour, vous devez vous abonner à MetaLink.
Appliquez l'ensemble des patches de sécurité et des solutions de contournement
Appliquez toujours l'ensemble des patches de sécurité pertinents à jour pour le système
d'exploitation sur lequel réside la base de données et les logiciels Oracle, et pour l'ensemble
des options et composants installés.
Contactez l'équipe des produits de sécurité Oracle
Si vous pensez avoir détecté une faille de sécurité dans les logiciels Oracle, suivez les
instructions fournies à partir du lien Security Alerts sur le site http://otn.oracle.com ou
http://www.oracle.com/technology/deploy/security/alerts.htm.
Synthèse
Ce chapitre vous a permis d'apprendre à :

• décrire vos responsabilités de DBA en matière
de sécurité
• appliquer le principe du moindre privilège
• définir les options d'audit
Présentation de l'exercice :
Implémenter la sécurité de la base
de données Oracle
Cet exercice porte sur les points suivants :

• définir des options d'audit pour la table HR.JOBS
• mettre à jour la table
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, 10g Release 2 (10.2), Référence
B14212-01
• Oracle Database, Net Services Reference, 10g Release 2 (10.2),
Référence B14213-01
Services Oracle Net
Application SGBDR
Oracle Net Réseau Oracle Net

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

Oracle Net Oracle Net
Services Oracle Net

Les services Oracle Net permettent 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 un élément qui simule Oracle Net tel 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 inclut un processus actif appelé processus
d'écoute (listener). Le processus d'écoute Oracle Net est responsable de la coordination des
connexions entre la base de données et les applications externes.
L'utilisation la plus courante des services Oracle Net 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
<oracle_home>/network/admin/listener.ora
sqlnet.ora
Processus d'écoute Oracle Net

Le processus d'écoute (listener) Oracle Net 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 au processus d'écoute. 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.
Si nécessaire, les administrateurs chevronnés peuvent également configurer les services
Oracle Net en éditant manuellement les fichiers de configuration à l'aide d'un éditeur de texte
standard du système d'exploitation tel que vi ou gedit.
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 :
• l'hôte sur lequel le processus d'écoute s'exécute
• le port que le processus d'écoute surveille
• le protocole utilisé par le processus d'écoute
• le 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 (listener)
Oracle Net, l'application doit connaître certaines informations sur ce service, notamment
l'adresse ou l'hôte sur lequel le processus d'écoute réside, le protocole accepté par le processus
d'écoute, et le port surveillé par le processus d'écoute. Une fois le processus d'écoute localisé,
l'information finale dont l'application a besoin est le nom du service auquel elle souhaite se
connecter.
Le processus qui consiste à déterminer cette information de connexion est appelé "résolution
de noms".
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 du niveau intermédiaire (middle tier), appelé(e) processus
utilisateur par la suite, au processus d'écoute (listener) Oracle Net. Le processus d'écoute
reçoit un paquet CONNECT et vérifie que ce paquet CONNECT demande un nom de service
Oracle Net valide.
Si le nom du service n'est pas demandé (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
Si le paquet CONNECT demande un nom de service valide, le processus d'écoute (listener)
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 des informations
d'initialisation, notamment l'adresse du processus d'écoute. A ce stade, le processus d'écoute
ne gère plus la connexion et tout le travail est envoyé au processus serveur.
Le processus serveur vérifie les informations d'identification et de connexion (credentials) de
l'utilisateur (généralement un mot de passe). Si elles sont valides, une session utilisateur est
créée.
Processus serveur dédié : La session étant établie, le processus serveur joue à présent 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 (buffer cache) de la base de données à la recherche de
blocs de données requis pour exécuter les instructions SQL.
• Lecture des blocs de données 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 (System Global
Area), si les blocs ne sont pas déjà présents dans la mémoire SGA.
Sessions utilisateur (suite)
• Gestion de toutes les activités de tri. Une partie du processus serveur, appelée
mémoire PGA (Program Global Area), contient une zone de mémoire appelée zone
de tri qui est utilisée pour les opérations de tri.
• 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 des 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 lancé
par Oracle Universal Installer
• Ligne de commande
Outils de configuration et de gestion de l'environnement réseau Oracle

Vous pouvez utiliser l'un quelconque des outils ou applications ci-après pour gérer la
configuration réseau Oracle :
• Enterprise Manager : offre un 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 (listeners).
• Oracle Net Manager : offre une interface utilisateur graphique vous permettant de
configurer Oracle Net Services pour un répertoire d'origine Oracle Home sur un client
local ou un hôte serveur.
• Oracle Net Configuration Assistant : lancé par Oracle Universal Installer lors de
l'installation du logiciel Oracle. Il vous permet de configurer l'adresse du protocole
d'écoute et les informations relatives aux services pour une base de données Oracle.
• Ligne de commande : permet de démarrer et d'arrêter le processus d'écoute, et
d'afficher son statut. C'est un utilisateur du système d'exploitation (dans ce cours,
oracle) 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 du processus d'écoute
Les processus d'écoute Oracle Net peuvent être

contrôlés à l'aide de l'utilitaire de ligne de commande
lsnrctl (ou à partir d'Enterprise Manager).
$lsnrctl
LSNRCTL for Linux: Version 10.2.0.0.0 on 12-MAY-2005 13:27:51
Copyright (c) 1991, 2004, Oracle. All rights reserved.
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 du processus d'écoute

Lorsqu'une instance démarre, un processus d'écoute (listener) établit une voie de
communication vers la base de données Oracle. Le processus d'écoute peut alors accepter les
demandes de connexion à la base.
L'utilitaire de contrôle du processus d'écoute vous permet de contrôler ce dernier. Grâce à
lsnrctl, vous pouvez effectuer 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.
Syntaxe de l'utilitaire de contrôle
du processus d'écoute
Les commandes de l'utilitaire de contrôle du processus
d'écoute peuvent être exécutées à partir de la ligne
de commande ou de l'invite LSNRCTL.
• Syntaxe de la ligne de commande sous UNIX ou Linux :
$ lsnrctl <command name>
$ lsnrctl start
$ lsnrctl status
• Syntaxe de l'invite :
LSNRCTL> <command name>
LSNRCTL> start
LSNRCTL> status
Syntaxe de l'utilitaire de contrôle du processus d'écoute

Les commandes lsnrctl peuvent être exécutées à partir de l'utilitaire (syntaxe d'invite) ou
de la ligne de commande. Les deux commandes suivantes ont un effet identique. Syntaxe de
ligne de commande :
$ lsnrctl start
Syntaxe d'invite :
$ lsnrctl
LSNRCTL for Linux: Version 10.2.0.0.0 on 12-MAY-2005
Welcome to LSNRCTL, type "help" for information.
LSNRCTL> start
En général, la syntaxe de ligne de commande est utilisée pour exécuter des commandes
individuelles ou des scripts. Si vous prévoyez d'exécuter plusieurs commandes lsnrctl
consécutives, la syntaxe d'invite est la plus efficace. Notez que l'argument listener_name
est omis . La commande STOP affecte donc le processus d'écoute nommé LISTENER. La
syntaxe d'invite doit être utilisée si le processus d'écoute est protégé par 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 le nom du processus d'écoute dans la commande, soit utiliser la commande SET
CURRENT_LISTENER. Supposons que le processus d'écoute soit nommé BACKUP. Voici deux
exemples arrêtant le processus BACKUP à l'aide de la syntaxe d'invite :
LSNRCTL> stop backup
Connecting to
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=rhel)(PORT=5521)))
The command completed successfully
La syntaxe qui suit génère le même résultat :
LSNRCTL> set cur backup
Current Listener is backup
LSNRCTL> stop
Connecting to
Remarque : Dans la syntaxe précédente, current_listener peut être abrégé en cur.
Vous pouvez également obtenir les mêmes résultats avec la syntaxe de ligne de commande :
/home/oracle> lsnrctl stop backup
LSNRCTL for Linux:Version 10.2.0.0.0 on 12-MAY-2005 15:19:33
Connecting to
Page d'accueil Listener
Page d'accueil Listener

Pour accéder à la page d'accueil Listener, cliquez sur le lien Listener dans la page d'accueil
Database d'Enterprise Manager.
Dans cette page, vous pouvez voir :
• le statut et la disponibilité du processus d'écoute (listener) au cours des dernières
24 heures,
• la version du processus d'écoute et le répertoire d'origine Oracle Home,
• la première adresse d'écoute du processus d'écoute,
• l'emplacement des fichiers de configuration utilisés pour démarrer le processus d'écoute,
• l'heure de démarrage du processus d'écoute et les informations relatives à l'hôte.
Pour démarrer le processus d'écoute, accédez à la page d'accueil Database, puis cliquez sur le
nom du processus d'écoute afin d'ouvrir la page d'accueil Listener. 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 dans le
cas contraire. 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.
Pages Net Services Administration
Pages 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
(listeners). Vous pouvez utiliser la page Net Services Administration pour configurer et
administrer les éléments suivants :
• Listeners : 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.
• Directory Naming : Définissez des noms et des identificateurs de connexion simples,
puis mettez-les en correspondance avec des descripteurs de connexion afin d'identifier
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é.
• Local Naming : Enregistrez les noms de service réseau dans le fichier
tnsnames.ora.
• Profiles : Configurez les paramètres du fichier sqlnet.ora.
• File Location : Modifiez l'emplacement des fichiers de configuration des services
réseau.
Créer un processus d'écoute
3
4
Créer un processus d'écoute

Pour créer un processus d'écoute (listener) 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 de la façon suivante :
1. Sélectionnez Listeners dans la liste déroulante Administer et cliquez sur Go.
2. Cliquez sur Create.
3. Entrez un nom pour le processus d'écoute. Le nom doit être unique sur le serveur.
4. Ajoutez une adresse de processus d'écoute. Chaque processus d'écoute doit comporter au
moins une adresse de processus d'écoute.
Ajouter des adresses de processus d'écoute
5
6
7
Ajouter des adresses de processus d'écoute

Suite du workflow de création d'un processus d'écoute :
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), ou des bibliothèques de code
externes (EXTPROC), NMP (Named Pipes) et TCP/IP avec SSL.
Remarque : Les protocoles NMP et EXTPROC sont configurés via l'onglet Other
Services.
6. Entrez le port que doit surveiller le processus d'écoute. Le 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 (listener) ou pour l'instance.
7. Entrez le nom ou l'adresse IP du serveur sur lequel le processus d'écoute s'exécutera.
8. Toutes les autres procédures 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. Cliquez sur OK pour
enregistrer vos modifications.
9. 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 (listener) transmette des connexions client à une instance, le
processus d'écoute doit connaître le nom de l'instance et savoir où se trouve le répertoire d'origine
ORACLE_HOME de l'instance. Le processus d'écoute peut trouver ces informations de deux façons :
• Enregistrement dynamique de services : Les instances Oracle8i, Oracle9i et Oracle
Database 10g 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 précédentes versions de la base de données 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. Vous pouvez tout de même opter pour l'enregistrement statique
de services avec les versions plus récentes 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 services.
Pour ajouter un service statique de base de données, 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. Vous devez
redémarrer le processus d'écoute pour que les modifications prennent effet.
Méthodes de résolution de noms
Oracle Net prend en charge plusieurs méthodes
de résolution des informations de connexion :
• Résolution de noms Easy Connect : utilise
une chaîne de connexion TCP/IP
• Résolution locale de noms : utilise un fichier
de configuration local
• Résolution de noms d'annuaire : utilise un serveur
de services annuaire LDAP centralisé
• 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
• Prend en charge uniquement le protocole TCP/IP (pas SSL)
• Ne prend pas en charge les options de connexion
avancées telles que :
– Gestion des incidents de connexion
– Routage source
– Equilibrage de la charge
SQL> CONNECT hr/hr@db.us.oracle.com:1521/dba10g
Pas de fichiers de configuration Oracle Net
Easy Connect
Avec Easy Connect, vous fournissez toutes les informations requises pour la connexion
Oracle Net dans le cadre de la chaîne de connexion. Les chaînes de connexion Easy Connect
se présentent sous la forme suivante :
<username>/<password>@<hostname>:<listener port>/<service name>
Le port du processus d'écoute (listener) et le nom du service sont facultatifs. Si le port du
processus d'écoute n'est pas indiqué, Oracle Net suppose que le port par défaut (1521) est
utilisé. Si le nom du service n'est pas fourni, Oracle Net suppose que le nom du service de
base de données et le nom d'hôte fournis dans la chaîne de connexion sont identiques.
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 peut accepter 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
telles que :
– 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 hôte, protocole, port et nom de 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 :
<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.
La 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 des 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 hôte, protocole, port et 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 la résolution de noms d'annuaire est que dès que le nom d'un nouveau
service est ajouté à l'annuaire LDAP, les utilisateurs peuvent se connecter par l'intermédiaire
du nom de ce service. Avec la résolution locale de noms, l'administrateur de base de données
(DBA) doit d'abord distribuer des fichiers tnsnames.ora mis à jour contenant les noms
des services modifiés pour que les utilisateurs puissent se connecter à des services nouveaux
ou modifiés.
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 :
– 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
Créer ou
modifier
Configurer des alias de service

Pour créer un alias de service Oracle Net, sélectionnez Local Naming dans la liste déroulante
Administer et cliquez sur Go, puis 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 entrent pour utiliser l'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 au nom de service.
Pour l'adresse, entrez le protocole, le port et l'hôte utilisés par le processus d'écoute (listener)
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 de connexion
• Equilibrage de la charge
• Routage source
Options de connexion avancées

Avec les options de connexion avancées, Oracle Net peut tirer parti de la gestion des incidents
de connexion et de l'équilibrage de la charge pour le processus d'écoute (listener), ainsi que du
routage source Oracle Connection Manager.
Lorsque la gestion des incidents de connexion 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é.
Lorsque l'équilibrage de la charge est activé, Oracle Net sélectionne une adresse aléatoire
dans la liste des adresses.
Le routage source est utilisé avec Oracle Connection Manager. Oracle Connection Manager
joue le rôle de serveur proxy pour le trafic Oracle Net, ce qui permet le routage sécurisé du
trafic Oracle Net 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.
Options de connexion avancées (suite)
Notez que vous disposez de cinq options pour la gestion des incidents de connexion et
l'équilibrage de la charge. Les cinq options sont les suivantes :
Option Fonctionnalité avancée

Essayer chaque adresse, dans l'ordre, jusqu'à ce Gestion des incidents
que l'une fonctionne.
Essayer chaque adresse, dans un ordre aléatoire, Gestion des incidents
jusqu'à ce que l'une 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 que Routage source
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 :

• garantit 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 db.us.oracle.com:1521/dba10g
• 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
(listener). En revanche, il ne vérifie pas si le processus d'écoute traite le nom de service. Un
autre élément utile révélé par tnsping est l'emplacement des fichiers de configuration. Dans
un système avec plusieurs emplacements ORACLE_HOME, cela peut s'avérer utile.
Sessions utilisateur : Serveurs dédiés
Processus serveur
Processus serveur
Processus serveur
Processus d'écoute
Sessions utilisateur : Serveurs dédiés

Avec les processus serveur dédiés, il existe un rapport un à un entre les processus serveur et
les 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 prohibitives et affecter de manière négative l'évolutivité du
système. Si les demandes de ressources de l'architecture "serveur dédié" ont un impact négatif
sur le système, les deux possibilités suivantes s'offrent à vous :
• Augmentation des ressources système en ajoutant de la capacité mémoire et CPU
• Utilisation de l'architecture Oracle Shared Server
Sessions utilisateur : Serveurs partagés
Répartiteur
Processus serveur
Processus serveur
Processus serveur
Processus d'écoute
Sessions utilisateur : Serveurs partagés

Chaque service qui participe à l'architecture "serveur partagée 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 gère une liste de répartiteurs
disponibles pour chaque nom de service, ainsi que la charge de connexion (nombre de connexions
simultanées) pour chaque répartiteur.
Les demandes de connexion sont acheminées vers le répartiteur le moins chargé qui gère un nom
de service donné. Les utilisateurs restent connectés au même répartiteur pour la durée d'une
session.
Contrairement aux processus serveur dédiés, un même répartiteur peut gérer des centaines de
sessions utilisateur.
Les répartiteurs ne traitent pas à proprement parler le travail des demandes utilisateur. Ils
transmettent les demandes utilisateur à une file d'attente commune située dans la partie zone de
mémoire partagée de la mémoire SGA.
Les processus serveur partagés prennent en charge la majeure partie du travail des 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
Unauthorized dans la zoneordedistribution
reproduction mémoire LARGE POOL
prohibitedฺ de la mémoire
Copyright© 2009,SGA.
Oracle and/or its affiliatesฺ
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.
SGA PGA
Données Zone de mémoire

Etat du Données Espace
de session LARGE POOL et autres
utilisateur
curseur de tri de pile
structures mémoire
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 de mémoire 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, en cas de prise en charge de nombreux 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 pouvez limiter 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
Client délai indiqué et un client entrant
inactif demande une connexion.
Client
actif
Serveur de Le nombre maximal

Nouveau base de de connexions est 255.
client données
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 quel cas ne pas utiliser
de serveur partagé ?
Certains types de travail 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 batch et opérations de chargement
en masse
• Opérations de data warehouse
Répartiteur Processus
serveur dédié
Dans quel 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 warehouse ou le traitement batch.
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 des index et des
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.
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
Maintenance proactive
Objectifs

• utiliser des statistiques
• gérer le référentiel AWR
(Automatic Workload Repository)
• utiliser le moniteur ADDM
(Automatic Database Diagnostic Monitor)
• décrire 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

automatisées
Alertes Infrastructure
serveur de conseil
Référentiel AWR
Efficace
Data warehouse de Collecte automatique des Accès direct

la base de données statistiques importantes à la mémoire
La maintenance proactive est facilitée par l'infrastructure sophistiquée de la base de données
Oracle. Les principaux éléments de cette infrastructure sont les suivants :
• AWR (Automatic Workload Repository) est un référentiel intégré dans chaque base de
données Oracle. A intervalles réguliers, la base Oracle prend un cliché (snapshot) de
l'ensemble des statistiques essentielles et des informations relatives à la charge globale,
et les stocke 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 de données.
• 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
des sauvegardes régulières afin d'optimiser la disponibilité ou la régénération des
statistiques, qui sont utilisées pour optimiser l'exécution des instructions SQL.
• Pour les problèmes ne pouvant pas être résolus automatiquement et nécessitant une
notification aux administrateurs (par exemple un manque d'espace), la base de données
Oracle fournit des alertes générées par le serveur. La base Oracle peut se surveiller elle-
même et envoyer des alertes pour vous informer de tout problème. Ces alertes
fournissent également des recommandations relatives à 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. Memory Advisor et SQL Advisor en sont des
exemples.
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 (baseline) : ensemble de données
collectées dans "une base de données fonctionnant
normalement" en vue d'une comparaison
de performances.
• Mesure de performances : taux de variation
d'une statistique cumulée.
• Statistiques : ensembles de données utilisés
pour l'optimisation des opérations internes,
telles que l'exécution d'une instruction SQL.
• 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 des sessions récentes.
Les statistiques sont un ensemble de données fournissant davantage de détails sur la base de
données 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 données de référence doivent inclure les statistiques suivantes :
• Statistiques relatives à l'application (volumes de transactions, temps de réponse)
• Statistiques relatives à la base de données
• Statistiques relatives au système d'exploitation
• Statistiques relatives aux E/S disque
• Statistiques relatives au réseau
> Statistiques
AWR
Statistiques destinées à l'optimiseur ADDM
Fonctions
de conseil
Alertes
Tâches
Les statistiques destinées à l'optimiseur : automatisées
• ne fournissent pas des données en temps réel

• persistent entre les redémarrages de l'instance
• sont 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 colecté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.
L'impact, en termes de performances, de la maintenance de statistiques en temps réel
concernant la répartition des données serait 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 le travail
préconfiguré GATHER_STATS_JOB, qui s'exécute au cours de périodes de maintenance
prédéfinies, une fois par jour.
Statistiques destinées à l'optimiseur (suite)
Une table volumineuse qui connaît une croissance (ou une diminution) de 10 % au cours d'une
période de 24 heures est généralement considérée comme trop volatile pour que la collecte de
statistiques une fois par jour soit suffisante. Pour ce type de table, Oracle recommande de
collecter les statistiques plus fréquemment, si possible suffisamment souvent pour que la
variation ne soit jamais supérieure à 10 % entre deux périodes de collecte. Cela nécessite une
collecte manuelle de statistiques.
Les statistiques peuvent être collectées manuellement à l'aide d'Enterprise Manager, ou via le
package DBMS_STATS, comme indiqué ci-dessous :
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.
Utiliser la page Manage
Optimizer Statistics
Utiliser la page Manage Optimizer Statistics

Pour accéder à la page Enterprise Manager de gestion des statistiques destinées à l'optimiseur,
cliquez sur Manage Optimizer Statistics dans l'onglet Administration. Dans la page présentée
dans la diapositive, le travail GATHER_STATS_JOB est activé. Il s'est exécuté neuf fois. Sa
dernière exécution a porté sur 97 objets et l'opération a pris à peine plus d'une minute. Pour
que le travail GATHER_STATS_JOB fonctionne correctement, vous devez vérifier que la
valeur du paramètre d'initialisation STATISTICS_LEVEL est au moins TYPICAL.
Remarque : La fenêtre par défaut pour ce travail va de 22h00 à 6h00 en semaine, et de midi
le samedi, à midi le lundi pour le week-end. A la fin de la fenêtre de maintenance, le
planificateur arrête par défaut le travail GATHER_STATS_JOB. Les objets restants sont
traités au cours de la fenêtre de maintenance suivante.
Utiliser la page Manage Optimizer Statistics (suite)
Dans cette page, vous pouvez effectuer les opérations suivantes sur les statistiques :
• Collecter manuellement des statistiques destinées à l'optimiseur. Cette action
soumet le travail qui est réalisé automatiquement par GATHER_STATS_JOB.
Vous devez procéder de la sorte si le contenu d'une table a tellement changé entre
les travaux de collecte automatique que les statistiques ne représentent plus
fidèlement la table. C'est le cas, par exemple, si une table est vidée en milieu de
journée, ou si un traitement batch s'exécute et ajoute des quantités importantes de
données à une table.
• 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.
Niveaux de statistiques
STATISTICS_LEVEL
BASIC TYPICAL ALL
Fonctionnalités Statistiques
de réglage Valeur par défaut supplémentaires pour
automatique recommandée le diagnostic manuel
désactivées d'instructions SQL
Niveaux de statistiques
Vous pouvez contrôler le jeu de statistiques à capturer à l'aide du paramètre d'initialisation
STATISTICS_LEVEL, qui autorise les niveaux de capture suivants :
• BASIC : Le calcul des statistiques et des mesures de performances AWR est désactivé.
• TYPICAL : Seules certaines des statistiques sont collectées. Il s'agit des statistiques
nécessaires pour surveiller le comportement de la base de données Oracle. Cette collecte
automatique de statistiques 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 ne doit être
utilisé que dans les rares cas où vous avez besoin d'informations supplémentaires pour le
diagnostic d'instructions SQL.
Statistiques
> AWR
Référentiel AWR ADDM
Fonctions
(Automatic Workload Repository) de
. conseil
Alertes
Tâches
automatisées
• 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 7 jours
• Constitue la base de toutes les fonctions
de gestion automatique
Statistiques 60 minutes
en mémoire MMON Clichés
SGA
AWR
Référentiel AWR (Automatic Workload Repository)

Le référentiel AWR est l'infrastructure qui fournit aux composants d'Oracle Database 10g 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 sockées les statistiques relatives à la base de données, les mesures
de performances, etc.
Par défaut, toutes les 60 minutes, la base de données capture automatiquement des
informations statistiques à partir de la mémoire SGA. Ces informations sont stockées 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 sept 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. La base de données Oracle ne prend pas en charge
l'accès direct au référentiel par les instructions SQL. Utilisez Enterprise Manager ou le
package DBMS_WORKLOAD_REPOSITORY pour travailler avec le référentiel AWR.
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
…
ADDM à réglage à réglage
Clients internes automatique automatique
Infrastructure du référentiel AWR

Les principaux éléments de l'infrastructure du référentiel AWR sont les suivants :
• Une fonction de collecte de statistiques en mémoire utilisé par les composants d'Oracle
Database 10g pour obtenir des statistiques. 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 de données Oracle permet
de capturer automatiquement des données statistiques historiques, sans l'intervention du DBA.
Jeux de clichés 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);
Jeux de clichés AWR

En utilisant des jeux de clichés, vous pouvez baliser des ensembles de données de cliché pour
des périodes importantes. Un jeu de clichés est défini sur une paire de clichés. Ces derniers sont
identifiés par leur numéro de séquence (snap_id). Chaque jeu de clichés correspond à une
seule paire de clichés.
Un jeu de clichés peut être identifié par un nom fourni par l'utilisateur ou par un identificateur
généré par le système. Pour créer un jeu de clichés, il vous suffit d'exécuter la procédure
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE, et d'indiquer un nom et une paire
d'identificateurs de cliché. Un identificateur est affecté au nouveau jeu de clichés. Les
identificateurs de jeu de clichés sont uniques pour toute la durée de vie d'une base de données.
Les jeux de clichés sont utilisés pour conserver les données de clichés. Par conséquent, les
clichés appartenant à des jeux sont conservés jusqu'à la suppression de ces derniers.
Vous pouvez configurer des jeux de clichés, généralement à partir de périodes représentatives
dans le passé, afin de les utiliser pour une comparaison avec le comportement actuel du
système. Vous pouvez également configurer des alertes basées sur des seuils à l'aide de jeux de
clichés à partir de Database Control.
Vous pouvez obtenir les numéros de séquence (snap_id) directement à partir de
DBA_HIST_SNAPSHOT ou d'Enterprise Manager 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

Sélectionnez Administration > Database Administration > Statistics Management >
Automatic Workload Repository et 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 (baselines), également nommées Preserved Snapshot Sets
(ensembles de clichés conservés).
• Générer un état AWR.
Gérer le référentiel AWR
• Période de conservation
– La valeur par défaut est
de 7 jours.
– Tenez compte des besoins
en termes de stockage.
• Intervalle de collecte
– La valeur par défaut est de 60 minutes.
– 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 (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 (advisors).
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 (snapshots) 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. La valeur ALL 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.
Statistiques
Moniteur ADDM (Automatic AWR
> ADDM
Database Diagnostic Monitor) Fonctions
de conseil
Alertes
Tâches
• Exécution après chaque cliché AWR automatisées
• Surveillance de l'instance et détection
des goulets d'étranglement
• Stockage des résultats dans
le référentiel AWR
Clichés
EM ADDM
Résultats ADDM
AWR
Moniteur ADDM (Automatic Database Diagnostic Monitor)

Contrairement aux autres fonctions de conseil (advisors), le moniteur ADDM s'exécute
automatiquement après chaque cliché (snapshot) 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 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é
• 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
Résultats ADDM
Dans la page Automatic Database Diagnostic Monitor (ADDM), vous pouvez voir les
résultats détaillés de la dernière exécution d'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 présente les éléments suivants :
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 une analyse
antérieure) 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.
Vous pouvez cliquer 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 é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 (advisors) : 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.
Statistiques
AWR
Infrastructure de conseil ADDM
> Fonctions
de conseil
Alertes
Tâches
automatisées
SQL Tuning PGA PGA Advisor

Advisor
Buffer Cache
Mémoire Advisor
SGA
ADDM
SQL Access Library Cache
Advisor Advisor
Segment Advisor
Espace
Undo Advisor
Sauvegarde MTTR Advisor
Infrastructure de conseil
Les fonctions de conseil (advisors) sont des composants serveur qui fournissent des
informations sur l'utilisation des ressources et sur les performances des composants qu'elles
analysent.
En se basant sur les données capturées dans le référentiel AWR, 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 :
• Utilisation d'une interface uniforme pour toutes les fonctions de conseil.
• 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).
Infrastructure de conseil (suite)
Moniteur ADDM (Automatic Database Diagnostic Monitor)
Il s'agit d'un outil d'analyse basé sur le serveur, qui examine les performances de la base
de données toutes les 60 minutes. L'objectif du moniteur ADDM est de détecter de
manière précoce les goulets d'étranglement du système et de recommander des corrections
avant toute dégradation perceptible des performances du système.
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 zone de mémoire partagée, le cache de
tampons (buffer cache) de la base de données et la mémoire PGA (Program Global Area).
Outre ces fonctions de conseil, cette page offre un point de contrôle central de la zone de
mémoire LARGE POOL et de la zone de mémoire Java.
Mean-Time-To-Recover (MTTR) Advisor
MTTR Advisor vous permet de définir la durée nécessaire pour la récupération de la base
de données 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'améliorer les performances.
SQL Tuning Advisor
Cette fonction de conseil analyse une instruction SQL individuelle et fournit des
recommandations pour l'amélioration 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, afin de faciliter l'optimisation des 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".
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 accéder à cette page, 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.
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.
Certaines fonctions de conseil sont décrites plus en détail dans les chapitres "Gérer les
données d'annulation", "Gestion des 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 des paramètres importants des fonctions de conseil.
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 via 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
(advisors).
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.
Statistiques
AWR
Alertes générées par le serveur ADDM
Fonctions
de conseil
> Alertes
Tâches
automatisées
Enterprise Manager
File d'attente
des alertes
serveur
Instance
Oracle La mesure de
performances
dépasse le seuil.
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 de données 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 sur nombre des mesures de performances
importantes du système. Oracle Database 10g 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.
Voici quelques-unes des mesures de performances permettant une notification précoce des
problèmes :
• Average File Read Time (centiseconds)
• Dump Area Used (%)
• Response Time (per transaction)
• SQL Response Time (%)
• Tablespace Used (%)
• Wait Time (%)
Alertes par défaut générées par le serveur
97 % : Seuil critique
85 % : Avertissement
Tablespace
Database Control : Tablespace
Mesures de Space Usage
performances SYSTEM
Resumable Recovery Area Snapshot

Session Low On Too Old
Suspended Free Space
Alertes par défaut générées par le serveur

Par défaut, les alertes générées par le serveur suivantes sont activées :
• Tablespace Space Usage (seuil d'avertissement 85 %, seuil critique 97 %)
• Snapshot Too Old
• Recovery Area Low On Free Space
• Resumable Session Suspended
Remarque : Enterprise Manager Database Control définit automatiquement des seuils pour
les mesures de performances du serveur présentant le type d'objet SYSTEM.
Définir des seuils
Définir des seuils

Pour définir ou modifier un seuil pour l'intégralité de la base de données, sélectionnez
Manage Metrics dans la région Related Links de la page d'accueil de la base de données.
Cliquez sur Edit Threshold. Entrez les valeurs Warning Threshold et Critical Threshold
souhaitées. Les alertes appropriées apparaissent lorsque la base de données atteint les valeurs
indiquées. Si nécessaire, vous pouvez indiquer une action de réponse supplémentaire.
Créer et tester une alerte
1. Indiquez un seuil.
2. Créez un scénario de test.
3. Recherchez une alerte.
1
2
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 d'administration du tablespace et définissez
le seuil souhaité.
2. Utilisez l'action Create like pour dupliquer une table existante et remplissez-la à l'aide
de SQL*Plus.
3. Lorsque vous recevez une erreur indiquant que cette table ne peut pas être étendue,
consultez la page d'accueil Database Instance pour visualiser l'alerte générée.
La plupart des alertes contiennent le nom d'une fonction de conseil (advisor) 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 utilisateur déjà disponible dans 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. Vous accédez à la page General, dans laquelle vous
pouvez indiquer l'adresse électronique à laquelle vous souhaitez recevoir les 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 de l'assistant Edit Notification Rule Database Availability and Critical States, dans
laquelle vous pouvez sélectionner les mesures de performances pour lesquelles vous souhaitez
recevoir des notifications et le niveau de gravité déclenchant ces notifications.
Notification des alertes (suite)
Vous pouvez éventuellement demander à ce 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
similaire au suivant :
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, visible 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 des notifications, procédez comme suit :
1. Dans n'importe quelle page de Database Control, cliquez sur le lien Preferences, visible
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, sélectionnez
Notification Rules. La page Notification Rules apparaît. 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.
• 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 fournies, ou exécutez le
moniteur ADDM ou une autre fonction de conseil (advisor) appropriée afin d'obtenir des
diagnostics plus détaillés sur le comportement du système ou de l'objet.
La plupart des alertes, par exemple Out of Space, sont effacées automatiquement lorsque la
cause du problème disparaît. Toutefois, d'autres alertes 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
page d'accueil, sous Diagnostic Summary. 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
97 % : Seuil critique Effacées
Alertes avec seuil
(avec conservation
d'état) 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
d'état)
Alerte
Basées sur des événements
Types d'alerte et effacement des alertes

Il existe deux types d'alerte générée par le serveur : les alertes avec seuil et les 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. Par exemple :
• 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 d'état (stateful). Ces alertes sont automatiquement
effacées lorsque leur cause disparaît. Les alertes avec conservation d'état apparaissent dans
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 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
d'état (stateless). Ces alertes vont directement dans la table d'historique. L'effacement des alertes
sans conservation d'état n'est pertinent que dans l'environnement Database Control, car ce
dernier stocke ces alertes dans son propre référentiel.
Statistiques
AWR
Tâches de maintenance ADDM
Fonctions
automatisées . de conseil
Alertes
> Tâches
• Le planificateur lance des travaux. automatisées
• Les travaux s'exécutent dans la fenêtre
de maintenance par défaut.
• Il est possible de limiter l'impact de
la maintenance sur le fonctionnement
normal à l'aide de Resource Manager.
Exemples de travaux de maintenance :
• Collecte des statistiques destinées
à l'optimiseur
• Collecte des informations relatives
aux segments
• Sauvegarde de la base de données
Tâches de maintenance automatisées

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 une "fenêtre de maintenance"
prédéfinie.
Par défaut, la fenêtre de maintenance commence à 22 h00 chaque soir et dure jusqu'à 6 h00 le
matin suivant, ainsi que tout le week-end. Tous les attributs de la fenêtre de maintenance sont
personnalisables, notamment les heures de début et de fin, la fréquence, les jours de la
semaine, etc. Il est également 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.
Voici des 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.
• Segment Advisor comporte des travaux par défaut qui sont exécutés 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 la base.
Synthèse

• utiliser des statistiques
• gérer le référentiel AWR (Automatic Workload
Repository)
• utiliser le moniteur ADDM (Automatic Database
Diagnostic Monitor)
• décrire 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

• gérer la base de données de façon proactive
à l'aide du moniteur ADDM
– 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
• régler les instructions SQL à l'aide de SQL Tuning
Advisor
• régler les instructions SQL à l'aide de SQL Access
Advisor
• utiliser la gestion automatique de la mémoire partagée
(ASSM -Automatic Shared Memory Management)
• utiliser Memory Advisor pour dimensionner
les mémoires tampon
• consulter les vues dynamiques des performances
• résoudre les problèmes concernant des objets
non valides et inutilisables
Oracle Database 10g: Administration Workshop I 13-2
> Surv. performances
Tuning Advisor
Surveillance des performances Access Advisor
Mémoire
Statistiques
Objets non valides
Problèmes
Problèmes
d'allocation
d'allocation
de
demémoire
mémoire
Contention
Contentiondes
des Contention
Contention
périphé-riques
périphé-riques des
des
d'entrée/sortie
d'entrée/sortie ressources
ressources
?
Problèmes DBA Goulets
Problèmesliés
liés Goulets
au d'étranglement
aucode
codedes
des d'étranglement
applications réseau
réseau
applications
Surveillance des performances

Pour administrer une base de données Oracle Database 10g et garantir son bon
fonctionnement, l'administrateur de base de données (DBA) doit surveiller régulièrement ses
performances afin de localiser les goulets d'étranglement et de 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 10g : Atelier SQL Tuning.
Surveillance des performances (suite)

L'onglet Performance d'Enterprise Manager est le portail menant à un ensemble d'outils de
surveillance des performances et de réglage (tuning). Le premier écran 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 entraînent le plus
d'événements Wait. Dans l'écran de la diapositive ci-dessus, vous pouvez noter une
augmentation récente de l'utilisation de la CPU et des événements Wait pour User I/O,
System I/O et Concurrency. Vous pouvez cliquer sur l'une de 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.).

Lorsque vous effectuez une hiérarchisation 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. Vous obtenez aussi 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'onglet principal Performance présente également les graphiques Instance Disk I/O et
Instance Throughput.
Surveillance des performances :
Option Top Sessions
Surveillance des performances : Option Top Sessions

Lorsque vous cliquez sur le nom d'une des catégories d'E/S, vous accédez à la page Top
Consumers, qui répertorie les services, les modules, les actions, les clients et les sessions les
plus consommateurs de ressources. Elle fournit aussi des statistiques essentielles telles que le
nombre de lectures et d'écritures logiques et physiques, le nombre d'analyses (parses) et le
nombre de tris. Si vous cliquez sur le nom d'une catégorie d'E/S, la statistique associée
devient la valeur de tri de la liste.
Le tableau présenté dans la diapositive répertorie les sessions, triées en fonction de
l'utilisation de la CPU. Vous constatez que l'utilisateur SH de la session 152 est le plus grand
consommateur de CPU à ce moment donné.
Surveillance des performances :
Option Top Services
Surveillance des 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 noms de service vous permet de surveiller les performances
avec davantage de précision. Dans l'exemple de la diapositive ci-dessus, on compte trois
services : inventory, orcl et hr. 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. La liste indique clairement que le service
applicatif inventory est celui des trois qui a été le plus actif au cours de l'intervalle de cinq
minutes considéré
Surv. performances
> Tuning Advisor
SQL Tuning Advisor : Access Advisor
Mémoire
Présentation Statistiques
Objets non valides
Optimiseur ATO Réglage des instructions SQL

en mode Comprehensive
Mode de Détecter les statistiques

vérification obsolètes ou manquantes
des statistiques
Mode de réglage Régler le plan

de plan des instructions SQL
(profil SQL)
Mode d'analyse Ajouter les index manquants

des chemins Exécuter Access Advisor
d'accès
Mode d'analyse
SQL Tuning Restructurer
des instructions Advisor les instructions SQL
SQL
SQL Tuning Advisor : Présentation

SQL Tuning Advisor est l'élément principal du processus de réglage (tuning). Il appelle
l'optimiseur ATO (Automatic Tuning Optimizer) pour réaliser quatre types d'analyse
spécifiques.
• Analyse des statistiques : L'optimiseur ATO vérifie chaque objet d'interrogation pour
déterminer si des statistiques sont obsolètes ou manquantes, et il émet des
recommandations pour la collecte des statistiques appropriées.
• Profilage (profiling) des instructions SQL : L'optimiseur ATO vérifie ses propres
estimations et collecte des informations auxiliaires pour éliminer les erreurs possibles. Il
construit un profil SQL à l'aide de ces informations auxiliaires et émet une
recommandation pour sa création. La création d'un profil SQL permet à l'optimiseur
d'instructions de générer un plan bien réglé.
• Analyse des chemins d'accès : L'optimiseur ATO vérifie si un nouvel index peut être
utilisé pour améliorer de façon significative l'accès à chaque table référencée dans
l'interrogation. Si c'est le cas, il émet des recommandations concernant la création de cet
index.
• Analyse de la structure des instructions SQL : L'optimiseur ATO tente d'identifier les
instructions SQL qui utilisent des plans inappropriés et émet des suggestions concernant
leur restructuration. Les modifications suggérées peuvent être d'ordre syntaxique ou
sémantique.
SQL Tuning Advisor :
Options et recommandations
SQL Tuning Advisor : Options et recommandations

Une fois SQL Tuning Advisor lancé, Enterprise Manager crée automatiquement une tâche de
réglage (tuning), à condition que l'utilisateur dispose des privilèges ADVISOR appropriés
pour cette opération. La tâche de réglage et les options par défaut sont affichées dans la page
SQL Tuning Options. Dans cette page, l'utilisateur peut modifier les valeurs par défaut d'une
tâche de réglage. Il est important de choisir la portée appropriée pour la tâche de réglage. Si
vous choisissez l'option Limited, SQL Tuning Advisor émet seulement des recommandations
basées sur l'analyse des statistiques, l'analyse des chemins d'accès et l'analyse de la structure
des instructions SQL. Aucune recommandation concernant le profil des instructions SQL n'est
générée. Si vous choisissez l'option Comprehensive, SQL Tuning Advisor émet les mêmes
recommandations qu'avec l'option Limited, mais il appelle l'optimiseur en mode de profilage
(profiling) des instructions SQL afin de construire un profil SQL s'il y a lieu. Avec cette
option, vous pouvez indiquer une durée maximale pour la tâche de réglage, la valeur par
défaut étant de 60 minutes. Après avoir sélectionné Run SQL Tuning Advisor, configurez la
tâche de réglage dans la page SQL Tuning Options. Revenez à la page Top SQL et cliquez sur
l'instruction réglée afin d'accéder à la page SQL Details, dans laquelle l'historique des
recommandations est affiché. Celui-ci indique que la tâche de réglage est terminée. Cliquez
sur la tâche pour voir les recommandations générales correspondantes. Cliquez sur View
Recommendations pour voir les détails concernant la tâche.
Utiliser SQL Tuning Advisor
• Utilisez SQL Tuning Advisor pour analyser des

instructions SQL et obtenir des recommandations
concernant leurs performances.
• Pour indiquer la source des instructions
à analyser, vous avez le choix entre les options
suivantes :
– Top SQL : Analyse des instructions SQL les plus
consommatrices de ressources actuellement
actives.
– SQL Tuning Sets : Analyse d'un ensemble
d'instructions SQL que vous fournissez.
– Snapshots : Analyse d'un cliché.
– Baselines : Analyse d'une ligne de base.
Utiliser SQL Tuning Advisor

Vous pouvez utiliser SQL Tuning Advisor pour analyser des instructions SQL et obtenir des
recommandations concernant leurs performances. Vous exécutez généralement cette fonction
de conseil pour améliorer les performances via ADDM.
Vous pouvez également exécuter SQL Tuning Advisor lorsque vous souhaitez analyser les
instructions SQL consommant le plus de temps CPU, d'E/S et de mémoire.
Utiliser SQL Tuning Advisor : Exemple
Utiliser SQL Tuning Advisor : Exemple

Vous pouvez appeler SQL Tuning Advisor en procédant comme suit :
1. Dans la région Related Links de la page d'accueil Database, cliquez sur Advisor Central.
2. Cliquez sur SQL Tuning Advisor. La page SQL Tuning Advisor Links apparaît.
Vous avez le choix entre les options suivantes pour indiquer la source des instructions à
analyser :
- Top SQL : Analyse des instructions SQL les plus consommatrices de ressources
actuellement actives.
- SQL Tuning Sets : Analyse d'un ensemble d'instructions SQL que vous fournissez.
- Snapshots : Analyse d'un cliché (snapshot).
- Baselines : Analyse d'une ligne de base (baseline).
3. Sélectionnez Top SQL. Sélectionnez un intervalle d'analyse de cinq minutes en le désignant à
l'aide de la zone ombrée. Sélectionnez les instructions à analyser au cours de la période
choisie.
4. Cliquez sur Run SQL Tuning Advisor. Vous accédez à la page SQL Tuning Options, qui
affiche les instructions SQL dans l'intervalle. Attribuez un nom et une description à la tâche,
sélectionnez la portée Comprehensive et l'heure de début Immediately.
Cliquez sur OK.
5. Revenez à la page Advisor Central. Le statut des tâches de conseil est indiqué sous l'en-tête
Advisor Tasks dans la région des résultats. Attendez que le statut de la tâche soit Completed.
Vérifiez le statut en cliquant sur le bouton Actualiser de votre navigateur. Sélectionnez la
tâche et cliquez sur View Result. La page SQL Tuning Result apparaît.
6. Sélectionnez
Unauthorized reproduction l'instruction SQL prohibitedฺ
or distribution et cliquez sur View Recommendations.
Copyright© 2009, Oracle and/or its affiliatesฺ
Statistiques sur une instruction SQL
select count(*) from x select count(*) from x
where object_id < 340 where object_id < 220
Chaque instruction entraîne une analyse complète.
Statistiques sur une instruction SQL

SQL Tuning Advisor présente également les statistiques pour un curseur représentant une
instruction SQL. Si vous visualisez les statistiques pour chacun des deux curseurs présentés
dans la diapositive, vous constatez qu'ils entraînent tous les deux une analyse complète (hard
parse) de l'instruction. Cela signifie qu'aucune correspondance n'a été trouvée pour
l'instruction dans le cache "library". Cela est dû à l'utilisation de littéraux au lieu de variables
attachées (bind variables).
Identifier les instructions SQL en double
Variables
attachées
candidates
Identifier les instructions SQL en double

Vous pouvez identifier les instructions SQL en double en cliquant sur Duplicate SQL dans
l'onglet Performance. Les instructions SQL similaires sont regroupées, sauf si elles présentent
des différences de mise en forme ou de littéraux, . Vous pouvez ainsi identifier les
instructions SQL de l'application qui peuvent être consolidées, de manière à réduire les
exigences portant sur le cache "library" et à accélérer l'exécution des instructions.
Surv. performances
Tuning Advisor
Utiliser SQL Access Advisor > Access Advisor
Mémoire
Statistiques
Objets non valides
Utiliser SQL Access Advisor

Vous pouvez utiliser SQL Access Advisor pour régler votre schéma et améliorer les
performances des interrogations. Pour cette fonction de conseil, vous devez identifier une charge
globale SQL, c'est-à-dire un ensemble représentatif d'instructions SQL accédant au schéma. Vous
pouvez sélectionner la charge globale à partir de différentes sources, notamment à partir de la
charge globale en cours ou d'une charge récente, ou d'un référentiel (repository) d'instructions
SQL. Vous pouvez également utiliser une charge globale définie par l'utilisateur, provenant par
exemple d'un environnement de développement.
SQL Access Advisor peut émettre des recommandations telles que la création d'index ou de vues
matérialisées pour améliorer les performances des interrogations constituant la charge
considérée.
Pour appeler SQL Access Advisor, procédez comme suit :
2. Cliquez sur SQL Access pour lancer un assistant. La page SQL Access Advisor: Workload
Source apparaît.
3. Indiquez la source de la charge globale et cliquez sur Next. La page SQL Access Advisor:
Recommendation Options apparaît.
4. Indiquez si vous souhaitez que la fonction de conseil recommande des index, des vues
matérialisées ou les deux.
Utiliser SQL Access Advisor (suite)
5. Indiquez le mode Limited ou Comprehensive. Le mode Limited est plus rapide car il
se concentre sur les instructions consommant le plus de ressources.
6. Cliquez sur Next. La page SQL Access Advisor: Schedule apparaît. Acceptez
l'exécution immédiate (option par défaut) ou planifiez une exécution ultérieure.
7. Cliquez sur Next. La page SQL Access Advisor: Review apparaît.
8. Passez en revue les options sélectionnées et cliquez sur Submit pour lancer le travail.
Les résultats apparaissent sur la page Advisor Central. Les recommandations de SQL
Access Advisor sont classées selon les gains qu'elles permettent en termes de coût. Par
exemple, une recommandation peut être composée d'un script SQL comprenant une ou
plusieurs instructions CREATE INDEX, que vous pouvez implémenter en cliquant sur
Schedule Implementation.
Surv. performances
Tuning Advisor
Gérer les composants de mémoire Access Advisor
> Mémoire
Statistiques
Objets non valides
• La gestion automatique de la mémoire

partagée (ASMM - Automatic Shared Memory
Management) :
– est recommandée pour simplifier la gestion
– vous permet d'indiquer la mémoire SGA totale
par l'intermédiaire d'un paramètre d'initialisation
– permet au serveur Oracle de gérer la quantité de mémoire
allouée à la zone de mémoire partagée, à la zone
de mémoire Java, au cache de tampons, à la zone de
mémoire Streams et à la zone de mémoire LARGE POOL
• La gestion manuelle de la mémoire partagée :
– dimensionne les composants par l'intermédiaire
de plusieurs paramètres d'initialisation individuels
– utilise Memory Advisor pour émettre
des recommandations
Gérer les composants de mémoire

La mémoire SGA comporte plusieurs composants. La taille de nombre de ces composants
peut être gérée par le serveur Oracle par l'intermédiaire de la fonction de gestion automatique
de la mémoire partagée (ASMM - Automatic Shared Memory Management). Cela simplifie
les tâches de gestion de la mémoire.
Vous pouvez également gérer la taille des composants manuellement en configurant plusieurs
autres paramètres d'initialisation. Si, ultérieurement, le serveur Oracle vous informe d'un
problème de performances lié à la taille de la mémoire SGA (Shared Global Area) ou PGA
(Program Global Area), vous pouvez utiliser Memory Advisor pour déterminer de nouveaux
paramètres appropriés. Memory Advisor peut modéliser l'effet de modifications de
paramètres. En outre, vous pouvez demander à ce que le serveur Oracle règle
automatiquement les paramètres de mémoire importants lorsque les conditions changent. Le
réglage (tuning) automatique est recommandé.
Activer la gestion automatique
de la mémoire partagée
Cliquez sur Enable

pour activer la gestion
automatique de la
mémoire partagée.
Activer la gestion automatique de la mémoire partagée

Si vous n'avez pas activé la gestion automatique de la mémoire partagée (ASMM- Automatic
Shared Memory Management) lors de la configuration de la base de données, vous pouvez
l'activer en procédant comme suit :
1. Cliquez sur Memory Parameters dans la région Instance de la page Administration.
2. Cliquez sur Enable.
La page Enable Automatic Shared Memory Management apparaît.
3. Indiquez la taille totale de la mémoire SGA. Cliquez sur OK.
Vous pouvez augmenter ultérieurement la taille totale de la mémoire SGA en augmentant la
valeur du paramètre d'initialisation SGA_TARGET dans la limite de la valeur indiquée par le
paramètre SGA_MAX_SIZE. Pour plus d'informations, reportez-vous au manuel Oracle
Database Administrator’s Guide.
Remarque : Oracle recommande d'utiliser la gestion automatique de la mémoire partagée
afin de simplifier les tâches de gestion de la mémoire.
Activer la gestion automatique de la mémoire partagée (suite)
Lorsque la fonction de gestion automatique de la mémoire partagée est activée, vous ne
devez pas, au départ, définir de paramètres d'initialisation pour les composants
spécifiques dont elle gère la mémoire. Si, après avoir vu les effets de l'allocation de
mémoire effectuée par cette fonction, vous décidez d'ajuster la mémoire allouée à
certains composants, vous pouvez indiquer des valeurs pour ces derniers. Ces valeurs
sont traitées comme des valeurs minimales pour les composants concernés. Cette
opération limite la quantité de mémoire disponible pour le réglage (tuning)
automatique, mais elle est utile si votre environnement requiert un dimensionnement
spécial non satisfait par la gestion automatique de la mémoire partagée. 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
Gérer manuellement
la mémoire partagée
Gérer manuellement la mémoire partagée

Si vous n'utilisez pas la gestion automatique de la mémoire partagée (ASMM, Automatic
Shared Memory Management), vous devez fournir des valeurs pour chaque composant de la
mémoire SGA lors de l'installation et de la création de la base de données. Procédez comme
suit :
1. Accédez à la page Memory Parameters en cliquant sur le lien Memory Parameters dans
la région Database Configuration de la page Administration.
2. Appelez l'une des fonctions de conseil (advisors) sur la mémoire en cliquant sur le
bouton Advice associé.
3. Cliquez sur Help pour consulter l'aide en ligne afin d'obtenir des informations
supplémentaires sur le fonctionnement de Memory Advisor.
Utiliser Memory Advisor
Utiliser Memory Advisor

Memory Advisor permet de régler la taille des structures mémoire. Vous ne pouvez utiliser
cette fonctionnalité que lorsque le réglage (tuning) automatique de la mémoire est désactivé.
Memory Advisor se compose de trois fonctions de conseil qui fournissent des
recommandations sur les structures mémoire suivantes :
• Zone de mémoire partagée dans la mémoire SGA (System Global Area)
• Cache de tampons (buffer cache) dans la mémoire SGA
• Mémoire PGA (Program Global Area)
Appelez Memory Advisor en procédant comme suit :
2. Cliquez sur Memory Advisor dans la page Advisor Central. La page Memory
Parameters apparaît. Cette page indique la décomposition de la mémoire SGA.
Remarque : Pour pouvoir exécuter Memory Advisor, il est nécessaire de désactiver la
gestion automatique de la mémoire partagée (ASMM - Automatic Shared Memory
Management).
3. Cliquez sur Advice en regard de la valeur Shared Pool ou Buffer Cache afin d'appeler la
fonction de conseil correspondante.
4. Cliquez sur PGA pour accéder à la page de propriétés relative à la mémoire PGA.
Cliquez sur Advice afin d'appeler PGA Advisor.
…
Access Advisor
Statistiques dynamiques Mémoire
> Statistiques
de performances Objets non valides
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

Pour pouvoir émettre un diagnostic pertinent sur les problèmes de performances, il est
nécessaire de disposer de statistiques. La base Oracle peut générer plusieurs types de
statistiques, pour différents niveaux de détail. Aux niveaux système, session et service, elle
peut déterminer des événements Wait et des statistiques cumulées. Le cadre supérieur
présente les statistiques cumulées. Le cadre inférieur regroupe les vues d'événements Wait.
Lorsque vous analysez un problème de performances à l'un de ces trois niveaux, vous
examinez 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. Toutes les
statistiques sont cataloguées dans la vue V$STATNAME>. Environ 360 statistiques sont
disponibles dans la base de données Oracle.
Statistiques dynamiques des performances (suite)
Afficher les statistiques au niveau système
Par 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 auxquelles vous pouvez accéder pour
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 Manual.
Surv. performances
Tuning Advisor
Objets non valides Access Advisor
Mémoire
et inutilisables Statistiques
> Objets non valides
Effet sur les performances :

• Les objets de code PL/SQL sont recompilés.
• Les index sont reconstruits.
Objets non valides et inutilisables

Il est possible de consulter le statut en cours de certains objets de base de données en
interrogeant le dictionnaire de données, décrit dans le chapitre intitulé "Gérer les objets de
schéma". 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 dans le code, vous ne pouvez pas faire
grand chose tant que l'erreur n'est pas résolue. Si la procédure a été valide par le passé et
qu'elle est devenue non valide récemment, vous pouvez résoudre le problème de deux façons
différentes :
• Ne rien faire. La plupart des objets PL/SQL sont recompilés automatiquement si
nécessaire lors d'un appel. Les utilisateurs perçoivent simplement un léger retard dû à la
recompilation des objets. (Dans la plupart des cas, ce retard 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 nécessite deux étapes :
ALTER PACKAGE HR.maintainemp COMPILE;
ALTER PACKAGE HR.maintainemp COMPILE BODY;
Objets non valides et inutilisables (suite)
Les index inutilisables sont rendus valides via leur reconstruction, qui permet de
recalculer les pointeurs. La reconstruction d'un index inutilisable recrée l'index dans un
nouvel emplacement, puis l'index inutilisable est supprimé. Cette opération 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 de mettre à jour la table
de l'index pendant la reconstruction. (Sans le mot-clé ONLINE, les utilisateurs doivent
attendre la fin de la reconstruction pour effectuer une opération LMD sur la table
affectée.)
Enterprise Manager utilise l'action Reorganize pour réparer un index UNUSABLE.
Remarque : La reconstruction d'un index nécessite que de l'espace libre soit disponible
pour l'opération. Vérifiez que l'espace libre est suffisant avant de tenter la reconstruction.
Enterprise Manager vérifie automatiquement les besoins en termes d'espace.
Synthèse
• utiliser Enterprise Manager pour surveiller
les performances
• régler les instructions SQL à l'aide de SQL Tuning
Advisor
• régler les instructions SQL à l'aide de SQL Access
Advisor
• utiliser la gestion automatique de la mémoire partagée
(ASMM - Automatic Shared Memory Management)
• utiliser Memory Advisor pour dimensionner les mémoires
tampon
• consulter les vues dynamiques des performances
• résoudre les problèmes concernant des objets
non valides et inutilisables
Surveiller et améliorer les performances

• Détecter et réparer les index inutilisables
• Utiliser SQL Tuning Advisor
• Utiliser la page Performance d'Enterprise Manager
Concepts de sauvegarde
et de récupération
Objectifs

• identifier les types de défaillance pouvant survenir
dans une base de données Oracle
• décrire comment régler la récupération d'instance
• décrire l'importance des points de reprise,
des fichiers de journalisation et des fichiers
de journalisation archivés
• configurer le mode ARCHIVELOG
Partie de votre travail
Les rôles de l'administrateur sont les suivants :

• Protéger la base de données contre les
défaillances dans toute la mesure du possible
• Augmenter la durée moyenne sans pannes (MTBF)
• Réduire la durée moyenne de récupération (MTTR)
• Limiter les pertes de données
Partie de votre travail

Le rôle de l'administrateur de base de données (DBA) est de garantir que la base est ouverte et
disponible au moment où les utilisateurs en ont besoin. Pour cela, le DBA (généralement en
collaboration avec l'administrateur système) doit effectuer les opérations suivantes :
• Il anticipe et prévient les causes courantes de panne.
• Il tente d'augmenter la durée moyenne sans pannes (MTBF), en s'assurant que le matériel
est le plus fiable possible, que les composants essentiels sont protégés par redondance et
que la maintenance du système d'exploitation est effectuée en temps utile. La base de
données Oracle fournit des options de configuration avancées permettant d'augmenter la
durée moyenne sans pannes, notamment :
- Real Application Clusters (étudié dans le cours Oracle Database 10g : Real
Application Clusters)
- Streams (étudié dans le cours Oracle Database 10g : Implémenter Oracle Streams)
• Il réduit la durée moyenne de récupération (MTTR), en testant à l'avance les procédures de
récupération et en configurant les sauvegardes de sorte qu'elles soient disponibles en cas de
besoin.
• Il limite les pertes de données. Les DBA qui appliquent les méthodes recommandées
peuvent configurer leurs bases de données de sorte qu'aucune transaction validée ne soit
jamais perdue. Les entités permettant de garantir cela sont les suivantes :
- Les fichiers de journalisation archivés, étudiés plus loin dans ce chapitre.
- Les bases de données de secours et Oracle Data Guard (voir le cours Oracle Database
10g : Administration de Data Guard).
Catégories de panne
Les pannes peuvent généralement être réparties

en plusieurs catégories :
• Echec d'une instruction
• Echec d'un processus utilisateur
• Défaillance réseau
• Erreur utilisateur
• Echec d'une instance
• Défaillance physique
Catégories de panne
Les pannes peuvent être réparties en plusieurs grandes catégories :
• Echec d'une instruction : Une opération unique sur la base de données (sélection,
insertion, mise à jour ou suppression) échoue.
• Echec d'un processus utilisateur : Une session unique de la base de données échoue.
• Défaillance réseau : La connexion à la base de données est interrompue.
• Erreur utilisateur : Un utilisateur effectue une opération avec succès, mais cette
opération (suppression d'une table ou saisie de données incorrectes) est incorrecte.
• Echec d'une instance : L'instance de base de données s'arrête de manière inattendue.
• Défaillance physique : Un ou plusieurs fichiers de la base de données sont perdus (ils
ont été supprimés ou le disque a eu une défaillance).
Echec d'une instruction
Problèmes typiques Solutions possibles
Tentative d'entrer des données Aidez les utilisateurs à valider

non valides dans une table et à corriger les données.
Tentative d'effectuer des Accordez les privilèges objet ou
opérations avec des privilèges les privilèges système appropriés.
insuffisants
Echec d'une tentative d'allouer • Activez le mode de reprise

de l'espace après un problème d'allocation
d'espace.
• Augmentez le quota
du propriétaire.
• Ajoutez de l'espace au tablespace.
Erreurs logiques dans Aidez les développeurs à corriger
les applications les erreurs du programme.
Echec d'une instruction

Lorsqu'une opération de base de données échoue, l'intervention d'un DBA peut être nécessaire
pour corriger les erreurs concernant des privilèges utilisateur ou l'allocation de l'espace dans
la base.
Echec d'un processus utilisateur
Un utilisateur procède à L'intervention d'un DBA n'est

une déconnexion anormale. généralement pas nécessaire
pour résoudre les échecs de
La session d'un utilisateur se processus utilisateur.
termine de façon anormale. Les processus en arrière-plan
de l'instance annulent les
Un utilisateur est confronté à modifications non validées et
une erreur de programme qui libèrent les verrous externes.
met fin à la session.
Observez les tendances.
Echec d'un processus utilisateur

Lorsque des processus utilisateur se déconnectent de façon anormale de l'instance, il se peut
que des transactions n'aient pas encore été validées (commit) et nécessitent d'être annulées
(rollback). Le processus en arrière-plan Process Monitor (PMON) interroge périodiquement
les processus serveur afin de vérifier que leurs sessions sont toujours connectées. Si le
processus PMON découvre un processus serveur dont l'utilisateur n'est plus connecté, il
procède à une récupération des transactions en cours. Par ailleurs, il annule les modifications
non validées et libère les éventuels verrous externes (locks) détenus par la session ayant
échoué.
Le DBA n'a généralement pas à intervenir en cas d'échec d'un processus utilisateur, mais il
doit effectuer une surveillance. Le fait qu'un ou deux utilisateurs soient déconnectés de façon
anormale ne doit pas éveiller de soupçons. Un faible pourcentage d'échecs de processus
utilisateur est normal. Les échecs fréquents et systémiques indiquent en revanche d'autres
problèmes. Un pourcentage élevé de déconnexions anormales peut indiquer la nécessité d'une
formation des utilisateurs (au cours de laquelle ils apprennent notamment à se déconnecter
plutôt qu'à quitter simplement les programmes). Ce problème peut également indiquer des
problèmes concernant le réseau ou les applications.
Défaillance réseau
Echec du processus d'écoute Configurez un processus d'écoute

de secours pour prendre en
charge la gestion des incidents
de connexion.
Défaillance d'une carte réseau Configurez plusieurs cartes
réseau.
Echec d'une connexion réseau Configurez une connexion réseau

de secours.
Défaillance réseau
La meilleure solution pour les défaillances réseau consiste à fournir des chemins redondants
pour les connexions réseau. Les processus d'écoute (listeners), connexions réseau et cartes
réseau de secours permettent de limiter la probabilité qu'une défaillance réseau n'affecte la
disponibilité du système.
Erreur utilisateur
Causes typiques Solutions possibles
Un utilisateur supprime Annulez la transaction ou utilisez

ou modifie des données une interrogation flashback pour
par inadvertance. la récupération.
Un utilisateur supprime Récupérez la table dans la corbeille.
une table.
Oracle LogMiner
Erreur utilisateur
Les utilisateurs peuvent supprimer ou modifier des données par inadvertance. Dans ce cas, le
DBA peut être amené à aider les utilisateurs à corriger l'erreur. Si les utilisateurs n'ont pas
encore validé la transaction ou quitté le programme, il suffit d'annuler (roll back) l'opération. En
revanche, s'ils ont déjà validé les modifications, les interrogations flashback peuvent être
utilisées pour déterminer les valeurs antérieures (les données peuvent alors être mises à jour de
manière à restaurer les informations d'origine) :
SQL> SELECT salary FROM employees WHERE employee_id=100;
SALARY
------
25
SQL> SELECT salary FROM employees
2 AS OF TIMESTAMP(SYSTIMESTAMP-INTERVAL’10’ minute)
3 WHERE employee_id=100;
SALARY
------
24000
Lorsque les interrogations flashback ne sont pas possibles parce que la période de conservation
des informations d'annulation a expiré, le DBA peut toujours récupérer les informations
d'origine via Oracle LogMiner.
Erreur utilisateur (suite)
Vous pouvez utiliser Oracle LogMiner pour interroger les fichiers de journalisation en
ligne (online) et les fichiers de journalisation archivés via une interface SQL. Les données
des transactions peuvent persister plus longtemps dans les fichiers de journalisation en
ligne que dans les segments d'annulation (undo). Par ailleurs, si vous avez configuré
l'archivage des informations de journalisation, celles-ci persistent jusqu'à la suppression
des fichiers archivés.
Oracle LogMiner est étudié dans le cours Oracle Database 10g : Administration
Workshop II et dans le manuel de référence Oracle Database: Utilities.
Les utilisateurs qui suppriment une table peuvent la récupérer dans la corbeille, via un
flashback de la table avant la suppression. Pour obtenir des instructions détaillées,
reportez-vous au chapitre intitulé "Procéder à un flashback de la base de données".
Si la corbeille a déjà été purgée, ou si l'utilisateur a supprimé la table avec l'option
PURGE, la table supprimée peut quand même être récupérée via la récupération jusqu'à un
point dans le temps, dès lors que la base de données a été correctement configurée.
La récupération jusqu'à un point dans le temps est étudiée dans le cours Oracle Database
10g : Administration Workshop II et dans le manuel Oracle Database: Backup and
Recovery Advanced User’s Guide.
Echec d'une instance
Panne de courant Redémarrez l'instance à l'aide de

la commande "startup".
La récupération suite à l'échec
Défaillance matérielle d'une instance est automatique,
notamment via la réimplémentation
des modifications des fichiers
Echec d'un des processus de journalisation, puis l'annulation
en arrière-plan des transactions non validées.
Procédures d'arrêt d'urgence Recherchez les causes d'échec

à l'aide du fichier d'alertes,
des fichiers trace et d'Enterprise
Manager.
Echec d'une instance

L'échec d'une instance se produit lorsque l'instance de base de données est arrêtée avant la
synchronisation de tous les fichiers de base de données. L'échec d'une instance peut se
produire suite à une défaillance matérielle ou logicielle, ou suite à l'utilisation des commandes
d'arrêt d'urgence SHUTDOWN ABORT et STARTUP FORCE.
L'implication de l'administrateur dans la récupération suite à l'échec d'une instance consiste
généralement à redémarrer l'instance et à éviter de nouvelles occurrences du problème.
Processus en arrière-plan et récupération :
Point de reprise (CKPT)
Un point de reprise assure les opérations
SGA
suivantes :
Cache de
• Indication des opérations des processus tampons
DBWn au niveau de points de reprise de la base
de données
• Mise à jour de l'en-tête des fichiers
de données avec les informations
de point de reprise Processus
Database
• Mise à jour des fichiers de contrôle Writer
avec les informations de point de reprise (DBWn)
Point de Fichier de
reprise contrôle
(CKPT) Fichiers de
données
Processus en arrière-plan et récupération : Point de reprise (CKPT)

Pour comprendre la récupération d'instance, vous devez comprendre le fonctionnement de
certains processus en arrière-plan.
Toutes les trois secondes (ou plus fréquemment), le processus CKPT stocke des données dans
le fichier de contrôle pour indiquer quels blocs de données modifiés le processus DBWn a
écrit de la mémoire SGA vers le disque. Cette opération est appelée un "point de reprise". Elle
permet d'identifier l'emplacement du fichier de journalisation en ligne (online) à partir duquel
la récupération d'instance doit commencer (cet emplacement est appelé "position du point de
reprise").
Dans le cas d'un changement de fichier de journalisation, le processus CKKPT écrit
également les informations de point de reprise dans les en-têtes des fichiers de données.
Les objectifs des points de reprise sont les suivants :
• Garantir que les blocs de données modifiés en mémoire sont écrits régulièrement sur le
disque afin qu'aucune donnée ne soit perdue en cas de panne système ou de panne de la
base de données.
• Réduire la durée de la récupération d'instance. Seules les entrées écrites dans le fichier
de journalisation en ligne après le dernier point de reprise doivent faire l'objet d'une
récupération.
• Garantir que toutes les données validées (commit) ont été écrites dans des fichiers de
données pendant l'arrêt.
Processus en arrière-plan et récupération : Point de reprise (CKPT) (suite)
Les informations de point de reprise écrites par le processus CKPT incluent la position du
point de reprise, le numéro SCN (System Change Number), l'emplacement du fichier de
journalisation en ligne à partir duquel la récupération doit commencer, les informations
sur les journaux, etc.
Remarque : Le processus CKPT n'écrit pas de blocs de données sur le disque ni de blocs
de journalisation dans les fichiers de journalisation en ligne.
Fichiers de journalisation et LogWriter
SGA Fichiers de journalisation :

Tampon de
• Ils enregistrent les modifications
journalisation apportées à la base de données.
• Ils doivent être multiplexés afin
d'éviter tout risque de perte.
LogWriter
LogWriter effectue une écriture :
(LGWR)
• lors d'une validation (commit)
• lorsqu'un tiers du tampon
Groupe de Groupe de Groupe de
de journalisation est plein
fichiers de fichiers de fichiers de
Groupe 3 3 •
journalisation 1 journalisation 2 journalisation toutes les trois secondes
• avant une écriture par
le processus DBWn
Processus en arrière-plan et récupération : Fichiers de journalisation et LogWriter

Les fichiers de journalisation (fichiers redo log) enregistrent les modifications apportées à la
base de données suite à des transactions et à des opérations internes du serveur Oracle. (Une
transaction est une unité de travail logique, composée d'une ou de plusieurs instructions SQL
exécutées par un utilisateur.) Les fichiers de journalisation permettent de conserver la cohérence
de la base de données suite à une défaillance du système due à une panne de courant, à une
panne de disque, etc. Les fichiers de journalisation doivent être multiplexés, afin que les
informations qu'ils contiennent ne soient pas perdues en cas de défaillance d'un disque.
Le fichier de journalisation est en fait constitué de groupes de fichiers de journalisation. Un
groupe est constitué d'un fichier de journalisation et de ses copies multiplexées. Chaque copie
identique est membre de ce groupe, et chaque groupe est identifié par un numéro. Le processus
LGWR (LogWriter) écrit les enregistrements de journalisation à partir du tampon de
journalisation (redo log buffer) vers tous les membres d'un groupe de fichiers de journalisation
jusqu'à ce que le fichier soit rempli ou qu'une opération de changement de fichier de
journalisation soit demandée. Il procède alors au changement et écrit dans les fichiers du groupe
suivant. Les groupes de fichiers de journalisation sont utilisés de manière circulaire.
Recommandation : Si possible, les fichiers de journalisation multiplexés doivent résider sur
des disques différents.
Processus d'archivage (ARCn)
Le processus d'archivage (ARCn) :
SGA
• est un processus
en arrière-plan facultatif Tampon de
journalisation
• archive automatiquement
les fichiers de journalisation
en ligne lorsque le mode
ARCHIVELOG est configuré LogWriter
pour la base de données (LGWR) Fichiers de
journalisation
archivés
• préserve l'enregistrement
de toutes les modifications
apportées à la base
Fichier de Processus
de données journalisation d'archivage
en ligne
(ARCn)
Processus en arrière-plan et récupération : Processus d'archivage (ARCn)

ARCn est un processus en arrière-plan facultatif. Toutefois, il est essentiel pour la récupération
d'une base de données après la perte d'un disque. Lorsqu'un groupe de fichiers de journalisation
en ligne est plein, l'instance Oracle commence à écrire dans le groupe de fichiers de
journalisation en ligne suivant. Le processus qui consiste à passer d'un groupe de fichiers de
journalisation en ligne à un autre est appelé changement de fichier de journalisation. Le
processus ARCn lance une sauvegarde ou un archivage du groupe de fichiers de journalisation
plein à chaque changement de fichier de journalisation. Il archive automatiquement le fichier de
journalisation en ligne avant que celui-ci soit réutilisé. Toutes les modifications apportées à la
base de données sont ainsi préservées. Il est alors possible de récupérer la base jusqu'au moment
de la panne même si un disque est endommagé.
L'une des décisions importantes relevant du DBA est de déterminer si la base de données doit
être configurée pour un fonctionnement en mode ARCHIVELOG ou en mode NOARCHIVELOG.
• En mode NOARCHIVELOG, les fichiers de journalisation en ligne sont écrasés à chaque
changement de fichier de journalisation.
• En mode ARCHIVELOG, les groupes inactifs de fichiers de journalisation en ligne qui sont
pleins doivent être archivés pour pouvoir être réutilisés.
Remarque : Le mode ARCHIVELOG est essentiel pour la plupart des stratégies de sauvegarde
(de plus, il est très facile à configurer).
Récupération d'instance
La récupération d'instance ou la récupération après panne :
• est provoquée par des tentatives d'ouverture d'une base
de données dont les fichiers n'ont pas été synchronisés
lors de l'arrêt
• est automatique
• utilise les informations stockées dans les groupes
de fichiers de journalisation pour synchroniser
les fichiers
• implique deux opérations distinctes :
– réimplémentation des modifications : les fichiers
de données sont restaurés dans leur état avant l'échec
de l'instance.
– annulation : les modifications effectuées mais non validées
sont annulées (l'état d'origine est rétabli).
Oracle Database 10g procède à une récupération automatique suite à l'échec d'une instance. Il
suffit au DBA de démarrer l'instance normalement. L'instance monte les fichiers de contrôle,
puis tente d'ouvrir les fichiers de données. Si elle découvre que les fichiers de données n'ont
pas été synchronisés lors de l'arrêt, l'instance utilise les informations contenues dans les
groupes de fichiers de journalisation pour réimplémenter les modifications des fichiers de
données jusqu'à l'instant de l'arrêt. Ensuite, elle annule (roll back) les éventuelles transactions
non validées (car le tablespace d'annulation (undo) fait également l'objet de la
réimplémentation).
Phases de la récupération d'instance
1. Fichiers de données
désynchronisés Instance
2. Réimplémentation des SGA
modifications (journalisation)
3. Données validées et Processus en
non validées des fichiers arrière-plan
4. Annulation
Groupe de
5. Données validées dans Fichier de Fichier de fichiers de
données contrôle journalisation
les fichiers SCN : 140 SCN : 143 SCN 74-101
Groupe de
Fichier de Fichier de fichiers de
Annulation données contrôle journalisation
SCN : 129 SCN : 143 SCN 102-143
Fichier de
données
SCN : 99
Base de données
Phases de la récupération d'instance

Pour qu'une instance puisse ouvrir un fichier de données, le numéro SCN (System Change
Number) contenu dans l'en-tête du fichier de données doit correspondre au numéro SCN
stocké dans les fichiers de contrôle de la base.
Si les numéros ne correspondent pas, l'instance applique les données des fichiers de
journalisation en ligne, en réexécutant de manière séquentielle les transactions jusqu'à ce que
les fichiers de données soient à jour. Une fois tous les fichiers de données synchronisés avec
les fichiers de contrôle, la base de données est ouverte et les utilisateurs peuvent se connecter.
Une fois tous les fichiers de journalisation appliqués, toutes les transactions sont appliquées
afin de rétablir la base de données dans l'état dans lequel elle se trouvait au moment de
l'échec. Cela concerne généralement les transactions qui sont en cours, mais qui n'ont pas
encore été validées (commit). Une fois la base de données ouverte, ces transactions non
validées sont annulées (roll back). A la fin de la phase d'annulation de la récupération
d'instance, les fichiers de données contiennent uniquement des données validées.
Régler la récupération d'instance
• Au cours de la récupération d'instance, les

transactions effectuées entre la position du point
de reprise et la fin du fichier de journalisation
doivent être appliquées aux fichiers de données.
• Vous réglez la récupération d'instance en
contrôlant la différence entre la position du point
de reprise et la fin du fichier de journalisation.
Position du point Fin du fichier
de reprise de journalisation
Transactions
Régler la récupération d'instance

Les informations relatives à une transaction sont toujours enregistrées dans les groupes de
fichiers de journalisation avant que l'instance ne renvoie commit complete pour la
transaction. Les informations des groupes de fichiers de journalisation garantissent que la
transaction pourra être récupérée en cas d'échec. Les informations de transaction doivent
également être écrites dans le fichier de données. L'écriture dans le fichier de données a
généralement lieu un peu après l'enregistrement des informations dans les groupes de fichiers de
journalisation, car le processus d'écriture dans les fichiers de données est beaucoup plus lent que
les écritures d'informations de journalisation. (Les écritures aléatoires dans les fichiers de
données sont plus lentes que les écritures en série dans les fichiers de journalisation.)
Toutes les trois secondes, le processus de point de reprise enregistre dans le fichier de contrôle
des informations concernant la position du point de reprise dans le fichier de journalisation.
Ainsi, la base de données Oracle sait que toutes les entrées de journalisation enregistrées avant ce
point ne sont pas nécessaires pour la récupération. Dans le schéma de la diapositive
ci-dessus, les blocs hachurés n'ont pas encore été écrits sur le disque.
Le temps nécessaire à la récupération de l'instance correspond au temps nécessaire pour rétablir
les fichiers de données de leur état au moment du dernier point de reprise jusqu'à l'état
correspondant au dernier numéro SCN enregistré dans le fichier de contrôle. L'administrateur
contrôle cet instant en définissant une durée MTTR cible (en secondes), ainsi que la taille des
groupes de fichiers de journalisation. La distance entre la position du point de reprise et la fin du
groupe de fichiers de journalisation ne peut jamais être supérieure à 90 % du groupe de fichiers
de journalisation le plus petit.
Utiliser MTTR Advisor
• Indiquez la durée souhaitée en secondes
ou en minutes.
• La valeur par défaut est 0 (désactivé).
• La valeur maximale est 3 600 secondes
(une heure).
MTTR Advisor
Pour obtenir de l'aide sur la définition de la durée moyenne de récupération (MTTR) cible,
sélectionnez Enterprise Manager > Administration > Advisor Central > MTTR Advisor.
MTTR Advisor convertit la valeur FAST_START_MTTR_TARGET en plusieurs paramètres
afin de permettre la récupération d'instance dans un délai aussi proche que possible de la
valeur souhaitée.
Si vous attribuez de façon explicite la valeur 0 au paramètre FAST_START_MTTR_TARGET,
le réglage (tuning) automatique des points de reprise est désactivé. Si vous indiquez
explicitement une autre valeur, la fonction Redo Log Advisor est également activée.
Vous devez attribuer au paramètre FAST_START_MTTR_TARGET une valeur conforme au
contrat de niveau de service de votre système. Plus la durée MTTR cible est faible, plus la
surcharge d'E/S est importante en raison de l'écriture de fichiers de données supplémentaires
(ce qui a un impact sur les performances). Toutefois, si vous attribuez une valeur trop élevée à
la durée MTTR, la récupération de l'instance suite à un échec est plus longue.
Défaillance physique

Echec d'un disque 1. Restaurez le fichier affecté à
partir d'une sauvegarde.
2. Si nécessaire, informez la base
Echec d'un contrôleur de de données de l'emplacement du
disque nouveau fichier.
3. Si nécessaire, récupérez le
Suppression ou corruption
fichier en appliquant les
d'un fichier de base de
informations de journalisation.
données
Défaillance physique
Oracle Corporation définit la défaillance physique comme une défaillance entraînant la perte
ou la corruption d'un ou plusieurs fichiers de base de données (fichiers de données, fichiers de
contrôle ou fichiers de journalisation).
La récupération suite à une défaillance physique nécessite la restauration et la récupération
des fichiers manquants. Pour garantir que la base de données pourra être récupérée suite à une
défaillance physique, appliquez les méthodes recommandées décrites dans les pages qui
suivent.
Configurer la base de données afin
d'optimiser la possibilité de récupération
Pour configurer la base de données afin d'optimiser

la possibilité de récupération, vous devez :
• planifier des sauvegardes régulières
• multiplexer les fichiers de contrôle
• multiplexer les groupes de fichiers
de journalisation
• conserver des copies archivées des fichiers
de journalisation
Configurer la base de données afin d'optimiser la possibilité de récupération

Pour protéger vos données de manière optimale, vous devez effectuer les opérations
suivantes :
• Planifier des sauvegardes régulières : La plupart des défaillances physiques
nécessitent la restauration des fichiers perdus ou endommagés à partir d'une sauvegarde.
• Multiplexer les fichiers de contrôle : Tous les fichiers de contrôle associés à une base
de données sont identiques. La récupération suite à la perte d'un fichier de contrôle
unique n'est pas difficile. La récupération suite à la perte de tous les fichiers de contrôle
est beaucoup plus complexe. Protégez-vous contre la perte de tous les fichiers de
contrôle en conservant au moins trois copies.
• Multiplexer les groupes de fichiers de journalisation : Lors de la récupération suite à
l'échec d'une instance ou à une défaillance physique, les informations de journalisation
sont utilisées pour réimplémenter les modifications dans les fichiers de données jusqu'à
la dernière transaction validée. Si les groupes de fichiers de journalisation ne comportent
qu'un seul fichier, il est probable que la perte de ce fichier entraînera la perte de
données. Veillez à disposer d'au moins trois copies de chaque groupe de fichiers de
journalisation, si possible sur des contrôleurs de disque distincts.
Configurer la base de données afin d'optimiser la possibilité de récupération
(suite)
• Conserver des copies archivées des fichiers de journalisation : Si un fichier est
perdu et restauré à partir d'une sauvegarde, l'instance doit appliquer les informations
de journalisation afin de rétablir ce fichier jusqu'au dernier numéro SCN contenu
dans le fichier de contrôle. Par défaut, la base de données peut remplacer les
informations de journalisation une fois qu'elles ont été écrites dans les fichiers de
données. La base de données peut toutefois être configurée pour conserver les
informations de journalisation sous forme de copies archivées des fichiers de
journalisation. La base de données est alors configurée en mode ARCHIVELOG.
Fichiers de contrôle
Protégez la base de données contre les défaillances

en multiplexant les fichiers de contrôle. Il est
recommandé que votre base de données dispose
des éléments suivants :
• Au moins deux copies (Oracle en recommande trois)
du fichier de contrôle
• Chaque copie sur un disque distinct
• Au moins une copie sur un contrôleur de disque
distinct
Fichiers de
contrôle
Un fichier de contrôle est un petit fichier binaire qui décrit la structure de la base de données.
Il doit être accessible en écriture par le serveur Oracle chaque fois que la base de données est
montée ou ouverte. La base de données ne peut pas être montée sans ce fichier. S'il est perdu,
il est nécessaire de le récupérer ou de le recréer. La base de données doit disposer d'un
minimum de deux fichiers de contrôle (si possible trois), sur des disques distincts, afin de
limiter l'impact de la perte de l'un d'entre eux.
Si la base de données a été créée avec l'assistant DBCA (Database Configuration Assistant),
vous disposez de trois fichiers de contrôle (à moins que vous n'ayez modifié ce paramétrage
avant la création de la base).
La perte d'un fichier de contrôle entraîne l'échec de l'instance, car tous les fichiers de contrôle
doivent être disponibles à tout moment. Cependant, la récupération consiste simplement à
copier l'un des autres fichiers de contrôle. La récupération suite à la perte de tous les fichiers
de contrôle est beaucoup plus difficile, mais ce scénario n'est généralement pas
catastrophique.
Fichiers de journalisation
Multiplexez les groupes de fichiers de journalisation afin
de protéger la base contre toute défaillance physique
ou perte de données. Il est recommandé de respecter
les règles suivantes :
• Au moins deux membres (fichiers) par groupe
• Chaque membre sur un disque distinct
• Chaque membre sur un contrôleur de disque distinct
Remarque : L'écriture
dans les fichiers Disque 1 Membre Membre Membre
1 2 1
de journalisation
a un impact important Disque 2 Membre Membre Membre
sur les performances. 2 1 2
Groupe 1 Groupe 2 Groupe 3
Fichiers de journalisation
Les groupes de fichiers de journalisation sont constitués d'un ou de plusieurs fichiers de
journalisation (fichiers redo log). Chaque fichier journal d'un groupe est la copie des autres.
Oracle recommande que les groupes de fichiers de journalisation comportent au moins deux
fichiers, ceux-ci étant répartis sur des disques ou contrôleurs distincts. Ainsi, vous ne risquez
pas de perdre un groupe entier suite à la défaillance d'un périphérique unique.
La perte d'un groupe de fichiers de journalisation entier est l'une des défaillances physiques
les plus graves, car elle peut entraîner la perte de données. La perte d'un membre unique d'un
groupe de fichiers de journalisation comportant plusieurs membres n'est pas grave et n'affecte
pas le fonctionnement de la base de données. Elle donne simplement lieu à la publication
d'une alerte dans le fichier d'alertes. En revanche, la récupération suite à la perte d'un groupe
de fichiers de journalisation entier nécessite des techniques de récupération avancées. Elle est
étudiée dans le cours Oracle Database 10g : Administration Workshop II.
Rappelez-vous que les fichiers de journalisation influencent fortement les performances de la
base de données, car aucune validation ne peut être effectuée tant que les informations
relatives à la transaction n'ont pas été écrites dans les fichiers de journalisation. Vous devez
placer les fichiers de journalisation sur les disques les plus rapides, gérés par les contrôleurs
les plus rapides. Si possible, ne placez aucun autre fichier de base de données sur les mêmes
disques que les fichiers de journalisation. Etant donné qu'un seul groupe fait l'objet d'une
écriture à un instant donné, il n'est pas gênant que des membres de plusieurs groupes résident
sur un même disque.
Multiplexer le fichier de journalisation
Multiplexer le fichier de journalisation

Vous pouvez multiplexer le fichier de journalisation (redo log) en ajoutant un membre à un
groupe de fichiers de journalisation existant. Pour ajouter un membre à un groupe de fichiers
de journalisation (la base de données étant ouverte et sans impact sur les performances pour
les utilisateurs), procédez comme suit :
1. Accédez à la page Redo Log Groups.
2. Sélectionnez un groupe et cliquez sur le bouton Edit, ou cliquez sur le lien
correspondant au numéro du groupe. La page Edit Redo Log Group apparaît.
3. Dans la région Redo Log Members, cliquez sur Add. La page Add Redo Log Member
apparaît.
4. Entrez le nom du fichier et le répertoire. Cliquez sur Continue.
Remarque : Il est recommandé de stocker les membres sur des disques distincts afin de
protéger la base contre la perte totale des entrées de journalisation en cas de défaillance
d'un disque.
Répétez cette procédure pour chaque groupe existant.
Lorsque vous ajoutez le fichier de journalisation à un groupe, le statut de ce dernier est
marqué comme INVALID. Il s'agit de l'état attendu, car aucun membre du groupe n'a encore
fait l'objet d'une écriture. Lorsqu'un changement de fichier de journalisation se produit et que
le groupe non valide devient le groupe actuel, le statut devient CURRENT.
Fichiers de journalisation archivés
Pour préserver les informations de journalisation,
créez des copies archivées des fichiers de
journalisation en procédant de la façon suivante.
1. Indiquez la convention d'appellation des fichiers
de journalisation archivés.
2. Indiquez l'emplacement d'un ou de plusieurs
fichiers de journalisation archivés.
3. Passez la base de données en mode
ARCHIVELOG.
Fichiers de Fichiers de
journalisation journalisation
en ligne archivés
Fichiers de journalisation archivés

L'instance considère les groupes de fichiers de journalisation en ligne comme une mémoire
tampon (buffer) réutilisable dans laquelle sont stockées les informations relatives aux
transactions, en remplissant un groupe et en passant au suivant. Une fois que tous les groupes
sont pleins, l'instance commence à remplacer les informations du premier groupe de fichiers
de journalisation.
Pour configurer la base de données pour une possibilité de récupération maximale, vous devez
ordonner à la base de données de créer une copie du groupe de fichiers de journalisation en
ligne avant d'autoriser son remplacement. Ces copies sont appelées fichiers de journalisation
archivés. Pour faciliter la création des fichiers de journalisation archivés, vous devez procéder
comme suit :
1. Indiquez une convention d'appellation pour les fichiers de journalisation archivés.
2. Indiquez une ou plusieurs destinations pour le stockage des fichiers de journalisation
archivés.
3. Placez la base de données en mode ARCHIVELOG.
Remarque : La destination doit exister pour que la base de données soit placée en mode
ARCHIVELOG. Lorsqu'un répertoire est désigné comme destination, le nom du répertoire doit
se terminer par une barre oblique.
Fichier de journalisation archivé :
Appellation et destinations
Fichier de journalisation archivé : Appellation et destinations

Configurez le nom et la destination des fichiers de journalisation archivés en cliquant sur
Configure Recovery Settings dans la page Maintenance.
Chaque fichier de journalisation archivé doit porter un nom unique, afin d'éviter le
remplacement des fichiers plus anciens. Indiquez le format d'appellation comme illustré dans
la diapositive ci-dessus. Afin de faciliter la création de noms de fichier uniques, Oracle
Database 10g autorise l'utilisation de plusieurs caractères génériques dans le nom :
• %s : inclut le numéro de séquence du fichier dans le nom.
• %t : inclut le numéro de thread dans le nom.
• %r : inclut un ID resetlogs pour garantir que le nom du fichier de journalisation archivé
reste unique, même suite à l'utilisation de certaines techniques de récupération avancées
qui réinitialisent les numéros de séquence des fichiers de journalisation.
• %d : inclut l'ID de la base de données dans le nom.
Le format doit inclure %s, %t et %r. L'utilisation de %d est facultative, mais elle est
obligatoire si plusieurs bases de données partagent la même destination des fichiers de
journalisation archivés.
Les fichiers de journalisation archivés peuvent être écrits dans dix destinations différentes.
Les destinations peuvent être locales (un répertoire) ou distantes (un alias Oracle Net pour une
base de données de secours). Les destinations locales doivent se terminer par une barre
oblique "/" (ou une barre oblique inverse "\" sous Windows).
Fichier de journalisation archivé : Appellation et destinations (suite)
La destination par défaut (numéro 10) envoie les fichiers de journalisation archivés vers
un emplacement déterminé par le paramètre d'initialisation
DB_RECOVERY_FILE_DEST. DB_RECOVERY_FILE_DEST est également appelé
zone de récupération rapide. Cette destination est visible en bas de la page de propriétés
Configure Recovery Settings, sous le nom Flash Recovery Area Location. Si vous ne
souhaitez pas que les archives soient envoyées vers cet emplacement, supprimez
USE_DB_RECOVERY_FILE_DEST.
Pour modifier les paramètres de récupération, vous devez être connecté en tant que
SYSDBA ou SYSOPER.
Mode ARCHIVELOG
• Pour placer la base de données en mode

ARCHIVELOG, procédez de la façon suivante :
1. Cochez la case ARCHIVELOG Mode.
2. Cliquez sur Apply. La base de données ne peut être
placée en mode ARCHIVELOG qu'à partir de l'état
MOUNT.
3. Cliquez sur Yes lorsque vous êtes invité à
redémarrer la base de données.
4. Sauvegardez la base de données.
• Les bases de données en mode ARCHIVELOG
peuvent utiliser toutes les options de sauvegarde
et de récupération.
Mode ARCHIVELOG
Le fait de placer la base de données en mode ARCHIVELOG empêche le remplacement des
fichiers de journalisation tant qu'ils n'ont pas été archivés. La commande SQL suivante permet
de placer la base de données en mode ARCHIVELOG :
SQL> ALTER DATABASE ARCHIVELOG;
Cette commande ne peut être exécutée que lorsque la base de données est dans l'état MOUNT.
L'instance doit donc être redémarrée pour terminer cette dernière étape. Vous êtes invité à saisir
les informations d'identification et de connexion (credentials) auprès du système d'exploitation
et de la base de données suite au redémarrage de la base. Les informations d'identification et de
connexion à la base de données doivent concerner un utilisateur doté des privilèges SYSDBA.
Une fois l'instance redémarrée, les modifications apportées aux processus d'archivage, au format
des fichiers de journalisation et à leur destination prennent effet.
Lorsque la base de données est en mode NOARCHIVELOG (par défaut), la récupération n'est
possible que jusqu'à l'instant de la dernière sauvegarde. Toutes les transactions effectuées après
cette sauvegarde sont perdues.
En mode ARCHIVELOG, la récupération est possible jusqu'à l'instant de la dernière validation
(commit). La plupart des bases de données de production s'exécutent en mode ARCHIVELOG.
Remarque : Sauvegardez la base de données après l'avoir placée en mode ARCHIVELOG car
elle ne peut être récupérée qu'à partir de la dernière sauvegarde effectuée dans ce mode.
Synthèse

• identifier les types de défaillance pouvant survenir
dans une base de données Oracle
• décrire comment régler la récupération d'instance
• décrire l'importance des points de reprise,
des fichiers de journalisation et des fichiers
de journalisation archivés
• configurer le mode ARCHIVELOG
Configurer la base de données afin
d'optimiser la possibilité de récupération

• multiplexer les fichiers de contrôle
• multiplexer les groupes de fichiers de
journalisation
• placer la base de données en mode ARCHIVELOG
• garantir la création de fichiers de journalisation
archivés redondants
Procéder à des sauvegardes
de la base de données
Objectifs

• créer des sauvegardes cohérentes de la base
de données
• sauvegarder la base de données sans l'arrêter
• créer des sauvegardes incrémentielles
• automatiser les sauvegardes de la base
de données
• surveiller la zone de récupération rapide
Solutions de sauvegarde : Présentation
Les sauvegardes peuvent être effectuées via :

• Recovery Manager
• Oracle Secure Backup
• un scénario géré par l'utilisateur
Solutions de sauvegarde : Présentation

Comme indiqué dans le reste de ce chapitre, Recovery Manager (RMAN) est la méthode
recommandée pour la sauvegarde de la base de données Oracle.
Oracle Secure Backup complète les fonctionnalités existantes en permettant la sauvegarde sur
bande et la sauvegarde réseau.
Les sauvegardes gérées par l'utilisateur sont basées sur des scripts qui doivent être écrits par
un DBA. Cette option est abandonnée graduellement car elle demande plus de travail.
Oracle Secure Backup
• Oracle Secure Backup et RMAN fournissent
une solution de sauvegarde de bout en bout pour
les environnements Oracle :
– Gestion centralisée des sauvegardes sur bande pour
les données du système de fichiers et la base Oracle
– Couche de gestion des supports très bien intégrée
pour les sauvegardes RMAN
– Sauvegarde de n'importe quelles données n'importe
où sur le réseau
• Une ressource de support technique unique
pour l'intégralité de la solution de sauvegarde
accélère la résolution des problèmes.
• Il est ainsi possible d'assurer une protection fiable
des données plus simplement et pour un coût moindre.
Oracle Secure Backup

Le produit Oracle actuel de sauvegarde et de récupération de la base de données est Recovery
Manager. Oracle Secure Backup complète les fonctionnalités existantes de la manière
suivante :
• Solution de sauvegarde complète : Oracle Secure Backup protège aussi bien les
données de la base que les données externes. Il s'applique à l'intégralité de
l'environnement Oracle.
• Gestion des supports : Oracle Secure Backup fournit la couche de gestion des médias
(Media Management Layer) pour les sauvegardes de base de données RMAN sur bande.
Avant Oracle Secure Backup, les clients devaient acheter des produits de gestion des
supports tiers coûteux offrant l'intégration aux sauvegardes sur bande RMAN.
• Sauvegarde n'importe où sur le réseau : Oracle Secure Backup sauvegarde les
données de plusieurs systèmes informatiques en réseau sur des ressources de stockage
tertiaire appartenant au réseau. Il prend en charge diverses configurations de serveurs,
de clients, de serveurs NAS (Network Attached Storage) et d'unités de stockage
tertiaires, et protège les environnements de stockage en réseau.
La combinaison de RMAN et d'Oracle Secure Backup fournit une solution de sauvegarde de
bout en bout, entièrement intégrée à la pile de produits Oracle. Le support technique est ainsi
plus efficace car Oracle Corporation est en charge de l'intégralité de la solution de
sauvegarde.
Sauvegarde gérée par l'utilisateur
Un scénario géré par l'utilisateur :

• est un processus manuel de suivi
des sauvegardes nécessaires et du statut
des sauvegardes
• requiert l'écriture de scripts par le DBA
• nécessite de placer les fichiers de base
de données dans le mode approprié
pour la sauvegarde
• repose sur des commandes du système
d'exploitation pour la réalisation
de sauvegardes des fichiers
Sauvegarde gérée par l'utilisateur

La réalisation d'une sauvegarde gérée par l'utilisateur nécessite l'écriture de scripts. Plusieurs
scénarios peuvent être exécutés et des scripts doivent être écrits pour les gérer. Voici certaines
des opérations qui doivent être effectuées par les scripts :
• Interrogation de v$datafile pour déterminer les fichiers de données qui doivent être
sauvegardés, ainsi que leur statut en cours.
• Interrogation de v$logfile pour identifier les fichiers de journalisation en ligne.
• Interrogation de v$controlfile pour identifier le fichier de contrôle à sauvegarder.
• Activation du mode de sauvegarde base ouverte pour chaque tablespace.
• Interrogation de v$backup pour voir quels fichiers font partie d'un tablespace qui a été
placé en mode de sauvegarde base ouverte.
• Exécution de commandes du système d'exploitation pour copier les fichiers de données
vers l'emplacement de sauvegarde.
• Désactivation du mode de sauvegarde base ouverte pour chaque tablespace.
Terminologie
• La stratégie de sauvegarde peut inclure :

– la base de données entière (sauvegarde totale)
– une partie de la base de données (sauvegarde partielle)
• Le type de sauvegarde peut indiquer l'inclusion de :
– toutes les informations de tous les fichiers de données
(sauvegarde complète)
– seules les informations modifiées depuis une
précédente sauvegarde (sauvegarde incrémentielle)
• Le mode de sauvegarde peut être :
– base fermée (sauvegarde cohérente, à froid)
– base ouverte (sauvegarde incohérente, à chaud)
Terminologie
Une sauvegarde totale de la base inclut tous les fichiers de données et au moins un fichier de
contrôle. (Rappelez-vous que tous les fichiers de contrôle d'une base de données sont identiques.)
Les sauvegardes partielles de la bas peuvent inclure un nombre quelconque de tablespaces, un
nombre quelconque de fichiers de données et inclure ou non un fichier de contrôle.
Les sauvegardes complètes créent une copie de chaque bloc qui contient des données et figure
dans les fichiers sauvegardés.
Les sauvegardes incrémentielles créent une copie de tous les blocs de données ayant changé
depuis une précédente sauvegarde. Oracle Database 10g prend en charge deux niveaux de
sauvegarde incrémentielle (0 et 1). Une sauvegarde de niveau 0 ou sauvegarde de ligne de base
(baseline) est équivalente à une sauvegarde complète et contient tous les blocs de données. Une
sauvegarde de niveau 1 ou sauvegarde incrémentielle inclut tous les blocs de base de données
ayant changé depuis la dernière sauvegarde de niveau 0. Pour procéder à une restauration à partir
de sauvegardes incrémentielles, vous devez commencer par restaurer la sauvegarde de ligne de
base, puis la sauvegarde incrémentielle.
Les sauvegardes base fermée (également appelées sauvegardes cohérentes) sont effectuées
alors que la base de données n'est pas ouverte. Elles sont cohérentes car, au moment de la
sauvegarde, les SCN (System Change Number) figurant dans les en-têtes des fichiers de données
correspondent aux SCN figurant dans les fichiers de contrôle.
Les sauvegardes base ouverte (également appelées sauvegardes incohérentes ou à chaud) sont
effectuées alors que la base de données est ouverte. Elles sont incohérentes car, lorsque la base
est ouverte, il n'est pas certain que les fichiers de données soient synchronisés avec les fichiers de
contrôle. L'utilisation des sauvegardes incohérentes nécessite une récupération.
Terminologie
Les sauvegardes peuvent être stockées sous forme de :

• copies d'image
• jeux de sauvegarde
Fichier de données 1 Fichier de Fichier de
données 1 données 2
Fichier de données 2
Fichier de Fichier de
Fichier de données 3 données 3 données 4
Fichier de données 4 Fichier de Fichier de
données 5 données 6
Fichier de données 5
Fichier de données 6 Jeu de sauvegarde
Copies d'image
Terminologie (suite)
Les copies d'image sont des doubles des fichiers de données ou des fichiers de journalisation
archivés (semblables à la simple copie des fichiers à l'aide des commandes du système
d'exploitation).
Les jeux de sauvegarde sont des copies d'un ou plusieurs fichiers de données ou fichiers de
journalisation archivés. Avec les jeux de sauvegarde, les blocs de données vides ne sont pas
stockés, ce qui fait que les jeux de sauvegarde occupent moins d'espace sur le disque ou sur bande.
Les jeux de sauvegarde peuvent être compressés afin de réduire encore davantage les besoins de la
sauvegarde en termes d'espace.
Les copies d'image doivent être sauvegardées sur le disque. Les jeux de sauvegarde peuvent être
envoyés sur le disque ou directement sur la bande.
L'avantage de la création d'une sauvegarde en tant que copie d'image est l'amélioration de la
granularité de l'opération de restauration. Avec une copie d'image, seuls le ou les fichiers doivent
être extraits de la bande. Avec les jeux de sauvegarde, l'ensemble du jeu de sauvegarde doit être
extrait de la bande pour permettre l'extraction du ou des fichiers nécessaires.
L'avantage de la création de sauvegardes sous forme de jeux de sauvegarde réside dans une
utilisation plus efficace de l'espace. La plupart des bases de données contiennent 20 % ou plus de
blocs vides. Les copies d'image sauvegardent chaque bloc de données, même s'il est vide. Les jeux
de sauvegarde limitent considérablement l'espace requis par la sauvegarde. Dans la plupart des
systèmes, les avantages des jeux de sauvegarde sont supérieurs à ceux des copies d'image.
Une sauvegarde d'une base de données exécutée en mode NOARCHIVELOG doit avoir les trois
attributs suivants : Offline Backup, Full Backup et Whole Database. Les bases de données en mode
ARCHIVELOG
Unauthorized peuvent
reproduction utiliser toutes
or distribution les optionsCopyright©
prohibitedฺ de sauvegarde.
2009, Oracle and/or its affiliatesฺ
Recovery Manager (RMAN)
• Enterprise Manager utilise RMAN (Recovery Manager)
pour effectuer les opérations de sauvegarde et
de récupération.
• RMAN :
– est un client en mode ligne de commande pour
les fonctions avancées
– présente un langage puissant de contrôle et
de génération de script
– comporte une API publiée permettant l'interface avec la
plupart des logiciels de sauvegarde les plus populaires
– sauvegarde les fichiers de données, les fichiers de
contrôle, les fichiers de journalisation archivés et
les fichiers de paramètres serveur (SPFILE)
– sauvegarde les fichiers sur disque ou sur bande
Recovery Manager (RMAN)

RMAN est le composant d'Oracle Database 10g utilisé pour effectuer les opérations de
sauvegarde et de récupération. Il peut effectuer des sauvegardes cohérentes ou incohérentes,
exécuter des sauvegardes incrémentielles ou complètes, et sauvegarder la base de données
entière ou seulement une partie.
RMAN utilise son propre langage puissant de contrôle des travaux et de génération de script,
ainsi qu'une API publiée permettant l'interaction entre RMAN et de nombreux logiciels de
sauvegarde populaires.
RMAN permet de stocker les sauvegardes sur disque, en vue d'une récupération rapide, ou sur
bande, pour un stockage à long terme. Pour que RMAN puisse stocker les sauvegardes sur
bande, il est nécessaire de configurer une interface avec le périphérique de bande, appelée
Media Management Library (MML).
Enterprise Manager fournit une interface graphique vers les fonctionnalités les plus
couramment utilisées de RMAN. Les opérations avancées de sauvegarde et de récupération
sont accessibles par l'intermédiaire du client RMAN en mode ligne de commande. Pour plus
d'informations sur les fonctionnalités RMAN avancées, reportez-vous au cours Oracle
Database 10g : Administration Workshop II ou au manuel Oracle Backup and Recovery
Advanced User’s Guide.
Configurer les paramètres de sauvegarde

Accédez à la page Maintenance et cliquez sur Configure Backup Settings. Dans cette page de
propriétés, vous pouvez gérer les paramètres persistants qui sont utilisés pour la création des
sauvegardes. Il existe des paramètres distincts pour les sauvegardes sur disque et pour les
sauvegardes sur bande. Les paramètres relatifs aux sauvegardes sur bande dépendent des
possibilités de Media Management Library (MML). Les paramètres de sauvegarde sur disque sont
les suivants :
• Parallelism : Nombre de flux distincts d'informations de sauvegarde que vous souhaitez
créer. La valeur appropriée dépend du matériel que vous utilisez. Une CPU unique, un
contrôleur de disque unique ou un serveur de disques unique ne peuvent pas tirer parti des
sauvegardes en parallèle. A mesure que les ressources matérielles augmentent, le degré de
parallélisme approprié augmente également.
• Disk Backup Location : Emplacement où les sauvegardes doivent être stockées.
L'emplacement par défaut est la zone de récupération rapide. Si vous souhaitez modifier ce
paramètre, cliquez sur "Test Disk Backup" afin de vérifier que RMAN peut écrire dans le
nouvel emplacement.
• Disk Backup Type : Sélectionnez Image Copy (copie d'image), Backup Set (jeu de
sauvegarde) ou Compressed Backup Set (jeu de sauvegarde compressé).
Sélectionnez l'onglet Backup Set afin de définir la taille maximale des fichiers du jeu de
sauvegarde. (Les jeux de sauvegarde peuvent être divisés si nécessaire pour faciliter l'archivage.)
Les informations d'identification et de connexion auprès de l'hôte sont nécessaires pour permettre à
Enterprise Manager d'enregistrer les modifications apportées aux paramètres de sauvegarde.
Configurer les paramètres de sauvegarde (suite)

Cliquez sur l'onglet Policy pour effectuer les opérations suivantes :
• Sauvegarder automatiquement le fichier de contrôle et le fichier de paramètres serveur
(SPFILE) avec chaque sauvegarde. Vous pouvez également indiquer un emplacement pour
les sauvegardes si vous ne souhaitez pas qu'elles soient placées dans la zone de récupération
rapide.
• Optimiser les sauvegardes en ne sauvegardant pas les fichiers qui sont parfaitement
identiques à un fichier déjà inclus dans les sauvegardes. Ce paramètre vous permet d'ignorer
les fichiers de données en lecture seule et les fichiers hors ligne (offline).
• Activer le suivi des modifications des blocs et indiquer un emplacement pour le fichier de
suivi. Si vous prévoyez de créer des sauvegardes incrémentielles, ce paramètre permet de
réduire le temps nécessaire pour choisir les blocs à inclure dans la sauvegarde
incrémentielle.
• Exclure des tablespaces d'une sauvegarde totale de la base de données. Certains
administrateurs choisissent de ne pas sauvegarder les tablespaces contenant des données ou
des objets pouvant être facilement recréés (tels que des index ou des données faisant l'objet
de fréquents chargements en mode batch).
• Indiquer une stratégie de conservation : durée pendant laquelle RMAN doit conserver les
sauvegardes. Si vous utilisez la zone de récupération rapide pour le stockage des
sauvegardes, RMAN supprime automatiquement les anciennes sauvegardes afin de libérer
de la place pour les nouvelles (si la stratégie de conservation le permet). Par défaut, seule la
dernière sauvegarde est conservée. La stratégie de conservation peut être définie sous la
Unauthorizedforme d'un nombre
reproduction de sauvegardes
or distribution ou d'un Copyright©
prohibitedฺ nombre de jours.
2009, Oracle and/or its affiliatesฺ
Planifier des sauvegardes : Stratégie
Sélectionnez une sauvegarde totale ou partielle.
Planifier des sauvegardes : Stratégie

Cliquez sur Schedule Backup dans la région Backup/Recovery de la page de propriétés
Maintenance. Sélectionnez la stratégie de sauvegarde suggérée par Oracle ou votre propre
stratégie personnalisée. La stratégie recommandée par Oracle consiste à créer une sauvegarde
unique totale, effectuée base ouverte. Il s'agit d'une sauvegarde de ligne de base (baseline)
incrémentielle de niveau 0. La stratégie de sauvegarde automatisée consiste ensuite à planifier
des sauvegardes incrémentielles de niveau 1 pour chaque jour suivant.
En sélectionnant l'option Customized, vous accédez à un plus large éventail d'options de
configuration. Sélectionnez les objets que vous souhaitez sauvegarder : la base de données
entière (par défaut), ou bien des tablespaces, des fichiers de données ou des fichiers de
journalisation archivés individuels, ou encore des sauvegardes Oracle résidant actuellement
sur disque (afin de les déplacer sur bande).
Planifier des sauvegardes : Options
Planifier des sauvegardes : Options

Sélectionnez Full Backup ou Incremental Backup pour Backup Type. Si vous procédez à une
sauvegarde complète de la base de données, vous pouvez sélectionner l'option "Use as the
base of an incremental backup strategy" afin d'en faire une sauvegarde incrémentielle de
niveau 0. Si vous utilisez des copies d'image, vous pouvez cocher la case "Refresh the latest
datafile copy on disk to the current time using the incremental backup" pour mettre à jour la
sauvegarde existante plutôt que de créer une nouvelle copie d'image.
Cliquez sur "Delete obsolete backups" afin de supprimer les sauvegardes qui n'entrent pas
dans le cadre de la stratégie de conservation définie précédemment. RMAN supprime
automatiquement les sauvegardes obsolètes si vous procédez à la sauvegarde dans la zone de
récupération rapide.
Planifier des sauvegardes : Paramètres
Planifier des sauvegardes : Paramètres

Indiquez si la sauvegarde doit être stockée sur disque ou sur bande.
Planifier des sauvegardes : Planification
Planifier des sauvegardes : Planification

Déterminez la façon dont la sauvegarde doit être planifiée : en tant que travail unique ou en
tant que processus automatisé et récurrent.
Pour configurer une base de données pour une possibilité de récupération maximale, Oracle
suggère la planification de sauvegardes régulières. L'automatisation des sauvegardes permet
de simplifier la tâche de l'administrateur.
Planifier des sauvegardes : Récapitulatif
Cliquez sur Edit RMAN Script afin de revoir

les commandes RMAN.
Planifier des sauvegardes : Récapitulatif

RMAN utilise son propre langage de commande et de génération de script. Cliquez sur le
bouton Edit RMAN Script pour voir les commandes générées par le planificateur de
sauvegarde à partir des informations que vous avez indiquées.
A l'aide de cette page, vous pouvez si nécessaire personnaliser les scripts RMAN ou les copier
à des fins d'enregistrement.
Sauvegarder le fichier de contrôle
dans un fichier trace
Les fichiers de contrôle offrent une option
de sauvegarde supplémentaire.
Des sauvegardes des fichiers de contrôle dans un fichier

trace peuvent être utilisées à des fins de récupération
en cas de perte de tous les fichiers de contrôle.
Sauvegarder le fichier de contrôle dans un fichier trace

Cliquez sur Control Files dans la région Storage de la page de propriétés Administration afin
de gérer les fichiers de contrôle de la base de données. Les fichiers de contrôle disposent
d'une option de sauvegarde supplémentaire : ils peuvent être sauvegardés dans un fichier
trace. Une telle sauvegarde contient l'instruction SQL nécessaire pour recréer les fichiers de
contrôle en cas de perte de tous les fichiers de contrôle.
Bien que ce scénario soit très peu probable dans une base de données correctement configurée
(avec plusieurs copies du fichier de contrôle placées sur des disques et des contrôleurs
distincts), il reste néanmoins possible. L'administrateur doit donc sauvegarder le fichier de
contrôle dans un fichier trace après chaque modification de la structure physique de la base
(ajout de tablespaces ou de fichiers de données, ajout de groupes de fichiers de journalisation
supplémentaires).
Pour créer des copies du fichier de contrôle dans un fichier trace via Enterprise Manager
(comme illustré dans la diapositive ci-dessus), cliquez sur Control Files dans la page de
propriétés Administration ou utilisez la commande SQL suivante :
SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
La sauvegarde dans un fichier trace est créée dans l'emplacement désigné par le paramètre
d'initialisation USER_DUMP_DEST, avec un nom de fichier tel que sid_ora_pid.trc.
Sauvegarder le fichier de contrôle dans un fichier trace (suite)
Le fichier trace contient des informations sur les destinations des fichiers de journalisation
archivés, suivies des commandes permettant de créer les fichiers de contrôle de remplacement, puis
de récupérer la base de données :
CREATE CONTROLFILE REUSE DATABASE ORCL NORESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 226
LOGFILE
GROUP 1 '/oracle/oradata/orcl/redo01.log' SIZE 10M,
GROUP 2 '/oracle/oradata/orcl/redo02.log' SIZE 10M,
GROUP 3 '/oracle/oradata/orcl/redo03.log' SIZE 10M
DATAFILE
'/oracle/oradata/orcl/system01.dbf',
'/oracle/oradata/orcl/undotbs01.dbf',
'/oracle/oradata/orcl/sysaux01.dbf',
'/oracle/oradata/orcl/users01.dbf',
'/oracle/oradata/orcl/example01.dbf'
CHARACTER SET WE8ISO8859P1;
-- Commands to re-create incarnation table
-- Below log names MUST be changed to existing filenames on
-- disk. Any one log file from each branch can be used to
-- re-create incarnation records.
-- ALTER DATABASE REGISTER LOGFILE
'/oracle/flash_recovery_area/ORCL/archivelog/2003_12_05/
o1_mf_1_1_%u_.arc';
-- ALTER DATABASE REGISTER LOGFILE
'/oracle/flash_recovery_area/ORCL/archivelog/2003_12_05/
o1_mf_1_1_%u_.arc';
-- Recovery is required if any of the data files are restored
backups,
-- or if the last shutdown was not normal or immediate.
RECOVER DATABASE
-- All logs need archiving and a log switch is needed.
ALTER SYSTEM ARCHIVE LOG ALL;
-- Database can now be opened normally.
ALTER DATABASE OPEN;
-- Commands to add tempfiles to temporary tablespaces.
-- Online tempfiles have complete space information.
-- Other tempfiles may require adjustment.
ALTER TABLESPACE TEMP ADD TEMPFILE
'/oracle/oradata/orcl/temp01.dbf'
SIZE 20971520 REUSE AUTOEXTEND ON NEXT 655360
MAXSIZE 32767M;
Gérer les sauvegardes
Gérer les sauvegardes

Cliquez sur Manage Current Backups dans la page de propriétés Maintenance afin de gérer les
sauvegardes existantes. Cette page indique le moment et l'emplacement de stockage de la
sauvegarde et précise si la sauvegarde est toujours disponible.
En haut de la page Manage Current Backups, vous pouvez voir quatre boutons qui vous
permettent d'utiliser les sauvegardes existantes :
• Catalog Additional Files : Bien que RMAN (utilisé via Enterprise Manager) constitue
la méthode recommandée pour créer des sauvegardes, il est possible de créer des copies
d'image ou des jeux de sauvegarde par d'autres moyens ou dans un autre environnement,
de sorte que RMAN n'en a pas connaissance. Cette tâche identifie de tels fichiers et les
ajoute au catalogue.
• Crosscheck All : RMAN peut supprimer automatiquement les sauvegardes obsolètes,
mais vous pouvez également les supprimer à l'aide de commandes du système
d'exploitation. Si vous supprimez une sauvegarde sans passer par RMAN, le catalogue
ne sait pas qu'elle est manquante, tant que vous n'avez pas procédé à une vérification
croisée entre le catalogue et le contenu réel.
• Delete All Obsolete : Cette option permet de supprimer les sauvegardes qui sont
obsolètes en vertu de la stratégie de conservation.
• Delete All Expired : Cette option permet de supprimer du catalogue les sauvegardes qui
n'ont pas été trouvées lors de la vérification croisée.
Zone de récupération rapide
Surveillez la zone de récupération rapide pour :

• configurer la journalisation flashback
• dimensionner la zone de récupération
• surveiller la consommation actuelle d'espace
Zone de récupération rapide

La zone de récupération rapide est un espace réservé sur le disque pour le stockage des
fichiers de journalisation archivés, des sauvegardes et des journaux flashback.
Si vous avez configuré les fichiers de journalisation archivés afin qu'ils soient écrits dans cet
emplacement (par l'intermédiaire de l'indicateur USE_DB_RECOVERY_AREA dans l'un des
emplacements), il est important de surveiller cet espace afin de s'assurer que sa capacité
maximale ne soit pas atteinte. Si l'instance ne parvient pas à créer un fichier de journalisation
archivé en raison d'un manque d'espace, elle s'interrompt jusqu'à ce que l'administrateur
corrige la situation.
Cliquez sur Recovery Settings dans la page de propriétés Maintenance afin d'accéder aux
paramètres de la zone de récupération rapide. Dans cette page, vous pouvez effectuer les
opérations suivantes :
• Indiquer l'emplacement de la zone de récupération rapide.
• Indiquer la taille de la zone de récupération rapide (Oracle recommande qu'elle soit au
moins égale à deux fois la taille de la base de données, afin que cette zone puisse
contenir une sauvegarde et plusieurs fichiers de journalisation archivés).
• Vérifier la proportion de la zone de récupération rapide déjà consommée.
• Configurer Flashback Database. Flashback Database est étudié dans le chapitre intitulé
"Procéder à un flashback de la base de données".
Synthèse

• créer des sauvegardes cohérentes de la base
de données
• sauvegarder la base de données sans l'arrêter
• créer des sauvegardes incrémentielles
• automatiser les sauvegardes de la base
de données
• surveiller la zone de récupération rapide
Créer des sauvegardes de la base de données

• configurer la base de données pour les
sauvegardes
• sauvegarder la base de données pendant
qu'elle est ouverte pour les utilisateurs
• planifier des sauvegardes incrémentielles
automatiques de la base de données pendant
la nuit
Procéder à une récupération
Objectifs
A la fin de ce chapitre, vous pourrez récupérer

une base de données suite à la perte d'un :
• fichier de contrôle
• fichier de journalisation
• fichier de données
Ouvrir une base de données
Pour qu'une base de données puisse être ouverte :

• Tous les fichiers de contrôle doivent être présents
et synchronisés.
• Tous les fichiers de données en ligne doivent être
présents et synchronisés.
• Au moins un membre de chaque groupe de
fichiers de journalisation doit être présent.
OPEN
STARTUP
MOUNT
NOMOUNT
SHUTDOWN
Ouvrir une base de données

Lorsqu'une base de données passe de l'état arrêté à l'état totalement ouvert, elle procède à des
vérifications de cohérence interne. Les phases sont les suivantes :
• NOMOUNT : Pour qu'une instance passe au statut NOMOUNT (également appelé
STARTED), elle doit lire le fichier de paramètres d'initialisation. Aucun fichier de base
de données n'est vérifié pendant que l'instance passe à l'état NOMOUNT.
• MOUNT : Lorsque l'instance passe au statut MOUNT, elle vérifie si tous les fichiers de
contrôle répertoriés dans le fichier de paramètres d'initialisation sont présents et
synchronisés. Dès lors que l'un des fichiers de contrôle est manquant ou corrompu,
l'instance renvoie une erreur (indiquant le fichier manquant) à l'administrateur et elle
reste à l'état NOMOUNT.
• OPEN : Lorsque l'instance passe de l'état MOUNT à l'état OPEN :
- Elle vérifie si au moins un membre est présent dans tous les groupes de fichiers de
journalisation (redo logs) connus du fichier de contrôle. Les éventuels membres
manquants sont indiqués dans le fichier d'alertes.
Ouvrir une base de données (suite)
- L'instance vérifie que tous les fichiers de données connus du fichier de contrôle sont
présents, sauf s'ils ont été mis hors ligne. Les fichiers hors ligne ne sont pas vérifiés
tant que l'administrateur n'a pas tenté de les mettre en ligne. L'administrateur peut
mettre un fichier de données hors ligne et ouvrir l'instance dès lors que le fichier de
données n'appartient pas au tablespace SYSTEM ou UNDO. Si des fichiers sont
manquants, une erreur indiquant le premier fichier manquant est renvoyée à
l'administrateur et l'instance reste à l'état MOUNT. Lorsque l'instance trouve des
fichiers manquants, seul le premier fichier provoquant un problème apparaît dans le
message d'erreur. Pour trouver tous les fichiers nécessitant une récupération,
l'administrateur peut examiner la vue dynamique des performances
v$recover_file afin d'obtenir la liste complète des fichiers nécessitant une
attention :
SQL> startup
ORACLE instance started.
Total System Global Area 171966464 bytes
Fixed Size 775608 bytes
Variable Size 145762888 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 4 - see DBWR trace
file
ORA-01110: data file 4: '/oracle/oradata/orcl/users01.dbf'
SQL> SELECT name, error
2 FROM v$datafile
3 JOIN v$recover_file
4 USING (file#);
NAME ERROR
----------------------------------- ------------------
/oracle/oradata/orcl/users01.dbf FILE NOT FOUND
/oracle/oradata/orcl/example01.dbf FILE NOT FOUND
- L'instance vérifie que tous les fichiers de données qui ne sont pas hors ligne ou en
lecture seule sont synchronisés avec le fichier de contrôle. Si nécessaire, une
récupération d'instance est automatiquement effectuée. Si un fichier est
désynchronisé à un point tel qu'il ne peut pas être récupéré à l'aide des groupes de
fichiers de journalisation en ligne, l'administrateur doit procéder à une restauration
physique. Si des fichiers nécessitent une restauration physique, un message d'erreur
indiquant le premier fichier nécessitant la restauration est renvoyé à l'administrateur
et l'instance reste à l'état MOUNT :
ORA-01113: file 4 needs media recovery
ORA-01110: data file 4: '/oracle/oradata/orcl/users01.dbf'
Là encore, la vue v$recover_file indique la liste complète des fichiers
nécessitant une attention. Les fichiers qui sont présents et qui nécessitent une
restauration physique sont également répertoriés, mais aucun message d'erreur
n'apparaît.
Modifier le statut d'une instance
Utilisez Database Control pour modifier le statut

de l'instance.
Modifier le statut d'une instance

Au démarrage de l'instance, le mode de démarrage par défaut est OPEN. Vous pouvez
cependant démarrer l'instance dans un autre mode, par choix ou suite à des problèmes
concernant la base de données. La page de propriétés Advanced Startup Options vous permet
de sélectionner un état autre que OPEN lors du démarrage de l'instance, et de modifier l'état si
l'instance a déjà démarré dans un autre mode. Vous pouvez également utiliser des commandes
SQL pour modifier le statut d'une instance :
SQL> STARTUP NOMOUNT
ORACLE instance started.
Total System Global Area 188743680 bytes

Fixed Size 778036 bytes
Variable Size 162537676 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes
SQL> ALTER DATABASE MOUNT
Database altered.
SQL> ALTER DATABASE OPEN
Maintenir une base de données ouverte
Une instance ouverte échoue en cas de perte :

• d'un fichier de contrôle
• d'un fichier de données appartenant au tablespace
système ou au tablespace d'annulation
• d'un groupe de fichiers de journalisation entier
(tant qu'au moins un membre du groupe est
présent, l'instance reste ouverte)
Maintenir une base de données ouverte

Une instance ouverte échoue lorsqu'une défaillance physique entraîne la perte d'un fichier de
contrôle, d'un groupe de fichiers de journalisation entier ou d'un fichier de données
appartenant au tablespace SYSTEM ou UNDO.
Dans de nombreux cas, l'instance ayant échoué ne s'arrête pas complètement, mais aucune
opération n'est plus possible. La récupération suite à ce type de défaillance physique doit être
effectuée base fermée. L'administrateur doit donc exécuter la commande SHUTDOWN ABORT
afin de procéder à la récupération.
La perte de fichiers de données appartenant à d'autres tablespaces n'entraîne pas l'échec de
l'instance. La base de données peut alors être récupérée tout en restant ouverte, les opérations
se poursuivant sur les autres tablespaces.
Ces erreurs peuvent être détectées en inspectant le fichier d'alertes.
Perte d'un fichier de contrôle
Si un fichier de contrôle est perdu ou endommagé,

il se produit une opération d'abandon normal de
l'instance. Vous devez alors procéder comme suit :
1. Arrêtez l'instance si elle est encore ouverte.
2. Restaurez le fichier de contrôle manquant
en copiant un fichier de contrôle existant.
3. Démarrez l'instance.
Perte d'un fichier de contrôle

La récupération suite à la perte d'un fichier de contrôle (dès lors qu'il en reste au moins un)
peut être effectuée de la façon suivante :
1. Si l'instance n'a pas encore échoué, arrêtez-la à l'aide de la commande SHUTDOWN
ABORT.
2. Copiez l'un des fichiers de contrôle restants dans l'emplacement du fichier manquant. Si
la défaillance physique est due à la perte d'un disque ou d'un contrôleur, copiez l'un des
fichiers de contrôle restants vers un autre emplacement et mettez à jour le fichier de
paramètres de l'instance afin qu'il pointe vers le nouvel emplacement. Vous pouvez
également supprimer du fichier de paramètres d'initialisation la référence au fichier de
contrôle manquant. Rappelez-vous qu'Oracle recommande de disposer en permanence
d'au moins deux fichiers de contrôle.
3. Démarrez l'instance.
La récupération suite à la perte de tous les fichiers de contrôle est traitée dans le cours Oracle
Database 10g : Administration Workshop II.
Perte d'un fichier de journalisation
Si un membre d'un groupe de fichiers de journalisation

est perdu et que le groupe comporte encore au moins
un membre :
1. Le fonctionnement normal de l'instance n'est pas
affecté.
2. Un message indiquant qu'un membre est introuvable
est écrit dans le fichier d'alertes.
3. Vous pouvez restaurer le fichier manquant
en copiant l'un des fichiers restants du même groupe.
Perte d'un fichier de journalisation

La récupération suite à la perte d'un membre unique d'un groupe de fichiers de journalisation ne
doit pas affecter l'instance en cours. Pour effectuer cette récupération, procédez comme suit :
1. Déterminez si un fichier de journalisation est manquant en examinant le fichier d'alertes.
2. Restaurez le fichier manquant en copiant l'un des fichiers restants du même groupe.
3. Si la défaillance physique est due à la perte d'un disque ou d'un contrôleur, renommez le
fichier manquant.
4. Si le groupe a déjà été archivé, ou si la base de données est en mode NOARCHIVELOG,
vous pouvez choisir de résoudre le problème en vidant le groupe afin de recréer le ou les
fichiers manquants. Sélectionnez le groupe approprié et sélectionnez l'action Clear Logfile.
Vous pouvez également vider manuellement le groupe affecté par l'intermédiaire de la
commande suivante :
SQL> ALTER DATABASE CLEAR LOGFILE GROUP #;
Remarque : Database Control ne vous permet pas de vider un groupe de fichiers de
journalisation qui n'a pas été archivé. En effet, il en résulterait une rupture de la chaîne des
informations de journalisation. Si vous devez vider un groupe de fichiers de journalisation non
archivé, procédez immédiatement à une sauvegarde complète de l'ensemble de la base de
données. A défaut, vous vous exposez à une perte de données si une autre défaillance se produit.
Pour vider un groupe de fichiers de journalisation non archivé, utilisez la commande suivante :
SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP #;
Perte d'un fichier de données en mode
NOARCHIVELOG
Si la base de données est en mode NOARCHIVELOG
et qu'un fichier de données est perdu, procédez
de la manière suivante :
1. Arrêtez l'instance si elle n'est pas déjà arrêtée.
2. Restaurez l'ensemble de la base de données à partir
de la sauvegarde, y compris tous les fichiers de données
et fichiers de contrôle.
3. Ouvrez la base de données.
4. Demandez aux utilisateurs d'entrer de nouveau toutes
les modifications apportées depuis la dernière sauvegarde.
Utilisateur Utilisateur Utilisateur Utilisateur Utilisateur
Perte d'un fichier de données en mode NOARCHIVELOG

La perte d'un fichier de données d'une base de données en mode NOARCHIVELOG nécessite
la restauration complète de la base, y compris les fichiers de contrôle et tous les fichiers de
données.
Lorsque la base de données est en mode NOARCHIVELOG, la récupération n'est possible que
jusqu'à l'instant de la dernière sauvegarde. Par conséquent, les utilisateurs doivent de nouveau
entrer toutes les modifications qui ont été apportées depuis cette sauvegarde. Pour ce type de
récupération, procédez comme suit :
1. Arrêtez l'instance si elle n'est pas déjà arrêtée.
2. Cliquez sur Perform Recovery dans la page de propriétés Maintenance.
3. Sélectionnez Whole Database comme type de récupération.
Perte d'un fichier de données non
essentiel en mode ARCHIVELOG
Si un fichier de données est perdu ou endommagé et que

ce fichier n'appartient pas au tablespace SYSTEM ou UNDO,
restaurez et récupérez le fichier de données manquant.
Utilisateurs
Perte d'un fichier de données non essentiel en mode ARCHIVELOG

La base de données étant en mode ARCHIVELOG, la perte d'un fichier de données n'appartenant
pas au tablespace SYSTEM ou UNDO affecte uniquement les objets du fichier manquant. Le reste
de la base de données reste disponible pour les utilisateurs. Pour restaurer et récupérer le fichier
de données manquant, procédez de la façon suivante :
2. Sélectionnez le type de récupération "Datafiles" et sélectionnez "Restore to current time".
3. Ajoutez tous les fichiers de données nécessitant une récupération.
4. Déterminez si vous souhaitez restaurer les fichiers dans l'emplacement par défaut ou
(si un disque ou un contrôleur est manquant) vers un nouvel emplacement.
5. Soumettez le travail RMAN afin de restaurer et de récupérer les fichiers manquants.
Etant donné que la base de données est en mode ARCHIVELOG, la récupération jusqu'à l'heure
de la dernière validation est possible et les utilisateurs n'ont pas besoin d'entrer de nouveau les
modifications.
Perte d'un fichier de données essentiel
pour le système en mode ARCHIVELOG
Si un fichier de données est perdu ou endommagé

et qu'il appartient au tablespace SYSTEM ou UNDO :
1. L'instance peut ou non s'arrêter automatiquement.
Si elle ne s'arrête pas, utilisez la commande
SHUTDOWN ABORT afin de l'arrêter.
2. Montez la base de données.
3. Restaurez et récupérez le fichier de données
manquant.
4. Ouvrez la base de données.
Utilisateurs
Perte d'un fichier de données essentiel pour le système

Les fichiers de données appartenant au tablespace SYSTEM ou contenant des données
d'annulation (undo) sont considérés comme essentiels pour le système. La perte de l'un de ces
fichiers nécessite la restauration de la base de données à partir de l'état MOUNT (contrairement
aux autres fichiers de données, qui peuvent être récupérés base ouverte). Pour effectuer cette
récupération, procédez comme suit :
1. Si l'instance n'est pas déjà arrêtée, arrêtez-la.
2. Montez la base de données.
4. Sélectionnez le type de récupération "Datafiles" et sélectionnez "Restore to current time".
5. Ajoutez tous les fichiers de données nécessitant une récupération.
6. Déterminez si vous souhaitez restaurer les fichiers dans l'emplacement par défaut ou
(si un disque ou un contrôleur est manquant) vers un nouvel emplacement.
7. Soumettez le travail RMAN afin de restaurer et de récupérer les fichiers manquants.
8. Ouvrez la base de données. Les utilisateurs n'ont pas besoin d'entrer de nouveau les
données, car la récupération a été effectuée jusqu'à l'heure de la dernière validation
(commit).
Synthèse
Dans ce chapitre, vous avez appris à procéder

à une récupération suite à la perte d'un :
• fichier de données
Procéder à une récupération
Cet exercice porte sur la récupération suite à la perte d'un :

• fichier de données non essentiel
• fichier de données essentiel pour le système
Procéder à un flashback
Objectifs

• décrire Flashback Database
• restaurer le contenu d'une table jusqu'à un point
spécifique dans le temps avec Flashback Table
• récupérer une table supprimée
• afficher le contenu de la base de données à partir
de n'importe quel point unique dans le temps
avec Flashback Query
• voir les différentes versions d'une ligne dans
le temps avec Flashback Versions Query
• afficher l'historique des transactions ou
une ligne avec Flashback Transaction Query
> Présentation
Avantages de la technologie Flashback Database
Table
Drop
Query
Versions
• La technologie Flashback constitue une avancée Transaction
révolutionnaire en matière de récupération.
• Les techniques de récupération traditionnelles
sont lentes.
– Il faut restaurer l'intégralité de la base de données
ou d'un fichier (la restauration ne se limite pas
aux données incorrectes).
– Chaque modification du journal de la base
de données doit être examinée.
• Le flashback est rapide.
– Les modifications sont indexées par ligne
et par transaction.
– Seules les données modifiées sont restaurées.
• Les commandes Flashback sont faciles à utiliser.
– Aucune procédure complexe à plusieurs étapes
n'est impliquée.
Avantages de la technologie Flashback

L'architecture Oracle Database 10g utilise les avancées technologiques uniques dans le
domaine de la récupération de base de données suite à la perte de données due à des erreurs
humaines. La technologie Flashback fournit un ensemble de nouvelles fonctionnalités
permettant d'afficher les données en arrière et en avant dans le temps, de les "rembobiner"
dans le temps.
Elle révolutionne la récupération en agissant simplement sur les données modifiées. La
correction d'une erreur ne prend pas plus de temps qu'il n'en a fallu pour la commettre.
Lorsqu'elle est applicable, la technologie Flashback fournit des avantages significatifs par
rapport à la restauration physique en termes de simplicité d'utilisation, de disponibilité et de
durée de restauration.
Dans quel cas utiliser
la technologie Flashback ?
Niveau objet Exemples de scénario Technologie Utilise Affecte

Flashback les données
Base de Vidage d'une table ; Database Journaux Oui
données modifications non souhaitées Flashback
sur plusieurs tables
Table Suppression d'une table Drop Corbeille Oui
Mise à jour avec une clause Table Données Oui

WHERE incorrecte d'annulation
Comparaison de données Query Données Non
actuelles avec des données d'annulation
du passé
Comparaison des versions Version Données Non
d'une ligne d'annulation
Transaction Examen de plusieurs états Transaction Données Non
historiques de données d'annulation
Dans quel cas utiliser la technologie Flashback ?

La technologie Flashback doit être utilisée lorsqu'une corruption logique se produit dans la base de
données Oracle, et que vous avez besoin de récupérer les données rapidement et facilement.
Comme avec les erreurs humaines, il est difficile d'identifier les objets et les lignes affectés par une
transaction erronée. Avec la technologie Flashback, vous pouvez déterminer de quelle façon les
erreurs ont été introduites dans la base de données, puis réparer les dommages. Vous pouvez
afficher les transactions qui ont contribué à des modifications de ligne spécifiques, afficher toutes
les versions d'une ligne spécifique sur une période donnée ou simplement afficher les données
telles qu'elles apparaissaient à un moment spécifique dans le passé. Le tableau de la diapositive ci-
dessus illustre les utilisations typiques de la technologie Flashback.
Flashback Database utilise les journaux Flashback pour procéder à un flashback de la base de
données. Flashback Drop utilise la corbeille. Toutes les autres fonctions Flashback utilisent les
données d'annulation (undo).
Les fonctionnalités Flashback ne modifient pas toutes la base de données. Certaines constituent
simplement des méthodes d'interrogation d'autres versions des données. Ces outils vous permettent
d'étudier un problème et vous aident à procéder à la récupération. Les résultats de ces interrogations
Flashback Query peuvent vous aider à effectuer les opérations suivantes :
• Déterminer le type d'opération Flashback à effectuer dans la base de données pour résoudre le
problème.
• Placer l'ensemble de résultats de ces interrogations dans une instruction INSERT, UPDATE
ou DELETE vous permettant de réparer facilement les données erronées.
Procéder à un flashback suite à une erreur
• Flashback Database rétablit la base de données

jusqu'à un point antérieur dans le temps en
annulant toutes les modifications apportées
à partir de ce point.
• Flashback Table récupère une table jusqu'à
un point dans le passé sans nécessiter
de restauration à partir d'une sauvegarde.
• Flashback Drop restaure les tables
accidentellement supprimées.
Procéder à un flashback suite à une erreur

Oracle Database 10g introduit des fonctionnalités avancées de flashback de base de données.
Si une erreur majeure se produit, apportant des modifications non isolées, comme deux
exécutions successives d'un traitement batch, vous pouvez demander une opération Flashback
qui récupère rapidement l'intégralité de la base de données jusqu'à un point antérieur dans le
temps. Il est ainsi inutile de restaurer des sauvegardes et de procéder à une récupération
jusqu'à un point dans le temps. Outre des opérations Flashback au niveau de la base de
données, il est également possible de procéder à un flashback d'une table unique ou de
récupérer une table supprimée par erreur.
Présentation
Flashback Database : Présentation > Database
Table
Drop
Query
Versions
L'opération Flashback Database : Transaction
• agit comme un bouton de rembobinage

pour la base de données
• peut être utilisée en cas de corruptions logiques
des données par des utilisateurs
Des utilisateurs La base de Vous "appuyez La base de

génèrent données est sur le bouton de données est
des erreurs. endommagée. rembobinage". "rembobinée".
Flashback Database : Présentation

Avec Flashback Database, vous pouvez rapidement rétablir la base de données jusqu'à un
point antérieur dans le temps en annulant toutes les modifications apportées depuis ce point.
Cette opération est rapide car vous n'avez pas besoin de restaurer de sauvegardes. Vous
pouvez utiliser cette fonctionnalité pour annuler des modifications ayant entraîné des
corruptions logiques des données.
En cas de perte ou de corruption physique de la base, vous devez utiliser les méthodes de
récupération traditionnelles.
Flashback Database :
Réduction de la durée de restauration
Récupération incomplète Restauration Base de données

Génération des fichiers réparée
de journaux
Application
Sauvegarde Erreur des journaux
utilisateur vers l'avant
Flashback Database Erreur Base de données

utilisateur réparée
Journaux
Flashback
Application des
Sauvegarde journaux Flashback
vers l'arrière
Flashback Database : Réduire la durée de restauration

L'opération Flashback Database est plus rapide que la récupération jusqu'à un point dans le
temps traditionnelle qui utilise des fichiers restaurés et des fichiers de journalisation (fichiers
redo log). Plus une base de données est volumineuse, plus la durée nécessaire pour restaurer
l'ensemble des fichiers de données afin de procéder à une récupération jusqu'à un point dans
le temps traditionnelle devient prohibitive. Avec Flashback Database, la durée nécessaire pour
récupérer une base de données est désormais proportionnelle au nombre de modifications à
opérer (et non à la taille de la base de données) car il n'est pas nécessaire de restaurer des
fichiers de données.
L'opération Flashback Database est implémentée à l'aide d'un type de fichier journal appelé
journal Flashback Database. La base de données Oracle consigne régulièrement des images
"avant" de blocs de données dans les journaux Flashback Database. Les images des blocs
peuvent être réutilisées pour rétablir rapidement les fichiers de données jusqu'au point dans le
temps correspondant au moment où les journaux Flashback Database ont été capturés, juste
avant le point de rétablissement visé. Les modifications issues des fichiers de journalisation
(fichiers redo log) sont ensuite appliquées pour combler les manques. Les journaux Flashback
Database sont automatiquement créés et gérés dans la zone de récupération rapide.
Flashback Database :
• Une fois l'opération Flashback Database terminée,

la base de données doit être ouverte à l'aide de
l'une des méthodes suivantes :
– en mode lecture seule pour vérifier que le point
cible ou le SCN correct a été utilisé
– avec le paramètre RESETLOGS pour autoriser
les mises à jour
• L'opposé d'une opération Flashback est
une récupération.
Flashback Database : Eléments à prendre en compte

Dans les cas où vous ne pouvez pas utiliser la fonctionnalité Flashback Database, vous devez
effectuer une opération de récupération incomplète pour rétablir la base de données jusqu'à un
point spécifique. Une fois l'opération Flashback Database terminée, vous pouvez ouvrir la
base de données en mode lecture seule pour vérifier que le point cible ou le numéro SCN
(System Change Number) correct a été utilisé. Si ce n'est pas le cas, vous pouvez procéder à
un nouveau flashback de la base de données ou effectuer une récupération pour
réimplémenter des modifications dans la base de données. Pour annuler une opération
Flashback Database, vous devez donc récupérer la base de données (recover).
Remarque : Le paramètre DB_FLASHBACK_RETENTION_TARGET n'est pas une garantie
absolue de la disponibilité des données Flashback. Si de l'espace est nécessaire dans la zone
de récupération rapide pour des fichiers requis, des journaux Flashback peuvent être
supprimés automatiquement.
Flashback Database : Limitations
Vous ne pouvez pas utiliser Flashback Database
dans les situations suivantes :
• Le fichier de contrôle a été restauré ou recréé.
• Un tablespace a été supprimé.
• De l'espace a été récupéré dans un fichier
de données.
Point cible Suppression Récupération Recréation Présent

du Flashback d'un d'espace dans du fichier
tablespace un fichier de contrôle
de données
Flashback Database : Limitations

Vous ne pouvez pas utiliser Flashback Database pour récupérer un fichier de données
supprimé entre le moment présent et le point cible du flashback. Le fichier de données
supprimé est ajouté au fichier de contrôle et marqué "offline", mais ne fait pas l'objet d'un
flashback. Flashback Database ne peut pas procéder à un flashback d'un fichier de données si
ce dernier a fait l'objet d'une récupération d'espace entre le moment présent et le point cible
du flashback. Tous les fichiers de données dans le même cas doivent être mis "offline" avant
l'opération Flashback.
Activer Flashback Database
Activer Flashback Database

La fonction Flashback Database peut être activée dans Enterprise Manager, via le lien
Recovery Settings de l'onglet Maintenance. Cochez la case de la région Flash Recovery de la
page et indiquez le délai de conservation des données Flashback, c'est-à-dire la période qui
définit jusqu'à quel point dans le passé vous souhaitez pouvoir procéder à un flashback de la
base de données.
Présentation
Database
Flashback Table : Présentation > Table
Drop
Query
Versions
Transaction
• Flashback Table récupère des tables jusqu'à

un point dans le temps spécifique.
• Flashback Table est une opération "in-place".
• La base de données reste ouverte.
Instructions LMD Tables ayant fait

erronées Utilisateur l'objet d'un flashback
Flashback Table : Présentation

Grâce à Flashback Table, vous pouvez récupérer un ensemble de tables jusqu'à un point dans
le temps spécifique sans avoir besoin de réaliser les opérations de récupération jusqu'à un
point dans le temps traditionnelles.
Une opération Flashback Table est réalisée "in-place", pendant que la base de données est
ouverte, en annulant (rollback) uniquement les modifications apportées aux tables indiquées
et à leurs objets dépendants.
Une instruction Flashback Table est exécutée en tant que transaction unique. Le flashback de
toutes les tables doit réussir, sinon l'intégralité de la transaction est annulée.
Remarque : Vous pouvez utiliser Flashback Versions Query et Flashback Transaction Query
pour déterminer l'heure de flashback appropriée.
Flashback Table
• Grâce à Flashback Table, vous pouvez récupérer

une ou plusieurs tables jusqu'à un point dans le
temps spécifique sans restaurer de sauvegarde.
• Des données nécessaires à une opération
Flashback Table sont extraites du tablespace
d'annulation.
• Le privilège FLASHBACK TABLE est requis
pour procéder au flashback d'une table.
• Le déplacement de lignes (row movement)
doit être activé pour la table sur laquelle
vous procédez au flashback.
Flashback Table
Avec Flashback Table, vous pouvez récupérer une ou plusieurs tables jusqu'à un point dans le
temps spécifique sans restaurer de sauvegarde. Lorsque vous utilisez cette fonctionnalité, les
données des tables et des objets associés (index, contraintes, déclencheurs (triggers), etc.) sont
restaurées. Les données utilisées pour satisfaire une demande Flashback Table sont extraites
du tablespace d'annulation.
Vous pouvez utiliser Flashback Versions Query et Flashback Transaction Query pour
déterminer l'heure de flashback appropriée. Pour plus d'informations sur l'utilisation de ces
fonctionnalités, reportez-vous au manuel Oracle Database Concepts.
Flashback Table permet aux utilisateurs de récupérer facilement et rapidement une table suite
à des modifications accidentelles sans l'intervention d'un administrateur de base de données
(DBA). Vous devez octroyer le privilège système FLASHBACK TABLE ou FLASHBACK ANY
TABLE à tout utilisateur qui emploie la fonctionnalité Flashback Table. Vous devez
également lui octroyer les privilèges objet SELECT, INSERT, DELETE et ALTER.
Vous pouvez utiliser Enterprise Manager pour procéder à un flashback d'une table. L'assistant
vous guide tout au long du processus.
Activer le déplacement de lignes
(row movement) dans une table
ALTER TABLE employees ENABLE ROW MOVEMENT;
Activer le déplacement de lignes (row movement) dans une table

Pour procéder au flashback d'une table, vous devez activer le déplacement de lignes dans cette
table. Lorsque vous activez le déplacement de lignes, le serveur Oracle peut déplacer une
ligne dans la table. Vous pouvez utiliser Enterprise Manager pour activer le déplacement de
lignes.
Pour effectuer cette opération sur une table, procédez comme suit :
1. Sélectionnez Tables dans la région Schema de la page de propriétés Administration.
Entrez le nom de schéma afin de rechercher la table, puis cliquez sur Go.
2. Cliquez sur le nom de la table pour laquelle vous souhaitez activer le déplacement de
lignes. Vous accédez alors à la page View Table.
3. Cliquez sur Edit pour accéder à la page Edit Table.
4. Sélectionnez l'onglet Options, dans lequel vous pouvez modifier le paramètre Enable
Row Movement correspondant à la table.
5. Attribuez la valeur Yes à Enable Row Movement, puis cliquez sur Apply.
Le message de confirmation de la mise à jour apparaît.
Procéder au flashback d'une table
FLASHBACK TABLE hr.employees TO TIMESTAMP

TO_TIMESTAMP('2005-05-05 05:32:00',
'YYYY-MM-DD HH24:MI:SS');
Procéder au flashback d'une table

Vous pouvez procéder au flashback d'une table via Enterprise Manager en procédant de la
manière suivante :
1. Sélectionnez Perform Recovery dans la région Backup/Recovery de la page de
propriétés Maintenance. La page Perform Recovery apparaît.
2. Dans la région Object Level Recovery, sélectionnez Tables dans la liste déroulante
Object Type.
3. Sélectionnez Flashback Existing Tables sous Operation Type. Cliquez sur Perform
Object Level Recovery. La page "Perform Object Level Recovery: Point-in-time"
apparaît.
4. Sélectionnez "Flashback to a timestamp" ou "Flashback to a known SCN", puis indiquez
la date et l'heure ou le SCN jusqu'auquel vous souhaitez procéder au flashback, et
cliquez sur Next.
5. Cliquez sur Add Tables pour ajouter des tables à la liste pour l'opération Flashback.
Cliquez sur Next.
6. En présence de tables dépendantes, la page Dependency Options apparaît. Sélectionnez
l'option souhaitée pour le traitement de ces tables. En général, il est conseillé de choisir
"Cascade" pour garantir un flashback cohérent. Cliquez sur Next.
Procéder au flashback d'une table (suite)
7. La page "Perform Object Level Recovery: Review" apparaît. Passez les informations
en revue et cliquez sur Submit. La page Confirmation apparaît.
Remarque : Vous pouvez également procéder au flashback de tables à partir du lien
Tables dans la région Schema de la page Administration.
Flashback Table :
• La commande FLASHBACK TABLE est exécutée
en tant que transaction unique, acquérant des
verrous LMD de type Exclusive.
• Les statistiques ne font pas partie d'un flashback.
• Les index actuels et les objets dépendants
sont conservés.
• Les opérations Flashback Table :
– ne peuvent pas être réalisées sur des tables
système
– ne peuvent pas concerner des opérations LDD
– sont écrites dans le fichier d'alertes
– génèrent des données d'annulation (undo)
et de journalisation (redo)
Flashback Table : Eléments à prendre en compte

• L'intégralité de l'instruction FLASHBACK TABLE est exécutée au sein d'une transaction
unique. Le flashback concerne l'ensemble ou aucune des tables indiquées.
• Flashback Table acquiert des verrous LMD (Langage de manipulation de données) de type
Exclusive sur toutes les tables indiquées dans l'instruction sur la période nécessaire à
l'opération.
• Les statistiques relatives aux objets concernés ne font pas partie du flashback.
• Tous les index existants sont conservés. Les index supprimés ne sont pas recréés. Les vues
matérialisées on-commit dépendantes sont également conservées automatiquement.
• Une instruction FLASHBACK TABLE est écrite dans le fichier d'alertes.
• Les tables indiquées dans l'instruction FLASHBACK TABLE font l'objet d'un flashback, à
condition qu'aucune des contraintes définies sur ces tables ne soit violée. Si l'une de ces
contraintes est violée pendant l'exécution du flashback, l'opération est abandonnée et les
tables sont laissées dans le même état qu'avant l'appel de l'instruction FLASHBACK
TABLE.
• Vous ne pouvez pas appliquer une opération Flashback Table jusqu'à un point dans le
temps antérieur au point d'exécution d'une opération LDD (Langage de définition de
données) qui a altéré la structure d'une table, ou qui a permis de récupérer de l'espace dans
une table impliquée dans l'opération Flashback. Cette restriction ne s'applique pas aux
instructions LDD qui modifient uniquement les attributs de stockage des tables.
• L'opération Flashback Table ne peut pas être réalisée sur des tables système, des tables
distantes et des vues V$.
Présentation
Database
Flashback Drop : Présentation Table
> Drop
Query
Versions
Transaction
Corbeille
DROP TABLE employees; FLASHBACK TABLE

employees
TO BEFORE DROP;
Une erreur a
été commise.
Flashback Drop : Présentation

Avec la fonctionnalité Flashback Drop, vous pouvez annuler les effets d'une instruction DROP
TABLE sans avoir recours à la récupération jusqu'à un point dans le temps traditionnelle. Ceci
est possible grâce à la corbeille, qui peut être interrogée via la vue DBA_RECYCLEBIN.
Procéder à un flashback
de tables supprimées
via Enterprise Manager
L'index bitmap dépendant fera

également l'objet du flashback.
Procéder à un flashback de tables supprimées via Enterprise Manager

Pour procéder à un flashback de tables avec la console Database Control, sélectionnez
Perform Recovery dans la région Backup/Recovery de la page Maintenance. Sélectionnez
Tables sous Object Type dans la région Type, puis sélectionnez Flashback Dropped Tables
dans la région Operation Type. Cliquez ensuite sur Perform Object Level Recovery.
La page "Perform Object Level Recovery: Dropped Objects Selection" apparaît ; vous pouvez
sélectionner des tables supprimées dans la corbeille. Vous pouvez également interroger le
contenu de tables supprimées en cliquant sur View Content. Sélectionnez les tables à
récupérer, puis cliquez sur Next.
La page "Perform Object Level Recovery: Rename" apparaît ; vous pouvez renommer la table
si une table portant le même nom existe dans le même schéma. Cliquez sur Next pour
continuer. Dans la page "Perform Object Level Recovery: Review", vous pouvez examiner les
détails de l'opération et afficher les instructions SQL correspondantes. Lorsque vous êtes prêt,
cliquez sur Submit. La page Confirmation apparaît. Cliquez sur OK pour revenir à la page
Maintenance.
Remarque : Vous pouvez également procéder à un flashback de tables supprimées à partir du
lien Tables dans la région Schema de la page Administration. Dans la page Tables, cliquez sur
le bouton Recycle Bin.
Flashback Drop :
• Flashback Drop ne fonctionne pas pour les tables qui :
– résident dans le tablespace SYSTEM
– utilisent des stratégies d'audit détaillé (FGA) ou VPD
(Virtual Private Database)
– résident dans un tablespace géré au moyen du
dictionnaire
– ont été purgées, manuellement, ou automatiquement en
cas de manque d'espace
• Les dépendances suivantes ne sont pas protégées :
– Index de jointure bitmap
– Journaux des vues matérialisées
– Contraintes d'intégrité référentielle
– Index supprimés avant les tables
Flashback Drop : Eléments à prendre en compte

Flashback Drop fonctionne uniquement pour les tables figurant dans des tablespaces non
SYSTEM gérés localement. Toutefois, les objets dépendants résidant dans des tablespaces
gérés au moyen du dictionnaire font l'objet d'un flashback dans le cadre de l'opération
Flashback de l'objet parent résidant dans un tablespace géré localement.
Les tables pour lesquelles des stratégies d'audit détaillé (FGA) ou VPD (Virtual Private
Database) sont définies ne peuvent pas être soumises à une opération Flashback Drop. De
même, vous ne pouvez pas procéder au flashback d'une table supprimée si celle-ci a été
purgée. Elle peut avoir été purgée manuellement avec l'instruction PURGE ou
automatiquement suite à un besoin d'espace pour d'autres objets dans le tablespace.
Lorsque vous effectuez une opération Flashback Drop sur une table, tous les objets dépendant
de cette table font également l'objet d'un flashback à partir de la corbeille. Il y a des
exceptions : les index de jointure bitmap, les contraintes d'intégrité référentielle et les
journaux des vues matérialisées ne sont pas pris en compte dans le flashback, même si leur
table parent fait l'objet d'un flashback.
Remarque : Si vous supprimez un index avant de supprimer la table qui lui est associée, la
récupération de l'index n'est pas prise en charge lorsque vous procédez à un flashback de la
table supprimée.
Présentation
Database
Navigation temporelle grâce aux Table
Drop
fonctionnalités Flashback > Query
Versions
Transaction
• Flashback Query
– Interrogez toutes les données à un point
dans le temps spécifique.
• Flashback Versions Query
– Consultez toutes les versions
d'une ligne entre deux points
dans le temps.
– Consultez les transactions
Temps
ayant modifié la ligne.
• Flashback Transaction Query
– Affichez toutes Transaction 3
les modifications
apportées par Transaction 2
Flashback
une transaction. Transaction 1
Navigation temporelle grâce aux fonctionnalités Flashback

La technologie Flashback offre la possibilité d'interroger des versions antérieures des objets
de schéma et des données historiques, et d'effectuer une analyse des modifications. Chaque
transaction génère de façon logique une nouvelle version de la base de données. Avec la
technologie Flashback, vous pouvez naviguer au sein de ces versions pour rechercher une
erreur et sa cause :
• Flashback Query : interrogez toutes les données telles qu'elles existaient à un point
dans le temps spécifique.
• Flashback Versions Query : consultez toutes les versions d'une ligne entre deux points
dans le temps, ainsi que les transactions qui ont modifié cette ligne.
• Flashback Transaction Query : affichez toutes les modifications apportées par une
transaction.
Flashback Query : Présentation
Employees Mises à jour Employees

non souhaitées
t1 t2
SELECT employee_id, salary FROM employees

AS OF TIMESTAMP t1
WHERE employee_id = 200
Flashback Query : Présentation

Avec la fonctionnalité Flashback Query, vous pouvez effectuer des interrogations sur la base
de données à partir d'un certain point dans le temps. En utilisant la clause AS OF de
l'instruction SELECT, vous pouvez indiquer l'horodatage pour lequel afficher les données.
Ceci est utile pour l'analyse d'une divergence des données.
Remarque : La clause AS OF peut être suivie de TIMESTAMP ou SCN.
Flashback Query : Exemple
Employees Employees Employees
salary = 4,400 salary = 4,840 salary = 4,400
11:00 11:10
UPDATE employees SET salary =

(SELECT salary FROM employees
AS OF TIMESTAMP TO_TIMESTAMP
('2005-05-04 11:00:00', 'yyyy-mm-dd hh24:mi:ss')
WHERE employee_id = 200)
WHERE employee_id = 200
Flashback Query : Exemple

Si une augmentation a récemment été accordée à un employé particulier par erreur, vous
pouvez procéder à une nouvelle mise à jour du salaire, en affectant le salaire fourni par une
sous-interrogation qui renvoie la valeur du flashback.
Présentation
Flashback Versions Query : Database
Table
Présentation Drop
Query
> Versions
Transaction 0 Transaction 1 Transaction 2 Transaction
Employees Employees Employees
200
t1 t2
SELECT versions_xid, salary FROM employees
VERSIONS BETWEEN TIMESTAMP t1 and t2
WHERE employee_id = 200;
Transaction 0 Transaction 1 Transaction 2
Flashback Versions Query : Présentation

Avec la fonctionnalité Flashback Query, vous pouvez effectuer des interrogations sur la base
de données à partir d'une certaine période ou plage de numéros SCN (System Change
Numbers) indiqués par l'utilisateur. La fonctionnalité Flashback Versions Query vous permet
d'utiliser la clause VERSIONS pour extraire toutes les versions des lignes qui existent entre
deux points dans le temps ou deux SCN.
Les lignes renvoyées par Flashback Versions Query représentent un historique des
modifications effectuées par les différentes transactions. Flashback Versions Query extrait
uniquement les occurrences validées (commit) des lignes. Les versions non validées des
lignes au sein d'une transaction ne sont pas affichées. Les lignes renvoyées incluent également
les versions supprimées et ensuite réinsérées des lignes.
Vous pouvez utiliser Flashback Versions Query pour extraire l'historique des lignes. Cela
vous permet d'auditer les lignes d'une table et d'extraire des informations sur les transactions
ayant affecté les lignes. Vous pouvez ensuite utiliser l'identificateur de transaction renvoyé
pour procéder à l'extraction des transactions à l'aide de LogMiner ou pour exécuter une
opération Flashback Versions Query, étudiée plus loin dans ce chapitre.
Remarque : Dans l'exemple ci-dessus, VERSIONS_XID est une pseudo-colonne qui renvoie
l'identificateur de transaction de la version correspondante d'une ligne.
Flashback Versions Query
Flashback Versions Query via Enterprise Manager

L'opération Flashback Versions Query peut également être réalisée via Enterprise Manager.
Dans la page Maintenance, sélectionnez Perform Recovery.
Dans la page Perform Recovery, sélectionnez Tables sous Object Type et Flashback Existing
Tables sous Operation Type. Cliquez sur Perform Object Level Recovery. Dans la page
"Perform Object Level Recovery: Point-in-Time", sélectionnez "Evaluate row changes and
transactions to decide on a point in time" et indiquez le nom de la table cible.
Dans la zone Available Columns, sélectionnez les colonnes à afficher, puis entrez une clause
de recherche dans la zone Bind The Row Value. Sélectionnez "Show all row history", puis
cliquez sur Next.
Flashback Versions Query :
• La clause VERSIONS ne peut pas être utilisée

pour interroger :
– des tables externes
– des tables temporaires
– des vues V$
– des vues
• La clause VERSIONS ne peut pas concerner
des commandes LDD.
• Les opérations de récupération d'espace dans
les segment sont exclues.
Flashback Versions Query : Eléments à prendre en compte

La clause VERSIONS ne peut pas être utilisée pour interroger les tables spéciales suivantes :
• Tables externes
• Tables temporaires
• Vues V$
Vous ne pouvez pas utiliser la clause VERSIONS pour interroger une vue. Toutefois, une
définition de vue peut utiliser la clause VERSIONS.
La clause VERSIONS d'une instruction SELECT ne peut pas produire les versions des lignes
modifiées par des instructions LDD qui changent la structure des tables correspondantes. Cela
signifie que l'interrogation cesse de produire des lignes après avoir atteint un point dans le
passé correspondant à la modification de la structure de la table.
Certaines opérations de maintenance, telles qu'une récupération d'espace dans les segments,
peuvent déplacer des lignes au sein de blocs. Dans ce cas, l'interrogation Versions Query
exclut les versions fantôme de ce type car les données de la ligne restent inchangées.
Présentation
Flashback Transaction Query : Database

Table
Présentation Drop
Query
Versions
> Transaction
FLASHBACK_TRANSACTION_QUERY
DBA
Instruction
LMD Instruction SQL
erronée d'annulation
Utilisateur
Flashback Transaction Query : Présentation

Flashback Transaction Query est un outil de diagnostic que vous pouvez utiliser pour afficher
les modifications apportées à la base de données au niveau transaction. Vous pouvez ainsi
diagnostiquer les problèmes dans la base de données, et procéder à des analyses et à des audits
des transactions.
Vous pouvez utiliser la vue FLASHBACK_TRANSACTION_QUERY pour déterminer quelles
sont les instructions SQL à utiliser pour annuler les modifications apportées par une
transaction spécifique ou sur une période donnée.
Flashback Transaction Query
Flashback Transaction Query via Enterprise Manager

Cette fonctionnalité est utilisée en liaison avec la fonctionnalité Flashback Versions Query
avec l'aide de l'assistant Perform Recovery Wizard. Dans la page "Perform Object Level
Recovery: Choose SCN", cliquez sur le lien Transaction ID correspondant dans la région
Flashback Versions Query Result.
Dans l'exemple de la diapositive ci-dessus, une opération Flashback Versions Query est
réalisée sur la table JOBS afin d'extraire les trois versions de la ligne JOBS pour
JOB_ID = 'AD_PRES'. L'utilisateur clique ensuite sur l'un des ID de transaction, ce qui
affiche toutes les modifications faisant partie de cette transaction. Notez que, outre la mise à
jour de la table JOBS, une mise à jour de la table EMPLOYEES a également été effectuée au
sein de cette transaction.
Flashback Transaction Query :
• Les opérations LDD sont vues comme des mises

à jour du dictionnaire.
• Les objets supprimés apparaissent en tant
que numéros d'objet.
• Les utilisateurs supprimés apparaissent
en tant qu'ID utilisateur.
Flashback Transaction Query : Eléments à prendre en compte

• Au sein de la base de données, les opérations LDD ne sont rien d'autre qu'une série
d'opérations de gestion de l'espace et de modifications du dictionnaire de données. Une
opération Flashback Transaction Query sur une transaction incluant une opération LDD
affiche les modifications apportées au dictionnaire de données.
• Lorsque Flashback Transaction Query implique des tables qui ont été supprimées de la
base de données, le nom de ces tables n'est pas indiqué. Les numéros d'objet sont utilisés
à la place.
• Si l'utilisateur qui a exécuté une transaction est supprimé, l'opération Flashback
Transaction Query sur cette transaction affiche uniquement l'ID utilisateur
correspondant, pas le nom utilisateur.
Remarque : Lorsque les données d'annulation sont insuffisantes pour une transaction
spécifique, une ligne contenant la valeur UNKNOWN dans la colonne OPERATION de
FLASHBACK_TRANSACTION_QUERY est renvoyée.
Synthèse

• décrire Flashback Database
• restaurer le contenu d'une table jusqu'à un point
spécifique dans le temps avec Flashback Table
• récupérer une table supprimée
• afficher le contenu de la base de données à partir
de n'importe quel point unique dans le temps avec
Flashback Query
• voir les différentes versions d'une ligne dans
le temps avec Flashback Versions Query
• afficher l'historique des transactions ou
une ligne avec Flashback Transaction Query
Utiliser Flashback

• Utiliser Flashback pour récupérer une table
supprimée
• Exécuter Flashback Versions Query
Déplacer des données
Objectifs Objet répertoire
SQL*Loader
Data Pump
- Export
- Import
Table externe

• décrire les méthodes disponibles pour déplacer
des données
• créer et utiliser des objets répertoire (DIRECTORY)
• utiliser SQL*Loader pour charger des données à partir
d'une base non Oracle (ou de fichiers utilisateur)
• expliquer l'architecture générale de Data Pump
• utiliser Data Pump Export et Data Pump Import
pour déplacer des données entre des bases Oracle
• utiliser des tables externes pour déplacer des données
via des fichiers indépendants de la plate-forme
Déplacer des données :
Architecture générale
SQL*Loader expdp impdp Autres clients
Data Pump
Moteur de déplacement de données/métadonnées

DBMS_DATAPUMP
Programme API de chargement

de Oracle API de
chargement DataPump des données par
métadonnées
Oracle chemin direct
API de table externe
Déplacer des données : Architecture générale

La diapositive ci-dessus présente le schéma des principaux composants fonctionnels :
• DBMS_DATAPUMP : Ce package intègre l'API associée aux utilitaires d'export et
d'import à haute vitesse pour le déplacement en masse de données et de métadonnées.
• API de chargement des données par chemin direct (DPAPI) : Oracle Database 10g
prend en charge une interface API de chargement des données par chemin direct qui
réduit les opérations de conversion et d'analyse (parse) des données lors du
déchargement et du chargement.
• DBMS_METADATA : Ce package est utilisé par les processus actifs pour le
déchargement et le chargement de l'ensemble des métadonnées. Les définitions d'objet
de base de données sont stockées en langage XML plutôt qu'en langage SQL.
• API de table externe : Avec les pilotes d'accès ORACLE_DATAPUMP et
ORACLE_LOADER, vous pouvez stocker des données dans des tables externes
(c'est-à-dire dans des fichiers indépendants de la plate-forme). L'instruction SELECT lit
les tables externes comme si elles étaient stockées dans une base de données Oracle.
• SQL*Loader : Le client SQL*Loader a été intégré à des tables externes, ce qui permet
une migration automatique des fichiers de contrôle SQL*Loader vers des paramètres
d'accès aux tables externes.
• expdp et impdp : Les clients expdp et impdp sont des couches légères appelant le
package DBMS_DATAPUMP pour le lancement et la surveillance d'opérations
Data Pump.
Déplacer des données : Architecture générale (suite)
• Autres clients : Il s'agit d'applications, telles que Database Control, des
fonctionnalités de réplication, des tablespaces transportables et des applications
utilisateur, qui bénéficient de cette infrastructure. SQL*Plus peut également être
utilisé comme client de DBMS_DATAPUMP pour de simples interrogations de statut
portant sur les opérations en cours.
Objet répertoire : Présentation .
Objet répertoire : Présentation

Les objets répertoire (DIRECTORY) sont des structures logiques représentant un répertoire
physique dans le système de fichiers du serveur. Ils contiennent l'emplacement d'un répertoire
spécifique du système d'exploitation. Les nom des objets répertoire peuvent être utilisés dans
Enterprise Manager, ce qui évite d'avoir à coder les chemin d'accès en dur. Vous bénéficiez
ainsi d'une plus grande flexibilité quant à la gestion des fichiers. Les objets répertoire
appartiennent à l'utilisateur SYS. Les noms de répertoire sont uniques au sein de la base de
données car tous les répertoires sont situés dans un espace de noms unique (SYS).
Les objets répertoire sont nécessaires lorsque vous indiquez l'emplacement de fichiers pour
Data Pump, car ce dernier accède à des fichiers situés sur le serveur plutôt que sur le client.
Dans Enterprise Manager, sélectionnez Administration > Directory Objects.
Pour modifier ou supprimer un objet répertoire, sélectionnez-le et cliquez sur le bouton
approprié.
Créer des objets répertoire
3
5
Créer des objets répertoire

1. Dans la page Directory Objects, cliquez sur le bouton Create.
2. Entrez le nom de l'objet répertoire (DIRECTORY), ainsi que son chemin d'accès au
niveau du système d'exploitation. Le répertoire doit préalablement avoir été créé. Vous
pouvez procéder à un test en cliquant sur le bouton "Test File System". Pour ce test,
indiquez les informations d'identification et de connexion (credentials) à l'hôte (c'est-à-
dire l'utilisateur du système d'exploitation qui dispose de privilèges sur ce répertoire du
système d'exploitation).
3. Les droits concernant les objets répertoire sont différents des droits du système
d'exploitation sur le répertoire physique dans le système de fichiers du serveur. Vous
pouvez gérer les privilèges utilisateur sur des objets répertoire individuels. Le niveau de
sécurité est ainsi accru et vous disposez d'un contrôle fin sur ces objets. Dans l'onglet
Privileges, cliquez sur Add pour sélectionner l'utilisateur auquel vous souhaitez octroyer
des privilèges de lecture et/ou d'écriture.
4. Cliquez sur Show SQL pour afficher les instructions sous-jacentes.
5. Cliquez sur OK afin de créer l'objet.
Objet répertoire
SQL*Loader : Présentation > SQL*Loader
Data Pump
- Export
- Import
Table externe
Fichiers
de données Fichier de
d'entrée contrôle
SQL*Loader
Rejet
Traitement des champs
Acceptation
Abandon
Enregistrement de la sélection
Sélection
Fichier des
Serveur Oracle enregistrements
Fichier Rejet refusés
de rebut Insertion
(facultatif)
Fichier
journal
SQL*Loader : Présentation
L'utilitaire SQL*Loader charge les données de fichiers externes dans des tables d'une base de
données Oracle. Cet utilitaire dispose d'un puissant moteur d'analyse (parse) des données, qui
ne limite que très peu le format des données du fichier. Les fichiers utilisés par SQL*Loader
sont les suivants :
Fichiers de données d'entrée : SQL*Loader lit les données à partir d'un ou plusieurs fichiers
(ou équivalents de fichiers dans le système d'exploitation), indiqués dans le fichier de
contrôle. Du point de vue de SQL*Loader, les données du fichier sont organisées en
enregistrements. Un fichier de données peut se présenter dans un format d'enregistrement de
type fixe, un format d'enregistrement de type variable ou un format d'enregistrement de type
"flux". Ce format peut être défini dans le fichier de contrôle via le paramètre INFILE. Si
aucun format d'enregistrement n'est défini, le format d'enregistrement de type "flux" est utilisé
par défaut.
SQL*Loader : Présentation (suite)
Fichier de contrôle : Le fichier de contrôle est un fichier texte écrit dans un langage
pouvant être interprété par SQL*Loader. Le fichier de contrôle indique à SQL*Loader où
trouver les données, comment les analyser et les interpréter, où insérer les données, etc.
Bien que ce ne soit pas explicitement défini, le fichier de contrôle du programme de
chargement est composé de trois sections.
• La première section contient des informations relatives à la session :
- Options globales, telles que le nom du fichier de données d'entrée et les
enregistrements à ignorer.
- Clauses INFILE indiquant où trouver les données d'entrée.
- Données à charger.
• La deuxième section est constituée d'un ou plusieurs blocs INTO TABLE. Chacun
de ces blocs contient des informations sur la table dans laquelle les données doivent
être chargées, telles que le nom et les colonnes de la table.
• La troisième section est facultative et, si elle est présente, contient les données
d'entrée.
Fichier journal : Lorsque l'exécution de SQL*Loader commence, un fichier journal est
créé. Si le système ne peut pas créer ce fichier journal, l'exécution se termine. Le fichier
journal contient un récapitulatif détaillé de la charge, notamment une description des
erreurs qui se sont produites pendant le chargement.
Fichier des enregistrements refusés (bad file) : Ce fichier contient les enregistrements
qui sont rejetés, soit par SQL*Loader, soit par la base de données Oracle. Les
enregistrements de fichiers de données sont rejetés par SQL*Loader lorsque le format
d'entrée n'est pas valide. Une fois que SQL*Loader a accepté le traitement d'un
enregistrement de fichiers de données, ce dernier est envoyé à la base de données Oracle
en vue de son insertion dans une table sous forme de ligne. Si la base de données Oracle
détermine que la ligne est valide, elle est insérée dans la table. Si la ligne est considérée
comme non valide, l'enregistrement est rejeté et SQL*Loader le place dans le fichier des
enregistrements refusés.
Fichier de rebut : Ce fichier est créé uniquement si nécessaire, et uniquement si vous
avez indiqué qu'un fichier de rebut doit être activé. Le fichier de rebut contient les
enregistrements qui sont exclus du chargement parce qu'ils ne satisfont à aucun des
critères de sélection indiqués dans le fichier de contrôle.
Pour plus d'informations sur SQL*Loader, reportez-vous au manuel Oracle Database
Utilities.
Charger des données avec SQL*Loader
Charger des données avec SQL*Loader

Utilisez l'assistant Load Data from User Files Wizard pour charger les données d'un fichier
plat dans une base Oracle. Pour afficher l'assistant, sélectionnez Enterprise Manager
Maintenance > Data Movement > Move Row Data > Load Data from User Files. L'assistant
vous guide tout au long des opérations à effectuer.
Fichier de contrôle SQL*Loader
Le fichier de contrôle SQL*Loader indique à ce dernier

les informations suivantes :
• Emplacement des données à charger
• Format des données
• Détails de configuration :
– Gestion de la mémoire
– Rejet des enregistrements
– Détails du traitement des chargements
interrompus
• Détails de la manipulation de données
Fichier de contrôle SQL*Loader

Le fichier de contrôle SQL*Loader est un fichier texte contenant des instructions LDD
(Langage de définition de données). Ces instructions LDD sont utilisées pour contrôler les
aspects suivants d'une session SQL*Loader :
• Où SQL*Loader peut trouver les données à charger.
• Comment ces données doivent être formatées pour SQL*Loader.
• Comment SQL*Loader est configuré (notamment gestion de la mémoire, critères de
sélection et de rejet, traitement des chargements interrompus, etc.) lors du chargement
des données.
• Comment SQL*Loader manipule les données chargées.
Voici l'explication des différentes lignes du fichier de contrôle :
1 -- This is a sample control file
2 LOAD DATA
3 INFILE ’SAMPLE.DAT’
4 BADFILE ’sample.bad’
5 DISCARDFILE ’sample.dsc’
6 APPEND
7 INTO TABLE emp
8 WHEN (57) = ’.’
Fichier de contrôle SQL*Loader (suite)
9 TRAILING NULLCOLS
10 (hiredate SYSDATE,
deptno POSITION(1:2) INTEGER EXTERNAL(3)
NULLIF deptno=BLANKS,
job POSITION(7:14) CHAR TERMINATED BY WHITESPACE
NULLIF job=BLANKS "UPPER(:job)",
mgr POSITION(28:31) INTEGER EXTERNAL
TERMINATED BY WHITESPACE, NULLIF mgr=BLANKS,
ename POSITION(34:41) CHAR
TERMINATED BY WHITESPACE "UPPER(:ename)",
empno POSITION(45) INTEGER EXTERNAL
TERMINATED BY WHITESPACE,
sal POSITION(51) CHAR TERMINATED BY WHITESPACE
"TO_NUMBER(:sal,’$99,999.99’)",
comm INTEGER EXTERNAL ENCLOSED BY ’(’ AND ’%’
":comm * 100"
)
1. Les commentaires peuvent apparaître n'importe où dans la section de commande du fichier,
mais ils ne doivent pas apparaître dans les données. Faites précéder les commentaires de deux
traits d'union. Tout le texte situé à droite du double trait d'union est ignoré, jusqu'à la fin de la
ligne.
2. L'instruction LOAD DATA indique à SQL*Loader le début d'un nouveau chargement de
données. Si vous poursuivez un chargement dont la progression a été interrompue, utilisez
l'instruction CONTINUE LOAD DATA.
3. Le mot-clé INFILE indique le nom d'un fichier contenant les données que vous souhaitez
charger.
4. Le mot-clé BADFILE indique le nom d'un fichier dans lequel sont placés les enregistrements
refusés.
5. Le mot-clé DISCARDFILE indique le nom d'un fichier dans lequel sont placés les
enregistrements écartés.
6. Le mot-clé APPEND est l'une des options que vous pouvez utiliser lors du chargement de
données dans une table qui n'est pas vide. Pour charger les données dans une table vide,
utilisez le mot-clé INSERT.
7. Le mot-clé INTO TABLE permet d'identifier les tables, les champs et les types de données. Il
définit la relation entre les enregistrements dans le fichier de données et les tables de la base.
8. La clause WHEN indique une ou plusieurs conditions relatives aux champs auxquelles chaque
enregistrement doit satisfaire pour que SQL*Loader puisse charger les données. Dans
l'exemple considéré, SQL*Loader ne charge l'enregistrement que si le 57e caractère est un
point décimal. Ce point décimal délimite les dollars et les cents dans le champ et entraîne le
rejet des enregistrements si SAL ne comporte aucune valeur.
9. La clause TRAILING NULLCOLS invite SQL*Loader à considérer comme une colonne
NULL toute colonne positionnée de manière relative et qui n'est pas présente dans
l'enregistrement.
10. Le reste du fichier de contrôle contient la liste des champs, qui fournit des informations sur les
formats de colonne dans la table chargée.
Méthodes de chargement
Insertion de Ecritures
données de blocs
Table
HWM
Chargement des données par chemin Chargement des données par chemin direct
conventionnel
Utilise une opération COMMIT Utilise des enregistrements de données
(opération plus rapide)
Génère toujours des entrées de Génère des informations de journalisation

journalisation uniquement dans certaines conditions
Applique toutes les contraintes Applique uniquement les contraintes PRIMARY KEY,
UNIQUE et NOT NULL
Exécute des déclencheurs INSERT N'exécute pas de déclencheurs (triggers) INSERT
Peut charger les données dans des Ne charge pas les données dans des clusters
tables clusterisées
Permet aux autres utilisateurs de Empêche les autres utilisateurs d'apporter des
modifier les tables pendant l'opération modifications aux tables pendant l'opération de
de chargement chargement
Comparaison du chargement des données par chemin direct et par chemin

conventionnel
Méthode d'enregistrement des données
Le chargement des données par chemin conventionnel utilise le traitement SQL et une
opération COMMIT de base de données pour enregistrer les données. L'insertion d'un tableau
d'enregistrements est suivie d'une opération COMMIT. Chaque chargement de données peut
impliquer plusieurs transactions.
Le chargement des données par chemin direct utilise des enregistrements pour écrire les blocs
de données dans des fichiers de données Oracle. C'est pourquoi les chargements de données
par chemin direct sont plus rapides que les chargements conventionnels. Les différences entre
un enregistrement de données et une opération COMMIT sont les suivantes :
• Au cours d'un enregistrement, seuls les blocs de base de données complets sont écrits
dans la base.
• Les blocs sont écrits après le repère high-water mark (HWM) de la table.
• Après un enregistrement, le repère high-water mark (HWM) est déplacé.
• Les ressources internes ne sont pas libérées après un enregistrement.
• Un enregistrement ne met pas fin à la transaction.
• Les index ne sont pas mis à jour lors de chaque enregistrement de données.
Remarque : Le chargement des données par chemin direct et le chargement parallélisé par
chemin direct présentent tellement de similitudes en ce qui concerne les activités LMD qu'ils
ne sont pas distingués dans cette comparaison.
Comparaison du chargement des données par chemin direct et par chemin
conventionnel (suite)
Journalisation des modifications
Le chargement des données par chemin conventionnel génère des entrées de
journalisation, comme n'importe quelle instruction LMD. Lors de l'utilisation du
chargement des données par chemin direct, les entrées de journalisation ne sont pas
générées dans les cas suivants :
• La base de données est en mode NOARCHIVELOG.
• La base de données est en mode ARCHIVELOG, mais la journalisation est
désactivée. La journalisation peut être désactivée via la définition de l'attribut
NOLOGGING pour la table ou via l'utilisation de la clause UNRECOVERABLE dans
le fichier de contrôle.
Application des contraintes
Au cours d'un chargement des données par chemin conventionnel, toutes les contraintes
activées sont appliquées, de la même façon qu'au cours de toute opération LMD.
Au cours d'un chargement des données par chemin direct, les contraintes sont traitées de la
façon suivante :
• Les contraintes NOT NULL sont vérifiées lors de la création de tableaux.
• Les contraintes FOREIGN KEY et CHECK sont désactivées. Elles peuvent être
activées à la fin du chargement via l'utilisation des commandes appropriées dans le
fichier de contrôle. Les contraintes FOREIGN KEY sont désactivées, car elles font
référence à d'autres lignes ou tables. Les contraintes CHECK sont désactivées parce
qu'elles peuvent utiliser des fonctions SQL. Si seul un petit nombre de lignes doit
être inséré dans une table volumineuse, utilisez un chargement des données par
chemin conventionnel.
• Les contraintes PRIMARY KEY et UNIQUE sont vérifiées pendant le chargement et à
la fin. Elles peuvent être désactivées si une violation est détectée.
Exécution de déclencheurs INSERT
Les déclencheurs (triggers) WHILE INSERT sont exécutés au cours d'un chargement des
données par chemin conventionnel. Ils sont désactivés avant un chargement des données
par chemin direct, puis réactivés à la fin du chargement. Ils peuvent rester désactivés si un
objet référencé n'est pas accessible à la fin de l'exécution. Envisagez l'utilisation de
chargements par chemin conventionnel pour charger des données dans des tables à l'aide
de déclencheurs INSERT.
Chargement dans des tables clusterisées
Le chargement des données par chemin direct ne peut pas être utilisé pour charger des
lignes dans des tables clusterisées. Seuls les chargements par chemin conventionnel sont
possibles avec les tables clusterisées.
Verrouillage
Pendant un chargement des données par chemin direct, d'autres transactions ne peuvent
pas apporter de modifications aux tables impliquées. La seule exception à cette règle est
l'utilisation simultanée de plusieurs sessions de chargement direct en parallèle.
Objet répertoire
SQL*Loader
Data Pump : Présentation > Data Pump
- Export
- Import
En tant que fonctionnalité basée sur le serveur Table externe
pour le déplacement à haute vitesse de données
et de métadonnées, Data Pump :
• peut être appelé via DBMS_DATAPUMP
• fournit les outils suivants :
– expdp
– impdp
– interface Web
• fournit des méthodes d'accès aux données :
– chemin direct
– tables externes
• se détache des travaux à longue durée d'exécution
et s'y rattache
• redémarre les travaux Data Pump
Data Pump : Présentation

Data Pump permet le chargement et le déchargement à très haute vitesse de données et de
métadonnées dans des bases Oracle. L'infrastructure Data Pump peut être appelée via le package
PL/SQL DBMS_DATAPUMP. Il est ainsi possible de construire des utilitaires personnalisés de
déplacement de données à l'aide de Data Pump.
Oracle Database 10g fournit les outils suivants :
• Des clients d'export et d'import en mode ligne de commande nommés respectivement
expdp et impdp.
• Une interface Web d'export et d'import accessible à partir de Database Control.
Data Pump décide automatiquement des méthodes d'accès aux données à utiliser (chargement des
données par chemin direct ou tables externes). Il utilise un chargement et un déchargement des
données par chemin direct lorsque la structure d'une table le permet et lorsque l'objectif est
d'obtenir des performances maximales avec un flux unique. Toutefois, en présence de tables
clusterisées, de contraintes d'intégrité référentielle, de colonnes cryptées ou d'un certain nombre
d'autres éléments, Data Pump utilise des tables externes plutôt qu'un chargement par chemin
direct pour déplacer les données.
Data Pump : Présentation (suite)
La possibilité de se détacher temporairement des travaux à longue durée d'exécution et de
s'y rattacher sans affecter le travail lui-même vous permet de surveiller les travaux à partir
de plusieurs emplacements pendant leur exécution. Tous les travaux Data Pump arrêtés
peuvent être redémarrés sans perte de données à condition que les métainformations
restent inchangées. Peu importe que le travail ait été arrêté volontairement ou
involontairement en raison d'une panne.
Remarque : Data Pump faisant partie intégrante d'Oracle Database 10g, il est disponible
dans toutes les configurations. Toutefois, le parallélisme est disponible uniquement dans
Enterprise Edition.
Data Pump : Avantages
• Sélection fine d'objets et de données

• Spécification explicite de la version de la base
de données
• Exécution en parallèle
• Estimation de la consommation d'espace par
le travail d'export
• Mode réseau dans un environnement distribué
• Fonctionnalités de remise en correspondance
pendant l'import
• Echantillonnage des données et compression
des métadonnées
Data Pump : Avantages

Les paramètres EXCLUDE, INCLUDE et CONTENT sont utilisés pour une sélection fine d'objets
et de données.
Vous pouvez indiquer la version de la base de données pour les objets à déplacer (à l'aide du
paramètre VERSION) afin de créer un jeu de fichiers dump compatible avec une version
antérieure de la base de données Oracle prenant en charge Data Pump.
Vous pouvez utiliser le paramètre PARALLEL pour indiquer le nombre maximal de threads de
serveurs d'exécution actifs pour le compte du travail d'export.
Vous pouvez estimer la quantité d'espace consommée par un travail d'export (sans réellement
réaliser l'export) à l'aide du paramètre ESTIMATE_ONLY.
Grâce au mode réseau, vous pouvez procéder directement à un export entre une base de données
distante et un jeu de fichiers dump. Cela est possible grâce à un lien de base de données vers le
système source.
Pendant l'import, vous pouvez modifier les noms de fichier, les schémas et les tablespaces cible.
En outre, Oracle Database 10g vous permet d'indiquer un pourcentage de données à
échantillonner et à décharger de la base source lors de la réalisation d'une opération Data Pump
Export. Il faut pour cela indiquer le paramètre SAMPLE.
Vous pouvez utiliser le paramètre COMPRESSION pour indiquer si les métadonnées doivent être
compressées dans le fichier dump d'export afin de consommer moins d'espace disque. Si vous
compressez les métadonnées, elles sont automatiquement décompressées pendant l'import.
Data Pump Export et Data Pump Import :
Client
Présentation
expdp Lien de base de données
Source Cible
Travail Processus
Data Pump serveur
Base de Base de
données données
Jeu de Jeu de
Table fichiers fichiers Table
maître dump dump maître
"Mode réseau"
Processus Travail
serveur Data Pump
Client
impdp
Data Pump Export et Data Pump Import : Présentation

Data Pump Export est un utilitaire permettant de décharger des données et des métadonnées dans
un ensemble de fichiers du système d'exploitation appelé jeu de fichiers dump. Data Pump Import
est utilisé pour charger sur un système cible les métadonnées et les données stockées dans un jeu de
fichiers dump d'export.
L'API Data Pump accède à ses fichiers sur le serveur plutôt que sur le client.
Les utilitaires Data Pump Export et Data Pump Import peuvent également être employés pour
effectuer un export direct entre une base de données distante et un jeu de fichiers dump, ou pour
charger la base de données cible directement à partir de la base source, sans fichiers intermédiaires.
C'est ce qu'on appelle le mode réseau. Ce mode est particulièrement utile pour exporter des données
à partir d'une base source en lecture seule.
Au centre de chaque opération Data Pump figure la table maître, qui est créée dans le schéma de
l'utilisateur qui exécute le travail Data Pump. La table maître gère tous les aspects du travail. Elle
est construite pendant un travail d'export basé sur des fichiers et son écriture dans le jeu de fichiers
dump constitue la dernière étape. Inversement, le chargement de la table maître dans le schéma de
l'utilisateur actuel est la première étape d'une opération d'import basée sur des fichiers. Cette table
est utilisé pour séquencer la création de tous les objets importés.
Remarque : La table maître est la clé de la fonctionnalité de redémarrage de Data Pump en cas
d'arrêt planifié ou non planifié du travail. Elle est supprimée lorsque le travail Data Pump se
termine normalement.
Utilitaire Data Pump : Interfaces et modes
• Interfaces Data Pump Export et Data Pump Import :

– Ligne de commande
– Fichier de paramètres
– Ligne de commande interactive
– Database Control
• Modes Data Pump Export et Data Pump Import :
– Complet
– Schéma
– Table
– Tablespace
– Tablespace transportable
Utilitaire Data Pump : Interfaces et modes

Vous pouvez interagir avec les utilitaires Data Pump Export et Data Pump Import à l'aide de l'une
des interfaces suivantes :
• L'interface de ligne de commande vous permet d'indiquer la plupart des paramètres d'export
directement sur la ligne de commande.
• L'interface de type fichier de paramètres vous permet d'indiquer tous les paramètres de
ligne de commande dans un fichier de paramètres. La seule exception est le paramètre
PARFILE.
• L'interface de ligne de commande interactive arrête la connexion au terminal, et affiche les
invites d'export ou d'import à partir desquelles vous pouvez entrer différentes commandes.
Pour activer ce mode, appuyez sur [Ctrl] + [C] pendant une opération d'export démarrée
avec l'interface de ligne de commande ou l'interface de type fichier de paramètres. Le mode
commande interactif est également activé lorsque vous vous attachez à un travail qui est en
cours d'exécution ou arrêté.
• Vous pouvez également accéder à l'interface Web. Dans la page d'accueil de Database
Control, cliquez sur l'onglet Maintenance, puis sélectionnez l'un des liens suivants dans la
région Utilities : Export to Files, Import from Files ou Import from Database.
Les utilitaires Data Pump Export et Data Pump Import fournissent différents modes de
déchargement et de chargement pour différentes parties de la base de données. Le mode est
indiqué sur la ligne de commande à l'aide du paramètre approprié. Les modes disponibles sont
répertoriés dans la diapositive ci-dessus. Ils sont identiques à ceux des utilitaires d'export et
d'import d'origine.
Objet répertoire
SQL*Loader
Sélection fine d'objets .
Data Pump
> - Export
- Import
Table externe
Sélection fine d'objets

Le travail Data Pump peut inclure ou exclure pratiquement n'importe quel type d'objet.
Le paramètre EXCLUDE permet d'exclure n'importe quel type d'objet de base de données
d'une opération d'export ou d'import. Le qualificatif de nom facultatif vous permet d'effectuer
une sélection à un niveau plus détaillé au sein de chaque type d'objet indiqué. Exemples :
EXCLUDE=VIEW
EXCLUDE=PACKAGE
EXCLUDE=INDEX:"LIKE 'EMP%'"
Le paramètre INCLUDE permet de restreindre une opération aux objets et aux types d'objet
indiqués. Syntaxe :
INCLUDE = object_type[:"name_expr"]
Le paramètre CONTENT vous permet de demander, pour l'opération actuelle, uniquement les
métadonnées, uniquement les données ou les deux. Syntaxe :
CONTENT = ALL | METADATA_ONLY | DATA_ONLY
Le paramètre QUERY fonctionne de la même manière qu'avec l'utilitaire d'export d'origine,
avec deux améliorations significatives. Il peut être qualifié avec un nom de table de façon à
s'appliquer uniquement à cette table. Par ailleurs, il peut également être utilisé pendant
l'import. Exemple :
QUERY=hr.employees:"WHERE department_id in (10,20) and
salary < 1600 ORDER BY department_id"
Fonctionnalité avancée : Echantillonnage
• Tâche : créer des données de test.

• Méthode : indiquer le pourcentage de données à
échantillonner et à décharger à partir de la base source.
Pour décharger 44 % de la table HR.EMPLOYEES :

SAMPLE="HR"."EMPLOYEES":44
Pour décharger 30 % de l'intégralité du travail d'export

(car aucun nom de table n'est indiqué) :
expdp hr/hr DIRECTORY=DATA_PUMP_DIR
DUMPFILE=sample1.dmp SAMPLE=30
Fonction avancée : Echantillonnage

Avec le paramètre SAMPLE, vous pouvez indiquer le pourcentage de données à
échantillonner et à décharger à partir de la base source lors de la réalisation d'une opération
Data Pump Export.
Syntaxe :
SAMPLE=[[schema_name.]table_name:]sample_percent
Plage pour sample_percent : de .000001 à 100 (non inclus)
La valeur sample_percent indique la probabilité de l'inclusion d'un bloc de lignes.
Remarque : Le paramètre SAMPLE n'est pas valide pour les exports réseau.
Options d'export : Fichiers
Options d'export : Fichiers

Les travaux Data Pump gèrent trois types de fichier :
• Des fichiers dump pour les données et les métadonnées à déplacer
• Des fichiers journaux pour les messages
• Des fichiers SQL pour la sortie d'une opération SQLFILE
Data Pump étant basé sur le serveur et non sur le client, l'accès aux fichiers Data Pump se fait
par rapport aux chemins de répertoire Oracle. Les chemins absolus ne sont pas pris en charge
pour des raisons de sécurité.
Emplacement des fichiers Data Pump
Ordre de priorité des emplacements de fichier :

• Répertoire par fichier
• Paramètre DIRECTORY
• Variable d'environnement DATA_PUMP_DIR
• Objet répertoire DATA_PUMP_DIR
Emplacement des fichiers Data Pump

La diapositive ci-dessus indique l'ordre de priorité utilisé par les clients Data Pump pour
localiser les fichiers :
• Des objets répertoire (DIRECTORY) par fichier peuvent être indiqués pour chaque
fichier dump, fichier journal et fichier SQL. Dans ce cas, ils doivent être séparés du nom
de fichier par le symbole deux-points (:).
• Les clients Data Pump Export et Data Pump Import fournissent un paramètre
DIRECTORY, qui indique le nom d'un objet répertoire. Les objets répertoire décrivent
l'emplacement d'accès aux fichiers.
• Vous pouvez également définir la variable d'environnement DATA_PUMP_DIR pour
indiquer le nom de l'objet répertoire au lieu d'utiliser le paramètre DIRECTORY. Les
clients Data Pump recherchent cette variable d'environnement si aucun objet répertoire
n'est indiqué explicitement.
• Un objet répertoire par défaut est créé pour chaque base de données. Cet objet répertoire
est nommé DATA_PUMP_DIR. L'accès à ce répertoire est automatiquement octroyé aux
rôles EXP_FULL_DATABASE et IMP_FULL_DATABASE.
Emplacement des fichiers Data Pump (suite)
• Vous n'avez pas besoin de créer manuellement un objet répertoire avant d'utiliser
Data Pump Export. Un objet répertoire par défaut est créé pour chaque base de
données nouvellement créée ou mise à niveau par un script sous UNIX ou Windows.
Cet objet répertoire est nommé DATA_PUMP_DIR. L'accès à ce répertoire est
automatiquement octroyé aux rôles EXP_FULL_DATABASE et
IMP_FULL_DATABASE. Le répertoire DATA_PUMP_DIR est créé à l'un des
emplacements suivants :
- <ORACLE_BASE>/admin/DB_UNIQUE_NAME
- <ORACLE_HOME>/admin/DB_UNIQUE_NAME
La spécification de chemin exacte du répertoire DATA_PUMP_DIR varie selon la
valeur des variables d'environnement système ORACLE_BASE et ORACLE_HOME,
et selon l'existence du sous-répertoire DATA_PUMP_DIR. Si la variable
ORACLE_BASE est définie sur le système cible, sa valeur est utilisée. Sinon, c'est la
valeur de la variable ORACLE_HOME qui est utilisée. Si, pour une raison ou pour
une autre, le sous-répertoire DATA_PUMP_DIR est introuvable, le chemin par
défaut suivant est utilisé : ORACLE_HOME/rdbms/log.
Remarque : Dans tous les cas, vous devez disposer des privilèges d'accès appropriés à
l'objet répertoire pour l'opération tentée. Pour un export, vous avez besoin d'un accès en
écriture sur tous les fichiers. Pour un import, vous avez besoin d'un accès en lecture sur les
fichiers dump et d'un accès en écriture sur les fichiers journaux et les fichiers SQL.
Planifier et exécuter un travail
Planifier et exécuter un travail

Les travaux Data Pump (créés via cet assistant) sont planifiés en tant que travaux pouvant être
répétés par Enterprise Manager Database Control.
Nom et taille des fichiers Data Pump
Nom et taille des fichiers Data Pump

Le paramètre DUMPFILE indique le nom et (éventuellement) le répertoire des fichiers dump
basés sur des disques. Plusieurs spécifications de fichiers peuvent être fournies sous la forme
d'une liste séparée par des virgules ou dans des spécifications de paramètre DUMPFILE
distinctes. Les noms de fichier peuvent contenir la variable de substitution %U, ce qui
implique que plusieurs fichiers peuvent être générés. La variable %U est développée en un
entier à deux caractères, de longueur fixe, augmentant de façon monotone à partir de 01. Si
aucun paramètre DUMPFILE n'est indiqué, expdat.dmp est utilisé par défaut. Par défaut,
les fichiers dump créés sont en auto-extension.
Si le paramètre FILESIZE est indiqué, chaque fichier présente une taille de FILESIZE
octets et n'est pas en auto-extension. Si davantage d'espace dump est requis et qu'un modèle
avec %U a été fourni, un nouveau fichier de FILESIZE octets est créé automatiquement.
Dans le cas contraire, le client reçoit un message l'invitant à ajouter un nouveau fichier.
Si un modèle avec %U est indiqué, le nombre de fichiers initialement créés est égal à la valeur
du paramètre PARALLEL.
Si l'un des fichiers créés a le même nom qu'un fichier pré-existant, il n'écrase pas ce dernier.
Une erreur est générée et le travail est abandonné.
Remarque : Si plusieurs modèles de fichier dump sont fournis, ils sont utilisés pour générer
de façon circulaire pour la génération des fichiers dump.
Objet répertoire
SQL*Loader
Data Pump Import Data Pump
- Export
> - Import
Table externe
Data Pump Import

Data Pump Import est un utilitaire permettant le chargement d'un jeu de fichiers dump
d'export sur un système cible. Le jeu de fichiers dump est constitué d'un ou de plusieurs
fichiers sur disque contenant des données de table, des métadonnées d'objet de base de
données et des informations de contrôle. Les fichiers sont écrits dans un format binaire
propriétaire. Pendant une opération d'import, l'utilitaire Data Pump Import emploie ces
fichiers pour localiser chaque objet de base de données.
Vous pouvez interagir avec Data Pump Import en mode ligne de commande, via un fichier de
paramètres ou en mode commande interactif :
• Vous pouvez utiliser la commande impdp et indiquer des paramètres directement sur la
ligne de commande.
• Vous pouvez entrer des paramètres de ligne de commande dans un fichier (le paramètre
PARFILE est exclu car les fichiers de paramètres ne peuvent pas être imbriqués).
• En mode commande interactif, l'exécution du travail en cours se poursuit, mais la
connexion au terminal est arrêtée et l'invite d'import apparaît. Vous pouvez, par
exemple, attacher des travaux supplémentaires à un travail qui est en cours d'exécution
ou arrêté.
Data Pump Import : Transformations
Vous pouvez remettre en correspondance :

• des fichiers de données à l'aide
de REMAP_DATAFILE
• des tablespaces à l'aide de REMAP_TABLESPACE
• des schémas à l'aide de REMAP_SCHEMA
REMAP_DATAFILE = 'C:\oradata\tbs6.f':'/u1/tbs6.f'

Les métadonnées d'objet étant stockées au format XML dans le jeu de fichiers dump, il est
facile d'appliquer des transformations lors de la formation d'une instruction LDD pendant
l'import. Data Pump Import prend en charge plusieurs transformations :
• REMAP_DATAFILE est utile lors du déplacement de bases de données entre des plates-
formes dotées de sémantiques de système de fichiers différentes.
• REMAP_TABLESPACE permet de déplacer des objets d'un tablespace vers un autre.
• REMAP_SCHEMA fournit l'ancien utilitaire FROMUSER /TOUSER permettant de
modifier le propriétaire d'un objet.
Grâce à TRANSFORM, vous pouvez également :

• exclure des tables et des index :
– clauses STORAGE et TABLESPACE
– clause STORAGE uniquement
• recréer des identificateurs d'objet pour des types
de données abstraits
• modifier les allocations d'extents et la taille
des fichiers
TRANSFORM =
SEGMENT_ATTRIBUTES|STORAGE|OID|PCTSPACE:{y|n|v}[:object type]
Data Pump Import : Transformations (suite)

Le paramètre TRANSFORM vous permet de modifier l'instruction LDD de création d'objet
pour des objets spécifiques ou pour tous les objets applicables en cours de chargement.
Définissez le paramètre TRANSFORM comme indiqué dans la diapositive ci-dessus. Voici les
options possibles :
• SEGMENT_ATTRIBUTES : Si la valeur indiquée est Y, les attributs de segment
(attributs physiques, attributs de stockage, tablespaces et options de journalisation) sont
inclus.
• STORAGE : Si la valeur indiquée est Y, les clauses STORAGE sont incluses.
• OID : Vous pouvez utiliser ce paramètre pour déterminer si l'ID d'objet (OID) des types
de données abstraits (ADT, Abstract Data Type) est réutilisé ou recréé. Si la valeur
indiquée est N, la génération de la clause d'OID d'export pour les types d'objet est
supprimée. Cela est utile si vous avez besoin de dupliquer des schémas entre des bases
de données via un export et un import, mais que vous ne pouvez pas garantir que les
types d'objet auront des valeurs d'OID identiques dans ces bases.
• PCTSPACE : Vous pouvez utiliser le paramètre PCTSPACE pour réduire la quantité
d'espace requise pour les tablespaces en réalisant une opération de récupération d'espace
sur l'allocation de mémoire aux tablespaces. La valeur fournie pour cette transformation
doit être un nombre supérieur à zéro. Elle représente le multiplicateur utilisé pour
modifier les allocations d'extents (ensembles de blocs contigus) et la taille des fichiers
de données.
Data Pump : Considérations relatives
aux performances
Optimiser les performances des travaux avec
le paramètre PARALLEL
Coordinateur maître
Exécution
en parallèle
Fichiers
générés
Exemple :
expdp hr/hr FULL=y
DUMPFILE=dp_dir1:full1%U.dmp, dp_dir2:full2%U.dmp
FILESIZE=2G PARALLEL=3
LOGFILE=dp_dir1:expfull.log JOB_NAME=expfull
Data Pump : Considérations relatives aux performances

Vous pouvez améliorer le débit d'un travail avec le paramètre PARALLEL. Le paramètre de
parallélisme est appliqué par le processus maître, qui alloue le travail à exécuter aux
processus actifs réalisant le traitement des données et des métadonnées au sein d'une
opération. Ces processus actifs fonctionnent en parallèle. En général, le degré de parallélisme
doit correspondre à plus du double du nombre de CPU d'une instance. Pour optimiser le
parallélisme, vous devez fournir au moins un fichier pour chaque degré de parallélisme. Si le
nombre de fichiers dump est insuffisant, les performances ne seront pas optimales car
plusieurs threads d'exécution tenteront d'accéder au même fichier dump. Le degré de
parallélisme peut être réinitialisé à tout moment pendant un travail.
L'exemple de la diapositive ci-dessus illustre un export de base de données complète. Toutes
les données et métadonnées de la base seront exportées. Les fichiers dump (full101.dmp,
full201.dmp, full102.dmp, etc.) seront créés selon la méthode par tourniquet (round
robin) dans les répertoires vers lesquels pointent les objets répertoire dp_dir1 et dp_dir2.
Pour des performances optimales, ceux-ci doivent figurer sur des canaux d'E/S distincts. Si
nécessaire, chaque fichier comportera jusqu'à 2 Go. Jusqu'à trois fichiers seront créés
initialement. D'autres fichiers seront créés si nécessaire. Le travail et la table maître portent le
même nom : expfull. Le fichier journal expfull.log sera écrit dans le répertoire
dp_dir1.
Paramètres d'initialisation
des performances
• Les performances de Data Pump peuvent être
affectées par :
– DISK_ASYNCH_IO=TRUE
– DB_BLOCK_CHECKING=FALSE
– DB_BLOCK_CHECKSUM=FALSE
• Pour un parallélisme maximal, les paramètres suivants
doivent avoir des valeurs élevées :
– PROCESSES
– SESSIONS
– PARALLEL_MAX_SERVERS
• Les paramètres suivants doivent définir
une taille importante :
– SHARED_POOL_SIZE
– UNDO_TABLESPACE
Paramètres d'initialisation des performances

Vous pouvez essayer d'utiliser les paramètres (illustrés dans la diapositive ci-dessus) pour
améliorer les performances. Toutefois, leur effet peut être différent d'une plate-forme à une
autre.
En outre, les paramètres d'initialisation SHARED_POOL_SIZE et UNDO_TABLESPACE
doivent avoir une valeur correspondant à une taille importante. Leur valeur exacte dépend de
la taille de la base de données.
Chemin d'accès Data Pump :
Considérations
L'un des chemins d'accès suivants est Base de

données
sélectionné automatiquement par Data Pump :
• Chemin direct
• Tables externes, si les données
incluent : Tables Chemin
externes direct
– des colonnes cryptées
– des tables clusterisées
– une partition différente lors du
Base de
déchargement et du chargement,
données
et autres (reportez-vous
aux commentaires)
Chemin direct Data Pump : Considérations

Data Pump sélectionne automatiquement la méthode d'accès la plus appropriée pour chaque
table.
Il utilise un chargement et un déchargement des données par chemin direct lorsque la
structure d'une table le permet et lorsque l'objectif est d'obtenir des performances maximales
avec un flux unique.
Data Pump utilise des tables externes dans les cas suivants :
• Tables avec contrôle d'accès de niveau fin activé en mode insertion ou sélection
• Index de domaine, qui existe pour une colonne LOB
• Tables avec déclencheurs (triggers) actifs définis
• Index global sur tables partitionnées avec chargement de partition unique
• Colonnes de type BFILE ou opaque
• Contrainte d'intégrité référentielle
• Colonnes VARRAY avec type opaque intégré
Remarque : Les deux méthodes prenant en charge la même représentation externe des
données, les données déchargées avec une méthode peuvent être chargées à l'aide de l'autre
méthode.
Utiliser Enterprise Manager pour surveiller
les travaux Data Pump
Utiliser Enterprise Manager pour surveiller les travaux Data Pump

Vous pouvez employer l'interface graphique d'Enterprise Manager pour surveiller tous les
travaux Data Pump, y compris ceux qui ont été créés à l'aide des interfaces de ligne de
commande expdp ou impdp, ou à l'aide du package DBMS_DATAPUMP.
Vous pouvez afficher et modifier le statut actuel du travail (EXECUTE, STOP ou SUSPEND).
Pour accéder à la page Export and Import Jobs, cliquez sur le lien Monitor Export and Import
Jobs dans la région Move Row Data de la page Maintenance.
Objet répertoire
SQL*Loader
Remplissage de tables externes Data Pump
- Export
- Import
> Table externe
• Déchargement de données vers des fichiers

externes avec le pilote d'accès ORACLE_DATAPUMP
• Aucune modification des tables externes
CREATE TABLE … AS SELECT INSERT … SELECT
Déchargement Chargement
Fichiers externes
Tables (format propriétaire) Tables
Remplissage de tables externes

Une "table externe" est composée de fichiers plats ayant un format propriétaire (DPAPI -
Direct Path API), qui sont indépendants du système d'exploitation. Lorsque des données sont
extraites de la base Oracle et "déchargées" dans des fichiers, elles sont converties de façon
transparente de leur représentation interne Oracle en une représentation externe native Oracle
équivalente (DPAPI).
Vous pouvez utiliser la commande CREATE TABLE AS SELECT pour remplir une table
externe. Une fois que vous avez créé et rempli une table externe, il est impossible d'y ajouter,
d'y mettre à jour ou d'y supprimer des lignes. Toute tentative de modification des données de
la table externe échoue. Une table externe ne peut pas comporter d'index.
Le pilote d'accès Data Pump permet les opérations de déchargement et de chargement pour
les tables externes.
Utiliser des tables externes
• Les données peuvent être utilisées directement

à partir du fichier externe ou chargées dans
une autre base.
• Les fichiers résultants ne peuvent être lus
qu'avec le pilote d'accès ORACLE_DATAPUMP.
• Vous pouvez combiner des fichiers générés
à partir de différentes sources à des fins
de chargement.
Depuis la base Depuis un fichier

de données Oracle externe
Utiliser des tables externes

Les fichiers de données créés pour la table externe peuvent être déplacés et utilisés en tant que
fichiers de données d'une autre table externe, dans la même base ou dans une autre. Ils ne
peuvent être lus que par le pilote d'accès ORACLE_DATAPUMP. Vous pouvez indiquer si les
applications doivent accéder directement aux tables externes avec la commande SELECT ou
si les données doivent d'abord être chargées dans une base cible.
Les fichiers de données alimentés par différentes tables externes peuvent tous être indiqués
dans la clause LOCATION d'une autre table externe. Il est ainsi facile d'agréger des données
provenant de plusieurs sources. La seule restriction est que les métadonnées doivent être
identiques pour toutes les tables externes.
Remplissage d'une table externe avec
ORACLE_DATAPUMP
CREATE TABLE emp_ext
(first_name, last_name, department_name)
ORGANIZATION EXTERNAL
(
TYPE ORACLE_DATAPUMP
DEFAULT DIRECTORY ext_dir
LOCATION ('emp1.exp','emp2.exp','emp3.exp')
)
PARALLEL
AS
SELECT e.first_name,e.last_name,d.department_name
FROM employees e, departments d
WHERE e.department_id = d.department_id AND
d.department_name in
('Marketing', 'Purchasing');
Remplissage d'une table externe avec ORACLE_DATAPUMP

L'exemple de la diapositive montre comment l'opération de remplissage de la nouvelle table
externe peut permettre d'exporter une sélection d'enregistrements résultant de la jointure des
tables EMPLOYEES et DEPARTMENTS.
La table externe pouvant être volumineuse, vous pouvez recourir à une opération de
remplissage en parallèle pour décharger les données vers une table externe. Contrairement à
ce qui se passe pour une interrogation en parallèle à partir d'une table externe, le degré de
parallélisme d'une opération de remplissage en parallèle est limité par le nombre de fichiers
dans lesquels le pilote d'accès peut écrire simultanément. A un instant donné, un seul
processus serveur d'exécution en parallèle écrit dans un fichier.
Le nombre de fichiers mentionnés dans la clause LOCATION doit correspondre au degré de
parallélisme indiqué car chaque processus serveur d'E/S requiert son propre fichier. Tout
fichier supplémentaire indiqué est ignoré. Si le nombre de fichiers est insuffisant pour le
degré de parallélisme indiqué, ce dernier est abaissé afin de correspondre au nombre de
fichiers indiqués dans la clause LOCATION.
Remarque : Pour plus d'informations sur les paramètres du pilote d'accès
ORACLE_DATAPUMP, reportez-vous au manuel Oracle Database Utilities.
Remplissage d'une table externe avec
ORACLE_LOADER
CREATE TABLE extab_employees
(employee_id NUMBER(4),
first_name VARCHAR2(20),
last_name VARCHAR2(25),
hire_date DATE)
ORGANIZATION EXTERNAL
( TYPE ORACLE_LOADER DEFAULT DIRECTORY extab_dat_dir
ACCESS PARAMETERS
( records delimited by newline
badfile extab_bad_dir:'empxt%a_%p.bad'
logfile extab_log_dir:'empxt%a_%p.log'
fields terminated by ','
missing field values are null
( employee_id, first_name, last_name,
hire_date char date_format date mask "dd-mon-yyyy"))
LOCATION ('empxt1.dat', 'empxt2.dat') )
PARALLEL REJECT LIMIT UNLIMITED;
Remplissage d'une table externe avec ORACLE_LOADER

Le pilote d'accès ORACLE_LOADER utilise la syntaxe SQL*Loader pour créer des tables
externes.
L'exemple de la diapositive ci-dessus suppose que trois objets répertoire (extab_dat_dir,
extab_bad_dir et extab_log_dir) sont créés et mis en correspondance avec des
répertoires du système d'exploitation existants, dont l'accès est octroyé à l'utilisateur.
Conseil : Si vous avez beaucoup de données à charger, activez PARALLEL pour l'opération
de chargement :
ALTER SESSION ENABLE PARALLEL DML;
Dictionnaire de données
Consultez les informations sur les tables externes dans :

• [DBA| ALL| USER]_EXTERNAL_TABLES
• [DBA| ALL| USER]_EXTERNAL_LOCATIONS
• [DBA| ALL| USER]_TABLES et autres
Dictionnaire de données
[DBA| ALL| USER]_EXTERNAL_TABLES répertorient les attributs spécifiques des
tables externes dans la base de données.
[DBA| ALL| USER]_EXTERNAL_LOCATIONS répertorient les sources de données pour
les tables externes.
[DBA| ALL| USER]_TABLES décrivent les tables relationnelles dans la base de données.
[DBA| ALL| USER]_TAB_COLUMNS décrivent les colonnes des tables, vues et clusters
dans la base de données.
Synthèse

• décrire les méthodes disponibles pour déplacer
des données
• créer et utiliser des objets répertoire (DIRECTORY)
• utiliser SQL*Loader pour charger des données à partir
d'une base non Oracle (ou de fichiers utilisateur)
• expliquer l'architecture générale de Data Pump
• utiliser Data Pump Export et Data Pump Import
pour déplacer des données entre des bases Oracle
• utiliser des tables externes pour déplacer
des données via des fichiers indépendants
de la plate-forme
Déplacer des données

• utiliser l'assistant Data Pump Export Wizard
pour sélectionner les objets de base de données
à exporter
• surveiller un travail Data Pump Export
• utiliser l'assistant Data Pump Import Wizard
pour importer des tables dans la base de données
• utiliser l'assistant Load Data Wizard pour charger
des données dans la base
• charger des données à l'aide de la ligne
de commande

Administration Workshop I V2

Transféré par

Informations du document

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

Administration Workshop I V2

Transféré par

Droits d'auteur :

Formats disponibles

Oracle Database 10g :

Volume II - Manuel du stagiaire

Tom Best Avertissement

2 Installer le logiciel de base de données Oracle

4 Gérer l'instance Oracle

7 Gérer les objets de schéma

8 Gérer les données et la simultanéité d'accès aux données

10 Implémenter la sécurité de la base de données Oracle

13 Gestion des performances

18 Déplacer des données

Annexe C : Commandes de base de Linux et vi

Annexe D : Syntaxe des instructions SQL

Annexe E : Acronymes et termes

Annexe F : Etapes suivantes : Poursuivre la formation

Copyright © 2005, Oracle. Tous droits réservés.

A la fin de ce chapitre, vous pourrez :

Copyright © 2005, Oracle. Tous droits réservés.

Copyright © 2005, Oracle. Tous droits réservés.

Obligations en matière de sécurité dans les entreprises

• Les utilisateurs disposant des privilèges DBA

Copyright © 2005, Oracle. Tous droits réservés.

Séparation des responsabilités

Un système sécurisé garantit la confidentialité

Copyright © 2005, Oracle. Tous droits réservés.

Sécurité de la base de données

Copyright © 2005, Oracle. Tous droits réservés.

Principe du moindre privilège

• Protégez le dictionnaire de données :

• Révoquez les privilèges non nécessaires de PUBLIC :

• Limitez les répertoires accessibles par les utilisateurs.

Copyright © 2005, Oracle. Tous droits réservés.

Appliquer le principe du moindre privilège

intégrante des procédures de sécurité. Déterminez

Copyright © 2005, Oracle. Tous droits réservés.

Surveiller les activités suspectes

Copyright © 2005, Oracle. Tous droits réservés.

Audit de base de données standard

ALTER SYSTEM SET audit_trail="XML" SCOPE=SPFILE;

Redémarrez la base de données après la modification

Utilisez AUDIT_TRAIL pour activer l'audit de base

Copyright © 2005, Oracle. Tous droits réservés.

Traces d'audit uniformes

Copyright © 2005, Oracle. Tous droits réservés.

Page Audit Settings d'Enterprise Manager

• Audit des instructions SQL :

• Audit des privilèges système (non ciblé et ciblé) :

• Audit des privilèges objet (non ciblé et ciblé) :

Copyright © 2005, Oracle. Tous droits réservés.

Définir les options d'audit

Désactivez les options d'audit si vous ne les utilisez pas.

Copyright © 2005, Oracle. Tous droits réservés.

Utiliser et gérer les informations d'audit

Un utilisateur Un déclencheur Un enregistrement

La modification Un enregistrement d'audit

Copyright © 2005, Oracle. Tous droits réservés.

Audit basé sur les données

• Audite SELECT, INSERT, UPDATE, DELETE

SELECT name, salary

Copyright © 2005, Oracle. Tous droits réservés.

SELECT name, salary

Copyright © 2005, Oracle. Tous droits réservés.

Stratégie d'audit détaillé

Copyright © 2005, Oracle. Tous droits réservés.

Instruction LMD auditée : Eléments à prendre en compte