Systèmes de Gestion Des Bases de Données Dr Mohamed Salah

Transcription

Systèmes de Gestion des Bases de Données : ORACLE
Institut Supérieur d’Education et de
Formation Continue
Systèmes de Gestion Des Bases de
Données
Dr Mohamed Salah GOUIDER
Page 1
29/06/2006
Table des matières
1. COMPOSANTS DE L ARCHITECTURE ORACLE
1.1. INTRODUCTION AU SERVEUR ORACLE
1.1.1. Tâches de l’administrateur de base de données
1.2. CONNEXION A UN SERVEUR ORACLE
1.2.1. Processus utilisateur
1.2.2. Processus serveur
1.3. INSTANCE ORACLE ET BASE DE DONN ES
1.3.1. System Global Area (SGA)
1.3.2. SGA dynamique.
1.3.3. Processus d'arrière plan
1.3.4. Fichiers de la base de données
1.3.5. Fichiers relatant à la Base de données
1.4. TRAITEMENT DE REQUETES
1.4.1. Etapes lors du traitement d'une requête
1.4.2. Pool partagé (Shared Pool)
1.4.3. Buffer de Cache de la base de données (Database Buffer Cache)
1.4.4. Buffer de Redo Log
1.4.5. Program Global Area (PGA)
1.5. TRAITEMENT DE REQU TES DML
1.5.1. Phases d'exécution d'un requête DML
1.5.2. Segments de Rollback
1.5.3. Database Writer (DBWn)
1.5.4. Log Writer (LGWR)
1.6. TRAITEMENT D’UN COMMIT
1.6.1. Numéro de changement du système (SCN)
1.6.2. Traitement d'un COMMIT : Etapes
2. OUTILS D'ADMINISTRATION
2.1. UTILITAIRES ADMINISTRATIFS
2.1.1. Utilitaires d'administration de base de données
2.1.2. Optimal Flexible Architecture (OFA)
2.2. ORACLE ENTREPRISE MANAGER (OEM)
2.2.1. Architecture d'OEM : Vue d'ensemble
2.2.2. Composants de la console OEM.
2.2.3. Services communs d'OEM.
2.2.4. Configurer OEM
2.3. PACKAGE D'ADMINISTRATION.
2.3.1. Pack de management DBA
2.3.2. Packs de management supplémentaires
Page 2
29/06/2006
3. GERER UNE INSTANCE ORACLE
3.1. AUTHENTIFICATION ET PRIVILEGES
3.2. FICHIERS DE PARAMETRES
3.2.1. Paramètres présents dans le fichier de paramètre
3.2.2. Le PFILE (initSID.ora)
3.2.3. Le SPFILE (spfileSID.ora)
3.2.4. Règles pour les valeurs de paramètre
3.2.5. Paramètres essentiels
3.2.6. Paramètres communément modifiés
3.3. DEMARRAGE ET ARRET D'UNE INSTANCE.
3.3.1. Etapes de démarrage d’une instance
3.3.2.. Changer la disponibilité de la Base de données
3.3.3. Etapes d'arrêt d'une instance
3.3.4. Modes d'arrêts
3.4. VUE DYNAMIQUE DES PERFORMANCES
3.4.1. Caractéristiques des vues dynamiques de performance
3.4.2. Descriptions des vues dynamiques de performance
4. PROCEDURE DE CREATION D UNE BASE DE DONN ES
4.1. PREREQUIS NECESSAIRES A LA CREATION
4.1.1. Gérer et sauvegarder les fichiers d’une base de données
4.1.2. Créer une base de données
4.2. ENVIRONNEMENT DU SYSTEME D’EXPLOITATION
4.2.1. Création de fichiers de mots de passe
4.3. CREER UNE BASE DE DONNEES
4.3.1. Assistant de configuration de base de données
4.3.2. Les options de la commande CREATE DATABASE
4.3.3. Créer une base de données en mode commande.
4.3.4. Les conditions d'erreur lors de la création d'une base de données
4.3.5. Le contenu d'une base de données après sa création
5. UTILISATION ET CONTENU DU DICTIONNAIRE DE DONNEES
5.1. STRUCTURE DU DICTIONNAIRE DE DONN ES
5.1.1. Présentation du dictionnaire de données
5.1.2. Création et catégories des vues du dictionnaire de données
5.1.3. Informations contenues dans le dictionnaire de données.
5.2. SCRIPTS DU DICTIONNAIRE DE DONNREES
5.2.1. Création de fonctions PL/SQL
5.2.2. Scripts administratifs
Page 3
29/06/2006
6. GESTION DES FICHIERS DE CONTROLE ET DE REDO LOG
6.1. FICHIER DE CONTROLE
6.1.1. Contenu des fichiers de contrôle
6.1.2. Multiplexage des fichiers de contrôle
6.1.3. Récupérer les informations des fichiers de contrôle
6.2. LES FICHIERS DE REDO LOG
6.2.1. Utiliser les fichiers de redo log
6.2.2. Structure des fichiers de redo log
6.2.3. Paramètres des fichiers de redo log.
6.3. GERER LES GROUPES DE REDO
6.3.1. Fonctionnement des fichiers de redo log.
6.3.2. Forcer un basculement de fichiers log et un point de synchronisation
6.3.3. Ajout de groupe de fichiers redo log online
6.3.4. Ajout des membres redo log online
6.3.5. Relocalisation des fichiers redo log online
6.3.6. Suppression de groupes de fichiers redo log online
6.3.7. Suppression des membres redo log online
6.3.8. Réinitialisation des fichiers redo log online
6.4. PLANIFICATION DES FICHIERS REDO LOG ONLINE
3.4.1. Nombre de fichiers redo log online
6.4.2. Emplacement des fichiers redo log online
6.4.3. Dimensionnement des fichiers redo log online
6.4.4. Gérer les redo log online with OMF
6.4.5. Obtenir des informations sur les groupes
6.4.6. Archivage de fichiers de redo log
7. GERER LES TABLESPACES ET LES FICHIERS DE DONNEES
7.1. ARCHITECTURE D'UNE BASE DE DONNEES
7.1.1. Vue d'ensemble de la structure d'une base de données
7.1.2. Relations.
Création de base de données
7.1.3. Caractéristiques d'un tablespace
7.1.4. Utilisations d'un tablespace
7.1.5. Caractéristiques d'un fichier de données
7.2. CREER DES TABLESPACES
7.2.1. Types de tablespaces
7.2.2. Création d’un tablespace
7.2.3. Gestion de l’espace dans les tablespaces
7.2.4. Locally Managed tablespaces
7.2.5. Dictionary Managed Tablespaces
7.2.6. Paramètres de stockage
7.2.7. Les Undo Tablespaces
7.3. TABLESPACE TEMPORAIRE
Page 4
29/06/2006
7.3.1. Tablespace temporaire
7.3.2. Tablespace temporaire par défaut
7.3.3. Restrictions sur les Tablespace temporaire par défaut
7.4. MANIPULATION DE TABLESPACE.
7.4.1.Offline Status
7.4.2. Tablespace en lecture seul
7.4.3. Tablespaces en lecture seul sur des supports en lecture seul
7.4.4. Supprimer un Tablespace
7.4.5. Conséquences de la suppression de tablespaces
7.5. FICHIERS DE MANIPULATION DES DONNNES
7.5.1. Mettre en place l’extension automatique des fichiers de données
7.5.2. Changer la taille des fichiers de données manuellement
7.5.3. Ajouter un fichier de données à un Tablespace
7.5.4. Déplacer un fichier de données : ALTER TABLESPACE
7.6. AUTRES OPTIONS SUR LES TABLESPACES
7.6.1. Configurer OMF pour la création de Tablespace
7.6.2. Créer des Tablespaces avec OMF
7.6.3. Récupérer des informations sur les Tablespaces.
Page 5
29/06/2006
1. Composants de l architecture Oracle
1.1. Introduction au serveur Oracle
Tâches de l administrateur de base de données
L'administrateur de base de données (appelé DBA) est responsable du contrôle et
de la configuration du système et des utilisateurs.
De nombreuses taches vont être effectuées par celui-ci :
• Installer le serveur Oracle et les outils applicatifs, créer les bases de
données.
• Assurer la maintenance et la disponibilité de la base de données.
• Créer la structure logique de stockage, c'est à dire les tablespaces, les
tables, les vues et les indexes.
• Manager la structure physique de stockage, comprenant les fichiers de
données, les fichiers de contrôle et les fichiers de redo log.
• Allouer et prévoir l'espace disque système de stockage nécessaire aux
spécifications de la base de données.
• Maintenir, contrôler et monitorer les accès des utilisateurs.
• Assurer la sécurité du système.
• Monitorer les performances de la base de données.
• Créer un plan de sauvegarde et de récupération.
1.2. Connexion a un serveur Oracle
Pour travailler et consulter les données, les utilisateurs doivent tout d'abord se
connecter à un Serveur Oracle. Il existe trois types de connexions grâce auxquelles
un utilisateur peut accéder à un Serveur Oracle :
Connexion locale : Selon cette méthode, un utilisateur est directement connecté
sur la machine faisant office de Serveur Oracle.
Connexion Deux Tiers : Ce type de connexion est couramment nommé
"Connexion Client Serveur", un utilisateur se connecte à partir d'une machine
directement connectée à un Serveur Oracle.
Par exemple, lorsque qu'un utilisateur lance un Oracle Forms (Front End pour
consulter des bases de données Oracle à travers des formulaires.) sur un poste
client sous Windows pour accéder à un Serveur Oracle résident sur une machine
Windows NT Serveur.
Connexion Multi Tiers : Dans une architecture multi tiers, la machine de
l'utilisateur se connecte à un Serveur applicatif (Par exemple un Serveur Web) qui
Page 6
29/06/2006
lui même va se connecter au serveur Oracle pour récupérer les données issues de
la base de données.
Lorsque qu'un utilisateur est connecté à une machine sur laquelle réside un
Serveur Oracle, deux process sont invoqués : Le process utilisateur et le process
serveur.
Un process utilisateur est créé lorsque tout outil client allant communiquer avec le
serveur Oracle est lancé (Un outil d'administration, une application, SQL*Plus,
une application Oracle Forms).
Un process utilisateur est un mécanisme qui va exécuter le code d'une application
ou d'un outil Oracle.
Un process serveur est créé lorsque un utilisateur va se loguer sur le serveur en
spécifiant un nom d'utilisateur, un mot de passe et un nom de base de données. Le
process Serveur est créé sur le serveur Oracle.
Le process serveur va permettre l'interaction entre le process utilisateur et le
serveur Oracle en récupérant les requêtes et en les exécutant sur les serveurs
Oracle.
Le lien entre le process utilisateur et le process serveur est appelé une connexion.
• Si l'utilisateur se connecte localement sur le serveur, le chemin de
communication est établi via un mécanisme de communication inter
process.
• Si l'utilisateur se connecte via une machine cliente, un logiciel réseau est
utilisé. Une connexion spécifique entre un utilisateur et un serveur Oracle
est appelé une Session.
La session démarre lorsque la connexion de l'utilisateur est validée par le serveur
Oracle et se termine lorsqu'il se déconnecte ou lorsqu'une fin de connexion
prématurée se produit.
De nombreuses sessions concurrentes d'un même utilisateur ou de plusieurs
peuvent s'exécuter sur le serveur Oracle.
Page 7
29/06/2006
1.2.1. Processus utilisateur
Pour faire fonctionner un outil application tel que SQL*Plus ou des applicatifs
Oracle Forms, Oracle crée un process utilisateur (Client). L'UPI (User Program
Interface) est un mécanisme standardisé utilisé par un process utilisateur pour
communiquer avec un process serveur. C'est l'UPI qui génère l'appel au serveur
Oracle.
1.2.2. Processus serveur
Le process serveur a les caractéristiques suivantes :
Il traite les requêtes du process utilisateur et retourne le statut et le résultat de cette
requête. Le DBA à la responsabilité de l'administration de ces process serveurs.
Chaque process serveur utilise une zone de mémoire appelée la PGA (Program
Global Area). Cette zone est créée au démarrage du process serveur.
Le process serveur inclus l'OPI (Oracle Program Interface) qui est utilisé pour
communiquer avec la base de données Oracle.
1.3. Instance Oracle et Base de données
1.3.1. System Global Area (SGA)
Un serveur Oracle est constitué d'une instance Oracle et d'une base de données
Oracle. L'instance Oracle comprend une région de la mémoire appelée La SGA
(System Global Area), ainsi que les processus d’arrière plan utilisé pour gérer la
base de données. La SGA contient des données et des informations de contrôle sur
le serveur Oracle.
La mémoire est allouée à la SGA lors du démarrage d'une instance et dés allouée
lors de son arrêt.
Cette zone mémoire est partagée et réside dans la mémoire vive qui n'est pas
swappée ni paginée pour des raisons de performances.
La SGA se compose de plusieurs structures de groupe de mémoire, les trois
principales étant :
Le pool partagé (Shared Pool) : Contient les requêtes SQL le plus récemment
exécuté et l'information du dictionnaire de données la plus récemment utilisée.
Le buffer de cache de la base de données (Database Buffer Cache) : Cette
structure stocke les données utilisatrices les plus récentes tirées des tables.
Le buffer de redo Log (Redo Log Buffer) : Ce buffer est utilisé pour enregistrer
les modifications effectuées sur la base de données.
On trouve aussi dans la SGA :
Le pool large (Large Pool) : Le large pool est une zone mémoire optionnel de la
SGA configurée uniquement dans un environnement serveur partagé. Quand un
utilisateur se connecte à un serveur partagé, Oracle a besoin d’allouer de l’espace
supplémentaire dans les shared pool pour stocker les informations de connexions
entre les différents process. Le pool large permet donc d’alléger certaines zones
Page 8
29/06/2006
mémoires de la SGA. En effet, il n’a pas besoin de diminuer la mémoire allouée
aux arbres de parcours au profit des informations de sessions, d’entrées/sortie, de
sauvegarde et des processus de récupérations. Le gain de performance vient de la
réduction de la charge occasionnée par l'augmentation ou la réduction de la
mémoire cache partagée.
Recover Manager (RMAN), utilise le large pool pour restaurer les données en cas
de défaillance.
Le pool Java (Java Pool) : Sa taille par défaut est de 24Mo et doit être utilisé en
cas d’utilisation du langage Java.
1.3.2. SGA dynamique
Une SGA dynamique implémente une infrastructure qui permet de modifier la
taille dynamiquement de la SGA sans éteindre l’instance. La taille de la SGA va
augmentée par l’intermédiaire du data buffer cache, du shared pool, et du pool
large sans jamais dépasser le SGA_MAX_SIZE. Les
Paramètres qui affectent la taille de la SGA sont :
DB_CACHE_SIZE : La taille de cache des blocs standard.
LOG_BUFFER : Le nombre de bit pour le redo log buffer cache.
SHARED_POOL_SIZE : La taille en bit du shared pool.
LARGE_POOL_SIZE : La taille du large pool, par défaut 0.
Page 9
29/06/2006
1.3.3. Processus d'arrière plan
Une instance Oracle comprend, en plus de la SGA, un ensemble de process
d'arrière plan qui sont au niveau du système d'exploitation.
Oracle 9i comprend cinq process d'arrière plan obligatoire pour une instance :
Database Writer (DBWn) : Il écrit les données changées du buffer de cache de
base de données vers les fichiers de données.
Log Writer (LGWR) : Il enregistre les changements qui sont instanciés dans le
buffer de redo log vers les fichiers de redo log. (Ces changements sont référencés
comme les données du redo log)
System Monitor (SMON) : Il exécute une récupération de l'instance lors de son
démarrage, il nettoie les segments temporaires qui ne sont plus utilisés et annule
les transaction qui n'avaient pas été validées lors d'un plantage du système. Il
défragmente l'espace disponible dans les fichiers de données.
Process Monitor (PMON) : Il récupère les process lorsque qu'un process
utilisateur échoue. Il est responsable du nettoyage du cache et de déverrouiller les
ressources système bloquées par un process utilisateur.
Check point (CKPT) : il met à jour les statuts d'information sur la base de
données tels que les entêtes des fichiers de base de données. Ceci est fait lors d'un
événement de check point tel qu'une rotation des logs. Les changements dans le
buffer de cache de la base de données sont alors écrits de manière permanente
dans les fichiers de données.
En plus de ces process obligatoires, on trouve un ensemble de process optionnels :
Recoverer (RECO)
Archiver (ARCn)
Lock (LCKn)
Dispatcher (Dnnn)
Shared Server (Snnn)
Parallel Query Slaves (Pnnn)
Page 10
29/06/2006
1.3.4. Fichiers de la base de données
Une base de données Oracle a une structure logique et physique. Entendons par
structure physique que les fichiers contenu dans la base de données ont une réelle
existence (ex : fichiers de données).
Pour sa part, la base de données Oracle est constituée de trois types de fichiers :
• Les fichiers de données contenant les données des blocs de données qui
sont modifiées par les transactions courantes, le dictionnaire de données, les
objets utilisateurs.
• Les fichiers de redo log contenant un enregistrement des changements qui
ont été fait sur la base de données, pour avoir la possibilité de revenir en
arrière en cas de dysfonctionnement. Une base Oracle contient au moins
deux groupes de redo log chacun contenant au moins un fichier de redo log.
Pour renforcer leur tolérance à une panne de disque dur, Oracle supporte les
fichiers de redo log multiplexés. On peut ainsi maintenir une ou plusieurs
copies de fichiers de redo log sur différents disques (On parle de fichiers
mirrorés).
• Les fichiers de contrôles contenant les informations nécessaires pour
maintenir et vérifier l’intégrité des données de la base. Une base de données
Oracle nécessite au moins un fichier de contrôle, il est toutefois possible de
les mirrorer sur plusieurs disques dur.
1.3.5. Fichiers relatant à la Base de données
Ce sont les fichiers qui ne font pas partie de la base de données mais qui sont
utilisés par le serveur Oracle pour des opérations telles que le démarrage d'une
instance ou l'authentification des utilisateurs. Il existe trois types de fichiers :
• Les fichiers de paramètre (Parameter File) : Il va définir les
caractéristiques de l'instance. Lors du démarrage d'une instance, le serveur
Oracle va lire les paramètres d'initialisation du fichier de paramètres. On
retrouve des informations telles que le nom de la base de données, la taille
de la mémoire à allouer, le nom des fichiers de contrôle ainsi que les autres
paramètres système.
• Le fichier de mots de passe (Password File) : Il est utilisé pour
authentifier les utilisateurs privilégiés.
• Les fichiers de redo log archivés (Archived Redo Log Files) : Ils
contiennent des copies off line des fichiers de redo log. Ils sont utilisés lors
d'une récupération suite à une défaillance d'un média. Les fichiers de redo
log sont sauvés lorsqu'ils sont pleins, cette fonctionnalité n'est utilisée que
lorsque la base de données est en mode "ARCHIVELOG".
Page 11
29/06/2006
1.4. Traitement de requêtes
1.4.1. Etapes lors du traitement d'une requête
Lorsqu'un utilisateur lance une déclaration ou une requête SQL, le process
utilisateur l'envoie au process serveur qui la traite.
Ce traitement est découpé en trois étapes :
Parcours (Parse) :
Le process serveur reçoit la requête, analyse la syntaxe et vérifie les privilèges de
l'utilisateur pour les objets référencés à accéder.
La section de mémoire du pool partagé de la SGA est utilisée pour compiler la
requête et créer un arbre de parcours.
Le statut de réussite ou non de l'analyse est renvoyé au process utilisateur.
Exécution (Exécution) :
Préparation de la récupération des données.
Si l'ordre SQL est un UPDATE ou un DELETE, les lignes affectées sont
verrouillées par le process serveur pour être rendues non accessibles aux autres
utilisateurs.
Récupération des données (Fetch) :
Les données sont récupérées et envoyées au process utilisateur. Selon la quantité
de mémoire disponible, un ou plusieurs fetch peuvent être nécessaires.
1.4.2. Pool partagé (Shared Pool)
Le pool partagé est une zone mémoire faisant parti de la SGA et dont la taille doit
être définie par le DBA. Le Shared Pool peut être retaillée dynamiquement avec la
commande :
ALTER SYSTEM
SET SHARED_POOL_SIZE = 128M;
Nous allons ici voir les différentes composantes de cette zone utilisée par le
process serveur pour traiter les requêtes.
On trouve dans le pool partagé :
Le cache de librairie (Library Cache) :
Contient les informations sur les requêtes SQL et/ou PL/SQL récemment utilisées.
Le plan d’exécution de ces requêtes est également stocké ainsi que l’arbre de
parcours et le texte des requêtes.
Les verrous et les handles sur le cache de librairie sont également consignés. Le
cache de librairie est composé de deux structures : la zone partagée SQL et la zone
partagée PL/SQL
Le cache du dictionnaire de données (Data Dictionary Cache) :
Page 12
29/06/2006
Contient des informations les plus récemment utilisées sur le dictionnaire de
données, les objets de la base de données, sa structure et la définition des
colonnes. On trouve également les utilisateurs valides, leur mot de passe et leurs
privilèges. Les informations du dictionnaire de données sont mises en cache
lorsque elles sont demandées par la base de données. Ceci permet d’augmenter la
rapidité d’accès aux données.
1.4.3. Buffer de Cache de la base de données (Database Buffer
Cache)
Lorsqu’une requête est exécutée, le process serveur consulte le database buffer
cache (Compris dans la SGA) pour les blocs de données requis par la requête.
Le DBA doit configurer la taille de cette zone mémoire. Le buffer de cache est
composé de trois caches indépendants :
• DB_CACHE_SIZE : Ne peut être mis à 0. Gère la taille du buffer par
défaut
• DB_KEEP_CACHE_SIZE : Gère la taille du keep buffer cache, utilisé
pour stocker les blocs dans la mémoire susceptible d’être réutilisés.
• DB_RECYCLE_CACHE_SIZE : Gère le taille du recycle buffer cache,
employé pour supprimer les blocs de mémoire réutilisé qui ont subit peu de
changement.
• DB_CACHE_ADVICE (ON, OFF, READY) : Permet d’activer les
statistiques qui prédisent le comportement de la base lorsqu’on modifie la
taille du cache. Les résultats sont consultables à l’aide de la vue
V$DB_CACHE_ADVISE.
Le database buffer cache contient des blocs de données lus dans les fichiers de
données. Cela permet au process serveur d’accéder plus rapidement aux données,
cette zone comporte les caractéristiques suivantes :
Le database buffer cache contient les données les plus récemment et fréquemment
utilisées. Il contient des blocs de données modifiées et non modifiées datés selon
un algorithme Oracle (LRU) pour mettre à jour le buffer. La taille de chaque
buffer du buffer cache est égale à la taille d’un bloc Oracle et spécifié par le
paramètre DB_BLOCK_SIZE.
1.4.4. Buffer de Redo Log
Le buffer de redo log enregistre les changements faits lors d’une requête DML.
Ces caractéristiques sont les suivantes :
• Il fait parti de la SGA.
• Sa taille est définie par le paramètre LOG_BUFFER et doit être définie par
le DBA.
Page 13
29/06/2006
• Il se compose d’entrées qui contiennent les blocs changés, la position du
changement et la nouvelle valeur.
• Il n’identifie pas le bloc où les changements sont faits, c'est-à-dire qu’il
traite de manière similaire les blocs de données, d’index ou de segments de
ROLLBACK.
• Son utilisation est séquentielle et circulaire. Il est renouvelé lorsqu’il est
plein et que les entrées ont été enregistrées dans les fichiers de redo log online.
1.4.5. Program Global Area (PGA)
Lorsque qu’un process serveur est créé, ou un process d’arrière plan, la base de
données Oracle alloue une zone globale de programme (PGA Program Global
Area ou bien Process Global Area) dans la mémoire. C’est un buffer mémoire qui
contient les données et les informations de contrôle pour ce process serveur.
Elle contient pour un serveur dédié :
Une zone de tri (Sort area) : Utilisé pour stocker, si nécessaire, les résultats
intermédiaires lors du tri.
Des informations de session : Contient les privilèges utilisateurs pour la session
en cours.
Un état de curseur (Cursor State) : Etat de l’étape dans l’exécution des
éventuels curseurs de la session. Un curseur est un pointeur sur la mémoire associé
à une requête SQL donnée. C’est une zone de travail utilisé pour stocker le résultat
de la requête.
Un espace de pile (Stack Space) : Contient les variables de session et les arrays.
Dans la version 9i, de nouveaux paramètres dynamiques de gestion de la PGA sont
apparus. Par exemple, PGA_AGGREGATE_TARGET définit la taille maximale
que peut atteindre la PGA totale allouée à toute une instance. La taille total de la
PGA est inférieur au PGA_AGGREGATE_TARGET en mode auto de
WORKAREA_SIZE_POLICY.
1.5. Traitement de requêtes DML
1.5.1. Phases d'exécution d'un requête DML
Les requêtes de manipulations de données (DML), tel que les UPDATE, DELETE
ou INSERT, sont utilisées pour manipuler les données. Comprendre leur exécution
permet de créer le data buffer cache et les segments de ROLLBACK appropriés.
Le traitement d’une requête DML se compose de deux phases :
Parcours (Parse) : Contrôle des erreurs et placement dans une mémoire partagée
SQL.
Page 14
29/06/2006
Exécution : Si la phase de parcours s’est effectuée avec succès, l’exécution se fait
en plusieurs étapes.
• Lecture des blocs de données et de ROLLBACK dans le database buffer
cache.
• Mise en place de verrous sur les données qui vont être changées.
• Ecriture de l’image avant dans les segments de roll back et enregistrement
des changements du buffer cache dans le redo log buffer pour protéger
l’image avant en cas de défaillance.
• Finalement, les données sont enregistrées dans le buffer cache et les
changements sont également enregistrés dans le redo log buffer protégeant
ainsi l’image après.
Les blocs de données altérées dans le buffer cache sont marqués comme "sales
(Dirty)", c'est-à-dire qu’ils ne correspondent plus aux blocs dans les fichiers de
données.
1.5.2. Segments de Rollback
Les segments de Rollback sont utilisés pour sauver les données lors d’une requête
DML afin de les restaurer en cas d'annulation de la transaction ainsi que pour
empêcher à d’autres transactions de voir les données en cours de modification.
Ces segments ne sont pas visibles par un utilisateur.
Une base de données contient un ou plusieurs segments de Rollback. Le serveur
Oracle assigne un segment de Rollback à chaque transaction. Les segments de
Rollback peuvent permettre de récupérer des données non commitées (validées)
Page 15
29/06/2006
lors d’une transaction. Ils permettent également de récupérer un état consistant de
la base de données en cas de défaillance système.
Les segments de Rollback sont contenus dans les fichiers de données et sont lus
dans le database buffer cache si nécessaire.
1.5.3. Database Writer (DBWn)
Ce process d’arrière plan écrit les données du database buffer cache vers les
fichiers de données sur le disque.
Ces blocs de données sont écrits lorsque certains évènements se produisent tel que:
• L’écriture a lieu lorsque le nombre de buffers « sales » atteint un seuil, cela
permet de libérer des buffers dans le database buffer cache.
• L’écriture se produit lorsque qu’un process serveur ne trouve plus de buffer
libre après avoir recherché un certain nombre de buffers.
• L’écriture s’effectue lors d’un timeout, par exemple lorsque le DBWn reste
inactif plus de trois secondes. Le DBWn recherche alors des buffers «sales»
selon l’algorithme LRU ou bien écrit la totalité si la base de données est
inactive.
• Le DBWn se déclenche lorsqu’un check point est atteint, cela se produit par
exemple lors de l’arrêt de la base de données.
• Lorsqu’un tablespace temporaire ou normal est mis offline.
• Lorsqu’un tablespace est mis en lecture seule.
• Lorsqu’une table est tronquée ou supprimée.
• Lors d’un timeout.
Page 16
29/06/2006
1.5.4. Log Writer (LGWR)
Le Log Writer écrit séquentiellement des entrées du redo log buffer vers les
fichiers de redo log. Le process LGWR écrit lorsque l’un des quatre événements
suivants se produit :
• Lorsque le buffer de redo log est plein à un tiers de sa capacité.
• Lorsqu’un timeout se produit, par exemple lors d’une inactivité de plus de
trois secondes.
• Avant que le process DBWn écrive les données du database buffer cache
vers les fichiers de données.
• Lorsqu’une transaction utilisateur est commitée.
• Toutes les 3secondes.
LGWR peut demander à DBWn d’écrire dans les fichiers de données.
1.6. Traitement d un commit
1.6.1. Numéro de changement du système (SCN)
La base de données Oracle assigne un SCN (System Change Number) à chaque
transaction qui est commitée dans le but de l’identifier de manière unique.
Ce numéro unique est enregistré dans les segments de Rollback ainsi que dans les
fichiers de redo log.
Il est également utilisé comme une marque temporelle (Timestamp) pour
permettre à la base de données de synchroniser les données. Les événements sont
organisés dans un ordre temporel au sein d’une instance et entre instances.
Page 17
29/06/2006
Il permet au serveur Oracle de lire les données de manière consistante en faisant
abstraction de la date système du système d’exploitation lors de la restauration de
1.6.2. Traitement d'un COMMIT : Etapes
Une transaction doit être écrite de manière permanente après le traitement de celleci. Pour cela un COMMIT est réalisé. Nous allons voir les étapes qui constitue
cette action de commit :
• Un process serveur enregistre une ligne COMMIT accompagnée de son
SCN dans le buffer de redo log.
• Le process LGWR écrit les entrées du buffer de redo log dans les fichiers
de redo log en commençant par la ligne de COMMIT (LGWR confirme la
réussite du commit seulement après que les buffer de redo log soit écrit sur
le disque.).
• Le process serveur enregistre les informations indiquant que la transaction
est terminée. Les ressources verrouillées dans les tables et les
enregistrements sont alors libérées.
• Le process serveur informe le process utilisateur de la fin du COMMIT.
Un commit réalisant ces étapes est appelé un commit rapide (Fast Commit), on
remarquera que seul le buffer de redo log est écrit sur le disque. Les buffers sales
sont écrits dans le fichier de données de manière indépendante par le process
DBWn.
Une seule écriture sur le disque est donc nécessaire pour réaliser un COMMIT. Si
plusieurs process utilisateurs réalisent un commit simultanément, le serveur Oracle
rassemble les commits et n’écrit qu’une seule fois.
Page 18
29/06/2006
2. Outils d'administration
2.1. Utilitaires administratifs
2.1.1. Utilitaires d'administration de base de données
Oracle Universal Installer :
L’installateur Universel est un installateur Java utilisé pour installer Oracle9i, les
outils Oracle et les utilitaires.
Il peut installer des logiciels à partir d’un CDROM ou d’Internet, détecter les
dépendances entre les différents composants. Il détecte le langage courant du
système d’exploitation ou bien utilise le langage par défaut.
Il est possible de spécifier différents répertoires principaux (Le ORACLE_HOME)
pour permettre d’installer plusieurs versions d’un même produit. L’installation
peut être guidé par des assistants ou permet d’utiliser des packages standard
nécessitant un minimum de réponses.
Il est également possible de le lancer en mode silencieux, dans ce cas, un fichier
de réponse est utilisé pour remplacer les réponses aux différentes questions lors de
l’installation. Le mode silencieux est utilisé lorsqu’il n’y a pas de terminal
graphique ou lorsque l’on veut que l’utilisateur n’a rien à faire pour l’installation.
La syntaxe de lancement de la commande varie en fonction du système
d’exploitation.
Un fichier de log est créé lors de l’installation et contient l’ensemble des étapes et
les résultats.
Une liste des produits installés est maintenue en cas de désinstallation de l’un
d’entre eux.
Les outils de post-installation sont également lancés si besoin est. Par exemple,
après l’installation d’OEM (Oracle Enterprise Manager), l’assistant de
configuration de base de données est lancé.
Oracle Database Configuration Assistant :
Cet assistant permet de créer une base de données, configurer les options de la
base de données, supprimer une base de données, gérer les templates.
Outils pour la création des fichiers de mots de passe :
La commande orapwd permet de créer un fichier de mot de passe.
Page 19
29/06/2006
Ensuite, il suffit de mettre REMOTE_LOGIN_PASSWORDFILE à EXLUSIVE
dans le fichier de paramètre. Puis, ajouter les utilisateurs au fichier de mot de
passe et de leur attribuer des privilèges.
SQL* Plus :
SQL* Plus est un outils Oracle qui permet de manipuler et interagir avec la base
de données. Une présentation plus complète de SQL* Plus est disponible dans le
module SQLP.
Oracle Enterprise Manager : C’est un outil important permettant, via une
interface graphique, d’administrer, de contrôler et de tuner une ou plusieurs bases
de données localisées sur un ou plusieurs serveurs.
2.1.2. Optimal Flexible Architecture (OFA)
OFA est l’architecture standard qu’il est recommandé d’utiliser dans une base de
données Oracle. Les trois règles importantes pour respecter cette architecture sont
:
• Etablir une structure de répertoires, où n’importe quel fichier de base de
données peut être enregistré sur n’importe quel espace disque.
• Séparer les objets avec un comportement différent sur différents
tablespaces.
• Augmenter les performances de la base de données en séparant les
composants de la base de données sur des disques différents.
OFA organise donc la base de données en fonction des types de fichiers et de leurs
utilisations. Les fichiers binaires, de contrôles, de logs et administratifs peuvent
être séparés sur des disques différents.
L’administration en sera simplifié et les performances grandement améliorées.
L’arborescence ci-dessus montre une structure de stockage selon le modèle OFA.
Page 20
29/06/2006
2.2. Oracle Entreprise Manager (OEM)
2.2.1. Architecture d'OEM : Vue d'ensemble
Oracle Entreprise Manager fournit un outil graphique de configuration système
pour administrer une ou plusieurs bases de données.
OEM se présente sous la forme d’une architecture trois tiers, elle comprend :
• La console est un outil graphique, utilisés par les DBA pour administrer
une ou plusieurs bases de données à partir d’une même console. La console
OEM comporte des menus, des barres d’outils et elle peut intégrer des
outils provenant d’autres fabricants. Elle permet d’accéder à un ensemble
d’outils tel que la planification de taches, la gestion des évènements, la
recherche de services sur le réseau et la sécurité.
• Les composants OMS forment le second tiers, les données de ces
composants sont en effet stockées dans le repository OEM. Le repository
OEM est un jeu de tables dans la base de données contenant les données
système, les données applicatives et l’état des n uds administrés sur
l’environnement Oracle. La base de données stockant le repository OEM
doit être accessible à la console OEM. Un repository est associé à des
utilisateurs et non à une machine, ainsi, il devient indépendant de sa localité
et peut être accédé de partout. Un repository OEM distinct peut être associé
à chaque utilisateur OMS peut donc effectuer toutes les taches
administratives, et ce de manière distribuée, de plus, plusieurs OMS
peuvent être mis en place et agir en load balancing, ce qui augmente la
tolérance de panne
Page 21
29/06/2006
• Les Noeuds constituent la troisième couche de l’architecture qu’un
utilisateur va chercher à administrer. Ces noeuds sont contrôlés par les «
intelligent agents ». Un « intelligent agent » est un process qui s’exécute sur
le noeud distant du réseau et qui permet de l’administrer à distance.
2.2.2. Composants de la console OEM
La console OEM est l’interface graphique utilisateur de l’application OEM, elle
contient un ensemble de composants qui permettent à un ensemble de DBA
d’administrer une ou plusieurs base de données dans un environnement Oracle.
Elle se compose de menus permettant de lancer des applications d’administrations,
des outils d’accès et de services et l’accès à l’ensemble des fonctionnalités de la
console OEM.
Elle contient un ensemble d’icônes présentant sous forme de palettes les différents
outils, et donnant un accès similaire aux éléments des menus de manière plus
rapide.
Une fenêtre de navigation apporte une vue hiérarchique des différents noeuds du
réseau, elle permet de visualiser l’ensemble des services Oracle à travers le réseau
ainsi que les objets qu’ils contiennent.
Les objets réseaux sont également représentés sur une carte graphique qui permet
de les situer géographiquement.
La console OEM comprend également la gestion des taches planifiées (Job) qui
permettent de lancer à distance des taches concernant les « listeners », les bases de
données ou bien les hôtes. Un historique et un suivi de l’état des jobs sont
également disponibles.
On peut également consulter les évènements systèmes sur les différents noeuds et
selon les critères que l’on souhaite. Le DBA peut alors être contacté par email ou
autres. Certains évènements peuvent faire l’objet de jobs correctifs qui seront
lancés au déclanchement de celui-ci.
2.2.3. Services communs d'OEM
OEM comporte un ensemble de services permettant au DBA d’administrer les
serveurs Oracle et leurs bases de données.
Les principaux services fournis par les OMS sont les suivants :
Le service de taches panifiées (Job Service) :
Il gère les jobs programmés et permet donc d’automatiser des taches répétitives.
Le service de gestion des évènements (Event Service) :
Il permet de contrôler les évènements systèmes survenant sur l’ensemble des
serveurs Oracle du réseau, il permet de contrôler des limites applicatives et
Page 22
29/06/2006
systèmes tel que l’espace occupé par les fichiers de données, la charge CPU ou
bien des pertes de disponibilité d’un service.
Il peut, lors d’un événement donné, déclencher des jobs de récupération ou autres.
Le service de découverte (Discovery Service) :
C’est un assistant permettant de découvrir sur le réseau les différents services tel
que les bases de données, les serveurs Web, les listeners, les machines, les «
parallel Servers » et les serveurs de vidéo.
Le service de sécurité (Security Service) :
Il permet de contrôler l’accès aux services Oracle ainsi qu’aux noeuds du réseau.
Un super administrateur peut également gérer les différents administrateurs et
leurs privilèges.
Les authentifications sont encodées dans le repository OEM et les utilisateurs
doivent spécifier leur identité pour accéder à chaque ressource à travers la console
OEM.
2.2.4. Configurer OEM
Cette section présente la configuration d’OEM, lors de son installation, installateur
universel lance l’assistant de configuration d’OEM, mais il est également possible
de le lancer à nouveau lors de la création d’un repository supplémentaire.
Les étapes se découpent comme suit :
Création du repository OEM : L’assistant de configuration demande l’hôte, le
port, et le SID du lieu ou va être installé le repository.
Lancement du service OMS : La seconde étape consiste à lancer le service OMS,
il démarre automatiquement au démarrage de Windows ou bien il peut être
démarré manuellement.
Lancement de la console OEM : La console OEM peut être lancé via le menu «
Démarrer ». Il est alors possible de se connecter au repository OEM et de
découvrir automatiquement (Ceux ou l’intelligent agent est lancé) ou
manuellement les différents noeuds et services présents sur le réseau.
Configuration de la sécurité : La sécurité appropriée doit être mise en place pour
contrôler l’accès aux différents noeuds et services du réseau. L’authentification
pour un utilisateur doit être configurée pour chaque objet à accéder.
Travail sur une base de données : La dernière étape consiste à choisir une base
de données via l’explorateur et s’authentifier pour pouvoir l’administrer.
2.3. Package d'administration
Page 23
29/06/2006
2.3.1. Pack de management DBA
Le pack de management DBA est un ensemble d’outils utilisés pour
l’administration des bases de données. Il se compose de cinq applications et de
deux jeux d’utilitaires et d’assistants :
• Instance Manager : Cet outil permet de monter, fermer et surveiller une
base de donnée
• Security Manager : Il permet de contrôler l’accès aux services Oracle ainsi
qu’aux noeuds du réseau. Un super administrateur peut également gérer les
différents administrateurs et leurs privilèges.
• Storage Manager : Permet de surveiller les tablespaces, fichiers de données,
segments de rollback.
• Schema Manager : Il permet de créer et maintenir des objets comme les
tables, indexes et vues.
• SQL* Plus Worksheet : C’est une application en ligne de commandes
permettant de lancer des requêtes SQL, du code PL/SQL ou encore des
commandes SQL*Plus.
Les outils et les assistants de sauvegarde Oracle : Ils permettent de sauvegarder,
restaurer ou bien recouvrer une base de données. On peut également gérer les
fichiers de redo log grâce à ces outils. On lance ces outils à partir de la console ou
du Gestionnaire de Schéma.
Les outils et assistants de gestion des données : Ils aident au chargement et
l’organisation des données dans les bases de données. Ils permettent également le
transfert des données à partir et vers une base de données Oracle. On lance ces
outils à partir de la console ou du Gestionnaire de Stockage.
2.3.2. Packs de management supplémentaires
OEM peut intégrer dans sa console trois outils administratifs supplémentaires :
Le Pack de Diagnostic : Il fournit des utilitaires d’audit et de monitoring des
bases de données, il devient possible de collecter et d’inspecter des performances
spécifiques selon des statistiques aidant au paramétrage fin d’une base de données.
Le Gestionnaire de Performances Oracle permet de réaliser cela en temps réel et
fournit des vues graphiques sur la performance de la base de données et du
système.
Oracle TopSessions permet de lister l’ensemble des sessions connectées au serveur
Oracle. On peut également voir les détails d’une session et y mettre fin.
Page 24
29/06/2006
Le planificateur de capacité permet de collecter des données et de stocker un
historique des informations sur la base de données pour parer à l’augmentation de
la capacité requise.
Le Visualisateur de données de trace Oracle permet de suivre et de programmer
les informations de traçages de la base de données et de Net8.
Le Pack de Tuning : Il se compose d’un ensemble d’outils visant à améliorer les
performances d’une base de données.
L’analyseur SQL permet d’analyser et d’éditer des requêtes SQL pour augmenter
leurs performances.
Le Gestionnaire de Tablespace permet de monitorer et contrôler l’espace de
stockage. Il fournit un ensemble d’informations sur les tablespaces et leurs
segments. On peut défragmenter l’espace occupé et réorganiser les données.
Oracle Expert permet de tuner et d’optimiser le système de manière très fine.
Le Pack de Gestion du Changement : Il se compose d’utilitaires utilisés pour
contrôler le changement de la définition des objets de la base de données.
L’application de Capture permet de capturer l’image d’un objet à un instant donné.
L’application de Différentiel permet de comparer les différences entre la définition
d’objet pour deux base de données ou selon un modèle.
Les Objet de Changement rapide et de modification permettent de propager des
changements aux objets d’une ou plusieurs bases de données.
L’application de Gestion des Plans permet de centraliser l’accès à tous ces outils.
Page 25
29/06/2006
3. Gérer une Instance Oracle
3.1. Authentification et privilèges
Les utilisateurs administrateurs de la base de données sont responsables de la
gestion et de l’administration du serveur Oracle. Des privilèges particuliers sont
requis pour permettre de faire ces taches.
Deux comptes utilisateur DBA son créés automatiquement et ont le rôle DBA :
Le compte SYS : Créé lors de l’installation d’Oracle avec tous les privilèges
systèmes. Mot de passe par défaut : change_on_install, à changer après
l’installation. Le schéma de SYS stocke toutes les tables et les vues du dictionnaire
de base de données.
Aucun utilisateur ne peut modifier ou créer de table dans ce schéma.
Le compte SYSTEM : Créé lors de l’installation d’Oracle avec tous les privilèges
systèmes. Mot de passe par défaut : manager à changer après l’installation.
Le schéma de SYSTEM stocke les tables et les vues administratives ainsi que des
informations administratives propres à certains produits Oracle supplémentaires.
3.2. Fichiers de paramètres
3.2.1. Paramètres présents dans le fichier de paramètre
Une base de données Oracle devient accessible aux utilisateurs lorsque le DBA
démarre l’instance et ouvre la base de données. Pour démarrer une instance,
Oracle lit le fichier d’initialisation. Ces fichiers sont au nombre de deux (le dernier
est une nouveauté de la 9i) : le PFILE et le SPFILE. Le PFILE fait communément
référence au fichier init<SID>.ora et le SPFILE (fichier binaire) fait référence au
fichier spfile<SID>.ora où SID est le nom de l’instance.
Le fichier de paramètre est un fichier texte contenant la liste des paramètres de
démarrage de l’instance.
3.2.2. Le PFILE (initSID.ora)
Sous Windows NT, ce fichier se trouve par défaut dans le répertoire
%ORACLE_HOME%\database et contient un paramètre IFILE qui fait référence
à
un
fichier
plus
complexe
situé
dans
le
répertoire
%ORACLE_HOME%\admin\<SID>\pfile.
Sous UNIX, on peut le trouver dans le répertoire $ORACLE_HOME/dbs.
Page 26
29/06/2006
Ce fichier est lu lors du démarrage de l’instance, on peut l’éditer avec n’importe
quel éditeur de texte et le redémarrage de l’instance est nécessaire pour que les
changements prennent effet. Il est préférable de faire une copie de ce fichier sur
l’ordinateur où se trouve OEM s’il en existe un.
Parmi les paramètres du fichier de paramètre, on trouve le nom de la base de
données pour laquelle l’instance est démarrée.
Les paramètres contrôlent les performances de la base de données ainsi que la
quantité de mémoire utilisée par les différentes composantes de la SGA.
On peut également définir certains attributs physiques de la base de données au
moment de sa création telle que la taille des blocs de données.
On trouve également dans ce fichier le nom et le chemin des fichiers de contrôle,
des fichiers de log archivés et des fichiers de trace de la base de données.
3.2.3. Le SPFILE (spfileSID.ora)
Le spfile est un fichier binaire de paramètres dynamiques qui est géré par le
serveur Oracle. Il se situe dans le même répertoire que le initSID.ora et contient
aussi les mêmes données. Si le fichier spfileSID.ora existe, il est prioritaire par
rapport au PFile. En effet, au démarrage de l’instance le serveur essayera de lire le
spfile plutôt que le pfile, le pfile sera lu seulement en cas d’échec de la lecture du
spfile.
Page 27
29/06/2006
Remarque : Le contenu du spfile est visible dans la vu dynamique
V$SPPARAMETER et non pas V$PARAMETER qui est utilisé par le pfile.
3.2.4. Règles pour les valeurs de paramètre
Un ensemble de règles régissent les paramètres compris dans le fichier de
paramètre :
• La plupart des paramètres sont optionnels.
• Leur ordre n’est pas important.
• Le format pour définir un paramètre est de la forme nom_de_paramètre =
valeur et s’écrit sur une ligne.
• La plupart des paramètres ont une valeur par défaut.
• Si un paramètre comprend des espaces ou des tabulations, il doit être mis
entre doubles quotes.
• Certain paramètres tel que CONTROL_FILE peuvent prendre plusieurs
valeurs, elles doivent être mises entre parenthèses et séparées par des
virgules.
• Des lignes de commentaires peuvent être incluses dans le fichier et doivent
commencer par le symbole #.
• Le mot clé IFILE est utilisé pour inclure d’autres fichiers à un fichier de
paramètre.
• Si le système d’exploitation est sensible à la casse, le fichier de paramètre
le devient également.
3.2.5. Paramètres essentiels
La plupart des paramètres sont optionnels, cependant certains paramètres sont au
contraire essentiels pour l’instance Oracle.
La liste suivante les présente :
DB_NAME : Identifiant de la base de données.
DB_CACHE_SIZE : Ne peut être mis à 0. Gère la taille du buffer par défaut.
DB_KEEP_CACHE_SIZE : Gère la taille du keep buffer cache, utilisé pour
stocker les blocks dans la mémoire susceptible d’être réutilisés.
DB_RECYCLE_CACHE_SIZE : Gère le taille du recycle buffer cache, employé
pour supprimer les blocs de mémoire réutilisé qui ont subit peu de changement.
DB_BLOCK_SIZE : Taille d’un bloc de données spécifié lors de la création de la
base de données. Ne peut être changé après la création.
COMPATIBLE : Version du serveur avec laquelle l’instance pourra être
compatible.
CONTROL_FILES : Spécifie le nom des fichiers de contrôle de la base de
données.
SHARED_POOL_SIZE : Spécifie la taille du pool partagé en bytes.
Page 28
29/06/2006
BACKGROUND_DUMP_DEST : Spécifie le répertoire ou le process de fond de
taches écrit les fichiers de trace et les fichiers de log d’alertes.
USER_DUMP_DEST : Spécifie le lieu où les fichiers de trace utilisateurs sont
crées.
3.2.6. Paramètres communément modifiés
Les paramètres le plus souvent modifiés par le DBA pour une instance donnée
sont les suivants :
IFILE : Permet d’inclure un autre fichier de paramètres dans le fichier courant.
Peut être utilisé jusqu’à trois niveaux.
LOG_BUFFER : Spécifie le nombre de bytes qui sont alloués pour le buffer de
redo log dans la SGA.
MAX_DUMP_FILE_SIZE : Spécifie la taille maximale en bloc des fichiers de
trace.
PROCESSES : Définit le nombre maximum de process du système d’exploitation
pouvant être simultanément connecté à l’instance.
SQL_TRACE : Permet d’activer ou non l’utilitaire de trace SQL pour toutes les
sessions utilisateurs.
TIMED_STATISTICS : Permet d’activer ou non la datation des événements
dans les fichiers de trace et les écrans de monitoring.
3.3. Démarrage et arrêt d'une instance
3.3.1. Etapes de démarrage d une instance
Le démarrage d’une instance se fait en plusieurs étapes. Elles sont au nombre de
trois et se présentent tel que suit :
• Le démarrage de l’instance,
• Le montage de la base de données
• Et l’ouverture de la base de données.
Le démarrage de l’instance est la première étape, on parle de mode NOMOUNT.
On démarre ce mode lors de la création de la base de données ou la régénération
des fichiers de contrôle.
C’est à ce moment que le serveur va essayer de lire les fichiers de paramètres dans
l’ordre suivant :
• le spfileSID.ora. Si il n’est pas trouvé alors,
• le spfile.ora (fichier de paramètres crée automatiquement avec une base de
données). Sinon,
• le initSID.ora
Page 29
29/06/2006
La SGA est allouée et les process démarrés. Les fichiers de trace et d’alertes sont
également ouverts.
La seconde étape consiste à monter la base de données. C’est le mode MOUNT.
La base de données n’est pas encore ouverte et donc non accessible.
Ce mode est utilisé pour certaines taches de maintenance de la base de données.
A ce moment, la base de données est associée à une instance démarrée, le serveur
Oracle localise les fichiers de contrôle et les ouvre.. Ces fichiers sont alors lus
pour obtenir le nom et le statut des fichiers de données et de redo log.
La troisième étape de démarrage est l’ouverture de la base de données. On
l’appelle également le mode OPEN ou mode normal de la base de données. A ce
moment, un utilisateur valide de la base de données peut se connecter et accéder
aux données.
Lors de cette étape finale, le serveur Oracle vérifie que les fichiers de données et
de redo log puissent être ouverts. Si l’ouverture de l’un d’entre eux échoue, une
erreur est renvoyée et la base de données n’est pas ouverte.
La consistance de la base de données est également vérifiée pour s’assurer que les
fichiers de données soient bien synchronisés.
Si nécessaire, le process d’arrière plan SMON lance la restauration d’instance. Les
derniers checkpoints sont identifiés, les fichiers de Rollback et les données
utilisateurs sont mises à jour, les transactions non commitées font l’objet d’un
rollback
3.3.2. Changer la disponibilité de la Base de données
Un DBA peut démarrer une instance Oracle dans l’un des trois modes
NOMOUNT, MOUNT et OPEN. Ce mode peut être changé de l’un à l’autre
lorsque l’instance à été lancée (de NOMOUT vers MOUNT puis VERS OPEN).
Il est possible de le changer soit grâce à la commande ALTER DATABASE ou
grâce au Manager d’Instance Oracle.
En ligne de commande et en mode NOMOUT, il est possible de taper ceci :
ALTER DATABASE [MOUNT| OPEN]
Il est possible d’agir sur le mode de la base de données à l’aide du Manager
d’Instance Oracle. On peut par exemple changer l’état de la base de données de
NOMOUNT à MOUNT. Cela se fait à l’aide du menu Base de données.
Page 30
29/06/2006
3.3.3. Etapes d'arrêt d'une instance
Il y a trois étapes dans le process d’arrêt d’une instance et de la base de données :
La base de données est d abord fermée : Lors de cette étape, le serveur Oracle
écrit tous les changements des buffers caches dans les fichiers de données. Tous
les buffers de redo log sont écrits dans les fichiers de redo log en ligne.
Ces mêmes fichiers sont ensuite fermés.
La base de données devient indisponible aux utilisateurs mais les fichiers de
contrôle restent ouverts.
Elle est ensuite démontée : La base de données est ensuite démontée de son
instance. Les fichiers de contrôle sont fermés à leur tour.
instance est finalement arrêtée : Les fichiers de traçage et d’alerte sont
fermés. La SGA est désallouée de la mémoire et les process de tâche de fond sont
terminés.
3.3.4. Modes d'arrêts
Un DBA peut fermer une base de données dans l’un des quatre différents mode
disponibles. Ces modes sont : normal, transactionnel, immédiat et abandon.
Le mode normal est le mode par défaut, les connexions à la base de données
deviennent impossibles, toutefois, le serveur Oracle attend que les utilisateurs
connectés se déconnectent de la base de données. Une fois tous les utilisateurs
déconnectés, le serveur Oracle démonte et ferme la base de données puis
l’instance. Dans ce mode de fermeture, une restauration de l’instance ne sera pas
nécessaire au redémarrage.
Dans le mode transactionnel, les clients ne peuvent perdre leur travail. Lors de
l’utilisation de ce mode, aucun utilisateur ne peut lancer une nouvelle transaction.
Les clients sont déconnectés lorsque leurs transactions en cours se terminent. La
base de données est ensuite immédiatement fermée. La restauration d’instance ne
sera pas nécessaire dans ce mode également.
Le mode d arrêt immédiat entraîne l’arrêt immédiat des requêtes SQL en cours,
les utilisateurs sont déconnectés sans attente. Le serveur Oracle rollback annule les
transactions actives. Une restauration de l’instance ne sera pas nécessaire.
Le mode abandon (ABORT) est utilisé seulement lorsque les autres modes ne
peuvent fonctionner.
(Ce mode est exécuté lorsque la commande STARTUP FORCE est utilisée).
Les requêtes SQL sont terminées et les utilisateurs déconnectés, les transactions
non commitées ne font pas l’objet d’un rollback. Le prochain démarrage de
l’instance nécessitera une restauration de l’instance par SMON. En mode abandon,
les fichiers ne sont pas fermés.
SHUTDOWN [NORMAL| TRANSACTIONAL | IMMEDIATE |
ABORT]
Page 31
29/06/2006
3.4. Vue dynamique des performances
3.4.1. Caractéristiques des vues dynamiques de performance
Le serveur Oracle maintient un jeu de tables virtuelles qui enregistre l’activité
courante de la base de données. Ces tables sont appelées les tables de
performances dynamiques. Elles sont visibles pour les utilisateurs via les vues
dynamiques de performances. Ces tables appartiennent au DBA et ne sont pas
accessibles à la plupart des utilisateurs. Les vues sont également accessibles au
DBA qui peut donner le droit d’accès à d’autres utilisateurs.
Ces vues sont identifiées avec le préfixe V_$ mais le serveur Oracle créé un
synonyme public avec le préfixe V$.
Les tables sous-jacentes à ces vues sont constamment mises à jour lorsque la base
de données est en cours d’utilisation. Les informations les plus à jours deviennent
alors disponibles à travers ces vues.
Ces vues sont utilisées pour fournir des données relatives aux performances telles
que des informations sur les fichiers de données et les structures de la mémoire.
Lorsqu’une instance est démarrée en mode NOMOUNT, seul les vues lisant des
données de la mémoire sont accessibles.
Lorsque la base de données est en mode MOUNT, les vues lisant les données des
fichiers de contrôle sont alors accessibles. La vue V$FIXED_TABLE montre les
vues dynamiques de performance.
3.4.2. Descriptions des vues dynamiques de performance
Les principales vues accessibles en mode NOMOUNT lisent des données de la
mémoire et sont les suivantes :
V$PARAMETER: Liste les informations sur les paramètres d’initialisation avec
leur nom, leur nombre, leur valeur et leur type.
V$SPPARAMETER : Liste les informations sur les paramètres d’initialisation du
serveur avec leur nom, leur nombre, leur valeur et leur type.
V$SGA : Donne des informations récapitulatives sur la SGA.
V$OPTION : Liste les options installées avec le serveur Oracle.
V$PROCESS : Contient des informations sur les process actifs.
V$SESSION : Donne les informations sur la session courante.
V$VERSION : Liste le numéro de version et les composants du serveur Oracle.
V$INSTANCE : Donne l’état de l’instance courante.
Les vues lisant les données des fichiers de contrôle sont accessibles seulement
lorsque la base de données est montée. Les principales vues sont les suivantes :
V$THREAD : Présente les informations sur les threads des fichiers de contrôle tel
que les informations sur les groupes de redo log.
Page 32
29/06/2006
V$CONTROLFILE : Fournit les noms des fichiers de contrôle.
V$DATABASE : Contient des informations sur la base de données tel que le nom
ou la date de création.
V$DATAFILE : Donne les informations sur les fichiers de données tel que leur
nom, leur statut et d’autres détails.
V$DATAFILE_HEADER : Donne des informations sur les en-têtes des fichiers
de contrôle.
V$LOGFILE : Contient des informations sur les fichiers de redo log en ligne
Page 33
29/06/2006
4.
Procédure de création d une base de Données
La création de la base de données est la première étape dans l’organisation et la
gestion d’un système de base de données.
La création d’une base de données permet à un ensemble de fichiers du système
d'exploitation de fonctionner en tant que base de base de données Oracle.
Indépendamment du nombre de fichiers de données et du nombre d'instances qui
accèdent à la base de données, une base de données ne peut être créée qu'une seule
fois.
Une base de données initiale peut être créée lors de l’installation d’Oracle. Cette
base de données peut être utilisée comme base de données initiale, ou une nouvelle
base de données peut être créée.
Pour créer une nouvelle base de données, il faut tenir compte de la taille des
fichiers de données, des blocs, des tables et des index. L’emplacement des fichiers
de contrôle doit être aussi planifié.
Lors de la création d'une nouvelle base de données, il faut également tenir compte
du jeu de caractères que la base de données utilisera. Une fois la base de données
créée, le jeu de caractères spécifié ne peut plus être changé, sauf si la base de
données est recréée.
4.1. Pré requis nécessaires à la création
Une base de données est créée et gérée par un DBA (Database Administrator). Si
le DBA connaît les conditions préalables à la création d'une base de données, il
pourra créer efficacement une base de données.
• Pour créer une base de données, un DBA doit posséder un compte
privilégié authentifié par le système d'exploitation ou par un fichier de mots
de passe. Un compte privilégié d’un utilisateur défini les actions que cet
utilisateur peut effectuer sur la base de données ou les objets de la base de
données.
• Il doit y avoir suffisamment de mémoire pour démarrer une instance. Ce
qui signifie qu’il doit y avoir suffisamment de mémoire pour que la zone
mémoire global du système (System Global Area SGA), les fichiers
exécutables et les autres processus en arrière plan s'exécutent normalement.
La taille minimale de la SGA des petites bases de données est de 6,5 MB.
• L’espace disque disponible sur la machine doit être suffisant pour recevoir
la base de données planifiée. Le disque doit comporter suffisamment
d'espace de stockage pour stocker les fichiers de contrôle, les fichiers de
données et les fichiers redo log online de la base de données.
Page 34
29/06/2006
4.1.1.
Gérer et sauvegarder les fichiers d une base de
données
Une base de données peut présenter une taille relativement importante et
comporter un grand nombre d'utilisateurs. Aussi, un DBA doit planifier
correctement la structure physique d'une base de données de telle façon que
l’échec d’un disque ne provoque pas l’arrêt de l’instance de la base de données.
• Créer au moins deux fichiers de contrôle et les stocker sur des disques
différents. Si un fichier de contrôle ou un disque sur lequel est stocké un
fichier de contrôle est corrompu, la base de données pourra toujours
accéder à l’autre fichier de contrôle.
• Les fichiers redo log online doivent être organisés en groupes multiplexés.
Un groupe de fichier redo log est constitué des copies identiques des
fichiers redo log. Le multiplexage des groupes de fichiers redo log online
permet au processus Log Writer (LGWR) de continuer d’écrire des entrées
log des membres disponibles dans un groupe si un membre de ce groupe est
indisponible ou corrompu. Le processus LOGWR est un processus d’arrière
plan qui écrit les entrées du cache redo log (redo log buffer) sur le disque.
• Les membres d’un groupe de redo log doivent également être stockés sur
des disques différents. Ainsi si un disque est corrompu, le LGWR et
l’instance de la base de données n’échoueront pas.
• Les fichiers de données contenant des objets de la base de données avec des
durées de vie différentes, telles que les données d’une application et les
données temporaires, doivent être séparés afin
de minimiser la
fragmentation.
• Les fichiers de données dont les données participent à la contention sur le
disque doivent être séparé sur différents disques.
• Les fichiers de données qui contiennent des données avec des
caractéristiques d'administration, différentes doivent être séparés. Par
exemple, les objets avec des besoins d’entrées/sorties concurrents, tels que
les tables et les index, doivent être séparés. Cette séparation garantit au
DBA un bon équilibrage des charges d’entrée/sortie.
4.1.2.
Créer une base de données
Il est possible de créer une base de données à la main avec un script SQL qui
utilise la commande CREATE DATABASE ou tout simplement avec Oracle
Database Configuration Assistant.
Attention : Pendant l’installation d’Oracle Server, le DBCA (interface graphique
utilisateur qui interagit avec Oracle Universal Installer) est lancé par OUI (Oracle
Page 35
29/06/2006
Universal Installer) et permet de réer une base de données par défaut. Il est
possible pour l’utilisateur de ne pas lancer cette option.
Si la structure de la base de données initiale ne remplie pas les besoins, une
nouvelle base de données peut être créée.
Voici les étapes dans la création manuelle d'une base de données :
• Décider d’un nom unique pour l’instance et pour la base de données. Le
nom de l’instance sert à identifier les instances associées à la base de
données, et le nom de la base de données sert à identifier une base de
données spécifique.
• Indiquer le jeu de caractères que la base de données doit utiliser. Ce choix
est très important car une fois configuré, le jeu de caractères ne peut être
changé pour cette base de données.
• Définir les variables du système d'exploitation. Les variables du système
d'exploitation sont définies dans la base de registre. Leur définition
détermine l’instance par défaut, le jeu de caractères de la base de données et
les autres paramètres nécessaires au bon fonctionnement de la base de
données.
• Créer un fichier de paramètres. Ce fichier est nécessaire pour créer et
démarrer une instance. Pour créer un fichier de paramètres, il faut spécifier
la taille des composants de la zone mémoire globale du système (SGA), le
nom de la base de données, les fichiers de contrôle de la base de données et
la taille des blocs de données de la base de données.
• Créer les services Oracle. Quand une base de données est créée, les services
d’Oracle, tel que le service OraHomeTNSListener81 en environnement
Windows NT, sont également créés. Les services d’Oracle préparent une
base de données en vue de son utilisation. Le service
OraHomeTNSListener81 identifie et accepte les demandes de connexion
provenant des applications cliente.
• Créer un fichier de mots de passe. La création d’une base de données
implique la création d’un fichier de mots de passe. Le fichier de mots de
passe contient les mots de passe pour authentifier des utilisateurs privilégiés
autorisés à effectuer des opérations telles que le démarrage et l’arrêt de la
base de données.
• Démarrer une instance sans monter la base de données. Lorsqu'une instance
est démarrée, la SGA est allouée à l’instance indiquée et les processus
d’arrière plan sont démarrés en vue de la création de la base de données.
• Créer la base de données à l’aide de la commande SQL CREATE
DATABASE et en définissant les paramètres facultatifs de la commande.
Ces paramètres servent à spécifier le nombre maximal de fichier, leurs
tailles et le mode de fonctionnement de ces fichiers.
Page 36
29/06/2006
• Exécuter les scripts qui génèrent les vues du dictionnaire de données. Un
dictionnaire de données est un ensemble de tables qui fournissent des
informations sur la base de données à laquelle elles sont associées.
4.2. Environnement du système d exploitation
Oracle utilise des paramètres de configuration pour localiser des fichiers et
spécifier les informations d’exécution de tous les produits Oracle. Ces
informations de configuration sont stockées dans la base de registre du système
d'exploitation.
Pour qu’une instance Oracle fonctionne proprement dans un environnement
Windows NT, il est essentiel de stocker les informations de configuration
adéquates dans la base de registre.
La base de registre Windows NT est une base de données hiérarchique et
centralisée qui stocke les informations de configuration du matérielle et logicielle
d'une machine locale.
Les paramètres de la plupart des produits Oracle sont stockés dans la sous-clé
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE de la base de registre
Windows NT. Les cinq variables de la base de registre sont :
• Pour qu’une instance Oracle fonctionne proprement, il faut préciser dans la
base de registres le chemin d'accès du répertoire racine où Oracle a été
installé. Ce chemin est indiqué dans la variable ORACLE_HOME.
• Le SID (identificateur du système Oracle) de l’instance, à laquelle un
utilisateur se connecte si la chaîne de connexion n’est pas spécifiée, est
stocké dans la variable de la base de registre ORACLE_SID. Le nom de
l'instance doit être unique pour chaque instance qui s'exécute sur une même
machine. La valeur de la variable ORACLE_SID doit comporter un
maximum de quatre caractères sous Windows NT et huit caractères sous
UNIX. Par exemple, si le nom par défaut de l’instance est ORCL, la
variable ORACLE_SID prendra la valeur ORCL.
• Si un jeu de caractères, autre que le jeu de caractères par défaut US7ASCII,
est utilisé pour la création d'une base de données, le nom d’un répertoire
contenant les informations de conversion pour le jeu de caractère choisi est
stocké dans la variable ORA_NLS33. Si la variable ORA_NLS33 n’est pas
définie et qu’une base de données est démarrée avec un jeu de caractères
autres que celui par défaut, le jeu ne sera pas reconnu par la base de
données.
• Pour qu’une instance d’Oracle fonctionne proprement, la variable PATH
doit stocker le chemin d'un fichier spécifique.
• La dernière variable est LD_LIBRARY_PATH, elle contient les chemins
pour les dossiers du système d’exploitation et des fichiers de la librairie
Oracle. Par exemple : ORACLE_HOME/lib.
Page 37
29/06/2006
4.2.1.
Création de fichiers de mots de passe
Les opérations telles que l’arrêt et le démarrage de la base de données doivent être
effectuées par des utilisateurs autorisés à administrer une base de données.
L'exécution de telles opérations par des utilisateurs de base de données non
autorisés peut entraîner la perte de données. Par exemple, si un utilisateur arrête
une base de données en mode Abort, les données non validées risquent d'être
perdues.
Le problème des utilisateurs non autorisés à effectuer des opérations critiques
spécifiques peut se résoudre en utilisant un fichier de mots de passe permettant
d'authentifier les utilisateurs qui administrent la base de données.
L'exécutable ORAPWD.exe permet d'exécuter l’utilitaire ORAPWD.
4.3. Créer une base de données
4.3.1. Assistant de configuration de base de données
Il existe deux méthodes pour créer une base de données. Soit en utilisant
l’assistant de configuration de base de données, soit en utilisant le commande
CREATE DATABASE. L’assistant de configuration de base de données est un
utilitaire qui se lance sous linux avec la commande dbca et qui permet :
• Créer une base de données : Option qui permet de créer une nouvelle base
de données ou un template, qui permet de choisir avec fichiers de données
ou sans fichiers de données.
• Configurer les options de base de données : Cette option permet d’ajouter
des options à la base de données qui n’ont pas été configurées initialement.
Par exemple : JVM, interMedia, Oracle OLAP Services…
• Supprimer une base de données : Option qui permet de supprimer une base
de données.
• Gérer les templates : Il existe trois moyens de créer un template. Soit à
partir d’un template déjà existant, soit à partir d’une base de données, soit à
partir d’un template prédéfini. Il existe deux types de templates de base de
données. Ceux qui contiennent seulement la structure physique de la base
de données (options, tablespaces, datafiles…), ou les templates contenant la
structure ainsi que les données contenues dans la base.
Page 38
29/06/2006
Lors de la création d’une base de données avec l’assistant de configuration, il vous
sera demandé de choisir parmi l’un des quatre types de base de données suivant :
• Installation typique ou personnalisée : L’installation typique est pour une
base de données avec un faible trafic. Le mode personnalisé permet de
choisir parmi l’un des environnements suivant :
• OLTP (OnLine Transaction Processing) : Cet environnement est utilisé
pour les grandes bases de données devant gérer des milliers de transactions
(lecture, écriture, suppression) par jour. Les performances pour ce type
d’environnement sont définit en terme de disponibilité des données.
• Data Warehousing : Cet environnement est utilisé avec des base de
données qui sont souvent interrogées mais peut modifiées. Les
performances de ce type d’environnement sont définit en terme de temps de
réponse.
• Mixed : Environnement supportant à la fois OLTP et Data Warehousing.
Mode par défaut pour l’installation d’une base de données.
4.3.2. Les options de la commande CREATE DATABASE
Le DBA peut créer une base de données en utilisant la commande CREATE
DATABASE. La connaissance des fonctions des options de la commande
CREATE DATABASE permettra au DBA d'identifier celles qu'il doit spécifier
pour créer une base de données adaptée.
CREATE DATABASE <database>
[MAXLOGFILES integer]
Spécifie le nombre maximum de groupes de fichier log qui peuvent être créé pour
La valeur de cette option affecte la taille du fichier de contrôle.
[MAXLOGMEMBERS integer]
Spécifie le nombre maximum de fichiers redo log membres d’un groupe de
fichiers redo log.
[MAXLOGHISTORY integer]
Spécifie le nombre maximum de redo log archivés qui peuvent être utilisés pour la
récupération automatique physique du serveur Oracle Parallel. La valeur de cette
option affecte la taille du fichier de contrôle.
[MAXDATAFILES integer]
Spécifie le nombre maximum de fichiers de données qui peuvent être créés pour la
base de données.
[MAXINSTANCES integer]
Page 39
29/06/2006
Spécifie le nombre maximum d’instances pouvant monter et ouvrir la base de
données simultanément. La valeur de cette option affecte la taille du fichier de
contrôle.
[ARCHIVELOG | NOARCHIVELOG]
Spécifie que les redo log doivent être archivés avant d’être réutilisés. L’option
NOARCHIVELOG spécifie que les fichiers redo log peuvent être réutilisés sans
archiver leur contenu. La valeur de cette option affecte la taille du fichier de
contrôle.
[CHARACTER SET charset]
Spécifie le jeu de caractères utilisé par la base de données pour stocker les
données. Si cette option n’est pas précisée, le jeu de caractère par défaut
US7ASCII sera utilisé.
[DATAFILE filespec [, filespec]…]
Spécifie le fichier de données à créer pour le tablespace SYSTEM. Cette option est
reliée à la clause autoextend_clause par la relation :
filespec :== ‘filename [SIZE n [K|M] ] [REUSE]
[autoextend_clause]
autoextend_clause :== AUTOEXTEND {OFF|ON [NEXT integer [K|M] ]
[MAXSIZE integer [K|M] }
active ou désactive l’extension automatique d’un fichier de données.
[CONTROLFILE REUSE]
Spécifie que les fichiers de contrôle identifiés dans le fichier de paramètre peuvent
être écrasés si ils existent déjà.
[NATIONAL CHARACTER SET charset]
Spécifie le jeu de caractères national utilise pour stocker les données dans des
colonnes de type NCHAR, NCLOB ou NVARCHAR2.
[LOGFILE [GROUP integer] filespec [, [GROUP integer] filespec] ]
Spécifie les fichiers log utilises pour la base de données et les groupes auxquels
ces fichiers appartiennent.
[Defaut Temporary Tablespace] Création d’un tablespace par défaut, chaque
utilisateur ne spécifiant pas un tablespace par défaut sera automatiquement assigné
au tablespace par défaut.
[SET TIME_ZONE] Fuseau horaire à utiliser pour la base de données.
4.3.3. Créer une base de données en mode commande
La principale responsabilité d'un DBA est de créer et de gérer une ou plusieurs
bases de données.
Dans ces bases de données peut être stocké un très grand nombre de données qui
peuvent être récupérées et analysées. Le script utilisé pour créer une base de
Page 40
29/06/2006
données doit être écrit dans un fichier texte. Le script est ensuite exécuté en
utilisant SQL*Plus (par exemple).
Exemple de script permettant de créer une base de données :
4.3.4. Les conditions d'erreur lors de la création d'une base de
données
Il existe plusieurs situations lors de la création d’une base de données avec la
commande CREATE DATABASE qui peuvent provoquer un échec. La
connaissance de ces situations permet au DBA d'identifier les erreurs faites lors de
la création d'une base de données.
• Des erreurs de syntaxe dans le script SQL
• Les fichiers que la commande CREATE DATABASE doit créer existent
déjà. Cette erreur apparaît lorsque l’option REUSE n’a pas été spécifiée ou
lorsque la taille des fichiers ne correspond pas.
• Une erreur se produit au niveau du système, telles que des permissions de
fichier et de répertoire non valides.
• Il n’y a pas assez d’espace disque pour créer les fichiers spécifiés dans la
commande CREATE DATABASE.
Dans tous les cas d’échec, il faut arrêter l’instance. Il faut ensuite modifier la
commande, redémarrer l’instance en mode NOMOUNT et créer à nouveau la base
de données.
Page 41
29/06/2006
4.3.5. Le contenu d'une base de données après sa création
Oracle crée automatiquement plusieurs fichiers, segments et tables dans une base
de données.
La connaissance des éléments qui constituent une base de données permet au DBA
d'identifier et de gérer les objets des bases de données.
Lors de la création de la base de données, le tablespace SYSTEM est créé.
Le tablespace SYSTEM est un ensemble de fichiers de données spécifiés dans la
commande CREATE DATABASE. Il contient le dictionnaire de données.
Les tables du dictionnaire de données sont créées durant la création de la base
de données. Les tables du dictionnaire de données contiennent les informations sur
la structure de la base de données, sur les utilisateurs de la base de données et sur
l’allocation de l'espace. Les vues du dictionnaire de données ne sont pas créées
automatiquement lors de la création de la base de données.
Les vues du dictionnaire de données sont des vues sur les tables du dictionnaire
de données.
Les fichiers de contrôle et les fichiers redo log sont créés à la création de la base
de données. Les fichiers de contrôle contiennent le nom de la base de données et le
chemin d'accès de tous les fichiers de données et fichiers redo log. Lors de la
création de la base de données, les fichiers redo log sont vides ; ils enregistrent
ensuite tous les modifications apportées aux données de la base de données.
Les deux utilisateurs par défaut SYS et SYSTEM sont créés à la création de la
base de données. SYS et SYSTEM ont respectivement les mots de passe par
défaut « change_on_install » et « manager ».
Les utilisateurs SYS et SYSTEM possèdent tous les privilèges système sur la base
de données.
Enfin, lorsque la base de données est créée, le segment de rollback SYSTEM est
créé dans le tablespace SYSTEM. Le segment de rollback SYSTEM est utilisé
pour enregistrer les modifications apportées dans le tablespace SYSTEM.
Page 42
29/06/2006
5. Utilisation et contenu du dictionnaire de
données
5.1. Structure du dictionnaire de données
5.1.1. Présentation du dictionnaire de données
Les utilisateurs des bases de données, les développeurs d'applications, les
administrateurs de bases de données et le serveur Oracle utilisent le dictionnaire de
données comme une source centrale d’information associée à une base de données.
Le dictionnaire de données est un ensemble de tables et de vues qui est utilisé
comme une référence fournissant de l’information à jour concernant la base de
données.
Le dictionnaire de données est automatiquement mis à jour par Oracle lorsque des
commandes de langage de définition des données ou des commandes de
manipulation des données, débouchant sur l'extension d'une table, sont exécutées.
Le dictionnaire de données stocke les informations sur :
• La structure logique de la base de données
Par exemple, les informations sur les tablespaces, les blocs de données, les
extents et les segments d'une base de données.
• La structure physique de la base de données
Notamment les informations sur les fichiers de contrôle, les fichiers redo
log et les fichiers de données.
• Les noms et les définitions des objets
Tels que les tables, les vues, les index, les clusters, les séquences, les
triggers (ou déclencheurs), les fonctions, les procédures et les packages
mais aussi les informations sur les espaces alloués et l’espace actuellement
utilisé par les objets.
• Les contraintes d’intégrité définies pour les tables d'une base de données.
• Les noms des utilisateurs valides de la base de données et les privilèges et
les rôles attribués à chaque utilisateur de la base de données.
• Les privilèges définissent les opérations qu’un utilisateur peut effectuer
dans la base de données. Un rôle est constitué d’un ensemble de privilèges.
• L'audit sur une base de données.
Par exemple, le dictionnaire de données fournit les informations sur les
utilisateurs qui ont accédé à des objets ou les ont mis à jour. L’audit
correspond à l’enregistrement d’opérations spécifiques en fonction d'un
utilisateur, d'un objet ou d'un privilège.
Page 43
29/06/2006
Le dictionnaire de données possède deux composants :
• les tables de base
• les vues du dictionnaire de données
Les tables de base sont les tables réelles d'Oracle qui stockent les informations sur
une base de données. Ces tables sont créées avec le script sql.bsq. Ce script est
stocké dans le répertoire orant\rdbms\admin. Les informations stockées dans les
tables de base sont lues et écrites par le serveur Oracle. Ces informations sont
rarement accédées directement par les utilisateurs car ces informations sont
normalisées et stockées sous une forme encodée.
Les utilisateurs ou administrateurs de bases de données ne doivent pas utiliser de
commandes DML, telles que INSERT, UPDATE et DELETE, pour mettre à jour
les tables de base directement, à l'exception de la table de trace d'audit lorsque la
fonctionnalité d'audit est utilisée.
Les vues du dictionnaire de données sont des vues sur les tables de base. Elles sont
crées par le script catalog.sql. Les vues du dictionnaire de données simplifient et
résument les informations contenues dans les tables de base. Les vues du
dictionnaire stockent également ces informations sous une forme que les
utilisateurs de la base de données peuvent lire facilement. Ces vues permettent au
DBA de gérer et tuner la base de données.
5.1.2. Création et catégories des vues du dictionnaire de
données
La création des vues du dictionnaire de données se fait à partir du script
catalog.sql, stocké dans ORACLE_HOME\rdbms\admin.
Une fois la base de donnée ouverte il suffit seulement d’exécuter ce script. Il faut
tenir compte que l’exécution de ce script est relativement longue.
Il existe trois principales catégories du dictionnaire de données :
• USER_<vues> :
Vues pouvant être accédées par les utilisateurs de la base de données.
USER_<vues>se réfère au schéma d’un utilisateur de la base de données.
Un schéma est un domaine logique appartenant à un utilisateur où les objets
créés par cet utilisateur peuvent être stockés.
USER_<vues> affiche les informations sur les objets appartenant à un
utilisateur spécifique.
Par exemple, la vue USER_TABLES contient les informations sur les
tables appartenant à un utilisateur. USER_<vues> affiche les informations
sur les privilèges et les rôles attribués par un utilisateur sur des objets créés
par cet utilisateur. Les informations fournies par USER_<vues> font partie
d'un sous-ensemble des informations fournies par ALL_<vues>.
Page 44
29/06/2006
• ALL_<vues>:
Vues affichant les informations sur des objets auxquels l’utilisateur peut
accéder à travers l’obtention publique ou explicite de rôles et de privilèges.
Le contenu de ALL_<vues> est un sous-ensemble de DBA_<vues>.
• DBA_<vues>:
Vues fournissant des informations sur tous les objets de la base de données.
Ces vues sont généralement interrogées par les DBA ou les utilisateurs qui
possèdent le privilège système SELECT ANY TABLE. Ce privilège permet
aux utilisateurs d’interroger toutes les tables de la base de données.
5.1.3. Informations contenues dans le dictionnaire de données
Le dictionnaire de données possède des vues variées qui fournissent différents
types d’informations.
Vues
dictionary dict_columns
Description
Vues générales
dba_tables dba_objects dba_lobs
dba_tab_columns dba_constraints
Informations sur les objets, tels que les
tables, les contraintes, les gros objets et
les colonnes
dba_users dba_sys_privs dba_roles
Informations sur les privilèges et les
rôles des utilisateurs
Page 45
29/06/2006
dba_extents dba_free_space dba_segments
dba_rollback_segs
dba_data_files dba_tablespaces
Allocation d’espace pour les objets de
la base de données
Structures générales de la base de
données
dba_audit_trail
dba_audit_objects
Informations d’audit
dba_audit_obj_opts
La vue DICTIONARY du dictionnaire de données fournit une vue d’ensemble de
toutes les données du dictionnaire de données. L’interrogation de la vue
DICTIONARY évite d'avoir à se souvenir de toutes les vues et des informations
fournis par chacune de ces vues.
La vue DICTIONARY possède deux colonnes : TABLE_NAME et COMMENT.
Ces colonnes indiquent la vue qui devra ensuite être interrogée pour extraire des
informations.
Par exemple, pour récupérer les informations concernant les tables accessibles à
un utilisateur, il faut interroger la vue ALL_CATALOG.
Exemple :
L’objectif est de récupérer les noms des segments de rollback de la base de
données en interrogeant la vue DICTIONARY.
SELECT *
FROM dictionary
WHERE table_name LIKE UPPER( %ROLLBACK% );
TABLE_NAME
-----------------------------DBA_ROLLBACK_SEGS
1 row selected.
COMMENTS
------------------------------------Description of rollback segments
Cette requête affiche le nom des vues qui contiennent des informations sur les
segments de rollback.
Pour afficher les noms des segments de rollback :
SELECT segment_name
FROM dba_rollback_segs;
SEGMENT_NAME
------------------------------
Page 46
29/06/2006
SYSTEM
RB_TEMP
RB1
RB2
RB3
...
Pour afficher la liste des colonnes d’une vue, il faut utiliser le mot clé :
DESCRIBE V$INSTANCE
5.2. Scripts du dictionnaire de données
5.2.1. Création de fonctions PL/SQL
Pour qu’un serveur Oracle fonctionne efficacement et de façon optimale, la base
de données doit supporter les fonctionnalités PL/SQL.
Le script catproc.sql est utilisé pour ajouter des fonctionnalités PL/SQL à une base
de données. Ce script lance tous les scripts utilisés ou nécessaires avec PL/SQL. Il
créé également des packages PL/SQL qui étendent les fonctionnalités du SGBDR
et des vues supplémentaires de gestion des files d'attente de messages et de
restauration des tablespaces. Catproc.sql est stocké sous le répertoire
ora92\rdbms\admin. Pour l’exécuter, il suffit d’ouvrir une session SQL*Plus et de
lancer l’exécution du script avec la commande : @<chemin complet du script>.
5.2.2. Scripts administratifs
Pour gérer une base, il peut être nécessaire au DBA de créer des structures
supplémentaires, telles que des tables, des vues et des packages.
Les scripts administratifs sont séparés en quatre catégories de fichiers se trouvant
dans le répertoire :
• Les scripts utl*.sql :
Ils créent des vues et des tables additionnelles pour les utilitaires de la base
de données. Par exemple, le script utlsampl.sql crée et remplit les tables
d’exemple EMP, DEPT, SALGRADE et BONUS de l’utilisateur SCOTT.
• Les scripts cat*.sql :
Ils créent des vues du dictionnaire de données et des tables de base du
dictionnaire de données. Par exemple, catalog.sql crée des vues du
dictionnaire pour une base de données, catman.sql crée des tables de base
pour la récupération et des vues pour l’utilitaire Recovery Manager.
• Les scripts dbms*.sql :
Page 47
29/06/2006
Ils créent des spécifications de package de base de données. Par exemple, le
script dbmspool.sql crée la spécification d’un package qui permet d’afficher
la taille des objets présent dans la shared pool.
• Les scripts prvt*.plb :
Ils créent le corps de package.
Page 48
29/06/2006
6. Gestion des fichiers de contrôle et de redo log
6.1. Fichier de contrôle
Le fichier de contrôle file est un petit fichier binaire, nécessaire pour démarrer et
maintenir une base de données. Le fichier de contrôle doit être disponible chaque
fois que la base de données est montée ou ouverte.
Lorsqu'une instance monte la base de données, elle lit le fichier de contrôle pour
localiser les fichiers de données et les fichiers redo log online.
Une des fonctions du fichier de contrôle est de fournir les informations les plus
récentes sur la base de données à l’instance Oracle mise à jour en permanence
pendant l'utilisation de la base de données.
Le fichier de contrôle fournit également des informations sur la cohérence de la
base de données. Ces informations sont utilisées lors de la restauration de la base
de données.
Si le fichier de contrôle utilisé par la base de données devient indisponible, la base
de données ne peut pas fonctionner proprement. Le fichier de contrôle peut
devenir indisponible pour un grand nombre de raisons telles que la défaillance du
disque ou la corruption du fichier.
Certains mots-clés utilisés pendant la création d’une base de données, affectent la
taille du fichier de contrôle. Ceci est surtout visible quand les paramètres ont de
très grandes valeurs. Les paramètres suivants affectent la taille du fichier de
contrôle :
•
•
•
•
•
MAXLOGFILES
MAXLOGMEMBERS
MAXLOGHISTORY
MAXDATAFILES
MAXINSTANCES
6.1.1. Contenu des fichiers de contrôle
Le fichier de contrôle stocke des informations permettant à la base de données de
fonctionner correctement.
Le fichier de contrôle stocke :
• Le nom et l’identifiant de la base de données
• Les noms et les emplacements des fichiers de données et des fichiers redo
log en ligne. Ces informations permettent au serveur Oracle de localiser les
fichiers de la base de données sur le disque.
• Le nom des tablespaces
Page 49
29/06/2006
• La date et l'heure de création de la base de données.
• Le numéro de séquence de log actuel. Cette information permet de
synchroniser tous les fichiers appartenant à la base de données.
• Les informations sur les points de synchronisation. Cette information est
utilisée par le serveur Oracle lors de la restauration de l’instance.
• L’historique des fichiers log
• Les informations de sauvegarde de l’utilitaire Recovery Manager.
• Le début et à la fin des segments de undo.
Le fichier de contrôle se divise en deux parties :
• Réutilisable, qui stocke les informations du Recovery Manager, comme les
fichiers de sauvegarde de redo log et les fichiers de sauvegarde de données.
Ces fichiers ne sont réutilisables que par le Recovery Manager.
• Non réutilisable.
6.1.2. Multiplexage des fichiers de contrôle
Dans le but de prévenir une erreur dans un fichier de contrôle, il est fortement
recommandé de multiplexer les fichiers de contrôles et de les stocker séparément
sur des disques différents. Si un fichier de contrôle est perdu, une copie du fichier
de contrôle peut être utilisé pour redémarrer l’instance. On peut multiplexer
jusqu’à 8 fichiers de contrôles.
6.1.3. Récupérer les informations des fichiers de contrôle
Pour récupérer l’emplacement et les noms des fichiers de contrôles, il est
nécessaire d’interroger la vue dynamique V$CONTROFILE.
SELECT name
FROM V$CONTROLFILE ;
NAME
------------------------------D:\ORACLE\ORADATA\IASDB\CONTROL01.CTL
D:\ORACLE\ORADATA\IASDB\CONTROL02.CTL
D:\ORACLE\ORADATA\IASDB\CONTROL03.CTL
3 rows selected.
D’autres vues peuvent être utilisées comme V$PARAMETER qui contient toutes
les
informations
sur
tous
les
paramètres,
V$CONTROLFILE_RECORD_SECTION qui contient les informations sur les
Page 50
29/06/2006
sections d’enregistrement des fichiers de contrôles, et la commande SHOW
PARAMETERS CONTROL_FILES qui liste le nom, l’état et l’emplacement des
fichiers de contrôles.
6.2. Les fichiers de redo log
6.2.1. Utiliser les fichiers de redo log
Les fichiers de redo log permettent d’enregistrer tous les changements effectués
par des transactions sur les données et fournissent un mécanisme de récupération
des données en cas de dysfonctionnement du système ou d’un disque. Les fichiers
redo log stockent toutes les modifications apportées aux données du buffer cache.
L’organisation des fichiers de redo log s’effectue en groupe (au minimum 2)
contenant un ou plusieurs fichiers de redo log. Chaque fichier de redo log
appartenant à un groupe est appelé un membre.
Tous les membres redo log online présentent tous des numéros de séquence log
identiques. Le numéro de séquence log est affecté chaque fois que le serveur
Oracle commence à écrire dans un groupe de fichiers redo log online. Ces
numéros sont utilisés pour identifier de façon unique chaque membre redo log
online.
Le numéro de séquence log courant est stocké dans le fichier de contrôle ainsi que
dans l'entête de tous les fichiers de données. Ce numéro est utilisé lors de la
récupération de la base de données.
Les membres redo log online ont tous la même taille.
Un groupe de redo log en ligne sert également à restaurer des données validées qui
n'ont pas été écrites dans les fichiers de données. Une telle situation peut se
produire après l'échec d'une instance.
6.2.2. Structure des fichiers de redo log
La charge de maintenir et gérer plusieurs fichiers de redo log appartient au DBA,
pour éviter qu’un seul dysfonctionnement d’un fichier fasse perdre des
informations à la base de données.
Les mêmes informations sur les modifications apportées aux données sont
enregistrées dans tous fichiers redo log online d'un groupe de redo log online.
Donc tous les fichiers redo log d'un groupe redo log en ligne possèdent exactement
les mêmes informations. Ce travail est effectué pas le processus d'arrière plan
LGWR.
Page 51
29/06/2006
6.2.3. Paramètres des fichiers de redo log
Les performances d'une base de données sont affectées par le nombre et la taille
des fichiers et des groupes redo log online.
Le numéro initial et la taille des fichiers redo log en ligne et des groupes sont
déterminés pas des paramètres d'initialisation :
• MAXLOGFILES spécifie le nombre maximal de groupes de fichiers redo
log online. La limite de MAXLOGFILES est de 255.
• MAXLOGMEMBERS détermine le nombre maximal de membres redo log
online pour chaque groupe de redo log online. Le nombre total de membres
redo log online est un multiple du nombre de fichiers redo log.
• LOG_FILES spécifie le nombre maximal actuel de groupes de fichiers redo
log online pour la durée de vie de l'instance courante. Par défaut, la valeur
de LOG_FILES est plus petite ou égale au nombre total de membres redo
log en ligne (MAXLOGMEMBERS * MAXLOGFILES).
Les fichiers redo log en ligne sont créés durant la création de la base de données.
Le serveur Oracle enregistre séquentiellement tous les changements fait sur la base
de données dans le buffer de redo log. Ensuite, les données contenues dans le redo
buffer sont écrites grâce au process LGWR dans le fichier de redo log online.
LGWR déclenche le processus d’écriture lors d’un des évènements suivants :
• Une transaction est comité.
• Quand le buffer de redo log est plein au tiers.
• Quand le buffer de redo log contient plus de 1Mo d’enregistrements
changés.
• Avant que le process DBWn écrivent les blocs modifiés du database buffer
cache dans les fichiers de données.
6.3. Gérer les groupes de redo
6.3.1. Fonctionnement des fichiers de redo log
Basculement de fichiers log (Log Switches) :
Toutes les modifications apportées à la base de données sont stockées
séquentiellement dans le buffer redo log avant le remplissage des groupes de
fichiers redo log online.
Le serveur Oracle écrit ensuite le contenu du redo log buffer dans les groupes de
redo log online. Le redo log buffer est utilisé de façon circulaire.
Dans certains cas, les entrées du redo log buffer sont écrites dans un des groupes
de redo log online par le processus d'arrière plan LGWR. Ce groupe est appelé le
groupe courant de redo log online.
Page 52
29/06/2006
Le LGWR écrit séquentiellement dans les fichiers redo log online. Il commence à
écrire dans le groupe suivant une fois que le groupe courant est plein.
Lorsque le dernier fichier redo log online disponible est plein, le LGWR revient au
premier groupe et écrase son contenu avec les nouvelles entrées.
L'événement durant lequel LGWR arrête d'écrire dans un groupe et commence à
écrire dans un autre, est appelé basculement de fichier log ("log switch").
L'événement basculement de fichier log amorce un événement point de
Page 53
29/06/2006
synchronisation ("checkpoint"), qui entraîne l'écriture des buffers modifiés ("dirty
blocks") du buffer cache dans les fichiers de données.
Un basculement de fichier log apparaît lorsque :
• le groupe courant de fichiers redo log online est plein
• l'administrateur force le basculement de fichier log.
Ces situations provoquent les événements qui permettent au serveur Oracle de
conserver les données les plus récentes dans les fichiers de données.
Chaque fois qu'un basculement de fichier log se produit et que le LGWR
commence l'écriture dans un nouveau groupe de fichiers redo log online, le
serveur Oracle assigne un numéro appelé le numéro de séquence log. Ce numéro
identifie l'ensemble des entrées redo log.
Points de synchronisation (Checkpoints) :
L'événement d’arrière plan du serveur Oracle qui met à jour les fichiers de
données est le point de synchronisation.
Les points de synchronisation peuvent concerner tous les fichiers de données de la
base de données ou seulement certains fichiers de données spécifiques.
Lors d'un point de synchronisation, tous les buffers modifiés ("dirty blocks") sont
écrits dans les fichiers de données par le processus DBWR. Le nombre de buffers
qui sont écrit par le process DBWn est déterminé par le paramètre
FAST_START_MTTR_TARGET.
Si le point de synchronisation s'est achevé correctement, le processus d'arrièreplan CKPT met à jour les entêtes de tous les fichiers de données et fichiers de
contrôle.
Un point de synchronisation se produit dans plusieurs situations :
• durant un basculement de fichier log.
• Lorsqu'une instance s'arrête en mode normal, transactional ou immediate
Page 54
29/06/2006
• Selon
la
configuration
des
paramètres
d'initialisation
LOG_CHECKPOINT_INTERVAL et LOG_CHECKPOINT_TIMEOUT
• lorsqu'il est imposé par l'administrateur
• lorsqu'un tablespace devient offline ou en lecture seule
Ces situations entraînent l'événement checkpoint. Ainsi les fichiers de données
dans la base de données sont mis à jour à intervalles réguliers.
Les informations à propos de chaque checkpoint sont enregistrées dans le fichier
alert<SID>.log si le paramètre LOG_CHECKPOINTS_TO_ALERT est initialisé à
TRUE. Sa valeur par défaut est à FALSE.
6.3.2. Forcer le basculement de fichiers log et un point de
synchronisation Log switch :
Comme vu dans le point précédent, le basculement de fichiers log et les
checkpoints sont fait automatiquement. Pourtant en cas de nécessité le DBA peut
décider de forcer l’exécution d’un log switch ou d’un checkpoint.
Un log switch peut être forcé avec la commande SQL suivante :
ALTER SYSTEM SWITCH LOGFILE ;
Outre la commande SQL, Oracle offre une interface graphique appelée Oracle
Backup Manager permettant d'imposer un basculement de fichier log.
Un basculement de fichier log peut être forcé même si aucune sauvegarde n'est
prévue dans l'immédiat.
Point de synchronisation :
L'administrateur procède souvent à des sauvegardes permanentes (dite "à chaud")
de tablespaces. Pour s'assurer que les fichiers de données contiennent les données
les plus récentes, l'administrateur doit forcer un point de synchronisation avant de
procéder à une sauvegarde.
La syntaxe suivante permet de forcer un point de synchronisation:
ALTER SYSTEM CHECKPOINT;
Outre la commande SQL, Oracle offre une interface graphique, Oracle Backup
Manager qui permet de forcer un point de synchronisation.
Il est possible de forcer un checkpoint en utilisant le paramètre
FAST_START_MTTR_TARGET.
Par exemple FAST_START_MTTR_TARGET = 600 signifie que la restauration
d’une instance après un crash ne doit pas prendre plus de 600 secondes, et la base
de données doit ajuster les autres paramètres pour arriver à ce résultat.
Page 55
29/06/2006
6.3.3. Ajout de groupe de fichiers redo log online
Si la base de données est en mode ARCHIVELOG et que le fichier redo log online
est gros, l'archivage peut prendre beaucoup de temps. Donc, un fichier redo log
online peut ne pas être disponible pour les écritures effectuées par le buffer redo
log. Dans ce cas, le processus LGWR est contraint d'attendre. Si le processus
LGWR doit attendre, le DBWR attend et le système ralentit.
Pour éviter les attentes et les ralentissements, l'addition de groupes redo log en
ligne peut être nécessaire.
Il existe deux méthodes pour ajouter un groupe redo log en ligne : avec une
commande SQL ou avec l'outil Oracle Storage Manager.
Des groupes de fichiers redo log en ligne peuvent être créés à l'aide de la
commande ALTER DATABASE :
ALTER DATABASE [database]
ADD LOGFILE [GROUP integer] 'filename' [SIZE n[K|M]]
[REUSE]
[,[GROUP integer] 'filename' [SIZE n[K|M]] [REUSE] ]...;
La valeur du paramètre GROUP peut être choisie pour chaque groupe de fichier
redo log. Si ce paramètre est omis, Oracle lui génère automatiquement une valeur.
Exemple :
ALTER DATABASE
ADD LOGFILE GROUP 3
('c:\orant\database\logorcl3.ora') SIZE 1000K;
Database altered.
Cette commande crée un nouveau groupe de fichiers redo log portant le numéro 3.
Ce groupe est constitué d'un membre redo log nommé logorcl3.ora d'une taille de
1000 Ko.
6.3.4. Ajout des membres redo log online
Des membres redo log en ligne peuvent être ajoutés à un groupe afin d'éviter des
défaillances isolées. En effet, l'ajout de membres redo log permet de placer les
Page 56
29/06/2006
fichiers redo log en miroir. Des membres redo log peuvent être ajoutés grâce à la
commande SQL suivante :
ADD LOGFILE MEMBER 'filename' [REUSE]
TO GROUP n;
Le chemin complet des membres doit être spécifié. Si le chemin complet n'est pas
spécifié, les fichiers seront créés dans le répertoire par défaut du serveur de base
de données.
Si le fichier existe déjà, il doit avoir la même taille que le nouveau fichier redo log
online et l'option de la commande REUSE doit être utilisé. Le groupe cible peut
être identifier en spécifiant le numéro du groupe soit un ou plusieurs membres du
groupe.
Exemple :
ALTER DATABASE
ADD LOGFILE MEMBER 'e:\orant\database\log7borcl.ora'
TO GROUP 7;
Database altered.
Cette commande ajoute un nouveau membre redo log nommé log7borcl.ora au
groupe redo log 7. Ce nouveau membre sera stocké dans le répertoire
e:\orant\database.
6.3.5. Relocalisation des fichiers redo log online
En raison de contraintes système, telles que l'insuffisance d'espace disque, les
fichiers redo log online peuvent avoir besoin d'être relocalisés.
Etapes à suivre pour relocaliser un fichier redo log online :
• Arrêter la base de données,
• Copier le fichier redo log online vers la nouvelle destination,
• Monter la base de données,
• Changer le nom du fichier redo log online à l'aide d'une commande SQL :
RENAME FILE 'old filename' TO 'new filename';
Avant de changer le nom du fichier, il faut s'assurer que le nouveau fichier
existe bien à l'emplacement prévu. Le serveur Oracle change seulement le
Page 57
29/06/2006
pointeur dans le fichier de contrôle, mais il ne renomme pas physiquement
ni ne crée de fichier.
• Ouvrir la base de données.
6.3.6. Suppression de groupes de fichiers redo log online
Pour améliorer les performances de la base de données, il peut s'avérer nécessaire
d'augmenter ou de diminuer la taille des groupes de fichiers redo log online. Pour
changer la taille d'un groupe de fichiers redo log online, il faut créer un nouveau
groupe de fichiers redo log online et ensuite supprimer le vieux groupe de fichiers
redo log online.
Pour supprimer un groupe de fichiers redo log online, il faut utiliser la commande
SQL suivante :
DROP LOGFILE GROUP n;
Cependant un certain nombre de restrictions sont à prendre en compte lors de la
suppression de groupes redo log online :
• L'instance doit avoir au moins deux groupes de fichiers redo log online. Un
groupe de fichiers redo log online ne pourra pas être supprimé si il n'existe
que deux groupes. Pour supprimer un groupe, il doit en rester au moins
trois.
• Un groupe redo log online actif ne peut pas être supprimé.
• Si la base de données tourne en mode ARHIVELOG, un groupe de fichiers
redo log online non archivé ne peut pas être supprimé.
Quand un groupe redo log est supprimé, les fichiers du système d'exploitation ne
sont pas supprimés automatiquement. Il est donc nécessaire de supprimer
manuellement les fichiers redo log online afin de garder un espace disque propre.
6.3.7. Suppression des membres redo log online
Pour obtenir les meilleures performances d'une base de données Oracle, il est
nécessaire de vérifier régulièrement le statut des fichiers redo log online. Parfois,
un fichier redo log online peut devenir invalide à cause d'événements tels qu'une
défaillance du support. Ce qui rend les fichiers inaccessibles. Dans ce cas, il faut
supprimer ces fichiers redo log online.
La commande SQL qui permet de supprimer un membre redo log en ligne est la
suivante :
Page 58
29/06/2006
DROP LOGFILE MEMBER 'filename';
Exemple :
Le fichier redo log online nommé log5borcl.ora dans le groupe 5 est devenu
invalide.
Ce fichier est stocké dans le répertoire e:\orant\oradata\orcl.
ALTER DATABASE
DROP LOGFILE MEMBER 'e:\orant\oradata\orcl\log5borcl.ora';
Database altered.
Cette commande supprime le fichier redo log online invalide log5borcl.ora.
Cependant un certain nombre de restrictions sont à prendre en compte lors de la
suppression de membres redo log en ligne :
• Le dernier membre redo log online valide d'un groupe ne peut pas être
supprimé.
• Un basculement de fichier log doit être effectué avant de supprimer un
membre redo log online actif.
• Si la base de données tourne en mode ARCHIVELOG, alors un membre
redo log online appartenant à un groupe non archivé ne peut pas être
supprimé
6.3.8. Réinitialisation des fichiers redo log online
Lors de l'utilisation de la base de données, il est possible que tous les membres
d'un groupe de fichiers redo log online soient corrompus. Pour faire face à ce
problème, il faut réinitialiser les fichiers redo log online.
Les commandes SQL pour réinitialiser les fichiers redo log en ligne sont les
suivantes :
CLEAR [UNARCHIVED] LOGFILE GROUP n;
Ou
CLEAR [UNARCHIVED] LOGFILE 'filename';
L'utilisation de ces commandes revient à ajouter et supprimer un fichier redo log
online. Cependant ces commandes peuvent être effectuées même si il y seulement
Page 59
29/06/2006
deux groupes de fichiers redo log online avec un membre chacun. Ces commandes
peuvent également être effectuées même si un groupe de fichiers redo log online
réinitialisé est disponible mais pas archivé.
Exemple :
Le fichier redo log online redo04.log dans le groupe 1 est corrompu.
ALTER DATABASE
CLEAR LOGFILE 'e:\orant\oradata\orcl\redo04.log';
Database altered.
Le fichier redo log online redo04.log a été réinitialisé. Ce fichier est désormais
prêt et disponible pour utilisation.
Un fichier redo log online peut être réinitialisé qu'il ait été archivé ou non. Si le
fichier à réinitialiser n'a pas été archivé, il faut inclure le mot clé UNARCHIVED
dans la commande SQL. Cependant, l'utilisation du mot clé UNARCHIVED
aboutit à des sauvegardes inutilisables si le fichier redo log en ligne est nécessaire
pour la récupération.
6.4. Planification des fichiers redo log online
6.4.1. Nombre de fichiers redo log online
Pour minimiser la perte de données causée par une défaillance, le serveur Oracle
fournit des groupes de fichiers redo log online.
Cependant le nombre et la taille des groupes de fichiers redo log online qui
peuvent être créés dépendent d'un certain nombre de facteurs :
• le nombre de transactions effectuées sur la base de données.
Quand le nombre de transaction est limité, une instance de base de données
ne peut avoir besoin que de deux groupes. Quand le nombre de transactions
est très grand, une instance de base de données peut avoir besoin de groupes
additionnels pour garantir la disponibilité des groupes de fichiers redo log
online au processus LGWR.
• La taille du buffer redo log.
Si des messages dans le fichier trace LGWR ou dans le fichier ALERT
indiquent que le processus LGWR attend fréquemment pour écrire dans un
groupe de fichiers redo log online, il faut ajouter des groupes de fichiers
redo log online. Le processus LGWR peut attendre à cause d'un point de
Page 60
29/06/2006
synchronisation pas terminé ou d'un groupe de fichiers redo log online pas
encore archivé.
• La stabilité des gros fichiers du système d'exploitation.
Le système d'exploitation peut devenir instable en traitant de gros fichiers,
il est donc préférable de maintenir des fichiers de petite taille, donc
d'augmenter le nombre de fichiers redo log online.
Bien que le nombre de membres dans des groupes multiplexés puisse être
différent, il est très conseillé de mettre en place une configuration symétrique.
Une configuration asymétrique peut être utilisée seulement temporairement dans
une situation inutilisable telle qu'une défaillance du support.
6.4.2. Emplacement des fichiers redo log online
La disponibilité des fichiers redo log online détermine la performance d'une base
de données Oracle.
Pour améliorer la performance de la base de données, les membres des groupes de
fichiers redo log online, les fichiers log archivés et les fichiers de données doivent
être stockés sur des disques séparés.
L'avantage de stocker les fichiers redo log online sur des disques séparés est que
l'instance ne s'arrêtera pas même si un des membres n'est pas disponible. Un autre
avantage de stocker les fichiers redo log online et les fichiers log archivés sur des
disques différents est que la contention entre les processus ARCH et LGWR est
réduite.
De plus, les fichiers de données placés sur différents disques permettent également
de réduire la contention entre les processus LGWR et DBWR.
Le stockage des fichiers redo log et des fichiers de données sur différents disques
permet de réduire de façon substantielle le risque de perdre à la fois les fichiers de
données et les fichiers redo log online lors d'une défaillance du support.
6.4.3. Dimensionnement des fichiers redo log online
Les performances d'une base de données Oracle dépendent de la disponibilité des
fichiers redo log online. Donc, la taille des fichiers redo log online est une décision
importante.
La taille minimale d'un fichier redo log en ligne est de 50 Ko, et la taille maximale
est spécifique au système d'exploitation.
Cependant, il existe des situations qui influencent la taille des fichiers redo log
online :
Page 61
29/06/2006
• Le nombre de basculements de fichiers log et de points de synchronisation.
Si les fichiers redo log online sont de petite taille, un grand nombre de
basculements de fichiers log aura lieu ce qui réduit l'efficacité de la base de
données.
• Le nombre et la quantité d'entrées redo.
Si le nombre d'entrées redo est élevé, les fichiers redo log online seront
remplis rapidement ce qui débouche sur la génération d'un grand nombre de
basculement de fichiers log.
• L'espace disponible sur le support de stockage.
Si le support de stockage ne présente pas la capacité suffisante pour stocker
le fichier redo log online en une seule entité, l'administrateur de la base de
données est contraint d'utiliser un fichier redo log online plus petit ou
plusieurs fichiers. Ces fichiers sont stockés sur plusieurs disques.
Les membres des groupes différents peuvent présenter des tailles différentes.
Cependant, il n'est pas souhaitable d'avoir des groupes de tailles différentes.
Les groupes de tailles différentes ne sont nécessaires que provisoirement lors de la
modification de la taille des membres des groupes de fichiers redo log online.
6.4.4. Gérer les redo log online with OMF
Pour créer un nouveau groupe de fichiers de redo log sans spécifications, le DBA
utilise la commande :
ALTER DATABASE ADD LOGFILE ;
Cette commande ajoute un fichier de log avec un membre dans
DB_CREATE_ONLINE_LOG_DEST_1
et
un
membre
dans
DB_CREATE_ONLINE_LOG_DEST_2. Les noms des fichiers uniques des
fichiers de redo log sont générés automatiquement.
Il est bien évidemment possible d’utiliser la clause GROUP pour supprimer un
fichier de log. Dans l’exemple précédent, le fichier du système d’exploitation
associé à chaque fichier de log membre OMF est automatiquement supprimé.
Les fichiers archivés de redo log ne peuvent être des fichiers OMF. Un
emplacement système pour les fichiers de log archivés peut être spécifié avec le
paramètre d’initialisation LOG_ARCHIVE_DEST_n
6.4.5. Obtenir des informations sur les groupes
Page 62
29/06/2006
Il est possible d’obtenir des informations sur les groupes et les membres en
interrogeant le dictionnaire de données.
La requête suivante retourne des informations sur le fichier de redo log online du
fichier de contrôle.
SELECT group#, sequence#, bytes, members, status
FROM V$LOG ;
GROUP#
-----1
2
3
SEQUENCE#
--------1985
1986
1984
BYTES
----1048576
1048576
1048576
MEMBERS
------1
1
1
STATUS
-----INACTIVE
CURRENT
INACTIVE
INACTIVE signifie que le groupe de fichier de redo n’est plus nécessaire pour la
restauration d’instance.
CURRENT, indique le groupe courrant de redo log. C’est ce groupe là qui est
actif.
UNUSED, signifie que le groupe de redo vient juste d’être ajouté et qu’il n’a
jamais été écrit.
Pour connaître tous les noms des membres d’un groupe, il faut interroger la vue
V$LOGFILE.
SELECT member
FROM V$LOGFILE ;
MEMBER
-------------------------------D:\ORACLE\ORADATA\IASDB\REDO03.LOG
D:\ORACLE\ORADATA\IASDB\REDO02.LOG
D:\ORACLE\ORADATA\IASDB\REDO01.LOG
La valeur du statut de la colonne peut être INVALID (fichier inaccessible),
STALE (le contenu du fichier est incomplet), DELETED (le fichier n’est plus
utilisé).
6.4.6. Archivage de fichiers de redo log
Une des décisions importantes qu’un DBA doit prendre est configurer la base de
données dans le mode ARCHIVELOG ou NOARCHIVELOG.
NOARCHIVELOG :
Page 63
29/06/2006
En mode, NOARCHIVELOG, les fichiers de redo log online sont réécrits à
chaque fois qu’un fichier de redo log online est rempli et qu’un log switch est
lancé. LGWR ne réécrit pas sur un groupe de fichier de redo log tant que le
checkpoint pour ce groupe n’est pas terminé.
ARCHIVELOG :
Si la base de données est configurée dans le mode ARCHIVELOG, alors les
groupes de redo remplis doivent être archivé. Comme toutes les modifications
faites sur la base de données sont enregistrées dans les fichiers de redo log online,
le DBA peut utiliser la sauvegarde présente sur le disque dur et les fichiers de redo
log archivés pour restaurer la base de données sans perdre aucune donnée comité.
On peut archiver les fichiers de redo log :
• Manuellement.
• Automatiquement : Méthode recommandée.
Le paramètre d’initialisation LOG_ARCHIVE_START, lorsqu’il est à TRUE
indique que l’archivage se fait automatiquement. A FALSE, indique que le DBA
le fait manuellement. En mode automatique, l’archivage se fait grâce au process
ARCn, et manuellement avec des requêtes SQL.
Page 64
29/06/2006
7. Gérer les Tablespaces et les fichiers de données
7.1. Architecture d'une base de données
7.1.1. Vue d'ensemble de la structure d'une base de données
Les performances d'une base de données dépendent en grande partie de la gestion
efficace des ressources du système, telles que l'espace du disque dur. Afin
d'obtenir les performances optimales pour la base de données, Oracle facilite un
contrôle poussé de la gestion de l'espace disque en divisant la base de données en
structures logiques et physiques.
Les structures logiques et physiques qui constituent la base de données Oracle sont
elles-mêmes constituées d'autres composants.
La structure physique est constituée de fichiers de contrôle, de fichiers redo log
online et de fichiers de données.
Les composants de la structure logique d'une base de données sont les tablespaces,
les segments, les extents et les blocs de données.
Lorsque les composants de la structure logique sont créés par Oracle, l'espace est
alloué dans la base de données en fonction de paramètres prédéfinis.
L'administrateur de la base de données peut remplacer ou configurer ces
paramètres afin d'optimiser l'utilisation de l'espace.
7.1.2. Relations
La séparation des structures logique et physique d'une base de données Oracle
facilite le contrôle poussé de la gestion de l'espace disque. L'administrateur peut
configurer les paramètres d'allocation d'espace aux composants physiques et
logiques de la base de données.
Pour utiliser efficacement l'espace du disque dur, il est important de connaître les
relations entre les composants physiques et logiques de la base de données. Il est
important également de savoir comment l'espace est alloué dans la base de
données.
La première entité est la base de données Oracle. Elle est divisée en structures
logique et physique.
La base de données est divisée en zones d'espace logiques plus petites, appelées
tablespaces.
Chaque tablespace d'une base de données Oracle est constitué d'un ou plusieurs
fichiers appelés fichiers de données. Il s'agit de structures physiques conformes au
système d'exploitation sur lequel le serveur Oracle fonctionne.
Page 65
29/06/2006
Un tablespace est constitué de segments. Un segment est l'espace alloué pour un
type spécifique de structure de stockage logique dans un tablespace. Les segments
d'index, segments temporaires, rollback segments et segments de données
représentent quelques exemples de segments.
Un segment, tel qu'un segment de données, peut être réparti sur plusieurs fichiers
appartenant au même tablespace.
Le niveau suivant de la structure logique d'une base de données est l'extent. Un
extent est un ensemble de blocs contigus. Chaque segment est constitué d'un ou
plusieurs extents. Le DBA peut ajouter des extents à un segment manuellement.
Un extent ne peut pas être réparti sur plusieurs fichiers de données.
Les blocs de données constituent le dernier niveau de granularité. Les données
d'une base de données Oracle sont stockées dans les blocs de données.
Un bloc de données correspond à un ou plusieurs blocs de fichiers physiques
alloués à partir de fichier de données existant.
7.1.3. Caractéristiques d'un tablespace
La structure de stockage logique la plus importante d'une base de données est le
tablespace.
Caractéristiques d'un tablespace :
• Un tablespace ne peut appartenir qu'à une seule base de données
• Un tablespace est constitué d'un ou plusieurs fichiers du système
d'exploitation.
Page 66
29/06/2006
• Les tablespace peuvent être mis offline lorsque la base de données
fonctionne. Cette fonctionnalité permet à l'administrateur de contrôler les
données sans arrêter la base de données.
• Tous les tablespaces, à l'exception du tablespace SYSTEM ou d'un
tablespace avec un undo segment actif, peuvent être mis offline. Dans ce
cas, la base de données continue de fonctionner. L'administrateur peut ainsi
assurer la gestion des données sans que la base de données ne soit
indisponible.
• L'état d'un tablespace peut être basculé entre lecture écriture et lecture
seule. Cette fonctionnalité permet d'empêcher les utilisateurs de modifier
des données stockées et inversement.
7.1.4. Utilisations d'un tablespace
Le tablespace présente plusieurs utilisations possibles permettant la gestion
efficace de l'espace disque.
Utilisations d'un tablespace :
• Aider les serveurs Oracle pour le contrôle de l'allocation de l'espace et
l'attribution de quotas d'espace aux utilisateurs.
• Contrôler la disponibilité des données. Ce contrôle est effectué par la mise
online ou offline des tablespaces individuels.
• Améliorer les performances E/S et réduire les contentions E/S grâce à la
répartition du stockage des données sur plusieurs périphériques.
• Utiliser lors des opérations de sauvegardes et de restaurations partielles.
• Utiliser pour stocker de grandes quantités de données statiques sur des
périphériques en lecture seule.
7.1.5. Caractéristiques d'un fichier de données
Un tablespace est la structure de stockage logique la plus importante d'une base de
données. Les données du tablespace sont stockées dans les structures de stockage
physiques appelées fichiers de données.
Chaque tablespace d'une base de données Oracle est constitué d'un ou plusieurs
fichiers de données.
Les fichiers de données sont les structures physiques conformes au système
d'exploitation sur lequel le serveur Oracle est installé.
Caractéristiques d'un fichier de données :
• Un fichier de données ne peut appartenir qu'à un seul tablespace. Ceci
permet à un administrateur de base de données de procéder à une
Page 67
29/06/2006
sauvegarde du fichier de données sans affecter la disponibilité de tout autre
tablespace.
• Un fichier de données est créé par le serveur Oracle. Cependant, la quantité
disque à occuper par le fichier de données est spécifiée par l'administrateur
de la base de données.
Le serveur Oracle crée le fichier de données avec la quantité spécifiée
d'espace disque plus un léger dépassement.
• Un fichier de données peut être modifié par l'administrateur de la base de
données après sa création. L'administrateur peut également spécifier que la
taille d'un fichier de données doit augmenter de façon dynamique, tout
comme le nombre d'objets du tablespace.
Cette caractéristique permet à l'administrateur de la base de données de contourner
la limitation du paramètre MAXDATAFILES et permet à la base de données d'être
constituée de moins de fichiers de données pour chaque tablespace. Elle évite
également que les utilisateurs et les applications ne subissent des erreurs dues au
manque d'espace libre dans un tablespace.
7.2. Créer des Tablespaces
7.2.1. Types de tablespaces
Lorsque l'administrateur crée une base de données, un tablespace appelé SYSTEM
est créé par défaut.
Tous les autres tablespaces, appelés tablespaces non-SYSTEM, sont créés par
l'administrateur de la base de données.
L'administrateur créé un tablespace non-SYSTEM pour gérer facilement la base de
données et permettre aux utilisateurs de l'utiliser de façon efficace.
Le tablespace SYSTEM est indispensable pour le bon fonctionnement de toute
base de données. Le tablespace non-SYSTEM n'est pas obligatoire.
Le tablespace SYSTEM contient les informations du dictionnaire de données, les
définitions des procédures stockées, des packages et des triggers base de données,
les undo segments SYSTEM.
D'autre part, les tablespaces non-SYSTEM peuvent contenir les segments de
données, les segments d'index, les segments temporaires et les undo segments. Ils
séparent aussi les données dynamiques et statiques
Le tablespace SYSTEM contient le rollback segment SYSTEM, tandis qu'un
tablespace non-SYSTEM peut contenir tout autre rollback segment.
Page 68
29/06/2006
Il n'est pas souhaitable de stocker les données utilisateur dans le tablespace
SYSTEM. Si le tablespace SYSTEM contient des données utilisateur, vous ne
pouvez pas procéder à des sauvegardes offline des données sans arrêter la base de
données.
7.2.2. Création d un tablespace
L'administrateur est responsable de la gestion des données des bases de données.
Un moyen efficace de gestion des données consiste à créer des tablespaces pour
différents groupes d'utilisateurs, en créant, par exemple, un tablespace marketing
pour le personnel du service marketing.
Syntaxe de création d'un tablespace :
CREATE TABLESPACE tablespace
[DATAFILE clause]
[MINIMUM EXTENT integer[K|M]]
[BLOCKSIZE integer [K]]
[LOGGING|NOLOGGING]
[DEFAULT storage_clause ]
[ONLINE|OFFLINE]
[PERMANENT|TEMPORARY]
• DATAFILE spécifie le ou les fichiers de données liés au tablespace. M
spécifie la taille en Mo ou Kbits.
• LOGGING option par défaut qui spécifie que toutes les tables, indexes et
partitions dans le tablespace génèrent des infos de redo log.
• DEFAULT définit les paramètres de stockage par défaut pour tous les
objets créés dans le tablespace.
• OFFLINE rend le tablespace indisponible immédiatement après la création.
• PERMANENT spécifie que le tablespace peut être utilisé pour contenir des
objets permanents.
• TEMPORARY cette clause est utilisée pour les objets temporaires.
storage_clause := (
[INITIAL integer [K|M]]
[NEXT integer [K|M]]
[MINEXTENTS integer ]
[MAXENTENTS {integer | UNLIMITED}]
[PCTINCREASE integer ])
Page 69
29/06/2006
Exemple :
Créez un tablespace nommé ACCOUNTS.
Le nom du fichier de données est accts01.dbf et sa taille est de 10 Mo.
Nom du tablespace : ACCOUNTS
Nom du fichier de données : accts01.dbf
Taille du fichier de données : 10 Mo
Emplacement : c:\oracle\oradata\database
Se connecter à la base de données avec les privilèges adéquates :
CREATE TABLESPACE accounts
DATAFILE 'c:\oracle\oradata\database\accts01.dbf' SIZE 10M;
Tablespace created.
Cette commande est relativement complexe, Oracle offre une interface graphique,
appelée Oracle Storage Manager, pour créer un tablespace.
Lors de la création de tablespaces, le nombre maximal de tablespaces pouvant être
affectés à chaque base de données est de 64 000 et le nombre maximal de fichiers
de données pouvant être affectés à chaque tablespace est de 1 023.
7.2.3. Gestion de l espace dans les tablespaces
Les tablespaces peuvent être gérés avec les tables du dictionnaire de données ou
des tables binaires d’allocations (bitmaps). L’une de ces méthodes doit être choisie
lorsque l’on crée un tablespace et ne pourra être changée par la suite.
Locally Managed Tablespaces
Un tablespace qui gère ses propres extents garde un bitmap dans chaque fichier de
données pour garder une trace des blocs libres ou utilisés dans ces fichiers de
données. Chaque bitmap correspond à un bloc ou un groupe de blocs. Lorsqu’un
extent est alloué ou prêt à être réutilisé, le serveur Oracle change la valeur du
bitmap pour mettre à jour le nouveau statut des blocs.
Dictionary-Managed Tablespaces
Pour un tablespace qui utilise le dictionnaire de données pour gérer les extents, le
serveur Oracle met à jour les tables appropriées dans le dictionnaire de données
dès qu’un extent est alloué ou désalloué.
7.2.4. Locally Managed tablespaces
L’option LOCAL de la clause EXTENT MANAGEMENT spécifie qu’un
tablespace est géré localement. Cette option est par défaut.
Page 70
29/06/2006
extent_management_clause :==
[ EXTENT MANAGEMENT
[ DICTIONARY | LOCAL
[ AUTOALLOCATE | UNIFORM [SIZE integer[K|M]] ] ] ]
• DICTIONARY signifie que le tablespace est géré grâce aux tables du
dictionnaire.
• LOCAL signifie que le tablespace est géré localement avec un bitmap. Si
c’est clause est utilisé, on ne peut utiliser DEFAULT storage_clause,
MINIMUM EXTENT, ou TEMPORARY.
• AUTOALLOCATE est l’option par défaut. Les utilisateurs ne peuvent
spécifier une taille d’extent.
• UNIFORM signifie que le tablespace est géré avec des extents de tailles
uniformes de SIZE bytes.
CREATE TABLESPACE userdata
DATAFILE ‘u01/oradate/userdata01.dbf’ SIZE 500M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256k;
Les avantages des tablespaces gérés localement sont les suivants :
• Pas de contention en mise a jour au niveau du dictionnaire.
• Par conséquence pas d'utilisation de Rollback segment pour ces
transactions.
• Pas de soucis de gestion de l'espace (calcul d'un espace de stockage
adéquat).
• "coalesce" automatique (fusion des espaces libres contigus pour optimiser
l'espace libre).
7.2.5. Dictionary Managed Tablespaces
Ce genre de tablespace a une gestion du stockage customisé, ceci est beaucoup
plus flexible que les tablespaces gérés localement mais bien moins efficace.
CREATE TABLESPACE userdata
DATAFILE ‘/u01/oradate/userdata01.dbf’ SIZE 500M
EXTENT MANAGEMENT DICTIONARY
DEFAULT STORAGE (initial 1M NEXT 1M) ;
7.2.6. Paramètres de stockage
Page 71
29/06/2006
L'efficacité d'un tablespace dépend de la quantité d'espace utilisée par un segment.
Ainsi, il est important de connaître les paramètres qui influent sur la quantité
d'espace utilisée par un segment.
Cinq paramètres déterminent et contrôlent la quantité d'espace utilisée par un
segment. Il s'agit des paramètres INITIAL, NEXT, MAXEXTENTS,
MINEXTENTS et PCTINCREASE.
La taille du premier extent de tout segment est définie par le paramètre INITIAL.
La taille minimale du premier extent est de deux blocs ou de
2*DB_BLOCK_SIZE. La taille par défaut est de cinq blocs ou de
5*DB_BLOCK_SIZE.
Le paramètre NEXT fait référence à la taille du deuxième extent. La taille
minimale de l'extent suivant est d'un bloc et la taille par défaut est de cinq blocs ou
de 5*DB_BLOCK_SIZE.
La valeur du paramètre MINEXTENTS détermine le nombre d'extent alloués lors
de la création du segment. Par défaut, la valeur minimale est de un.
Le PCTINCREASE est le pourcentage d'augmentation de la taille de NEXT.
Par exemple, NEXT est défini sur 200 Ko et PCTINCREASE est défini sur 50%.
Dans une telle situation, le deuxième extent présente une taille de 200 Ko, le
troisième extent une taille de 300 Ko et le quatrième extent une taille de 450 Ko.
La valeur minimale du paramètre PCTINCREASE est de zéro et sa valeur par
défaut est de 50. La valeur calculée est arrondie à la valeur immédiatement
supérieure de 5*DB_BLOCK_SIZE.
Page 72
29/06/2006
Le paramètre MAXEXTENTS détermine le nombre maximum d'extents qu'un
segment peut contenir.
La valeur minimale est de un. La valeur maximale par défaut dépend de la taille
des blocs de données.
La taille maximale peut également être spécifiée par le mot clé UNLIMITED,
équivalent à une valeur de 2 147 483 645.
Il est important de garder à l'esprit que les valeurs de ces paramètres doivent
représenter un objet typique qui sera créé dans le tablespace. Cependant, ces
paramètres de stockage peuvent être rejetés de la création de segments individuels.
Il est possible d’utiliser la commande ALTER TABLESPACE pour modifier les
paramètres par défaut. Par exemple :
ALTER TABLESPACE userdata
MINIMUM EXTENT 2M;
Ou :
ALTER TABLESPACE userdata
DEFAULT STORAGE (
INITIAL 2M
NEXT 2M
MAXEXTENTS 999);
7.2.7. Les Undo Tablespaces
Les tablespaces de undo sont une nouveauté de Oracle 9i. Ils peuvent remplacer
les rollback segments qui doivent être gérés de manière manuelle et servent au
stockage de segments d’images avant modification des données pour des
annulations éventuelles. Ils sont utilisés uniquement pour stocker les segments de
undo. La gestion des segments de undo se fait grâce aux paramètres du fichier
d’initialisation :
• UNDO_MANAGEMENT : MANUAL (rollback segments) ou AUTO
(géré par l’instance donc undo tablespaces).
• UNDO_TABLESPACE : Nom du tablespace de undo.
• UNDO_SUPRESS_ERRORS : Si positionné à TRUE, cela supprime les
messages d’erreurs affichés, lorsqu’on est en mode AUTO et qu’une
opération manuelle est exécutée (telle que ALTER ROLLBACK
SEGMENT).
• UNDO_RETENTION : Durée pendant laquelle la donnée modifiée est
gardée.
Pour créer un tablespace de undo :
Page 73
29/06/2006
CREATE UNDO TABLESPACE undo1
DATAFILE ‘u01/oradate/undo101.dbf’ SIZE 40M;
Les informations d’utilisation des segments de UNDO sont stockées dans la vue
V$UNDOSTAT.
7.3. Tablespace temporaire
7.3.1. Tablespace temporaire
Ces tablespaces sont apparus avec la 9i et remplacent les segments temporaires qui
étaient placés dans les tablespaces standard. Il est nécessaire de créer une
tablespace temporaire par défaut autre que SYSTEM, où seront stockées
uniquement les données temporaires (création d’index, jointures, tris, etc...). Un
segment temporaire permet d’avoir un gain de performance lorsque, par exemple,
plusieurs tris occupent trop de place pour la mémoire et doivent être stockés sur le
disque dur temporairement.
Ainsi la taille du segment de tris va augmenter en allouant des extents jusqu’à ce
que la taille du segment soit suffisante pour stocker toutes les données que
calculent les opérations de tris de l’instance.
La commande pour créer un tablespace temporaire est la suivante :
CREATE TEMPORARY TABLESPACE temp
TEMPFILE ‘u01/oradate/temp01.dbf’ SIZE 500m
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 10M;
Les tablespaces temporaires gérés localement ont des fichiers de données
temporaires (tempfiles) qui sont identiques aux fichiers de données ordinaires.
Mais certaines différences existent. Tout d’abord, les tempfiles sont toujours en
mode NOLOGGING, ils ne peuvent être en lecture seule ou renommés.
On ne peut créer de tempfile avec la commande ALTER DATABASE.
7.3.2. Tablespace temporaire par défaut
Lorsque une base de données est crée sans tablespace temporaire par défaut, le
tablespace qui est assigné aux utilisateurs créés sans la clause TEMPORARY
TABLESPACE est le tablespace SYSTEM.
Pour éviter que le tablespace système soit utilisé comme tablespace temporaire, il
est nécessaire de créer un tablespace temporaire et de modifier la base de données
avec la commande :
ALTER DATABASE
Page 74
29/06/2006
DEFAULT TEMPORARY TABLESPACE temp;
Après cela, tous les utilisateurs qui n’étaient pas assignés à un tablespace
temporaire seront affectés directement à temp.
7.3.3. Restrictions sur les Tablespace temporaire par défaut
Les tablespaces temporaires ne peuvent être mis offline et ne peuvent être
supprimés tant qu’un nouveau tablespace par défaut soit crée. D’autre part, un
tablespace temporaire ne peut devenir un tablespace permanent.
7.4. Manipulation de Tablespace
7.4.1. Offline Status
L'administrateur doit assurer la gestion de bases de données. Dans le cadre des
tâches de maintenance, telles que la relocalisation d'un fichier de données,
l'administrateur peut être amené à rendre indisponible un tablespace tout en
autorisant l'accès normal au reste de la base de données.
Pour cela, il peut mettre offline des tablespaces individuels.
La commande SQL permettant de mettre offline un tablespace est la suivante :
ALTER TABLESPACE tablespace
{ ONLINE | OFFLINE [ NORMAL | TEMPORARY |
IMMEDIATE ] } ;
Mettez le tablespace ACCOUNTS offline.
ALTER TABLESPACE accounts OFFLINE NORMAL;
Tablespace altered
Oracle offre également une interface graphique, appelée Oracle Storage Manager,
pour mettre un tablespace offline.
Le tablespace SYSTEM, et les tablespaces avec des segments de undo ou
temporaires actifs ne peuvent être mis offline.
7.4.2. Tablespace en lecture seul
Pour répondre aux exigences en matière d'organisation, il se peut que
l'administrateur dispose de tablespaces destinés à contenir des données de nature
Page 75
29/06/2006
statique. Afin d'éviter d'avoir à procéder à des opérations de sauvegarde et de
restauration de telles données statiques, l'administrateur peut mettre ces
tablespaces en lecture seule. Ceci permet également de garantir qu'aucune
opération d'écriture ne sera effectuée sur les données.
Les fichiers de données peuvent être stockés sur des supports en lecture seule, tels
que des CD-ROM ou des disques WORM, car le serveur Oracle ne met jamais à
jour les fichiers d'un tablespace en lecture seule.
La commande SQL permettant de mettre un tablespace en mode lecture seule est
la suivante :
ALTER TABLESPACE tablespace READ { ONLY | WRITE } ;
Exemple :
Mettez le tablespace ACCOUNTS en lecture seule.
ALTER TABLESPACE accounts READ ONLY ;
Tablespace altered.
Outre la commande SQL, Oracle offre une interface graphique nommée Oracle
Storage Manager permettant de mettre un tablespace en mode lecture seule.
Il est possible de supprimer des objets comme des index ou des tables dans un
tablespace en lecture seul. En effet, la commande DROP met à jour seulement le
dictionnaire de données mais pas les fichiers physiques qui constituent le
tablespace.
Cependant, plusieurs conditions doivent être remplies pour pouvoir mettre un
tablespace en mode lecture seule :
• le tablespace doit être online,
• aucune transaction active ne doit être en cours d'exécution sur ce tablespace
• le tablespace ne doit contenir aucun rollback segment actif et ne doit pas
être actuellement impliqué dans une sauvegarde online.
Le moyen recommandé de se conformer à ces restrictions consiste à démarrer
l'instance en mode restreint.
En outre, la mise en lecture seule des tablespaces provoque un point de
synchronisation sur les fichiers de données.
Page 76
29/06/2006
7.4.3. Tablespaces en lecture seul sur des supports en lecture
seul
L'administrateur de bases de données souhaite diminuer le temps passé sur les
sauvegardes de données. Un moyen de diminuer ce temps consiste à stocker les
données statiques dans des tablespaces en lecture seule, puis à les stocker sur des
supports en lecture seule.
Le stockage des données en lecture seule se déroule en trois étapes :
• mettre le tablespace en lecture seule,
• copier tous les fichiers de données du tablespace sur des supports en lecture
seule,
• renommer les fichiers de données afin qu'ils pointent vers le nouvel
emplacement.
7.4.4. Supprimer un Tablespace
En raison d'une modification des besoins des utilisateurs, il se peut que certains
tablespaces ne soient plus nécessaires. La présence de ces tablespaces constitue un
gaspillage d'espace disque. Pour résoudre ce problème, Oracle permet de
supprimer de tels tablespaces.
La commande SQL permettant de supprimer de tels tablespaces est la suivante :
DROP TABLESPACE tablespace
[INCLUDING CONTENTS [CASCADE CONSTRAINTS] ];
CASCADE CONSTRAINTS supprime les contraintes d'intégrité référentielle des
tables se trouvant en dehors du tablespace. Il s'agit des contraintes qui font
référence aux clés primaires et uniques des tables du tablespace supprimé.
Exemple :
Supprimez le tablespace ACCOUNTS
DROP TABLESPACE accounts
INCLUDING CONTENTS CASCADE CONSTRAINTS ;
Tablespace dropped.
Outre la commande SQL, Oracle offre une interface graphique, Oracle Storage
Manager, permettant de supprimer un tablespace.
Il est important de suivre un certain nombre de règles lors de la suppression d'un
tablespace.
Page 77
29/06/2006
• Il faut s'assurer que les transactions n'accèdent à aucun des segments du
tablespace. Le meilleur moyen de garantir cela consiste à mettre d'abord le
tablespace offline.
• Si le tablespace est supprimé avec la commande SQL, il est important de se
souvenir qu'un tablespace contenant encore des données ne peut pas être
supprimé sans l'option INCLUDING CONTENTS.
Lorsque le tablespace contient de nombreux objets, l'utilisation de l'option
INCLUDING CONTENTS peut générer un grand nombre de rollback. Une
alternative consiste à utiliser un script pour supprimer un par un les objets du
tablespace, puis à supprimer le tablespace.
7.4.5. Conséquences de la suppression de tablespaces
Pour économiser de l'espace disque, l'administrateur supprime les tablespaces qui
ne sont plus nécessaires.
Voici les conséquences de la suppression d'un tablespace :
• Les données du tablespace supprimé ne sont plus disponibles, elles ne
peuvent donc plus être interrogées.
• Lors de la suppression d'un tablespace, seuls les pointeurs de fichiers dans
le fichier de contrôle de la base de données associée sont supprimés. Pour
récupérer l'espace disque utilisé par le tablespace, il faut supprimer
explicitement les fichiers de données au niveau du système d'exploitation.
• Si un tablespace en lecture seule est supprimé, les segments qu'il contient
sont également supprimés. Dans ce cas, seuls le dictionnaire de données et
les fichiers de données doivent être mis à jour.
7.5. Fichiers de manipulation des données
7.5.1. Mettre en place l extension automatique des fichiers de
données
La clause AUTOEXTEND permet d’autoriser ou non l’extension automatique des
fichiers de données. Les commandes suivantes peuvent être utilisées pour spécifier
l’extension automatique.
• CREATE DATABASE
• CREATE TABLESPACE … DATAFILE
• ALTER TABLESPACE … ADD DATAFILE
Page 78
29/06/2006
Exemple :
ALTER DATABASE DATAFILE
‘u01/oradata/userdata02.dbf’ SIZE 200m
AUTOEXTEND ON NEXT 10M MAXSIZE 500M ;
7.5.2. Changer la taille des fichiers de données manuellement
L'administrateur doit estimer les besoins d'espace d'une base de données.
Cependant, lorsque l'administrateur utilise réellement la base de données, il se peut
qu'il se rende compte que son estimation des besoins d'espace est erronée. Pour
faire face à ce problème, Oracle permet de redimensionner les fichiers de données.
La commande SQL permettant de redimensionner les fichiers de données d'un
tablespace est la suivante :
DATAFILE 'filename' [,'filename']
RESIZE integer [ K | M ];
Exemple :
Affectez au fichier de données accts01.dbf du répertoire c:\ora92\database la
nouvelle taille de 3 Mo à l'aide SQL*Plus :
ALTER DATABASE
DATAFILE 'c:\ora92\database\accts01.dbf'
RESIZE 3M ;
statement processed
4.5.3.
Ajouter un fichier de données à un Tablespace
Lorsque les tables sont remplies avec des objets pendant une période donnée,
l'espace disponible dans les fichiers de données s'épuise. Pour faire face à cette
situation, Oracle vous permet d'ajouter des fichiers de données aux tablespaces.
Cette opération alloue davantage d'espace disque aux objets de la base de données.
La commande SQL permettant d'ajouter un fichier de données à un tablespace est
affichée à l'écran.
ADD DATAFILE 'filespec' [auto_extend_clause];
Page 79
29/06/2006
Exemple :
Ajoutez un fichier de données nommé accts02.dbf de 1 000 Ko situé dans le
répertoire c:\ora92\database au tablespace ACCOUNTS.
ALTER TABLESPACE accounts
ADD DATAFILE 'c:\ora92\database\accts02.dbf' SIZE 1000K;
tablespace altered.
Outre la commande SQL, Oracle offre une interface graphique appelée Oracle
Storage Manager afin
de permettre d'ajouter un fichier de données à un
tablespace.
4.5.4.
Déplacer un fichier de données :
ALTER TABLESPACE Fichier de données non-SYSTEM :
Avec l'augmentation du nombre d'enregistrements de la base de données, la taille
du fichier de données augmente également. Par conséquent, il peut arriver que le
support de stockage du fichier de données ne dispose plus de suffisamment
d'espace. Pour faire face à ce problème, Oracle permet de déplacer les fichiers de
données vers un nouvel emplacement.
RENAME DATAFILE 'filename' [,'filename']...
TO 'filename' [,'filename']... ;
Exemple :
Déplacez le fichier de données accts01.dbf du tablespace ACCOUNTS du
répertoire
c:\ora92\database.
• Mettre offline le tablespace ACCOUNTS en mode normal
ALTER TABLESPACE accounts OFFLINE NORMAL;
Tablespace altered
• Déplacez le fichier de données avec les commandes du système
d'exploitation
copy c:\ora92\database\accts01.dbf
Page 80
29/06/2006
d:\ ora92\database\accts01.dbf
1 file(s) copied
• Modifier le chemin d'accès du fichier de données
ALTER TABLESPACE accounts
RENAME DATAFILE 'c:\ora92\database\accts01.dbf'
TO 'd:\ ora92\database\accts01.dbf' ;
Tablespace altered.
• Mettez online le tablespace ACCOUNTS
ALTER TABLESPACE accounts ONLINE ;
Tablespace altered
• Supprimez le fichier d'origine dans le répertoire c:\ora92\database.
Oracle Storage Manager peut déplacer les fichiers de données appartenant aux
seuls tablespaces non-SYSTEM et ne contenant aucun rollback segment ou
segment temporaire actif.
Fichier de données SYSTEM :
Le tablespace SYSTEM est nécessaire pour que la base de données fonctionne
correctement. Cependant, dans certaines situations, telles que le remplacement du
disque dur sur lequel les fichiers de données du tablespace SYSTEM sont
actuellement stockés, l'administrateur doit déplacer les fichiers de données du
tablespace SYSTEM vers un nouvel emplacement.
Oracle permet de déplacer un fichier de données du tablespace SYSTEM vers un
nouvel emplacement. Voici les étapes à suivre :
• Arrêter la base de données
• Utiliser une commande du système d'exploitation pour déplacer les fichiers
de données vers le nouvel emplacement.
• Monter la base de données
• Déplacer le fichier de données du tablespace SYSTEM
• Ouvrir la base de données
Il faut toujours fournir les noms complets des fichiers accompagnés de leur
chemin d'accès pour identifier les anciens et les nouveaux fichiers de données.
Exemple :
Page 81
29/06/2006
Déplacez le fichier de données SYS1ORCL.ORA du répertoire c:\ora92\database
appartenant au tablespace SYSTEM vers le répertoire d:\orclbackup.
• Montez la base de données
• Copiez le fichier dans le répertoire d:\orclbackup avec les commandes du
système d'exploitation
• Déplacer les fichiers de données dans la base de données :
ALTER DATABASE
RENAME FILE 'c:\ora92\database\sys1orcl.ora'
TO 'd:\orclbackup\sys1orcl.ora';
• Ouvrir la base de données
7.6. Autres options sur les Tablespaces
7.6.1. Configurer OMF pour la création de Tablespace
Lorsque l’on configure OMF pour créer un tablespace, un paramètre
d’initialisation est spécifié :
DB_CREATE_FILE_DEST. Ce paramètre stocke le chemin par défaut des
fichiers de données.
Il existe deux moyens de le configurer, soit directement dans le fichier
d’initialisation soit avec la commande suivante :
ALTER SYSTEM SET
db_create_file_dest = ‘u01/oradate/db01’;
7.6.2. Créer des Tablespaces avec OMF
Lorsque l’on crée un tablespace avec OMF, la clause DATAFILE n’est pas
obligatoire. Par défaut les fichiers ont une taille de 100M, paramétrés à autoextend
et de taille maximale illimitée.
CREATE TABLESPACE apps2_data DATAFILE SIZE 20M;
7.6.3. Récupérer des informations sur les Tablespaces
L'organisation des données dans le tablespaces présente plusieurs avantages.
Avantages liés à l'utilisation de plusieurs tablespaces :
• L'utilisation de plusieurs tablespaces garantit que les données utilisateur et
les données du dictionnaire de données peuvent être conservées
Page 82
29/06/2006
•
•
•
•
•
•
séparément. Ceci permet une souplesse des opérations sur la base de
données.
Les données des différentes applications peuvent être stockées dans des
tablespaces distincts. Ceci permet de garantir une bonne disponibilité des
données.
La réduction des contentions constitue un autre avantage de l'utilisation de
plusieurs tablespaces. Les contentions E/S sont réduites grâce au stockage
des fichiers de données de différents tablespaces sur des disques durs
distincts.
L'utilisation de plusieurs tablespaces constitue une protection contre la
perte définitive de données. Cette protection est assurée par la séparation
des rollback segments et des segments de données.
L'utilisation de plusieurs tablespaces offre un degré élevé de flexibilité dans
l'administration des données, car les tablespaces individuels peuvent être
mis offline. Ceci permet également de garantir une bonne disponibilité des
données.
L'utilisation de plusieurs tablespaces permet également la sauvegarde des
tablespaces individuels.
L'utilisation de plusieurs tablespaces permet de réserver des tablespaces
pour un type particulier d'activité sur la base de données, tel que des
activités de mise à jour, des opérations en lecture seule et le stockage
temporaire de segments. Ceci permet d'améliorer l'efficacité de la base de
données.
L'administrateur a besoin d'informations sur les tablespaces afin d'assurer une
gestion efficace de la base de données.
Oracle offre des vues du dictionnaire de données et des vues dynamiques sur les
performances, qui vous permettent de rassembler des informations sur les
tablespaces. Les noms des vues dynamiques sur les performances et des vues du
dictionnaire de données sont les suivantes :
• DBA_TABLESPACES
Cette vue contient des informations sur les noms, les paramètres de stockage par
défaut, les types et la disponibilité de tous les tablespaces.
Exemple :
Pour assurer une gestion efficace de la base de données, l'administrateur souhaite
obtenir l'emplacement et les paramètres de stockage par défaut de tous les
tablespaces.
Page 83
29/06/2006
SELECT * FROM dba_tablespaces ;
• DBA_DATA_FILES
Cette vue contient des informations sur les fichiers de données appartenant à un
tablespace spécifique ainsi que sur leurs paramètres AUTOEXTEND
Exemple :
L'administrateur souhaite afficher les tablespaces auxquels les fichiers de données
appartiennent, ainsi que la valeur de l'option AUTOEXTEND.
SELECT * FROM dba_data_files;
• V$DATAFILE
Cette vue dynamique contient des informations sur le nom du fichier de données,
la taille, la disponibilité et les noms des tablespaces auxquels les fichiers de
données appartiennent.
• V$TEMPFILE
Cette vue contient des informations sur les tablespaces temporaires.
Page 84
29/06/2006

Systèmes de Gestion Des Bases de Données Dr Mohamed Salah

Transcription

Documents pareils

L`oracle de Margyle

voir le détail de l`offre

oracle 10g administration BASES DE DONNÉES ORACLE

Entreprise 7 - Offre 33 - DBA ORACLE HF

Transformateur de log

Annonce JOB France IT Production systems Integrator

CONTROLE SUR LES FONCTIONS LOGARITHMES PROC SUJET 1

Consultant Chef de projet Inform atique

Cours à la carte 2014-2015 - Collège de Bois-de

Détermination de E°(Ox/Red) à partir d`autres potentiels rédox