Oracle 11g Administration: Guide Complet

Oracle 11g
Administration
Olivier HEURTEL
Résumé
Ce livre sur Oracle 11g s’adresse à tout informaticien désireux de maîtriser les tâches d’administration des bases de données Oracle. Après
une présentation générale de l’architecture interne d’un serveur Oracle (mémoire, processus), ce livre détaille les différentes tâches
d’administration d’une base de données : installation (sous Windows et sous Linux), configuration Oracle Net, création d’une nouvelle base de
données, gestion de la mémoire, gestion du stockage, gestion des utilisateurs et des droits, sauvegardes et restaurations avec RMAN (Recovery
Manager).
Une attention particulière est apportée aux nouvelles fonctionnalités d’Oracle 11g qui facilitent le travail de l’administrateur : réglage automatique
de la mémoire, référentiel de Diagnostique Automatique, mots de passe sensibles à la casse, rétrécissement d’un tablespace temporaire géré
localement, nouvelle ergonomie de Oracle Entreprise Manager Database Control, etc.
L’ouvrage contient de nombreux conseils pratiques et recommandations et présente les solutions qui peuvent être apportées aux problèmes les
plus courants.
Des exemples de scripts sont en téléchargement sur cette page.
L'auteur
Après plus de huit ans passés en société de service, où il a successivement occupé les postes de développeur, chef de projet puis directeur
de projet, Olivier Heurtel a démarré une activité de consultant/formateur indépendant spécialisé sur les bases de données (Oracle), le
développement Web (PHP) et les systèmes décisionnels. Olivier Heurtel est certifié Oracle Certified Professional et cet ouvrage est le fruit de
l'expérience acquise au cours de nombreuses prestations de mise en œuvre de bases Oracle en entreprise.
Ce livre numérique a été conçu et est diffusé dans le respect des droits d’auteur. Toutes les marques citées ont été déposées par leur éditeur respectif. La loi du 11 Mars
1957 n’autorisant aux termes des alinéas 2 et 3 de l’article 41, d’une part, que les “copies ou reproductions strictement réservées à l’usage privé du copiste et non destinées
à une utilisation collective”, et, d’autre part, que les analyses et les courtes citations dans un but d’exemple et d’illustration, “toute représentation ou reproduction intégrale,
ou partielle, faite sans le consentement de l’auteur ou de ses ayants droit ou ayant cause, est illicite” (alinéa 1er de l’article 40). Cette représentation ou reproduction, par
quelque procédé que ce soit, constituerait donc une contrefaçon sanctionnée par les articles 425 et suivants du Code Pénal. Copyright Editions ENI
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Installation du serveur
1. Introduction
L’installation d’Oracle sur un serveur nécessite une bonne compréhension de l’architecture Oracle et des compétences
minimales sur le système d’exploitation ; ces compétences sont réduites au strict minimum pour la plate­forme
Windows mais sont un peu plus avancées pour les autres plates­formes.
Dans tous les cas, il est impératif de se référer à la documentation Oracle spécifique à la plate­forme :
●
Oracle® Database Installation Guide for ...
●
Oracle® Database Quick Installation Guide for ...
●
Oracle® Database Release Notes for ...
La documentation "Quick Installation Guide" décrit comment installer rapidement Oracle en utilisant des options par
défaut. Cette documentation est en général suffisante pour une première prise en main.
L’objectif de ce chapitre est de présenter les principales étapes et options de l’installation, en se limitant aux plates­
formes Windows et Linux (en l’occurrence Red Hat Enterprise Linux 4) ; ce chapitre n’a pas vocation à remplacer les
manuels d’installation fournis par Oracle. Par ailleurs, l’ouvrage dans son ensemble apporte les compétences sur
l’architecture Oracle nécessaires à la compréhension des différentes phases de l’installation.
Sur OTN (Oracle Technology Network : http://www.oracle.com/technology/index.html), moyennant une
inscription gratuite au site, vous pouvez télécharger les produits Oracle à des fins de développement ou
d’évaluation.
Sur Metalink (site du support Oracle : https://metalink.oracle.com/), vous pouvez trouver des notes
d’installation précises, à jour, pour chaque version d’Oracle, chaque système d’exploitation et chaque
architecture (32/64 bits) ; n’hésitez pas à les consulter.
2. Principales étapes de l’installation
Installer Oracle sur un serveur comporte trois grandes phases :
●
pré­installation : préparer le système d’exploitation ;
●
installation : installer les produits Oracle ;
●
post­installation : terminer l’installation et configurer certains composants Oracle.
Sur plate­forme Windows, la phase de pré­installation est réduite au strict minimum :
●
vérifier les pré­requis logiciels et matériels ;
●
se connecter en tant que membre du groupe Administrateur.
Sur plate­forme Unix ou Linux, la phase de pré­installation comporte par contre, plusieurs étapes. Dans les grandes
lignes, les étapes sont les suivantes :
●
vérifier les pré­requis logiciels et matériels ;
●
configurer le noyau (sémaphores, mémoire partagée...) ;
●
créer les répertoires nécessaires ;
© ENI Editions - All rights reserved - Algeria Educ
- 1-
●
créer un groupe et un compte appartenant à ce groupe.
L’installation des produits Oracle s’effectue avec l’application Oracle Universal Installer ; cet installeur est "universel"
dans la mesure où il est identique (à peu de choses près) sur les différentes plates­formes et est utilisé par différents
produits Oracle (serveur, client, etc.).
Oracle Universal Installer permet :
●
●
de choisir le type d’installation : Enterprise Edition, Standard Edition, Personal Edition (plate­forme Windows
uniquement) personnalisé ;
de créer une base de données de départ avec différentes options de configuration pour le stockage,
l’administration, la sauvegarde, etc.
À l’issue de cette phase, si vous optez pour une installation avec base de données, vous devriez avoir :
●
une base de données de départ lancée ;
●
une configuration Oracle Net par défaut avec un processus d’écoute (listener) lancé ;
●
Oracle Enterprise Manager Database Control et lancé et accessible à l’aide d’un navigateur ;
La phase de post­installation consiste essentiellement à :
●
télécharger et appliquer d’éventuels patchs Oracle ;
●
recompiler les modules PL/SQL invalides ;
●
configurer certains composants Oracle (Oracle Net, etc.) ;
●
installer des produits supplémentaires ;
●
configurer l’environnement de travail ;
●
configurer le démarrage et l’arrêt automatiques des différents composants Oracle (base de données,
processus d’écoute, etc.).
Sur plate­forme Windows, si vous optez pour une installation avec base de données de départ, Oracle
Universal Installer crée automatiquement les services associés aux différents composants et les configure en
démarrage automatique ; si l’installation s’effectue sans base de départ, ces services doivent être créés et
configurés ultérieurement. Sur plate­forme Linux ou Unix, les services doivent être explicitement créés et configurés
par l’administrateur du système d’exploitation.
Les différentes phases de l’installation sont décrites ci­après. Ensuite, nous verrons comment configurer
l’environnement de travail et configurer le démarrage et l’arrêt automatiques des différents composants Oracle.
Avant cela, nous présenterons le standard Optimal Flexible Architecture (OFA). OFA est un ensemble de
recommandations sur l’arborescence et le nommage des fichiers du serveur, destinées à faciliter l’administration des
produits Oracle.
Avant toute installation, il est conseillé de sauvegarder les éléments critiques éventuellement présents sur le
serveur (bases Oracle d’une autre version d’Oracle, autres produits).
3. Optimal Flexible Architecture (OFA)
a. Principes généraux
- 2-
© ENI Editions - All rights reserved - Algeria Educ
OFA est un ensemble de recommandations sur l’arborescence et le nommage des fichiers du serveur, destinées à
faciliter l’administration des produits Oracle.
Un des points les plus intéressants du standard OFA est de clairement séparer le produit Oracle, les fichiers relatifs à
l’administration et les fichiers des bases de données, en tenant compte de la possibilité d’avoir plusieurs versions
d’Oracle et/ou plusieurs bases sur le serveur.
Les recommandations varient légèrement selon la plate­forme (voir la documentation "Oracle® Database Installation
Guide" de votre plate­forme).
Oracle Universal Installer est compatible OFA et propose une arborescence par défaut qui respecte ce standard.
Dans le standard OFA, deux répertoires jouent un rôle particulier : les répertoires Oracle Base et Oracle Home.
Le répertoire Oracle Base est le répertoire racine de l’arborescence Oracle.
Le répertoire Oracle Home est un sous­répertoire du répertoire Oracle Base qui contient le logiciel Oracle proprement
dit, pour une version donnée. Dans un répertoire Oracle Base, il est possible d’avoir plusieurs répertoires Oracle Home
correspondant chacun à une certaine version d’un produit Oracle donné (serveur de base de données, client, serveur
d’application, etc.).
Dans des configurations avancées, il est possible d’avoir plusieurs répertoires Oracle Base, pour installer
plusieurs produits Oracle sur des disques différents.
Chaque répertoire Oracle Home est, par ailleurs, identifié par un nom, par défaut sous la formeOraDb11g_homeN, N
étant un numéro d’ordre.
Sur plate­forme Windows, les emplacements de ces deux répertoires sont définis dans des entréesde la base de
registre (dans HKEY_LOCAL_ MACHINE\SOFTWARE\ORACLE\KEY_nom, nom étant le nom du Oracle Home). Sur plate­forme
Linux ou Unix, les emplacements de ces deux répertoires sont généralement définis dans des variables
d’environnement ORACLE_BASE et ORACLE_HOME du compte dans lequel Oracle est installé.
Sur plate­forme Windows, depuis la version 11, les recommandations sont les suivantes pour ces deux répertoires :
Oracle Base
X:\app\compte, X étant un lecteur de disque et compte le nom du compte utilisé pour l’installation. Exemple :
d:\app\oracle
Oracle Home
ORACLE_BASE\product\ v.v.v\type_n, ORACLE_BASE désignant le répertoire Oracle Base, product étant une constante
indiquant que les produits sont ici, v.v.v le numéro de version du produit, type le type de produit (db pour un
serveur de base de données, client pour un client, etc.) et n un numéro d’ordre dans le type.
Exemple : d:\app\oracle\product\11.1.0\db_1
Avant la version 10, le chemin Oracle Base était du type X:\Oracle (par exemple D:\Oracle) et le chemin Oracle Home
du type ORACLE_BASE\OraVV, VV étant le numéro de version du produit (par exemple D:\Oracle\Ora92). Le nom du
Oracle Home était de la forme OraHomeVV (par exemple OraHome 92) et la clé de la base de registre de la forme HOMEn,
n étant un numéro d’ordre (par exemple HOME0). Puis en version 10, le chemin Oracle Base était du type
X:\oracle\product\v.v.v et le chemin Oracle Home du type ORACLE_BASE\type_n (c’est le chemin Oracle Base qui
comportait l’information de version).
Si vous installez Oracle11g sur un système sur lequel une version précédente d’Oracle est installée,
l’installeur va conserver l’ancien chemin du répertoire Oracle Base et adapter en conséquence le chemin
Oracle Home. En cas de doute, consultez les valeurs dans la base de registre.
Sur la plate­forme Windows, il n’est pas habituel de créer un compte spécifique pour installer Oracle. Si
vous utilisez le compte administrateur de la machine, vous pouvez modifier le chemin proposé pour Oracle
Base par l’installeur et mettre oracle en guise de compte.
Sur plate­forme Unix ou Linux depuis la version 10, les recommandations sont les suivantes pour ces deux
répertoires :
Oracle Base
/ pm/ ccc/ compte, pm étant un point de montage d’un système de fichiers (avec p une chaîne et m un numéro
d’ordre), ccc une chaîne quelconque et compte le nom du compte utilisé pour l’installation.Exemple : /u01/app/oracle
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Oracle Home
ORACLE_BASE/product/v.v.v/type_n,ORACLE_BASE désignant le répertoire Oracle Base, v.v.v le numéro de version du
produit, type le type de produit (db pour un serveur de base de données, client pour un client, etc.) et n un numéro
d’ordre dans le type. Exemple : /u01/app/oracle/product/11.1.0/db_1
Avant la version 10, les recommandations étaient les mêmes, mais sans la partie type_ n.
La partie type_ n du chemin Oracle Home permet d’installer différents produits avec le même numéro de version sous
le même répertoire Oracle Base. Cela permet aussi d’installer plusieurs fois le même produit, dans la même version,
sous le même répertoire Oracle Base.
En dehors du répertoire Oracle Home, le répertoire Oracle Base est destiné à contenir quatre autres répertoires :
●
oradata pour les fichiers des bases de données ;
●
admin pour les fichiers d’administration des bases de données ;
●
cfgtoollogs pour les fichiers journaux des assistants de configuration ;
●
diag pour le Référentiel du Diagnostique Automatique (Automatic Diagnostic Repository ­ ADR).
Puisque plusieurs bases sont susceptibles d’être présentes sur le système, le standard OFA recommande de créer
un sous­répertoire par base, portant le nom de la base (paramètre DB_NAME), dans les répertoires oradata et admin.
Exemple :
- 4-
© ENI Editions - All rights reserved - Algeria Educ
Sur ces deux exemples, deux bases (ORCL et TEST) sont présentes sur le système.
Les différents sous­répertoires du répertoire d’administration sont présentés dans le chapitre Création d’une
nouvelle base de données.
En ce qui concerne les fichiers de la base de données, les recommandations de nommage sont les suivantes :
Fichier de contrôle
control.nn.ctl, nn étant un numéro d’ordre (01, 02, etc.).
Fichier de journalisation
redonn.log, nn étant le numéro du groupe (01, 02, etc.).
Fichiers de données
tablespacenn.dbf, tablespace étant le nom du tablespace et nn le numéro d’ordre du fichier au sein du tablespace
(01, 02, etc.).
b. Répartition des fichiers de la base de données sur plusieurs disques
D’une manière générale, il est souhaitable de séparer le stockage du système d’exploitation, du logiciel Oracle et des
bases de données, chaque stockage pouvant être au choix un disque, un volume logique ou un volume RAID.
Dans le cas où vous créez une base de données sur des disques qui ne sont pas organisés en volumes logiques ou
en RAID, il est recommandé de répartir les fichiers de la base de données sur différents disques afin d’améliorer les
performances et la sécurité.
Vous pouvez donc être amenés à utiliser plusieurs répertoires oradata situés sur différents points de montage ou
lecteurs de disque.
Selon la recommandation OFA, ces répertoires oradata supplémentaires doivent être créés en respectant la même
arborescence que le répertoire oradata principal.
Exemple :
Windows
e:\app\oracle\oradata
© ENI Editions - All rights reserved - Algeria Educ
- 5-
Unix ou Linux
/u02/app/oradata/oradata
À partir de là, selon les systèmes de stockage disponibles, plusieurs organisations sont disponibles.
Exemple :
Axe
Nature
Contenu
1
Disque
Système d’exploitation
2
Disque
Logiciel Oracle
3
N disques en RAID 0+1
Fichiers de données des
tablespaces
Fichiers de contrôle
4
N disques en RAID 0+1
Fichiers de journalisation
5
Disque
Fichiers de journalisation
archivés
Sauvegardes sur disque
Sur plate­forme Linux ou Unix, il est possible d’utiliser les liens symboliques pour faire croire que les fichiers
sont situés sous un seul point de montage alors qu’ils sont en fait répartis sur plusieurs.
Si vous le souhaitez, vous pouvez adopter une organisation OFA non standard, du moment que vous en
respectez la philosophie (séparation des produits Oracle, séparation des bases de données).
4. Pré­installation
a. Sur plate­forme Windows
Se connecter au système
Oracle doit être installé à l’aide d’un compte membre du groupe Administrateur. Si l’installation s’effectue sur un
serveur contrôleur de domaine (principal ou secondaire), le compte doit être membre du groupe Administrateur de
domaine.
Dans cet ouvrage, nous supposerons qu’un compte nommé « oracle », membre du groupe Administrateur, a été
spécialement créé pour l’occasion.
Vérifier les pré­requis logiciels et matériels
Oracle11g supporte les systèmes d’exploitation Windows suivants :
●
Windows 2000 (service pack 1 ou supérieur) ;
●
Windows Server 2003 (toutes les éditions) ;
●
Windows XP Professional ;
●
Windows Vista (Business, Enterprise et Ultimate).
Dans cet ouvrage, nous utiliserons une plate­forme Windows Server 2003 Entreprise Edition. L’installation sur les
autres plates­formes Windows est identique.
Les exigences matérielles sont les suivantes :
- 6-
© ENI Editions - All rights reserved - Algeria Educ
●
1 Go de mémoire physique minimum ;
●
Le double de mémoire virtuelle ;
●
200 Mo d’espace temporaire ;
●
Environ 3 Go d’espace disque pour les produits Oracle ;
●
●
Environ 2 Go d’espace disque supplémentaire si vous souhaitez créer une base de données de départ lors
de l’installation ;
256 couleurs pour la vidéo.
Si vous n’avez que 256 Mo de mémoire physique, vous n’aurez pas suffisamment de mémoire pour créer une
base de données au cours de l’installation ; vous devrez créer la base de données ultérieurement (avec une
petite SGA).
b. Sur plate­forme Linux
Se connecter au système en tant qu’utilisateur root
Les premières tâches de la phase de pré­installation doivent être effectuées en tant que root .
Vérifier les pré­requis logiciels et matériels
Oracle11g supporte les systèmes d’exploitation Linux suivants :
●
Oracle Enterprise Linux 4 ou Red Hat Enterprise Linux 4 (noyau 2.6.9) ;
●
Oracle Enterprise Linux 5 ou Red Hat Enterprise Linux 5 (noyau 2.6.18) ;
●
SUSE Enterprise Linux 10 (noyau 2.6.16.21).
Dans cet ouvrage, nous utiliserons une plate­forme Red Hat Enterprise Linux 4. L’installation sur les autres plates­
formes Linux (ou Unix en général) est similaire : les principes sont les mêmes, mais certaines valeurs ou certaines
commandes peuvent différer (reportez­vous au manuel d’installation de votre plate­forme).
Pour chaque distribution, un certain nombre de packages doivent être installés (avec une version minimum).
Exemple pour Red Hat Enterprise Linux 4 :
binutils-2.15.92.0.2-18
compat-libstdc++-33.2.3-47.3
elfutils-libelf-0.97-5
elfutils-libelf-devel-0.97-5
glibc-2.3.4-2.19
glibc-common-2.3.4-2.19
glibc-devel-2.3.4-2.19
glibc-headers-2.3.4-2.19
gcc-3.4.5-2
gcc-c++-3.4.5-2
libaio-devel-0.3.105-2
libaio-0.3.105-2
libgcc-3.4.5
libstdc++-3.4.5-2
libstdc++-devel-3.4.5-2
make-3.80-5
sysstat-5.0.5
unixODBC-2.2.11
unixODBC-devel-2.2.11
© ENI Editions - All rights reserved - Algeria Educ
- 7-
Le script suivant permet de vérifier ces exigences sur Red Hat Enterprise Linux 4 :
echo "* Version du noyau"
uname -r
echo "* Packages"
# Liste des packages
listePackages=$(cat < _EOF_
binutils
libaio
libaio-devel
gcc
gcc-c++
glibc
glibc-common
glibc-headers
glibc-devel
libstdc++
libstdc++-devel
compat-libstdc++-33
make
sysstat
elfutils-libelf
elfutils-libelf-devel
unixODBC
unixODBC-devel
_EOF_
)
# Recherche les packages et indique si le package est
# installe ou pas.
for package in $listePackages;
do
version=$(rpm -q $package --qf "%{version} %{arch}")
if [ $? = 0 -a "$version" ]
then
printf "+ %-25s %-15s %s\n" $package $version
else
printf "o %-25s %s\n" $package "?"
fi
done
Résultat :
* Version du noyau
2.6.9-67.0.15.ELsmp
* Packages
+ binutils
+ libaio
+ libaio-devel
+ gcc
+ gcc-c++
+ glibc
+ glibc-common
+ glibc-headers
+ glibc-devel
+ libstdc++
+ libstdc++-devel
+ compat-libstdc++-33
+ make
+ sysstat
+ elfutils-libelf
+ elfutils-libelf-devel
+ unixODBC
+ unixODBC-devel
2.15.92.0.2
0.3.105
0.3.105
3.4.6
3.4.6
2.3.4
2.3.4
2.3.4
2.3.4
3.4.6
3.4.6
3.2.3
3.80
5.0.5
0.97.1
0.97.1
2.2.11
2.2.11
i386
i386
i386
i386
i386
i686
i386
i386
i386
i386
i386
i386
i386
i386
i386
i386
i386
i386
Les exigences matérielles sont les suivantes :
- 8-
●
1 Go de mémoire physique minimum ;
●
Espace swap : 1,5 fois la mémoire physique si cette dernière fait moins de 2 Go ou égal à la mémoire
© ENI Editions - All rights reserved - Algeria Educ
physique si cette dernière est comprise entre 2 Go et 8 Go ;
●
400 Mo d’espace temporaire (/tmp) ;
●
Environ 3,5 Go d’espace disque pour les produits Oracle ;
●
Environ 2 Go d’espace disque supplémentaire si vous souhaitez créer une base de données de départ lors
de l’installation ;
Le script suivant permet de vérifier ces exigences sur Red Hat Enterprise Linux 4 :
echo "* Mémoire (Mo)"
free -m
echo "* Disque"
df -h /tmp /u0*
Résultat :
* Memoire (Mo)
total
used
free
shared
buffers
Mem:
1010
966
44
0
4
-/+ buffers/cache:
591
419
Swap:
2559
116
2443
* Disque
Filesystem
Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
9.9G 2.8G 6.6G 30% /
/dev/mapper/VolGroup01-LogVol100
9.9G 5.4G
4.0G
cached
370
58% /u01
Configurer le noyau
Paramètre
Valeur
Fichier
semmsl
250
semmns
32000
semopm
100
semmni
128
shmall
2097152
/proc/sys/kernel/shmall
shmmax
la moitié de la mémoire physique
/proc/sys/kernel/shmmax
shmmni
4096
/proc/sys/kernel/shmmni
file-max
65536
/proc/sys/fs/file-max
ip_local_port_range
1024 65000
/proc/sys/net/ipv4/ip_
/proc/sys/kernel/sem
local_port_range
rmem_default
4194304
/proc/sys/net/core/
rmem_default
rmem_max
4194304
/proc/sys/net/core/
rmem_max
wmem_default
262144
/proc/sys/net/core/
© ENI Editions - All rights reserved - Algeria Educ
- 9-
wmem_default
wmem_max
262144
/proc/sys/net/core/wmem_max
Le script suivant permet de vérifier ces paramètres sur Red Hat Enterprise Linux 4 :
listeVariables=$(cat << _EOF_
kernel.shmall
kernel.shmmax
kernel.shmmni
kernel.sem
fs.file-max
net.ipv4.ip_local_port_range
net.core.rmem_default
net.core.rmem_max
net.core.wmem_default
net.core.wmem_max
_EOF_
)
for variable in $listeVariables;
do
sysctl $variable
done
Résultat :
kernel.shmall = 2097152
kernel.shmmax = 33554432
kernel.shmmni = 4096
kernel.sem = 250
32000
32
128
fs.file-max = 102445
net.ipv4.ip_local_port_range = 3276861000
net.core.rmem_default = 110592
net.core.rmem_max = 131071
net.core.wmem_default = 110592
net.core.wmem_max = 131071
Sur cet exemple, les valeurs en gras ne sont pas conformes aux recommandations Oracle. Si un des paramètres du
noyau a une valeur inférieure à la valeur recommandée, vous pouvez éditer le fichier /etc/sysctl.conf et ajouter ou
modifier des lignes de configuration des paramètres :
Exemple de lignes ajoutées dans le fichier :
# modifications pour oracle
kernel.shmmax = 536870912
kernel.sem = 250 32000 100 128
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default = 4194304
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 262144
Pour que les nouvelles valeurs soient prises en compte immédiatement, exécutez la commande suivante :
sysctl -p
Créer les groupes et l’utilisateur
Ensuite, vous devez créer deux groupes et un compte utilisateur qui sera utilisé pour l’installation et qui sera donc le
propriétaire des logiciels Oracle.
Lors de la première installation d’Oracle sur un système, l’installeur crée un fichier oraInst.loc (dans le
répertoire /etc sous Linux). Ce fichier contient le chemin vers le répertoire contenant l’inventaire des produits Oracle
installés sur la machine, ainsi que le nom du groupe Oracle Inventory (typiquement oinstall) utilisé pour protéger
l’accès au répertoire d’inventaire. La présence du fichier oraInst.loc permet de déterminer si le groupe Oracle
Inventory existe déjà, et de retrouver son nom.
Comme indiqué dans le chapitre Les bases de l’architecture Oracle, un groupe particulier (nommé génériquement
- 10 -
© ENI Editions - All rights reserved - Algeria Educ
OSDBA) est utilisé pour identifier les comptes utilisateurs qui peuvent se connecter AS
l’authentification par le système d’exploitation. Traditionnellement, ce groupe s’appelle dba.
SYSDBA en utilisant
En complément, il est possible de créer un groupe (traditionnellement nommé oper) pour l’authentification AS
SYSOPER (cf. Chapitre Les bases de l’architecture Oracle).
Traditionnellement, le compte utilisateur utilisé pour l’installation s’appelle oracle ; il a le groupe Oracle Inventory
comme groupe principal et le groupe OSDBA comme groupe secondaire.
Les commandes suivantes permettent de créer les deux groupes et le compte s’ils n’existent pas déjà :
groupadd oinstall
groupadd dba
useradd -g oinstall -G dba oracle
passwd oracle
Dans cet ouvrage, le terme « compte oracle » désignera le compte utilisé pour l’installation d’Oracle. Si vous
appelez ce compte autrement, adaptez les exemples au nom que vous avez choisi.
Définir les limites du shell pour le compte oracle
Pour améliorer les performances du logiciel, vous devez augmenter les limites suivantes pour le compte oracle :
Nombre maximum de descripteurs de fichiers ouverts : 65535
Nombre maximum de processus : 16384
Pour augmenter ces limites :
■
Ajoutez les lignes suivantes dans le fichier /etc/security/limits.conf :
oracle
oracle
oracle
oracle
■
nproc
nproc
nofile
nofile
2047
16384
1024
65536
Ajoutez les lignes suivantes dans le fichier /etc/pam.d/login (si elles n’existent pas déjà) :
session
session
■
soft
hard
soft
hard
required
required
/lib/security/pam_limits.so
pam_limits.so
Ajoutez les lignes suivantes dans le fichier /etc/profile (à adapter en fonction de la distribution et du shell par
défaut de l’utilisateur oracle) :
if [ $USER = "oracle" ]; then
if [ $SHELL = "/bin/ksh" ]; then
ulimit -p 16384
ulimit -n 65536
else
ulimit -u 16384 -n 65536
fi
fi
Créer les répertoires
Pour respecter le standard OFA présenté précédemment, vous devez créer au minimum le répertoire parent du
répertoire Oracle Base, par exemple /u01/app.
Vous pouvez utiliser un répertoire Oracle Base déjà existant, du moment que vous utilisez bien un répertoire
Oracle Home différent. N’oubliez pas qu’il faut prévoir environ 3,5 Go pour les produits Oracle et 2 Go pour la
base de données de départ.
Les commandes suivantes permettent de créer le répertoire, et de définir le propriétaire, les groupes et les
permissions :
© ENI Editions - All rights reserved - Algeria Educ
- 11 -
mkdir -p /u01/app
chown -R oracle:oinstall /u01/app/
chmod -R 775 /u01/app/
Les répertoires oracle et oraInventory seront créés par l’installeur dans le répertoire parent du répertoire
Oracle Base (/u01/app/ sur notre exemple). Le compte oracle doit donc, bien avoir des droits d’écriture dans
ce répertoire, sous peine de recevoir une erreur lors de l’installation.
Des répertoires supplémentaires peuvent être prévus sur d’autres disques pour la base de données et la zone de
récupération rapide (flash recovery area). Le propriétaire, les groupes et les permissions doivent être définis à
l’identique du premier répertoire.
Configurer l’environnement du compte oracle
■
Editez le fichier de démarrage du shell de l’utilisateur :
Bash Shell (bash) sur Red Hat .bash_profile
Bourne shell (sh), Bash shell (bash) sur SUSE ou Korn shell (ksh) .profile
C shell (csh ou tcsh) .login
■
Ajoutez la ligne suivante dans ce fichier pour définir les droits d’accès par défaut des nouveaux fichiers :
umask 022
Si le répertoire /tmp ne comporte pas suffisamment d’espace, vous pourrez définir les variables d’environnements
TMP et TMPDIR et y indiquer le nom d’un répertoire contenant suffisamment d’espace libre. Exemple :
TMP=/home/oracle/tmp
TMPDIR=/home/oracle/tmp
export TMP TMPDIR
Se connecter au système en tant qu’utilisateur oracle
Pour la suite de l’installation, vous devez vous connecter en tant qu’utilisateur oracle.
5. Installation avec Oracle Universal Installer
a. Vue d’ensemble
Oracle Universal Installer (OUI) fonctionne de la même manière, à peu de chose près, sur les différentes plates­
formes.
OUI propose deux grands modes pour l’installation :
●
L’installation de base ;
●
L’installation avancée.
L’installation de base permet d’installer Oracle avec les options standards, en un petit nombre d’étapes. Dans ce
mode, si vous choisissez de créer une base de données de départ, cette dernière utilisera le système de fichiers
pour le stockage et le même mot de passe sera attribué aux comptes SYS, SYSTEM, SYSMAN et DBSNMP.
L’installation avancée offre un plus grand contrôle sur l’installation, notamment sur les composants installés et la
configuration de la base de données de départ.
En règle générale, sauf pour un test rapide, je dissocie l’installation d’Oracle proprement dite de la création de la
base de données. Cette approche présente deux avantages :
●
- 12 -
Après l’installation du produit, mais avant la création de la base de données, je peux appliquer les éventuels
© ENI Editions - All rights reserved - Algeria Educ
patchs apparus depuis la sortie du produit.
●
Lors de la création de la base de données en SQL ou avec l’assistant Configuration de base de données, je
peux configurer la base de données très précisément en fonction des besoins.
Avec une telle approche, l’installation de base, avec création ou non d’une base de données de départ, répond à la
majorité des besoins. C’est le seul mode d’installation qui sera présenté dans cet ouvrage.
Les bases de données de départ d’Oracle sont intéressantes pour avoir rapidement un environnement
opérationnel pour le test ou le développement. Par contre, ces bases contiennent un grand nombre de
schémas et de fonctionnalités qui ne sont pas forcément utiles pour une base de données de production. C’est
une raison supplémentaire pour installer Oracle sans créer de base de données, puis créer ensuite la base de
données, à l’aide de l’assistant graphique, ou à la main (chapitre Création d’une nouvelle base de données).
Cette partie est donc organisée de la manière suivante :
●
b. Lancer Oracle Universal Installer sur plate­forme Windows
●
c. Lancer Oracle Universal Installer sur plate­forme Linux
●
d. Installation de base
Il est possible d’utiliser Oracle Universal Installer en mode non interactif en utilisant un fichier de réponse. Il
est aussi possible de cloner une installation Oracle Home existante. Pour plus d’informations, consultez la
documentation « Oracle® Database Installation Guide » de votre plate­forme.
b. Lancer Oracle Universal Installer sur plate­forme Windows
■
Pour démarrer l’installeur, lancez l’application setup.exe qui se trouve sur le média utilisé pour l’installation (ou
dans le répertoire database si vous avez téléchargé le produit sur le site OTN). Une fenêtre de lancement d’Oracle
Universal Installer s’affiche. Cette fenêtre vérifie les pré­requis puis lance Oracle Universal Installer si les
exigences sont vérifiées. La page d’accueil d’Oracle Universal Installer s’affiche alors.
© ENI Editions - All rights reserved - Algeria Educ
- 13 -
Pour l’installation de base, reportez­vous à la section Installation de base.
c. Lancer Oracle Universal Installer sur plate­forme Linux
Oracle Universal Installer, en mode interactif, doit être lancé dans un environnement X Window. Vous devez donc
démarrer l’interface graphique dans votre session oracle, par exemple avec la commande startx.
Si l’affichage X ne s’effectue pas sur le système sur lequel le produit est installé, positionnez la variable
d’environnement DISPLAY pour déporter l’affichage sur une autre machine.
Pour démarrer l’installeur, lancez l’application runInstaller qui se trouve sur le média utilisé pour l’installation (ou
dans le répertoire database si vous avez téléchargé le produit sur le site OTN). Le script vérifie les pré­requis puis
lance Oracle Universal Installer si les exigences sont vérifiées. La page d’accueil d’Oracle Universal Installer s’affiche
alors.
- 14 -
© ENI Editions - All rights reserved - Algeria Educ
Pour l’installation de base, reportez­vous à la section Installation de base.
d. Installation de base
Sélectionner une méthode d’installation
© ENI Editions - All rights reserved - Algeria Educ
- 15 -
La méthode Installation de base permet d’installer Oracle très rapidement en saisissant quelques informations sur
le premier écran :
Emplacement du répertoire d’origine Oracle Home
Répertoire de l’installation d’Oracle (Oracle Home).
Type d’installation
Au choix : Enterprise Edition, Standard Edition, Standard Edition One et Personal Edition (Windows uniquement).
Créer une base de données de départ (1482 MB) supplémentaire
Permet de créer une base de données de type « universel » (pour plus de détails, voir la section Création de la base
de données à l’aide de l’assistant graphique dans le chapitre Création d’une nouvelle base de données).
Nom global de base de données
Nom global de la base de données sous la forme nom_base[.domaine] (par exemple orcl.olivier-heurtel.priv).
Mot de passe de base de données
Mot de passe des comptes SYS, SYSTEM, SYSMAN et DBSNMP.
Sur plate­forme Linux ou Unix, l’option Groupe DBA UNIX est proposée en plus :
Cette option permet de choisir le nom du groupe utilisé pour identifier les comptes utilisateurs qui peuvent se
connecter AS SYSDBA en utilisant l’authentification par le système d’exploitation ; le groupe dba, précédemment créé à
cet effet et affecté à l’utilisateur oracle, est proposé.
■
- 16 -
Saisissez les valeurs souhaitées puis cliquez sur le bouton Suivant.
© ENI Editions - All rights reserved - Algeria Educ
Sélectionner le répertoire de l’inventaire et les informations d’identification
Cet écran est affiché uniquement sur plate­forme Linux ou Unix, lors de la première installation d’un produit Oracle. Il
permet de définir les informations relatives au répertoire d’inventaire (chemin et groupe ayant l’accès en écriture sur
ce répertoire). Si vous avez bien respecté les étapes de la phase de pré­installation, les valeurs proposées doivent
être correctes. Le répertoire d’inventaire oraInventory est créé par défaut dans le répertoire parent du répertoire
Oracle Base et le nom du groupe doit être celui du groupe Oracle Inventory créé précédemment (traditionnellement
oinstall).
■
Saisissez, si besoin, les informations demandées et cliquez sur le bouton Suivant.
Vérification de pré­requis propres au produit
© ENI Editions - All rights reserved - Algeria Educ
- 17 -
L’installeur vérifie que le système est correctement configuré. Si vous avez respecté les étapes de la phase de pré­
installation, il ne devrait pas y avoir de problème.
■
- 18 -
Si la vérification échoue, sélectionnez la ligne concernée et analysez la cause du problème :
© ENI Editions - All rights reserved - Algeria Educ
■
Si possible, corrigez le problème et recommencez la vérification (bouton Ressayer).
■
Si vous pensez qu’il n’y a pas de problème, vous pouvez cocher la case :
Lorsque les vérifications sont terminées avec succès, vous pouvez cliquer sur le bouton Suivant pour poursuivre
l’installation. S’il reste une vérification avec un échec, une confirmation est demandée :
Vous pouvez alors poursuivre l’installation, mais à vos risques et périls.
Inscription Oracle Configuration Manager
Cet écran est affiché uniquement si une base de données de départ est créée durant l’installation ; il permet
d’activer Oracle Configuration Manager.
Oracle Configuration Manager est utilisé pour collecter des informations sur la configuration d’une installation. Ces
informations sont envoyées à intervalles réguliers dans un référentiel du support Oracle. Lorsqu’une demande de
service (Service Request) est soumise à Oracle, elle peut être associée aux informations de configuration collectées
au préalable.
Cette fonctionnalité n’est pas présentée plus en détail dans ce livre. A noter qu’elle peut être installée
ultérieurement. Pour plus d’informations, consultez la documentation "Oracle® Configuration Manager Installation
and Administration Guide" (à ce jour, cette documentation existe uniquement en version 10.2).
© ENI Editions - All rights reserved - Algeria Educ
- 19 -
■
Cliquez sur le bouton Suivant.
Résumé
Dans cet écran, vous pouvez notamment repérer les chemins utilisés pour les répertoires Oracle Base et Oracle Home,
ainsi que les langues du produit.
Les langues du produit sont les langues utilisées par OUI lors de l’installation, et non les langues disponibles
dans la base de données Oracle proprement dite. Vous pouvez installer Oracle en anglais avec l’installeur et
utiliser plus tard le français, ou d’autres langues, dans la base de données.
■
Cliquez sur le bouton Installer pour lancer l’installation.
Installation et configuration du logiciel Oracle
Pendant l’installation, un écran présentant l’état d’avancement est affiché.
- 20 -
© ENI Editions - All rights reserved - Algeria Educ
Assistants de configuration
À la fin de l’installation, plusieurs assistants de configuration sont automatiquement lancés par l’installeur.
Ces assistants ne sont lancés que si une base de données de départ est créée au cours de l’installation. Si
© ENI Editions - All rights reserved - Algeria Educ
- 21 -
ce n’est pas le cas, ces assistants ne sont pas lancés et il faudra configurer Oracle Net ultérieurement.
Une fenêtre spécifique d’avancement s’affiche pour l’assistant Configuration de base de données :
À la fin de la création de la base de données, l’écran suivant s’affiche :
- 22 -
© ENI Editions - All rights reserved - Algeria Educ
Cet écran indique notamment l’URL à utiliser pour accéder à la console Enterprise Manager. Un clic sur le bouton
Gestion des mots de passe… ouvre une fenêtre de dialogue qui permet d’activer ou désactiver des comptes
utilisateur et de définir les mots de passe de ces différents comptes :
Comme vous pouvez le constater, la base de données de départ d’Oracle contient un grand nombre de comptes
© ENI Editions - All rights reserved - Algeria Educ
- 23 -
utilisateurs. Pour plus d’informations sur ces différents comptes, reportez­vous à la documentation « Oracle®
Database Installation Guide ». Pour verrouiller/déverrouiller un compte, il suffit de cliquer dans la colonne Verrouiller
le compte.
Exécuter les scripts de configuration
Cet écran est affiché uniquement sur plate­forme Linux ou Unix, et vous invite à exécuter des scripts de configuration
en tant qu’utilisateur root.
Le script orainstRoot.sh est exécuté uniquement lors de la première installation d’un produit Oracle sur la machine.
Il modifie les droits et le groupe du répertoire oraInventory.
Le script root.sh copie trois fichiers (dbhome, oraenv et coraenv) dans un répertoire local bin (demandé par le script,
par défaut /usr/local/bin), crée le fichier /etc/oratab (s’il n’existe pas déjà) et y ajoute une entrée pour la base de
données éventuellement créé pendant l’installation. Le rôle et l’utilisation de ces différents fichiers seront présentés
ultérieurement.
■
- 24 -
Pour exécuter ces deux scripts, ouvrez une fenêtre de terminal en tant que root :
© ENI Editions - All rights reserved - Algeria Educ
■
Tapez [Entrée] pour accepter la valeur par défaut proposée par chaque invite affichée par le script root.sh.
■
Lorsque le script est terminé, cliquez sur le bouton OK de la fenêtre de dialogue.
Fin de l’installation
L’installation est terminée ; un dernier écran s’affiche :
© ENI Editions - All rights reserved - Algeria Educ
- 25 -
Dans le cas où vous avez créé une base de données de départ, cet écran rappelle l’URL à utiliser pour accéder à la
console Enterprise Manager. Dans le cas contraire, la zone "n’oubliez pas…" n’est pas affichée.
■
Cliquez sur le bouton Quitter pour quitter Oracle Universal Installer (une confirmation vous sera demandée).
6. Post­installation
a. Télécharger et appliquer des patches Oracle
La version d’Oracle que vous venez d’installer à partir d’un média ou d’un téléchargement sur OTN ne contient pas
les derniers patches applicables au produits. Par ailleurs, Oracle publie régulièrement des patches pour ces produits
et vous pouvez donc être amenés à mettre à jour votre configuration à intervalles réguliers.
Pour identifier et télécharger les patches d’un produit, vous devez aller sur le site Web OracleMetaLink, à l’adresse
suivante : http://metalink.oracle.com
À l’heure où cet ouvrage est rédigé, Oracle est en train de mettre en place une nouvelle version de son site
de support (dorénavant appelé My Oracle Support). Il est donc possible que vous ayez des pages légèrement
différentes de celles présentées ici.
Pour accéder à OracleMetaLink, vous devez disposer d’un compte ; pour ouvrir un compte (lien Register For
Metalink), vous devez posséder un identifiant de support qui vous est fourni dans le cadre d’un contrat de support.
■
■
Pour vous connecter, cliquez sur le lien Login To Metalink, puis saisissez votre identifiant et votre mot de passe.
Une fois connecté, cliquez sur l’onglet Patches & Updates en haut à droite de l’écran puis sur le lien Simple
Search.
Dans la page qui s’affiche :
- 26 -
■
Dans le champ Search By, sélectionnez Product or Family, puis saisissez RDBMS Server.
■
Dans le champ Release, sélectionnez la version souhaitée du produit.
■
Dans le champ Patch Type, sélectionnez la valeur Patchset/Minipack.
■
Dans le champ Platform or Language, sélectionnez votre plate­forme.
■
Cliquez sur le bouton Go pour obtenir la liste des patches disponibles.
© ENI Editions - All rights reserved - Algeria Educ
Exemple
À l’heure où cet ouvrage est rédigé, Oracle Database est distribué en version 11.1.0.6 et le Patchset 11.1.0.7 n’est
pas encore disponible (mais il devrait l’être au moment où vous lirez ce livre).
Un Patchset ou Minipack est un regroupement de patches qui corrigent plusieurs problèmes. En règle générale, les
Patchsets sont cumulatifs (le Patchset 2 reprend les corrections du Patchset 1) et peuvent être installés
systématiquement sans avoir besoin de les qualifier ; Oracle indique que les correctifs ont un faible impact sur le
système et ont été complètement testés (mais le risque zéro n’existe pas…). Sinon, il est possible d’appliquer des
patches individuels qui corrigent un problème précis (indiquez Patch dans le champ Patch Type) ; ces patches ne
doivent généralement être appliqués qu’en réponse à un problème précis identifié dans la base des bugs.
Exemple de recherche de patches individuels
© ENI Editions - All rights reserved - Algeria Educ
- 27 -
■
Cliquez sur l’icône
pour afficher la note du patch qui décrit les problèmes corrigés et la procédure
d’installation.
■
Cliquez sur l’icône
pour télécharger le patch puis procédez à son installation (suivez la procédure indiquée
dans la note).
La procédure d’installation dépend du patch. En règle générale, les Patchsets s’installent avec Oracle Universal
Installer et les autres avec l’utilitaire opatch (installé dans le sous­répertoire OPatch du répertoire Oracle Home). Dans
le cas des Patchsets, il y a la plupart du temps une procédure de mise à niveau à appliquer aux bases de données
(exécution d’un ou plusieurs scripts).
Oracle Enterprise Manager peut être utilisé pour récupérer et appliquer des patches ; il peut même être
configuré pour télécharger automatiquement les patches disponibles.
b. Configurer l’environnement de travail
Choix du langage et du jeu de caractères
Oracle supporte différents langages pour l’interaction avec la base de données. Le langage courant est défini dans la
variable d’environnement NLS_LANG.
NLS signifie National Language Support.
Cette variable a le format suivant : LANGAGE_PAYS.CARACTERES
Avec :
LANGAGE
Langage utilisé pour les messages (ainsi que les noms de jour ou de mois).
PAYS
Nom du pays (définit des conventions par défaut pour les formats de dates et de nombres, le symbole monétaire,
etc.).
CARACTERES
Jeu de caractères utilisé pour l’affichage des messages (peut être différent du jeu de caractères utilisé pour le
stockage des chaînes de caractères dans la base de données ­ voir le chapitre Les outils d’administration ­ Création
d’une nouvelle base).
Exemple :
FRENCH_FRANCE.WE8ISO8859P15
AMERICAN_AMERICA.US7ASCII
Vous
pouvez
parfaitement
choisir
un
langage
et
un
pays
qui
ne
correspondent
pas.
Ainsi
AMERICAN_FRANCE.WE8ISO8859P15 permet d’avoir des messages en anglais mais des conventions françaises par défaut
pour les formats de dates et de nombres.
Les jeux de caractères les plus couramment rencontrés sont :
US7ASCII
ASCII 7­bit American.
WE8ISO8859P1
ISO 8859­1 West European (ne gère pas le symbole de l’euro).
WE8ISO8859P15
- 28 -
© ENI Editions - All rights reserved - Algeria Educ
ISO 8859­15 West European (gère le symbole de l’euro).
UTF8
Unicode 3.0 UTF­8 Universal (gère le symbole de l’euro).
WE8PC850
IBM­PC Code Page 850 8­bit West European (sur plate­forme Windows, permet d’avoir les accents dans les
environnements ligne de commande).
WE8PC858
IBM­PC Code Page 858 8­bit West European (gère le symbole de l’euro).
WE8MSWIN1252
MS Windows Code Page 1252 8­bit West European (gère le symbole de l’euro).
Consultez la documentation Oracle® Database Globalization Support Guide pour avoir plus d’informations
sur le support des différents langages et pays.
Plate­forme Windows
Sur plate­forme Windows, il n’y a rien de particulier à faire : l’installeur a pris soin de positionner plusieurs
paramètres dans la base de registre et de définir la variable d’environnement PATH, en y mettant notamment le
chemin vers le répertoire bin.
Vous pouvez donc, sans problème, lancer des outils Oracle en ligne de commande (sqlplus par exemple), sans
mentionner le chemin complet.
Pour
chaque
Oracle
Home,
la
base
de
registre
contient
une
clé
HKEY_LOCAL_MACHINE\
SOFTWARE\ORACLE\KEY_nom_oracle_home qui stocke plusieurs paramètres relatifs au Oracle Home.
Vous y trouverez notamment un paramètreORACLE_SID. Ce paramètre contient le nom de la dernière instance créée
dans le Oracle Home concerné ; c’est l’instance à laquelle vous vous connectez par défaut quand vous lancez un outil
d’administration directement sur le serveur (cf. section SQL*Plus dans le chapitre Les outils d’administration).
La base de registre contient aussi un paramètreNLS_LANG, défini par défaut par l’installeur en fonction de la
localisation du système d’exploitation (typiquement FRENCH_ FRANCE.WE8MSWIN1252 pour une version française de
Windows).
Les différents paramètres présents dans la base de registre sont décrits dans la documentation Oracle®
Database Platform Guide for Windows.
Les paramètres de la base de registre comme ORACLE_SID et NLS_LANG sont utilisés par défaut par les différents outils
Oracle. Si vous souhaitez utiliser des valeurs différentes, avant de lancer un outil, vous pouvez modifier les
paramètres de la base de registre ou définir des variables d’environnement de même nom (dans le panneau de
configuration Système ou dans une fenêtre de commandes).
Vous pouvez notamment utiliser le jeu de caractères WE8PC850 si vous souhaitez avoir un affichage correct
des accents dans les outils ligne de commande (permet d’éviter des messages du type Connectú).
Lorsque votre système comporte plusieurs Oracle Home, la variable d’environnement PATH contient plusieurs chemins
vers les répertoires bin des différents Oracle Home, dans un certain ordre ; le premier chemin trouvé est, en quelque
sorte, celui du Oracle Home par défaut. Si vous lancez un outil sans mentionner de chemin complet, c’est celui du
Oracle Home par défaut qui sera lancé, ce qui risque de poser des problèmes si vous souhaitez travailler sur une
base de données d’un autre Oracle Home (et donc peut­être d’une autre version).
Pour éviter ce genre de problème, une première solution consiste à utiliser un chemin complet pour lancer l’outil du
bon Oracle Home. La deuxième solution consiste à changer de Oracle Home par défaut, soit en modifiant soi­même la
variable PATH, soit en utilisant Oracle Universal Installer :
■
Lancez Oracle Universal Installer (menu Démarrer ­ Programmes ­ Oracle ­ nom_oracle_home ­ Oracle
Installation Products ­ Universal Installer).
© ENI Editions - All rights reserved - Algeria Educ
- 29 -
■
Sur l’écran de bienvenue, cliquez sur le bouton Produits installés...
■
Dans la fenêtre Inventaire qui s’affiche, cliquez sur l’onglet Environnement :
Cet onglet liste les différents Oracle Home trouvés sur le système, dans leur ordre d’apparition dans la variable
d’environnement PATH (affichée dans la zone Chemin). Vous pouvez alors sélectionner les Oracle Home qui doivent
apparaître dans la variable d’environnement PATH et modifier leur ordre. Cliquez sur le bouton Appliquer pour
enregistrer vos modifications.
Plate­forme Unix ou Linux
Sur plate­forme Unix ou Linux, l’installeur ne modifie pas l’environnement du compte dans lequel Oracle est installé.
À chaque fois que vous utiliserez ce compte pour administrer Oracle, vous serez amenés à positionner différentes
variables d’environnement : ORACLE_HOME(et éventuellement ORACLE_BASE), ORACLE_SID, PATH(chemin vers
ORACLE_HOME/bin notamment) et éventuellement NLS_LANG.
Ces variables d’environnement peuvent être définies à la main, lors de chaque session ou être définies dans le
fichier de démarrage du shell de l’utilisateur.
Exemple :
ORACLE_BASE=/u01/app/oracle
ORACLE_HOME=$ORACLE_BASE/product/11.1.0/db_1
ORACLE_SID=ORCL
PATH=$PATH:$ORACLE_HOME/bin
NLS_LANG=FRENCH_FRANCE.UTF8
export ORACLE_BASE ORACLE_HOME ORACLE_SID PATH NLS_LANG
Si vous avez plusieurs bases de données, et éventuellement plusieurs Oracle Home, il faut penser à modifier en
conséquence les variables ORACLE_SID, et éventuellement ORACLE_HOME et PATH.
- 30 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Pour cela, vous pouvez utiliser un script shell fourni par Oracle : coraenv(C shell) ou oraenv (autres shells). Ces deux
scripts sont créés pendant l’installation (par le script root.sh) et se situent par défaut dans /usr/local/bin.
Pour les exécuter, utilisez une des commandes suivantes :
source /usr/local/bin/coraenv
. /usr/local/bin/oraenv
Ces scripts vous invitent à saisir le nom de l’instance à laquelle vous voulez accéder et modifient en conséquence la
valeur des variables d’environnement ORACLE_SID, ORACLE_ HOME et PATH (ajout du chemin $ORACLE_HOME/bin à la
variable PATH.).
Pour déterminer la valeur de la variable ORACLE_HOME, ces scripts appellent le script dbhome. Ce dernier se base sur le
fichier /etc/oratab, lui aussi créé dans l’installation.
Le fichier /etc/oratab est, en quelque sorte, un référentiel central des différentes instances (et donc bases de
données) présentes sur le serveur. Il contient des lignes de la forme :
$ORACLE_SID:$ORACLE_HOME:{Y|N}
Exemple :
ORCL:/u01/app/oracle/product/11.1.0/db_1:Y
Voir le chapitre Démarrage et arrêt pour l’utilisation de ce fichier dans le contexte du démarrage d’une base
à l’aide du script dbstart et le chapitre Création d’une nouvelle base de données pour la mise à jour de ce
fichier après la création d’une nouvelle base de données.
Si l’instance n’est pas trouvée dans le fichier oratab, le script oraenv ou coraenv demande de saisir la valeur de la
variable ORACLE_HOME.
Si le fichier oratab est correctement renseigné (ce qui est conseillé), les scripts oraenv et coraenv sont très pratiques
pour modifier l’environnement du compte et basculer d’une base à une autre.
Exemple
[oracle@srvlinora ~]$ tail -2 /etc/oratab
ORCL:/u01/app/oracle/product/11.1.0/db_1:Y
TEST:/u01/app/oracle/product/10.2.0/db_1:N
[oracle@srvlinora ~]$ sqlplus / as sysdba
-bash: sqlplus: command not found
[oracle@srvlinora ~]$ . oraenv
ORACLE_SID = [oracle] ? ORCL
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_1 is /u01/app/oracle
[oracle@srvlinora ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.1.0.6.0 ...
...
SQL> exit
...
[oracle@srvlinora ~]$ . oraenv
ORACLE_SID = [ORCL] ? TEST
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1 is /u01/app/oracle
[oracle@srvlinora ~]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 ...
...
SQL> exit
...
[oracle@srvlinora ~]$
c. Configurer le démarrage et l’arrêt automatique
Plate­forme Windows
Sur plate­forme Windows, l’installeur crée automatiquement les services qui permettent le démarrage et l’arrêt
© ENI Editions - All rights reserved - Algeria Educ
- 31 -
automatique des différents composants Oracle : processus d’écoute, base de données, console Oracle Enterprise
Manager.
Il n’y a donc rien de particulier à faire à ce stade.
Nous étudierons plus en détail ces différents composants dans la suite de cet ouvrage.
Plate­forme Unix ou Linux
Sur plate­forme Unix ou Linux, l’installeur ne configure aucun composant en démarrage automatique.
Il est de la responsabilité de l’administrateur du système (root) de créer un script de démarrage de ces composants
et le faire s’exécuter dans les niveaux d’exécution souhaités.
Dans cet ouvrage, nous allons présenter les actions à effectuer sur une plate­forme Red Hat Enterprise Linux ES 4.
Les principes sont les mêmes pour les autres distributions (ou Unix en général), mais certains chemins, certaines
valeurs ou certaines commandes peuvent être différents (consultez la documentation Oracle® Database
Administrator’s Reference de votre plate­forme et la documentation de votre système d’exploitation sur les
processus de démarrage et d’arrêt).
Connectez­vous en tant que root.
Dans le répertoire /etc/init.d, >créez un script nommé dbora avec un contenu similaire au suivant :
#! /bin/sh
#
# chkconfig: 35 99 01
# description: démarre et arrête les services Oracle
#
# Modifiez la valeur des variables suivantes pour tenir compte de
# votre environnement :
#
- ORACLE_HOME
#
chemin vers le répertoire Oracle Home des
#
scripts dbstart et dbshut
#
- ORACLE_HOME_LISTENER
#
chemin vers le répertoire Oracle Home du listener
#
- ORACLE
#
nom du compte oracle
#
- LOG
#
chemin vers un fichier journal
#
- VAR_LOCK
#
chemin vers le fichier utilisé par le système pour savoir
#
si le service est démarré
#
(normalement /var/lock/subsys/<nom du service>)
ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_1
ORACLE_HOME_LISTENER=$ORACLE_HOME
ORACLE=oracle
LOG=$ORACLE_HOME/dbora.log
VAR_LOCK=/var/lock/subsys/dbora
#
# Si le script est appelé sans deuxième paramètre (appel initial),
# on le relance sous le compte oracle (du coup avec un deuxième
# paramètre)
if [ ! "$2" = "ORA" ] ; then
su - $ORACLE -c "$0 $1 ORA"
case $1 in
’start’)
# indiquer que le service a démarré (du moins a priori)
touch $VAR_LOCK
;;
’stop’)
# indiquer que le service a été stoppé (du moins a priori)
rm -f $VAR_LOCK
esac
exit
fi
PATH=${PATH}:$ORACLE_HOME/bin
export ORACLE_HOME PATH
- 32 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
touch $LOG
chmod a+r $LOG
case $1 in
’start’)
echo "***** $(date) - $0 : démarrage" > $LOG
$ORACLE_HOME/bin/dbstart $ORACLE_HOME_LISTENER > $LOG 2>&1 &
;;
’stop’)
echo "***** $(date) - $0 : arrêt" > $LOG
$ORACLE_HOME/bin/dbshut $ORACLE_HOME_LISTENER > $LOG 2>&1 &
;;
*)
echo "usage: $0 {start|stop}"
;;
esac
exit
Depuis la version 11, les scripts dbstart et dbshut prennent en charge le démarrage et l’arrêt du processus
d’écoute. En conséquence, le script présenté ci­dessus permet le démarrage et l’arrêt automatique du
processus d’écoute et des bases de données. Par contre, il doit être complété pour prendre en charge la console
Oracle Enterprise Manager.
Changer le groupe du fichier dbora en dba (ou votre groupe OSDBA s’il est différent) et modifier les permissions du
fichier :
chgrp dba dbora
chmod 750 dbora
Créer des liens symboliques vers le script dbora dans les répertoires des niveaux d’exécution adéquats, par exemple
pour avoir un démarrage (plutôt en dernier) dans les niveaux 3 et 5, et un arrêt (plutôt en premier) dans les niveaux
0 (arrêt du système) et 6 (redémarrage du système) :
ln
ln
ln
ln
-s
-s
-s
-s
/etc/init.d/dbora
/etc/init.d/dbora
/etc/init.d/dbora
/etc/init.d/dbora
/etc/rc.d/rc0.d/K01dbora
/etc/rc.d/rc3.d/S99dbora
/etc/rc.d/rc5.d/S99dbora
/etc/rc.d/rc6.d/K01dbora
Ces liens symboliques peuvent être créés par l’utilitaire chkconfig qui exploite les informations contenues dans les
commentaires en début de script :
chkconfig --add dbora
Le système est opérationnel.
Si plusieurs versions d’Oracle sont installées sur votre serveur, il faut plutôt utiliser la version la plus récente
dans le script dbora (avec une variable $ORACLE_HOME configurée en conséquence). La seule exception
potentielle concerne le démarrage de la console Oracle Enterprise Manager (cf. Chapitre Les outils
d’administration). Si besoin, ce script peut être adapté, ou scindé en plusieurs scripts, afin d’utiliser différents
Oracle Home.
© ENI Editions - All rights reserved - Algeria Educ
- 33 -
Installation du client
Les procédures d’installation d’un client Oracle ressemblent beaucoup, en plus simples, aux procédures d’installation
du serveur. En conséquence, dans cet ouvrage, nous présenterons ces procédures de manière très synthétique. Pour
plus d’informations, reportez­vous à la documentation Oracle spécifique à votre plate­forme
●
Oracle® Database Client Installation Guide for...
●
Oracle® Database Client Quick Installation Guide for...
●
Oracle® Database Client Release Notes for...
Les similitudes d’installation entre un serveur et un client portent notamment sur :
●
●
Les différentes étapes de l’installation (pré­installation, installation avec Oracle Universal Installer, post­
installation) ;
Le standard OFA, avec notamment un répertoire Oracle Home (plusieurs clients peuvent être installés sur la
même machine) ;
●
Les spécificités de chaque plate­forme (variables d’environnement, base de registre, etc.) ;
●
La possibilité d’effectuer une installation non interactive, en utilisant un fichier de réponse.
Un client Oracle comporte généralement au minimum le composant Oracle Net qui permet d’accéder à une base Oracle
du réseau. En complément, le client peut comporter :
●
des outils d’interrogation ou d’administration (SQL*Plus, etc.) ;
●
des produits nécessaires pour le développement ou le déploiement d’applications.
Les produits pour le développement ou le déploiement qui peuvent être installés, varient d’une plate­forme à l’autre.
Les principaux produits sont les suivants :
●
OCI (Oracle Call Interface ­ API de bas niveau utilisable en C par exemple) ;
●
Oracle Object For OLE (produit équivalent à OLE DB) ;
●
Drivers ODBC ;
●
Provider pour OLE DB ou .NET ;
●
Drivers JDBC ;
●
pré­compilateurs Pro*C/C++, Pro*COBOL...
L’installation proprement dite s’effectue avec Oracle Universal Installer. Les principales étapes sont les suivantes :
●
spécification du répertoire d’inventaire (première installation sur plate­forme Linux ou Unix) ;
●
désignation de l’emplacement des fichiers (Oracle Home) ;
●
choix d’un type d’installation (voir ci­dessous) ;
●
choix éventuel des composants à installer (installation personnalisée uniquement) ;
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
●
affichage d’un écran de synthèse permettant de confirmer l’installation.
Les types d’installation proposés par l’installeur sont les suivants :
InstantClient : n’installe que les librairies nécessaires aux applications qui utilisent les OCI avec la fonctionnalité de
"client instantané" (instant client). Nécessite peu d’espace disque (plus ou moins 150 Mo selon la plate­forme).
Administrateur : installe la quasi­totalité des composants, y compris les outils d’administration et les produits de
développement
Runtime : installe un client simple comportant principalement Oracle Net, SQL*Plus et les drivers JDBC.
Personnalisée : permet de sélectionner précisément les composants et d’installer un client parfaitement adapté à un
besoin précis (développeur, déploiement) : avec ou sans outil (SQL*Plus par exemple), avec un produit de
développement précis, etc.
La fonctionnalité de "client instantané" permet d’établir une connexion à une base de données sans
configuration préalable d’Oracle Net (cf. Chapitre Oracle Net).
À la fin de l’installation, dans le cas d’une installation autre que InstantClient, l’assistant Configuration Oracle Net est
lancé, en mode automatique ou interactif selon le type d’installation, afin de configurer le composant Oracle Net. Dans
le cas d’une installation Runtime, l’assistant effectue une configuration standard : cliquez simplement sur le bouton
Suivant puis sur le bouton Terminer. Dans le cas d’une installation Administrateur ou Personnalisée, l’assistant
propose d’effectuer une configuration standard ou une configuration manuelle. La configuration standard est souvent
suffisante, au moins pour démarrer. En cas de besoin, l’assistant Configuration Oracle Net peut être relancé
ultérieurement. Pour effectuer une configuration standard, cochez la case Exécuter la configuration standard puis
cliquez sur le bouton Suivant (deux fois), puis sur le bouton Terminer.
Sur plate­forme Unix ou Linux, après en avoir terminé avec la configuration Oracle Net, il faut exécuter le script root.sh
dans une connexion root.
L’installation est alors terminée !
L’environnement de travail peut ensuite être configuré comme sur le serveur (cf. section Installation du serveur dans le
chapitre Installation).
À ce stade, vous pouvez tester une connexion avec votre base en utilisant la méthode de résolution de nom Easy
Connect :
> sqlplus system/xxxx@//hôte/service
Pour utiliser une autre méthode de résolution de nom, il faut configurer Oracle Net (cf. Chapitre Oracle Net).
Sur OTN, vous pouvez télécharger un client instantané (instant client) sous la forme d’une archive compressée
qui s’installe directement par décompression, sans utiliser Oracle Universal Installer. Pour utiliser ce client
instantané, il faut juste ajouter le répertoire d’installation dans la variable d’environnement utilisée pour le
chargement des librairies (PATH sur plate­forme Windows et LD_LIBRARY_PATH sur plate­forme Unix ou Linux).
- 2-
© ENI Editions - All rights reserved - Algeria Educ
Introduction
1. Rôle d’Oracle Net
Oracle Net permet à des produits Oracle situés sur des machines différentes de communiquer. Les fonctions
essentielles d’Oracle Net sont d’établir des sessions de communication réseau entre deux machines (client ↔ serveur
ou serveur ↔ serveur) et de transférer les données entre les deux machines.
Dans cet ouvrage, nous nous intéresserons uniquement à la communication entre un client et un serveur. La
communication entre deux serveurs est un cas particulier où un serveur joue le rôle de client vis­à­vis de l’autre
serveur ; sur ce serveur client, Oracle Net doit être configuré à la fois en serveur et en client.
Oracle Net a pour objectif de rendre le réseau "transparent" pour les applications : les applications n’ont pas besoin
de savoir où se trouve le serveur, quel est le protocole à utiliser pour s’y connecter, etc. Les applications ont
simplement besoin de connaître un nom de service réseau (sorte d’alias) qui leur permettra d’établir une connexion
avec la base de données souhaitée.
Oracle Net doit être installé côté client et côté serveur ; cette installation est réalisée par défaut par Oracle Universal
Installer. Après installation, la couche Oracle Net doit être configurée, là encore, côté client et côté serveur.
2. Principes de fonctionnement
Le schéma suivant illustre le fonctionnement (simplifié) d’Oracle Net :
Lorsqu’une application cliente utilise un nom de service réseau pour se connecter, ce nom de service réseau est
résolu par Oracle Net en un descripteur de connexion comportant l’adresse du service : protocole à utiliser, adresse
du serveur, port de communication (dans le cas du protocole TCP) et nom du service (instance dans le cas qui nous
intéresse).
Côté serveur, un processus d’écoute est chargé de recevoir les demandes de connexion et de les transmettre à la
base concernée. Ce processus d’écoute se matérialise par un service sur plate­forme Windows et un processus sur
plate­forme Unix ; il est configuré par le fichier listener.ora.
Plusieurs méthodes peuvent être utilisées pour la résolution du nom de service :
Locale (local naming)
Un fichier de configuration (tnsnames.ora), situé sur le poste de l’utilisateur, se charge de la résolution. Cette
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
méthode est la plus couramment utilisée.
Connexion simplifiée (easy connect naming)
La connexion s’effectue sans nom de service, en utilisant directement une adresse TCP/IP du type [//]hôte[:port]
[/service]. Cette méthode est utilisable uniquement en environnement TCP/IP. Elle ne nécessite aucune
configuration mais le réseau n’est plus transparent pour l’utilisateur. Cette méthode est apparue en version 10.
Annuaire LDAP (directory naming)
Un annuaire LDAP se charge de la résolution. Cette méthode nécessite un produit tiers.
Externe
Un produit tiers se charge de la résolution.
Par défaut (configuration standard), Oracle Net est configuré côté client pour utiliser la méthode de résolution de nom
locale et la connexion simplifiée (si TCP/IP est installé sur le poste client).
3. Nom de service et nom d’instance
Depuis Oracle8i, une instance peut être identifiée par un ou plusieurs noms de service, en plus de l’identifiant de
l’instance (SID). Ces noms de service peuvent être définis grâce au paramètre SERVICE_NAMES du fichier d’initialisation.
L’identifiant de l’instance peut être vu comme étant le nom "physique" de l’instance. Le nom de service de l’instance
peut être vu comme un nom logique, correspondant à un service offert par la base de données ouverte par l’instance.
Par exemple, si une base abrite deux applications (une application de paie et une application de gestion des
ressources humaines), il est possible de définir deux noms de service pour l’instance :
SERVICE_NAMES = paie,rh
Un nom de service peut inclure une identification de domaine. Exemple : paie.olivier.fr.
Par défaut, le paramètre SERVICE_NAMES est égal au nom global de la base de données (DB_NAME.DB_DOMAIN). Si le
paramètre DB_DOMAIN est vide (valeur par défaut), le paramètre SERVICE_NAMES est alors égal par défaut au paramètre
DB_NAME, qui est lui­ même généralement égal au nom de l’instance ; dans ce cas, nom de service et nom d’instance
sont égaux.
Lors de la définition d’un nom de service réseau, il est possible de désigner l’instance cible, soit par son identifiant,
soit par un nom de service.
Les services sont aussi utilisés par Oracle pour faire un suivi d’activité par service (charge, performance, priorité, etc.).
Ils peuvent être gérés et supervisés dans le Database Control. Ils peuvent aussi être supervisés par plusieurs vues
du dictionnaire de données (DBA_ SERVICES, V$ACTIVE_SERVICES, etc.) et gérés par le package DBMS_SERVICE.
- 2-
© ENI Editions - All rights reserved - Algeria Educ
Configuration côté serveur
1. Configuration du processus d’écoute
La configuration côté serveur consiste à configurer le processus d’écoute LISTENER, c’est­à­dire à indiquer "comment"
et pour quelles bases il "écoute".
Cette configuration peut s’effectuer directement dans le fichier listener.oramais cela nécessite de bien comprendre
la structure de ce fichier, ce qui n’est pas immédiat (voir l’exemple plus loin). Le plus simple consiste alors à utiliser
l’application Oracle Net Manager(menu Programmes ­ Oracle ­ nom_oracle_home ­ Outils de configuration et de
migration ­ Net Manager sur plate­forme Windows ou script shell netmgr sur plate­forme Unix).
Si aucune base de données n’a été créée durant l’installation d’Oracle, aucun processus d’écoute n’a encore été
créé ; dans ce cas, le dossier Processus d’écoute est vide. Pour créer un processus d’écoute, sélectionnez le menu
Modifier ­ Créer et donnez un nom au processus d’écoute (par exemple LISTENER) dans la boîte de dialogue qui
s’affiche.
Le fichier listener.orase trouve par défaut dans le répertoire $ORACLE_HOME/ network/admin (plate­forme Unix ou
Linux) ou %ORACLE_HOME%\network\admin (plate­forme Windows). Cet emplacement peut être modifié en définissant la
variable d’environnement TNS_ADMIN.
Le processus d’écoute peut aussi être configuré et administré à partir de la console Oracle Enterprise
Manager.
Paramètres généraux
La configuration des paramètres généraux s’effectue dans les trois onglets Général, Journalisation et trace et
Authentification.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
L’onglet Journalisation et trace permet d’activer ou de désactiver la journalisation (active par défaut) et la trace
(inactive par défaut). Le fichier journal enregistre essentiellement des informations sur le démarrage du processus
d’écoute et les demandes de connexion reçues. Depuis la version 11, ce fichier (nommé listener.log) se trouve par
défaut dans le Référentiel de Diagnostic Automatique (Automatic Diagnostic Repository) : répertoire
$ORACLE_BASE/diag/tnslsnr/<nom hôte>/<nom listener>/trace (plate­forme Unix ou Linux) ou %ORACLE_BASE%
\diag\tnslsnr\<nom hôte>/<nom listener>/trace (plate­forme Windows). Pour pouvoir modifier l’emplacement par
défaut, il faut désactiver l’utilisation d’ADR ; tant que ce n’est pas le cas, les éventuelles modifications effectuées dans
Oracle Net Manager ne sont pas prises en compte. La trace peut être activée pour aider à résoudre des problèmes
de fonctionnement du processus d’écoute. Là encore, depuis la version 11, les fichiers de traces sont enregistrés par
défaut dans ADR, au même emplacement que le fichier journal.
L’onglet Authentification permet de définir un mot de passe à utiliser pour lancer l’utilitaire lsnrctl (voir plus loin).
Lorsque les paramètres généraux sont personnalisés, ils sont enregistrés dans le fichier listener.ora.
Exemple :
PASSWORDS_LISTENER= (54290B53985ADB21 )
TRACE_LEVEL_LISTENER = USER
Emplacements d’écoute
Les emplacements d’écoute sont des adresses réseaux utilisées par le processus d’écoute pour recevoir les
demandes de connexion à une base de données.
Le processus d’écoute peut écouter à plusieurs adresses (pour des protocoles différents, pour des variantes du
même protocole ­ par exemple deux ports en TCP/IP, etc.).
La configuration de l’emplacement d’écoute dépend du protocole :
●
●
●
TCP/IP : indique le nom ou l’adresse IP du serveur et le port de communication (1521 par défaut).
IPC (Interprocess Communication) : indique un nom unique de service (nom de l’instance pour une base de
données).
NMP (Named Pipes) : indique le nom du serveur et le nom du canal (typiquement ORAPIPE).
Les définitions des emplacements d’écoute sont enregistrées de la manière suivante dans le fichier listener.ora :
LISTENER =
(DESCRIPTION_LIST =
- 2-
© ENI Editions - All rights reserved - Algeria Educ
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = srvwinora)(PORT = 1521))
)
Les lignes en gras correspondent à une définition d’emplacement d’écoute.
Services de base de données
Cet écran permet de définir les services de base de données inscrits (ou enregistrés) auprès du processus d’écoute,
c’est­à­dire ceux pour lesquels le processus d’écoute accepte des demandes de connexion.
Les bases de données inscrites auprès du processus d’écoute sont définies par l’identifiant de l’instance (SID), le nom
global de la base de données (DB_NAME.DB_DOMAIN, ou une des valeurs du paramètre SERVICE_NAMES, ou toute autre
valeur) et le chemin du répertoire Oracle Home de la base de données.
Le processus d’écoute peut accepter des demandes de connexion pour plusieurs bases de données,
éventuellement pour des versions d’Oracle différentes.
Les définitions des services de base de données sont enregistrées de la manière suivante dans le fichier
listener.ora :
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = ORCL)
(ORACLE_HOME = d:\app\oracle\product\11.1.0\db_1)
(SID_NAME = ORCL)
)
)
Les lignes en gras correspondent à une définition de service de base de données.
En règle générale, il y a un seul processus d’écoute par serveur, même si le serveur abrite plusieurs bases
de données. Si ces bases de données utilisent des versions différentes d’Oracle, il faut plutôt utiliser le
processus d’écoute de la version la plus récente.
2. Gestion du processus d’écoute
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Le processus d’écoute se matérialise par un service (Oracle<nom_oracle_home>TNSListener) sur plate­forme Windows
et par un processus (tnslsnr) sur plate­forme Unix ou Linux.
Le processus d’écoute s’administre grâce à l’utilitaire lsnrctl, disponible sur toutes les plates­formes.
Syntaxe :
lsnrctl [commande]
Lorsque l’utilitaire est appelé sans commande, il se lance et affiche une invite :
LSNRCTL>
Les commandes peuvent alors être saisies sur la ligne d’invite.
Les principales commandes sont les suivantes :
HELP
Affiche la liste des commandes.
HELP commande
Affiche l’aide d’une commande.
START
Démarre le processus d’écoute.
STOP
Arrête le processus d’écoute.
STATUS
Affiche des informations sur la configuration du processus d’écoute, les emplacements d’écoute et les services
enregistrés.
SERVICES
Affiche des informations détaillées sur les services enregistrés auprès du processus d’écoute.
RELOAD
Recharge la configuration du processus d’écoute (listener.ora). Permet d’ajouter ou de modifier les services
enregistrés auprès du processus d’écoute, sans arrêter ce dernier.
Les commandes peuvent être saisies indifféremment en majuscules ou en minuscules. Sur plate­forme Windows, le
processus d’écoute peut aussi être démarré et arrêté en démarrant ou en arrêtant le service associé.
Exemple :
C:\>lsnrctl
LSNRCTL for 32-bit Windows: Version 11.1.0.6.0 - Production
on 22-JUIN -2008 21:26:04
Copyright (c) 1991, 2007, Oracle. All rights reserved.
Bienvenue dans LSNRCTL, tapez "help" pour plus d’informations.
LSNRCTL> status
Connexion à (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521)))
STATUT du PROCESSUS D’ECOUTE
---------------------------Alias
LISTENER
Version
TNSLSNR for 32-bit Windows: Version
11.1.0.6.0 - Production
Date de départ
22-JUIN -2008 21:12:45
Durée d’activité
0 jours 0 heures 13 min. 25 sec
Sécurité
ON: Local OS Authentication
SNMP
OFF
- 4-
© ENI Editions - All rights reserved - Algeria Educ
Fichier de paramètres du processus d’écoute
D:\app\oracle\product\
11.1.0\db_1\network\admin\listener.ora
Fichier journal du processus d’écoute
d:\app\oracle\diag\tnslsnr\srvwinora\listener\alert\
log.xml
Récapitulatif d’écoute des points d’extrémité...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\pipe\EXTPROC1521ipc)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=srvwinora)(PORT=1521)))
Récapitulatif services...
Le service "ORCL" comporte 1 instance(s).
L’instance "ORCL", statut UNKNOWN, comporte 1 gestionnaire(s)
pour ce service
La commande a réussi
LSNRCTL>
Sur plate­forme Windows, si le service associé au processus d’écoute n’existe pas, un message d’erreur est affiché
lors du démarrage, mais le service est alors automatiquement créé et le processus d’écoute est bien démarré :
LSNRCTL> start
Starting tnslsnr: please wait...
Failed to open service <OracleOraDb11g_home1TNSListener>, error 1060.
3. Démarrage automatique du processus d’écoute
Généralement, il est souhaitable que le processus d’écoute soit démarré automatiquement lors du démarrage du
système.
Sur plate­forme Windows, le processus d’écoute peut être démarré automatiquement lors du démarrage du système,
en positionnant le service associé (Oracle<nom_oracle_ home>TNSListener) en démarrage automatique.
Sur plate­forme Unix ou Linux, le processus d’écoute peut être démarré automatiquement grâce au script de
démarrage présenté dans la section Installation du serveur du chapitre Installation ­ Configurer le démarrage et
l’arrêt automatique. Ce script de démarrage appelle les scripts Oracle dbstart et dbshut qui prennent en charge le
démarrage et l’arrêt du processus d’écoute depuis la version 11.
Extraits du script :
$ORACLE_HOME/bin/dbstart $ORACLE_HOME_LISTENER > $LOG 2>&1 &
...
$ORACLE_HOME/bin/dbshut $ORACLE_HOME_LISTENER > $LOG 2>&1 &
Les scripts dbstart et dbshut acceptent en paramètre le chemin Oracle Home du processus d’écoute à démarrer ou à
arrêter ; s’il y a plusieurs versions d’Oracle installées sur le serveur, cela permet de choisir la version du processus
d’écoute à utiliser.
4. Enregistrement dynamique de services
Depuis Oracle8i, une instance est capable d’enregistrer automatiquement des services auprès du processus d’écoute.
Aucune configuration n’est requise dans le fichier listener.ora.
L’enregistrement automatique s’effectue par défaut auprès du processus d’écoute sur le serveur, en TCP/IP, sur le
port 1521. Pour effectuer l’enregistrement automatique à une autre adresse, il faut configurer le paramètre
d’initialisation LOCAL_LISTENER en y indiquant un nom de service réseau qui doit être résolu (par exemple avec le
fichier tnsnames.ora) en une adresse de processus d’écoute.
Les noms des services automatiquement enregistrés proviennent du paramètre d’initialisation SERVICES_NAMES.
L’enregistrement dynamique s’effectue en complément de l’enregistrement statique éventuellement défini dans le
fichier listener.ora. Avec ces deux mécanismes, une instance peut présenter plusieurs services dans le processus
d’écoute, ce qui est parfois déroutant.
Avec l’enregistrement automatique, une instance non démarrée n’est pas connue du processus d’écoute.
Cela pose un problème si l’instance doit être démarrée à partir d’un poste du réseau car le processus
d’écoute refusera la demande de connexion (erreur ORA-12514). Dans ce cas, il faut prévoir un enregistrement
statique dans le fichier listener.ora.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 5-
Il peut y avoir d’autres services enregistrés auprès du processus d’écoute correspondant à des
fonctionnalités installées dans la base de données (Oracle XML DB par exemple).
- 6-
© ENI Editions - All rights reserved - Algeria Educ
Configuration côté client
1. Introduction
Pour configurer le client, il faut :
●
sélectionner les méthodes de résolution de noms utilisables par le client ;
●
configurer les méthodes de résolution de noms sélectionnées.
Les méthodes de résolution de noms utilisables par le client sont stockées dans le fichier sqlnet.ora. Si la méthode
de résolution de nom locale est utilisée, il faut en plus définir un ou plusieurs noms de service réseau dans le fichier
tnsnames.ora.
Ces deux fichiers se trouvent par défaut dans le répertoire $ORACLE_HOME/network/ admin (plate­forme Unix ou Linux)
ou %ORACLE_HOME%\network\admin (plate­forme Windows). Cet emplacement peut être modifié en définissant la
variable d’environnement TNS_ADMIN.
Les fichiers sqlnet.ora et tnsnames.ora peuvent être édités directement mais cela nécessite de bien comprendre leur
structure et de bien connaître la syntaxe et le rôle des différents paramètres.
Le plus simple consiste alors à utiliser l’application Oracle Net Manager (menu Programmes ­ Oracle ­
nom_oracle_home ­ Outils de configuration et de migration ­ Net Manager sur plate­forme Windows ou script
shell netmgr sur plate­forme Unix).
2. Sélection des méthodes de résolution de noms
Pour configurer les méthodes de résolution de noms utilisables par le client, cliquez sur l’icône Profil, puis
sélectionnez l’élément Affectation de noms dans la liste déroulante :
Dans une configuration standard, la méthode de résolution de nom locale (TNSNAMES) et la méthode de connexion
simplifiée (EZCONNECT) sont sélectionnées par défaut. En utilisant les différents boutons de ce panneau, il est possible
d’ajouter ou de supprimer des méthodes et de modifier l’ordre dans lequel les méthodes seront utilisées :
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Sur l’exemple précédent, la méthode de résolution de nom d’hôte (HOSTNAME) a été ajoutée dans la liste.
La zone Domaine par défaut permet d’ajouter un nom de domaine par défaut aux noms de service réseau utilisés.
Ce nom de domaine par défaut est souvent une source de problème. S’il est défini (valeur X par exemple), il est
automatiquement ajouté au nom de service réseau lors de la connexion, si aucun domaine n’est indiqué (CONNECT ...
@ORCL devient CONNECT ... @ORCL.X). Si le nom de service ainsi constitué (ORCL.X) ne peut pas être résolu par une
des méthodes de résolution de nom, une erreur est retournée (erreurORA-12154). Pour éviter ce genre de problème,
le plus simple est de ne pas définir de nom de domaine par défaut.
Les différentes informations saisies dans cet écran sont enregistrées dans le fichier sqlnet.ora.
Exemple :
NAMES.DIRECTORY_PATH= (EZCONNECT, TNSNAMES, HOSTNAME)
# NAMES.DEFAULT_DOMAIN = X
Le paramètre NAMES.DIRECTORY_PATH contient la liste ordonnée des méthodes de résolution de nom utilisables.
Le paramètre NAMES.DEFAULT_DOMAIN (ici en commentaire) contient le nom de domaine par défaut.
3. Configuration des méthodes de résolution de nom
a. Résolution de nom locale
Des noms de service réseau peuvent être définis dans le fichiertnsnames.ora avec l’application Oracle Net
Manager :
Pour afficher la liste des noms de service réseau déjà définis, double cliquez sur le dossier Résolution de noms de
service.
Pour créer un nouveau nom de service réseau, sélectionnez le dossier Résolution de noms de service puis
sélectionnez le menu Modifier ­ Créer.
- 2-
© ENI Editions - All rights reserved - Algeria Educ
Saisissez le nom de service réseau souhaité puis cliquez sur le bouton Suivant.
Sélectionnez le protocole réseau utilisé (TCP/IP dans cet exemple) puis cliquez sur le bouton Suivant.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Les paramètres du protocole dépendent du protocole sélectionné. Dans le cas du protocole TCP/IP, saisissez le nom
du serveur Oracle ou son adresse IP et le numéro du port (1521 par défaut, mais si un autre port a été configuré
pour le processus d’écoute, utilisez le même ici).
Dans le cas du protocole IPC, vous devez indiquer un nom de clé (reprendre la valeur utilisée pour le processus
d’écoute, généralement le nom de l’instance). Dans le cas du protocole Named Pipes, vous devez indiquer le nom de
la machine et le nom du canal (reprendre la valeur utilisée pour le processus d’écoute, habituellement ORAPIPE).
Cliquez sur le bouton Suivant.
Pour identifier l’instance cible, saisissez au choix un nom de service ou un identifiant d’instance (SID). Le nom de
service doit être un des noms de service enregistrés auprès du processus d’écoute (cf. section Configuration côté
serveur dans ce chapitre).
La liste déroulante Type de connexion permet de définir le type de connexion souhaité : Valeur par défaut de la
base de données (valeur par défaut), Serveur dédié ou Serveur partagé. Le choix de l’option Serveur dédié est
nécessaire pour forcer une connexion à un serveur dédié alors que le serveur est configuré en serveur partagé.
Cliquez sur le bouton Suivant ; l’écran suivant permet de tester le nouveau nom de service réseau.
- 4-
© ENI Editions - All rights reserved - Algeria Educ
Cliquez sur le bouton Terminer. Le nouveau nom de service réseau apparaît dans le dossier ; il peut être
sélectionné et modifié directement si besoin :
Les noms de service réseau ainsi définis, sont enregistrés dans le fichier tnsnames.ora.
Exemple :
ORCL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = SRVWINORA)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = ORCL)
)
)
Après configuration du processus d’écoute côté serveur, il est judicieux, en restant sur le serveur, de
configurer un nom de service réseau et de tenter une connexion à l’aide de ce nom afin de tester la
configuration. Ensuite, si la configuration d’un poste ne fonctionne pas, la configuration du serveur ne sera, a
priori, pas en cause. De plus, si le serveur héberge plusieurs bases de données, les noms de service réseau
pourront être utilisés pour passer rapidement d’une base à l’autre (pas besoin de modifier la variable
d’environnement ORACLE_SID).
Le fichier tnsnames.ora ne contient aucune information relative au poste ; il est donc parfaitement possible d’en
créer un sur un poste puis de le diffuser sur tous les autres postes.
b. Connexion simplifiée
La méthode de résolution de nom Easy Connect ne nécessite aucune configuration côté client et peut être utilisée
directement, si elle a été, au préalable, sélectionnée comme méthode de résolution de nom dans le fichier
sqlnet.ora(cf. section Configuration des méthodes de résolution de nom dans ce chapitre). Cette méthode est
apparue en version 10 et est utilisable uniquement en environnement TCP/IP.
L’adresse de connexion est définie de la manière suivante :
[//]hôte[:port][/service]
Avec :
hôte
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 5-
Nom du serveur (éventuellement qualifié par un domaine) ou adresse IP du serveur.
port
Port utilisé par le processus d’écoute (1521 par défaut).
service
Nom de service auquel se connecter. Le nom de service doit être un des noms de service enregistrés auprès du
processus d’écoute (cf. section Configuration côté serveur dans ce chapitre). Si le nom de service n’est pas spécifié,
le processus se connecte à la base définie par le paramètre DEFAULT_SERVICE_<nom_listener> dans le fichier
listener.ora.
Exemple :
srvwinora/orcl
srvwinora:1522/test.olivier.fr
- 6-
© ENI Editions - All rights reserved - Algeria Educ
Problèmes courants et solutions
Les problèmes possibles de connexion entre un client et un serveur sont nombreux.
ORA-12541: TNS : pas de processus d’écoute
TNS-12541: TNS : aucun processus d’écoute
Explication
Le serveur spécifié par la chaîne de connexion a bien été trouvé, mais aucun processus d’écoute ne répond.
Cause(s)
Le processus d’écoute n’est pas lancé.Le port indiqué dans la chaîne de connexion ne correspond pas au port d’écoute
du processus d’écoute.
Action(s)
Vérifier que les ports sont bien configurés de la même manière côté client et côté serveur. Vérifier si le processus
d’écoute est démarré (le démarrer si besoin (ne pas hésiter à le redémarrer en cas de doute)).
ORA-12505: TNS : le processus d’écoute ne connaît pas
actuellement le SID indiqué dans le descripteur de connexion
ORA-12514: TNS : le processus d’écoute ne connaît pas
actuellement le service demandé dans le descripteur de connexion
Explication
Le processus d’écoute a bien été contacté mais le SID ou le SERVICE_NAME indiqué dans la chaîne de connexion ne
correspond à aucune instance écoutée par le processus d’écoute.
Cause(s)
Le SID ou SERVICE_NAME indiqué dans la chaîne de connexion n’est pas bon. Le SID_NAME spécifié dans le fichier de
configuration du processus d’écoute n’est pas bon.
Action(s)
Vérifier que les identifiants d’instance ou les noms de service correspondent bien entre le client et le serveur (utiliser la
commande status ou services dans l’utilitaire lsnrctl). En cas de doute, utiliser un SID à la place d’un SERVICE_NAME
dans la chaîne de connexion.
ORA-12545: Connexion impossible car l’hôte ou l’objet cible
n’existe pas
TNS-12545: la connexion a échoué car l’hôte ou l’objet cible
n’existe pas
Explication
Le serveur indiqué dans la chaîne de connexion n’a pas pu être contacté.
Cause(s)
Le nom du serveur est erroné.
Action(s)
Vérifier la validité du nom du serveur. Éventuellement, remplacer le nom du serveur par son adresse IP. Vérifier si le
serveur est accessible.
ORA-12170: TNS : délai de connexion dépassé
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
TNS-12535: TNS : le délai imparti à l’opération est écoulé
Explication
Le serveur indiqué dans la chaîne de connexion n’a pas pu être contacté dans le délai imparti (défini par le paramètre
SQLNET. INBOUND_CONNECT_TIMEOUT du fichier sqlnet.ora côté client).
Cause(s)
Le nom du serveur (ou l’adresse IP) est erroné. Le serveur n’est pas accessible ou il y a un problème réseau (coupure,
ralentissement).
Action(s)
Vérifier la validité du nom du serveur ou de l’adresse IP. Éventuellement, remplacer le nom du serveur par son adresse
IP. Vérifier si le serveur est accessible et s’il n’y a pas de problème réseau. Modifier la valeur du paramètre
SQLNET.INBOUND_CONNECT_ TIMEOUT.
ORA-12154: TNS : l’identificateur de connexion indiqué n’a pas pu être
résolu
TNS-03505: Echec de la résolution du nom
Explication
Le nom de service réseau utilisé pour la connexion (@) n’a pas pu être résolu par une des méthodes de résolution de
nom autorisées côté client.
Cause(s)
Le nom de service réseau utilisé dans la connexion est erroné (faute de frappe). Il n’existe par de nom de service
réseau correspondant dans le fichier tnsnames.ora (méthode de résolution locale). Le nom de service réseau n’a pas
pu être traduit en adresse IP (méthode de résolution de nom d’hôte). Le nom de service réseau n’a pas pu être résolu
en hôte[:port] [/service] (connexion simplifiée).
Action(s)
Vérifier que les méthodes de résolution de nom souhaitées sont bien configurées dans le fichier sqlnet.ora. Si la
méthode de résolution de nom local est utilisée, vérifier que le nom de service réseau utilisé dans la connexion est bien
défini dans le fichier tnsnames.ora (penser notamment à l’existence éventuelle d’un nom de domaine par défaut défini
dans le fichier sqlnet.ora). Si une autre méthode de résolution de nom est utilisée, vérifier que la syntaxe et la
configuration sont correctes.
Si vous obtenez une erreur ORA-01033 ou ORA-01034, la configuration Oracle Net n’est pas en cause ; l’instance est
arrêtée, ou elle est démarrée mais la base n’est pas ouverte.
Pour aider à établir un diagnostic, l’utilitaire tnsping peut être utilisé côté client.
Syntaxe :
tnsping nom_de_service
L’utilitaire tnsping teste si le nom de service passé en paramètre peut être résolu et si la cible peut être contactée.
En cas de succès, tnsping affiche le nom de la méthode de résolution de nom utilisée, la chaîne de connexion utilisée et
le temps mis pour contacter la cible. En cas d’échec, tnsping affiche un message d’erreur, ainsi que le nom de la
méthode de résolution de nom utilisée et la chaîne de connexion utilisée, s’il a pu résoudre le nom de service réseau.
Exemples
C:\>tnsping orcl
TNS Ping Utility for 32-bit Windows: Version 11.1.0.6.0 - Production
on 24-JUIN-2008 06:52:18
Copyright (c) 1997, 2007, Oracle. All rights reserved.
Fichiers de paramètres utilisés :
C:\app\oracle\product\11.1.0\client_1\network\admin\sqlnet.ora
Adaptateur TNSNAMES utilisé pour la résolution de l’alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)
(HOST = SRVWINORA)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = ORCL)))
- 2-
© ENI Editions - All rights reserved - Algeria Educ
OK (30 msec)
C:\>tnsping srvwinora/orcl
…
Fichiers de paramètres utilisés :
C:\app\oracle\product\11.1.0\client_1\network\admin\sqlnet.ora
Adaptateur EZCONNECT utilisé pour la résolution de l’alias
Attempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=orcl))
(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.154.51)(PORT=1521)))
OK (20 msec)
L’utilitaire tnsping teste uniquement si un processus d’écoute peut être contacté ; il ne teste pas si le nom de
service ou l’identifiant d’instance est connu du processus d’écoute.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Introduction
Oracle propose plusieurs outils d’administration :
●
●
●
●
SQL*Plus : outil de base permettant d’éditer et d’exécuter des requêtes SQL.
Oracle Enterprise Manager Database Control : application Web, permettant d’administrer graphiquement une
seule base de données.
Oracle Enterprise Manager Grid Control : application Web, similaire à la précédente, permettant d’administrer
de manière centralisée plusieurs bases de données.
Oracle SQL Developer : application graphique permettant d’exécuter des requêtes ou des scripts SQL, de gérer
les objets d’une base de données (tables, vues, etc.) et de développer et mettre au point des programmes
PL/SQL.
Oracle Enterprise Manager Grid Control est une infrastructure d’administration composée d’un serveur d’application,
d’un référentiel stocké dans une base de données Oracle et d’agents installés sur les différents nœ uds administrés. Ce
produit qui nécessite une installation séparée est intéressant pour les entreprises ayant un très grand nombre de
bases de données à administrer. Pour les entreprises ayant quelques bases à administrer, la version Database Control
est généralement suffisante. Oracle Enterprise Manager Grid Control n’est pas présenté dans cet ouvrage.
Sur plate­forme Windows, Oracle propose aussi l’application Oracle Administration for Windows (menu Démarrer ­
Programmes ­ Oracle ­ nom_oracle_home ­ Outils de configuration et de migration ­ Assistant d’administration
pour Windows). Cette application requiert le produit Microsoft Management Console.
Dans cet ouvrage, nous nous intéresserons uniquement à SQL*Plus, à Oracle SQL Developer et à Oracle Enterprise
Manager Database Control.
En complément, dans ce chapitre, nous présenterons brièvement la documentation Oracle (un autre « outil »
d’administration bien pratique !) puis nous parlerons des fichiers d’alerte et de trace, ainsi que du nouveau Référentiel
de Diagnostic Automatique (Automatic Diagnostic Repository).
© ENI Editions - All rights reserved - Algeria Educ
- 1-
SQL*Plus
1. Vue d’ensemble
Depuis la version 11, SQL*Plus est disponible uniquement en version ligne de commande. Les anciennes formes
SQL*Plus Windows, SQL*Plus Worksheet et iSQL*Plus n’existent plus.
SQL*Plus permet de saisir et d’exécuter des ordres SQL ou du code PL/SQL et dispose en plus de plusieurs
commandes, dont des commandes d’administration.
La connexion peut s’effectuer localement à l’instance définie par la variable d’environnement ORACLE_SID(section
Installation du serveur du chapitre Installation) ou bien à travers le réseau à l’instance définie par un nom de service
réseau ou une identification de >connexion simplifiée (cf. section Configuration côté client du chapitre Oracle Net).
Pour la connexion à travers le réseau, le nom de service réseau ou l’identification de connexion simplifiée peuvent
être indiqués lors du lancement de l’outil (voir ci­après) ou être définis dans une variable d’environnement :
●
TWO_TASK sur plate­forme Linux ou Unix ;
●
LOCAL sur plate­forme Windows (éventuellement dans la base de registre).
Exemple :
$ export TWO_TASK=orcl
$ export TWO_TASK=srvlinora:1521/orcl
C:\>set LOCAL=orcl
C:\>set LOCAL=srvwinora:1521/orcl
La variable d’environnement TWO_TASK ou LOCAL est prioritaire sur la variable d’environnement ORACLE_SID.
SQL*Plus propose beaucoup de commandes souvent très utiles pour écrire des scripts d’administration. Pour
plus d’informations, reportez­vous à la documentation SQL*Plus® User’s Guide and Reference.
2. Utilisation
a. Lancer SQL*Plus
La syntaxe pour lancer SQL*Plus en ligne de commande est la suivante :
sqlplus [ connexion | /NOLOG] [@fichier_script [argument [,...]]]
Syntaxe de l’option connexion :
[utilisateur]/[mot_de_passe][@service] [AS SYSDBA | AS SYSOPER]
Avec :
utilisateur
Nom de l’utilisateur Oracle.
mot de passe
Mot de passe de l’utilisateur.
service
Nom de service réseau ou identification de connexion simplifiée, utilisé(e) pour la connexion.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
AS SYSDBA |AS SYSOPER
Demande une connexion SYSDBA ou SYSOPER.
/NOLOG
Lance SQL*Plus sans établir de connexion.
fichier_script
Script à exécuter.
argument
Paramètre du script à exécuter.
Appeler SQL*Plus sans paramètre sur la ligne de commande provoque l’affichage d’une invite de connexion.
L’option /NOLOG permet de lancer SQL*Plus sans établir de connexion ; dans ce cas, la connexion peut être établie
ensuite avec la commande CONNECT.
Lorsqu’un script est soumis à SQL*Plus sur la ligne de commande, la connexion peut être assurée par la ligne de
commande ou par le script (dans ce cas, mettre l’option /NOLOG sur la ligne de commande). Par ailleurs, à la fin du
script, SQL*Plus ne quitte pas ; en cas de besoin, il faut donc penser à mettre une commande EXIT.
Exemple :
sqlplus /nolog
sqlplus system/xy$78@orcl
sqlplus @info.sql
sqlplus "/ as sysdba"
Avec le script info.sql :
CONNECT sys/ab$12@orcl AS SYSDBA
SELECT name FROM v$database;
EXIT
b. Se connecter
La commande CONNECT permet d’établir une nouvelle connexion.
Syntaxe :
CONNECT [utilisateur]/[ mot_de_passe][ @service] [AS SYSDBA | AS SYSOPER]
Les options sont les mêmes que lors du lancement de SQL*Plus en ligne de commande. La connexion en cours est
automatiquement déconnectée.
La commande DISCONNECT permet de se déconnecter.
Exemple:
SQL> CONNECT /@orcl AS SYSDBA
Connecté.
SQL> CONNECT system/xy$78@srvlinora:1521/orcl
Connecté.
Avant de se connecter, il est possible de taper la commande SET INSTANCE service pour définir le nom de service
réseau ou l’identifiant de connexion simplifiée à utiliser pour la totalité de la session ; cette commande doit être
saisie sans aucune connexion en cours, donc éventuellement après un DISCONNECT.
Exemple:
SQL> SET INSTANCE orcl
Oracle Database 11g Release 11.1.0.0.0 - Production
SQL> CONNECT / AS SYSDBA
Connecté.
- 2-
© ENI Editions - All rights reserved - Algeria Educ
SQL> CONNECT system/xy$78
Connecté.
c. Exécuter un script SQL
Les commandes START ou @ permettent d’exécuter un script SQL.
Syntaxe
START script
@script
script est le nom du script SQL à exécuter (avec le chemin si nécessaire) ; l’extension par défaut est .sql.
Vous serez parfois amenés à exécuter des scripts situés dans l’arborescence Oracle Home. Le point d’interrogation
(?) peut être utilisé comme raccourci du chemin vers le répertoire Oracle Home. Par ailleurs, sur plate­forme
Windows, SQL*Plus accepte le séparateur / (à la place de \) dans la spécification d’un chemin.
Exemple
SQL> @?/rdbms/admin/utlpwdmg
d. Exécuter une commande du système d’exploitation
La commande HOST permet d’exécuter une commande du système d’exploitation à partir de SQL*Plus, notamment
dans un script SQL.
Syntaxe
HOST commande
Exemple
SQL> HOST copy d:\app\oracle\oradata\orcl\system01.dbf g:\app\oracle\
oradata\orcl\system01.dbf
1 fichier(s) copié(s).
Sur plate­forme Unix ou Linux, le point d’exclamation (!) peut être utilisé à la place de la commande HOST.
e. Utiliser des variables de substitution
SQL*Plus permet d’utiliser des variables de substitution dans l’exécution des ordres SQL, notamment dans un
script.
Une variable de substitution est définie par un nom précédé du caractère &. Elle peut être utilisée pour substituer
une valeur à tout élément de l’ordre SQL : valeur dans une clause WHERE, nom de colonne, nom de table, clause
WHERE complète, etc.
Lors de l’exécution d’un ordre SQL, si SQL*Plus rencontre une variable de substitution non définie, il affiche une
invite permettant de saisir une valeur.
Il est possible de contrôler l’invite et d’affecter une valeur à une variable de substitution avant l’exécution de l’ordre
SQL grâce à la commande ACCEPT.
Syntaxe
ACC[EPT] variable [NUM[BER]|CHAR|DATE] [FOR[MAT] format] [DEF[AULT]
défaut] [PROMPT texte|NOPR[OMPT]] [HIDE]
Avec
variable
Nom de la variable de substitution (sans le caractère &).
format
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Format de saisie (mêmes conventions que celles utilisées dans l’option FORMAT de la commande COLUMN).
défaut
Valeur par défaut si aucune valeur n’est saisie.
texte
Texte de l’invite (à mettre entre apostrophes ou entre guillemets si le texte contient des espaces).
HIDE
Permet de masquer la saisie (comme pour un mot de passe).
Une variable de substitution peut aussi être définie, sans intervention de l’utilisateur, grâce à la commande DEFINE.
Syntaxe
DEFINE variable = valeur
Avec
variable
Nom de la variable de substitution (sans le caractère &).
valeur
Valeur de la variable (à mettre entre apostrophes ou entre guillemets si la valeur contient des espaces).
Par défaut, lorsque SQL*Plus effectue une substitution, il affiche un message donnant l’ordre SQL avant et après la
substitution. Il est possible d’activer ou de désactiver cette fonctionnalité grâce à la commande SET VERIFY ON |
OFF.
Exemple de script info.sql utilisant des variables de substitution
ACCEPT colonnes CHAR DEFAULT empno PROMPT "Colonne(s) : "
ACCEPT nom CHAR PROMPT "
Nom : "SELECT &colonnes FROM emp WHERE ename = UPPER(’&nom’);
Exécution du script dans SQL*Plus (saisie en gras)
SQL> @info
Colonne(s) : job
Nom : blake
old
1: SELECT &colonnes FROM emp WHERE ename = UPPER(’&nom’)
new
1: SELECT job FROM scott.emp WHERE ename = UPPER(’blake’)
JOB
--------MANAGER
SQL> SET VERIFY OFFSQL> @info
Colonne(s) : empno,job,sal
Nom : king
EMPNO JOB
SAL
--------- --------- --------7839 PRESIDENT
5000
Notez que dans le deuxième cas, la substitution effectuée par SQL*Plus n’est pas affichée (résultat de la commande
SET VERIFY OFF).
Lorsque la variable est immédiatement suivie d’une lettre, d’un chiffre, d’un point ou d’un souligné, il est nécessaire
d’utiliser un point pour bien délimiter la fin du nom de la variable.
Exemple :
- 4-
© ENI Editions - All rights reserved - Algeria Educ
SQL> DEFINE prefixe=user_
SQL> SELECT COUNT(*) FROM &prefixetables;
Enter value for prefixetables:
Sur cet exemple, SQL*Plus considère que le nom de la variable est prefixetables (et il demande sa valeur puisque
cette variable n’est pas définie).
Solution :
SQL> SELECT COUNT(*) FROM &prefixe.tables;
old 1: SELECT COUNT(*) FROM &prefixe.tables
new 1: SELECT COUNT(*) FROM user_tables
COUNT(*)
---------638
Avec le point après le nom de la variable, le problème ne se pose plus.
Le problème ne se pose pas si le caractère qui suit est un délimiteur du type /, -, $, #, etc. En cas de doute, le point
peut de toute façon être utilisé.
f. Passer des valeurs à un script
Les variables de substitution &1, &2, … peuvent être utilisées pour faire référence aux paramètres présents sur la
ligne d’appel du script.
Exemple de script info.sql utilisant des paramètres passés sur la ligne d’appel du script
SET VERIFY OFF
SELECT &1 FROM emp WHERE ename = UPPER(’&2’);
Exécution du script dans SQL*Plus
SQL> @info job blake
JOB
-------MANAGER
Exécution du script dans la ligne de commande SQL*Plus
> sqlplus scott/tiger @info.sql job blake
...
JOB
-------MANAGER
La valeur passée en paramètre à un script doit être mise entre apostrophes ou entre guillemets si elle contient des
espaces (l’espace est le séparateur des paramètres).
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 5-
Oracle SQL Developer
Oracle SQL Developer est une application graphique permettant d’exécuter des requêtes ou des scripts SQL, de gérer
les objets d’une base de données (tables, vues, etc) et de développer et mettre au point des programmes PL/SQL.
Oracle SQL Developer est gratuit et peut être téléchargé directement sur le site OTN. La page d’accueil d’Oracle SQL
Developer
se
trouve
à
l’adresse
suivante
:
http://www.oracle.com/technology/products/database/sql_
developer/index.html. Vous trouverez notamment à cette adresse la documentation et des tutoriaux. Depuis la version
11 d’Oracle, Oracle SQL Developer est installé par défaut.
Sur plate­forme Windows, Oracle SQL Developer peut être lancé par le menu Démarrer ­ Programmes ­ Oracle ­
nom_oracle_home ­ Développement d’applications ­ SQL Developer.
Sur plate­forme Unix ou Linux, Oracle SQL Developer peut être lancé à l’aide
$ORACLE_HOME/sqldeveloper/sqldeveloper.sh. L’application nécessite un environnement graphique.
du
shell
script
Sur plate­forme Windows, lors du premier lancement, il est possible que l’outil demande le chemin de l’application
java.exe. Vous pouvez utiliser celle fournie par Oracle : %ORACLE_HOME%\jdk\bin\java.exe.
La fenêtre principale d’Oracle SQL Developer a l’allure suivante :
Dans la partie gauche de la fenêtre, une structure arborescente permet de naviguer dans les objets d’une ou de
plusieurs bases de données. Un clic sur le bouton
permet de définir une nouvelle connexion.
Dans la partie droite de la fenêtre, la zone de travail permet d’éditer et d’exécuter des requêtes SQL et de visualiser le
résultat.
Dans l’ensemble, cet outil est très convivial et son apprentissage est aisé. Comme son nom l’indique, l’outil est plutôt
destiné aux développeurs et il ne propose donc aucune fonctionnalité d’administration. Pour plus d’informations sur
l’utilisation de cet outil, vous pouvez consulter la documentation "Oracle® Database SQL Developer User’s Guide".
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Oracle Enterprise Manager Database Control
1. Introduction
Oracle Enterprise Manager Database Control est un outil d’administration graphique accessible par un navigateur : il
est apparu en version 10g d’Oracle.
Lors de la création d’une base de données, Oracle vous propose d’administrer cette base de façon centralisée avec
Oracle Enterprise Manager Grid Control ou de façon locale avec Oracle Enterprise Manager Database Control.
Pour administrer la base avec le Grid Control (non traité dans cet ouvrage), il faut installer au préalable l’agent Oracle
Management Agent sur le système. Si ce n’est pas le cas, l’option n’est pas sélectionnable et l’administration avec le
Database Control est proposée par défaut.
Dans la suite de cet ouvrage, nous utiliserons principalement les expressions "Database Control" ou "console Oracle
Enterprise Manager" pour désigner l’outil Oracle Entreprise Manager Database Control.
Database Control propose toutes les fonctionnalités nécessaires à l’administration et à l’optimisation d’une base de
données Oracle.
2. Architecture
Derrière une apparente simplicité, le Database Control repose sur une architecture relativement complexe. Le
Database Control est une application J2EE qui utilise une version autonome du serveur d’application OC4J (Oracle
Containers for J2EE).
Le Database Control utilise différents composants pour surveiller et administrer la base de données Oracle et son
environnement (serveur hôte, processus d’écoute) :
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
●
●
●
une version locale du service Oracle Management Service (OMS) destiné à fonctionner avec la base de
données administrée ;
un référentiel (Oracle Management Repository) installé dans la base de données administrée (schémaSYSMAN),
destiné à stocker des informations utilisées par le Database Control ;
une version locale de l’agent (Oracle Management Agent) dont le rôle est de fournir des informations au service
OMS local.
Côté client, un simple navigateur suffit pour utiliser la console ; le navigateur communique avec le service OMS, sur le
port 1158. Côté serveur, le service OMS et l’agent communiquent sur le port 3938.
Le compte DBSNMP est utilisé par l’agent pour superviser et gérer la base de données. Le compte SYSMAN est utilisé
pour stocker le référentiel du Database Control ; il peut aussi être utilisé pour administrer la base de données.
Le Database Control est associé à une base de données. Si plusieurs bases de données sont présentes sur le
serveur, chaque base de données possède sa propre infrastructure (service OMS, agent, référentiel). Dans un tel cas
de figure, les ports utilisés sont différents : 5500 et 1830 pour la seconde base de données, par exemple.
Le fichier portlist.ini stocké dans le répertoire install donne la liste des ports utilisés par les différentes
bases de données présentes sur le serveur.
Les fichiers utilisés par le Database Control d’une base de données sont stockés dans deux répertoires :
●
●
%ORACLE_HOME%\serveur_sid (plate­forme Windows) ou $ORACLE_HOME/serveur_sid (plate­forme Linux)
%ORACLE_HOME%\oc4j\j2ee\OC4J_DBConsole_serveur_sid
(plate­forme
$ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_serveur_sid (plate­forme Linux)
Windows)
ou
La configuration du Database Control est un sujet relativement complexe qui est décrit dans la documentation
Oracle® Enterprise Manager Advanced Configuration. Vous trouverez notamment dans ce manuel comment effectuer
les tâches suivantes :
●
configurer le Database Control lors de la création d’une base de données ;
●
changer les mots de passe de SYSMAN et DBSNMP ;
●
modifier les ports utilisés ;
●
sécuriser le Database Control (c’est le cas par défaut en version 11).
Sur MetaLink, vous trouverez aussi de nombreuses notes relatives au Database Control.
Dans cet ouvrage, nous verrons simplement comment Configurer le Database Control lors de la création d’une base
de données (cf. Chapitre Création d’une nouvelle base de données).
3. Gérer le Database Control
Le Database Control peut être arrêté ou démarré grâce à l’utilitaire ligne de commande emctl.
Syntaxe :
emctl { start | stop | status } dbconsole
Les commandes start et stop permettent respectivement de démarrer et d’arrêter la console ; la commande status
permet de voir le statut.
L’utilitaire agit sur le Database Control de la base de données ouverte par l’instance définie par la variable
d’environnement ORACLE_SID ; si cette variable d’environnement n’est pas positionnée, l’utilitaire affiche un message
d’erreur.
La commande emctl status agent peut aussi être utilisée pour afficher des informations détaillées sur l’agent.
- 2-
© ENI Editions - All rights reserved - Algeria Educ
Le démarrage du Database Control est assez long (environ 1 minute).
Si vous utilisez le Database Control pour administrer la base de données, il est souhaitable que ce dernier soit
démarré automatiquement lors du démarrage du système.
Sur plate­forme Windows, le Database Control peut être démarré automatiquement lors du démarrage du système
en positionnant le service associé (OracleDBConsole<SID>) en démarrage automatique.
Sur plate­forme Unix ou Linux, le serveur d’application peut être démarré automatiquement grâce au script de
démarrage présenté dans la section Installation du serveur du chapitre Installation.
Le script actuel doit être modifié pour prendre en charge le démarrage et l’arrêt de plusieurs Database Control
(éventuellement dans des Oracle Home différents) à l’aide de la commande emctl.
Vous pouvez vous inspirer des scripts dbstart et dbshut pour écrire un tel script.
Exemple
for ligne in $(cat /etc/oratab | egrep ’^[a-zA-Z]+:.*:Y$’)
do
SID=$(echo $ligne | cut -d: -f1)
EM_HOME=$(echo $ligne | cut -d: -f2)
export ORACLE_SID=$SID
$EM_HOME/bin/emctl start dbconsole > $LOG 2>&1 &
done
Cet exemple de code permet de démarrer le Database Control pour toutes les instances définies en démarrage
automatique dans le fichier /etc/oratab.
4. Débuter avec le Database Control
a. Vue d’ensemble
Dans cette partie, nous allons donner une vue d’ensemble de l’utilisation du Database Control. Dans les différents
chapitres de l’ouvrage, nous verrons ensuite comment utiliser le Database Control pour effectuer les différentes
tâches d’administration. Pourdémarrer une session Database Control, il suffit d’ouvrir une fenêtre de votre
navigateur et de saisir une URL de la forme : https://serveur:port/em
serveur est le nom ou l’adresse IP du serveur de base de données. port est le numéro du port sur lequel le service
OMS communique (1158 par exemple).
Exemple :
https://srvwinora:1158/em
Si la base est démarrée, la page de connexion s’affiche. Si la base n’est pas démarrée, la page de démarrage
s’affiche (cf. Chapitre Démarrage et arrêt).
La page de connexion permet de saisir un nom, un mot de passe et éventuellement de demander une connexion
SYSDBAou SYSOPER(zone Se connecter en tant que) :
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Initialement, seuls les comptes Oracle SYS, SYSTEM et SYSMANpeuvent utiliser le Database Control.
Une fois connecté, vous arrivez sur la page d’accueil du Database Control :
Cette page d’accueil vous donne une vision globale du fonctionnement général de la base de données. Cette page
affiche notamment des informations synthétiques sur les performances du système, l’utilisation de l’espace et les
alertes signalées par le système ; différents liens permettent ensuite d’afficher des informations détaillées sur ces
différents aspects.
Les liens Performances, Disponibilité, Serveur, Schéma, Mouvement de données et Logiciel et fichiers associés
affichent des pages de navigation qui permettent d’accéder aux différents outils d’administration.
En haut de chaque page, le Database Control propose 4 liens :
Le lien Installation affiche une page qui permet de configurer le Database Control ; cette page permet notamment
de définir d’autres utilisateurs habilités à utiliser la console.
Le lien Préférences affiche une page qui permet de modifier les préférences de l’utilisateur courant, et notamment
de définir une adresse de courrier électronique permettant de recevoir une notification en cas de problème (voir la
section Utiliser les alertes dans ce chapitre).
b. Informations d’identification et de connexion
Pour certaines tâches d’administration (planification de travaux, sauvegarde/restauration), le Database Control
vous demandera de saisir des informations d’identification et de con­ nexion à la base de données et/ou au
système hôte.
Pour éviter de devoir saisir ces informations à chaque fois, vous pouvez les enregistrer dans vos préférences.
Sur la page Préférences, cliquez sur le lien Informations d’identification et de connexion stockées dans les
préférences.
- 4-
© ENI Editions - All rights reserved - Algeria Educ
Cliquez sur une des icônes de la dernière colonne pour saisir les informations d’identification de la cible souhaitée
(instance de base de données, hôte).
Pour la base de données, vous pouvez enregistrer deux identifications Oracle pour la base de données (une
identification "normale", par exemple SYSTEM, et une identification SYSDBA, par exemple SYS) ainsi qu’une
identification pour l’hôte.
En ce qui concerne l’identification pour l’hôte, vous devez indiquer un utilisateur du système qui a le droit d’exécuter
des applications dans le répertoire Oracle Home ; c’est le cas des comptes qui sont membres du groupe OSDBA, et
donc notamment du compte utilisé pour l’installation.
Sur plate­forme Windows, le compte utilisé doit par ailleurs être membre du groupe Administrateurs et avoir le
privilège Ouvrir une session en tant que tâche. Si ce n’est pas le cas, vous aurez le message d’erreur suivant
lorsque vous cliquerez sur le bouton Test :
Pour attribuer ce privilège, procédez de la manière suivante :
■
Sélectionnez le menu Démarrer ­ Programmes ­ Outils d’administration ­ Stratégie de sécurité locale.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 5-
■
■
Dans l’arborescence de gauche, cliquez sur le dossier Stratégies locale ­ Attribution des droits utilisateur.
Dans la liste des stratégies, double cliquez sur la stratégie Ouvrir une session en tant que tâche et ajoutez
l’utilisateur souhaité dans la liste.
5. Utiliser les alertes
a. Visualiser les alertes
Par défaut, le Database Control est configuré pour signaler différents problèmes sur le fonctionnement de la base
de données : c’est la notion d’alerte. Les alertes sont visibles sur la page d’accueil du Database Control :
La liste Alertes donne les alertes de l’instance et de la base de données. La liste Alertes associées donne les
alertes d’autres composants Oracle (Oracle Net par exemple) ou de l’hôte. Lorsqu’une alerte est signalée, vous
pouvez cliquer sur le lien associé pour avoir plus d’informations ; selon la nature de l’alerte, la page affichée peut
proposer des liens pour faire des actions correctrices ou une analyse supplémentaire.
b. Définir les seuils des alertes
Sur la page d’accueil, vous pouvez cliquer sur le lien Paramètres de mesure et de règle (cadre Liens associés en
bas), pour accéder à la page de gestion des seuils de déclenchement des alertes :
Cette page affiche les seuils actuels de déclenchement des alertes pour les différentes mesures. Pour les mesures
- 6-
© ENI Editions - All rights reserved - Algeria Educ
souhaitées, vous pouvez définir un seuil d’avertissement et un seuil critique.
c. Recevoir une notification lorsqu’une alerte survient
Il est possible de recevoir directement une notification lorsqu’une alerte survient, typiquement par messagerie
électronique.
Pour recevoir une notification par messagerie électronique, vous devez faire deux choses :
●
configurer les méthodes de notification du Database Control ;
●
vous "abonner" à des notifications.
Configurer les méthodes de notification
Sur la page d’accueil, ou toute autre page, cliquez sur le lien Installation en haut à droite, puis sur le lien Méthodes
de notification pour accéder à la page de définition des méthodes de notification :
La première méthode de notification que vous pouvez définir est la notification par messagerie électronique. Pour la
configurer, il suffit d’indiquer l’adresse du serveur de messagerie sortant (et si besoin une authentification pour ce
serveur) et d’identifier l’expéditeur (le Database Control) par un nom et une adresse électronique. Si vous le
souhaitez, vous pouvez définir d’autres méthodes de notifications : SNMP (Simple Network Management Protocol),
commande du système d’exploitation, procédure PL/SQL.
La configuration de la méthode de notification par messagerie électronique peut être réalisée lors de la
création d’une base de données à l’aide de l’assistant graphique, ou lors de la configuration du Database
Control avec l’utilitaire emca.
S’abonner à une notification
Si vous souhaitez recevoir des notifications par messagerie électronique, vous devez d’abord associer une adresse
électronique au compte Oracle que vous utilisez pour l’administration.
Sur la page d’accueil, ou toute autre page, cliquez sur le lien Préférences en haut à droite, pour accéder à la page
de gestion de vos préférences :
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 7-
Dans le cadre Adresse email, vous pouvez indiquer une ou plusieurs adresses électroniques.
Ensuite, vous pouvez cliquer sur le lien Règles pour vous abonner à une notification :
Une règle de notification est un ensemble de conditions qui déclenche une notification : cible (base de données,
processus d’écoute, hôte, etc.), disponibilité de la cible, survenance d’une ou plusieurs alertes (avec seuil de
gravité). Plusieurs règles de notification sont définies par défaut lors de l’installation du Database Control. Par
exemple, la règle "Database Availability and Critical States" déclenche une notification lorsque la base de données
est arrêtée, et un seuil critique est atteint sur plusieurs mesures (pourcentage de remplissage de la zone
d’archivage, pourcentage de remplissage d’un tablespace, etc.).
Sur la page ci­dessus, vous pouvez consulter ou modifier une règle prédéfinie ou créer de nouvelles règles. En
cochant la case de la dernière colonne (Abonnement), vous pouvez vous "abonner" à la règle, c’est­à­dire
demander à être destinataire de la notification.
C’est le compte Oracle SYSMANqui est propriétaire des règles de notification prédéfinies, mais celles­ci sont
publiques et peuvent donc être modifiées par les autres utilisateurs habilités du Database Control. Lors de
- 8-
© ENI Editions - All rights reserved - Algeria Educ
la création d’une base de données à l’aide de l’assistant graphique, ou lors de la configuration du Database
Control avec l’utilitaire emca, si vous configurez la notification par messagerie électronique, l’adresse de
messagerie indiquée sera associée au compte SYSMAN, et les notifications seront automatiquement envoyées à
cette adresse.
6. Les tâches de maintenance automatisées
Trois tâches de maintenance automatisées sont programmées par défaut :
●
Collecte des statistiques pour l’optimiseur (voir Chapitre Gestion des tables et des index) ;
●
Conseil sur le stockage des segments (voir Chapitre Gestion des tables et des index) ;
●
Conseil sur l’optimisation des requêtes SQL.
Les tâches de maintenance automatisées peuvent être supervisées dans le Database Control. Sur la page d’accueil,
cliquez sur le lien Serveur, puis sur le lien Tâches de maintenance automatisées (cadre Oracle Scheduler) pour
afficher la liste des tâches de maintenance automatisées :
Par défaut, les tâches de maintenance automatique s’exécutent du lundi au vendredi entre 22h00 et 2h00 et le
samedi et le dimanche entre 6h00 et 2h00.
Si vous cliquez sur le lien correspondant au nom de la tâche, vous pouvez visualiser le résultat de la dernière
exécution (sauf pour la collecte des statistiques).
Si vous cliquez sur le bouton Configurer, la page de configuration des tâches de maintenance s’affiche :
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 9-
À partir de cette page, vous pouvez activer ou désactiver les tâches, modifier leur planification ou les configurer
(bouton Configurer).
Dans ces deux pages, il y a une inversion entre les termes "Désactivé" et "Activé" : "Désactivé" veut dire
"Activé" et réciproquement.
- 10 -
© ENI Editions - All rights reserved - Algeria Educ
Objectifs de l’ouvrage
Cet ouvrage a pour objectif de vous présenter toutes les bases de l’administration d’une base de données Oracle11g :
●
compréhension minimale de l’architecture ;
●
procédures d’installation en environnement Windows et Unix/Linux ;
●
configuration d’Oracle Net ;
●
arrêt et démarrage ;
●
création d’une nouvelle base de données ;
●
gestion de la mémoire ;
●
gestion du stockage (fichiers de données, tablespaces, tables, index, etc.) ;
●
gestion de la sécurité (utilisateurs et droits) ;
●
sauvegardes et restaurations avec RMAN (Recovery Manager) ;
Ce livre contient de nombreux conseils pratiques et de nombreuses recommandations, et présente les solutions qui
peuvent être apportées aux problèmes courants. Le tout est abondamment illustré par une quantité d’exemples sur
l’utilisation des commandes et autres ordres SQL, mais aussi par de nombreuses copies d’écrans d’Oracle Enterprise
Manager Database Control. Les différents exemples de cet ouvrage peuvent être téléchargés sur le site des Editions ENI.
Cet ouvrage s’adresse à la fois aux débutants qui souhaitent devenir administrateur Oracle, mais aussi aux nombreux
administrateurs formés sur le tas, et qui souhaitent mettre à jour leurs connaissances, les consolider et découvrir les
nombreuses nouvelles fonctionnalités d’Oracle 11g.
Pour pouvoir profiter pleinement de ce livre, il est conseillé d’avoir des connaissances préalables sur les bases de
données relationnelles (savoir ce qu’est une table, une vue, un index) et sur le SQL (ordres SELECT, INSERT, UPDATE et
DELETE).
Dans cet ouvrage, nous emploierons souvent le terme couramment utilisé de DBA pour désigner l’administrateur
de la base de données. En anglais, DBA signifie DataBase Administrator.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
La documentation Oracle
1. Où la trouver ?
Le média d’installation contient essentiellement la documentation relative à l’installation, notamment :
●
Oracle® Database Release Notes ;
●
Oracle® Database Quick Installation Guide ;
●
Oracle® Database Installation Guide.
La
documentation
Oracle
est
accessible
http://www.oracle.com/technology/documentation/index.html
en
ligne
à
l’adresse
suivante :
2. Organisation
La documentation comporte plusieurs "livres" (format HTML ou PDF) regroupés par thème.
La zone Search permet d’effectuer des recherches, notamment sur un numéro d’erreur Oracle.
Le lien Master Book List affiche la liste de tous les livres.
Les principaux livres sont identifiés par des codes proposés sous forme de lien dans le tableau de synthèse de la liste
des livres. Les livres les plus utiles pour l’administration sont les suivants :
Oracle® Database Concepts (CON)
Concepts sur l’architecture et les fonctionnalités d’Oracle.
Oracle® Database Administrator’s Guide (ADM)
Manuel de l’administration.
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Oracle® Database Security Guide (SEC)
Gestion des utilisateurs et des droits.
Oracle® Database Reference (REF)
Manuel de référence de tous les paramètres du fichier de paramètres et de toutes les vues du dictionnaire de
données.
Oracle® Database SQL Language Reference (SQL)
Manuel de référence du SQL.
Oracle® Database Error Messages (ERR)
Manuel des erreurs.
Oracle® Database Utilities (UTI)
Manuel d’utilisation des outils Data Pump, Import, Export et SQL*Loader.
Oracle® Database Backup and Recovery User’s Guide (BAC)
Manuel des sauvegardes et restaurations.
Oracle® Database Backup and Recovery Reference (BAC)
Manuel de référence de l’outil RMAN.
Oracle® Database Upgrade Guide (UPG)
Manuel pour la migration d’une base Oracle d’une ancienne version.
La documentation comporte beaucoup d’autres livres relatifs au développement (PL/SQL, Java...), à la couche Oracle
Net, à l’optimisation, etc.
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Diagnostiquer les problèmes
1. Vue d’ensemble
Depuis la version 11, Oracle inclut une nouvelle infrastructure pour le diagnostic des problèmes.
Le composant principal de cette infrastructure est le Référentiel de Diagnostic Automatique (Automatic Diagnostic
Repository ­ ADR). ADR est un répertoire qui stocke de façon structurée et centralisée toutes les données de
diagnostic, par exemple des fichiers de trace ou d’alerte.
Cette infrastructure introduit deux concepts : les problèmes et les incidents.
Un problème est une erreur critique de la base de données, comme les erreurs internes (ORA-00600), les erreurs du
système d’exploitation (ORA-07445) ou le manque de mémoire dans la Shared Pool (ORA-04031). Chaque problème est
identifié par une clé qui inclut le code de l’erreur (par exemple ORA-600) et éventuellement, des paramètres
supplémentaires.
Un incident est une occurrence d’un problème. Chaque incident est identifié par un numéro d’incident. Lorsqu’un
incident se produit, la base de données effectue les actions suivantes :
●
une entrée est écrite dans le fichier d’alerte de l’instance (voir ci­après) ;
●
une alerte est envoyée à Oracle Enterprise Manager ;
●
des informations de diagnostic sont capturées et enregistrées dans des fichiers d’incident qui sont marqués
avec le numéro de l’incident et stockés dans un sous­répertoire du Référentiel de Diagnostic Automatique.
Un autre composant de la nouvelle infrastructure est le Health Monitor qui regroupe plusieurs outils de vérification de la
bonne santé de la base de données. Ces outils de vérification sont exécutés automatiquement par Oracle lorsqu’une
erreur critique se produit ; ils peuvent aussi être exécutés à la demande. Les résultats sont stockés dans le
Référentiel de Diagnostic Automatique.
Pour exploiter le Référentiel de Diagnostic Automatique, Oracle propose deux outils :
●
Le Support Workbench de la console Enterprise Manager
●
L’outil ligne de commande adrci
2. Le Référentiel de Diagnostic Automatique
Depuis la version 11, tous les fichiers de trace et tous les fichiers journaux des différents composants qui s’exécutent
sur le serveur (bases de données, processus d’écoute, etc.), sont stockés de façon structurée et centralisée dans un
répertoire de diagnostic : c’est le Référentiel de Diagnostic Automatique (Automatic Diagnostic Repository ­ ADR).
Le répertoire de base d’ADR est défini par le paramètre DIAGNOSTIC_DEST qui est, par défaut, égal au répertoire Oracle
Base si la variable d’environnement ORACLE_BASE est définie ; sinon, il est égal, par défaut, au sous­répertoire log du
répertoire Oracle Home. Sous ce répertoire de base, un répertoire diag est créé avec une arborescence du type
suivant :
diag
+---asm
+---clients
+---crs
+---diagtool
+---lsnrctl
+---netcman
+---ofm
+---rdbms
¦
+---<nom unique base de données>
¦
¦
+---<nom instance>
¦
¦
+---alert
¦
¦
+---incident
¦
¦
+---trace
¦
¦
+---...
© ENI Editions - All rights reserved - Algeria Educ
- 1-
¦
+---...
+---tnslsnr
Le répertoire diag contient un sous­répertoire par composant Oracle, avec notamment un répertoire rdbms pour les
bases de données et un répertoire tnslsnr pour le processus d’écoute. Pour les bases de données, le répertoire
rdbms contient un sous­répertoire par base de données qui, lui­même, contient un sous­répertoire par instance qui
accède à la base de données (en général une seule instance, sauf dans le cas d’une configuration Real Application
Clusters). Les principaux répertoires sont les suivants :
alert
Fichier d’alerte de l’instance au format XML.
incident
Fichiers relatifs aux incidents.
trace
Fichiers de trace des processus et version texte du fichier d’alerte de l’instance.
La vue V$DIAG_INFO donne des informations sur le répertoire de diagnostic :
SQL> SELECT name,value FROM v$diag_info;
NAME
VALUE
--------------------- ----------------------------------------------------Diag Enabled
TRUE
ADR Base
d:\app\oracle
ADR Home
d:\app\oracle\diag\rdbms\orcl\orcl
Diag Trace
d:\app\oracle\diag\rdbms\orcl\orcl\trace
Diag Alert
d:\app\oracle\diag\rdbms\orcl\orcl\alert
Diag Incident
d:\app\oracle\diag\rdbms\orcl\orcl\incident
Diag Cdump
d:\app\oracle\diag\rdbms\orcl\orcl\cdump
Health Monitor
d:\app\oracle\diag\rdbms\orcl\orcl\hm
Default Trace File
d:\app\oracle\diag\rdbms\orcl\orcl\trace\
orcl_ora_4088.trc
Active Problem Count 1
Active Incident Count 1
Avant la version 11, l’emplacement des fichiers d’alerte et de trace était défini par les paramètres
BACKGROUND_DUMP_DEST (fichiers d’alerte et fichiers de trace des processus d’arrière plan) et USER_DUMP_DEST (fichiers de
trace des processus serveur). Les emplacements recommandés par le standard OFA étaient respectivement les sous­
répertoires bdump et udump du répertoire d’administration.
Depuis la version 11, les paramètres BACKGROUND_DUMP_DEST et USER_DUMP_DEST sont dépréciés et ignorés. S’ils ne sont
pas définis dans le fichier de paramètres de l’instance, ils sont automatiquement renseignés par Oracle.
3. Les fichiers d’alerte et de trace
Oracle maintient un fichier d’alerte dans lequel il écrit des messages d’information ou d’erreur sur la vie de la base de
données :
- 2-
●
Création de la base de données ;
●
Démarrages et arrêts ;
●
Modifications de la structure (tablespaces, fichiers de données) ;
●
Erreurs critiques (incidents) ;
●
Erreurs de bloc corrompu (ORA-01578) ;
●
Problèmes relatifs à l’écriture ou à l’archivage des fichiers de journalisation.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
En complément, lorsqu’un processus rencontre un problème, il écrit des informations dans un fichier trace.
Le fichier d’alerte est disponible sous deux formes : une version texte et une version XML (nouveau en version 11).
Le fichier d’alerte au format XML se nomme log.xml et se trouve dans le sous­répertoire alert du répertoire de
diagnostic de la base de données. Il est automatiquement renommé en log_n.xml lorsqu’il atteint une certaine taille.
Le nom du fichier d’alerte au format texte est de la forme alert_<SID>.log ; il se trouve dans le sous­répertoire trace
du répertoire de diagnostic de la base de données.
Le fichier d’alerte au format texte, grossit sans limite. Il est conseillé de le purger régulièrement pour éviter qu’il ne
soit trop volumineux ; le mieux est de l’archiver à intervalles réguliers pour garder l’historique de la vie de la base.
Vous pouvez supprimer ou renommer le fichier d’alerte au format texte sans crainte ; Oracle le recréera lorsqu’il en
aura besoin.
Le nom des fichiers de trace des processus d’arrière­plan est de la forme <sid>_<nom_processus>_<id_processus>.trc.
Le nom des fichiers de trace des processus serveur est de la forme <sid>_ora_<id_processus>.trc. La taille des
fichiers de trace est limitée par le paramètreMAX_DUMP_FILE_SIZE.
Il faut périodiquement consulter ces fichiers d’alerte et de trace. Si le contenu d’un fichier d’alerte ou de trace
n’est pas clair, il ne faut pas hésiter à contacter le support Oracle.
4. Utiliser le Database Control
a. Support Workbench
La console Enterprise Manager propose une fonctionnalité intitulée Support Workbench qui permet d’exploiter très
facilement le Référentiel de Diagnostic Automatique.
Dans la console, le terme "Support Workbench" est maladroitement traduit par "Prise en charge de
workbench". Dans la suite de ce chapitre, je préfère donc utiliser le nom anglais.
■
Pour accéder à la page d’accueil du Support Workbench à partir de la page d’accueil de la console, cliquez sur le lien
Logiciel et fichiers associés puis sur le lien Prise en charge de workbench.
La page d’accueil du Support Workbench affiche les problèmes survenus au cours des 24 dernières heures.
En cliquant sur le lien Afficher, les incidents relatifs au problème sont affichés :
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Pour afficher le détail d’un incident, il suffit ensuite de cliquer sur le lien associé :
Le Support Workbench permet, très facilement, de regrouper les données de diagnostic dans un "package" en vue de
les envoyer au support Oracle.
■
Sur la page d’accueil du Support Workbench, cochez le problème concerné puis cliquez sur le bouton Package :
La page suivante s’affiche :
- 4-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
■
Sur cette page, laissez l’option Packaging rapide sélectionnée puis cliquez sur le bouton Continuer.
La première page de l’assistant s’affiche :
■
■
Sur cette page, vous devez saisir vos identifiants de connexion à Metalink. Si vous avez déjà créé une demande
de service, sélectionnez l’option Non pour le bouton radio Créer une demande de service (SR). Optionnellement,
vous pouvez saisir un nom et une description pour le package.
Cliquez trois fois sur le bouton Suivant, pour terminer la création du package et son envoi au support Oracle.
En cas de problème lors de l’envoi du package au support Oracle, une page d’erreur s’affiche :
Comme l’indique le message d’erreur, le package est néanmoins créé et peut être envoyé ultérieurement au support,
soit à partir de la console, soit manuellement. Comme le montre l’exemple ci­dessus, l’envoi du package au support
Oracle échoue lorsqu’Oracle Configuration Manager n’a pas été correctement installé et configuré lors de l’installation
d’Oracle. Pour plus d’informations sur l’installation et la configuration de ce composant, consultez la documentation
"Oracle® Configuration Manager Installation and Administration Guide" (à ce jour, cette documentation existe
uniquement en version 10.2).
Une fois que le package est créé, et même s’il n’a pas pu être envoyé, des informations supplémentaires sont
affichées dans la page d’accueil du Support Workbench :
© ENI Editions - All rights reserved - Algeria Educ
- 5-
Pour le problème concerné, la colonne Packagée contient Oui, et l’onglet Packages permet de retrouver les
packages qui ont été générés, et éventuellement de les envoyer de nouveau si l’envoi initial a échoué.
b. Consulter le contenu du fichier d’alerte de l’instance
Dans la section Liens associés située dans le bas des pages de la console, le lien Contenu du journal d’alertes
affiche une page de consultation du contenu du fichier d’alerte de l’instance.
Le lien Rechercher affiche un formulaire de recherche qui permet d’effectuer une recherche dans le fichier d’alerte de
l’instance (par date, texte du message, etc.).
c. Vérificateurs
Pour accéder aux outils de vérification de la bonne santé de la base de données, vous pouvez cliquer sur le lien
Centre de conseil (section Liens associés située dans le bas de la page d’accueil de chaque onglet) puis sur le lien
(onglet) Vérificateurs.
- 6-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Les liens de la section Vérificateurs permettent de lancer les différents outils de vérification.
La section Traitements du vérificateur affiche le résultat de l’exécution des outils, notamment des exécutions
automatiques effectuées par Oracle lorsqu’une erreur critique se produit.
Pour consulter le résultat, vous pouvez cliquer sur le bouton Détails ou sur le lien du nom du traitement.
La cause de l’erreur, si elle n’a pas encore été traitée, est affichée dans cette page.
La même information peut être consultée dans l’onglet Résultats de recherche du vérificateur du Support
Workbench.
© ENI Editions - All rights reserved - Algeria Educ
- 7-
Dans les deux cas, vous pouvez cliquer sur le bouton Lancer Recovery Advisor pour réparer le problème à l’aide du
Data Recovery Advisor (cf. section Utiliser le Database Control du chapitre Sauvegarde et récupération).
5. L’outil ligne de commande adrci
L’outil ligne de commande adrci permet de consulter le contenu du Référentiel de Diagnostic Automatique.
Pour lancer l’outil en interactif, il faut s’assurer que l’environnement Oracle est correctement positionné (ORACLE_HOME
et PATH) puis saisir la commande adrci à l’invite du système d’exploitation.
Exemple
C:\>adrci
ADRCI: Release 11.1.0.6.0 - Beta on Lun. Juin 30 16:40:29 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
ADR base = "d:\app\oracle"adrci>
L’outil propose un très grand nombre de commandes qui pour certaines d’entre elles, comportent un grand nombre
d’options. Dans ce chapitre, nous présenterons brièvement les commandes et options les plus utiles pour effectuer
des tâches courantes. Toutes les commandes et options sont décrites dans la documentation "Oracle® Database
Utilities".
Les commandes les plus utiles sont les suivantes :
HELP
Liste toutes les commandes.
HELP commande
Affiche l’aide d’une commande.
EXIT ou QUIT
Quitte l’outil.
SHOW HOMES
- 8-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Affiche le chemin de la racine du répertoire de diagnostic de chaque composant présent sur le serveur.
SET HOMEPATH chemin
Définit le répertoire de diagnostic courant.
SET EDITOR programme
Définit l’éditeur externe à utiliser pour afficher le contenu des fichiers d’alerte ou de trace.
SHOW ALERT [options]
Affiche le contenu d’un fichier d’alerte. Sans option, la totalité du contenu du fichier d’alerte est affiché avec l’éditeur
externe.
SHOW INCIDENT [options]
Affiche des informations sur les incidents répertoriés dans ADR.
SHOW PROBLEM [options]
Affiche des informations sur les problèmes répertoriés dans ADR.
Les commandes ne sont pas sensibles à la casse.
La commande SET EDITOR doit absolument être utilisée sur une plate­forme Windows car l’éditeur par défaut
est vi qui n’existe pas (en standard) sur cette plate­forme.
Exemples
●
Définir le répertoire de diagnostic courant (celui de l’instance ORCL) :
adrci> SHOW HOMES
ADR Homes:
...
diag\rdbms\orcl\orcl
diag\rdbms\test\test
diag\tnslsnr\srvwinora\listener
adrci> SET HOMEPATH diag\rdbms\orcl\orcl
●
Afficher les 10 dernières entrées du fichier d’alerte de l’instance :
adrci> SHOW ALERT -TAIL 10
2008-06-27 10:07:57.375000 +02:00
SMCO started with pid=20, OS id=2856
...
2008-06-30 12:26:09.593000 +02:00
Thread 1 advanced to log sequence 43
Current log# 1 seq# 43 mem# 0: D:\APP\ORACLE\ORADATA\ORCL\REDO01.LOG
●
Afficher, dans la fenêtre courante, les entrées du fichier d’alerte de l’instance correspondant à un critère
particulier (ici, la présence d’une certaine erreur) :
adrci> SHOW ALERT -TERM -P "message_text like ’ORA-1652%’"
ADR Home = d:\app\oracle\diag\rdbms\orcl\orcl:
********************************************************************
2008-06-24 15:33:29.312000 +02:00
ORA-1652: unable to extend temp segment by 128 in tablespace USERS
2008-06-24 15:35:07.031000 +02:00
ORA-1652: unable to extend temp segment by 128 in tablespace USERS
© ENI Editions - All rights reserved - Algeria Educ
- 9-
●
La même chose en utilisant un éditeur externe (ici sur une plate­forme Windows, ce qui nécessite de définir
l’éditeur à utiliser au préalable) :
adrci> SET EDITOR notepad.exe
adrci> SHOW ALERT -P "message_text like ’ORA-1652%’"
ADR Home = d:\app\oracle\diag\rdbms\orcl\orcl:
***************************************************************
Output the results to file: c:\temp\alert_2348_3036_orcl_2.ado
●
Afficher la "structure" du fichier d’alerte (liste les "colonnes" qui peuvent être utilisées dans les recherches) :
adrci> DESCRIBE alert_ext
Name
Type
NULL?
----------------------------- --------------- ----------ORIGINATING_TIMESTAMP
timestamp
NORMALIZED_TIMESTAMP
timestamp
ORGANIZATION_ID
text(65)
COMPONENT_ID
text(65)
HOST_ID
text(65)
HOST_ADDRESS
text(17)
MESSAGE_TYPE
number
MESSAGE_LEVEL
number
MESSAGE_ID
text(65)
MESSAGE_GROUP
text(65)
CLIENT_ID
text(65)
MODULE_ID
text(65)
PROCESS_ID
text(33)
THREAD_ID
text(65)
USER_ID
text(65)
INSTANCE_ID
text(65)
DETAILED_LOCATION
text(161)
UPSTREAM_COMP_ID
text(101)
DOWNSTREAM_COMP_ID
text(101)
EXECUTION_CONTEXT_ID
text(101)
EXECUTION_CONTEXT_SEQUENCE
number
ERROR_INSTANCE_ID
number
ERROR_INSTANCE_SEQUENCE
number
MESSAGE_TsEXT
text(2049)
MESSAGE_ARGUMENTS
text(129)
SUPPLEMENTAL_ATTRIBUTES
text(129)
SUPPLEMENTAL_DETAILS
text(129)
PARTITION
number
RECORD_ID
number
FILENAME
text(513)
PROBLEM_KEY
text(65)
VERSION
number
●
Afficher les incidents répertoriés dans ADR :
adrci> SHOW INCIDENT
********************************************************************
INCIDENT_ID
PROBLEM_KEY
CREATE_TIME
-------------------- ----------------------------------------------6529
ORA 600 [kssadd: null parent]
2008-06-24 16:03:16.593000 +02:00
1 rows fetched
●
Afficher le détail d’un incident :
adrci> SHOW INCIDENT -MODE DETAIL -P "incident_id = 6529"
ADR Home = d:\app\oracle\diag\rdbms\orcl\orcl:
***********************************************************
- 10 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
**********************************************************
INCIDENT INFO RECORD 1
**********************************************************
INCIDENT_ID
6529
STATUS
ready
CREATE_TIME
2008-06-24 16:03:16.593000 +02:00
PROBLEM_ID
1
...
PROBLEM_KEY
ORA 600 [kssadd: null parent]
FIRST_INCIDENT
6529
FIRSTINC_TIME
2008-06-24 16:03:16.593000 +02:00
...
INCIDENT_FILE
d:\app\oracle\diag\rdbms\orcl\orcl\trace\
orcl_ora_2108.trc
OWNER_ID
1
INCIDENT_FILE
d:\app\oracle\diag\rdbms\orcl\orcl\incident\
incdir_6529\orcl_ora_2108_i6529.trc
1 rows fetched
L’outil adcri peut être utilisé en mode batch, soit en passant les commandes sur la ligne de commande
(option exec), soit en exécutant un script de commandes (option script). Voir la documentation "Oracle®
Database Utilities" pour plus d’informations.
© ENI Editions - All rights reserved - Algeria Educ
- 11 -
Principes
Pour rendre une base accessible à tous les utilisateurs, il faut démarrer une instance et ouvrir la base de données avec
cette instance.
Il y a trois grandes phases dans le processus de démarrage :
●
démarrage de l’instance ;
●
montage de la base de données ;
●
ouverture de la base de données.
De même, il y a trois grandes phases dans le processus d’arrêt :
●
fermeture de la base de données ;
●
démontage de la base de données ;
●
arrêt de l’instance.
Une instance peut être démarrée avec trois niveaux successifs de disponibilité de la base de données, correspondant
aux trois phases du démarrage :
●
Instance démarrée (état NOMOUNT) ;
●
Base montée (état MOUT) ;
●
Base ouverte (état OPEN).
Lors du démarrage de l’instance, le fichier de paramètres est lu, la SGA est allouée et les processus d’arrière­plan sont
démarrés. À ce stade, seule l’instance est lancée ; il n’y a pas de base de données associée. Les vues dynamiques
relatives à l’instance (V$INSTANCE, V$SGA, V$OPTION, V$PARAMETER, V$VERSION etc.) sont interrogeables mais pas les vues
dynamiques relatives à la base de données (V$DATABASE par exemple). Cet état est principalement utilisé lors de la
création d’une nouvelle base.
Lors du montage de la base de données, l’instance utilise le paramètreCONTROL_FILES du fichier de paramètres pour
localiser les fichiers de contrôle et les ouvrir. Dans le fichier de contrôle, l’instance extrait le nom et le statut des fichiers
de données et des fichiers de journalisation, mais ne les ouvre pas et ne vérifie pas non plus leur présence ; si un
fichier n’est pas trouvé, aucun message d’erreur n’est affiché. À ce stade, une base de données est associée à
l’instance (V$DATABASE est maintenant interrogeable) mais n’est pas ouverte pour une utilisation "normale" : personne
ne peut se connecter à la base de données, à l’exception d’un utilisateur ayant le privilège SYSDBA ou SYSOPER. Les vues
statiques du dictionnaire ne sont notamment pas accessibles. Dans cet état, le DBA peut effectuer certaines tâches
d’administration : renommer ou déplacer un fichier de données ou un fichier de journalisation, activer ou désactiver
l’archivage des fichiers de journalisation, effectuer une récupération de la base de données.
Lors de l’ouverture de la base de données, l’instance ouvre les fichiers de journalisation et les fichiers de données qui
étaient en ligne au moment de l’arrêt, et vérifie la cohérence de la base de données. Si l’un des fichiers de données à
ouvrir n’est pas trouvé ou est endommagé, l’instance signale une erreur et la base de données n’est pas ouverte. Si la
base de données peut être ouverte mais que le dernier arrêt n’était pas un arrêt propre, SMON effectue la
récupération de l’instance. À ce stade, la base de données est accessible pour une utilisation "normale" : les
utilisateurs peuvent se connecter. Le dictionnaire de données est totalement disponible.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Démarrage
1. Utiliser SQL*Plus
a. La commande STARTUP
Dans SQL*Plus, la commande STARTUP permet de démarrer une instance et de lui associer une base avec le niveau
de disponibilité souhaité.
Syntaxe simplifiée
STARTUP [NOMOUNT | MOUNT [nom_base] | OPEN [nom_base]]
[RESTRICT] [PFILE=nom_fichier]
Avec
NOMOUNT | MOUNT | OPEN
niveau de disponibilité souhaité.
nom_base
nom de la base à monter ou à ouvrir.
RESTRICT
restreint l’accès à la base aux utilisateurs ayant le privilège RESTRICTED SESSION.
PFILE
nom du fichier de paramètres à utiliser.
L’option RESTRICT
Une base de données peut être ouverte (OPEN) dans un mode restreint (option RESTRICT) où seuls les utilisateurs
ayant le privilège particulier RESTRICTED SESSION (voir la section Gestion des droits dans le chapitre Gestion des
utilisateurs et de leurs droits) peuvent effectivement se connecter ; généralement, ce privilège n’est donné qu’aux
administrateurs.
Ce mode restreint peut être utilisé pour effectuer certaines opérations d’administration qui nécessitent que la base
soit ouverte mais qu’il est préférable (pas obligatoire) de réaliser sans utilisateur connecté. Exemples :
●
réorganiser le stockage d’une table, reconstruire des index ;
●
faire un export ou un import ;
●
faire un chargement de données avec SQL*Loader.
Ne pas avoir d’utilisateurs connectés pendant ces opérations permet d’éviter des mises à jour concurrentes
intempestives et de réaliser l’opération plus rapidement.
Lorsque l’opération est terminée, il est possible de quitter le mode restreint avec l’ordre SQL :
ALTER SYSTEM DISABLE RESTRICTED SESSION;
Fichier de paramètres et clause PFILE
Les noms par défaut du fichier de paramètres texte et du fichier de paramètres serveur d’une instance sont
respectivement init<SID>.ora et spfile<SID>.ora.
L’emplacement par défaut de ces deux fichiers dépend de la plate­forme :
© ENI Editions - All rights reserved - Algeria Educ
- 1-
●
%ORACLE_HOME%\database (Windows) ;
●
$ORACLE_HOME/dbs (Unix/Linux).
En ce qui concerne le fichier de paramètres texte, le nom et l’emplacement recommandés par le standard OFAsont
différents : init.ora dans le sous­répertoire pfiledu répertoire d’administration. Pour concilier l’emplacement par
défaut et le standard OFA, il est possible de créer un fichier init<SID>.ora dans le répertoire par défaut de la plate­
forme et d’y mettre une simple inclusion vers le "vrai" fichier de paramètres, grâce au paramètre IFILE. Exemple
(Windows) :
IFILE=’D:\app\oracle\admin\ORCL\pfile\init.ora’<$I[]IFILE>
Si la plate­forme le permet, il est aussi possible d’utiliser un lien symbolique.
Sans clause PFILE dans la commande STARTUP, Oracle recherche, à l’emplacement par défaut de la plate­forme, dans
l’ordre, un fichier :
●
spfile<SID>.ora
●
spfile.ora
●
init<SID>.ora
Le fichier spfile.ora (sans nom d’instance) est principalement utilisé dans le cas d’une configuration Real
Application Cluster.
En priorité, l’instance recherche donc par défaut un fichier de paramètres serveur. Spécifier la clause PFILE permet
de démarrer explicitement avec un fichier de paramètres texte, qui peut éventuellement ne pas respecter le nom
et/ou l’emplacement par défaut.
Pour démarrer avec un fichier de paramètres serveur situé à un autre emplacement ou ayant un autre nom, il faut
démarrer avec un fichier de paramètres texte contenant un paramètre SPFILE(pas IFILE) indiquant le chemin
d’accès complet au fichier de paramètres serveur. Exemple (Windows) :
SPFILE=’D:\app\oracle\admin\ORCL\pfile\sp.ora’
La valeur du paramètre SPFILE peut être consultée après démarrage de l’instance, dans la vue V$PARAMETER ou à
l’aide de la commande SQL*Plus SHOW PARAMETER. Si ce paramètre n’a pas été spécifié explicitement, il est affecté en
interne par le serveur. S’il est vide, c’est que l’instance a démarré avec un fichier de paramètres texte.
Il est recommandé d’utiliser un fichier de paramètres serveur. Pour vous simplifier la vie, respectez le nom
et l’emplacement par défaut.
b. Mode opératoire
Lancez SQL*PLUS et connectez­vous avec le privilège AS SYSDBA, en vous assurant que l’instance souhaitée est
correctement désignée.
Exemple :
●
Connexion locale après avoir positionné la variable d’environnement : ORACLE_SID
●
Plate­forme Windows :
C:\>set ORACLE_SID=ORCL
C:\>sqlplus /nolog
SQL> CONNECT / AS SYSDBA
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
●
Plate­forme Linux :
$ .oraenv<$I[]oraenv> <<< ORCL
$ sqlplus /nolog
SQL> CONNECT / AS SYSDBA
●
Connexion à travers le réseau en spécifiant un <nom de service réseau grâce à la commande SET
INSTANCE :
> sqlplus /nolog
SQL> SET INSTANCE orcl
SQL> CONNECT / AS SYSDBA
●
Connexion à travers le réseau en spécifiant un nom de service réseau dans la chaîne de connexion :
> sqlplus /nolog
SQL> CONNECT /@orcl AS SYSDBA
Tapez la commande STARTUP avec les options souhaitées :
●
Démarrer une instance sans associer de base de données (sans doute en vue d’en créer une nouvelle) :
SQL> STARTUP NOMOUNT
●
Démarrer une instance et simplement monter la base de données (pour effectuer certaines tâches
d’administration) :
SQL> STARTUP MOUNT
●
Démarrer une instance et ouvrir la base de données pour la rendre accessible à tous les utilisateurs :
SQL> STARTUP
Exemple de démarrage avec le fichier de paramètres serveur par défaut :
SQL> STARTUP
Instance ORACLE lancée.
Total System Global Area 313860096 bytes
Fixed Size
1332892 bytes
Variable Size
230689124 bytes
Database Buffers
75497472 bytes
Redo Buffers
6340608 bytes
Base de données montée.
Base de données ouverte.
SQL> SELECT value FROM v$parameter WHERE name = ’spfile’;
VALUE
---------------------------------------------------------D:\APP\ORACLE\PRODUCT\11.1.0\DB_1\DATABASE\SPFILEORCL.ORA
c. Modifier le niveau de disponibilité de la base de données
Si l’instance a été démarrée avec un état intermédiaire pour la base de données (NOMOUNT ou MOUNT), il est possible
de la faire passer à l’état suivant grâce à l’ordre SQL ALTER DATABASE.
●
De NOMOUNT à MOUNT
© ENI Editions - All rights reserved - Algeria Educ
- 3-
ALTER DATABASE [nom_base] MOUNT;
●
De MOUNT à OPEN
ALTER DATABASE [nom_base] OPEN;
Pour passer de l’état NOMOUNT à l’état OPEN, il faut passer par l’état MOUNT.
Il existe aussi des ordres SQL ALTER DATABASE CLOSE et ALTER DATABASE DISMOUNT qui permettent de fermer puis
démonter la base de données. Par contre, ces ordres ne peuvent pas être utilisés pour fermer une base de
données puis la rouvrir sans passer par un arrêt complet.
d. Récupérer des informations sur l’instance et sur la base de données
Plusieurs vues du dictionnaire de données permettent de récupérer des informations sur l’instance et la base de
données au cours du démarrage.
●
●
Dès l’état NOMOUNT :
●
V$INSTANCE : informations sur l’instance ;
●
V$PARAMETER : liste des paramètres actifs ;
●
V$SGA : informations sur la SGA ;
●
V$VERSION : version des différents composants d’Oracle
●
V$OPTION : liste des options Oracle.
À partir de l’état MOUNT :
●
●
V$DATABASE : information sur la base de données.
Dans l’état OPEN :
●
PRODUCT_COMPONENT_VERSION : version des différents composants d’Oracle.
Dans la vue V$INSTANCE, la colonne STATUS peut prendre les valeurs suivantes :
STARTED
instance démarrée, sans base (NOMOUNT)
MOUNTED
instance démarrée, base montée (MOUNT)
OPEN
instance démarrée, base ouverte (OPEN)
La colonne LOGINS indique si les connexions sont autorisées (valeur ALLOWED) ou restreintes (RESTRICTED).
Dans la vue V$DATABASE, la colonne OPEN_MODE peut prendre les valeurs suivantes :
MOUNTED
base montée (MOUNT)
READ WRITE
- 4-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
base ouverte (OPEN) en lecture/écriture (par défaut)
READ ONLY
base ouverte (OPEN) en lecture seule
Le mode d’ouverture de la base de données peut être spécifié dans l’ordre SQL ALTER DATABASE, ou dans la
commande STARTUP.
2. Utiliser le Database Control
Lorsque vous vous connectez au Database Control et que la base de données n’est pas ouverte, la page suivante
s’affiche :
Cette page vous permet soit de démarrer la base de données, soit d’effectuer une récupération.
Si la base est arrêtée mais qu’elle n’est pas endommagée, vous pouvez cliquer sur le bouton Démarrer ; une page
d’identification s’affiche :
© ENI Editions - All rights reserved - Algeria Educ
- 5-
Sur cette page, saisissez une identification pour l’hôte et une identification SYSDBAou SYSOPERpour la base de
données, puis cliquez sur le bouton OK.
Si l’instance est arrêtée, la page de confirmation de démarrage s’affiche :
Si l’instance est démarrée, base non montée (NOMOUNT) ou base montée (MOUNT), une page de choix d’opérations
s’affiche.
Cette page vous permet de préciser l’opération que vous souhaitez faire : arrêter la base de données, monter la
base de données, ouvrir la base de données. Sélectionnez l’option souhaitée et cliquez sur le bouton Continuer ; la
page de confirmation de démarrage s’affiche avec des informations de statut et d’opération adaptés. Exemple
(demande d’ouverture pour une base de données montée) :
Sur la page de confirmation de démarrage, vous pouvez cliquer sur le bouton Options avancées pour sélectionner les
options de démarrage (NOMOUNT, MOUNT, OPEN, RESTRICT, PFILE, etc.) ; les options proposées dépendent du contexte.
La séquence de recherche d’un fichier de paramètres est la même que pour le démarrage avec la commande
STARTUP dans SQL*Plus.
- 6-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Pour lancer l’opération, cliquez sur le bouton Oui. Pendant que l’opération se déroule, une page d’informations
d’activité est affichée.
Une fois que l’opération est terminée, la page qui s’affiche dépend du contexte.
●
●
Si la base de données n’est pas ouverte (non montée ou montée), la page d’informations sur le statut est de
nouveau affichée.
Si la base de données est ouverte, la page de connexion s’affiche.
Vous pouvez alors vous reconnecter au Database Control.
© ENI Editions - All rights reserved - Algeria Educ
- 7-
Arrêt
1. Utiliser SQL*Plus
a. La commande SHUTDOWN
Dans SQL*Plus, la commande SHUTDOWN permet de fermer la base et d’arrêter l’instance.
Syntaxe
SHUTDOWN [NORMAL | IMMEDIATE | TRANSACTIONAL | ABORT]
Options :
NORMAL
Oracle attend que tous les utilisateurs soient déconnectés (pas de nouvelle connexion autorisée) puis ferme
proprement la base de données.
IMMEDIATE
Oracle déconnecte tous les utilisateurs (en effectuant un ROLLBACK des éventuelles transactions en cours) puis
ferme proprement la base de données.
TRANSACTIONAL
Oracle attend que toutes les transactions en cours se terminent avant de déconnecter les utilisateurs (pas de
nouvelle transaction autorisée) puis ferme proprement la base de données.
ABORT
Oracle déconnecte tous les utilisateurs (sans effectuer de ROLLBACK des éventuelles transactions en cours) puis
ferme "brutalement" la base de données, sans effectuer de point de synchronisation (checkpoint). Une récupération
de l’instance sera nécessaire lors du prochain démarrage.
Le processus de l’arrêt est le suivant :
●
La base de données est fermée.
●
La base de données est démontée.
●
L’instance est arrêtée (les processus d’arrière­plan sont arrêtés et la SGA est libérée).
Un arrêt est forcément complet ; il n’est pas possible de s’arrêter dans un état intermédiaire (MOUNT ou NOMOUNT).
Pour passer une base ouverte (OPEN) en état monté (MOUNT), il faut arrêter la base (SHUTDOWN) et la redémarrer dans
l’état souhaité (STARTUP MOUNT par exemple).
Les arrêts NORMAL, IMMEDIATE et TRANSACTIONAL sont propres ; un point de synchronisation (checkpoint) est réalisé
sur les fichiers de données. Le redémarrage ultérieur ne nécessitera pas de récupération de l’instance. Ce n’est pas
le cas de l’arrêt ABORT pour lequel le point de synchronisation n’est pas réalisé ; les fichiers de données sont
immédiatement fermés. Ce comportement est similaire à un arrêt anormal de l’instance. Lors du prochain
redémarrage, une récupération de l’instance (automatique) sera nécessaire (voir les principes dans le chapitre Les
bases de l’architecture Oracle).
L’arrêt NORMAL est souvent problématique car il attend la déconnexion des utilisateurs, même si ceux­ci sont inactifs.
Dans ce cas, l’arrêt IMMEDIATE peut être utilisé pour déconnecter les utilisateurs ; les transactions éventuellement
en cours sont annulées. L’opération d’annulation des transactions peut prendre un peu de temps et l’arrêt n’est
pas aussi immédiat.
L’arrêt TRANSACTIONAL est un peu moins "violent" que l’arrêt IMMEDIATE puisqu’il attend que les transactions en cours
se terminent avant d’arrêter la base. Par contre, il faut avoir conscience que cet arrêt peut être bloqué par une
transaction qui ne termine pas (la transaction est elle­même bloquée ou un utilisateur est parti en laissant un ordre
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
INSERT/ UPDATE/DELETE en suspens).
L’arrêt ABORT est le plus rapide (lui est immédiat !) mais ne doit être utilisé qu’en dernier recours : blocage d’un
autre type d’arrêt, besoin réel d’arrêter la base immédiatement.
Dans un script d’arrêt automatique destiné, par exemple, à faire une sauvegarde, utilisez un
SHUTDOWN IMMEDIATE pour être certain que la base de données sera effectivement arrêtée.
b. Mode opératoire
Lancez SQL*PLUS et connectez­vous AS SYSDBA, en vous assurant que l’instance souhaitée est correctement
désignée.
Exemple :
> sqlplus /nolog
SQL> SET INSTANCE orcl
SQL> CONNECT / AS SYSDBA
Vérifiez éventuellement s’il y a des utilisateurs connectés et des transactions en cours :
Exemple :
SQL> SELECT sid,serial#,username,DECODE(taddr,NULL,’’,’Oui’) trans
2 FROM v$session
3 /
Tapez la commande SHUTDOWN avec les options souhaitées :
●
Arrêt sans utilisateur connecté :
SQL> SHUTDOWN
●
Arrêt avec des utilisateurs connectés en laissant les transactions se terminer :
SQL> SHUTDOWN TRANSACTIONAL
La vue V$SESSIONpermet de visualiser les utilisateurs connectés ; cette vue sera présentée plus en détail dans la
section Superviser les utilisateurs connectés du chapitre Gestion des utilisateurs et de leurs droits. Les techniques
utilisables pour déconnecter les utilisateurs seront aussi présentées dans la section Superviser les utilisateurs
connectés du chapitre Gestion des utilisateurs et de leurs droits.
Dans V$SESSION, il faut vérifier s’il existe d’autres sessions que les sessions correspondant aux processus d’arrière­
plan (colonne username vide) et que la session SYS (session utilisée pour l’arrêt). La requête présentée ci­dessus
permet aussi de savoir si les utilisateurs connectés ont une transaction en cours (colonne trans égale à Oui).
Dans la pratique, si le Database Control est lancé (service OMS et agent), vous aurez une ou plusieurs
sessions SYSMAN et DBSNMP. Pour arrêter la base de données, vous devrez donc, soit arrêter le Database
Control (emctl stop dbconsole), soit utiliser la commande SHUTDOWN IMMEDIATE.
2. Utiliser le Database Control
Sur la page d’accueil du Database Control, le cadre Général donne le statut actuel et propose un bouton Arrêter qui
permet d’arrêter la base de données :
- 2-
© ENI Editions - All rights reserved - Algeria Educ
Si vous cliquez sur le bouton Arrêter, la page d’identification s’affiche :
Sur cette page, saisissez une identification pour l’hôte et une identification SYSDBA ou SYSOPER pour la base de
données, puis cliquez sur le bouton OK.
Les champs de cette page sont remplis par défaut si vous avez défini des informations d’identification dans
vos préférences (cf. section Oracle Enterprise Manager Database Control du chapitre Les outils
d’administration). Notez par ailleurs que c’est l’identification SYSDBA indiquée sur cette page qui sera utilisée pour
effectuer l’arrêt et non votre connexion actuelle au Database Control (qui peut être une connexion normale et pas
SYSDBA).
La page de confirmation d’arrêt est ensuite affichée :
Sur cette page de confirmation de démarrage, vous pouvez cliquer sur le bouton Options avancées pour sélectionner
les options de l’arrêt (NORMAL, IMMEDIATE, etc.) ; un lien est aussi proposé pour visualiser les sessions.
Cliquez sur le bouton Oui pour procéder à l’arrêt. Pendant que l’opération se déroule, une page d’informations
d’activité est affichée :
Au bout de quelques instants, cliquez sur le bouton Régénérer pour revenir au Database Control.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Si l’arrêt n’est pas encore terminé, la page d’accueil habituelle s’affiche. Attendez encore quelques instants avant de
rafraîchir la page.
Pour une raison inconnue, il arrive fréquemment qu’une page d’erreur soit affichée à ce stade :
Cliquez sur le bouton OK pour revenir à la page précédente et attendez quelques instants pour cliquer de nouveau
sur le bouton Régénérer. Si le problème persiste, quittez le Database Control puis ouvrez­le à nouveau.
Attendez encore quelques instants avant de rafraîchir la page. Lorsque l’arrêt est terminé, la page d’informations sur
le statut doit s’afficher :
- 4-
© ENI Editions - All rights reserved - Algeria Educ
Automatisation et scripts
1. Sur plate­forme Unix ou Linux
a. Automatisation
Sur plate­forme Unix ou Linux, des bases de données peuvent être démarrées ou arrêtées automatiquement grâce
au script de démarrage présenté dans la section Installation du serveur du chapitre L’installation. Ce script de
démarrage appelle les scripts dbstart et dbshut fournis par Oracle.
Extraits du script :
# Démarrer les bases de données
echo "** démarrage des bases de données" >> $LOG
$ORACLE_HOME/bin/dbstart $ORACLE_HOME_LISTENER > $LOG 2>&1 &
...
# Arrêter les bases de données
echo "** arrêt des bases de données" >> $LOG
$ORACLE_HOME/bin/dbshut $ORACLE_HOME_LISTENER > $LOG 2>&1 &
Les scripts dbstart et dbshut utilisent le fichier /etc/oratabpour déterminer quelles sont les bases de données à
démarrer ou arrêter automatiquement. Ce fichier contient une ou plusieurs lignes de la forme suivante :
<ORACLE_SID>:<ORACLE_HOME>:{Y|N}
Exemple :
ORCL:/u01/app/oracle/product/11.1.0/db_1:Y
L’emplacement du fichier oratab peut varier selon le système d’exploitation. Consultez la documentation
Installation Guide de votre plate­forme.
Pour démarrer ou arrêter automatiquement une base de données, il suffit de mettre un Y dans le dernier champ de
la ligne correspondant à la base de données.
Le script dbstart lance SQL*Plus et utilise la commande STARTUP sans clause PFILE ; la séquence de recherche du
fichier de paramètres est donc la même que pour un démarrage manuel avec la commande STARTUP dans SQL*Plus.
Si vous avez plusieurs versions d’Oracle sur votre serveur, utilisez les scripts dbstart et dbshut de la
version la plus récente (ajustez la variable d’environnement $ORACLE_HOME en conséquence).
b. Scripts
Les scripts dbstart et dbshut peuvent être appelés manuellement pour démarrer ou arrêter les bases de données
configurées à Y dans oratab.
Des scripts shell personnalisés similaires à dbstart et dbshut peuvent être très facilement écrits.
Exemple (script restart) :
ORACLE_SID=$1
ORAENV_ASK=NO
. oraenv
export ORACLE_SID ORAENV_ASK
sqlplus /nolog << _EOF_
CONNECT / AS SYSDBA
SHUTDOWN IMMEDIATE
STARTUP
EXIT
_EOF_
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Appel :
$ . restart ORCL
Ce script permet de redémarrer une base de données dont l’identifiant d’instance est passé en paramètre. Il
appelle le script oraenv pour modifier l’environnement puis SQL*Plus pour faire un SHUTDOWN et un STARTUP. La
connexion SYSDBA s’effectue avec une authentification par le système d’exploitation. ORAENV_ASK=NO permet de ne
pas avoir de question posée par oraenv.
2. Sur plate­forme Windows
a. Automatisation
Pour démarrer automatiquement une base au démarrage du système, il faut mettre le service associé à l’instance
(OracleService<SID>) en démarrage automatique.
En complément, il peut être nécessaire (en cas de problème notamment) de s’assurer que le paramètre
ORA_<SID>_AUTOSTARTest bien à TRUE dans la base de registre. Si le service a été créé en démarrage automatique
(chapitre Création d’une nouvelle base de données), cela doit être le cas.
Pour arrêter automatiquement une base lors de l’arrêt du système, il faut s’assurer que le paramètre
ORA_<SID>_SHUTDOWNest bien à TRUE dans la base de registre et ajuster éventuellement la valeur du
paramètreORA_<SID>_SHUTDOWN_TIMEOUT. Normalement, cela doit être le cas.
Dans
la
base
de
registre,
les
paramètres
indiqués
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_nom_oracle_home.
ci­dessus
se
trouvent
dans
la
clé
Les paramètres de la base de registre ont la signification suivante :
ORA_<SID>_AUTOSTART
Indique si l’instance identifiée par <SID> doit être démarrée (valeur TRUE) ou non (valeur FALSE) après le démarrage
du service.
ORA_<SID>_SHUTDOWN
Indique si l’instance identifiée par <SID> doit être arrêtée (valeur TRUE) ou non (valeur FALSE) lors de l’arrêt du
service.
ORA_<SID>_SHUTDOWNTYPE
Type d’arrêt effectué sur l’instance identifiée par <SID> : abort, immediate (valeur par défaut), transactional et
normal.
ORA_<SID>_SHUTDOWN_TIMEOUT
Délai (en secondes) accordé à l’instance identifiée par <SID> pour s’arrêter avant l’arrêt du service (qui est alors
équivalent à un SHUTDOWN ABORT).
Si votre base met plus de 90 secondes à s’arrêter, augmentez
ORA_<SID>_SHUTDOWN_TIMEOUT pour éviter d’avoir des arrêts de type ABORT.
la
valeur
du
paramètre
Dans la base de registre, il est possible de définir un paramètre ORA_<SID>_PFILE qui donne le chemin d’accès
complet vers le fichier de paramètres texte à utiliser pour le démarrage de l’instance identifiée par <SID>.
Si ce paramètre est vide, ou n’existe pas, la séquence de recherche du fichier de paramètres s’effectue comme lors
d’un STARTUP sans clause PFILE dans SQL*Plus. Si le paramètre est renseigné, le démarrage s’effectue avec le
fichier de paramètres texte indiqué. Si ce paramètre contient une valeur erronée, l’instance ne démarre pas au
redémarrage du service associé. Pour démarrer avec un fichier de paramètres serveur non standard, vous pouvez
utiliser la technique du fichier de paramètres texte contenant un paramètre SPFILE.
b. Scripts
Plusieurs techniques sont possibles pour écrire des scripts de démarrage ou d’arrêt :
●
- 2-
en utilisant la commande système net pour démarrer (net start) ou arrêter le service (net stop) ;
© ENI Editions - All rights reserved - Algeria Educ
●
●
en utilisant l’utilitaire oradim fourni par Oracle ;
en utilisant un fichier de commandes (.bat) qui lance SQL*Plus avec un script SQL sur la ligne de commande
qui démarre ou arrête la base.
Syntaxe simplifiée de l’utilitaire oradim :
■
Pour le démarrage :
ORADIM -STARTUP -SID sid
■
Pour l’arrêt :
ORADIM -SHUTDOWN -SID sid [-SHUTTYPE type] [-SHUTMODE mode]
Avec :
sid
Identifiant de l’instance.
type
Indique ce qui doit être arrêté. Valeurs possibles : srvc (service) ou inst (instance, par défaut) ou srvc,inst (les
deux).
mode
Mode de l’arrêt. Valeurs possibles : i (IMMEDIATE, valeur par défaut), n (NORMAL) ou a (ABORT).
Exemple (fichier de commande restart.bat) :
set ORACLE_SID=%1%
oradim -shutdown -sid %ORACLE_SID%
oradim -startup -sid %ORACLE_SID%
Appel :
C:\>restart ORCL
Ce script permet de redémarrer une base de données dont l’identifiant d’instance est passé en paramètre.
Le service du Database Control (OracleDBConsole<SID>) est dépendant du service de l’instance ; pour
arrêter le service de l’instance, il faut au préalable arrêter le service du Database Control. Inversement,
démarrer le service du Database Control démarre le service de l’instance.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Problèmes courants et solutions
ORA-01033: ORACLE initialization or shutdown in progress
Explication
La base de données n’est pas ouverte.
Cause(s)
Vous tentez de vous connecter à une base de données non ouverte sans utiliser de connexion SYSDBA. La base de
données est peut être effectivement en train de démarrer ou de s’arrêter ; la base de données est peut­être aussi
tout simplement non montée ou montée.
Action(s)
Connectez­vous AS SYSDBA et interrogez la colonne STATUS de V$INSTANCE.
ORA-01034: ORACLE not available
Explication
L’instance est arrêtée.
Cause(s)
Vous tentez de vous connecter à une instance Oracle arrêtée sans utiliser de connexion SYSDBA.
Action(s)
Connectez­vous AS SYSDBA et démarrez l’instance.
ORA-01081: impossible de lancer ORACLE déjà en cours - fermer d’abord le thread
Explication
Vous tentez de démarrer une instance déjà démarrée.
Cause(s)
Vous n’êtes pas connecté à la bonne instance. Vous tentez de passer d’un état NOMOUNT ou MOUNT à OPEN en faisant un
STARTUP.
Action(s)
Interrogez V$INSTANCE pour vérifier à quelle instance vous êtes connecté. Si vous n’êtes pas sur la bonne instance,
reconnectez­vous (après avoir modifié ORACLE_SID ou en utilisant le bon nom de service réseau). Pour passer une base
de données de l’état NOMOUNT ou MOUNT à OPEN, utilisez la commande ALTER DATABASE.
ORA-01109: base de données non ouverte
ORA-01219: BdD fermee : demandes seulement autorisées sur des tables/vues fixes
Explication
La base de données n’est pas ouverte mais simplement montée (MOUNT).
Cause(s)
Vous tentez de faire une action (ORA-01109) ou de lire une vue statique du dictionnaire de données (ORA-01219) qui
nécessite que la base soit ouverte.
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Action(s)
Interrogez la colonne STATUS de V$INSTANCE et si c’est le cas (valeur MOUNTED au lieu de OPEN), ouvrez d’abord la base
de données.
ORA-01507: base de données non montée
Explication
La base de données n’est pas montée (NOMOUNT) ; seule l’instance est démarrée.
Cause(s)
Vous tentez de faire une action qui nécessite que la base de données soit montée, par exemple : interrogation de
V$DATABASE, ordre SQL ALTER DATABASE OPEN, etc.
Action(s)
Interrogez la colonne STATUS de V$INSTANCE et si c’est le cas (valeur STARTED au lieu de MOUNTED), montez d’abord la
base de données (ALTER DATABASE MOUNT).
ORA-12560: TNS : erreur d’adaptateur de protocole
Explication
Le processus d’écoute n’a pas réussi à démarrer un processus pour connecter l’utilisateur à l’instance.
Cause(s)
La variable ORACLE_SID n’est pas correctement positionnée. Sur plate­forme Windows, le service associé à l’instance
(OracleService<SID>) n’est pas lancé.
Action(s)
Vérifiez la variable et/ou le service associé.
Blocage d’un SHUTDOWN
Cause(s)
Sur un SHUTDOWN NORMAL, il y a des utilisateurs connectés. Sur un SHUTDOWN TRANSACTIONAL, il y a des transactions en
cours. Sur un SHUTDOWN IMMEDIATE, il y a une très grosse transaction à annuler... ou un autre problème.
Action(s)
Ouvrez une autre session de l’outil d’administration, connectez­vous AS SYSDBA et exécutez un SHUTDOWN ABORT. Si cela
ne marche pas, il faut "tuer" les processus :
­ Redémarrage du service associé à l’instance sur plate­forme Windows.
­ kill des processus sur plate­forme Unix.
Lorsqu’un SHUTDOWN est en cours, il n’est plus possible d’interroger V$SESSION et donc de déterminer si le problème est
lié à des utilisateurs connectés.
Sur un SHUTDOWN IMMEDIATE, soyez patient ! L’arrêt peut prendre plusieurs dizaines de secondes.
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Vue d’ensemble
1. Étapes de création d’une nouvelle base de données pour une application
Le processus complet de création d’une nouvelle base de données pour une application comporte les grandes étapes
suivantes :
Conception du modèle physique
●
●
Définir
tous
les
objets
(Oracle)
de
l’application : tables,
contraintes
d’intégrité
(clés
primaires/uniques/étrangères), index, vues, programmes stockés (triggers, procédures/ fonctions stockées,
packages).
Étudier la volumétrie de l’application (nombre d’utilisateurs, nombre de lignes attendues dans les tables).
Création de la base proprement dite (ce chapitre)
●
●
●
●
Créer une nouvelle instance.
Créer une nouvelle base de données (fichiers de contrôle, fichiers de journalisation et fichiers de données des
tablespaces "techniques" d’Oracle).
Rendre le dictionnaire de données exploitable.
À ce stade, la base de données peut être vue comme une "enveloppe" (une "boîte vide") dans laquelle des
structures vont être créées pour une ou plusieurs applications.
Création des structures de stockage adaptées (chapitres Gestion des tablespaces et des fichiers de données et
Gestion des informations d’annulation)
●
●
Créer les tablespaces (avec leurs fichiers de données) destinés à stocker les données de l’application (tables
et index).
Les dimensionner en fonction de l’étude de volumétrie réalisée initialement.
Création du compte Oracle qui va contenir les objets de l’application (chapitre Gestion des utilisateurs et de
leurs droits)
●
Créer le compte.
●
Lui donner les privilèges suffisants pour créer les objets.
●
L’autoriser à utiliser de l’espace dans les tablespaces de l’application.
Création des objets de l’application dans ce compte Oracle (chapitre Gestion des tables et des index)
●
●
Créer les objets Oracle de l’application (généralement sous la forme d’un ou de plusieurs scripts).
Dimensionner chaque objet occupant de l’espace de stockage (table et index) en fonction de l’étude de
volumétrie réalisée initialement.
Création des utilisateurs finaux de l’application (chapitre Gestion des utilisateurs et de leurs droits)
© ENI Editions - All rights reserved - Algeria Educ
- 1-
●
●
Créer les utilisateurs.
Leur donner des droits adaptés sur les objets de l’application (i.e. sur les objets créés précédemment dans le
compte propriétaire de l’application).
Sauvegarde de la base (chapitre Sauvegarde et récupération)
●
Sauvegarde de référence de la base.
Comme vous pouvez le constater, la création de la base de données proprement dite présentée dans ce chapitre
n’est qu’une petite étape du processus complet (mais une étape fondamentale).
2. Étapes de création de la base de données proprement dite
Les grandes étapes de la création de la base de données proprement dite sont les suivantes :
●
Créer les répertoires sur les disques, si possible en respectant les recommandations du standard OFA.
●
Préparer un nouveau fichier de paramètres texte, généralement par copie d’un ancien.
●
Positionner la variable d’environnement ORACLE_SID.
●
Créer le service associé à l’instance (plate­forme Windows) ou créer le fichier de mot de passe pour
l’identification SYSDBA (plate­forme Unix ou Linux).
●
Lancer SQL*Plus et se connecter AS SYSDBA.
●
Créer un fichier de paramètres serveur (pas obligatoire, mais conseillé).
●
Démarrer l’instance en état NOMOUNT.
●
Créer la base de données (ordre SQL CREATE DATABASE).
●
Finaliser la création du dictionnaire (quelques scripts à exécuter).
●
Configurer Oracle Net pour la nouvelle base de données.
●
Enregistrer la nouvelle instance dans le fichier oratab (plate­forme Unix ou Linux).
●
Configurer le Database Control.
La création d’une nouvelle base de données suppose l’installation préalable d’Oracle (chapitre Installation).
Si le serveur abrite déjà des bases de données Oracle, il est vivement conseillé d’effectuer une sauvegarde
de ces bases de données avant de démarrer le processus de création.
Après ces étapes, la nouvelle base de données est ouverte et contient :
- 2-
●
les tablespaces SYSTEM et SYSAUX avec leur(s) fichier(s) de données associé(s) ;
●
éventuellement un tablespace d’annulation et un tablespace temporaire selon les options utilisées ;
●
les fichiers de contrôle et de journalisation ;
●
les deux comptes DBA standard (SYS et SYSTEM) ;
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
●
le segment d’annulation SYSTEM ;
●
le dictionnaire de données.
À ce stade, la base de données est prête pour accueillir des structures complémentaires qui vont constituer
l’application.
3. Méthodes disponibles
La nouvelle base de données peut être créée à la main avec les outils du système d’exploitation et SQL*Plus ; dans
ce cas, il est très simple d’écrire ou de récupérer des scripts et de les réutiliser à chaque fois. Les étapes de création
de la base de données proprement dite sont toujours les mêmes et dépendent (relativement) peu des
caractéristiques de l’application (et en tout état de cause, des paramètres peuvent être ajustés ultérieurement en
fonction des caractéristiques de l’application) ; utiliser des scripts "génériques" de création de bases est donc
envisageable.
La nouvelle base de données peut aussi être créée à l’aide d’un assistant graphique, l’assistant Configuration de
base de données. Cet assistant facilite la création de la base de données en offrant la possibilité d’utiliser des
modèles de base de données prêts à l’emploi et/ou en permettant de définir très précisément les caractéristiques de
la nouvelle base de données à l’aide de plusieurs écrans. Par ailleurs, il est possible de définir ses propres modèles
de base de données, comprenant ou non des fichiers de données prêts à l’emploi, puis de les utiliser lors de la
création ultérieure d’une nouvelle base de données. L’assistant graphique offre aussi la possibilité de générer les
scripts de création de la base de données, sans créer la base de données ; c’est un bon moyen pour constituer nos
scripts "génériques".
L’assistant graphique inclut les étapes suivantes de création des structures de stockage (chapitres Gestion
des fichiers de contrôle et de journalisation et Gestion des tables­ paces et des fichiers de données).
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Création de la base de données manuellement
1. Créer les répertoires sur les disques
Pour respecter les recommandations du standard OFA (voir le chapitre Installation), vous devez créer :
●
●
un répertoire d’administration, portant le nom de la base de données, situé dans le répertoire %ORACLE_BASE%
\admin(Windows) ou $ORACLE_BASE/admin (Linux/ Unix),
un répertoire de données, portant le nom de la base de données, situé dans un répertoire oradata lui­même
situé dans ORACLE_BASE ou sur un autre volume.
Depuis la version 11 et l’apparition du Référentiel de Diagnostic Automatique, le répertoire d’administration
contient moins de répertoires et de fichiers.
Le répertoire d’administration contient généralement les répertoires suivants :
adump
Répertoire pour des fichiers d’audit.
create ou scripts
Répertoire des scripts de création de la base de données.
exp ou dpdump
Répertoire pour les fichiers d’export.
pfile
Répertoire pour les fichiers de paramètres texte.
Si le serveur comporte plusieurs disques, il sera judicieux de répartir les différents fichiers de la base de données sur
ces disques afin d’optimiser les entrées/sorties et d’éviter les contentions ; dans ce cas, il faut créer d’autres
répertoires de données sur les disques concernés.
Un répertoire supplémentaire peut être créé pour la zone de récupération rapide (voir le chapitre Sauvegarde et
récupération).
Généralement, la base de données et l’instance portent le même nom.
2. Préparer un nouveau fichier de paramètres texte
a. Principes
Comme indiqué dans la section La base de données du chapitre Les bases de l’architecture Oracle, il est conseillé
d’utiliser un fichier de paramètres serveur, celui­ci étant initialement créé à partir d’un fichier de paramètres texte.
Pour respecter le standard OFA, ce fichier de paramètres texte doit s’appeler init.ora et se trouver dans le sous­
répertoire pfiledu répertoire d’administration. Généralement, ce fichier de paramètres texte est créé par duplication
d’un fichier existant ou d’un fichier modèle que vous aurez défini.
Nous ne créerons pas de fichier init<SID>.ora (avec une inclusion du fichier init.ora) à l’emplacement par défaut de
la plate­forme (dbs sous Unix/Linux, database sous Windows) ; ainsi, nous ne risquons pas de démarrer par mégarde
avec un fichier de paramètres texte.
Il y a plus de 250 paramètres documentés par Oracle ! Il n’est évidemment pas question de les spécifier tous ! Sur la
totalité des paramètres, une trentaine de paramètres qu’il convient de connaître, sont suffisants pour la plupart des
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
bases de données.
Certains paramètres seront décrits brièvement dans cette partie puis présentés de manière plus détaillée dans des
chapitres ultérieurs.
b. Les principaux paramètres
Les paramètres ne sont pas listés dans un ordre alphabétique mais dans un ordre thématique.
Reportez­vous à la section Compléments sur les paramètres relatifs à la mémoire pour avoir plus
d’informations à ce sujet.
DB_NAME
Nom de la base (jusqu’à 8 caractères). Généralement DB_NAME est égal au nom de l’instance (ORACLE_SID).
Exemple :
DB_NAME = hermes
DB_DOMAIN
Localisation logique de la base sur le réseau (jusqu’à 128 caractères). Ce paramètre, associé au paramètre DB_NAME,
permet à Oracle de construire le nom global de la base de données<, sous la forme DB_NAME.DB_DOMAIN. Ce
paramètre est important si la base de données appartient à un système distribué (ou est susceptible de
l’être) ; sinon, il peut être ignoré.
Exemple :
DB_DOMAIN = olivier-heurtel.fr
DB_UNIQUE_NAME
Nom unique de base de données (jusqu’à 30 caractères). Des bases de données ayant le même DB_NAME au sein du
même DB_DOMAIN (par exemple une base de production et une base de test) doivent avoir un DB_UNIQUE_NAME
différent. Ce paramètre est apparu en version 10. Il est, par défaut, égal à DB_NAME.
Ce paramètre doit être spécifié si vous souhaitez ouvrir simultanément sur un serveur deux bases portant le même
nom (le même DB_NAME) ; il permet de les différencier.
Exemple :
DB_UNIQUE_NAME = hermes_demo
COMPATIBLE
Indique un numéro de version d’Oracle avec laquelle la base de données doit être compatible. Valeurs possibles :
10.0.0 jusqu’au numéro de la version actuelle (11.1.0.6). Valeur par défaut : 11.0.0.
Ce paramètre permet d’utiliser une nouvelle version d’Oracle en restant compatible avec une version plus ancienne,
et donc sans avoir besoin de tester les nouvelles fonctionnalités sur la base de données. Certaines fonctionnalités
de la nouvelle version peuvent être restreintes. La valeur du paramètre peut être augmentée ultérieurement, mais il
est ensuite généralement impossible de redescendre (il faut repartir d’une sauvegarde antérieure au changement).
Exemple :
COMPATIBLE = 11.1.0.
CONTROL_FILES
Emplacement des fichiers de contrôle de la base de données. Il est conseillé d’en spécifier au minimum 2, si possible
sur des disques différents (dans l’idéal, 3 ou 4 sur des disques différents). La recommandation OFA pour le nommage
du fichier est controlN.ctl, N étant un numéro d’ordre (1, 2, etc. ou 01, 02, etc.).
Si le fichier de paramètres a été créé par duplication d’un fichier existant utilisé, n’oubliez pas de modifier ce
paramètre. En cas d’oubli, vous risquez d’écraser les fichiers de contrôle présents dans cette directive et
donc de provoquer un arrêt brutal de la base de données qui les utilise.
- 2-
© ENI Editions - All rights reserved - Algeria Educ
Exemple :
CONTROL_FILES = ("f:\oracle\oradata\HERMES\control01.ctl",
"g:\oracle\oradata\HERMES\control02.ctl")
DB_BLOCK_SIZE
Taille de bloc "standard" en octets, utilisée par défaut pour les fichiers de données des tablespaces et pour
l’organisation du cache de données (buffer cache). La valeur doit être comprise entre 2 Ko et 32 Ko (sauf restriction
spécifique à la plate­forme) et être un multiple de la taille de bloc du système d’exploitation. Ce paramètre ne peut
pas être modifié ultérieurement sans recréer la base de données. Valeur par défaut = 8192 (8 Ko).
La taille de bloc peut avoir un impact plus ou moins important sur les performances. L’exposé des avantages et
inconvénients respectifs des "petits" blocs et des "grands" blocs sort du cadre de cet ouvrage. En résumé, les
recommandations d’Oracle sont les suivantes :
●
●
●
Pour un système plutôt transactionnel (généralement caractérisé par des petites requêtes de lecture et de
mises à jour), utilisez des "petits" blocs (4 Ko ou 8 Ko).
Pour un système plutôt décisionnel (généralement caractérisé par des grosses requêtes de lecture), utilisez
des "gros" blocs (16 Ko ou 32 Ko).
Pour les systèmes mixtes, ou dans le doute, utilisez une taille de bloc de 8 ko (valeur par défaut).
Exemple :
DB_BLOCK_SIZE = 8192
MEMORY_MAX_TARGET
Taille maximum de la mémoire utilisable par l’instance. Peut être spécifiée en octets, en Ko (symbole K), en Mo
(symbole M) ou en Go (symbole G). Si ce paramètre n’est pas spécifié, il est égal à la valeur du paramètre
MEMORY_TARGET.
N’oubliez pas que les modifications dynamiques de la mémoire s’effectuent dans la limite de la valeur du paramètre
MEMORY_MAX_TARGET, qui lui n’est pas dynamique (cf. Chapitre Les bases de l’architecture Oracl, section L’instance).
Exemple
MEMORY_MAX_TARGET = 2G
MEMORY_TARGET
Taille de la mémoire allouée à l’instance. Peut être spécifié en octets, en Ko (symbole K), en Mo (symbole M) ou en Go
(symbole G). Valeur par défaut : 0. Valeur minimale : 148 Mo. La valeur peut être arrondie par Oracle au granule
supérieur. Ce paramètre est apparu en version 11.
Si ce paramètre a une valeur différente de zéro, la gestion automatique de la mémoire (Automatic Memory
Management ­ AMM) est activée. Dans ce cas, Oracle dimensionne automatiquement la SGA et la PGA en fonction de
leurs besoins respectifs et de la charge du système (cf. section L’instance du chapitre Les bases de l’architecture
Oracle).
Exemple
MEMORY_TARGET = 2G
SGA_MAX_SIZE
Taille maximale de la SGA. Peut être spécifiée en octets, en Ko (symbole K), en Mo (symbole M) ou en Go (symbole G).
Si ce paramètre n’est pas spécifié, Oracle lui donne la valeur du paramètre MEMORY_MAX_TARGET s’il est défini ou la
taille de la SGA au démarrage de l’instance.
N’oubliez pas que les modifications dynamiques de la SGA s’effectuent dans la limite de la valeur du paramètre
SGA_MAX_SIZE, qui lui n’est pas dynamique (cf. section L’instance du chapitre Les bases de l’architecture Oracle).
Exemple :
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
SGA_MAX_SIZE = 1G
SGA_TARGET
Taille souhaitée pour la SGA. Peut être spécifié en octets, en Ko (symbole K), en Mo (symbole M) ou en Go (symbole
G). Valeur par défaut : 0. Valeur minimale : 64 Mo, annoncée dans la documentation mais plutôt 80 Mo sur une plate­
forme 32 bits et 88 Mo sur une plate­forme 64 bits. La valeur peut être arrondie par Oracle au granule supérieur. Ce
paramètre est apparu en version 10.
Si la gestion automatique de la mémoire est activée (MEMORY_TARGET est différent de zéro), ce paramètre fixe une
taille minimale pour la SGA ; s’il n’est pas spécifié, la valeur 0 lui est attribuée et la taille de la SGA est ajustée en
interne.
Si la gestion automatique de la mémoire est désactivée (MEMORY_TARGET est égal à zéro), et si ce paramètre a une
valeur différente de zéro, le réglage automatique de la mémoire partagée est activé. Dans ce cas, les composantes
suivantes de la SGA sont automatiquement dimensionnées (cf. section L’instance du chapitre Les bases de
l’architecture Oracle) : Database Buffer Cache (DB_CACHE_SIZE), Shared Pool (SHARED_POOL_SIZE), Large Pool
(LARGE_POOL_SIZE), Java Pool (JAVA_POOL_SIZE) et Streams Pool (STREAMS_ POOL_SIZE).
Exemple :
SGA_TARGET = 1G
SHARED_POOL_SIZE
Taille en octets de la Shared Pool. Peut être spécifiée en octets, en Ko (symbole K), en Mo (symbole M) ou en Go
(symbole G). La valeur peut être arrondie par Oracle au granule supérieur.
Si le réglage automatique de la mémoire partagée est activé (SGA_TARGET ou MEMORY_ TARGET différent de zéro), ce
paramètre fixe une taille minimale pour la Shared Pool. S’il n’est pas spécifié, la valeur 0 lui est attribuée et la taille de
la Shared Pool est ajustée en interne par Oracle.
Si le réglage automatique de la mémoire partagée est désactivé (SGA_TARGET ou MEMORY_TARGET égal à zéro), ce
paramètre fixe la taille de la Shared Pool. S’il n’est pas spécifié, sa valeur par défaut est de 64 Mo sur une plate­forme
32 bits et 128 Mo sur une plate­forme 64 bits.
Il n’y a pas de règle simple ni de formule de calcul pour déterminer la taille de la Shared Pool. Les besoins dépendent
énormément de l’application. Par contre, il peut être facilement audité ultérieurement et modifié en cas de besoin
(sans arrêter la base car le paramètre est dynamique).
Si le partage des requêtes est bon, la taille de la Shared Pool est peu liée au nombre d’utilisateurs. La taille de la
Shared Pool est plutôt liée au nombre total de requêtes différentes, exécutées par l’application et à leur complexité. Il
est par ailleurs important de tenir compte des programmes PL/SQL utilisés par l’application (triggers,
procédures/fonctions stockées, packages).
Pour une application moyenne, ayant un bon partage des requêtes (utilisation de variables bind) et n’utilisant pas de
programmes PL/SQL, une valeur de l’ordre de 150 Mo peut être suffisante. Si l’application utilise des programmes
PL/SQL, ou si l’application utilise beaucoup de requêtes, il ne faut pas hésiter à augmenter la taille de la Shared Pool
à 300 Mo ou plus.
Si le partage des requêtes est mauvais, avoir une Shared Pool trop importante n’apportera rien, voire dégradera les
performances (l’instance passant beaucoup de temps, en vain, à chercher une requête identique en mémoire).
Si vous utilisez le Database Control, il faut augmenter la taille de la Shared Pool (au moins 80 Mo).
Exemple :
SHARED_POOL_SIZE = 128M
JAVA_POOL_SIZE
Taille en octets de la Java Pool. Peut être spécifiée en octets, en Ko (symbole K), en Mo (symbole M) ou en Go
(symbole G). La valeur peut être arrondie par Oracle au granule supérieur.
Si le réglage automatique de la mémoire partagée est activé (SGA_TARGET ou MEMORY_TARGET différent de zéro), ce
paramètre fixe une taille minimale pour la Java Pool. S’il n’est pas spécifié, la valeur 0 lui est attribuée et la taille de la
Java Pool est ajustée en interne par Oracle.
Si le réglage automatique de la mémoire partagée est désactivé (SGA_TARGET ou MEMORY_TARGET égal à zéro), ce
paramètre fixe la taille de la Java Pool. S’il n’est pas spécifié, sa valeur par défaut est de 24 Mo.
Si vous n’utilisez pas la machine virtuelle Java intégrée au serveur Oracle (pour développer des procédures stockées
- 4-
© ENI Editions - All rights reserved - Algeria Educ
en Java par exemple), vous pouvez mettre ce paramètre à zéro.
Exemple :
JAVA_POOL_SIZE = 0
LARGE_POOL_SIZE
Taille en octets de la Large Pool. Peut être spécifiée en octets, en Ko (symbole K), en Mo (symbole M) ou en Go
(symbole G). La valeur peut être arrondie par Oracle au granule supérieur.
Si le réglage automatique de la mémoire partagée est activé (SGA_TARGET ou MEMORY_TARGET différent de zéro), ce
paramètre fixe une taille minimale pour la Large Pool. S’il n’est pas spécifié, la valeur 0 lui est attribuée et la taille de
la Large Pool est ajustée en interne par Oracle.
Si le réglage automatique de la mémoire partagée est désactivé (SGA_TARGET ou MEMORY_TARGET égal à zéro), ce
paramètre fixe la taille de la Large Pool. S’il n’est pas spécifié, sa valeur par défaut est dérivée de la valeur d’autres
paramètres.
Les besoins en Large Pool dépendent énormément de l’application et des fonctionnalités utilisées (exécution parallèle
des requêtes, serveurs partagés, etc). Il peut être facilement audité ultérieurement et modifié en cas de besoin
(sans arrêter la base car le paramètre est dynamique).
Exemple :
LARGE_POOL_SIZE = 64M
DB_CACHE_SIZE
Taille du Database Buffer Cache pour la taille de bloc standard (pool standard). Peut être spécifiée en octets, en Ko
(symbole K), en Mo (symbole M) ou en Go (symbole G). La valeur peut être arrondie par Oracle au granule supérieur.
Si le réglage automatique de la mémoire partagée est activé (SGA_TARGET ou MEMORY_TARGET différent de zéro), ce
paramètre fixe une taille minimale pour le Database Buffer Cache. S’il n’est pas spécifié, la valeur 0 lui est attribuée et
la taille du DatabaseBuffer Cache est ajustée en interne par Oracle.
Si le réglage automatique de la mémoire partagée est désactivé (SGA_TARGET ou MEMORY_TARGET égal à zéro), ce
paramètre fixe la taille du Database Buffer Cache. S’il n’est pas spécifié, sa valeur par défaut est de 48 Mo (ou 4 Mo
multiplié par le nombre de CPU, si cette valeur est plus grande).
Il n’y a pas de règle simple ni de formule de calcul pour déterminer la taille du Database Buffer Cache. Les besoins
dépendent énormément de l’application. Par contre, il peut être facilement audité ultérieurement et modifié en cas de
besoin (sans arrêter la base car le paramètre est dynamique).
Le Database Buffer Cache est souvent la composante la plus importante de la SGA (les deux tiers ou plus).
Pour une petite base avec peu d’utilisateurs, une taille de 128 à 256 Mo peut être suffisante. Pour les bases plus
volumineuses avec un nombre d’utilisateurs élevé, la taille peut monter à 1 Go ou plus.
Exemple :
DB_CACHE_SIZE = 640M
DB_nK_CACHE_SIZE
Taille en octets du Database Buffer Cache pour les blocs de n Ko (n valant 2, 4, 8, 16 ou 32, mais pas pour la taille de
bloc standard). Peut être spécifiée en octets, en Ko (symbole K), en Mo (symbole M) ou en Go (symbole G). La valeur
peut être arrondie par Oracle au granule supérieur.
Si la base de données utilise d’autres tailles de bloc que la taille standard, il faut utiliser ces paramètres pour
dimensionner des pools adaptés dans le Database Buffer Cache.
LOG_BUFFER
Taille en octets du Redo Log Buffer. Valeur par défaut : 512 Ko (ou 128 Ko multiplié par le nombre de CPU, si cette
valeur est plus grande). La valeur par défaut est généralement suffisante, d’autant plus que cette valeur est dans la
pratique supérieure à ce qui est annoncé dans la documentation.
Exemple :
LOG_BUFFER = 524288 # 512 Ko
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 5-
PGA_AGGREGATE_TARGET
Quantité de mémoire totale allouée à la PGA agrégée de tous les processus serveurs. Peut être spécifiée en octets,
en Ko (symbole K), en Mo (symbole M) ou en Go (symbole G). Valeur par défaut : 10 Mo, ou 20% de la taille de la SGA
si cette valeur est plus grande.
Si la gestion automatique de la mémoire est activée (MEMORY_TARGET est différent de zéro), ce paramètre fixe une
taille minimale pour la PGA cumulée ; s’il n’est pas spécifié, la valeur 0 lui est attribuée et la taille de la PGA est
ajustée en interne.
Si la gestion automatique de la mémoire est désactivée (MEMORY_TARGET est égal à zéro), ce paramètre fixe la taille de
la PGA cumulée.
Oracle alloue la mémoire aux différents processus serveurs en fonction de leur besoins, en essayant de maintenir la
taille totale cumulée de toutes les PGA en dessous de la limite définie par ce paramètre.
Plus ce paramètre est élevé, plus Oracle est capable d’allouer beaucoup de mémoire aux processus serveurs et plus
les processus serveurs sont capables de faire des opérations mémoire volumineuses (tri ou jointure par hachage par
exemple), sans faire de stockage temporaire sur disque (ce qui améliore évidemment les performances).
Il n’y a pas de règle simple ni de formule de calcul pour déterminer la valeur de ce paramètre. En général, dans un
système transactionnel les besoins en mémoire des processus serveurs sont faibles ; une valeur de l’ordre de 512
Ko à 1 Mo par session peut être suffisante. Par contre, dans un système décisionnel, les utilisateurs exécutent
souvent des requêtes qui effectuent des tris sur un gros volume de données ; dans ce cas, il faut compter au moins
10 Mo par session.
Exemple :
PGA_AGGREGATE_TARGET = 200M
STATISTICS_LEVEL
Niveau de collecte des statistiques sur la base de données et le système d’exploitation, utilisées notamment pour les
fonctionnalités de gestion automatique d’Oracle. Valeurs possibles : ALL, TYPICAL (valeur par défaut) et BASIC.
La valeur par défaut (TYPICAL) est adaptée pour la plupart des bases de données ; elle permet de bénéficier des
fonctionnalités de gestion automatique d’Oracle, avec un impact minimum sur le système. La valeur BASIC désactive
les fonctionnalités de gestion automatique d’Oracle. La valeur ALL permet de collecter plus de statistiques mais a un
impact important sur le système ; cette valeur peut être utilisée ponctuellement dans une session particulière, à des
fins d’optimisation.
Laissez la valeur par défaut !
Exemple :
STATISTICS_LEVEL = typical
OPEN_CURSORS
Détermine le nombre maximum de curseurs qui peuvent être ouverts simultanément par une session. Valeur par
défaut : 50.
Les besoins varient énormément d’une application à l’autre. Mettre une valeur trop élevée par rapport aux besoins
n’a pas d’incidence. Une valeur de 500 doit être suffisante pour un grand nombre d’applications.
Si une session atteint la limite, l’erreur ORA-01000: nombre maximum de curseurs ouverts dépassé est retournée.
Dans ce cas, sauf dysfonctionnement de l’application, augmentez la valeur du paramètre.
Exemple :
OPEN_CURSORS = 500
PROCESSES
Nombre maximum de processus qui peuvent se connecter simultanément à l’instance. Valeur par défaut : 100.
Comptez un pour chaque session utilisateur simultanée, plus un pour chaque processus d’arrière­plan (15 à 20 en
général), plus un certain nombre pour les sessions SYSMAN et DBSNMP utilisées par le Database Control (une dizaine
en général).
Pour connaître le nombre de processus d’arrière­plan lancés par l’instance, vous pouvez interroger la
vueV$BGPROCESS (filtrez sur paddr <> ’00’). Vous pouvez aussi interroger la vue<V$PROCESS pour connaître le nombre
total de processus démarrés par l’instance.
- 6-
© ENI Editions - All rights reserved - Algeria Educ
Si le nombre maximum de processus est atteint et qu’un utilisateur cherche à se connecter, il recevra le message
d’erreurORA-00020: nombre maximum de processus (NN) atteint, NN étant la valeur du paramètre.
Exemple :
PROCESSES = 200
SESSIONS
Détermine le nombre maximum de sessions qui peuvent être ouvertes dans l’instance. La valeur par défaut de ce
paramètre est dérivée de la valeur du paramètrePROCESSES par la formule (1.1 * PROCESSES) + 5. Cette valeur par
défaut est aussi la valeur minimale du paramètre.Ce paramètre doit être considéré dans une configuration serveurs
partagés où le nombre de processus peut être faible, mais le nombre de sessions élevé. Dans une configuration
serveurs dédiés, ce paramètre peut être ignoré si le paramètre PROCESSES a été défini.
Exemple :
SESSIONS = 300
SHARED_SERVERS
Spécifie le nombre de processus serveurs partagés qui sont créés lorsque l’instance démarre (0 par défaut). Indiquer
une valeur différente de zéro, active la fonctionnalité de serveurs partagés. Laissez cette valeur à zéro pour être en
configuration serveurs dédiés (configuration à utiliser a priori, sauf si le nombre d’utilisateurs simultanés est vraiment
très élevé).
Exemple :
SHARED_SERVERS = 20
JOB_QUEUE_PROCESSES
Nombre maximum de processus qui peuvent être lancés pour exécuter des tâches automatiques (calcul de
statistiques, rafraîchissement d’une vue matérialisée, etc.). Valeurs possibles : entre 0 et 1000 (valeur par défaut).
La valeur de ce paramètre doit être supérieure au nombre de tâches susceptibles de s’exécuter en parallèle.
Laissez la valeur par défaut !
NLS_LANGUAGE
Langage par défaut de l’instance, utilisé pour les messages, les noms de jour et de mois et le tri. Détermine aussi la
valeur des paramètres NLS_DATE_LANGUAGE et NLS_SORT. La valeur par défaut est dérivée de la variable
d’environnement NLS_LANG.
Exemple :
NLS_LANGUAGE = french
NLS_TERRITORY
Territoire par défaut de l’instance, utilisé pour la numérotation des jours et des semaines. Détermine aussi la valeur
par défaut des formats de date, des séparateurs numériques et des symboles monétaires.
Exemple :
NLS_TERRITORY = france
UNDO_MANAGEMENT
Mode de gestion souhaité pour les segments d’annulation. Les valeurs possibles sont MANUAL pour la gestion
manuelle et AUTO (par défaut) pour la gestion automatique.La gestion automatique des segments d’annulation est
présentée en détail dans le chapitre Gestion des informations d’annulation. Ce mode de gestion est vraiment très
intéressant et doit être utilisé. Il peut être activé dès la création de la base en mettant le paramètre
UNDO_MANAGEMENT à AUTO et en créant un tablespace d’annulation dans l’ordre SQL CREATE DATABASE (voir la section
Création de la base de données dans ce chapitre).
Exemple :
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 7-
UNDO_MANAGEMENT = auto
UNDO_TABLESPACE
Nom du tablespace d’annulation à utiliser par défaut lors du démarrage de l’instance. Si ce paramètre n’est pas
renseigné, l’instance utilise le premier tablespace d’annulation qu’elle trouve (cf. Chapitre Gestion des informations
d’annulation).
DIAGNOSTIC_DEST
Répertoire de base du Référentiel de Diagnostic Automatique (cf. section Diagnostiquer les problèmes du chapitre
Les outils d’administration). Ce paramètre est apparu en version 11. Egal, par défaut, à la valeur de la variable
d’environnement ORACLE_BASE ; si cette variable n’est pas définie, il est égal par défaut, au sous­répertoire log du
répertoire Oracle Home.
Arrangez­vous pour que ce paramètre soit égal au répertoire de base d’Oracle, soit en définissant la
variable d’environnement ORACLE_BASE, soit en définissant le paramètre.
Exemple
DIAGNOSTIC_DEST = d:\app\oracle
DB_RECOVERY_FILE_DEST
Emplacement de la zone de récupération rapide (flash recovery area). Si ce paramètre est spécifié, il faut aussi
spécifier le paramètre DB_RECOVERY_FILE_DEST_SIZE. Voir le chapitre Sauvegarde et récupération pour plus
d’informations sur le fonctionnement et le rôle de la zone de récupération rapide. Ce paramètre est apparu en
version 10.
Exemple :
DB_RECOVERY_FILE_DEST = h:\oracle\flash_recovery_area
DB_RECOVERY_FILE_DEST_SIZE
Taille maximale autorisée pour l’ensemble des fichiers stockés dans la zone de récupération rapide. Peut être
spécifiée en octets, Ko (symbole K), en Mo (symbole M) ou en Go (symbole G). Ce paramètre est apparu en version
10.
Exemple :
DB_RECOVERY_FILE_DEST_SIZE = 20G
LOG_ARCHIVE_DEST et LOG_ARCHIVE_DUPLEX_DEST
Spécifient une ou deux destinations pour l’archivage des fichiers de journalisation (Standard Edition). Voir le chapitre
Sauvegarde et récupération pour plus d’informations sur l’archivage des fichiers de journalisation.
Exemple :
LOG_ARCHIVE_DEST = h:\oracle\arch\HERMES
LOG_ARCHIVE_DEST_n
Spécifie une ou plusieurs destinations pour l’archivage des fichiers de journalisation (Enterprise Edition). n est
compris entre 1 et 10. Voir le chapitre Sauvegarde et récupération pour plus d’informations sur l’archivage des
fichiers de journalisation.
Exemple :
LOG_ARCHIVE_DEST_1 = "LOCATION=h:\oracle\arch\HERMES"
LOG_ARCHIVE_FORMAT
Définit le format du nom des archives des fichiers de journalisation. Doit inclure les variables %T, %S et %R donnant
respectivement le numéro de l’instance (thread), le numéro de séquence du fichier de journalisation et un identifiant
- 8-
© ENI Editions - All rights reserved - Algeria Educ
d’incarnation. Voir le chapitre Sauvegarde et récupération pour plus d’informations sur ces variables.
Exemple :
LOG_ARCHIVE_FORMAT = redo_%T_%S_%R.arc
REMOTE_LOGIN_PASSWORDFILE
À positionner selon la stratégie adoptée pour l’identificationSYSDBA (cf. section L’administrateur de base de données
du chapitre Les bases de l’architecture Oracle). Valeurs possibles :
●
NONE : pas de fichier de mot de passe ; seule l’authentification par le système d’exploitation est active.
●
EXCLUSIVE : utilisation d’un fichier de mot de passe dédié à la base de données.
●
SHARED : utilisation d’un fichier de mot de passe partagé entre plusieurs bases de données.
Avec un fichier de mot de passe, par défaut, seul le compte SYS a le droit de se connecter avec le privilège SYSDBA ou
SYSOPER. Si le paramètre REMOTE_LOGIN_PASSWORDFILE est égal à EXCLUSIVEde>, il est possible de donner le privilège
SYSDBA ou SYSOPER à d’autres utilisateurs (dans la limite d’un nombre maximum d’utilisateurs indiqué lors de la
création du fichier de mot de passe). Si le paramètre REMOTE_LOGIN_PASSWORDFILE est égal à SHARED, seul le compte
SYS peut utiliser les privilèges SYSDBA ou SYSOPER.
Exemple :
REMOTE_LOGIN_PASSWORDFILE = exclusive
SEC_CASE_SENSITIVE_LOGON
Indique si les mots de passe sont sensibles à la casse (true, valeur par défaut) ou non (false). Ce paramètre est
apparu en version 11.
Laissez la valeur par défaut, sauf si cela pose un problème de compatibilité avec votre application.
Exemple
SEC_CASE_SENSITIVE_LOGON = true
c. Un exemple simple
Vous pouvez créer une base de données de démarrage, utilisant la gestion automatique de la mémoire, avec un
fichier de paramètre contenant très peu de paramètres.
Exemple :
DB_NAME = HERMES
COMPATIBLE = 11.1.0
CONTROL_FILES = ("d:\oracle\oradata\HERMES\control01.ctl",
"d:\oracle\oradata\HERMES\control02.ctl")
DB_BLOCK_SIZE = 8192
MEMORY_TARGET = 512M
DB_RECOVERY_FILE_DEST = d:\oracle\flash_recovery_area
DB_RECOVERY_FILE_DEST_SIZE = 20G
Pour les autres paramètres, les valeurs par défaut sont satisfaisantes, au moins dans un premier temps.
3. Créer le service associé à l’instance ou créer le fichier de mot de passe
a. Créer le service associé à l’instance (plate­forme Windows)
Sur plate­forme Windows, il faut créer le service associé à l’instance ; selon les options utilisées, cette étape permet
aussi de créer le fichier de mot de passe utilisé pour l’authentification SYSDBA.
Le service est créé à l’aide de l’utilitaire oradim.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 9-
Syntaxe simplifiée
ORADIM -NEW -SID sid [-SYSPWD mot_de_passe] [-MAXUSERS nombre]
[-STARTMODE auto|manual] [-SRVCSTART system|demand]
[-PFILE fichier] [-SPFILE]
[-SHUTMODE normal|immediate|abort] [-TIMEOUT durée]
Avec
-SID sid
SID de la nouvelle instance.
-SYSPWD mot_de_passe
Mot de passe de SYS pour le privilège SYSDBA. La présence de cette option crée le fichier de mot de passe, ce qui
permet d’avoir une authentification SYSDBA par fichier de mot de passe. L’option peut être omise en cas d’utilisation
d’une authentification SYSDBA par le système d’exploitation. Ne pas oublier de positionner le paramètre
REMOTE_LOGIN_PASSWORDFILEen conséquence (cf. section L’administrateur de base de données du chapitre Les bases
de l’architecture Oracle).
-MAXUSERS nombre
Indique le nombre d’utilisateurs qui pourront recevoir le privilège SYSDBA ou SYSOPER et qui seront enregistrés dans le
fichier de mot de passe. Nécessite l’utilisation d’un fichier de mot de passe (option précédente).
-STARTMODE auto | manual
Précise le mode de démarrage souhaité pour l’instance :
­ auto : l’instance est démarrée lorsque le service démarre (paramètre ORA_<SID>_ AUTOSTART = TRUE dans la base
de registre).
­ manual (par défaut) : l’instance n’est pas démarrée lorsque le service démarre (paramètre ORA_<SID>_AUTOSTART =
FALSE dans la base de registre).
-SRVCSTART system | demand
Précise le mode de démarrage souhaité pour le service :
­ system : le service est en redémarrage automatique.
­ demand (par défaut) : le service est en redémarrage manuel.
-SPFILE
Indique que l’instance n’utilise pas explicitement de fichier de paramètres texte pour le démarrage automatique.
Dans ce cas, lors d’un démarrage automatique, la séquence de recherche d’un fichier paramètres s’effectue comme
indiquée dans la section Démarrage du chapitre Démarrage et arrêt ­ La commande STARTUP. Option par défaut si
l’option ­PFILE n’est pas spécifiée.
-PFILE fichier
Chemin d’accès complet au fichier de paramètres texte à utiliser explicitement pour le démarrage automatique (pas
de séquence de recherche de fichier de paramètres). Ne pas mettre cette clause si vous utilisez un fichier de
paramètres serveur (recommandé).
-SHUTMODE normal | immediate |abort
Type d’arrêt effectué sur l’instance lorsque le service s’arrête (voir les options de la commande STARTUP dans la
section Démarrage du chapitre Démarrage et arrêt ­ La commande STARTUP). Est enregistré dans le paramètre
ORA_<SID>_AUTOSTART = FALSE de la base de registre.
-TIMEOUT durée
Délai (en secondes) accordé à l’instance pour s’arrêter avant l’arrêt du service (qui est alors équivalent à un
- 10 -
© ENI Editions - All rights reserved - Algeria Educ
SHUTDOWN ABORT). Est enregistré dans le paramètre ORA_<SID>_SHUTDOWN_TIMEOUT de la base de registre. 90 secondes
par défaut.
ORADIM -NEW crée et démarre le serviceOracleService<SID>. Il crée aussi le service OracleJobScheduler<SID> utilisé
par l’ordonnanceur Oracle (scheduler) pour lancer des travaux au niveau du système d’exploitation ; par défaut, ce
service est désactivé.
Pour les options -STARTMODE, -SHUTMODE et -SRVCSTART, la première lettre des valeurs suffit (STARTMODE a, par
exemple).
Exemple :
C:\>oradim -new -sid HERMES -syspwd wX#12 -startmode a -srvcstart s -spfile
Instance créée.
C:\>
Cet exemple crée un service avec toutes les options qui permettent d’avoir un redémarrage automatique. Un fichier
de paramètres serveur est utilisé et l’authentificationSYSDBA par un fichier de mot de passe est possible (en plus de
l’authentification par le système d’exploitation).
D’une manière plus générale, l’utilitaire ORADIM permet de gérer le service associé à l’instance, notamment de
modifier certains paramètres ou de le supprimer (suite à la suppression d’une base par exemple).
Taper simplement ORADIM sur la ligne de commande permet d’obtenir l’aide de l’outil.
L’option -EDIT de ORADIM permet de modifier les caractéristiques du service et de l’instance, notamment d’activer ou
de désactiver le démarrage automatique.
Syntaxe simplifiée
ORADIM -EDIT -SID sid
[-SYSPWD mot_de_passe] [-MAXUSERS nombre]
[-STARTMODE auto| manual ] [-SRVCSTART system| demand ]
[-PFILE fichier] [-SPFILE]
[-SHUTMODE normal| immediate |abort] [-TIMEOUT durée]
Les clauses sont les mêmes que pour la création.
b. Créer le fichier de mot de passe (plate­forme Unix/Linux)
Sur plate­forme Unix ou Linux, il n’y a pas de notion de service associé à l’instance. Par contre, il peut être nécessaire
de créer le fichier de mot de passe utilisé pour l’authentification SYSDBA.
Le fichier de mot de passe est créé à l’aide de l’utilitaire orapwd.
Cet utilitaire existe aussi sur plate­forme Windows. Il permet de créer ou de recréer le fichier de mot de
passe sans utiliser oradim.
Syntaxe
ORAPWD FILE=fichier PASSWORD=mot_de_passe ENTRIES=nombre
FORCE=y|n IGNORECASE=y|n
Avec
FILE=fichier
Chemin complet vers le fichier de mot de passe à créer.
PASSWORD=mot_de_passe
Mot de passe de SYS pour le privilège SYSDBA.
ENTRIES=nombre
Indique le nombre d’utilisateurs qui pourront recevoir le privilège SYSDBA ou SYSOPER et qui seront enregistrés dans le
fichier de mot de passe.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 11 -
FORCE=y|n
Mettre y pour forcer la suppression préalable du fichier s’il existe déjà (utile en cas de recréation du fichier de mot de
passe).
IGNORECASE=y|n
Mettre y pour avoir un mot de passe non sensible à la casse et n (valeur par défaut) pour avoir un mot de passe
sensible à la casse. Apparu en version 11. Avant la version 11, le mot de passe n’était pas sensible à la casse.
Aucun espace ne doit être présent autour du signe =.
Exemple :
ORACLE_SID=HERMES
PWFILE=$ORACLE_HOME/dbs/orapw$ORACLE_SID
orapwd file=$PWFILE password=wX#12 entries=4
Sur plate­forme Unix ou Linux, le fichier de mot de passe s’appelle généralement orapw<SID> (<SID> désignant le nom
de l’instance) et est situé dans le répertoire $ORACLE_HOME/dbs.
Sur plate­forme Windows, le fichier de mot de passe s’appelle généralement pwd<SID>.ora (<SID> désignant le nom
de l’instance) et est situé dans le répertoire %ORACLE_HOME%\database.
Si le fichier de mot de passe existe déjà, vous obtiendrez une erreur ; pour recréer un fichier de mot de passe, il faut
supprimer manuellement le précédent ou utiliser l’option FORCE.
N’oubliez pas de positionner le paramètreREMOTE_LOGIN_PASSWORDFILE en conséquence
L’administrateur de base de données du chapitre Les bases de l’architecture Oracle).
(section
4. Lancer SQL*Plus et se connecter AS SYSDBA
Maintenant que les étapes à réaliser au niveau du système d’exploitation sont terminées, nous pouvons lancer
SQL*Plus et nous connecter AS SYSDBA.
Pour cela :
●
Positionner la variable d’environnement ORACLE_SID au niveau du système d’exploitation :
●
Sur plate­forme Windows (possible aussi dans la base de registre) :
set ORACLE_SID=HERMES
●
Sur plate­forme Unix ou Linux (à adapter en fonction du shell) :
export ORACLE_SID=HERMES
●
Démarrer SQL*Plus sans se connecter :sqlplus /nolog
●
Se connecter AS SYSDBA :
●
Authentifié par le système d’exploitation :
CONNECT / AS SYSDBA
●
Authentifié par un fichier de mot de passe :
CONNECT sys/wX#12 AS SYSDBA
- 12 -
© ENI Editions - All rights reserved - Algeria Educ
5. Créer le fichier de paramètres serveur
La création d’un fichier de paramètres serveur s’effectue à partir d’un fichier de paramètres texte, grâce à l’ordre SQL
CREATE SPFILE.
Syntaxe :
CREATE SPFILE [ = ’nom_spfile’ ] FROM PFILE [ = ’nom_pfile’ ] ;
Avec :
nom_spfile
Chemin d’accès complet (sur le serveur) et nom du fichier de paramètres serveur à créer. Si non spécifié, un nom par
défaut et un emplacement par défaut sont utilisés (dépend de la plate­forme).
nom_pfile
Chemin d’accès complet (sur le serveur) et nom du fichier de paramètres texte d’origine. Si non spécifié, un nom par
défaut et un emplacement par défaut sont utilisés (dépend de la plate­forme).
Exemple :
SQL> CREATE SPFILE FROM
2 PFILE = ’d:\app\oracle\admin\HERMES\pfile\init.ora’;
Fichier créé.
Cette opération nécessite une connexion SYSDBA ou SYSOPER. Si le fichier de paramètres serveur existe déjà, il est
remplacé.
Le nom et l’emplacement par défaut du fichier de paramètres serveur est le suivant :
●
%ORACLE_HOME%\database\spfile<SID>.ora (Windows) ;
●
$ORACLE_HOME/dbs/spfile<SID>.ora (Unix/Linux).
Utiliser le nom et l’emplacement par défaut facilite l’administration ultérieure de la base, notamment le démarrage (voir
le chapitre Démarrage et arrêt).
Le nom et l’emplacement par défaut du fichier de paramètres texte est le suivant :
●
%ORACLE_HOME%\database\init<SID>.ora (Windows) ;
●
$ORACLE_HOME/dbs/init<SID>.ora (Unix/Linux).
Dans ce chapitre, titre Création de la base de données à la main, section Préparer un nouveau fichier de paramètres
texte, nous avons préconisé de ne pas créer de fichier de paramètres texte à l’emplacement par défaut. En
conséquence, dans l’ordre SQL CREATE SPFILE, il faut donc spécifier l’emplacement du fichier de paramètres texte
utilisé comme source (c’est la seule fois !).
Si le fichier de paramètres texte contient une erreur de syntaxe (nom de paramètre erroné, parenthèse absente ou
surnuméraire, guillemet ou apostrophe absent ou surnuméraire, etc.), l’ordre CREATE SPFILE va échouer :
●
Nom de paramètre erroné : LRM-00101: unknown parameter name ...
●
Syntaxe (parenthèse, guillemet, etc.) : LRM-00116: syntax error at ...
●
Chemin du fichier texte : LRM-00109: could not open parameter file ...
Corrigez le fichier de paramètres texte et recommencez. Bien noter qu’à ce stade, les valeurs des paramètres ne sont
pas vérifiées ; elles seront vérifiées au démarrage de l’instance. La création du fichier de paramètres serveur peut
s’effectuer ultérieurement. Personnellement, je préconise de le créer dès le début ; ainsi, dès le premier démarrage de
l’instance, le fichier de paramètres serveurs est utilisé, ce qui permet si besoin de faire des modifications dynamiques
de paramètres en les rendant persistantes dans le fichier de paramètres (cf. Chapitre Gestion de l’instance).
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 13 -
6. Démarrer l’instance
L’instance peut maintenant être démarrée, en NOMOUNT puisque la base de données n’existe pas encore :
SQL> STARTUP NOMOUNT
Instance ORACLE lancée.
...
Si le fichier de paramètres texte contient une erreur de valeur sur un paramètre (valeur en dehors de la plage
autorisée, mauvais chemin, etc.), la commande STARTUP NOMOUNT va échouer. Corrigez le fichier de paramètres texte,
recréez le fichier de paramètres serveur et recommencez. Bien noter qu’à ce stade, les valeurs de tous les paramètres
ne sont pas vérifiées ; certaines seront vérifiées ultérieurement (par exemple lors de l’exécution de l’ordre SQL CREATE
DATABASE).
7. Créer la base de données
a. L’ordre SQL CREATE DATABASE
L’ordre SQL CREATE DATABASE permet de créer la base de données.
Syntaxe :
CREATE DATABASE [nom_base]
[ USER SYS IDENTIFIED BY mot_de_passe ]
[ USER SYSTEM IDENTIFIED BY mot_de_passe ]
[ CONTROLFILE REUSE ]
[ SET DEFAULT { BIGFILE | SMALLFILE } TABLESPACE ]
[ DATAFILE spécification_fichier [,...] ]
[ EXTENT MANAGEMENT LOCAL ]
[ SYSAUX DATAFILE spécification_fichier [,...] ]
[[ BIGFILE | SMALLFILE ] UNDO TABLESPACE nom
[ DATAFILE spécification_fichier [,...] ] ]
[[ BIGFILE | SMALLFILE ] DEFAULT TEMPORARY TABLESPACE nom
[ TEMPFILE spécification_fichier [,...] ]
[ EXTENT MANAGEMENT LOCAL ] [ UNIFORM [ SIZE valeur [K|M|G|T] ] ] ]
[ DEFAULT TABLESPACE nom
[ DATAFILE spécification_fichier [,...] ]
[ clause_extent_management ] ]
[ LOGFILE [GROUP numéro] spécification_fichier_redo [,...] ]
[ ARCHIVELOG | NOARCHIVELOG ]
[ FORCE LOGGING ]
[ CHARACTER SET jeu ]
[ NATIONAL CHARACTER SET jeu ]
[ SET TIME_ZONE = { ’+|- hh:mi’ | ’region’ } ]
[ MAXINSTANCES nombre ]
[ MAXLOGFILES nombre ]
[ MAXLOGMEMBERS nombre ]
[ MAXDATAFILES nombre ] ;
Avec :
- spécification_fichier
’nom_fichier’ [ SIZE valeur [K|M|G|T] ] [REUSE]
[ clause_auto_extend ]
- clause_auto_extend
AUTOEXTEND OFF
| AUTOEXTEND ON [ NEXT valeur [K|M|G|T] ]
[ MAXSIZE UNLIMITED | valeur [K|M|G|T] ]
- clause_extent_management
EXTENT MANAGEMENT DICTIONARY
| EXTENT MANAGEMENT LOCAL
{ AUTOALLOCATE | UNIFORM [ SIZE valeur [K|M|G|T] ] }
- spécification_fichier_redo
(’nom_fichier’ [,...]) [ SIZE valeur [K|M|G] ] [REUSE]
- 14 -
© ENI Editions - All rights reserved - Algeria Educ
Exemple :
CREATE DATABASE hermes
USER SYS IDENTIFIED BY wX#12
USER SYSTEM IDENTIFIED BY az#78
SET DEFAULT SMALLFILE TABLESPACE
DATAFILE ’&chemin\system01.dbf’ SIZE 200M
AUTOEXTEND ON NEXT 10M
EXTENT MANAGEMENT LOCAL
SYSAUX DATAFILE ’&chemin\sysaux01.dbf’ SIZE 100M
AUTOEXTEND ON NEXT 10M
LOGFILE
GROUP 1
(’&chemin\redo01a.log’,
’&chemin\redo01b.log’) SIZE 50M,
GROUP 2
(’&chemin\redo02a.log’,
’&chemin\redo02b.log’) SIZE 50M,
GROUP 3
(’&chemin\redo03a.log’,
’&chemin\redo03b.log’) SIZE 50M
SMALLFILE UNDO TABLESPACE undotbs
DATAFILE ’&chemin\undotbs01.dbf’ SIZE 100M
AUTOEXTEND ON NEXT 10M MAXSIZE 1024M
SMALLFILE DEFAULT TEMPORARY TABLESPACE temp
TEMPFILE ’&chemin\temp01.dbf’ SIZE 100M
AUTOEXTEND ON NEXT 10M MAXSIZE 1024M
DEFAULT TABLESPACE deftbs
DATAFILE ’&chemin\deftbs01.dbf’ SIZE 10M
AUTOEXTEND ON NEXT 10M MAXSIZE 500M
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
NOARCHIVELOG
CHARACTER SET WE8ISO8859P15
NATIONAL CHARACTER SET AL16UTF16
SET TIME_ZONE = ’Europe/Paris’
MAXINSTANCES 1
MAXLOGFILES 16
MAXLOGMEMBERS 4
MAXDATAFILES 128
/
Cet exemple utilise une variable de substitution &chemin pour le chemin des fichiers de la base de données ; cette
variable est définie au préalable dans SQL*Plus, avec la syntaxe DEFINE chemin=....
L’ordre SQL CREATE DATABASE dure quelques minutes.
L’ordre SQL CREATE DATABASE crée la nouvelle base de données, en l’occurrence :
●
création des fichiers de contrôle ;
●
création des fichiers de journalisation ;
●
création du tablespace SYSTEM et de son fichier de données ;
●
création du tablespace SYSAUX et de son fichier de données ;
●
création du dictionnaire de données (dans le tablespace SYSTEM) ;
●
création d’un segment d’annulation (nommé SYSTEM stocké dans le tablespace SYSTEM) ;
●
création des comptes SYS et SYSTEM (entre autres) ;
●
création éventuelle d’un tablespace d’annulation, d’un tablespace temporaire par défaut et d’un tablespace
permanent par défaut.
À l’arrivée, la base de données est ouverte et parfaitement opérationnelle. Par contre, les vues et synonymes du
dictionnaire de données ne sont pas créés et le dictionnaire est donc peu exploitable. La finalisation de la création
du dictionnaire est décrite dans le point Finaliser la création du dictionnaire ci­après.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 15 -
Toutes les structures stockées dans le tablespace SYSTEM sont créées grâce au script sql.bsq qui se trouve dans le
répertoire %ORACLE_HOME%\rdbms\admin ou $ORACLE_HOME/rdbms/admin.
En ce qui concerne les fichiers de la base de données, les recommandations de nommage sont les suivantes :
Fichier de contrôle
controlnn.ctl, nn étant un numéro d’ordre (01, 02, etc.).
Fichier de journalisation
redonn.log, nn, nn étant le numéro du groupe (01, 02, etc.).
Fichiers de données
tablespacenn.dbf, tablespace étant le nom du tablespace et nn le numéro d’ordre du fichier au sein du tablespace
(01, 02, etc.).
Si l’ordre SQL CREATE DATABASE échoue pour une raison ou pour une autre, il est possible que plusieurs des fichiers
de la base de données aient déjà été créés. Dans ce cas, avant de relancer la création, il faut supprimer les fichiers
déjà créés (sous peine que le CREATE DATABASE échoue de nouveau, mais cette fois parce que des fichiers existent
déjà).
Les causes d’un échec de la création d’une base de données peuvent être multiples :
●
manque d’espace ;
●
chemin erroné pour un fichier (Oracle ne crée par les répertoires, ils doivent déjà exister) ;
●
etc.
Si le message d’erreur affiché à l’écran est sibyllin (du genre ORA-01092: instance ORACLE interrompue. Déconnexion
imposée), consultez le fichier d’alerte de l’instance qui vous donnera (normalement) des informations détaillées sur la
nature du problème.
b. Options de l’ordre SQL CREATE DATABASE
Toutes les clauses de l’ordre SQL CREATE DATABASE sont optionnelles et ont des valeurs par défaut. Dans la pratique,
il est préférable de les spécifier toutes (ou presque) afin de bien contrôler les caractéristiques de la nouvelle base.
nom_base
Nom de la base de données. Par défaut égal au paramètre DB_NAME. Provoque une erreur si le nom indiqué ici est
différent de la valeur du paramètre DB_NAME.
USER { SYS | SYSTEM } IDENTIFIED BY
Exemple :
USER SYS IDENTIFIED BY wX#12
USER SYSTEM IDENTIFIED BY az#78
Ces deux clauses permettent de changer les mots de passe de SYS et SYSTEM dès la création de la base de données.
Bien noter que ces deux clauses ne sont pas obligatoires (mais risquent de le devenir dans une version ultérieure).
Par contre, si l’une est spécifiée, l’autre doit l’être aussi. Si ces clauses ne sont pas spécifiées, les mots de passe par
défaut sont attribués à SYS (change_on_install) et SYSTEM (manager).
CONTROLFILE REUSE
Si l’option est présente et qu’un des fichiers indiqués dans le paramètre CONTROL_FILES existe déjà, Oracle le réutilise
et l’écrase. Si l’option est absente, dans la même situation, un message d’erreur s’affiche et la création de la base
est stoppée.
Du point de vue de la sécurité, il est préférable de ne pas mettre cette option afin d’éviter d’écraser par mégarde un
fichier de contrôle utilisé par une autre base.
- 16 -
© ENI Editions - All rights reserved - Algeria Educ
SET DEFAULT { BIGFILE | SMALLFILE } TABLESPACE
Cette clause spécifie le type par défaut (BIGFILE ou SMALLFILE) des tablespaces créés lors de la création de la base
de données. Le type spécifié ici s’applique notamment aux tablespaces SYSTEM et SYSAUX, et ne peut pas être modifié
pour ces deux tablespaces. Si cette clause est omise, Oracle crée des tablespaces SMALLFILE par défaut.
Un tablespace BIGFILE est un tablespace qui ne comporte qu’un seul fichier de données qui peut contenir jusqu’à
2^32 blocs Oracle (plus de 4 milliards). Un tablespace SMALLFILE est le tablespace traditionnel d’Oracle, qui peut
comporter jusqu’à 1022 fichiers, chaque fichier pouvant contenir jusqu’à 2^22 blocs Oracle (plus de 4 millions). Les
tablespaces BIGFILE sont apparus en version 10.
Cette notion de tablespace BIGFILE est présentée plus en détail dans le chapitre Gestion des tablespaces et des
fichiers de données.
DATAFILE spécification_fichier [,...]
Exemple :
DATAFILE ’&chemin\system01.dbf’ SIZE 200M
AUTOEXTEND ON NEXT 10M
Cette clause permet de préciser l’emplacement, le nom et la taille d’un (ou éventuellement de plusieurs) fichiers de
données pour le tablespace SYSTEM.
La syntaxe est la suivante pour la spécification d’un fichier de données :
- spécification_fichier
’nom_fichier’ [ SIZE valeur [K|M|G|T] ] [REUSE]
[ clause_auto_extend ]
nom_fichier
Chemin d’accès complet au fichier de données, normalement dans un répertoire de données (oradata) pour
respecter le standard OFA.
SIZE
Taille initiale du fichier. La taille peut être omise uniquement si l’option REUSE est utilisée et que le fichier existe déjà.
REUSE
Si l’option est présente et que le fichier existe déjà, Oracle le réutilise et l’écrase. Si l’option est absente, dans la
même situation, un message d’erreur s’affiche et la création de la base de données est stoppée. Du point de vue de
la sécurité, il est préférable de ne pas mettre cette option afin d’éviter d’écraser par mégarde un fichier de données
utilisé par une autre base de données.
- clause_auto_extend
AUTOEXTEND OFF
| AUTOEXTEND ON [ NEXT valeur [K|M|G|T] ]
[ MAXSIZE UNLIMITED | valeur [K|M|G|T] ]
AUTOEXTEND
Indique si le fichier de données peut (ON) ou non (OFF) grossir une fois que tout l’espace initialement alloué est
complètement utilisé.
NEXT
Espace minimum alloué au fichier lors de l’extension.
MAXSIZE
Taille maximale du fichier, éventuellement non limitée (UNLIMITED).
La gestion des tablespaces et des fichiers de données sera présentée en détail dans le chapitre Gestion des
tablespaces et des fichiers de données.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 17 -
Pour le< tablespace SYSTEM, il faut prévoir un fichier de données d’au minimum 200 Mo (si aucune option particulière
n’est installée), et il est vivement conseillé de permettre à ce fichier de données de s’étendre en fonction des
besoins (clause AUTOEXTEND).
Toutes les tailles peuvent être exprimées en octet (pas de symbole), Ko (symbole K), Mo (symbole M), Go (symbole G)
ou To (symbole T). Les tailles en To ne sont autorisées que pour les tablespaces BIGFILE.
Le type (BIGFILE ou SMALLFILE) du tablespace SYSTEM est déterminé par la clause SET DEFAULT ... TABLESPACE
présentée précédemment. Un seul fichier de données peut être spécifié si le tablespace est de type BIGFILE.
EXTENT MANAGEMENT LOCAL
Cette clause indique que le tablespace SYSTEM doit être géré localement ; par défaut, il est géré par le dictionnaire.
La notion de tablespace géré localement sera présentée dans le chapitre Gestion des tablespaces et des fichiers de
données. Bien noter les conséquences (positives !) de cette clause :
●
Tous les tablespaces doivent être gérés localement (conseillé par Oracle).
●
Un tablespace temporaire par défaut doit être créé dès la création de la base (conseillé par Oracle).
●
Si la gestion automatique des segments d’annulation est activée (par défaut et conseillé par Oracle), un
tablespace d’annulation doit être créé dès la création de la base de données (conseillé par Oracle).
Il n’y a pas d’inconvénient (au contraire) à utiliser un tablespace SYSTEM géré localement !
SYSAUX DATAFILE spécification_fichier [,...]
Exemple :
SYSAUX DATAFILE ’&chemin\sysaux01.dbf’ SIZE 100M
AUTOEXTEND ON NEXT 10M
Cette clause permet de préciser l’emplacement, le nom et la taille d’un (ou éventuellement de plusieurs) fichiers de
données pour le tablespace SYSAUX (apparu en version 10).
La syntaxe de spécification du fichier de données est la même que le tablespace SYSTEM. Les caractéristiques du
tablespace SYSAUX seront présentées dans le chapitre Gestion des tablespaces et des fichiers de données.
Le type (BIGFILE ou SMALLFILE) du tablespace SYSAUX est déterminé par la clause SET DEFAULT ... TABLESPACE
présentée précédemment.
La taille du tablespace SYSAUX dépendra énormément des fonctionnalités utilisées dans la base de données (OLAP,
Oracle Text, Oracle interMedia, etc.). Si aucune option particulière n’est utilisée, une taille de départ de 100 Mo est
suffisante. En rythme de croisière, il faut compter 200 à 300 Mo pour le référentiel AWR (base comportant en
moyenne une trentaine de sessions actives) et environ 100 Mo pour le référentiel du Database Control (mais
l’espace utilisé par ces deux composants dépend de nombreux facteurs). Il est conseillé de permettre au fichier de
données du tablespace SYSAUX de s’étendre en fonction des besoins (clause AUTOEXTEND).
[ BIGFILE | SMALLFILE ] UNDO TABLESPACE ...
Exemple :
SMALLFILE UNDO TABLESPACE undotbs
DATAFILE ’&chemin\undotbs01.dbf’ SIZE 100M
AUTOEXTEND ON NEXT 10M MAXSIZE 1024M
Cette clause permet de créer un tablespace d’annulation qui est utilisé pour la gestion automatique des segments
d’annulation. Ce mode de gestion est intéressant et doit être utilisé dès la création de la base. La gestion
automatique des segments d’annulation sera présentée en détail dans le chapitre Gestion des informations
d’annulation.
La syntaxe pour spécifier les caractéristiques des fichiers de données de ce tablespace est la même que pour le
tablespace SYSTEM. La clause optionnelle BIGFILE ou SMALLFILE permet de préciser le type de tablespace ; si cette
clause est omise, le type est déterminé par la clause SET DEFAULT ... TABLESPACE présentée précédemment.
[ BIGFILE | SMALLFILE ] DEFAULT TEMPORARY TABLESPACE ...
Exemple :
- 18 -
© ENI Editions - All rights reserved - Algeria Educ
SMALLFILE DEFAULT TEMPORARY TABLESPACE temp
TEMPFILE ’&chemin\temp01.dbf’ SIZE 100M
AUTOEXTEND ON NEXT 10M MAXSIZE 1024M
Cette clause permet de créer un tablespace temporaire par défaut. Cette notion est intéressante et doit être mise
en œ uvre dès la création de la base de données. Le tablespace temporaire sera présenté en détail dans le chapitre
Gestion des tablespaces et des fichiers de données.
La syntaxe pour spécifier les caractéristiques des fichiers de données de ce tablespace, est la même que pour le
tablespace SYSTEM, mais en remplaçant le mot clé DATAFILE par TEMPFILE. La clause optionnelle BIGFILE ou SMALLFILE
permet de préciser le type de tablespace ; si cette clause est omise, le type est déterminé par la clause SET
DEFAULT ... TABLESPACE présentée précédemment.
DEFAULT TABLESPACE nom ...
Exemple :
DEFAULT TABLESPACE deftbs
DATAFILE ’&chemin\deftbs01.dbf’ SIZE 10M
AUTOEXTEND ON NEXT 10M MAXSIZE 500M
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
Cette clause permet de créer un tablespace permanent par défaut. Ce tablespace sera affecté par défaut, comme
tablespace par défaut des utilisateurs non "système" (autres que SYS, SYSTEM, etc.). Le tablespace par défaut d’un
utilisateur est le tablespace dans lequel Oracle stocke les segments créés par l’utilisateur si celui­ci n’a pas
mentionné explicitement de tablespace. Cette notion n’est pas fondamentale. Elle n’est réellement intéressante que
dans les bases de données où beaucoup d’utilisateurs, ayant le droit de créer des segments, devront être
gérés ; définir un tablespace permanent par défaut permet de simplifier la création des utilisateurs (chapitre Gestion
des utilisateurs et de leurs droits). Le tablespace permanent par défaut peut être défini ultérieurement. Le
tablespace permanent par défaut utilisé par défaut par Oracle est le tablespace SYSTEM ; cela ne présente pas de
risque vis­à­vis du tablespace SYSTEM, car les utilisateurs non DBA n’ont pas (normalement ­ c’est le cas par défaut)
de quota sur le tablespace SYSTEM, et ne peuvent pas y créer de segments (voir le chapitre Gestion des utilisateurs
et de leurs droits).
La syntaxe pour spécifier les caractéristiques des fichiers de données de ce tablespace est la même que pour le
tablespace SYSTEM. Le tablespace est obligatoirement de type SMALLFILE. La clause EXTENT MANAGEMENT sera
présentée dans le chapitre Gestion des tablespaces et des fichiers de données.
LOGFILE
Exemple :
LOGFILE
GROUP 1
GROUP 2
GROUP 3
(’&chemin\redo01a.log’,
’&chemin\redo01b.log’) SIZE 50M,
(’&chemin\redo02a.log’,
’&chemin\redo02b.log’) SIZE 50M,
(’&chemin\redo03a.log’,
’&chemin\redo03b.log’) SIZE 50M
Cette clause permet de préciser l’emplacement, le nombre et la taille des fichiers de journalisation (voir le chapitre
Les bases de l’architecture Oracle pour les principes d’organisation en groupes, composés de plusieurs membres).
La syntaxe est la suivante :
LOGFILE [GROUP numéro] spécification_fichier_redo [,...]
spécification_fichier_redo =
(’nom_fichier’ [,...]) [ SIZE valeur [K|M|G] ] [REUSE]
Avec :
numéro
Numéro du groupe. Si l’option est absente, Oracle numérote les groupes 1, 2, ... (ce qui est bien).
nom_fichier
Chemin d’accès complet à un fichier membre du groupe, normalement dans un répertoire de données (oradata) pour
respecter le standard OFA.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 19 -
SIZE
Taille de chaque membre du groupe en octet (pas de symbole), Ko (symbole K), Mo (symbole M) ou Go (symbole G). La
taille peut être omise uniquement si l’option REUSE est utilisée et que le fichier existe déjà.
REUSE
Si l’option est présente et que le fichier existe déjà, Oracle le réutilise et l’écrase. Si l’option est absente, dans la
même situation, un message d’erreur s’affiche et la création de la base de données est stoppée. Du point de vue de
la sécurité, il est préférable de ne pas mettre cette option afin d’éviter d’écraser par mégarde un fichier de données
utilisé par une autre base de données.
Vous devez spécifier au minimum deux groupes, composés chacun d’un membre. Du point de vue de la sécurité, il est
conseillé d’avoir au minimum deux membres par groupe, si possible sur des disques différents. Pour les
performances, il est aussi conseillé de mettre les fichiers de journalisation sur des disques dédiés (pour éviter les
contentions sur les entrées/sorties).
Compte tenu de la syntaxe, tous les membres d’un groupe ont forcément la même taille. Par contre, rien n’interdit
d’avoir des groupes de tailles différentes : cela ne présente aucun intérêt, sauf temporairement, durant une
opération de redimensionnement de la taille des fichiers de journalisation (chapitre Gestion des fichiers de contrôle
et des fichiers de journalisation).
Déterminer le nombre de groupes et la taille des groupes est un sujet complexe pour lequel il n’existe pas de formule
de calcul. Là encore, il est possible, a posteriori, d’auditer le fonctionnement des fichiers de journalisation afin de voir
si le nombre de groupes et la taille des groupes sont satisfaisants ; en cas de problème, il est relativement simple
d’apporter des corrections en ajoutant un nouveau groupe (c’est simple) ou en augmentant la taille des groupes
(c’est un peu plus compliqué). Nous verrons tout cela dans le détail dans le chapitre Gestion des fichiers de contrôle
et des fichiers de journalisation.
Pour démarrer, il est classique d’utiliser trois ou quatre groupes de fichiers de journalisation d’une taille comprise
entre 20 (petite activité transactionnelle) et 100 Mo (activité transactionnelle plus importante).
ARCHIVELOG | NOARCHIVELOG
Cette clause indique si la base de données fonctionne dans le mode ARCHIVELOG ou NOARCHIVELOG. Généralement, la
base est toujours créée en mode NOARCHIVELOG puis éventuellement passée ensuite en mode ARCHIVELOG. ; il n’est
en effet pas utile d’archiver les fichiers de journalisation remplis lors de la création de la base de données (en cas de
problème, il est plus simple de recréer la base). La mise en œ uvre de l’archivage après création de la base de
données est présentée dans le chapitre Sauvegarde et récupération.
FORCE LOGGING
Certains ordres SQL peuvent être exécutés en mode NOLOGGING, c’est­à­dire sans générer d’activité (ou presque pas)
dans les fichiers de journalisation. Cette technique est intéressante pour les performances (l’opération est plus
rapide) mais peut poser des problèmes pour la récupération : les opérations effectuées en NOLOGGING qui n’ont pas
été sauvegardées ne sont pas récupérables ; il faut les refaire (si c’est possible...).
La clause FORCE LOGGING de l’ordre SQL CREATE DATABASE met la base de données dans le mode FORCELOGGING, ce qui
permet de garantir que toutes les modifications seront enregistrées dans les fichiers de journalisation, même si
l’opération concernée est effectuée dans le mode NOLOGGING.
Dans la pratique, s’ôter la possibilité de réaliser certaines opérations dans le mode NOLOGGING est dommage, car cela
peut être très intéressant du point de vue des performances (pour la création des index par exemple). Il est
préférable de ne pas mettre la base de données dans le mode FORCE LOGGING et de bien contrôler les opérations
réalisées en NOLOGGING, et notamment de faire des sauvegardes après les opérations de ce genre si, celles­ci ne
peuvent pas être facilement refaites en cas d’incident.Cette propriété de la base de données peut être modifiée
ultérieurement par l’ordre SQL ALTER DATABASE [NO] FORCE LOGGING. Elle est enregistrée dans la colonne
FORCE_LOGGING de la vue V$DATABASE.
La clause FORCE LOGGING peut être positionnée sur un tablespace ce qui permet d’avoir un contrôle plus fin.
CHARACTER SET & NATIONAL CHARACTER SET
Exemple :
CHARACTER SET WE8ISO8859P15
La clause CHARACTER SET définit le jeu de caractères utilisé pour le stockage des données dans les colonnes de type
CHAR, VARCHAR2, LONG et CLOB.
- 20 -
© ENI Editions - All rights reserved - Algeria Educ
Le CHARACTER SET, bien qu’optionnel, doit être indiqué avec soin, car il n’est pas simple à changer ultérieurement ; la
valeur par défaut dépend de la plate­forme et de l’installation.
Pour l’Europe de l’ouest, les jeux de caractères WE8ISO8859P1 et WE8ISO8859P15 sont souvent utilisés car ils stockent
les caractères sur 8 bits et permettent donc de conserver les caractères accentués ; le deuxième jeu permet en plus
de stocker le symbole de l’euro. Une autre valeur usuelle est US7ASCII ; ce jeu de caractère anglo­saxon ne permet
pas de stocker les accents. Le jeu Unicode AL32UTF8 est aussi supporté et recommandé par Oracle.
La clause NATIONAL CHARACTER SET définit le jeu de caractères utilisé pour le stockage des données dans les
colonnes de type NCHAR, NVARCHAR2 et NCLOB.
Il est, lui aussi, délicat à changer ultérieurement. Le NATIONAL CHARACTER SET peut être omis si vous ne prévoyez pas
d’utiliser un deuxième jeu de caractères dans la base de données ; il est par défaut égal à AL16UTF16. Seuls les jeux
de caractères UTF8 et AL16UTF16 sont autorisés.
Les techniques de changement de jeu de caractères sont décrites dans la documentation Oracle® Database
Globalization Support Guide.
SET TIME_ZONE
Exemple :
SET TIME_ZONE = ’Europe/Paris’
Cette option permet de définir le fuseau horaire de la base. Ce fuseau horaire est utilisé par les types de données
TIMESTAMP WITH TIME ZONE et TIMESTAMP WITH LOCAL TIME ZONE. Si cette option n’est pas spécifiée, Oracle utilise le
fuseau horaire du système d’exploitation. Si le fuseau horaire du système d’exploitation n’est pas valide, Oracle
utilise le fuseau UTC. Le fuseau horaire peut être défini par une chaîne de la forme +|- hh:mi donnant le décalage
par rapport à l’heure universelle (+01:00 par exemple), ou par le nom d’une région (Europe/Paris par exemple). Vous
pouvez interroger la colonne TZNAME de la vue V$TIMEZONE_NAMES pour avoir la liste des noms de région.
MAXINSTANCES ­ MAXLOGFILES ­ MAXLOGMEMBERS ­ MAXDATAFILES
Exemple :
MAXINSTANCES 1
MAXLOGFILES 16
MAXLOGMEMBERS 4
MAXDATAFILES 128
Ces options permettent de limiter le nombre de fichiers de la base de données :
MAXLOGFILES
Nombre maximum de groupes de fichiers de journalisation.
MAXLOGMEMBERS
Nombre maximum de membres dans un groupe de fichiers de journalisation.
MAXDATAFILES
Nombre maximum de fichier de données.
Les valeurs minimales, par défaut, et maximales dépendent de la plate­forme.Ces paramètrent impactent
directement la taille des fichiers de contrôle car Oracle réserve le nombre d’entrées nécessaires dans les fichiers de
contrôle ; mettre des valeurs très grandes, "pour être tranquille", peut donc conduire à un fichier de contrôle
démesurément grand (plus de 10 Mo, contre moins de 10 Mo en temps normal). Mettre les valeurs suivantes permet,
en général, d’être tranquille, sans trop augmenter la taille du fichier de contrôle :
MAXLOGFILES
En général, une base utilise quatre ou cinq groupes, donc, mettre une valeur de l’ordre de 10 serait largement
suffisant ; malheureusement, MAXLOGFILES a une valeur minimum égale à deux fois celle d’une autre option,
MAXINSTANCES (intéressante uniquement avec l’option RAC), qui par défaut vaut 16 (soit un MAXLOGFILES minimum de
32 !). Le plus simple est soit de ne rien mettre (et la valeur par défaut, égale à la valeur minimum est largement
suffisante) soit de mettre 32 (ce qui revient au même) : qui peut le plus, peut le moins et l’espace gaspillé dans le
fichier de contrôle est négligeable. Une autre approche peut consister à donner une valeur à MAXINSTANCES (1 par
exemple) et à mettre MAXLOGFILES à une valeur de l’ordre de 10.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 21 -
MAXLOGMEMBERS
3 ou 4 (utiliser trois membres par groupe offre normalement un niveau de sécurité suffisant, si ces membres sont
situés sur des disques différents). 5 est souvent la valeur maximale autorisée pour cette option.
MAXDATAFILES
De l’ordre de 50 à 100 (éventuellement plus pour les très grosses bases). Classiquement, une base moyenne utilise
10 à 20 fichiers de données.
8. Finaliser la création du dictionnaire de données
Après l’exécution de l’ordre SQL CREATE DATABASE, la base de données est parfaitement opérationnelle, mais les vues
et les synonymes qui rendent le dictionnaire de données exploitable ne sont pas créés.
Pour créer ces vues et ces synonymes, vous devez exécuter (sous SYS) des scripts fournis par Oracle (dans %
ORACLE_HOME%\rdbms\admin ou $ORACLE_HOME/rdbms/admin) :
●
●
catalog.sql : vues et synonymes de base ;
catproc.sql : compléments pour les options procédurales (création d’un grand nombre de packages fournis
par Oracle).
Les scripts catalog.sql et catproc.sql appellent d’autres scripts.
Le passage de catalog et catproc dure environ 10 à 15 minutes.
D’autres fonctions particulières d’Oracle peuvent nécessiter l’exécution de scripts supplémentaires ; dans ce cas, le
script à lancer est clairement indiqué dans la documentation.
En règle générale, les scripts doivent être exécutés dans le schéma SYS (propriétaire du dictionnaire de données) et
donc avec une connexion AS SYSDBA. En cas de doute, ouvrez le script et regardez son en­tête ; la connexion à utiliser
est généralement indiquée.
En complément, vous pouvez exécuter (sous SYSTEM) le script pupbld.sqlsitué dans %ORACLE_HOME%\sqlplus\admin ou
$ORACLE_HOME/sqlplus/admin. Ce script est exécuté pour créer une table (PRODUCT_USER_PROFILE) dont la présence est
testée par les outils Oracle (SQL*Plus notamment) lors de la connexion d’un utilisateur. Si la table n’existe pas et que
l’utilisateur n’est pas un DBA, un message d’alerte est affiché (mais la connexion est acceptée).
Exécuter le script pupbld.sql permet d’éviter d’avoir ce message.
La table PRODUCT_USER_PROFILE peut être utilisée pour limiter la nature des ordres SQL qu’un utilisateur peut exécuter
avec les outils (par exemple, interdire l’utilisation de l’ordre UPDATE dans SQL*Plus). Pour en savoir plus, consulter la
documentation SQL*Plus® User’s Guide and Reference.
9. Configurer Oracle Net pour la nouvelle base de données
À ce stade, vous pouvez configurer Oracle Net pour la nouvelle base de données :
●
●
Modification de la configuration du processus d’écoute (fichier listener.ora) pour avoir un enregistrement
statique de l’instance.
Création d’un nom de service réseau (fichier tnsnames.ora) pour pouvoir se connecter à la base de données
sans devoir positionner la variable d’environnement ORACLE_SID.
Ces différentes configurations ont été présentées dans la section Configuration côté serveur du chapitre Oracle Net et
Configuration côté client du chapitre Oracle Net.
10. Enregistrer la nouvelle instance dans le fichier oratab
Sur plate­forme Unix ou Linux, il est intéressant d’enregistrer la nouvelle instance dans le fichier /etc/oratab, d’une
part, pour pouvoir changer facilement d’environnement avec l’utilitaire oraenv (voir la section Installation du serveur
du chapitre Installation), et d’autre part, pour bénéficier éventuellement du redémarrage automatique (voir la section
- 22 -
© ENI Editions - All rights reserved - Algeria Educ
Automatisation et scripts du chapitre Démarrage et arrêt).
Exemple :
HERMES:/u01/app/oracle/product/11.1.0/db_1:Y
11. Configurer le Database Control
L’environnement du Database Control (référentiel, arborescence de fichiers dans le répertoire Oracle Home service sur
plate­forme Windows) peut être créé grâce à l’utilitaire ligne de commande emca (Enterprise Manager Configuration
Assistant)Appelé sans option, l’utilitaire affiche une aide. Cet utilitaire propose un grand nombre d’options qui
permettent de configurer, reconfigurer, mettre à jour ou supprimer le Database Control.
Syntaxe simplifiée :
emca -config dbcontrol db [-repos {create | recreate}]
emca -deconfig dbcontrol db [-repos drop]
Le premier appel permet de configurer l’environnement complet. L’option -repos permet de créer ou recréer le
référentiel. Si cette option est absente, le référentiel est supposé déjà exister.
Le deuxième appel permet de supprimer la configuration. L’option -repos drop permet de supprimer le référentiel. Si
cette option est absente, le référentiel n’est pas supprimé.Pour reconfigurer le Database Control sans supprimer le
référentiel, vous pouvez donc appeler successivement emca -deconfig puis emca -config en omettant à chaque fois
l’option -repos.
Lorsque vous lancez l’utilitaire pour créer l’environnement, ce dernier vous pose une série de questions.
Exemple :
C:\>emca -config dbcontrol db -repos create
EMCA DEMARRE à 10 juil. 2008 07:49:35
Assistant Configuration d’EM, version 11.1.0.5.0 - Production
Copyright (c) 2003, 2005, Oracle. Tous droits réservés.
Entrez les informations suivantes :
SID de base de données:
HERMES
Numéro de port du processus d’écoute:
1521
Mot de passe de l’utilisateur SYS:
Mot de passe de l’utilisateur DBSNMP:
Mot de passe de l’utilisateur SYSMAN:
Adresse électronique pour les notifications (facultatif):
[email protected]
Serveur de messagerie sortant (SMTP) pour les notifications (facultatif):
smtp.orange.fr
----------------------------------------------------------------Vous avez indiqué les paramètres suivants
Répertoire d’origine ORACLE_HOME de la base de données
................ D:\app\oracle\product\11.1.0\db_1
Nom d’hôte local ................ srvwinora
Numéro de port du processus d’écoute ................ 1521
SID de base de données ................ HERMES
Adresse électronique pour les notifications
................ [email protected]
Serveur de messagerie sortant (SMTP) pour les notifications
................ smtp.orange.fr
----------------------------------------------------------------Voulez-vous continuer ? [oui(Y)/non(N)]: Y
10 juil. 2008 07:50:38 oracle.sysman.emcp.EMConfig perform
INFO: Cette opération est en cours de journalisation dans
D:\app\oracle\cfgtoollogs\emca\HERMES\emca_2008_07_10_07_49_35.log.
...
10 juil. 2008 08:36:34 oracle.sysman.emcp.EMDBPostConfig perform
Configuration
INFO: >>>>>>> URL de Database Control : https://srvwinora:5500/
em <<<<<<<10 juil. 2008 08:36:37 oracle.sysman.emcp.EMDBPostConfig invoke
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 23 -
ATTENTION:
************************ WARNING ************************
Le référentiel de gestion a été mis en mode sécurisé : les données
Enterprise Manager seront cryptées. La clé de cryptage a été stockée
dans le fichier D:\app\oracle\product\11.1.0\db_1\srvwinora_HERMES\
sysman\config\emkey.ora. Vérifiez que ce fichier est bien
sauvegardé, car les données cryptées deviendront inutilisables si
vous perdez ce fichier.
***********************************************************
Enterprise Manager a été configuré
EMCA ARRETE à 10 juil. 2008 08:36:38
Sur l’exemple ci­dessus, les questions posées sont en gras et les réponses en italique. Les questions posées sont les
suivantes :
SID de base de données
Identifiant de l’instance.
Numéro de port du processus d’écoute
Numéro du port sur lequel le processus d’écoute communique (généralement 1521).
Mot de passe de l’utilisateur SYS
Mot de passe du compte SYS (indiquer le mot attribué à SYS lors de la création de la base de données). La saisie est
masquée.
Mot de passe de l’utilisateur DBSNMP
Mot de passe du compte DBSNMP (créé par l’utilitaire). La saisie est masquée.
Mot de passe de l’utilisateur SYSMAN
Mot de passe du compte SYSMAN (créé par l’utilitaire). La saisie est masquée.
Adresse électronique pour les notifications (facultatif)
Adresse électronique à laquelle les notifications seront envoyées (associé au compte administrateur SYSMAN). Peut être
laissé vide et configuré ultérieurement dans le Database Control.
Serveur de messagerie sortant (SMTP) pour les notifications (facultatif)
Passerelle SMTP utilisée pour l’envoi des notifications par courrier électronique. Peut être laissé vide et configuré
ultérieurement dans le Database Control.
À la fin de l’installation, emca affiche deux messages importants :
●
Un message donnant l’URL à utiliser pour se connecter au Database Control.
●
Un message invitant à sauvegarder un fichier contenant une clé de chiffrage.
Vous pouvez ensuite vous connecter au Database Control en utilisant l’URL indiquée par l’utilitaire.
Si besoin, vous pouvez utiliser l’appel emca -reconfig ports pour modifier les ports utilisés par le Database Control.
L’utilitaire emca peut aussi être utilisé dans un mode non interactif, soit en spécifiant les valeurs dans la ligne de
commande, soit en utilisant un fichier de réponse avec l’option -respFile. Pour plus d’informations sur ces différentes
possibilités, vous pouvez consulter la documentation "Oracle® Database Utilities".
12. Résumé : écrire un script de création d’une base de données
En utilisant les caractéristiques de chaque système d’exploitation, il est facile d’écrire des scripts plus ou moins
paramétrés permettant d’automatiser la création d’une nouvelle base de données.
- 24 -
© ENI Editions - All rights reserved - Algeria Educ
Vous trouverez des exemples de scripts pour les plates­formes Windows et Unix/Linux sur les sites des Editions ENI.
13. Retrouver des informations sur la base de données
Les vues V$DATABASE et DATABASE_PROPERTIES permettent de retrouver des informations sur une base de données.
Les colonnes intéressantes de la vue V$DATABASE sont les suivantes :
NAME
Nom de la base de données.
CREATED
Date/heure de création de la base de données.
LOG_MODE
Mode de fonctionnement vis­à­vis de l’archivage (ARCHIVELOG ou NOARCHIVELOG).
FORCE_LOGGING
YES ou NO selon que le mode FORCE LOGGING est actif ou non.
PLATFORM_NAME
Nom de la plate­forme.
DB_UNIQUE_NAME
Nom unique de la base de données.
La vue DATABASE_PROPERTIES contient des informations sur les propriétés de la base. Les principales colonnes de cette
vue sont les suivantes :
PROPERTY_NAME
Nom de la propriété.
PROPERTY_VALUE
Valeur de la propriété.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 25 -
Création de la base de données à l’aide de l’assistant graphique
1. Vue d’ensemble
L’assistant Configuration de base de données permet de :
●
créer une nouvelle base de données, à partir de modèles pouvant comporter des fichiers de données prêts à
l’emploi ;
●
modifier les options installées dans une base de données ;
●
supprimer une base de données ;
●
créer des modèles ;
●
configurer ASM.
L’assistant crée des structures de stockage complémentaires (que nous verrons dans les chapitres Gestion des
tablespaces et des fichiers de données et Gestion des informations d’annulation).
L’assistant peut être lancé à partir d’une fenêtre du système d’exploitation par la commande dbca. Sur plate­forme
Windows, l’assistant peut aussi être lancé par le menu Démarrer ­ Programmes ­ Oracle ­nom_oracle_home ­
Outils de configuration et de migration ­ Assistant Configuration de base de données.
Un écran de bienvenue s’affiche ; cliquez sur le bouton Suivant pour afficher l’écran proposant les différentes
opérations :
Les options sont les suivantes :
Créer une base de données
Permet de créer une nouvelle base de données (voir ci­après).
Configurer les options de base de données
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Permet de modifier le mode de connexion par défaut de la base de données (serveur dédié ou serveur partagé) et
d’installer ou de supprimer des options supplémentaires dans la base de données.
Supprimer une base de données
Permet de supprimer une base de données.
Gérer les modèles
Permet de créer, modifier et supprimer des modèles (voir ci­après).
Configurer Automatic Storage Management
Permet de configurer une instance pour utiliser le système de stockage ASM.
Sélectionnez l’option souhaitée et cliquez sur le bouton Suivant.
L’assistant peut être utilisé en mode non interactif en utilisant un fichier de réponse. Pour plus d’informations,
consultez la documentation "Oracle® Database Installation Guide" de votre plate­forme.
2. Création à partir d’un modèle avec fichiers de données
Les modèles avec fichiers de données permettent de créer une nouvelle base très rapidement. Par contre, cette
dernière inclut un grand nombre d’options pas forcément utiles pour toutes les applications.
Un modèle avec fichiers de données est en quelque sorte un clone de base de données (une "sauvegarde") qui peut
déjà contenir les objets d’une application, avec éventuellement des données (données dans des tables de
nomenclature par exemple). La base de données créée avec un modèle de ce genre est prête à l’emploi.
Choix du modèle
En standard, l’assistant propose trois modèles, dont deux incluent des fichiers de données prêts à l’emploi ; avec ce
genre de modèle, l’opération de création d’une nouvelle base est très rapide car il n’est pas nécessaire de créer les
fichiers, d’exécuter les scripts, etc. Le modèle Data Warehouse permet de créer une base de données plutôt orientée
application décisionnelle. Le modèle Usage général ou traitement transactionnel permet de créer une base de
données pour une activité mixte ou orientée application de saisie; c’est le modèle choisi pour la suite. Le modèle
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Base de données personnalisée ne comporte pas de fichiers de données ; ils devront donc être spécifiés et créés
(création de base complète). Nous verrons l’utilisation d’un tel modèle au point Création à partir d’un modèle sans
fichier de données de cette section.
Le bouton Afficher les détails... permet d’afficher des informations sur les modèles.
Sélectionnez le modèle (Usage général ou traitement transactionnel pour la suite) et cliquez sur le bouton Suivant.
Identification de la nouvelle base
Sur cet écran, saisissez le Nom global de la base de données (sous la forme DB_NAME.DB_DOMAIN) et le SID de
l’instance, puis cliquez sur le bouton Suivant.
Options de gestion
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Sur cet écran, indiquez si vous souhaitez que la base de données soit gérée ou non par le Database Control,
saisissez éventuellement les informations demandées pour la notification et la sauvegarde (peut être fait plus tard
dans le Database Control) puis cliquez sur le bouton Suivant. Si vous choisissez d’administrer la base avec le
Database Control, l’assistant effectuera la configuration nécessaire (référentiel, répertoires, service sur plate­forme
Windows).
Mots de passe
Sur cet écran, saisissez les mots de passe des différents comptes puis cliquez sur le bouton Suivant. Utiliser le même
mot de passe pour les différents comptes est pratique dans un environnement de test mais, déconseillé en
- 4-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
production.
Options de stockage
Sur cet écran, indiquez le système de stockage choisi pour la base de données puis cliquez sur le bouton Suivant.
Dans cet ouvrage, seul le stockage dans un système de fichiers est étudié.
Emplacement des fichiers de la base de données
© ENI Editions - All rights reserved - Algeria Educ
- 5-
Sur cet écran, indiquez l’emplacement des fichiers de la base de données puis cliquez sur le bouton Suivant. En
cliquant sur le bouton Variables d’emplacement de fichier... vous pourrez définir des variables contenant des
chemins d’accès, qui pourront être utilisées dans la spécification de l’emplacement des fichiers.
Configuration de la récupération
Sur cet écran, saisissez l’emplacement
(paramètre DB_RECOVERY_FILE_DEST) et la taille (paramètre
DB_RECOVERY_FILE_DEST_SIZE) de la zone de récupération rapide, indiquez si vous souhaitez activer dès le départ
l’archivage des fichiers de journalisation, puis cliquez sur le bouton Suivant. Si vous activez l’archivage des fichiers de
journalisation, vous pouvez cliquer sur le bouton Activer les paramètres du mode d’archivage... pour définir la
destination des archives, le format des noms d’archives, etc. (tous les paramètres LOG_ ARCHIVE_*).
Contenu de la base de données
- 6-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Sur cet écran, indiquez si vous souhaitez installer les schémas d’exemple fournis par Oracle (premier onglet) et/ou
exécuter des scripts personnels (deuxième onglet), puis cliquez sur le bouton Suivant. Les schémas d’exemple
peuvent être installés ultérieurement (scripts stockés dans le répertoire %ORACLE_HOME%\demo\schema ou
$ORACLE_HOME/demo/ schema).
Paramètres d’initialisation
Les quatre onglets de cet écran permettent de spécifier les valeurs de plusieurs paramètres d’initialisation. Le bouton
Tous les paramètres d’initialisation... permet de consulter tous les paramètres utilisés et si besoin de les modifier.
© ENI Editions - All rights reserved - Algeria Educ
- 7-
Notez que l’assistant utilise systématiquement un fichier de paramètres serveur.
L’onglet Mémoire permet de régler les paramètres relatifs à la mémoire. Si l’option Standard est sélectionnée, vous
pouvez modifier la quantité de mémoire allouée à l’instance (SGA et PGA). Si l’option Utiliser la gestion automatique
de la mémoire est cochée, l’assistant active la gestion automatique de la mémoire (paramètre
MEMORY_TARGET) ; sinon, l’assistant active la gestion automatique de la mémoire partagée et calcule une répartition
SGA/PGA en fonction du type de base de données du modèle (décisionnel ou usage général) : les valeurs calculées
peuvent être visualisées grâce au bouton Afficher la répartition de la mémoire.... Si l’option Personnalisé est
choisie, vous pouvez activer ou non la gestion automatique de la mémoire partagée (menu déroulant Gestion de la
mémoire). Si la gestion automatique de la mémoire partagée est activée, l’assistant vous demandera juste de saisir
la taille de la SGA (paramètre <$I[]SGA_TARGET>SGA_TARGET) <et la taille de la PGA (paramètre PGA_AGGREGATE_TARGET).
Si la gestion automatique de la mémoire partagée n’est pas activée, vous pourrez dimensionner individuellement les
différentes structures de la mémoire.
L’onglet Dimensionnement permet de définir le nombre maximum de processus (paramètre PROCESSES). La taille de
bloc (paramètre DB_BLOCK_SIZE) ne peut pas être modifiée car le modèle inclut les fichiers de données et ceux­ci
utilisent déjà une certaine taille de bloc.
L’onglet Jeux de caractères permet de choisir les jeux de caractères (clause CHARACTER SET et NATIONAL CHARACTER
SET de l’ordre SQL CREATE DATABASE), le langage par défaut (paramètreNLS_LANGUAGE) et le territoire par défaut
(paramètre NLS_ TERRITORY).
L’onglet Mode de connexion permet de choisir le mode de connexion par défaut de la base de données (serveur
dédié ou serveur partagé) et éventuellement d’indiquer le nombre de processus serveurs partagés, à lancer au
démarrage de l’instance (paramètre SHARED_ SERVERS).
Après avoir saisi les informations requises sur les différents onglets, vous pouvez cliquer sur le bouton Suivant.
Paramètres de sécurité
Sur cet écran, vous pouvez choisir d’utiliser ou pas les nouveaux paramètres de sécurité apparus en version 11
(notamment les mots de passe sensibles à la casse ­ paramètre SEC_CASE_SENSITIVE_LOGON). A priori, il est
recommandé d’utiliser ces nouveaux mécanismes de sécurité (voir le chapitre Gestion des utilisateurs et de leurs
droits).
Après avoir sélectionné une des deux options, vous pouvez cliquer sur le bouton Suivant.
Tâches de maintenance automatique
- 8-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Sur cet écran, vous pouvez choisir d’activer ou pas les tâches de maintenance automatiques prévues en standard
(collecte des statistiques, conseil sur le stockage des segments, conseil sur l’optimisation des requêtes SQL). A priori,
il est recommandé d’activer ces tâches automatiques qui, sont réalisées la nuit et le week­end, avec un faible impact
sur les performances du serveur. Les paramètres de ces tâches de maintenance, notamment la planification, peuvent
être modifiés dans le Database Control (cf. section La documentation Oracle du chapitre Les outils d’administration).
Après avoir effectué votre choix, vous pouvez cliquer sur le bouton Suivant.
Stockage de la base de données
L’écran suivant permet de spécifier les fichiers de la base de données : fichier de contrôle, fichiers de journalisation et
fichiers de données.
© ENI Editions - All rights reserved - Algeria Educ
- 9-
Le dossier Fichier de contrôle permet de configurer les fichiers de contrôle (paramètre CONTROL_FILES). L’onglet
Options permet de définir la valeur des options MAX* (MAXDATAFILES, etc.) de l’ordre SQL CREATE DATABASE.
Le dossier Fichiers de donnéespermet de modifier l’emplacement et le nom des fichiers de données. Par contre, dans
le cas de l’utilisation d’un modèle avec fichiers de données (comme ici), il n’est pas possible (à ce stade) d’ajouter
d’autres tablespaces et fichiers de données, ou de modifier la taille des fichiers de données existants ; ces opérations
pourront être faites ultérieurement dans le Database Control.
- 10 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Le dossier Groupes de fichiers de journalisation permet de configurer les fichiers de journalisation :
ajouter/supprimer des groupes, ajouter des membres dans les groupes, modifier la taille des groupes.
Après avoir saisi les informations requises, vous pouvez cliquer sur le bouton Suivant.
Options de création
Sur cette page, indiquez si vous souhaitez créer la base immédiatement et/ou enregistrer les options dans un
nouveau modèle et/ou générer les scripts de création de la base de données, puis cliquez sur le bouton Terminer.
© ENI Editions - All rights reserved - Algeria Educ
- 11 -
La troisième option est un moyen pratique pour générer des scripts de création de base de données que vous
pourrez ensuite modifier, paramétrer et réutiliser.
Confirmation
Un récapitulatif est affiché lorsque vous cliquez sur le bouton Terminer.
Cliquez sur le bouton OK pour lancer l’opération.
Durant la création de la base de données, une fenêtre affiche un état d’avancement.
Lorsque la création de la base de données est terminée, une fenêtre donnant quelques informations s’affiche :
Cette fenêtre donne notamment l’URL à utiliser pour se connecter au Database Control.
L’assistant crée automatiquement un nom de service réseau pour la nouvelle instance dans le fichier
tnsnames.ora. Par contre, la configuration du processus d’écoute n’est pas modifiée ; l’instance n’est pas
enregistrée de manière statique auprès du processus d’écoute.
Sur plate­forme Unix/Linux, l’assistant ajoute automatiquement une entrée pour la nouvelle instance dans le
fichier /etc/oratab ; par contre, l’instance n’est pas positionnée en redémarrage automatique.
3. Création à partir d’un modèle sans fichier de données
Si vous utilisez un modèle sans fichier de données, vous pourrez contrôler plus finement les options installées et
l’assistant effectue une création complète (CREATE DATABASE, catalog, catproc, etc.). La création de la base de
données est donc plus longue que lors de l’utilisation d’un modèle avec fichiers de données.
Dans cette section, nous ne présentons que les écrans supplémentaires ou différents de ceux présentés
précédemment.
Nouvelle étape : contenu de la base de données
- 12 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Cet écran permet de sélectionner les fonctionnalités à installer dans la base de données ; chaque option se
matérialise par l’exécution d’un script supplémentaire qui rallonge la durée de création de la base. Ces options
peuvent être installées ultérieurement, notamment via l’option Configurer les options de base de données proposée
sur le premier écran de l’assistant.
L’onglet Scripts personnalisés permet de désigner des scripts complémentaires à exécuter lors de la création.
Le bouton Composants de base de données standard... affiche un écran qui permet de désactiver quatre options
installées par défaut par Oracle : la machine virtuelle Java, l’option Multimedia (anciennement interMedia), la
fonctionnalité Oracle XML DB et Application Express (un environnement de développement rapide Web intégré à la
base de données). Oracle conseille de laisser ces quatre options.
Paramètres d’initialisation
Sur le deuxième onglet, la taille de bloc peut être spécifiée (paramètre DB_BLOCK_SIZE).
Stockage de la base de données
© ENI Editions - All rights reserved - Algeria Educ
- 13 -
Des tablespaces et des fichiers de données peuvent être ajoutés, supprimés et modifiés (taille notamment).
4. Gérer les modèles
L’assistant permet de définir des modèles de base de données personnalisés, pouvant éventuellement inclure des
fichiers de données prêts à l’emploi.
Le premier écran de la gestion des modèles permet de choisir l’opération à réaliser, création ou suppression.
- 14 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Plusieurs options sont proposées pour la création.
L’option A partir d’un modèle existant permet de choisir un modèle puis de dérouler les différentes étapes de la
création pour modifier les options souhaitées (comme pour une création de base de données).
L’option A partir d’une base de données existante (structure seulement) permet de reprendre la structure d’une
base de données existante, mais sans inclure les fichiers de la base de données.
L’option A partir d’une base de données existante (structure et données) permet de reprendre la structure d’une
base de données existante avec les fichiers de données (et donc les données qui sont stockées dedans) : c’est en
quelque sorte un clone de la base de données d’origine qui pourra être utilisé pour créer une nouvelle base de
données identique (sauf modifications de configuration effectuées lors de la création de la base de données : nom,
taille de la SGA, etc.).
Les modèles sont stockés par défaut dans le répertoire %ORACLE_HOME%\assistants\ dbca\templates (plate­forme
Windows) ou $ORACLE_HOME/assistants/dbca/ templates (plate­forme Unix/Linux).
Un modèle avec fichiers de données est composé de trois fichiers : un fichier XML .dbc qui contient la définition du
modèle, un fichier .ctl qui est une copie du fichier de contrôle de la base de données et un fichier .dfb qui contient
les fichiers de données. Un modèle sans fichiers de données comporte un seul fichier XML .dbt qui contient la
définition du modèle. Notez que les fichiers Seed_Database.ctl et Seed_Database.dfb sont communs aux deux
modèles avec fichiers de données fournis par Oracle.
Pour créer une base de données à partir du modèle sur un autre serveur, il suffit de copier les fichiers du modèle
dans le répertoire templates du serveur, puis de lancer l’assistant.
Un modèle avec fichiers de données créé sur une plate­forme (Windows par exemple) ne peut pas être utilisé
sur une autre plate­forme (Unix par exemple). Il n’en est pas de même pour les modèles sans fichiers de
données.
© ENI Editions - All rights reserved - Algeria Educ
- 15 -
Présentation d’Oracle11g
1. Introduction
Cet ouvrage présente l’administration d’Oracle Database 11g, qui sera le plus souvent désignée par le terme
"Oracle11g".
Oracle Database 11g est un Système de Gestion de Bases de Données Relationnelles (SGBDR) disponible sur un
grand nombre de plates­formes (Unix, Linux, Windows). Du point de vue de l’administration, les différences entre les
plates­formes sont minimes.
Oracle11g est commercialisé selon trois gammes :
●
Edition Entreprise (Enterprise Edition) ;
●
Edition Standard (Standard Edition) et Edition Standard One (Standard Edition One) ;
●
Edition Personnelle (Personal Edition), sur plate­forme Windows uniquement.
L’édition Standard comporte toutes les fonctionnalités de base permettant de mettre en œ uvre des applications
client­serveur ou Internet/Intranet, pour un groupe de travail ou un département d’entreprise. Cette édition ne
permet pas de faire fonctionner les options avancées d’Oracle11g (voir ci­dessous) et est limitée à des serveurs ou
des clusters de serveurs avec une capacité maximale de 4 processeurs. Depuis quelques temps, Oracle commercialise
aussi une édition Standard One, fonctionnellement identique à l’édition Standard, mais limitée à des serveurs bi­
processeurs.
L’édition Entreprise est plus particulièrement destinée aux applications critiques de l’entreprise et propose des
fonctionnalités supplémentaires, en standard ou en option, permettant d’améliorer la disponibilité et les capacités de
montée en charge des grosses bases de données, et d’en faciliter l’administration et l’optimisation. À titre d’exemple :
●
●
●
●
●
●
●
●
Oracle Real Application Clusters (RAC) : permet d’utiliser Oracle sur des serveurs en cluster (haute
disponibilité, répartition de charge).
Oracle Partitioning : permet de subdiviser le stockage des gros objets (tables et index) en plusieurs éléments
appelés partitions.
Advanced Security Option : offre des fonctionnalités avancées sur la gestion de la sécurité (cryptage,
authentification, etc.).
Oracle Tuning Pack : module d’administration permettant de faciliter l’optimisation des performances de la
base de données.
Oracle OLAP et Oracle Data Mining : fonctionnalités destinées à la mise en place de systèmes décisionnels.
Total Recall (nouveau en version 11g) : solution permettant le stockage sur le long terme de données
historiques.
Real Application Testing (nouveau en version 11g) : permet de capturer l’activité réelle d’une base de
données et de rejouer cette activité sur un autre système.
Advanced Compression (nouveau en version 11g) : permet la compression de tout type de données
(structurées et non structurées).
Oracle Real Application Clusters est une option de l’édition Entreprise mais est incluse, avec quelques petites
contraintes, dans l’édition Standard (pas Standard One) !
L’édition Personnelle est une version monolicence du produit, particulièrement destinée au développeur ; elle offre le
même niveau de fonctionnalité que l’édition Entreprise.
Les bases de l’architecture et de l’administration sont les mêmes pour les trois éditions. Sauf exception, les
fonctionnalités présentées dans cet ouvrage sont communes aux trois éditions ; toute fonctionnalité nécessitant
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
l’édition Entreprise sera clairement signalée.
Les différents produits Oracle peuvent être téléchargés sur le site Oracle Technology Network
(http://www.oracle.com/technology/index.html) ; ils peuvent être utilisés gratuitement pour le développement ou le
prototypage d’une application (mais pas pour l’utilisation d’une application).
2. Principales nouveautés de la version 11
La version 11 apporte un grand nombre de nouveautés et d’améliorations dans de nombreux domaines. Pour n’en
citer que quelques­unes :
- 2-
●
Installation et mise à niveau simplifiées.
●
Gestion complètement automatique de la mémoire totale utilisée par l’instance.
●
Compression des tables, même dans un environnement transactionnel.
●
Gestion simplifiée des paramètres d’initialisation (SPFILE).
●
Gestion automatique de l’annulation activée par défaut.
●
Gestion simplifiée de l’espace temporaire.
●
Nouveau cache pour stocker le résultat des requêtes.
●
Configuration de la base de données, par défaut, plus sécurisée.
●
Nouveau référentiel pour faciliter le diagnostic des incidents (Automatic Diagnostic Repository).
●
Assistant pour la récupération des données (Data Recovery Advisor).
●
Amélioration de la gestion des fichiers de journalisation archivés dans RMAN (Recovery Manager).
●
Amélioration des performances des sauvegardes compressées dans RMAN.
●
Extension des techniques de flashback à l’annulation d’une transaction validée (Flashback Transaction).
●
Base de données transportable entre Linux et Windows.
●
Amélioration de la détection des blocs corrompus.
●
Amélioration de la création et de la récupération d’une sauvegarde de long terme.
●
Sauvegarde et restauration parallélisée des très gros fichiers de données.
●
Index invisibles.
●
Tables en lecture seule.
●
Compression de la totalité du fichier d’export généré par Data Pump.
●
Chiffrage du fichier d’export généré par Data Pump.
●
Colonnes virtuelles.
●
Opérateurs PIVOT et UNPIVOT.
© ENI Editions - All rights reserved - Algeria Educ
●
Nouvel assistant pour résoudre un problème relatif à un ordre SQL (SQL Repair Advisor).
●
Amélioration de l’interface utilisateur d’Oracle Enterprise Manager Database Control.
●
Utilisation du LogMiner à travers l’interface graphique d’Oracle Enterprise Manager Database Control.
●
Chiffrage d’un tablespace.
Bien évidemment, cette liste n’est pas exhaustive.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Gestion des paramètres d’initialisation
1. Modifier les paramètres d’initialisation
a. Les types de paramètres
Les paramètres peuvent être classés en deux catégories :
●
les paramètres dynamiques ;
●
les paramètres statiques.
Les paramètres dynamiques peuvent être modifiés par un ordre SQL alors que l’instance est en cours de
fonctionnement. Selon les cas, le paramètre est modifiable au niveau de la session et/ou du système (pour toutes
les sessions). Au niveau système, la modification peut être immédiate (s’applique aux sessions actuelles) ou différée
(s’applique aux sessions futures uniquement).
Les paramètres statiques ne peuvent pas être modifiés dynamiquement alors que l’instance est en cours de
fonctionnement ; il faut modifier la valeur du paramètre dans le fichier de paramètres et redémarrer l’instance.
Les colonnes ISSES_MODIFIABLE et ISSYS_MODIFIABLE de la vue V$PARAMETER donnent des informations sur le type de
paramètre. La colonne ISSES_MODIFIABLE vaut TRUE ou FALSE selon que le paramètre est modifiable ou non au
niveau de la session. La colonne ISSYS_MODIFIABLE vaut FALSE si le paramètre n’est pas modifiable au niveau du
système, et DEFERRED ou IMMEDIATE selon qu’il est modifiable en différé ou immédiatement.
Les différents paramètres sont décrits dans la documentation Oracle® Database Reference.
b. Les ordres SQL ALTER SYSTEM et ALTER SESSION
Les ordres SQL ALTER SESSION et ALTER SYSTEM permettent de modifier dynamiquement la valeur des paramètres
d’initialisation, respectivement au niveau de la session et du système.
Syntaxe simplifiée :
ALTER SESSION SET paramètre = valeur [...] ;
ALTER SYSTEM SET paramètre = valeur [...] [ COMMENT = ’texte’ ]
[ DEFERRED ] [ SCOPE = MEMORY | SPFILE | BOTH ] ;
Options :
paramètre
Nom du paramètre.
valeur
Valeur attribuée au paramètre.
COMMENT = ’texte’
Commentaire associé à la modification du paramètre. Inséré dans le fichier de paramètres serveur si ce dernier est
la cible de la modification (voir la clause SCOPE) ; visible dans la colonne UPDATE_ COMMENT de la vue V$PARAMETER si la
mémoire est la cible de la modification (voir la clause SCOPE).
DEFERRED
Si présente, indique que la modification ne concerne que les futures sessions, pas celles actuellement connectées.
N’a de sens que si la mémoire est la cible de la modification (voir la clause SCOPE). Peut être obligatoire pour certains
paramètres (ceux dont la colonne ISSYS_MODIFIABLE vaut DEFERRED dans la vue $PARAMETER).
© ENI Editions - All rights reserved - Algeria Educ
- 1-
SCOPE
Définit la cible de la modification :
­ MEMORY : la mémoire seulement (instance en cours).
­ SPFILE : le fichier de paramètres serveur seulement.
­ BOTH : les deux.
La clause SCOPE = SPFILE ne peut être spécifiée que si l’instance a démarré avec un fichier de paramètres serveur.
La modification s’applique uniquement au fichier de paramètres serveur et n’est pas prise en compte
immédiatement ; elle sera prise en compte uniquement au prochain démarrage. C’est la seule option possible pour
les paramètres statiques.
La clause SCOPE = MEMORY s’applique uniquement à la mémoire (instance en cours) et est prise en compte
immédiatement. La modification ne survit pas à l’arrêt de la base. Cette option n’est pas autorisée pour les
paramètres statiques. C’est la seule option possible si l’instance a démarré avec un fichier de paramètres
texte ; c’est la valeur par défaut dans ce cas.
La clause SCOPE = BOTH s’applique à la mémoire (instance en cours) et est prise en compte immédiatement (aspect
MEMORY). La modification est persistante dans le fichier de paramètres serveur (aspect SPFILE). Cette option n’est
pas autorisée pour les paramètres statiques (aspect MEMORY). Elle ne peut être spécifiée que si l’instance a démarré
avec un fichier de paramètres serveur (aspect SPFILE). Cette option n’est pas autorisée pour les paramètres
statiques (aspect MEMORY).
Exemple :
Modification d’un paramètre uniquement dans le fichier de paramètres serveur :
SQL> ALTER SYSTEM SET PROCESSES = 200
2 COMMENT = ’Modif. OH du 10/07/2008’
3 SCOPE = SPFILE;
Système modifié.
Modification d’un paramètre en mémoire et dans le fichier de paramètres serveur :
SQL> ALTER SYSTEM SET MEMORY_TARGET = 500M
2 COMMENT = ’Modif. OH du 10/07/2008’
3 SCOPE = BOTH;
Système modifié.
Si vous utilisez un fichier de paramètres serveur (conseillé) et que vous souhaitez modifier un paramètre statique,
procédez de la manière suivante :
●
Modifiez le paramètre avec l’ordre SQL ALTER SYSTEM et la clause SCOPE=SPFILE.
●
Redémarrez l’instance (SHUTDOWN IMMEDIATE puis STARTUP).
Si l’instance est arrêtée et que vous souhaitez modifier un paramètre statique pour le prochain démarrage, vous
devez d’abord faire un STARTUP (NOMOUNT suffit), avant de modifier le paramètre par l’ordre SQL ALTER SYSTEM et de
redémarrer. L’ordre SQL ALTER SYSTEM nécessite que l’instance soit démarrée.
Pour supprimer un paramètre du fichier de paramètres serveur, vous pouvez utiliser une variante de l’ordre SQL
ALTER SYSTEM.
Syntaxe simplifiée :
ALTER SYSTEM RESET paramètre [ SCOPE = SPFILE ] ;
Options :
paramètre
Nom du paramètre
La clause SCOPE = SPFILE est optionnelle ; c’est la seule autorisée. Après la suppression, au prochain démarrage, la
valeur par défaut du paramètre sera utilisée. Les ordres SQL ALTER SYSTEM de modification de paramètres sont
enregistrés dans le fichier d’alerte de l’instance.
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
2. Les paramètres dans le dictionnaire de données
Plusieurs vues du dictionnaire permettent de visualiser les paramètres :
●
●
●
●
V$SYSTEM_PARAMETER : valeur actuelle des paramètres dans l’instance.
V$SYSTEM_PARAMETER2 : même chose que V$SYSTEM_PARAMETER mais avec un affichage sur plusieurs lignes des
paramètres qui ont une liste de valeurs (comme le paramètre CONTROL_FILES par exemple).
V$PARAMETER et V$PARAMETER2 : même contenu que les vues V$SYSTEM_ PARAMETER et V$SYSTEM_PARAMETER2
mais avec les valeurs actuelles des paramètres dans la session courante ; ces vues donnent donc la valeur
des paramètres qui ont été éventuellement modifiés dans la session (par un ALTER SESSION).
V$SPPARAMETER : contenu actuel du fichier de paramètres serveur actif ; le contenu de la vue est vide si
l’instance n’utilise pas de fichier de paramètres serveur.
Principales colonnes des vuesV$SYSTEM_PARAMETER, V$SYSTEM_PARAMETER2, V$PARAMETER et V$PARAMETER2 :
NAME
Nom du paramètre (en minuscules).
VALUE
Valeur du paramètre.
DISPLAY_VALUE
Valeur du paramètre dans un format d’affichage plus convivial (par exemple 252M au lieu de 264241152).
ISDEFAULT
TRUE si le paramètre est égal à sa valeur par défaut, FALSE sinon.
ISSES_MODIFIABLE
TRUE si le paramètre est modifiable au niveau de la session, FALSE sinon.
ISSYS_MODIFIABLE
FALSE si le paramètre n’est pas modifiable au niveau du système, et DEFERRED ou IMMEDIATE selon qu’il est modifiable
en différé ou immédiatement.
ISMODIFIED
Indique si le paramètre a été modifié depuis le démarrage de l’instance. MODIFIED si modifié au niveau de la session
courante, SYSTEM_MOD si modifié au niveau du système, FALSE si non modifié.
ISDEPRECATED
TRUE si le paramètre est déprécié (risque de disparaître dans une prochaine version), FALSE sinon.
UPDATE_COMMENT
Commentaire associé à la modification la plus récente (option COMMENT de l’ordre SQL ALTER SYSTEM).
Principales colonnes de la vue V$SPPARAMETER :
NAME
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Nom du paramètre (en minuscules).
VALUE
Valeur du paramètre.
DISPLAY_VALUE
Valeur du paramètre dans un format d’affichage plus convivial (par exemple 252M au lieu de 264241152).
ISSPECIFIED
TRUE si le paramètre est spécifié dans le fichier de paramètres serveur, FALSE sinon.
UPDATE_COMMENT
Commentaire associé à la modification la plus récente (option COMMENT de l’ordre SQL ALTER SYSTEM).
Notez que la vue V$SPARAMETER donne la valeur du paramètre dans le fichier de paramètres serveur ; la valeur
actuelle peut être différente si le paramètre a été modifié pour l’instance courante uniquement (SCOPE=MEMORY).
Exemple : comparaison entre V$PARAMETER et V$SPPARAMETER
SQL> SELECT
2
p.name,
3
p.display_value
actuel,
4
sp.display_value
spfile
5 FROM
6
v$parameter
p,
7
v$spparameter
sp
8 WHERE
9
p.name = sp.name
10
AND
p.name = ’processes’
11 /
NAME
ACTUEL
SPFILE
-------------------- -------------------- --------------processes
100
200
Dans SQL*Plus, les commandes SHOW PARAMETERS [chaîne] et SHOW SPPARAMETERS [chaîne] affichent la valeur des
paramètres respectivement dans la session courante et dans le fichier de paramètres serveur. Par défaut, ces
commandes affichent la valeur de tous les paramètres. Si une chaîne est spécifiée lors de l’appel, ces commandes
affichent la valeur de tous les paramètres dont le nom contient cette chaîne.
Exemple
SQL> SHOW PARAMETERS memory
NAME
TYPE
VALUE
-------------------------------- ----------- -----------hi_shared_memory_address
integer
0
memory_max_target
big integer 500M
memory_target
big integer 400M
shared_memory_address
integer
0
3. Exporter un fichier de paramètres serveur
Un fichier de paramètres serveur peut être réexporté au format texte par l’ordre SQL CREATE PFILE.
Syntaxe
CREATE PFILE [ = ’nom_pfile’ ] FROM SPFILE [ = ’nom_spfile’ ];
Le fonctionnement (signification des paramètres, valeurs par défaut, etc.) est le même que pour l’ordre SQL CREATE
SPFILE (voir la section Création d’une base de données à la main du chapitre Création d’une nouvelle base de
données).L’utilisation de cet ordre SQL nécessite notamment une connexion SYSDBA ou SYSOPER. Cet ordre SQL peut
être utilisé instance arrêtée !
- 4-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Exemple :
SQL> CREATE PFILE = ’d:\app\oracle\admin\HERMES\pfile\init.ora’
2 FROM SPFILE;
Fichier créé.
Contenu du fichier (extrait)
*.__db_cache_size=152M
...
*.__shared_pool_size=72M
...
*.db_name=’HERMES’
...
*.memory_target=524288000#Modif. OH du 10/07/2008
...
*.processes=200#Modif. OH du 10/07/2008
...
Ces lignes en gras correspondent à des paramètres dont la valeur avait été modifiée précédemment avec l’option
COMMENT. Le commentaire est présent dans le fichier de paramètres serveur (voir aussi le contenu de la colonne
UPDATE_COMMENT dans la vue V$SPPARAMETER).
Dans l’optique de l’utilisation d’un fichier de paramètres commun à plusieurs instances (par exemple, avec l’option
RAC ­ Real Application Clusters), les paramètres peuvent être spécifiés sous la forme instance.paramètre, le symbole *
désignant n’importe quelle instance (*.memory_target). Cette syntaxe est utilisée lors de l’export d’un fichier de
paramètres serveur.
Le fichier ainsi généré peut être utilisé à des fins de simple consultation ou de modification, pour recréer le fichier de
paramètres serveur à partir du fichier de paramètres texte modifié (à l’aide de l’ordre SQL CREATE SPFILE ... FROM
PFILE), ou pour effectuer des démarrages particuliers. Notez que si l’instance a démarré avec un fichier de
paramètres serveur, celui­ci ne peut pas être remplacé alors qu’il est en cours d’utilisation ; vous devez donc arrêter
la base de données (SHUTDOWN IMMEDIATE) avant de recréer le fichier de paramètres serveur à l’aide de l’ordre SQL
CREATE SPFILE (qui lui aussi fonctionne instance arrêtée !).Depuis la version 11, il est possible de créer un fichier de
paramètres texte ou un fichier de paramètres serveur à partir des valeurs des paramètres actuellement en mémoire
(instance en cours).
Syntaxe
CREATE PFILE [ = ’nom_pfile’ ] FROM MEMORY;
CREATE SPFILE [ = ’nom_spfile’ ] FROM MEMORY;
Les principes de fonctionnement sont les mêmes que pour les autres variantes de syntaxe de ces deux ordres SQL.
4. Utiliser le Database Control
Dans le Database Control, cliquez sur le lien Serveur sur la page d’accueil puis sur le lien Paramètres d’initialisation
(cadre Configuration de base de données) pour accéder à la page de gestion des paramètres d’initialisation :
© ENI Editions - All rights reserved - Algeria Educ
- 5-
Sur l’onglet En cours, vous pouvez consulter et modifier la valeur actuelle des paramètres.
Par défaut, les modifications affectent uniquement l’instance en cours (SCOPE=MEMORY). Pour affecter l’instance en
cours et le fichier de paramètres serveur (SCOPE=BOTH), cochez la case Appliquer au fichier SPFILE les modifications
dans le mode des instances en cours d’exécution avant de cliquer sur le bouton Appliquer. Seuls les paramètres
dynamiques sont modifiables.
Sur l’onglet Fichier SPFILE, vous pouvez consulter et modifier la valeur des paramètres dans le fichier de paramètres
serveur :
Par défaut, les modifications affectent uniquement le fichier de paramètres serveur (SCOPE=SPFILE). Pour affecter
l’instance en cours et le fichier de paramètres serveur (SCOPE=BOTH), cochez la case Appliquer les modifications en
mode SPFILE aux instances en cours d’exécution avant de cliquer sur le bouton Appliquer. Si vous cochez cette
case et que vous modifiez un paramètre statistique, le Database Control vous proposera de redémarrer (seul moyen
pour appliquer la modification à "l’instance en cours").
- 6-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Le bouton Réinitialiser permet de supprimer le paramètre sélectionné du fichier de paramètres serveur (ALTER
SYSTEM RESET).
5. Problèmes courants et solutions
a. Fichier de paramètres serveur perdu ou endommagé
Si le fichier de paramètres serveur est perdu ou endommagé, vous pouvez au choix :
●
●
●
Si l’instance est démarrée, le recréer à partir des valeurs des paramètres actuellement en mémoire (CREATE
SPFILE FROM MEMORY).
Si un fichier de paramètres texte valide est disponible, le recréer à partir de ce fichier texte (CREATE SPFILE
FROM PFILE).
Le restaurer à partir d’une sauvegarde (voir le chapitre Sauvegarde et récupération).
En dernier ressort, vous pouvez créer un fichier de paramètres texte à la main puis recréer le fichier de paramètres
serveur à partir de ce fichier texte. Pour créer le fichier de paramètres texte, vous pouvez copier­coller les valeurs
des paramètres qui sont écrites dans le fichier d’alerte de l’instance à chaque démarrage.
Exemple :
Starting up ORACLE RDBMS Version: 11.1.0.6.0.
Using parameter settings in server-side
spfile D:\APP\ORACLE\PRODUCT\11.1.0\DB_1\DATABASE\SPFILEHERMES.ORA
System parameters with non-default values:
processes
= 150
nls_language
= "FRENCH"
nls_territory
= "FRANCE"
memory_target
= 252M
...
b. Valeur erronée qui empêche le démarrage
Une valeur erronée dans le fichier de paramètres serveur peut empêcher le démarrage "normal" de la base de
données.
Deux cas peuvent se produire :
●
L’instance démarre mais la base de données ne peut pas être montée ou ouverte.
●
L’instance ne démarre pas.
Si l’instance démarre, vous pouvez modifier le paramètre erroné, ou le supprimer, avec l’ordre SQL ALTER SYSTEM
(SET ou RESET).
Si l’instance ne démarre pas, vous pouvez créer un fichier de paramètres texte à partir du fichier de paramètres
serveur (CREATE PFILE FROM SPFILE), corriger la valeur du paramètre dans le fichier de paramètre texte, puis recréer
le fichier de paramètres serveur à partir du fichier texte (CREATE SPFILE FROM PFILE). Pour mémoire, les ordres SQL
CREATE PFILE et CREATE SPFILE fonctionnent même si l’instance n’est pas démarrée (il faut juste une connexion
SYSDBA).
c. Erreur lors d’un ALTER SYSTEM
ORA-02065: option interdite pour ALTER SYSTEM
Explication
L’option spécifiée n’est pas supportée.
© ENI Editions - All rights reserved - Algeria Educ
- 7-
Cause(s)
Le nom du paramètre est incorrect.
Action(s)
Vérifiez et corrigez le nom du paramètre.
ORA-02095: Le paramètre d’initialisation indiqué ne peut pas être modifié
Explication
Le paramètre ne peut pas être modifié.
Cause(s)
Le paramètre est statique et ne peut pas être modifié pour l’instance en cours.
Action(s)
Utilisez la clause SCOPE=SPFILE.
ORA-02096: Le paramètre d’initialisation indiqué ne peut pas être modifié avec cette option
Explication
Le paramètre est modifiable mais pas avec l’option utilisée.
Cause(s)
Vous n’avez pas utilisé l’option DEFERRED pour un paramètre qui le nécessite ou à l’inverse, vous avez utilisé l’option
DEFERRED pour un paramètre pour lequel c’est interdit.
Action(s)
Consultez la documentation du paramètre et corrigez l’ordre SQL.
ORA-02097: le paramètre ne peut pas être modifié, car la valeur indiquée n’est pas valide
Explication
Le paramètre est modifiable mais la valeur est incorrecte.
Cause(s)
En règle générale, cette erreur survient lorsque la valeur spécifiée est trop grande ou trop petite.
Action(s)
Consultez la documentation du paramètre et corrigez l’ordre SQL.
- 8-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Gestion dynamique de la mémoire
1. Principes
Depuis Oracle9i, la SGA et la PGA sont dynamiques. Elles peuvent être modifiées dynamiquement alors que l’instance
est en cours de fonctionnement, c’est à dire augmentées ou diminuées, sans devoir arrêter la base. De plus, depuis
Oracle10g, la mémoire partagée peut être gérée automatiquement, et depuis Oracle11g, la totalité de la mémoire
(SGA et PGA) peut l’être aussi (voir la section L’instance du chapitre Les bases de l’architecture Oracle).
Plusieurs paramètres relatifs à la gestion de la mémoire (PGA ou SGA) sont modifiables dynamiquement par
l’intermédiaire de l’ordre SQL ALTER SYSTEM :
●
MEMORY_TARGET
●
SGA_TARGET
●
DB_CACHE_SIZE et éventuellement les différents paramètres DB_nK_CACHE_SIZE (n valant 2,4,8,16 ou 32)
●
SHARED_POOL_SIZE
●
LARGE_POOL_SIZE
●
JAVA_POOL_SIZE
●
STREAMS_POOL_SIZE
●
RESULT_CACHE_MAX_SIZE
●
PGA_AGGREGATE_TARGET
Seule la taille du Redo Log Buffer (paramètre LOG_BUFFER) ne peut pas être modifiée dynamiquement (mais sa valeur
par défaut est généralement satisfaisante).
La taille maximum de la mémoire de l’instance est définie par le paramètre MEMORY_MAX _TARGET et la taille maximum
de la SGA par le paramètre SGA_MAX_SIZE. Ces deux paramètres ne sont pas dynamiques et sont calculés, par défaut,
au démarrage de l’instance, s’ils ne sont pas définis dans le fichier de paramètres.
N’oubliez pas que toutes les valeurs des paramètres de dimensionnement de la mémoire sont arrondies au
granule supérieur (à l’exception du paramètre RESULT_ CACHE_MAX_SIZE dont la valeur est définie par pas de
32 Ko).
Lors de la modification dynamique d’une structure mémoire, vous pouvez obtenir un message d’erreur si la valeur
demandée est trop grande ou trop petite (cf. section Gestion dynamique de la mémoire).
2. Informations sur la mémoire
La commande SQL*Plus SHOW SGA ou la vue V$SGA donne des informations synthétiques sur la taille de la SGA. Dans
les deux cas, la quantité SGA_MAX_SIZE est virtuellement affectée à la SGA.
SQL> SELECT name,value,display_value FROM v$parameter
2 WHERE name IN (’sga_target’,’sga_max_size’,
3
’memory_target’,’memory_max_target’);
NAME
VALUE
DISPLAY_VALUE
-------------------- -------------------- ---------------sga_max_size
524288000
500M
sga_target
0
0
memory_target
419430400
400M
memory_max_target
524288000
500M
© ENI Editions - All rights reserved - Algeria Educ
- 1-
SQL> SELECT name,value FROM v$sga
2 UNION ALL
3 SELECT ’*** TOTAL ***’,SUM(value) FROM v$sga;
NAME
VALUE
-------------------- ---------Fixed Size
2145984
Variable Size
356516160
Database Buffers
159383552
Redo Buffers
3891200
*** TOTAL ***
521936896
La vue V$SGAINFO donne des informations plus détaillées sur la SGA, et s’avère à l’usage plus intéressante que la vue
V$SGA.
SQL> SELECT name,ROUND(bytes/(1024*1024),1) size_mb,resizeable
2 FROM v$sgainfo;
NAME
SIZE_MB RES
-------------------------------- ---------- --Fixed SGA Size
2 No
Redo Buffers
3.7 No
Buffer Cache Size
152 Yes
Shared Pool Size
72 Yes
Large Pool Size
4 Yes
Java Pool Size
4 Yes
Streams Pool Size
0 Yes
Shared IO Pool Size
0 Yes
Granule Size
4 No
Maximum SGA Size
497.8 No
Startup overhead in Shared Pool
44 No
Free SGA Memory Available
260
Cette vue donne notamment la taille actuelle réelle des différentes composantes de la SGA, ainsi que la taille du
granule (ligne Granule Size). Toutes les tailles sont en octets. La colonne RESIZEABLE indique si la taille de la
structure correspondante peut être modifiée dynamiquement.
La ligne Free SGA Memory Available donne la différence entre la taille maximum de la SGA (SGA_MAX_SIZE) et la taille
actuelle de la SGA, et donc la quantité de mémoire supplémentaire qui peut être allouée à la SGA en cas de besoin
(soit automatiquement, soit manuellement selon la configuration). Il faut noter que, dans le cas où la gestion
automatique de la mémoire de l’instance est activée, cette mémoire "libre" inclut la quantité de mémoire allouée à la
PGA et n’est donc pas réellement disponible en totalité pour la SGA.
La même information est disponible dans la vue V$SGA_DYNAMIC_FREE_MEMORY qui donne la quantité de mémoire SGA
disponible pour une opération de redimensionnement dynamique (seule et unique colonne CURRENT_SIZE).
Des informations plus complètes sur les structures dynamiques de la mémoire (SGA et PGA) sont disponibles dans la
vue V$MEMORY_DYNAMIC_COMPONENTS. Les principales colonnes sont les suivantes :
COMPONENT
Nom de la structure.
CURRENT_SIZE
Taille actuelle de la structure.
MIN_SIZE
Taille minimum de la structure depuis le démarrage de l’instance.
MAX_SIZE
Taille maximum de la structure depuis le démarrage de l’instance.
USER_SPECIFIED_SIZE
Valeur affectée au paramètre.
LAST_OPER_TYPE
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Information sur la dernière opération réalisée sur la structure (GROW, SHRINK, etc.).
LAST_OPER_MODE
Mode de la dernière opération (MANUAL, IMMEDIATE, etc.).
LAST_OPER_TIME
Date/heure de la dernière opération.
GRANULE_SIZE
Taille du granule.
Toutes les tailles sont en octets.
Exemple :
SQL> SELECT component,current_size/(1024*1024) current_mb
2 FROM v$memory_dynamic_components;
COMPONENT
CURRENT_MB
------------------------------ ---------shared pool
72
large pool
4
java pool
4
streams pool
0
SGA Target
240
DEFAULT buffer cache
152
KEEP buffer cache
0
RECYCLE buffer cache
0
DEFAULT 2K buffer cache
0
DEFAULT 4K buffer cache
0
DEFAULT 8K buffer cache
0
DEFAULT 16K buffer cache
0
DEFAULT 32K buffer cache
0
Shared IO Pool
0
PGA Target
160
ASM Buffer Cache
0
Par l’intermédiaire de cette vue, nous pouvons voir la quantité de mémoire allouée à la SGA (ligne SGA Target) et à la
PGA (ligne PGA Target), ainsi que la répartition de la SGA entre ces différentes composantes. Sur cet exemple, nous
voyons qu’il y a 8 Mo (240­72­4­4­152), soit 2 granules, réservés pour les structures non dynamiques de la SGA
(Redo Log Buffer et SGA fixe).
En complément, vous pouvez interroger la vue V$MEMORY_RESIZE_OPS pour avoir l’historique des 800 dernières
opérations de redimensionnement de la mémoire et V$MEMORY_ CURRENT_RESIZE_OPS pour avoir des informations sur
un éventuel redimensionnement en cours.
Les vues V$MEMORY_* sont apparues en version 11 et tiennent compte de la PGA. Il existe des vues équivalentes,
apparues en version 10, mais limitées à la SGA : V$SGA_
DYNAMIC_COMPONENTS, V$SGA_RESIZE_OPS et
V$SGA_CURRENT_RESIZE_OPS.
3. Modifier la mémoire dynamiquement
a. Avec la gestion automatique de la mémoire partagée
Lorsque la gestion automatique de la mémoire partagée est activée (paramètre SGA_TARGET différent de zéro), la
taille de la SGA peut être modifiée dynamiquement en modifiant la valeur du paramètre SGA_TARGET.
La valeur de ce paramètre peut être augmentée jusqu’à la valeur du paramètre SGA_MAX_SIZE. Elle peut être
diminuée jusqu’à une valeur minimale déterminée par Oracle en tenant de différents éléments, dont la taille que
vous avez éventuellement affectée aux composantes non prises en charge par la gestion automatique (paramètres
DB_nK_CACHE_SIZE par exemple) mais aussi de la taille minimale que vous avez pu définir pour les composantes
gérées automatiquement.
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Lorsque le paramètre SGA_TARGET est modifié, seules les composantes gérées automatiquement sont modifiées, et
la répartition entre les différentes composantes est automatiquement déterminée par Oracle ; les composantes
gérées manuellement restent inchangées. En cas de diminution, Oracle ne descendra pas en dessous de la valeur
minimale que vous avez pu définir pour une ou plusieurs composantes.
Si vous le souhaitez, vous pouvez aussi modifier la valeur des paramètres gérés manuellement et/ou la valeur des
paramètres gérés automatiquement (dans ce dernier cas vous définissez alors un minimum pour le paramètre).
Le comportement est le suivant :
●
●
●
●
Si vous diminuez la valeur d’un paramètre géré manuellement, vous augmentez implicitement la quantité de
mémoire disponible pour la gestion automatique ; la mémoire supplémentaire va être automatiquement
réattribuée aux paramètres gérés automatiquement (Oracle décide de la répartition).
Si vous augmentez la valeur d’un paramètre géré manuellement, vous diminuez implicitement la quantité de
mémoire disponible pour la gestion automatique ; cette quantité de mémoire va être automatiquement
enlevée aux paramètres gérés automatiquement (Oracle décide de la répartition).
Si vous diminuez la valeur d’un paramètre géré automatiquement, vous ne diminuez en fait que la valeur
minimale de ce paramètre, mais pas sa valeur actuelle. En cas de besoin, Oracle pourra diminuer la valeur
actuelle du paramètre pour attribuer de la mémoire à une autre structure. Si vous mettez la valeur à 0, vous
n’imposez plus de minimum.
Si vous augmentez la valeur d’un paramètre géré automatiquement, vous augmentez la valeur minimale de
ce paramètre, mais pas sa valeur actuelle si, celle­ci est actuellement supérieure au nouveau minimum. Par
contre, si le nouveau minimum est supérieur à la valeur actuelle, la valeur est immédiatement augmentée,
et Oracle diminue en contrepartie les autres paramètres automatiques (Oracle décide de la répartition).
Exemple :
SQL> -- contenu du script memoire.sql
SQL> HOST more memoire.sql
COL component FOR A30
SELECT component,
current_size/1024/1024 current_size,
user_specified_size/1024/1024 user_specified_size
FROM
v$memory_dynamic_components
WHERE current_size 0
UNION ALL
SELECT ’*** LIBRE SGA ***’,current_size/1024/1024,null
FROM
v$sga_dynamic_free_memory
/
SQL> -- situation de départ
SQL> SELECT name,display_value FROM v$parameter
2 WHERE name IN (’sga_target’,’sga_max_size’);
NAME
DISPLAY_VALUE
--------------------- ----------------sga_max_size
300M
sga_target
252M
SQL> @memoire
COMPONENT
CURRENT_SIZE USER_SPECIFIED_SIZE
------------------------------ ------------ ------------------shared pool
72
0
large pool
4
0
java pool
4
0
SGA Target
252
252
DEFAULT buffer cache
164
0
PGA Target
64
64
*** LIBRE SGA ***
48
SQL> -- augmentation de SGA_TARGET à 300M
SQL> ALTER SYSTEM SET SGA_TARGET = 300M;
Système modifié.
SQL> @memoire
COMPONENT
CURRENT_SIZE USER_SPECIFIED_SIZE
------------------------------ ------------ ------------------shared pool
72
0
- 4-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
large pool
java pool
SGA Target
DEFAULT buffer cache
PGA Target
*** LIBRE SGA ***
4
4
300
212
64
0
0
0
300
0
64
SQL> -- affectation d’une valeur à DB_16K_CACHE_SIZE
SQL> -- et d’un minimum à SHARED_POOL_SIZE
SQL> ALTER SYSTEM SET
2
DB_16K_CACHE_SIZE = 32M
3
SHARED_POOL_SIZE = 96M ;
Système modifié.
SQL> @memoire
COMPONENT
CURRENT_SIZE USER_SPECIFIED_SIZE
------------------------------ ------------ ------------------shared pool
96
0
large pool
4
0
java pool
4
0
SGA Target
300
300
DEFAULT buffer cache
156
0
DEFAULT 16K buffer cache
32
32
PGA Target
64
64
*** LIBRE SGA ***
0
SQL> -- diminution de SGA_TARGET
SQL> ALTER SYSTEM SET SGA_TARGET = 168M;
Système modifié.
SQL> @memoire
COMPONENT
CURRENT_SIZE USER_SPECIFIED_SIZE
------------------------------ ------------ ------------------shared pool
96
96
large pool
4
0
java pool
4
0
SGA Target
168
168
DEFAULT buffer cache
24
0
DEFAULT 16K buffer cache
32
32
PGA Target
64
64
*** LIBRE SGA ***
132
Sur cet exemple, nous voyons les choses suivantes :
●
●
●
Lors de l’augmentation de SGA_TARGET à 300 Mo, la totalité de la mémoire supplémentaire est allouée au
Buffer Cache, et il n’y a plus de mémoire libre pour la SGA.
Lors de l’affectation d’une valeur au paramètre DB_16K_CACHE_SIZE (géré manuellement) et d’une valeur à
SHARED_POOL_SIZE (minimum puisque le paramètre est automatique), un cache pour les blocs de 16 Ko est
alloué à la valeur demandée et la Shared Pool est augmentée, car la valeur actuelle était inférieure au
nouveau minimum. Le Buffer Cache est diminué en conséquence (plus de mémoire libre pour la SGA).
Lors de la diminution de SGA_TARGET à 168 Mo, le Buffer Cache est diminué. Les autres paramètres ne
peuvent pas être diminués : DB_16K_CACHE_SIZE est géré manuellement et les autres sont à leur valeur
minimale.
b. Avec la gestion automatique de la mémoire
Lorsque la gestion automatique de la mémoire est activée (paramètre MEMORY_TARGET), la taille de la mémoire
allouée à l’instance (SGA et PGA) peut être modifiée dynamiquement en modifiant la valeur du paramètre
MEMORY_TARGET.
La valeur de ce paramètre peut être augmentée jusqu’à la valeur du paramètre MEMORY_ MAX_TARGET. Il peut être
diminué jusqu’à une valeur minimale déterminée par Oracle en tenant compte de différents éléments (comme pour
la gestion automatique de la mémoire partagée).
Lorsque le paramètre MEMORY_TARGET est modifié, Oracle détermine une nouvelle répartition de la mémoire entre la
PGA (PGA_AGGREGATE_TARGET) et la SGA (SGA_TARGET), puis une nouvelle répartition de la SGA entre ces différentes
© ENI Editions - All rights reserved - Algeria Educ
- 5-
composantes, selon les mêmes règles que pour la gestion automatique de la mémoire partagée.
Du point de vue de la SGA, la gestion automatique de la mémoire n’est qu’une extension de la gestion automatique
de la mémoire partagée. Toutes les règles exposées précédemment sur la modification des paramètres gérés
manuellement et des paramètres gérés automatiquement demeurent valable (voir le titre précédent).
En complément, si vous le souhaitez, vous pouvez aussi modifier la valeur des paramètres SGA_TARGET et
PGA_AGGREGATE_TARGET. Dans ce cas, SGA_TARGET et PGA_ AGGREGATE_TARGET imposent simplement un minimum
respectivement pour la SGA et pour la PGA.
Le comportement est le suivant :
●
●
Si vous augmentez la valeur de SGA_TARGET ou PGA_AGGREGATE_TARGET, vous augmentez la valeur minimale
de ces paramètres, mais pas leur valeur actuelle si, celle­ci est actuellement supérieure au nouveau
minimum. Par contre, si le nouveau minimum est supérieur à la valeur actuelle, la valeur est immédiatement
augmentée, et Oracle diminue en contrepartie les autres paramètres automatiques (Oracle décide de la
répartition).
Si vous diminuez la valeur de SGA_TARGET ou PGA_AGGREGATE_TARGET, vous ne diminuez en fait que la valeur
minimale de ces paramètres, mais pas leur valeur actuelle. En cas de besoin, Oracle pourra diminuer la
valeur actuelle du paramètre pour attribuer de la mémoire à une autre structure. Si vous mettez la valeur à
0, vous n’imposez plus de minimum.
Par ailleurs, n’oubliez pas que le paramètre statique SGA_MAX_SIZE, s’il est défini, impose une taille maximum pour la
SGA.
Exemple :
SQL> -- contenu du script memoire.sql
SQL> HOST more memoire.sql
COL component FOR A30
SELECT component,
current_size/1024/1024 current_size,
user_specified_size/1024/1024 user_specified_size
FROM
v$memory_dynamic_components
WHERE current_size 0
UNION ALL
SELECT ’*** LIBRE SGA ***’,current_size/1024/1024,null
FROM
v$sga_dynamic_free_memory
/
SQL> -- situation de départ
SQL> SELECT name,display_value FROM v$parameter
2 WHERE name IN (’memory_target’,’memory_max_target’);
NAME
DISPLAY_VALUE
--------------------- ----------------memory_target
400M
memory_max_target
500M
SQL> @memoire
COMPONENT
CURRENT_SIZE USER_SPECIFIED_SIZE
------------------------------ ------------ ------------------shared pool
72
0
large pool
4
0
java pool
4
0
SGA Target
240
0
DEFAULT buffer cache
152
0
PGA Target
160
0
*** LIBRE SGA ***
260
SQL> -- augmentation de MEMORY_TARGET à 500M
SQL> ALTER SYSTEM SET MEMORY_TARGET = 500M;
Système modifié.
SQL> @memoire
COMPONENT
CURRENT_SIZE USER_SPECIFIED_SIZE
------------------------------ ------------ ------------------shared pool
72
0
large pool
4
0
java pool
4
0
SGA Target
240
0
DEFAULT buffer cache
152
0
- 6-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
PGA Target
260
0
*** LIBRE SGA ***
260
SQL> -- affectation d’une valeur à DB_16K_CACHE_SIZE
SQL> ALTER SYSTEM SET DB_16K_CACHE_SIZE = 32M;
Système modifié.
SQL> @memoire
COMPONENT
CURRENT_SIZE USER_SPECIFIED_SIZE
------------------------------ ------------ ------------------shared pool
72
0
large pool
4
0
java pool
4
0
SGA Target
240
0
DEFAULT buffer cache
120
0
DEFAULT 16K buffer cache
32
32
PGA Target
260
0
*** LIBRE SGA ***
260
SQL> -- affectation d’une valeur à SGA_TARGET
SQL> ALTER SYSTEM SET SGA_TARGET = 300M;
Système modifié.
SQL> @memoire
COMPONENT
CURRENT_SIZE USER_SPECIFIED_SIZE
------------------------------ ------------ ------------------shared pool
72
0
large pool
4
0
java pool
4
0
SGA Target
300
300
DEFAULT buffer cache
180
0
DEFAULT 16K buffer cache
32
32
PGA Target
200
0
*** LIBRE SGA ***
200
SQL> -- diminution de MEMORY_TARGET
SQL> ALTER SYSTEM SET MEMORY_TARGET = 352M;
Système modifié.
SQL> @memoire
COMPONENT
CURRENT_SIZE USER_SPECIFIED_SIZE
------------------------------ ------------ ------------------shared pool
72
0
large pool
4
0
java pool
4
0
SGA Target
300
300
DEFAULT buffer cache
180
0
DEFAULT 16K buffer cache
32
32
PGA Target
52
0
*** LIBRE SGA ***
200
Sur cet exemple, nous voyons les choses suivantes :
●
●
●
●
Lors de l’augmentation de MEMORY_TARGET à 500 Mo, la totalité de la mémoire supplémentaire est allouée à
la PGA.
Lors de l’affectation d’une valeur au paramètre DB_16K_CACHE_SIZE (géré manuellement), un cache pour les
blocs de 16 Ko est alloué à la valeur demandée et le Buffer Cache est diminué en conséquence (comme pour
la gestion automatique de la mémoire partagée).
Lors de l’affectation d’une valeur (minimum) à SGA_TARGET, la SGA est augmentée immédiatement car la
valeur actuelle était inférieure au nouveau minimum ; la quantité de mémoire supplémentaire est
intégralement allouée au Buffer Cache.
Lors de la diminution de MEMORY_TARGET à 352 Mo, la PGA est diminuée. La SGA ne peut pas être diminuée
car elle est à la valeur minimale imposée par SGA_TARGET.
c. Sans la gestion automatique
© ENI Editions - All rights reserved - Algeria Educ
- 7-
Si vous n’utilisez pas la gestion automatique de la mémoire ni la gestion automatique de la mémoire partagée, les
modifications apportées aux paramètres sont immédiatement prises en compte, toujours dans la limite de
SGA_MAX_SIZE et MEMORY_MAX_TARGET (s’il est défini).
d. Conclusion et conseil
Oracle recommande d’utiliser la gestion automatique de la mémoire qui simplifie beaucoup le travail de
l’administrateur : il suffit juste de définir le paramètre MEMORY_TARGET (et éventuellement le paramètre
MEMORY_MAX_TARGET).
Si vous utilisez la gestion automatique de la mémoire, ou simplement de la mémoire partagée, il faut, par contre,
éviter d’imposer trop de contraintes à Oracle en donnant des valeurs minimums aux paramètres gérés
automatiquement.
En interne, les paramètres __* (__db_cache_size par exemple) sont utilisés par les fonctionnalités de gestion
automatique. Ils donnent la quantité de mémoire actuellement allouée à chaque structure gérée
automatiquement ; le paramètre « normal » (non préfixé par les deux caractères soulignés) donne la valeur
minimale du paramètre, telle que vous avez pu la définir (0 sinon). La valeur de ces paramètres internes est
enregistrée dans le fichier de paramètres serveur (s’il est utilisé) ; en cas de redémarrage, la configuration mémoire,
qui était utilisée au moment de l’arrêt (a priori optimale), sera rétablie.
4. Utiliser le Database Control
a. Accès à la page de gestion de la mémoire
Dans le Database Control, cliquez sur le lien Serveur sur la page d’accueil puis sur le lien Fonctions de conseil sur
la mémoire (cadre Configuration de base de données) pour accéder à la page de gestion des paramètres de
mémoire.
Le contenu de la page dépend du mode de gestion de la mémoire.
Pour affecter une valeur minimum à un paramètre de la SGA géré automatiquement, ou pour affecter une
valeur à un paramètre de la SGA géré manuellement, vous devez passer par la page Paramètres
d’initialisation (cf. la section Gestion des paramètres d’initialisation).
b. Avec la gestion automatique de la mémoire
Lorsque la gestion automatique de la mémoire est activée, le Database Control montre l’historique de la répartition
de la mémoire entre la SGA et la PGA.
- 8-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Dans la deuxième partie de l’écran, l’onglet SGA affiche la répartition de la SGA entre les différentes composantes
(avec l’historique de la répartition) et l’onglet PGA, quelques informations sur la PGA :
© ENI Editions - All rights reserved - Algeria Educ
- 9-
Dans la première partie de la fenêtre, la zone Taille totale de mémoire permet de modifier la taille de la mémoire
(paramètre MEMORY_TARGET) et la zone Taille maximale de mémoire, la taille maximum de la mémoire (paramètre
MEMORY_MAX_TARGET).
Vous pouvez cocher la case Appliquer les modifications uniquement au fichier SPFILE (tout en bas de l’écran) si
vous souhaitez que les modifications n’affectent que le fichier de paramètres serveur (SCOPE=SPFILE). Par défaut, les
modifications affectent l’instance actuelle et le fichier de paramètres serveur (SCOPE=BOTH) ; le Database Control
vous proposera en conséquence de redémarrer si vous modifiez la taille maximum de la mémoire (paramètre
statique). Cliquez sur le bouton Désactiver si vous souhaitez désactiver la gestion automatique de la mémoire.
Dans la nouvelle configuration, la gestion automatique de la mémoire partagée est activée.
c. Avec la gestion automatique de la mémoire partagée
Lorsque la gestion automatique de la mémoire partagée est activée, le Database Control permet de régler
séparément la taille de la SGA et la taille de la PGA.
- 10 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Dans l’onglet SGA, le Database Control affiche la répartition de la SGA entre les différentes composantes (avec
l’historique de la répartition). La zone Taille totale de mémoire SGA (Mo) permet de modifier la taille de la SGA
(paramètre SGA_TARGET) et la zone Taille maximale de mémoire SGA (MB), la taille maximum de la SGA (paramètre
SGA_MAX_SIZE).
Dans l’onglet PGA, le Database Control affiche quelques informations sur la PGA. La zone Cible d’agrégation de la
mémoire PGA permet de modifier la taille de la PGA (paramètre PGA_AGGREGATE_TARGET).
© ENI Editions - All rights reserved - Algeria Educ
- 11 -
La case Appliquer les modifications uniquement au fichier SPFILE a le même rôle qu’avec la gestion automatique
de la mémoire. Le Database Control vous proposera notamment de redémarrer si vous modifiez la taille maximum
de la SGA (paramètre statique).
En haut de l’écran, vous pouvez cliquer sur le bouton Activer pour activer la gestion automatique de la mémoire. Le
Database Control vous invite alors à régler la taille de la mémoire (paramètre MEMORY_TARGET) et la taille maximum
de la mémoire (paramètre MEMORY_MAX_TARGET) :
À l’inverse, dans l’onglet SGA, vous pouvez cliquer sur le bouton Désactiver pour désactiver la gestion automatique
de la mémoire partagée. Le Database Control vous invite alors à régler la taille des différents composants de la SGA
qui sont gérés automatiquement :
d. Sans la gestion automatique
Lorsque la gestion automatique de la mémoire partagée est désactivée, l’onglet SGA se présente ainsi :
- 12 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
La Database Control affiche la taille des structures de la SGA qui sont gérées automatiquement, ainsi que la taille
maximum de la SGA, et permet de les modifier (voir ci­dessus pour le fonctionnement).
Cliquez sur le bouton Activer de l’onglet SGA si vous souhaitez activer la gestion automatique de la mémoire
partagée. Le Database Control vous invite alors à régler la taille de la SGA (SGA_TARGET) :
Comme dans le point précédent, le bouton Activer situé tout en haut de l’écran permet d’activer la gestion
automatique de la mémoire.
5. Problèmes courants et solutions
ORA-00845: MEMORY_TARGET non pris en charge sur ce système
Explication
La gestion automatique de la mémoire partagée ne peut pas être activée.
Cause(s)
La plate­forme n’est pas supportée ou, sur plate­forme Linux, /dev/shm n’est pas dimensionné correctement.
Action(s)
Si vous êtes sur une plate­forme Linux, redimensionnez /dev/shm ou diminuez la valeur de MEMORY_TARGET (voir la
© ENI Editions - All rights reserved - Algeria Educ
- 13 -
documentation "Administrator’s Reference for Linux and UNIX­Based Operating Systems").
Lorsque vous modifiez la valeur d’un paramètre de mémoire avec une valeur erronée (trop grande ou trop petite)
vous obtenez une erreur ORA-02097 (cf. section Gestion des paramètres dans ce chapitre), suivie d’une deuxième
erreur qui précise la nature du problème.
Les principaux cas sont les suivants :
■
MEMORY_TARGET trop grand
ORA-00837: la valeur de MEMORY_TARGET est supérieure à celle de MEMORY_MAX_TARGET
■
MEMORY_TARGET trop petit
ORA-00838: la valeur de MEMORY_TARGET est trop petite ; elle doit être de nnn Mo au minimum
ORA-00846: impossible de réduire MEMORY_TARGET a la valeur indiquée
■
SGA_TARGET trop grand
ORA-00823: la valeur de sga_target est supérieure a celle de sga_max_size
■
SGA_TARGET trop petit
ORA-00827: impossible de réduire sga_target a la valeur indiquée
■
PGA_AGGREGATE_TARGET trop grand par rapport à MEMORY_TARGET
ORA-00840: la valeur de PGA_AGGREGATE_TARGET ne peut pas être changée pour la valeur indiquée
■
PGA_AGGREGATE_TARGET hors limites
ORA-00093: pga_aggregate_target doit être compris entre 10M et 4096G-1
■
DB_CACHE_SIZE (ou DB_nk_CACHE_SIZE) trop grand par rapport à la mémoire disponible pour la SGA
ORA-00384: mémoire insuffisante pour faire évoluer le cache
■
*_POOL_SIZE trop grand par rapport à la mémoire disponible pour la SGA
ORA-04033: mémoire insuffisante pour augmenter la taille du pool
■
*_POOL_SIZE trop petit
ORA-04034: impossible de réduire le pool a la taille indiquée.
- 14 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Gestion des fichiers de contrôle
1. Rappel sur le fichier de contrôle
Le fichier de contrôle contient des informations de contrôle sur la base de données :
●
le nom de la base de données ;
●
la date/heure de création de la base de données ;
●
l’emplacement des autres fichiers de la base de données (fichiers de données et fichiers de journalisation) ;
●
le numéro de séquence actuel des fichiers de journalisation ;
●
des informations sur les points de reprise (checkpoint), etc.
Le fichier de contrôle est automatiquement mis à jour par Oracle lors de chaque modification de la structure de la
base de données (ajout ou déplacement d’un fichier par exemple). La taille du fichier de contrôle est déterminée par
Oracle.
Lorsqu’une instance est lancée pour ouvrir une base de données, le fichier de contrôle est le premier fichier ouvert. Il
permet ensuite, à l’instance de localiser et d’ouvrir les autres fichiers de la base de données. Si le fichier de contrôle
ne peut pas être trouvé (ou est endommagé), la base de données ne peut pas être montée, même si les autres
fichiers de la base de données sont présents (l’instance reste dans le statut NOMOUNT). Différents scénarios de
restauration sont alors disponibles en fonction de la situation (présence ou non d’une sauvegarde du fichier de
contrôle, notamment) pour redémarrer la base de données, mais ce sont des scénarios relativement complexes.
Pour des raisons de sécurité, il est donc conseillé de multiplexer le fichier de contrôle, c’est­à­dire de disposer de
plusieurs copies gérées en miroir (multiplexées) par Oracle. Techniquement, il est possible de créer une base de
données avec un seul fichier de contrôle mais il est vivement conseillé d’utiliser plusieurs copies, même si le serveur
ne comprend qu’un disque (cela met à l’abri d’une suppression accidentelle).
Plusieurs fichiers de contrôle peuvent être spécifiés lors de la création de la base (chapitre Création d’une nouvelle
base de données) ou ultérieurement (voir ci­après).
2. Trouver des informations sur les fichiers de contrôle
La vue V$CONTROLFILEdonne la liste des fichiers de contrôle :
SQL> SELECT * FROM v$controlfile;
STATUS NAME
IS_ BLOCK_SIZE FILE_SIZE_BLKS
------- ------------------------------- --- ---------- -------------F:\ORADATA\HERMES\CONTROL01.CTL NO
16384
618
G:\ORADATA\HERMES\CONTROL02.CTL NO
16384
618
La colonne STATUS est normalement toujours vide. La colonne IS_RECOVERY_ DEST_FILE indique si le fichier de contrôle
est stocké dans la zone de récupération rapide (telle que définie par le paramètre DB_RECOVERY_FILE_DEST). Le
produit FILE_SIZE_ BLKS x BLOCK_SIZE donne la taille des fichiers de contrôles en octets.
Vous pouvez aussi interroger la vue V$CONTROLFILE_RECORD_SECTION pour obtenir des informations sur le contenu des
différentes sections du fichier de contrôle :
SQL> SELECT type,records_total,records_used
2 FROM v$controlfile_record_section;
TYPE
RECORDS_TOTAL RECORDS_USED
---------------------------- ------------- -----------DATABASE
1
1
CKPT PROGRESS
4
0
REDO THREAD
1
1
REDO LOG
16
3
DATAFILE
128
6
FILENAME
2370
13
TABLESPACE
128
7
© ENI Editions - All rights reserved - Algeria Educ
- 1-
...
Cette vue indique notamment le nombre maximum d’enregistrements possibles dans les différentes sections et le
nombre d’enregistrements actuellement utilisés. Dans notre exemple, il y a 6 enregistrements de fichiers de données
utilisés, sur les 128 possibles. Certaines limites proviennent des valeurs attribuées aux options MAX* de l’ordre SQL
CREATE DATABASE (MAXDATAFILES par exemple).
Certaines colonnes de la vue V$DATABASE donnent aussi des informations sur les fichiers de contrôle :
CONTROLFILE_CREATED
Date de création du fichier de contrôle.
CONTROLFILE_SEQUENCE#
Numéro de séquence du fichier de contrôle, incrémenté lors des mises à jour du fichier de contrôle.
CONTROLFILE_CHANGE#
Dernier numéro SCN (System Change Number) enregistré dans le fichier de contrôle.
CONTROLFILE_TIME
Date/heure de dernier enregistrement dans le fichier de contrôle.
CHECKPOINT_CHANGE#
Numéro SCN du dernier point de reprise.
CURRENT_SCN
Numéro SCN courant.
3. Multiplexer le fichier de contrôle
Comme indiqué précédemment, il est conseillé de faire fonctionner la base de données avec au moins, deux fichiers
de contrôle, si possible sur des disques différents (dans l’idéal, 3 ou 4 sur des disques différents).
Le multiplexage des fichiers de contrôle peut être mis en œ uvre lors de la création de la base de données, en
spécifiant la liste des fichiers de contrôle souhaités dans le paramètre CONTROL_FILES, avant d’exécuter l’ordre SQL
CREATE DATABASE (voir le chapitre Création d’une nouvelle base de données).
Le multiplexage peut aussi être mis en œ uvre (ou renforcé) ultérieurement. Pour cela, il faut arrêter proprement la
base de données, dupliquer un fichier de contrôle existant vers le nouvel emplacement, mentionner le nouveau fichier
de contrôle dans le paramètre CONTROL_FILES (paramètre statique) et redémarrer la base de données. Si vous utilisez
un fichier de paramètres serveur (conseillé), vous devez modifier le paramètre CONTROL_ FILES avant d’arrêter la base
de données.
Le mode opératoire est alors le suivant :
●
spécifier l’emplacement du nouveau fichier de contrôle dans le fichier de paramètres serveur :
SQL> ALTER SYSTEM SET CONTROL_FILES = ’f:\oradata\hermes\control01.ctl’,
2
’g:\oradata\hermes\control02.ctl’,
3
’e:\oradata\hermes\control03.ctl’
4 SCOPE = SPFILE;
●
arrêter la base proprement (pas ABORT !) :
SQL> SHUTDOWN IMMEDIATE
●
dupliquer un fichier de contrôle existant vers le nouvel emplacement :
SQL> HOST copy f:\oradata\hermes\control01.ctl >
e:\oradata\hermes\control03.ctl
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
●
redémarrer la base de données :
SQL> STARTUP
●
Vérifier :
SQL> SELECT name FROM v$controlfile;
NAME
----------------------------------------------F:\ORADATA\HERMES\CONTROL01.CTL
G:\ORADATA\HERMES\CONTROL02.CTL
E:\ORADATA\HERMES\CONTROL03.CTL
Une technique similaire peut être utilisée pour déplacer un fichier de contrôle d’un emplacement à un autre ou
supprimer un fichier de contrôle.
La duplication du fichier de contrôle doit se faire sur un fichier de contrôle cohérent. Il ne faut donc pas
dupliquer le fichier de contrôle alors que la base de données est ouverte ou après un SHUTDOWN ABORT (le
fichier de contrôle n’a pas été fermé proprement). Si la copie du fichier de contrôle n’est pas jugée cohérente par
Oracle, une erreur se produira au redémarrage.
En complément, nous verrons au chapitre Sauvegarde et récupération quand et comment sauvegarder le fichier de
contrôle, et comment récupérer une base de données en cas de perte d’un fichier de contrôle.
4. Utiliser le Database Control
Dans le Database Control>, cliquez sur le lien Serveur sur la page d’accueil puis, sur le lien Fichiers de contrôle
(cadre Stockage) pour accéder à la page d’information sur les fichiers de contrôle :
Les trois onglets donnent des informations sur les fichiers de contrôle, en provenance des vues V$CONTROLFILE,
V$DATABASE et V$CONTROLFILE_RECORD_SECTION. Le Database Control ne propose pas de moyen simple pour multiplexer
les fichiers de contrôle.
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Gestion des fichiers de journalisation
1. Rappel sur les fichiers de journalisation
Les fichiers de journalisation (redo log) enregistrent toutes les modifications apportées à la base de données. Ils sont
organisés en groupes écrits de manière circulaire ; les informations sauvegardées sont donc, par défaut,
périodiquement écrasées.
Les fichiers de journalisation sont utilisés pour la restauration de l’instance après un arrêt anormal et pour la
restauration de média si un fichier de données est perdu ou endommagé ; dans ce cas, ils sont appliqués à une
sauvegarde de fichier de données, pour rejouer toutes les modifications survenues entre la sauvegarde et l’incident
ayant endommagé le fichier.
Les fichiers de journalisation sont organisés en groupes (au minimum 2) composés d’un ou de plusieurs membres
(minimum 1) ; ils sont créés lors de la définition de la base (chapitre Création d’une nouvelle base de données). À
l’intérieur d’un groupe, les membres sont écrits simultanément en miroir par l’instance Oracle (processus LGWR) et
contiennent la même information. Tous les membres d’un groupe ont la même taille définie lors de la création du
groupe ; un fichier de journalisation contient donc une quantité maximale d’informations. De même, le nombre de
groupe est déterminé ; il n’augmente pas dynamiquement.
Lorsqu’un groupe est plein (c’est­à­dire lorsque les membres sont pleins), l’instance Oracle passe au groupe suivant
et ainsi de suite jusqu’au dernier ; lorsque le dernier groupe est plein, l’instance Oracle repasse au premier. Le
passage d’un groupe à un autre est appelé basculement (switch).
Lorsque l’instance Oracle revient dans le premier groupe, elle écrase les informations qui y sont stockées ; ces
informations ne sont donc plus disponibles en cas de besoin, par exemple pour une restauration de média. Afin de
garantir cette possibilité d’effectuer des restaurations complètes, il faut activer le mécanisme d’archivage (chapitre
Sauvegarde et récupération) qui permet d’archiver les fichiers de journalisation (en l’occurrence un membre du
groupe) lorsqu’ils sont pleins, avant que l’instance ne les réutilise.
Si un groupe possède plusieurs membres et qu’un des membres soit indisponible, la base de données peut continuer
à fonctionner.
Les fichiers de journalisation sont très importants pour la sécurité de la base de données. Il est donc conseillé
d’utiliser au minimum deux ou trois membres par groupe (multiplexage), si possible sur des disques différents.
2. Trouver des informations sur les fichiers de journalisation
Plusieurs vues du dictionnaire permettent d’obtenir des informations sur les fichiers de journalisation :
●
V$LOG : informations sur les groupes ;
●
V$LOGFILE : informations sur les membres ;
●
V$LOG_HISTORY : informations sur l’historique des fichiers de journalisation.
Les colonnes intéressantes des différentes vues sont présentées ci­après.
V$LOG
GROUP#
Numéro du groupe.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
SEQUENCE#
Numéro de séquence du groupe (s’incrémente à chaque basculement).
BYTES
Taille en octets.
MEMBERS
Nombre de membres.
ARCHIVED
Groupe archivé (YES ou NO).
STATUS
Statut du groupe :
●
UNUSED : groupe jamais écrit (sans doute nouveau) ;
●
CURRENT : groupe courant (groupe en cours d’écriture) ;
●
ACTIVE : groupe encore nécessaire en cas de restauration d’instance (point de reprise non terminé) ;
●
INACTIVE : groupe inutile pour une restauration d’instance (point de reprise terminé).
FIRST_CHANGE#
Plus petit numéro SCN écrit dans le groupe.
FIRST_TIME
Date et heure du plus petit numéro SCN.
V$LOGFILE
GROUP#
Numéro du groupe.
STATUS
Statut du membre :
●
INVALID : fichier inaccessible ;
●
STALE : fichier incomplet (statut des nouveaux membres) ;
●
DELETED : fichier supprimé, plus utilisé ;
●
vide : fichier utilisé.
MEMBER
Nom complet du fichier membre
IS_RECOVERY_DEST_FILE
Indique (YES ou NO) si le membre est stocké dans la zone de récupération rapide (telle que définie par le paramètre
- 2-
© ENI Editions - All rights reserved - Algeria Educ
DB_RECOVERY_ FILE_DEST).
V$LOG_HISTORY
SEQUENCE#
Numéro de séquence du groupe.
FIRST_CHANGE#
Plus petit numéro SCN écrit dans le groupe.
NEXT_CHANGE#
Plus grand numéro SCN écrit dans le groupe.
FIRST_TIME
Date et heure du plus petit numéro SCN écrit dans le groupe.
Exemple :
SQL> SELECT group#,sequence#,bytes/(1024*1024) size_mo,members,status
2 FROM v$log;
GROUP# SEQUENCE#
SIZE_MO
MEMBERS STATUS
------ ---------- ---------- ---------- ---------------1
16
50
2 INACTIVE
2
17
50
2 CURRENT
3
18
50
2 INACTIVE
SQL> SELECT group#,status,member,is_recovery_dest_file
2 FROM v$logfile
3 ORDER BY group#;
GROUP# STATUS MEMBER
IS_RECOVERY_DEST_FILE
------ ------- ------------------------------ --------------------1
F:\ORADATA\HERMES\REDO01A.LOG NO
1
G:\ORADATA\HERMES\REDO01B.LOG NO
2
F:\ORADATA\HERMES\REDO02A.LOG NO
2
G:\ORADATA\HERMES\REDO02B.LOG NO
3
F:\ORADATA\HERMES\REDO03A.LOG NO
3
G:\ORADATA\HERMES\REDO03B.LOG NO
SQL> SELECT sequence#,TO_CHAR(first_time,’DD/MM HH24:MI’) first_time
2 FROM v$log_history;
SEQUENCE# FIRST_TIME
--------- -----------1 16/07 14:53
2 16/07 14:55
3 16/07 14:56
15 16/07 15:17
16 16/07 15:19
17 16/07 15:25
3. Dimensionner les fichiers de journalisation
Déterminer le nombre de groupes et la taille des groupes est un sujet complexe pour lequel il n’existe pas de formule
de calcul. Par contre, il est possible, a posteriori, d’auditer le fonctionnement des fichiers de journalisation afin de voir
si le nombre de groupes et la taille des groupes sont satisfaisants ; en cas de problème, il est relativement simple
d’apporter des corrections en ajoutant un nouveau groupe ou en augmentant la taille des groupes (cette action est
un peu plus complexe).
L’objectif est simple :
●
openmirrors.com
Utiliser des fichiers de journalisation de taille suffisante pour éviter des basculements trop fréquents,
pénalisants pour les performances. La recommandation d’Oracle est d’avoir un basculement toutes les 20 à
© ENI Editions - All rights reserved - Algeria Educ
- 3-
30 minutes environ.
Utiliser un nombre suffisant de groupes pour permettre aux points de reprise et à l’archivage de se terminer
avant que l’instance ne revienne sur un fichier de journalisation. Si le point de reprise ou l’archivage ne sont
pas terminés, le processus LGWR attend, ce qui est très mauvais pour les performances.
●
Avoir des basculements peu fréquents (plus de 4 heures par exemple), et donc des points de reprise peu fréquents,
combinés à une forte activité de mise à jour (possible avec des fichiers de journalisation volumineux), est bénéfique
pour les performances mais cela risque, en cas d’arrêt anormal de l’instance, d’augmenter la durée de la récupération
de l’instance et donc, la durée du redémarrage. La recommandation d’Oracle est de trouver un bon compromis entre
la performance en fonctionnement normal et la performance du redémarrage, en cas d’arrêt anormal de l’instance.
Le fichier d’alerte de l’instance (voir la section Diagnostiquer les problèmes du chapitre Les outils d’administration)
peut être utilisé comme premier outil d’audit simple de l’activité des fichiers de journalisation. Les informations à
surveiller sont les suivantes :
Basculement de fichier de journalisation :
●
Wed Jul 16 15:25:04 2008
Thread 1 advanced to log sequence 17
Current log# 2 seq# 17 mem# 0: F:\ORADATA\HERMES\REDO02A.LOG
Current log# 2 seq# 17 mem# 1: G:\ORADATA\HERMES\REDO02B.LOG
Attente lors d’un basculement de fichier de journalisation :
●
●
Point de reprise non terminé
Wed Jul 16 15:17:28 2008
Thread 1 cannot allocate new log, sequence 15
Checkpoint not complete
●
Archivage non terminé
Wed Jul 16 15:19:02 2008
Thread 1 cannot allocate new log, sequence 16
All online logs needed archiving
La vue V$LOG_HISTORY peut aussi être utilisée pour analyser la vitesse de basculement des fichiers de journalisation.
Si la durée qui sépare les messages de ce type est systématiquement courte, les fichiers de journalisation sont mal
dimensionnés. Si cette situation de basculements rapprochés (ou de basculements temporairement bloqués) est rare
(une fois par jour par exemple), le dimensionnement est satisfaisant (la situation est peut être liée à un batch qui
génère un pic de l’activité transactionnelle).
En cas de basculement trop rapide (largement inférieur à 20/30 minutes), il faut augmenter la taille des groupes.
En cas d’attentes fréquentes lors d’un basculement, il faut ajouter un groupe (le processus LGWR mettra plus de
temps à faire le tour des groupes, ce qui laissera plus de temps au point de reprise ou à l’archivage pour se
terminer).
Les opérations d’ajout d’un groupe ou d’augmentation de la taille des groupes sont présentées dans la suite de ce
chapitre.
4. Administrer les fichiers de journalisation
a. Vue d’ensemble
Différentes opérations d’administration peuvent être effectuées sur les fichiers de journalisation :
●
●
- 4-
Ajouter un nouveau membre dans un groupe permet d’améliorer la sécurité des fichiers de journalisation
(multiplexage).
Ajouter un nouveau groupe permet d’améliorer la disponibilité des fichiers de journalisation pour le
processus LGWR, en augmentant la durée d’un cycle complet de rotation.
© ENI Editions - All rights reserved - Algeria Educ
●
●
●
●
Déplacer un membre permet d’améliorer la répartition des entrées/sorties par exemple.
Supprimer un groupe peut être utilisé dans une opération d’augmentation de la taille des groupes (ajout
d’un nouveau groupe plus gros puis suppression d’un ancien).
Supprimer un membre d’un groupe s’il est endommagé par exemple.
Forcer le basculement du groupe courant au suivant peut être utilisé dans l’opération d’augmentation de
taille.
Il n’existe pas de commande pour modifier la taille des groupes ; la technique consiste à ajouter des groupes ayant
la taille souhaitée et à supprimer les anciens groupes. Supprimer un groupe ne sera pas possible si c’est le groupe
courant ; la commande permettant de forcer un basculement peut alors être utilisée pour éviter d’attendre. Sinon,
supprimer un groupe ou forcer le basculement du groupe courant au suivant sont des opérations rarement utilisées
en elles­mêmes.
b. Ajouter un nouveau membre à un groupe (multiplexage)
Nous avons vu que le multiplexage des fichiers de journalisation pouvait être mis en œ uvre lors de la création de la
base de données (voir la section Création de la base de données à la main du chapitre Création d’une nouvelle
base de données). Il suffit de spécifier plusieurs membres pour chaque groupe listé dans la clause LOGFILE de
l’ordre SQL CREATE DATABASE.
Le multiplexage des fichiers de journalisation peut aussi être mis en œ uvre (ou renforcé) ultérieurement, à l’aide de
l’ordre SQL ALTER DATABASE.
Syntaxe simplifiée :
ALTER DATABASE
ADD LOGFILE MEMBER ’nom_fichier’ [,...] TO GROUP numéro;
Exemple :
ALTER DATABASE
ADD LOGFILE MEMBER ’e:\oradata\HERMES\redo01c.log’ TO GROUP 1;
La taille du fichier n’a pas besoin d’être spécifiée ; le nouveau fichier a forcément la même taille que les autres
membres du groupe. Notez aussi que le nouveau membre aura un statut INVALID dans V$LOGFILE ; c’est normal et
le statut changera lorsque le fichier sera utilisé.
Même s’il est techniquement possible d’avoir des groupes qui n’ont pas le même nombre de membres, c’est
normalement une situation temporaire. Bien protéger tous les groupes sauf un, est périlleux ; la loi de Murphy
indique que si un incident doit se produire, il aura lieu sur le groupe mal protégé.
c. Ajouter un nouveau groupe
Ajouter un nouveau groupe peut être réalisé à l’aide de l’ordre SQL ALTER DATABASE.
Syntaxe :
ALTER DATABASE
ADD LOGFILE [GROUP numéro] spécification_fichier_redo [,...] ;
- spécification_fichier_redo
(’nom_fichier’ [,...]) [ SIZE valeur [K|M|G] ] [REUSE]
Avec :
numéro
Numéro du groupe. Si l’option est absente, Oracle numérote les groupes 1, 2... (ce qui est bien).
nom_fichier
Chemin d’accès complet à un fichier membre du groupe, normalement dans un répertoire de données (oradata) pour
respecter le standard OFA.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 5-
SIZE
Taille de chaque membre du groupe en octets (pas de symbole), Ko (symbole K), Mo (symbole M) ou Go (symbole G).
La taille peut être omise uniquement si l’option REUSE est utilisée et que le fichier existe déjà.
REUSE
Si l’option est présente et que le fichier existe déjà, Oracle le réutilise et l’écrase. Si l’option est absente, dans la
même situation, un message d’erreur s’affiche et la création de la base de données est stoppée. Du point de vue de
la sécurité, il est préférable de ne pas utiliser cette option afin d’éviter d’écraser par mégarde un fichier de
journalisation utilisé par une autre base de données.
Exemple :
ALTER DATABASE
ADD LOGFILE
GROUP 4 (’e:\oradata\hermes\redo04a.log’,
’g:\oradata\hermes\redo04b.log’) SIZE 50M;
Sauf opération d’augmentation de la taille des groupes, le nouveau groupe présente normalement la même taille
que les autres ; avoir des groupes de tailles différentes ne présente aucun intérêt.
d. Déplacer un membre
Le mode opératoire pour déplacer un fichier de journalisation est le suivant :
●
arrêter la base de données (proprement, pas ABORT) :
SQL> SHUTDOWN IMMEDIATE
●
déplacer le(s) fichier(s) de journalisation vers le nouvel emplacement :
SQL> HOST move e:\oradata\hermes\redo04a.log >
f:\oradata\hermes\redo04a.log
●
monter la base de données :
SQL> STARTUP MOUNT
●
utiliser l’ordre SQL ALTER DATABASE RENAME FILE pour indiquer à Oracle le nouvel emplacement :
SQL> ALTER DATABASE
2 RENAME FILE ’e:\oradata\hermes\redo04a.log’
3 TO ’f:\oradata\hermes\redo04a.log’;
●
ouvrir la base de données :
SQL> ALTER DATABASE OPEN;
La syntaxe de l’ordre SQL ALTER DATABASE RENAME FILE est la suivante :
ALTER DATABASE
RENAME FILE ’ancien_nom_complet’ [,...]
TO ’nouveau_nom_complet’ [,...];
Exemple :
ALTER DATABASE
RENAME FILE ’e:\oradata\hermes\redo04a.log’
TO ’f:\oradata\hermes\redo04a.log’;
Notez bien que l’ordre SQL ALTER DATABASE RENAME FILE ne renomme pas, ni ne déplace le fichier physique ; cette
opération doit être effectuée par une commande du système d’exploitation. L’ordre SQL ALTER DATABASE RENAME
- 6-
© ENI Editions - All rights reserved - Algeria Educ
FILE sert juste à indiquer à Oracle le nouvel emplacement ou le nouveau nom d’un fichier (Oracle met à jour en
conséquence le fichier de contrôle).L’ancien nom complet doit correspondre à un fichier appartenant à la base de
données, mais il peut ne plus exister physiquement ; par contre, Oracle vérifie que le fichier existe bien avec le
nouveau nom et/ou dans le nouvel emplacement (et que le fichier est valide).
e. Supprimer un groupe
Supprimer un groupe peut être réalisé à l’aide de l’ordre SQL ALTER DATABASE.
Syntaxe :
ALTER DATABASE
DROP LOGFILE GROUP numéro ;
Exemple :
ALTER DATABASE
DROP LOGFILE GROUP 4;
La base de données doit avoir au moins 3 groupes de fichiers de journalisation pour pouvoir en supprimer un (il doit
rester au moins 2 groupes).
Seul un groupe au statut INACTIVE peut être supprimé. Le groupe courant (celui dans lequel le processus LGWR est
en train d’écrire) ne peut pas être supprimé ; il en est de même si le groupe a le statut ACTIVE (groupe encore
nécessaire en cas de restauration d’instance). En mode ARCHIVELOG, un groupe non encore archivé ne peut pas être
supprimé.
Les fichiers concernés ne sont pas physiquement supprimés par Oracle ; il faut les supprimer manuellement, à l’aide
d’une commande du système d’exploitation.
f. Supprimer un membre d’un groupe
Supprimer un membre d’un groupe peut être réalisé à l’aide de l’ordre SQL ALTER DATABASE.
Syntaxe :
ALTER DATABASE
DROP LOGFILE MEMBER ’nom_fichier’ [,...]
Exemple :
ALTER DATABASE
DROP LOGFILE MEMBER ’g:\oradata\hermes\redo01b.log’;
Le groupe concerné doit avoir au moins 2 membres pour pouvoir en supprimer un (il doit toujours au moins exister
un membre valide par groupe) ; si le groupe a deux membres dont un invalide, vous ne pourrez pas supprimer le
membre valide. Pour supprimer tous les membres d’un groupe, il faut en fait supprimer le groupe (point précédent).
Le tableau suivant indique si un membre peut être supprimé en fonction du statut du groupe :
Status du groupe
Membre supprimable ?
CURRENT
Non
ACTIVE
Non
INACTIVE
Oui
En mode ARCHIVELOG, un membre d’un groupe non encore archivé ne peut pas être supprimé. Les fichiers concernés
ne sont pas physiquement supprimés par Oracle ; il faut les supprimer manuellement, à l’aide d’une commande du
système d’exploitation.
g. Forcer le basculement du groupe courant au suivant
Forcer le basculement du groupe courant au suivant peut être réalisé à l’aide de l’ordre SQL ALTER SYSTEM.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 7-
Syntaxe :
ALTER SYSTEM SWITCH LOGFILE;
Le basculement manuel provoque les mêmes événements qu’un basculement automatique :
●
point de reprise ;
●
archivage (si l’archivage est activé).
5. Contrôler la fréquence des points de reprise
Par défaut, les points de reprise se déclenchent lors d’un basculement de fichier de journalisation.
Lorsque les fichiers de journalisation sont gros et que les basculements sont peu fréquents, cela peut conduire à des
redémarrages un peu longs en cas d’arrêt anormal de l’instance (beaucoup de modifications à apporter aux fichiers
de données pour les remettre en état).Dans ce genre de situation, il peut être intéressant de contrôler la fréquence
des points de reprise et de faire en sorte d’avoir des points de reprise intermédiaires, entre les basculements de
fichiers de journalisation.
La méthode recommandée consiste à utiliser le paramètre FAST_START_MTTR_TARGET qui indique le nombre maximum
de secondes souhaité pour le redémarrage de l’instance, après un arrêt anormal. Une fois que ce paramètre est
positionné, l’instance ajuste automatiquement la fréquence des points de reprise afin de ne pas avoir trop d’activité à
rejouer dans les fichiers de données, en cas d’arrêt anormal de l’instance.
Des points de reprise trop fréquents peuvent dégrader les performances de l’activité courante ; il faut
trouver le juste équilibre …
La vue V$INSTANCE_RECOVERY peut être utilisée pour superviser le temps estimé de restauration de l’instance. Cette
vue contient notamment les colonnes suivantes :
TARGET_MTTR
Objectif réel de durée de récupération maximum, recalculé par Oracle, en fonction du contexte ; tient compte de la
valeur du paramètre FAST_START_MTTR_TARGET mais aussi, d’autres facteurs.
ESTIMATED_MTTR
Durée de récupération estimée actuellement compte tenu de l’activité de l’instance.
OPTIMAL_LOGFILE_SIZE
Taille optimale des fichiers de journalisation (en Mo) permettant d’atteindre l’objectif (valeur actuelle du paramètre
FAST_START_ MTTR_TARGET) uniquement avec les points de reprises liés aux basculements des fichiers de
journalisation.
Si le paramètre FAST_START_MTTR_TARGET est réglé à une valeur trop basse, la durée effective de recouvrement est
déterminée au mieux de ce que le système est capable de faire, compte tenu du contexte. Si le paramètre
FAST_START_MTTR_TARGET est réglé à une valeur élevée, telle que, même dans le pire des cas, le recouvrement serait
plus court, la durée effective de recouvrement est estimée par rapport au scénario le pire : tous les blocs sont
modifiés dans le Buffer Cache, pour des transactions validées, et aucun n’a encore été écrit sur disque, dans les
fichiers de données.
Exemple :
SQL> SELECT value FROM v$parameter
2 WHERE name = ’fast_start_mttr_target’;
VALUE
-------------------60
SQL> SELECT target_mttr,estimated_mttr,optimal_logfile_size
2 FROM v$instance_recovery;
TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE
----------- -------------- --------------------
- 8-
© ENI Editions - All rights reserved - Algeria Educ
30
18
99
Si le paramètre FAST_START_MTTR_TARGET n’est pas défini, la colonne TARGET_MTTR est égale à 0 et la colonne
OPTIMAL_LOGFILE_SIZE est vide ; par contre, la colonne ESTIMATED_MTTR est renseignée.
6. Utiliser le Database Control
Dans le Database Control, cliquez sur le lien Serveur sur la page d’accueil puis, sur le lien Groupes de fichiers de
journalisation (cadre Stockage) pour accéder à la page de gestion des fichiers de journalisation :
À partir de cette page, vous pouvez effectuer diverses actions sur les groupes de fichiers de journalisation :
●
créer un nouveau groupe (bouton Créer ou menu Créer comme) ;
●
supprimer un groupe (bouton Supprimer) ;
●
forcer le basculement du groupe courant au suivant (menu Changer de fichier journal) ;
●
forcer un point de reprise (menu Forcer l’application d’un point de reprise).
En cliquant sur le lien du numéro de groupe ou en cliquant sur les boutons Modifier ou Visualiser, vous arrivez sur la
page de gestion des membres du groupe :
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 9-
Cette page permet d’ajouter, supprimer, ou modifier un membre. Notez que le Database Control n’effectue aucune
action sur les fichiers physiques (suppression, déplacement, renommage) ; ces opérations doivent être effectuées
manuellement au niveau du système d’exploitation.
- 10 -
© ENI Editions - All rights reserved - Algeria Educ
Vue d’ensemble et directives
1. Vue d’ensemble
Un tablespace est une unité logique de stockage composée d’un ou plusieurs fichiers physiques (fichiers de
données).
Dans le Database Control, le tablespace est appelé "espace disque logique" ; dans cet ouvrage, nous
utiliserons le terme "tablespace".
La majorité des opérations d’administration relatives au stockage s’effectue au niveau du tablespace, et non au
niveau des fichiers de données.
À l’intérieur d’un tablespace, le stockage est organisé en segments, composés d’une ou plusieurs extensions (extent).
Ces extensions peuvent être gérées "par le dictionnaire" ou "localement". Dans le premier cas (tablespace< géré par
le dictionnaire), les informations sur les extensions libres et allouées sont stockées dans des tables du dictionnaire
de données ; dans le second cas (tablespace géré localement), les informations sur les extensions libres et allouées
sont stockées dans l’en­tête des fichiers de données du tablespace.
En version 10, Oracle a introduit la notion de tablespace BIGFILE : un tablespace BIGFILE est un tablespace composé
d’un seul fichier de données qui peut être particulièrement volumineux (jusqu’à 2^32 blocs Oracle soit plus de 4
milliards de blocs). A contrario, un tablespace traditionnel, dorénavant appelé tablespace SMALLFILE, peut contenir
plusieurs fichiers de données (jusqu’à 1 022 fichiers), mais de taille plus limitée ("seulement" 2^22 blocs Oracle, soit
tout de même plus de 4 millions de blocs).
Lorsqu’un tablespace SMALLFILE contient plusieurs fichiers de données, les fichiers sont généralement situés sur des
disques différents avec deux objectifs possibles :
●
allouer de l’espace supplémentaire à un tablespace dont le fichier de données initial ne peut plus s’étendre ;
●
répartir le stockage du tablespace sur plusieurs disques (striping au niveau d’Oracle).
Une base de données possède toujours au minimum deux tablespaces nommés SYSTEM et SYSAUX (tablespace SYStem
AUXiliaire, apparu en version 10). Le tablespace SYSTEM contient le dictionnaire de données. Le tablespace SYSAUX
contient les données de certains composants Oracle. Avant la version 10, ces données étaient stockées dans
plusieurs tablespaces ; l’utilisation d’un tablespace unique permet donc réduire le nombre de tablespaces utilisés par
une base de données. Normalement, les tablespaces SYSTEM et SYSAUX ne doivent pas contenir de données
utilisateur. En complément, une base de données contient souvent (vivement conseillé) deux tablespaces particuliers,
utilisés en interne par Oracle : le tablespace d’annulation (chapitre Gestion des informations d’annulation) et le
tablespace temporaire. Ces tablespaces "techniques" ne peuvent pas contenir de données utilisateur. Les
tablespaces autres que le tablespace d’annulation et le tablespace temporaire sont appelés "tablespaces
permanents".Un tablespace peut être ONLINE (accessible) ou OFFLINE. Rendre un tablespace OFFLINE est un moyen de
rendre certaines données de l’application temporairement inaccessibles, ou si la base de données abrite plusieurs
applications, de rendre une application inaccessible sans toucher à une autre.
Le tablespace SYSTEM doit toujours être ONLINE.
Un tablespace peut être READ WRITE (en lecture/écriture) ou READ ONLY (en lecture seule). Rendre un tablespace READ
ONLY est un moyen simple de garantir que les données qu’il contient ne seront jamais modifiées.
2. Directives
Les principales directives sur l’organisation des tablespaces sont les suivantes :
●
●
●
openmirrors.com
ne pas mettre de données utilisateur dans les tablespaces SYSTEM et SYSAUX ;
en plus des tablespaces SYSTEM et SYSAUX, créer au minimum ; un tablespace pour les segments d’annulation
(tablespace d’annulation) ; un tablespace pour les segments temporaires (tablespace temporaire) ; un
tablespace pour les tables ; un tablespace pour les index.
si possible, répartir les fichiers de données de ces tablespaces sur des disques différents.
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Le tablespace est l’unité de base de nombreuses tâches d’administration. La règle fondamentale est donc d’utiliser
plusieurs tablespaces pour séparer au maximum les différents types d’éléments et garantir une plus grande
souplesse dans les opérations d’administration. De plus, si le serveur possède plusieurs disques, il sera possible de
répartir les fichiers de données des tablespaces sur les différents disques pour éviter les contentions sur les
entrées/sorties.
Des variantes sont possibles concernant l’organisation des tablespaces. Si la base de données abrite plusieurs
applications, créez des tablespaces de tables et d’index différents pour chaque application.
Le tablespace SYSAUX peut être utilisé pour vos besoins d’administration (création de tables particulières) ; dans ce
cas, utilisez un schéma séparé.
Utiliser plusieurs tablespaces permet :
●
de séparer les données de l’application des données du dictionnaire Oracle ;
●
de séparer les données de plusieurs applications stockées dans la même base de données ;
●
de séparer le stockage des différents types d’objets ;
●
de répartir les entrées/sorties sur plusieurs disques ;
●
de réaliser des sauvegardes/restaurations partielles ;
●
de contrôler la disponibilité des données.
Pour les bases de données volumineuses et les serveurs comprenant plusieurs disques, vous pouvez utiliser deux
tablespaces (ou plus) pour les tables et deux tablespaces (ou plus) pour les index et répartir les fichiers de données
des tablespaces sur les différents disques.
Dans une telle configuration, l’idéal est d’avoir aussi les tablespaces SYSTEM, SYSAUX, annulation et temporaire sur des
disques différents, et de dédier d’autres disques aux fichiers de journalisation. Le serveur Oracle idéal doit posséder
au minimum une dizaine de disques. Dans la pratique, nous disposons bien souvent de moyens limités, et nous
essayons, dans ce cas, de répartir au mieux les entrées/sorties sur les différents disques.
Les recommandations d’Oracle vis­à­vis du stockage des fichiers de la base de données tiennent en un sigle : SAME
(Strip And Mirror Everything). En clair, Oracle recommande d’utiliser une technologie de type RAID0+1 sur chaque
axe : "Strip" (RAID0) pour les performances et "Mirror" (RAID1) pour la sécurité.
- 2-
© ENI Editions - All rights reserved - Algeria Educ
Tablespace permanent
1. Création d’un tablespace permanent
L’ordre SQL CREATE TABLESPACE permet de créer un tablespace permanent.
Syntaxe simplifiée
CREATE [ BIGFILE | SMALLFILE ] TABLESPACE nom
DATAFILE spécification_fichier [,...]
[ clause_gestion_extension ]
[ clause_gestion_segment ]
[ MINIMUM EXTENT valeur [K|M] ]
[ DEFAULT [ clause_compression ] [ clause_stockage ] ]
[ BLOCKSIZE valeur [K] ]
[ LOGGING | NOLOGGING ]
[ FORCE LOGGING ]
[ FLASHBACK { ON | OFF } ]
[ ONLINE | OFFLINE ] ;
- spécification_fichier
’nom_fichier’ [ SIZE valeur [K|M|G|T] ] [REUSE]
[ clause_auto_extension ]
- clause_auto_extension
AUTOEXTEND OFF
| AUTOEXTEND ON [ NEXT valeur [K|M|G|T] ]
[ MAXSIZE UNLIMITED | valeur [K|M|G|T] ]
- clause_gestion_extent
EXTENT MANAGEMENT DICTIONARY
| EXTENT MANAGEMENT LOCAL
{ AUTOALLOCATE | UNIFORM [ SIZE valeur [K|M|G|T] ] }
- clause_gestion_segment
SEGMENT SPACE MANAGEMENT { MANUAL | AUTO }
- clause_stockage
STORAGE ( [ INITIAL valeur [K|M] ]
[ NEXT valeur [K|M] ]
[ MINEXTENTS valeur ]
[ MAXEXTENTS { valeur | UNLIMITED } ]
[ PCTINCREASE valeur ] )
- clause_compression
COMPRESS [ FOR { ALL | DIRECT_LOAD } OPERATIONS ]
| NOCOMPRESS
Exemple :
Tablespace pour les tables, avec une gestion locale uniforme des extensions :
CREATE TABLESPACE data
DATAFILE ’e:\oradata\hermes\data01.dbf’ SIZE 500M
AUTOEXTEND ON NEXT 100M MAXSIZE 800M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 10M
SEGMENT SPACE MANAGEMENT AUTO;
Tablespace pour les index, avec une gestion locale automatique des extensions :
CREATE TABLESPACE indx
DATAFILE ’e:\oradata\hermes\indx01.dbf’ SIZE 500M
AUTOEXTEND ON NEXT 100M MAXSIZE 800M
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
SEGMENT SPACE MANAGEMENT AUTO;
Toutes les opérations relatives aux tablespaces et aux fichiers de données sont enregistrées dans le fichier
d’alerte de l’instance.
Les options de l’ordre SQL CREATE TABLESPACE sont :
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
BIGFILE | SMALLFILE
Cette clause indique si le tablespace est un tablespace BIGFILE ou SMALLFILE. Si cette clause est omise, Oracle utilise
le type par défaut défini au niveau de la base de données (voir la section Remarques sur les tablespaces BIGFILE).
nom
Nom du tablespace.
DATAFILE spécification_fichier
Cette clause permet de préciser l’emplacement, le nom et la taille d’un (ou éventuellement plusieurs) fichier de
données pour le tablespace. Un seul fichier de données peut être spécifié si le tablespace est de type BIGFILE.
La syntaxe est la suivante pour la spécification d’un fichier de données :
’nom_fichier’ [ SIZE valeur [K|M|G|T] ] [REUSE]
[ clause_auto_extend ]
nom_fichier
Chemin d’accès complet au fichier de données, normalement dans un répertoire de données (oradata) pour respecter
le standard OFA.
SIZE
Taille initiale du fichier. La taille peut être omise uniquement si l’option REUSE est utilisée et que le fichier existe déjà.
REUSE
Si l’option est présente et que le fichier existe déjà, Oracle le réutilise et l’écrase. Si l’option est absente, dans la
même situation, un message d’erreur s’affiche et la création du tablespace est stoppée. Du point de vue de la
sécurité, il est préférable de ne pas sélectionner cette option afin d’éviter d’écraser par mégarde un fichier de
données utilisé par une autre base de données.
- clause_auto_extend
AUTOEXTEND OFF
| AUTOEXTEND ON [ NEXT valeur [K|M|G|T] ]
[ MAXSIZE UNLIMITED | valeur [K|M|G|T] ]
AUTOEXTEND
Indique si le fichier de données peut (ON) ou non (OFF) grossir une fois que tout l’espace initialement alloué est utilisé.
NEXT
Espace minimum alloué au fichier lors de l’extension.
MAXSIZE
Taille maximale du fichier, éventuellement non limitée (UNLIMITED).
Toutes les tailles peuvent être exprimées en octets (pas de symbole), Ko (symbole K), Mo (symbole M), Go (symbole G)
ou To (symbole T). Les tailles en To ne sont autorisées que pour les tablespaces BIGFILE.
Si le fichier de données n’est pas autoextensible, un message d’erreur se produira si un segment stocké dans le
tablespace concerné n’a pas suffisamment d’espace lors de sa création initiale ou de son extension. Rendre le fichier
de données autoextensible permet de s’affranchir de ce genre de problème, jusqu’à la taille limite autorisée pour le
fichier. Si le fichier est autoextensible, la taille minimum d’extension est spécifiée par l’option NEXT. La taille réelle de
chaque extension sera égale à NEXT si la taille demandée est inférieure à NEXT et égale à la taille demandée dans le
cas contraire.
Exemple avec un NEXT de 500K :
●
- 2-
taille demandée = 200 Ko : 500 Ko alloués au fichier ;
© ENI Editions - All rights reserved - Algeria Educ
●
taille demandée = 750 Ko : 750 Ko alloués au fichier.
Attention à l’option UNLIMITED. Le disque dur n’est pas "illimité". Dans la pratique, il est préférable d’avoir un
message d’erreur d’Oracle indiquant qu’il a atteint la limite spécifiée plutôt que d’obtenir un message d’erreur
d’Oracle répercutant un message d’erreur du système indiquant que le disque est plein.
EXTENT MANAGEMENT ...
Cette clause permet de définir le mode de gestion des extensions à l’intérieur du tablespace (par le dictionnaire ou
localement). L’organisation du stockage dans un tablespace est présentée plus loin.
SEGMENT SPACE MANAGEMENT { MANUAL | AUTO }
Cette clause permet de définir le mode de gestion de l’espace libre des segments stockés dans le tablespace (voir le
chapitre Gestion des tables et des index). Cette clause n’est valide que pour un tablespace géré localement.
MINIMUM EXTENT valeur [K|M]
Cette clause permet de définir la taille minimale des extensions dans le tablespace. Toutes les extensions allouées
dans le tablespace auront une taille multiple de la taille minimale. Cette clause n’est valide que pour un tablespace
géré par le dictionnaire (un peu plus loin dans ce chapitre Organisation du stockage à l’intérieur d’un tablespace).
DEFAULT [ COMPRESS | NOCOMPRESS ] clause_stockage
Cette clause permet de définir une clause de stockage par défaut pour les segments qui seront créés dans le
tablespace sans clause de stockage. La partie clause_stockage (STORAGE...) n’est valide que pour un tablespace
géré par le dictionnaire ; la partie clause_compression est valide quel que soit le mode de gestion du tablespace.
L’organisation du stockage dans un tablespace est présentée au point Organisation du stockage à l’intérieur d’un
tablespace. Le stockage des segments est détaillé au chapitre Gestion des tables et des index.
BLOCKSIZE valeur [K]
Cette clause définit la taille de bloc utilisée par le tablespace. Les valeurs autorisées sont 2 Ko, 4 Ko, 8 Ko, 16 Ko et
32 Ko (certaines plates­formes sont plus restrictives). La valeur par défaut est la taille de bloc standard définie par le
paramètre DB_BLOCK_SIZE. Pour utiliser une taille de bloc non standard pour un tablespace, vous devez configurer un
pool pour cette taille de bloc dans le Buffer Cache, grâce à un des paramètres DB_nK_ CACHE_SIZEn valant 2, 4, 8, 16 ou
32). Si ce n’est pas le cas, vous obtiendrez l’erreur suivante
ORA-29339: la taille de bloc de tablespace nnnn ne correspond pas
aux tailles de blocs configurées
LOGGING | NOLOGGING
Cette clause définit le mode de journalisation par défaut des segments qui seront stockés dans le tablespace et pour
lesquels aucun mode de journalisation n’aura été défini. NOLOGGING supprime la journalisation de certaines opérations
(insertion par chargement direct, création de table à partir d’une requête, création ou reconstruction d’index). LOGGING
est l’option par défaut. L’option NOLOGGING est ignorée si le tablespace ou la base de données sont dans le mode
FORCE LOGGING.
FORCE LOGGING
Cette clause place le tablespace dans le mode FORCE LOGGING, ce qui permet de garantir que toutes les modifications
seront enregistrées dans les fichiers de journalisation, même si l’opération concernée est effectuée dans le mode
NOLOGGING.
FLASHBACK { ON | OFF }
Cette clause indique si le tablespace participe ou non aux opérations de FLASHBACK DATABASE (voir le chapitre
Sauvegarde et récupération).
ONLINE | OFFLINE
Cette clause indique si le tablespace est créé ONLINE (défaut) ou OFFLINE.
Depuis la version 11, un tablespace peut être chiffré (clause ENCRYPTION). Cette fonctionnalité, qui nécessite
l’option Advanced Security, n’est pas présentée dans cet ouvrage. Pour plus d’informations, consultez la
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
documentation "Oracle® Database Advanced Security Administrator’s Guide".
2. Remarques sur les tablespaces BIGFILE
Les tablespaces BIGFILE simplifient l’administration en offrant une transparence du fichier de données. Comme nous
le verrons par la suite, certaines opérations peuvent être réalisées directement sur le tablespace BIGFILE (par un
ordre SQL ALTER TABLESPACE) et non sur les fichiers de données, comme c’est le cas pour un tablespace SMALLFILE.
Les tablespaces BIGFILE sont forcément gérés localement (EXTENT MANAGEMENT LOCAL) avec une gestion automatique
de l’espace dans les segments (SEGMENT SPACE MANAGEMENTAUTO).
Exemple de tablespace BIGFILE
CREATE BIGFILE TABLESPACE je_suis_gros
DATAFILE ’e:\oradata\hermes\je_suis_gros.dbf’ SIZE 10G;
Les tablespaces BIGFILE sont plutôt destinés à être utilisés avec un gestionnaire de volumes logiques qui supporte le
striping ou le RAID. Si ce n’est pas le cas, il est possible de rencontrer des problèmes de performance avec l’exécution
en parallèle des requêtes ou la parallélisation des sauvegardes RMAN.
Un type par défaut SMALLFILE ou BIGFILE peut être défini au niveau de la base de données, soit lors de la création de
la base de données (clause SET DEFAULT TABLESPACE de l’ordre SQL CREATE DATABASE ­ voir la section Création de la
base de données à la main du chapitre Création d’une nouvelle base de données), soit ultérieurement grâce à l’ordre
SQL ALTER DATABASE.
Syntaxe :
ALTER DATABASE SET DEFAULT { SMALLFILE | BIGFILE } TABLESPACE ;
Le type par défaut actuel peut être consulté dans la vue DATABASE_PROPERTIES pour la propriété DEFAULT_TBS_TYPE :
SQL> SELECT property_value FROM database_properties
2 WHERE property_name = ’DEFAULT_TBS_TYPE’;
PROPERTY_VALUE--------------------------------------------------SMALLFILE
3. Tablespace permanent par défaut
Lorsqu’un utilisateur crée un segment sans préciser de tablespace (voir la section Organisation du stockage à
l’intérieur d’un tablespace), Oracle stocke le segment dans le tablespace par défaut de l’utilisateur.
Ce tablespace par défaut est défini grâce à la clause DEFAULT TABLESPACE des ordres SQL CREATE USER et ALTER USER
(voir le chapitre Gestion des utilisateurs et de leurs droits). Si cette clause est omise, c’est le tablespace SYSTEM qui
est affecté comme tablespace par défaut à l’utilisateur. Dans la pratique, ce comportement par défaut ne pose pas de
problème car les utilisateurs non DBA n’ont pas (normalement ­ c’est le cas par défaut) de quotas sur le tablespace
SYSTEM, et ne peuvent y créer de segments (voir le chapitre Gestion des utilisateurs et de leurs droits).
Depuis la version 10, dans le but de simplifier la gestion des utilisateurs, il est possible de définir un tablespace
permanent par défaut. Ce tablespace est affecté par défaut aux utilisateurs lors de leur création, lorsque la clause
DEFAULT TABLESPACE de l’ordre SQL CREATE USER est omise. Cette technique n’empêche pas d’utiliser d’autres
tablespaces permanents affectés spécifiquement à des utilisateurs pour des besoins particuliers.
Le tablespace permanent par défaut peut être défini lors de la création de la base de données, grâce à la clause
DEFAULT TABLESPACE de l’ordre SQL CREATE DATABASE.
Syntaxe
[ DEFAULT TABLESPACE nom
[ DATAFILE spécification_fichier [,...] ]
[ clause_extent_management ] ]
Exemple :
DEFAULT TABLESPACE deftbs
DATAFILE ’e:\oradata\hermes\deftbs01.dbf’ SIZE 10M
AUTOEXTEND ON NEXT 10M MAXSIZE 500M
- 4-
© ENI Editions - All rights reserved - Algeria Educ
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
Notez que le tablespace ainsi défini est obligatoirement de type SMALLFILE.
Pour créer et définir un tablespace permanent par défaut après la création de la base de données, vous devez :
créer un tablespace permanent, grâce à l’ordre SQL CREATE TABLESPACE présenté précédemment ;
●
le définir comme tablespace permanent par défaut, grâce à la clause DEFAULT TABLESPACE de l’ordre SQL ALTER
DATABASE.
●
Syntaxe
ALTER DATABASE DEFAULT TABLESPACE nom ;
nom doit désigner un tablespace permanent qui existe déjà.
Lorsque cet ordre SQL est exécuté, tous les utilisateurs à qui l’ancien tablespace permanent par défaut était affecté
se voient automatiquement attribuer le nouveau.
Pour retrouver le nom du tablespace permanent par défaut, vous pouvez interroger la vue DATABASE_PROPERTIESpour
la propriété DEFAULT_PERMANENT_TABLESPACE :
SQL> SELECT property_value FROM database_properties
2 WHERE property_name = ’DEFAULT_PERMANENT_TABLESPACE’ ;
PROPERTY_VALUE
-----------------------------DEFTBS
4. Modification d’un tablespace permanent
a. Vue d’ensemble
Après création, il est possible de modifier un tablespace, notamment pour :
●
le renommer ;
●
lui allouer de l’espace supplémentaire ;
●
déplacer le(s) fichier(s) de données ;
●
le passer OFFLINE / ONLINE ;
●
le passer READ ONLY / READ WRITE ;
●
modifier ces autres caractéristiques (LOGGING / NOLOGGING, FORCE LOGGING, FLASHBACK ON / OFF, etc.).
Ces opérations s’effectuent selon les cas avec l’ordre SQL ALTER TABLESPACE ou ALTER DATABASE.
Il est possible d’allouer de l’espace supplémentaire à une base de données :
●
en ajoutant un nouveau tablespace (avec un ou plusieurs fichiers de données) ;
●
en ajoutant un fichier de données à un tablespace existant ;
●
en augmentant la taille d’un fichier de données d’un tablespace.
La syntaxe complète de l’ordre SQL ALTER TABLESPACE est "excessivement longue" ; nous n’allons donc pas la
présenter dans son intégralité mais indiquer la syntaxe à utiliser pour différentes opérations.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 5-
b. Renommer un tablespace
Renommer un tablespace s’effectue avec l’ordre SQL ALTER TABLESPACE. Cette possibilité est apparue en version 10.
Syntaxe
ALTER TABLESPACE ancien_nom RENAME TO nouveau_nom;
Exemple :
ALTER TABLESPACE deftbs RENAME TO tbsdef;
Les tablespaces SYSTEM et SYSAUX, ainsi que les tablespaces OFFLINE, ne peuvent pas être renommés.
Notez que dans le cas du tablespace OFFLINE, le message d’erreur indique en fait, que le fichier de données est
"hors ligne" (OFFLINE), ce qui empêche Oracle de modifier l’en­tête du fichier de données pour y enregistrer le
nouveau nom du tablespace. Un problème similaire pourrait se poser avec un tablespace en lecture seule, mais ce
n’est pas le cas ; Oracle ne cherche pas à modifier l’en­tête du fichier de données et enregistre juste le nouveau
nom dans le fichier de contrôle (l’en­tête sera modifié lorsque le tablespace repassera en lecture/écriture).
c. Ajouter un fichier de données à un tablespace
Ajouter un fichier de données à un tablespace s’effectue avec l’ordre SQL ALTER TABLESPACE.
Syntaxe
ALTER TABLESPACE nomADD DATAFILE spécification_fichier [,...];
Exemple :
ALTER TABLESPACE data
ADD DATAFILE ’f:\oradata\hermes\data02.dbf’ SIZE 100M
AUTOEXTEND ON NEXT 100M MAXSIZE 500M;
Ajouter un fichier de données à un tablespace est un premier moyen pour lui allouer de l’espace
supplémentaire ; généralement, cette méthode est utilisée pour allouer un nouveau fichier de données sur un autre
disque que le disque actuellement utilisé par le tablespace (sinon, autant modifier la taille du fichier de données
existant ­ voir ci­après). Cette opération est interdite pour un tablespace BIGFILE.
La spécification du fichier de données (spécification_fichier) est la même que lors de la création du tablespace
(section Création d’un tablespace permanent).
d. Modifier la taille d’un fichier de données
Modifier la taille d’un fichier de données s’effectue avec l’ordre SQL ALTER DATABASE, ou l’ordre SQL ALTER TABLESPACE
dans le cas d’un tablespace BIGFILE.
Syntaxe
ALTER DATABASE
DATAFILE ’nom_complet’ | numéro_fichier [,...] RESIZE valeur [K|M|G|T];
ALTER TABLESPACE nom_tablespace_bigfile RESIZE valeur [K|M|G|T];
Exemple :
●
Tout type de tablespace
ALTER DATABASE
DATAFILE ’f:\oradata\hermes\data02.dbf’ RESIZE 200M;
●
Tablespace BIGFILE uniquement
ALTER TABLESPACE je_suis_gros RESIZE 1T;
La clause RESIZE donne la nouvelle taille souhaitée (à la hausse ou à la baisse) pour le fichier de données.
- 6-
© ENI Editions - All rights reserved - Algeria Educ
Modifier la taille d’un fichier de données permet :
●
dans le cas d’une diminution, de récupérer de l’espace inutilisé alloué au tablespace ;
●
dans le cas d’une augmentation, d’allouer de l’espace supplémentaire à un tablespace.
Dans le cas d’une diminution, la taille du fichier de données ne peut pas descendre en dessous de la position de la
dernière extension occupée par un segment dans le tablespace (visible dans la vue DBA_EXTENTS). En cas de
tentative de cette sorte, un message d’erreur est affiché et la taille du fichier est inchangée :
ORA-03297: le fichier contient des données utilisées au-delà
de la valeur RESIZE requise
e. Modifier l’extension automatique d’un fichier de données
Modifier l’extension automatique d’un fichier de données s’effectue avec l’ordre SQL ALTER DATABASE, ou l’ordre SQL
ALTER TABLESPACE dans le cas d’un tablespace BIGFILE.
Syntaxe
ALTER DATABASE
DATAFILE ’nom_complet’ | numéro_fichier[,...] clause_auto_extension;
ALTER TABLESPACE nom_tablespace_bigfile clause_auto_extension;
La spécification de la clause d’extension automatique (clause_auto_extension) est la même que lors de la création
du tablespace (section Création d’un tablespace permanent).
Exemple :
●
Désactivation de la clause AUTOEXTEND
ALTER DATABASE
DATAFILE ’e:\oradata\hermes\data01.dbf’ AUTOEXTEND OFF;
●
Activation (ou modification) de la clause AUTOEXTEND
ALTER DATABASE
DATAFILE ’e:\oradata\hermes\data01.dbf’
AUTOEXTEND ON NEXT 200M MAXSIZE 800M;
●
Exemple avec un tablespace BIGFILE
ALTER TABLESPACE je_suis_gros
AUTOEXTEND ON NEXT 1G MAXSIZE 100G;
Activer l’extension automatique d’un fichier de données permet à ce dernier de grossir automatiquement en cas de
besoin d’espace supplémentaire pour un segment (nouveau ou déjà présent) dans le tablespace ; c’est un bon
moyen pour éviter les problèmes et ne pas avoir à augmenter soi­même la taille d’un fichier de données (voir
précédemment). Désactiver l’extension automatique d’un fichier de données peut être envisagé (et même conseillé)
s’il n’y a plus d’espace disponible sur un disque.
f. Passer un tablespace OFFLINE / ONLINE
Passer un tablespace OFFLINE / ONLINE s’effectue avec l’ordre SQL ALTER TABLESPACE.
Syntaxe
ALTER TABLESPACE nom ONLINE | OFFLINE;
Exemple :
●
openmirrors.com
Désactivation
© ENI Editions - All rights reserved - Algeria Educ
- 7-
ALTER TABLESPACE data OFFLINE;
●
Activation
ALTER TABLESPACE data ONLINE;
Désactiver un tablespace peut être nécessaire pour effectuer certaines opérations d’administration sur le
tablespace (par exemple, déplacer un de ces fichiers de données) ou tout simplement pour rendre certaines
données temporairement inaccessibles.
Le tablespace SYSTEM ne peut pas être mis OFFLINE ; un message d’erreur s’affiche en cas de tentative. Le
tablespace SYSAUX peut être passé OFFLINE mais certaines fonctionnalités risquent de ne plus fonctionner.
Le statut d’un tablespace (OFFLINE / ONLINE) est conservé lors de l’arrêt ; au prochain démarrage de la base de
données, le tablespace sera dans l’état où il était lors de l’arrêt.
Il existe des options sur le OFFLINE qui doivent être utilisées si le tablespace à désactiver est endommagé (voir le
chapitre Sauvegarde et récupération).
g. Renommer ou déplacer un fichier de données
Renommer ou déplacer un fichier de données s’effectue avec l’ordre SQL ALTER TABLE- SPACE ou ALTER DATABASE.
Dans le cas de l’utilisation de l’ordre SQL ALTER TABLESPACE, la base de données doit être ouverte mais le
tablespace concerné doit être OFFLINE. Dans le cas de l’utilisation de l’ordre SQL ALTER DATABASE, le tablespace
concerné doit être OFFLINE ou la base de données en état MOUNT. L’utilisation de l’ordre SQL ALTER DATABASE, base
montée, est nécessaire pour déplacer un fichier de données du tablespace SYSTEM puisque ce dernier ne peut pas
être mis OFFLINE.
Ces deux ordres SQL ne manipulent pas physiquement le fichier. Ils se contentent de mettre à jour le fichier
de contrôle. Le fichier de données doit être renommé/copié /déplacé à l’aide d’une commande du système
d’exploitation, avant d’exécuter l’ordre SQL.
Syntaxe
- ALTER TABLESPACE
ALTER TABLESPACE nom
RENAME DATAFILE ’ancien_nom_complet’
TO ’nouveau_nom_complet’;
- ALTER DATABASE
ALTER DATABASE
RENAME FILE ’ancien_nom_complet’
TO ’nouveau_nom_complet’;
"Renommer" un fichier de données est surtout utilisé pour déplacer le fichier. Cette possibilité est intéressante si le
tablespace est plein et qu’il ne reste plus d’espace disponible sur le disque sur lequel il est actuellement
situé ; dans ce cas, il est envisageable de déplacer le fichier de données du tablespace vers un disque où il reste de
l’espace disponible puis de faire grossir le fichier (ou l’autoriser à grossir).
Le mode opératoire, lors de l’utilisation de l’ordre SQL ALTER TABLESPACE, est le suivant :
●
Se connecter en tant que DBA :
SQL> CONNECT system/xxxx
●
Passer le tablespace OFFLINE :
SQL> ALTER TABLESPACE data OFFLINE;
●
Par une commande du système d’exploitation, renommer, copier ou déplacer le fichier :
SQL> HOST move e:\oradata\hermes\data01.dbf >
f:\oradata\hermes\data01.dbf
●
- 8-
Exécuter l’ordre SQL ALTER TABLESPACE :
© ENI Editions - All rights reserved - Algeria Educ
SQL> ALTER TABLESPACE data
2 RENAME DATAFILE ’e:\oradata\hermes\data01.dbf’
3 TO ’f:\oradata\HErmes\data01.dbf’;
●
Repasser le tablespace ONLINE :
SQL> ALTER TABLESPACE data ONLINE;
Le mode opératoire, lors de l’utilisation de l’ordre SQL ALTER DATABASE, est le suivant :
●
Se connecter AS SYSDBA :
SQL> CONNECT / AS SYSDBA
●
Passer la base de données en état MOUNT :
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT
●
Par une commande du système d’exploitation, renommer, copier ou déplacer le fichier :
SQL> HOST move e:\oradata\hermes\system01.dbf >
f:\oradata\hermes\system01.dbf
●
Exécuter l’ordre SQL ALTER DATABASE :
SQL> ALTER DATABASE
2 RENAME FILE ’e:\oradata\hermes\system01.dbf’
3 TO ’f:\oradata\hermes\system01.dbf’;
●
Ouvrir la base de données :
SQL> ALTER DATABASE OPEN;
h. Supprimer un fichier de données
Supprimer un fichier de données d’un tablespace s’effectue avec l’ordre SQL ALTER TABLESPACE.
Syntaxe
ALTER TABLESPACE nom DROP DATAFILE ’nom_complet’ | numéro_fichier;
Exemple
ALTER TABLESPACE data DROP DATAFILE ’E:\ORADATA\HERMES\DATA02.DBF’;
Le fichier de données est physiquement supprimé par Oracle.Les restrictions suivantes s’appliquent :
●
Le fichier de données doit être vide (ne doit contenir aucune extension) ;
●
Le fichier de données ne peut pas être le premier fichier créé pour le tablespace ;
●
Le fichier de données ne doit pas appartenir à un tablespace en lecture seule ;
●
Le fichier de données doit être en ligne (ONLINE) ;
●
Le fichier ne doit pas appartenir au tablespace SYSTEM.
i. Autres opérations
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 9-
L’ordre SQL ALTER TABLESPACE peut être utilisé pour modifier les caractéristiques du tablespace :
- READ ONLY / READ WRITE
ALTER TABLESPACE nom { READ ONLY | READ WRITE } ;
- LOGGING / NOLOGGING
ALTER TABLESPACE nom LOGGING | NOLOGGING ;
- FORCE LOGGING
ALTER TABLESPACE nom [NO] FORCE LOGGING ;
- FLASHBACK ON / OFF
ALTER TABLESPACE nom FLASHBACK ON | OFF ;
5. Suppression d’un tablespace permanent
L’ordre SQL DROP TABLESPACE permet de supprimer un tablespace permanent.
Syntaxe
DROP TABLESPACE nom [ INCLUDING CONTENTS [ AND DATAFILES ]
[ CASCADE CONSTRAINTS ] ];
Exemple :
DROP TABLESPACE data INCLUDING CONTENTS AND DATAFILES ;
C’est un ordre DDL (Data Definition Language) : il n’y a pas de ROLLBACK. La seule solution est de repartir d’une
sauvegarde ; le fichier physique, même s’il n’est pas supprimé, n’est pas récupérable.
Le tablespace SYSTEM et le tablespace permanent par défaut ne peuvent pas être supprimés.Il est recommandé de
passer le tablespace OFFLINE avant de le supprimer.
Les options de l’ordre SQL DROP TABLESPACE sont :
INCLUDING CONTENTS
Cette clause est nécessaire si le tablespace n’est pas vide, pour forcer la suppression préalable des segments qui y
sont stockés. Si le tablespace n’est pas vide et que l’option n’est pas utilisée, l’erreur ORA-01549 est retournée :
ORA-01549: le tablespace n’est pas vide ; utiliser l’option INCLUDING
CONTENTS
AND DATAFILES
Cette option de la clause précédente permet en plus, de supprimer les fichiers physiques du tablespace. Un message
est écrit dans le fichier d’alerte de l’instance pour chaque fichier physique supprimé par Oracle.
Sinon, ils ne sont pas supprimés.
CASCADE CONSTRAINTS
Cette clause permet en plus, de supprimer les contraintes d’intégrité référentielle définies sur des tables hors du
tablespace et qui référencent des tables à l’intérieur du tablespace. Si de telles contraintes existent et que l’option
n’est pas utilisée, l’erreur ORA-02449 est retournée :
ORA-02449: clés uniques/primaires de la table référencées
par des clés étrangères<$I[]ORA-02449>
- 10 -
© ENI Editions - All rights reserved - Algeria Educ
Organisation du stockage à l’intérieur d’un tablespace
1. Principes
L’organisation du stockage à l’intérieur d’un tablespace peut être résumée par le schéma ci­après.
À l’intérieur d’un tablespace, le stockage est organisé en segments contenant une ou plusieurs extensions (extents),
une extension étant un ensemble de blocs Oracle contigus.
Lorsqu’un segment est créé dans un tablespace, Oracle lui alloue une (ou plusieurs) extension(s) dans un des fichiers
de données du tablespace. Lorsque l’espace initialement alloué est plein (suite à l’insertion de données par
exemple), Oracle alloue une nouvelle extension au segment, et ainsi de suite. Toutes les extensions allouées à un
segment sont dans le tablespace de création du segment, mais pas forcément côte à côte, ni forcément dans le
même fichier de données (si le tablespace est composé de plusieurs fichiers de données). Lorsqu’un segment est
supprimé, les extensions qu’il occupe sont libérées et rendues disponibles pour d’autres segments. Des
créations/suppressions fréquentes de segments dans un tablespace peuvent donc conduire à une fragmentation de
l’espace disponible dans ce tablespace.
Pour mémoire, il existe quatre types principaux de segments :
●
les segments de table : espace occupé par les tables ;
●
les segments d’index : espace occupé par les index ;
●
●
les segments d’annulation : espace temporaire utilisé pour stocker les informations permettant d’annuler une
transaction ;
les segments temporaires : espace temporaire utilisé notamment lors d’un tri.
La première extension d’un segment contient au minium deux blocs, le premier étant réservé à l’en­tête du segment
(ne contient pas de données utiles mais la carte des extensions allouées au segment). Il en est de même pour
chaque fichier de données du tablespace ; le premier bloc est un bloc d’en­tête (nous verrons bientôt que l’en­tête du
fichier peut contenir davantage de blocs).
Nous verrons au chapitre Gestion des tables et des index qu’il est possible, sous certaines conditions, de libérer des
extensions sans supprimer le segment.
Un tablespace peut être "géré par le dictionnaire" ou "géré localement".
Dans un tablespace "géré par le dictionnaire", les informations relatives à la gestion de l’espace (extensions
libres/allouées) sont enregistrées dans le dictionnaire de données.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Dans un tablespace "géré localement", les informations relatives à la gestion de l’espace (extensions libres/allouées)
sont enregistrées dans une bitmap, dans l’en­tête de chaque fichier de données du tablespace. Chaque bit de la
bitmap correspond à une extension et vaut 0 ou 1 selon que l’extension est libre ou allouée.
Les tablespaces gérés localement sont apparus dans Oracle8i. Depuis Oracle9i, les tablespaces sont, par défaut,
gérés localement (sauf le tablespace SYSTEM qui est, par défaut, géré par le dictionnaire ­ voir plus loin).
Oracle recommande fortement d’utiliser des tablespaces gérés localement. C’est le seul type de tablespace
qui sera étudié dans cet ouvrage. Il est fort probable que les tablespaces gérés par le dictionnaire ne soient
plus supportés par Oracle dans une prochaine version.
Oracle propose deux variantes pour les tablespaces gérés localement :
●
●
Une gestion dite "automatique" : la taille des extensions est déterminée automatiquement par Oracle.
Une gestion dite "uniforme" : la taille des extensions est uniforme, égale à une valeur définie lors de la
création du tablespace.
Par défaut, un tablespace permanent géré localement est en gestion automatique des extensions ; la gestion
uniforme doit être spécifiée.
Un tablespace temporaire géré localement est obligatoirement en gestion uniforme des extensions (détaillé
ultérieurement).
2. Spécifier le stockage d’un segment
Les clauses TABLESPACE et STORAGE peuvent être utilisées dans les ordres de création des segments pour spécifier le
stockage du segment.
Syntaxe de la clause TABLESPACE
TABLESPACE nom_tablespace
Syntaxe de la clause STORAGE
STORAGE ( [
[
[
[
[
INITIAL valeur [K|M] ]
NEXT valeur [K|M] ]
MINEXTENTS valeur ]
MAXEXTENTS { valeur | UNLIMITED } ]
PCTINCREASE valeur ] )
Exemple pour une table :
CREATE TABLE categorie
(
identifiant NUMBER(6),
intitule
VARCHAR2(20)
)
TABLESPACE data
STORAGE (INITIAL 500K) ;
Les options de la clause STORAGE sont :
INITIAL
Taille de la première extension allouée.
NEXT
Taille de la deuxième extension allouée.
MINEXTENTS
Nombre initial d’extension(s) allouée(s).
- 2-
© ENI Editions - All rights reserved - Algeria Educ
MAXEXTENTS
Nombre maximal d’extensions allouables.
PCTINCREASE
Pourcentage d’augmentation (0 à 100) de la taille des extensions, à partir de la troisième, par rapport à la
précédente.
La manière dont la clause STORAGE est utilisée par Oracle dépend du mode de gestion des extensions à l’intérieur du
tablespace.
La clause STORAGE a vraiment beaucoup d’importance pour le stockage des segments dans un tablespace géré par le
dictionnaire, puisqu’elle permet de spécifier précisément le stockage du segment. Si une clause MINIMUM EXTENT est
définie au niveau du tablespace, la taille des extensions est éventuellement ajustée pour devenir un multiple de cette
taille minimum. En cas d’absence de clause STORAGE, le segment hérite de la clause DEFAULT STORAGE éventuellement
définie au niveau du tablespace. Si cette dernière est elle­même absente, Oracle utilise des valeurs par défaut
(INITIAL = 5 blocs Oracle, NEXT = 5 blocs Oracle, PCTINCREASE = 50). Dans le cas d’un tablespace géré localement, la
clause STORAGE a beaucoup moins d’importance car, de par sa définition, le tablespace impose des contraintes sur la
taille des extensions (taille choisie par Oracle ou taille uniforme). Dans la pratique, seule l’option INITIAL a réellement
de l’importance puisqu’elle indique à Oracle la taille initiale souhaitée pour le segment.
3. Spécifier le mode de gestion d’un tablespace
La clause EXTENT MANAGEMENT de l’ordre SQL CREATE TABLESPACE permet de spécifier le mode de gestion d’un
tablespace.
Syntaxe :
EXTENT MANAGEMENT
DICTIONARY
| LOCAL [ AUTOALLOCATE | UNIFORM [ SIZE valeur [K|M] ] ]
Exemple :
●
Tablespace géré localement avec des extensions uniformes
CREATE TABLESPACE tbs_local_uniform
DATAFILE ’e:\oradata\hermes\tbs_local_uniform.dbf’ SIZE 10M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128K;
●
Tablespace géré localement avec des extensions gérées par Oracle
CREATE TABLESPACE tbs_local_auto
DATAFILE ’d:\oradata\hermes\tbs_local_auto.dbf’ SIZE 10M
EXTENT MANAGEMENT LOCAL AUTOALLOCATE;
Les options de la clause EXTENT MANAGEMENT sont :
DICTIONARY
Indique que le tablespace est géré par le dictionnaire. Des clauses DEFAULT STORAGE et MINIMUM EXTENT peuvent être
indiquées en complément.
LOCAL
Indique que le tablespace est géré localement. Les clauses DEFAULT STORAGE et MINIMUM EXTENT sont interdites.
AUTOALLOCATE
Indique que les extensions sont automatiquement gérées par Oracle.
UNIFORM
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Indique que les extensions ont une taille uniforme définie par la clause SIZE. Si la clause SIZE n’est pas spécifiée, la
taille par défaut est 1 Mo.
SIZE
Spécifie la taille des extensions pour les tablespaces LOCAL UNIFORM. La taille peut être donnée en octets (pas de
symbole), en Ko (symbole K) ou en Mo (symbole M).
Par défaut (clause EXTENT MANAGEMENT absente), un tablespace permanent est géré localement avec une gestion
automatique des extensions (AUTOALLOCATE).
Comme nous le verrons ultérieurement, un tablespace temporaire géré localement est obligatoirement en gestion
uniforme des extensions (UNIFORM).
Lorsqu’un tablespace permanent est géré localement, la gestion automatique de l’espace libre à l’intérieur des
segments est, par défaut, activée (clause SEGMENT SPACE MANAGEMENT AUTO implicite dans l’ordre SQL CREATE
TABLESPACE) ; nous étudierons ce mode de gestion plus en détail dans le chapitre Gestion des tables et des index.
Compte tenu de ce mode de gestion, les extensions doivent contenir au minimum cinq blocs ; dans le cas d’un
tablespace géré localement avec une gestion uniforme des extensions, il faut en tenir compte dans la spécification de
la clause SIZE, sous peine d’obtenir l’erreur suivante :
ORA-03249: UNIFORM SIZE pour le tablespace géré par un espace de
segment AUTO doit avoir au moins 5 blocs
L’en­tête de chaque fichier de données d’un tablespace géré localement utilise au minimum trois blocs (contre un
pour un tablespace géré par le dictionnaire). La taille du fichier de données doit donc être au minimum égale à trois
blocs plus la taille d’une extension (valeur explicite ou par défaut de la clause SIZE pour un tablespace UNIFORM, 64 Ko
pour un tablespace AUTOALLOCATE). Si la taille initiale du fichier de données est supérieure à 64 Ko plus la taille d’une
extension, un en­tête de 64 Ko est en fait alloué au fichier, ce qui permet de stocker une bitmap plus grande et donc
de gérer d’entrée de jeu, un plus grand nombre d’extensions.
Le package DBMS_SPACE_ADMIN <propose différentes procédures qui permettent de diagnostiquer et réparer les
tablespaces gérés localement (en cas d’endommagement de la bitmap par exemple), ou d’effectuer une migration de
tablespace géré par le dictionnaire en tablespace géré localement (et réciproquement). Dans ce dernier cas, le
résultat obtenu est meilleur en créant un nouveau tablespace géré localement et en transférant les segments de
l’ancien tablespace dans le nouveau ; par contre, l’opération est plus longue.
4. Gestion des extensions à l’intérieur d’un tablespace géré localement
Dans le cas d’une gestion automatique des extensions, Oracle utilise un petit nombre de tailles d’extension
différentes (64 Ko, 1 Mo, 8 Mo, 64 Mo) et tente d’allouer côté à côte des extensions de même taille, en nombre
suffisant pour occuper de l’espace potentiellement utilisable pour une extension de taille supérieure (16 extensions
de 64 Ko = une extension potentielle de 1 Mo). Cette technique permet de limiter les risques de fragmentation de
l’espace disponible : si un segment contenant de nombreuses extensions est supprimé, l’espace libéré peut être
réutilisé de différentes manières.La taille d’extension initialement choisie pour un segment dépend de la taille initiale
du segment :
●
64 Ko pour un segment de moins de 1 Mo ;
●
1 Mo pour un segment de moins de 64 Mo ;
●
8 Mo pour un segment de moins de 1 024 Mo, etc.
L’algorithme utilisé par Oracle pour calculer la taille des extensions dans un tablespace géré localement, avec
une gestion automatique des extensions, n’est pas documenté. Les valeurs indiquées ici sont des valeurs
constatées pour la création d’une table dans un tablespace vide.
Dans le cas d’une gestion uniforme des extensions toutes les extensions ont la même taille définie par l’option SIZE
de la clause EXTENT MANAGEMENT (1 Mo par défaut).
La taille initiale du segment est calculée à l’aide des valeurs INITIAL, NEXT, MINEXTENTS et PCTINCREASE de la clause
STORAGE :
●
- 4-
si MINEXTENTS = 1 alors INITIAL (c’est le cas le plus fréquent) ;
© ENI Editions - All rights reserved - Algeria Educ
●
si MINEXTENTS = 2 alors INITIAL+NEXT ;
●
si MINEXTENTS = 3 alors INITIAL+NEXT+NEXT*(1+PCTINCREASE/100), etc.
La valeur calculée devient la nouvelle valeur INITIAL, telle qu’enregistrée dans le dictionnaire de données.
Oracle alloue alors une ou plusieurs extensions (sans tenir compte du MINEXTENTS initial), de taille uniforme (cas
UNIFORM) ou de taille déterminée en interne (cas AUTOALLOCATE), pour obtenir une taille initiale égale ou supérieure à
la taille calculée précédemment.
À titre d’exemple, supposons que la table suivante soit créée dans un tablespace géré localement avec des
extensions uniformes de 128 Ko :
CREATE TABLE adherent (...)
TABLESPACE tbs_local_uniform
STORAGE (INITIAL 400K NEXT 100K PCTINCREASE 0 MINEXTENTS 2);
Oracle alloue (400+100)/128 = 3,5 arrondi à l’entier supérieur = 4 extensions de 128 Ko pour la table.
Si la même table est créée dans un tablespace géré localement, avec une gestion automatique des extensions,
Oracle alloue (400+100)/64 = 7,8 arrondi à l’entier supérieur = 8 extensions de 64 Ko pour la table (une taille
d’extension de 64 Ko est choisie par Oracle car la taille initiale du segment est inférieure à 1 Mo).
Les informations enregistrées dans le dictionnaire de données (vue DBA_TABLES et consoeurs) sont les suivantes :
■
■
■
■
Les valeurs MINEXTENTS et MAXEXTENTS sont ignorées et forcées respectivement à 1 (même si plusieurs extensions
ont été allouées au segment) et UNLIMITED.
La valeur calculée pour la taille initiale devient la nouvelle valeur INITIAL (même si l’espace réellement alloué est
supérieur, compte tenu de l’arrondi sur le nombre d’extensions).
Pour un tablespace AUTOALLOCATE, les valeurs NEXT et PCTINCREASE sont ignorées et mises à NULL (c’est Oracle qui
décide).
Pour un tablespace UNIFORM, NEXT est mis égal à la taille des extensions du tablespace (option SIZE de la clause
UNIFORM du tablespace) et PCTINCREASE est mis égal à 0 (toutes les extensions ont la même taille).
Conclusion : les options NEXT, PCTINCREASE, MINEXTENTS et MAXEXTENTS ne sont pas d’une grande utilité pour un
tablespace géré localement.
Lorsque l’espace initialement alloué au segment est plein, des extensions supplémentaires sont allouées au
segment.
Si le segment est stocké dans un tablespace UNIFORM, toutes les extensions complémentaires allouées au segment
ont la même taille.
Si le segment est stocké dans un tablespace AUTOALLOCATE, c’est Oracle qui détermine la taille des nouvelles
extensions allouées au segment, selon un algorithme non documenté, Visiblement, le fonctionnement est le suivant
lorsqu’une taille initiale de 64 Ko a été utilisée : tant que le segment a moins de 16 extensions, Oracle alloue des
extensions de 64 Ko, puis il passe à des extensions de 1 Mo, jusqu’à 64 Mo, puis à des extensions de 8 Mo. Par
ailleurs, Oracle tente d’allouer consécutivement des extensions de même taille, jusqu’à obtenir un nombre
d’extensions consécutives occupant un espace égal à la taille d’extension supérieure.
Exemple :
SQL> -- création d’un tablespace géré localement avec
SQL> -- une gestion automatique des extensions
SQL> CREATE TABLESPACE test
2 DATAFILE ’e:\oradata\hermes\test01.dbf’ SIZE 10M
3 EXTENT MANAGEMENT LOCAL AUTOALLOCATE;
Tablespace créé.
SQL> -- création de trois tables : deux "petites" et une "grosse"
SQL> CREATE TABLE table200k(c NUMBER)
2 TABLESPACE test
3 STORAGE(INITIAL 200K);
Table créée.
SQL> CREATE TABLE tablexk(c NUMBER)
openmirrors.com
sans clause STORAGE
© ENI Editions - All rights reserved - Algeria Educ
- 5-
2 TABLESPACE test;
Table créée.
SQL> CREATE TABLE table2M(c NUMBER)
2 TABLESPACE test
3 STORAGE(INITIAL 2M);
Table créée.
SQL> -- supervision du stockage dans le tablespace
SQL> @info_stockage_tablespace
BLOCK_ID EXTENT_ID SEGMENT_NAME
BLOCKS TAILLE_KO
---------- ---------- --------------- ---------- ---------9
0 TABLE200K
8
64
17
1 TABLE200K
8
64
25
2 TABLE200K
8
64
33
3 TABLE200K
8
64
41
0 TABLEXK
8
64
49
*** LIBRE ***
88
704
137
0 TABLE2M
128
1024
265
1 TABLE2M
128
1024
393
*** LIBRE ***
888
7104
Cet exemple illustre les points suivants:
●
●
Oracle a choisi des extensions de 64 Ko pour les "petites" tables et des extensions de 1 Mo pour la "grosse"
table.
Oracle a laissé de l’espace libre entre les petites tables et la grosse table : 704 Ko, soit 11 extensions de 64
Ko. Cet espace est plutôt réservé à des extensions de 64 Ko, ce qui lui permet d’avoir un total de 16
extensions de 64 Ko consécutives (soit potentiellement une extension de 1 Mo en cas de libération de ces
extensions).
5. Cas des tablespaces SYSTEM et SYSAUX
Depuis Oracle9i release 2 (version 9.2), le tablespace SYSTEM peut être géré localement, et dans ce cas, forcément
avec une gestion automatique des extensions (EXTENT MANAGEMENT LOCAL AUTOALLOCATE) et une gestion manuelle de
l’espace dans les segments (SEGMENT SPACE MANAGEMENT MANUAL). Par défaut, il est géré par le dictionnaire. Créer un
tablespace SYSTEM géré localement a les conséquences (positives) suivantes :
●
Tous les tablespaces doivent être gérés localement (conseillé par Oracle) ;
●
Un tablespace temporaire par défaut doit être créé dès la création de la base (conseillé par Oracle) ;
●
Si la gestion automatique des segments d’annulation est activée (conseillé par Oracle), un tablespace
d’annulation doit être créé dès la création de la base de données (conseillé par Oracle).
Dans l’ordre SQL CREATE DATABASE, la clause EXTENT MANAGEMENT LOCALpermet de spécifier que le tablespace SYSTEM
est géré localement :
CREATE DATABASE hermes
...
DATAFILE ’e:\oradata\hermes\system01.dbf’ SIZE 200M
AUTOEXTEND ON NEXT 10M
EXTENT MANAGEMENT LOCAL
...
Le tablespace SYSAUX est obligatoirement géré localement avec une gestion automatique des extensions (EXTENT
MANAGEMENT LOCAL AUTOALLOCATE) et une gestion automatique de l’espace dans les segments (SEGMENT SPACE
MANAGEMENT AUTO) ; il n’y a rien à spécifier lors de la création de la base de données.
En cas de mise à niveau d’une base de données, le tablespace SYSAUX est créé par un ordre SQL CREATE TABLESPACE.
La syntaxe suivante doit être utilisée :
CREATE TABLESPACE sysaux
- 6-
© ENI Editions - All rights reserved - Algeria Educ
DATAFILE spécification_fichier
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO;
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 7-
Tablespace temporaire
1. Rôle du tablespace temporaire
Lorsqu’une requête nécessite un tri (clause ORDER BY par exemple), Oracle tente de faire le tri en mémoire, dans la
PGA du processus serveur qui exécute la requête.
Si le tri ne tient pas en mémoire, Oracle le découpe en morceaux et trie chaque morceau individuellement en stockant
des résultats intermédiaires sur disque dans des segments temporaires.
Un segment temporaire peut être créé dans n’importe quel tablespace mais ce n’est pas souhaitable pour les
performances.
Oracle recommande donc de créer un tablespace dédié, de type TEMPORARY, pour stocker les segments temporaires,
et de préférence un tablespace temporaire géré localement. Il est possible de créer un tablespace temporaire géré
par le dictionnaire mais les performances sont alors limitées et ce choix est déprécié par Oracle ; c’est pourquoi nous
ne l’évoquerons pas davantage.
Les requêtes qui peuvent demander un tri sont les suivantes :
●
SELECT ... ORDER BY ;
●
SELECT ... GROUP BY ;
●
SELECT DISTINCT ... ;
●
requêtes ensemblistes (UNION, INTERSECT, MINUS) ;
●
CREATE INDEX ;
●
calcul des statistiques ;
●
jointures par tri­fusion (sort merge join).
Utiliser un tablespace permanent comme tablespace temporaire est possible (c’est ce qui passe par défaut avec le
tablespace SYSTEM) mais ce n’est pas conseillé, notamment du point de vue des performances. En effet, dans un
tablespace permanent, les segments temporaires sont alloués et libérés à chaque tri ; c’est mauvais pour les
performances et cela risque de fragmenter l’espace disponible du tablespace. Dans le cas de l’utilisation d’un
tablespace temporaire, un seul segment de tri est créé, par le premier tri, et réutilisé par les tris suivants.
Le segment temporaire peut être partagé par plusieurs tris (mais pas les extensions) et il est libéré uniquement lors
de l’arrêt de l’instance ; de cette manière, il y a moins d’allocation dynamique d’extensions, et les performances s’en
trouvent optimisées.
Un tablespace permanent géré localement ne peut pas être utilisé comme tablespace temporaire ; ce n’est
pas le cas d’un tablespace permanent géré par le dictionnaire.
Les tablespaces temporaires sont aussi utilisés pour le stockage des tables temporaires créées par l’ordre SQL
CREATE GLOBAL TEMPORARY TABLE.
2. Groupe de tablespaces temporaires
Avant la version 10, une requête ne pouvait utiliser qu’un seul tablespace temporaire, ce qui posait des problèmes de
performance si la requête s’exécutait en parallèle. Dans ce cas, plusieurs processus serveur traitaient la requête en
parallèle et chaque processus pouvait solliciter un accès au tablespace temporaire, ce qui posait parfois des
problèmes de contentions au niveau des entrées/sorties.
Depuis la version 10, il est possible de définir des groupes de tablespaces temporaires. Dans le cas de l’exécution
d’une requête en parallèle, les différents tablespaces temporaires du groupe pourront être utilisés par les différents
processus serveur qui traitent la requête. Cela ne présente réellement un intérêt du point de vue des performances
que si les fichiers de données des différents tablespaces temporaires sont stockés sur des disques différents.
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Le nom d’un groupe de tablespaces temporaires peut être utilisé partout où un nom de tablespace temporaire est
employé. L’espace de nommage des groupes de tablespaces temporaires est d’ailleurs celui des tablespaces ; un
groupe de tablespace temporaires ne peut pas porter le même nom qu’un tablespace.
Un groupe de tablespaces temporaires n’est pas explicitement créé ou supprimé. Il est implicitement créé lorsqu’un
premier tablespace temporaire est affecté au groupe et implicitement supprimé, lorsque le dernier tablespace
temporaire est retiré du groupe.
3. Création d’un tablespace temporaire géré localement
L’ordre SQL CREATE TEMPORARY TABLESPACEpermet de créer un tablespace temporaire géré localement.
Syntaxe
CREATE [ BIGFILE | SMALLFILE ] TEMPORARY TABLESPACE nom
TEMPFILE spécification_fichier [,...]
[ EXTENT MANAGEMENT LOCAL ] [ UNIFORM [ SIZE valeur [K|M] ] ]
[ TABLESPACE GROUP nom_groupe ] ;
- spécification_fichier
’nom_fichier’ [ SIZE valeur [K|M|G|T] ] [REUSE]
[ clause_auto_extend ]
- clause_auto_extend
AUTOEXTEND { OFF | ON [ NEXT valeur [K|M|G|T] ]
[ MAXSIZE { UNLIMITED | valeur [K|M|G|T] } ] }
Exemple :
CREATE TEMPORARY TABLESPACE tempo
TEMPFILE ’e:\oradata\hermes\tempo01.dbf’
SIZE 100M AUTOEXTEND ON NEXT 10M MAXSIZE 1G ;
Les options de l’ordre SQL CREATE TEMPORARY TABLESPACE ont la même signification que les options de même nom de
l’ordre SQL CREATE TABLESPACE (voir la section Tablespace permanent).
Vous pouvez néanmoins noter les points suivants :
●
●
●
●
●
●
Un tablespace temporaire géré localement peut être un tablespace BIGFILE ; dans ce cas, un seul fichier de
données peut être spécifié.
Les fichiers de données d’un tablespace temporaire géré localement sont spécifiés par le mot clé TEMPFILE et
non DATAFILE.
Un tablespace temporaire géré localement présente forcément une gestion uniforme de ses extensions. Les
clauses EXTENT MANAGEMENT LOCAL et UNIFORM sont donc optionnelles. Par défaut, la taille des extensions est
de 1 Mo ; elle est satisfaisante dans une grande majorité des cas. La clause SIZE peut être utilisée pour
spécifier une autre taille ; dans ce cas, le mot clé UNIFORM doit être mentionné.
Un tablespace temporaire géré localement utilise obligatoirement la taille de bloc standard ; il n’est pas
possible d’employer une autre taille de bloc.
Un tablespace temporaire géré localement est obligatoirement ONLINE.
Les clauses LOGGING, NOLOGGING, FORCE LOGGING et FLASHBACK sont interdites pour un tablespace temporaire
géré localement.
La clause TABLESPACE GROUP permet d’affecter le tablespace temporaire à un groupe ; si le groupe n’existe pas, il est
implicitement créé. Par défaut, le tablespace temporaire n’appartient à aucun groupe.
4. Tablespace temporaire par défaut
Un tablespace temporaire n’est réellement utilisé que lorsqu’il est "affecté" aux utilisateurs, grâce à la clause
TEMPORARY TABLESPACE des ordres SQL CREATE USER et ALTER USER (voir le chapitre Gestion des utilisateurs et de leurs
droits). Si cette clause est omise, c’est le tablespace SYSTEM qui est affecté comme tablespace temporaire à
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
l’utilisateur, ce qui est mauvais pour les performances.
Pour résoudre ce problème et faciliter la gestion des utilisateurs, il est possible de définir un tablespace temporaire
par défaut, dès la création de la base de données, ou ultérieurement. Cette technique n’empêche pas d’utiliser
d’autres tablespaces temporaires affectés spécifiquement à des utilisateurs pour des besoins particuliers.
Un tablespace SYSTEM géré localement ne peut pas être utilisé comme tablespace temporaire par défaut, d’où la
nécessité, dans ce cas, de créer et définir un tablespace temporaire par défaut dès la création de la base.
Si le tablespace SYSTEM est géré par le dictionnaire, et s’il est utilisé comme tablespace temporaire par défaut, un
message est écrit dans le fichier d’alerte de l’instance.
Pour créer et définir un tablespace temporaire par défaut lors de la création de la base de données, vous devez
utiliser la clause DEFAULT TEMPORARY TABLESPACE de l’ordre SQL CREATE DATABASE.
Syntaxe
[ BIGFILE | SMALLFILE ] DEFAULT TEMPORARY TABLESPACE nom
TEMPFILE spécification_fichier [,...]
[ EXTENT MANAGEMENT LOCAL ] [ UNIFORM [ SIZE valeur [K|M] ] ]
Exemple :
DEFAULT TEMPORARY TABLESPACE temp
TEMPFILE ’e:\oradata\hermes\temp01.dbf’ SIZE 100M
AUTOEXTEND ON NEXT 10M MAXSIZE 1024M
Cette clause doit être présente si le tablespace SYSTEM est géré localement.
La syntaxe est la même que celle de l’ordre SQL CREATE TEMPORARY TABLESPACE. Un tablespace temporaire géré
localement est créé selon la spécification et défini comme tablespace temporaire par défaut. Notez bien que le
tablespace temporaire par défaut ainsi créé est forcément géré localement (ce qui est conseillé par Oracle).
Le tablespace temporaire ainsi créé est pris en compte dès la création de la base de données, et donc affecté comme
tablespace temporaire aux utilisateurs créés durant cette opération (notamment SYS et SYSTEM).
Pour créer et définir un tablespace temporaire par défaut après la création de la base de données, vous devez :
●
●
créer un tablespace temporaire, grâce à l’ordre SQL CREATE TEMPORARY TABLESPACE présenté précédemment ;
le définir comme tablespace temporaire par défaut, grâce à la clause DEFAULT TEMPORARY TABLESPACE de
l’ordre SQL ALTER DATABASE.
Syntaxe
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE nom ;
nom doit désigner un tablespace temporaire ou un groupe de tablespaces temporaires qui existe déjà.
Lorsque cet ordre SQL est exécuté, tous les utilisateurs qui avaient l’ancien tablespace temporaire par défaut comme
tablespace temporaire se voient automatiquement attribuer le nouveau.
Pour retrouver le nom du tablespace temporaire par défaut, vous pouvez interroger la vue DATABASE_PROPERTIES pour
la propriété DEFAULT_TEMP_TABLESPACE :
SQL> SELECT property_value FROM database_properties
2 WHERE property_name = ’DEFAULT_TEMP_TABLESPACE’ ;
PROPERTY_VALUE
-----------------------------TEMP
5. Administration des tablespaces temporaires géré localement
L’administration d’un tablespace temporaire géré localement s’effectue avec les ordres SQL présentés pour les
tablespaces permanents, avec quelques restrictions : ALTER TABLESPACE, ALTER DATABASE pour la gestion des fichiers
de données et DROP TABLESPACE.
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Les fichiers de données d’un tablespace temporaire géré localement sont particuliers ; Oracle les appelle d’ailleurs
"fichiers de données temporaires". Les différences avec un fichier de données ordinaire sont les suivantes :
●
Ils sont toujours en mode NOLOGGING ;
●
Ils ne peuvent pas être désactivés ;
●
Ils ne peuvent pas être passés en lecture seule.
Les fichiers de données temporaires des tablespace temporaires gérés localement étant en mode NOLOGGING, les
modifications ne sont pas enregistrées dans les fichiers de journalisation (intéressant pour les performances). Par
contre, en cas de perte ou d’endommagement d’un de ces fichiers, la récupération (RECOVER) n’est pas possible. Ce
n’est pas très grave puisqu’un tablespace temporaire ne contient pas de données permanentes ; en cas de
problème, il suffit de supprimer le tablespace, où plus simplement le fichier de données, puis de le recréer.
Les fichiers de données temporaires sont administrés avec les ordres SQL ALTER TABLESPACE et ALTER DATABASE, en
remplaçant le mot clé DATAFILE par le mot clé TEMPFILE.
Les opérations suivantes sont autorisées :
●
Ajout d’un fichier de données temporaire à un tablespace temporaire géré localement
ALTER TABLESPACE nom_tablespace
ADD TEMPFILE spécification_fichier ;
●
Modification de la taille d’un fichier de données temporaire
●
Tout type de tablespace
ALTER DATABASE TEMPFILE ’nom_complet’ [,...]
RESIZE valeur [K|M|G|T] ;
●
Tablespace BIGFILE uniquement
ALTER TABLESPACE nom_tablespace_bigfile
RESIZE valeur [K|M|G|T];
●
Modification de la clause AUTOEXTEND d’un fichier de données temporaire
●
Tout type de tablespace
ALTER DATABASE TEMPFILE ’nom_complet’ [,...] clause_auto_extension;
●
Tablespace BIGFILE uniquement
ALTER TABLESPACE nom_tablespace_bigfile clause_auto_extension;
Par contre, un tablespace temporaire géré localement ne peut pas être passé OFFLINE.
De même, un fichier de données temporaire ne peut pas être renommé par l’ordre SQL ALTER TABLESPACE ... RENAME
DATAFILE (puisqu’il ne peut pas être passé OFFLINE). Par contre, renommer un fichier de données temporaire avec un
ALTER DATABASE RENAME FILE est possible (base montée). Pour renommer un fichier de données temporaire base
ouverte, et donc aussi pour le déplacer, il faut le supprimer et le récréer.
Exemple :
-- supprimer le fichier de données temporaire
SQL> ALTER DATABASE<$IALTER DATABASE;TEMPFILE DROP>
2
TEMPFILE ’e:\oradata\hermes\temp01.dbf’ DROP
3
INCLUDING DATAFILES;
Base de données modifiée.
-- le recréer
SQL> ALTER TABLESPACE temp ADD
- 4-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
2
TEMPFILE ’f:\oradata\hermes\temp01.dbf’ SIZE 100M
3
AUTOEXTEND ON NEXT 10M MAXSIZE 1G;
Tablespace modifié.
Notez l’utilisation de l’option INCLUDING DATAFILES qui permet de supprimer physiquement le fichier.
Un fichier de données temporaire peut aussi être supprimé par un ordre SQL ALTER TABLESPACE ... DROP TEMPFILE.
Par ailleurs, depuis la version 11, il est possible de rétrécir un tablespace temporaire géré localement.
Syntaxe
ALTER TABLESPACE nom SHRINK SPACE [ KEEP taille [K|M|G] ] ;
ALTER TABLESPACE nom SHRINK TEMPFILE ’nom_complet’ | numéro_fichier
[ KEEP taille [K|M|G] ] ;
Cette commande est intéressante pour libérer l’espace utilisé, par exemple, par un tri volumineux qui vient de se
terminer. La première syntaxe permet de rétrécir tous les fichiers de données temporaires du tablespace alors que la
deuxième syntaxe travaille sur un fichier spécifique. La clause KEEP définit une taille minimum à conserver pour le
tablespace ou le fichier ; si cette clause est absente, Oracle tente de libérer le maximum d’espace. Si la clause KEEP
est trop basse, une erreur est retournée :
ORA-03214: La taille de fichier indiquée est inférieure au minimum requis
Curieusement, cette erreur est aussi retournée si la clause KEEP est absente et qu’Oracle tente de rétrécir le fichier à
une taille inférieure au minimum requis.
Enfin, le tablespace temporaire par défaut ne peut pas être supprimé. Il en est de même pour tout tablespace
temporaire appartenant à un groupe de tablespaces temporaires utilisé comme tablespace temporaire par défaut.
Pour placer un tablespace temporaire dans un groupe de tablespaces temporaires, le changer de groupe ou le retirer
d’un groupe, vous pouvez utiliser la clause TABLESPACE GROUP de l’ordre SQL ALTER TABLESPACE.
Syntaxe :
ALTER TABLESPACE nom_tablespace TABLESPACE GROUP nom_groupe | ’’ ;
Vous pouvez utiliser une chaîne vide pour n’affecter le tablespace à aucun groupe. Lors de l’affectation d’un
tablespace temporaire à un groupe, le groupe est implicitement créé s’il n’existe pas. Lorsqu’un tablespace
temporaire est retiré d’un groupe, le groupe est implicitement supprimé s’il ne contient plus de tablespace
temporaire.
Vous ne pouvez pas retirer le dernier tablespace temporaire d’un groupe si ce groupe est utilisé comme tablespace
temporaire par défaut.
© ENI Editions - All rights reserved - Algeria Educ
- 5-
Conclusions
1. Avantages des tablespaces gérés localement
Les tablespaces gérés localement présentent de nombreux avantages :
●
●
●
moins de SQL récursif, voire de gestion récursive de l’espace, lié à la mise à jour du dictionnaire de données ;
extensions adjacentes libres automatiquement identifiées, ce qui élimine les opérations de fusion (coalesce)
des extensions adjacentes libres ;
limitation, voire disparition, des problèmes de fragmentation de l’espace disponible.
Avec un tablespace géré par le dictionnaire, lorsque l’instance alloue ou libère une extension, elle doit lire puis mettre
à jour le dictionnaire de données, par l’intermédiaire d’ordre SQL SELECT, INSERT, UPDATE ou DELETE ; ces différents
ordres sont appelés "SQL récursif" et sont susceptibles d’utiliser de l’espace d’annulation dans le segment
d’annulation SYSTEM. Lors de la mise à jour du dictionnaire, Oracle peut manquer de place dans la table du
dictionnaire ou dans le segment d’annulation : il en résulte une allocation récursive d’espace, pénalisante pour les
performances. Ces problèmes disparaissent en grande partie avec les tablespaces gérés localement.
Dans un tablespace géré par le dictionnaire, lorsqu’une extension est libérée, Oracle ne regarde pas immédiatement
si elle est adjacente à une extension déjà libre. Plus tard, en tâche de fond ou en cas de recherche d’une grande
extension, le processus SMON fusionnera les extensions adjacentes libres du tablespace : c’est l’opération de
coalesce. Cette opération peut prendre beaucoup de temps s’il y a un grand nombre d’extensions libres dans le
tablespace. Dans un tablespace géré localement, cette opération n’est pas nécessaire car les extensions adjacentes
libres sont automatiquement identifiées dans la bitmap (zéros qui se suivent).
Un des objectifs des tablespaces gérés localement est de rationaliser l’utilisation de l’espace dans les tablespaces et
d’éviter le phénomène de fragmentation de l’espace disponible. Cette fragmentation de l’espace disponible peut
survenir suite à une forte activité d’allocation/libération d’extensions : il peut y avoir beaucoup d’espace disponible
dans le tablespace mais sous la forme d’une multitude de petites extensions non adjacentes. Le risque de
fragmentation disparaît complètement dans un tablespace géré localement avec une gestion uniforme des
extensions : toutes les extensions allouées dans le tablespace ont forcément la même taille et une extension libérée
pourra obligatoirement être réutilisée.
Lorsque les extensions sont gérées par Oracle, l’instance utilise un algorithme qui vise à réduire le risque de
fragmentation, d’une part en utilisant un petit nombre de tailles différentes d’extensions, et d’autre part en allouant
consécutivement des extensions qui, regroupées, peuvent constituer une extension de taille supérieure.
2. Recommandations
Oracle recommande d’utiliser des tablespaces gérés localement :
●
●
pour le tablespace SYSTEM ;
pour le tablespace temporaire, en le créant dès la création de la base de données, pour avoir en plus un
tablespace temporaire par défaut ;
●
pour les segments d’annulation (chapitre Gestion des informations d’annulation) ;
●
pour les tablespaces des tables et des index.
Quel mode de gestion choisir pour les extensions des tablespaces de tables et d’index ? Préférez une gestion
automatique des extensions, si vous n’avez pas une bonne vision des besoins en espace et que vous ne souhaitiez
exercer aucun contrôle sur l’allocation des extensions. Choisissez une gestion uniforme des extensions si vous
souhaitez contrôler l’allocation des extensions et que vous ayez une bonne vision de vos besoins en espace.
Les tablespaces gérés localement avec une gestion automatique des extensions sont intéressants lorsque la
volumétrie des segments est complètement inconnue ; ils permettent une gestion plus saine de l’espace que les
tablespaces gérés par le dictionnaire. Si les besoins sont connus avec précision, utiliser des tablespaces gérés
localement avec une gestion uniforme des extensions n’est pas forcément immédiat, notamment pour déterminer la
bonne taille d’extension ; dans ce cas, il faut sans doute employer plusieurs tablespaces pour séparer les segments
en grandes catégories. Exemple :
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
●
les "petits" (par ex. entre 0 et 2 Mo) : un tablespace avec des extensions de 64 Ko ;
●
les "moyens" (par ex. entre 2 Mo et 64 Mo) : un tablespace avec des extensions de 2 Mo ;
●
les "gros" (par ex. au delà de 64 Mo) : un tablespace avec des extensions de 64 Mo (et sans doute plusieurs
tablespaces).
Dans le chapitre Gestion des tables et des index, nous verrons comment estimer la taille des segments à une
échéance donnée.
- 2-
© ENI Editions - All rights reserved - Algeria Educ
Trouver des informations sur les tablespaces et les fichiers de
données
1. Tablespaces et fichiers de données
Plusieurs vues du dictionnaire de données permettent d’obtenir des informations sur les tablespaces et les fichiers de
données :
●
●
●
●
●
DBA_TABLESPACES ou V$TABLESPACE : informations sur les tablespaces ;
DBA_DATA_FILES ou V$DATAFILE : informations sur les fichiers de données <(sauf ceux des tablespaces
temporaires gérés localement) ;
DBA_TEMP_FILES ou V$TEMPFILE : informations sur les fichiers de données des tablespaces temporaires gérés
localement ;
DBA_TABLESPACE_GROUPS : informations sur les groupes de tablespaces temporaires ;
DATABASE_PROPERTIES : propriétés de la base de données, dont le tablespace temporaire par défaut, le
tablespace permanent par défaut et le type de tablespace par défaut (BIGFILE ou SMALLFILE).
Les colonnes intéressantes des différentes vues sont présentées ci­après.
DBA_TABLESPACES
TABLESPACE_NAME
Nom du tablespace.
CONTENTS
Type du tablespace (PERMANENT ou TEMPORARY ou UNDO).
EXTENT_MANAGEMENT
DICTIONARY : le tablespace est géré par le dictionnaire. LOCAL : le tablespace est géré localement.
ALLOCATION_TYPE
USER : gestion des extensions par "l’utilisateur" (tablespace géré par le dictionnaire). SYSTEM : gestion automatique
des extensions (tablespace géré localement). UNIFORM : gestion uniforme des extensions (tablespace géré
localement).
STATUS
Statut du tablespace (ONLINE, OFFLINE ou READ ONLY).
BLOCK_SIZE
Taille de bloc du tablespace.
LOGGING
Mode de journalisation par défaut (LOGGING ou NOLOGGING).
FORCE_LOGGING
Indique si le tablespace est en FORCE LOGGING (YES ou NO).
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
SEGMENT_SPACE_MANAGEMENT
Indique si l’espace libre dans les segments est géré manuellement (MANUAL) ou automatiquement (AUTO).
BIGFILE
Indique si le tablespace est un tablespace BIGFILE (YES ou NO).
Exemple :
SQL> SELECT tablespace_name,contents,extent_management,
2
allocation_type,bigfile,block_size,status
3 FROM dba_tablespaces;
TABLESPACE_NAME CONTENTS EXTENT_MAN ALLOCATIO BIG BLOCK_SIZE STATUS
--------------- --------- ---------- --------- --- ---------- -----SYSTEM
PERMANENT LOCAL
SYSTEM
NO
8192 ONLINE
UNDOTBS
UNDO
LOCAL
SYSTEM
NO
8192 ONLINE
SYSAUX
PERMANENT LOCAL
SYSTEM
NO
8192 ONLINE
TEMP
TEMPORARY LOCAL
UNIFORM
NO
8192 ONLINE
DEFTBS
PERMANENT LOCAL
SYSTEM
NO
8192 ONLINE
DATA
PERMANENT LOCAL
UNIFORM
NO
8192 ONLINE
INDX
PERMANENT LOCAL
SYSTEM
NO
8192 ONLINE
JE_SUIS_GROS
PERMANENT LOCAL
SYSTEM
YES
8192 ONLINE
DBA_DATA_FILES et DBA_TEMP_FILES
FILE_NAME
Nom du fichier de données (chemin complet).
FILE_ID
Identifiant du fichier de données.
TABLESPACE_NAME
Nom du tablespace auquel le fichier de données appartient.
BYTES
Taille du fichier en octets.
BLOCKS
Taille du fichier en blocs Oracle.
STATUS
Statut du fichier (INVALID ou AVAILABLE).
RELATIVE_FNO
Numéro relatif du fichier par rapport au tablespace.
AUTOEXTENSIBLE
Indicateur d’autoextensibilité (YES ou NO).
MAXBYTES
Taille maximum du fichier en octets.
MAXBLOCKS
- 2-
© ENI Editions - All rights reserved - Algeria Educ
Taille maximum du fichier en blocs Oracle.
INCREMENT_BY
Taille de l’incrément de l’autoextension en blocs Oracle.
USER_BYTES
Taille utile du fichier en octets (généralement taille du fichier moins les blocs d’en­tête).
USER_BLOCKS
Taille utile du fichier en blocs Oracle (généralement taille du fichier moins les blocs d’en­tête).
Exemple :
SQL> SELECT tablespace_name,file_name,status,autoextensible,
2
blocks,user_blocks,maxblocks
3 FROM (
SELECT * FROM dba_data_files
4
UNION ALL SELECT * FROM dba_temp_files);
TABLESPACE_NAME FILE_NAME
STATUS
AUT
--------------- ---------------------------------------- --------- --BLOCKS USER_BLOCKS MAXBLOCKS
---------- ----------- ---------SYSTEM
F:\ORADATA\HERMES\SYSTEM01.DBF
AVAILABLE YES
29440
29432
4194302
UNDOTBS
E:\ORADATA\HERMES\UNDOTBS01.DBF
AVAILABLE YES
20480
20472
131072
SYSAUX
E:\ORADATA\HERMES\SYSAUX01.DBF
AVAILABLE YES
14080
14072
4194302
DEFTBS
E:\ORADATA\HERMES\DEFTBS01.DBF
AVAILABLE YES
6400
6392
64000
DATA
F:\ORADATA\HERMES\DATA01.DBF
AVAILABLE YES
64000
62720
102400
INDX
E:\ORADATA\HERMES\INDX01.DBF
AVAILABLE YES
64000
63992
102400
DATA
F:\ORADATA\HERMES\DATA02.DBF
AVAILABLE YES
25600
24320
64000
JE_SUIS_GROS
E:\ORADATA\HERMES\JE_SUIS_GROS.DBF
AVAILABLE NO
128
112
0
TEMP
F:\ORADATA\HERMES\TEMP01.DBF
AVAILABLE YES
12800
12672
131072
V$TABLESPACE
TS#
Numéro du tablespace.
NAME
Nom du tablespace.
BIGFILE
Indique si le tablespace est un tablespace BIGFILE (YES ou NO).
V$DATAFILE et V$TEMPFILE
TS#
Numéro du tablespace auquel le fichier de donnée appartient.
FILE#
Identifiant du fichier de données.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
NAME
Nom du fichier de données (chemin complet).
STATUS
Statut du fichier de données (OFFLINE, ONLINE, SYSTEM ou RECOVER).
ENABLED
Disponibilité du fichier de données (DISABLED, READ ONLY, READ WRITE).
BYTES
Taille du fichier en octets.
CREATE_BYTES
Taille du fichier à sa création en octets.
BLOCKS
Taille du fichier en blocs Oracle.
BLOCK_SIZE
Taille de bloc du fichier de données.
CREATION_TIME
Date et heure de création du fichier.
CHECKPOINT_CHANGE#
Numéro SCN du dernier point de reprise (n’existe pas dans V$TEMPFILE).
CHECKPOINT_TIME
Date et heure du dernier point de reprise (n’existe pas dans V$TEMPFILE).
Exemple :
SQL> SELECT file#,name,status,enabled,checkpoint_change#
2 FROM v$datafile ;
FILE# NAME
STATUS ENABLED
CHECKPOINT
----- ----------------------------------- ------- ---------- ---------1 F:\ORADATA\HERMES\SYSTEM01.DBF
SYSTEM READ WRITE
421362
2 E:\ORADATA\HERMES\UNDOTBS01.DBF
ONLINE READ WRITE
421362
3 E:\ORADATA\HERMES\SYSAUX01.DBF
ONLINE READ WRITE
421362
4 E:\ORADATA\HERMES\DEFTBS01.DBF
ONLINE READ WRITE
421362
5 F:\ORADATA\HERMES\DATA01.DBF
ONLINE READ WRITE
421362
6 E:\ORADATA\HERMES\INDX01.DBF
ONLINE READ WRITE
421362
8 F:\ORADATA\HERMES\DATA02.DBF
ONLINE READ WRITE
421362
9 E:\ORADATA\HERMES\JE_SUIS_GROS.DBF ONLINE READ WRITE
421362
DBA_TABLESPACE_GROUPS
GROUP_NAME
Nom du groupe.
TABLESPACE_NAME
- 4-
© ENI Editions - All rights reserved - Algeria Educ
Nom du tablespace.
DATABASE_PROPERTIES
PROPERTY_NAME
Nom de la propriété :
DEFAULT_TBS_TYPE : type de tablespace par défaut (SMALLFILE ou BIGFILE).
DEFAULT_TEMP_TABLESPACE : tablespace temporaire par défaut (peut être un groupe de tablespaces temporaires).
DEFAULT_PERMANENT_TABLESPACE : tablespace permanent par défaut.
PROPERTY_VALUE
Nom du tablespace.
Exemple
SQL> SELECT property_name,property_value
2 FROM database_properties
3 WHERE property_name IN (’DEFAULT_TEMP_TABLESPACE’,
4
’DEFAULT_PERMANENT_TABLESPACE’,
5
’DEFAULT_TBS_TYPE’);
PROPERTY_NAME
PROPERTY_VALUE
------------------------------ ---------------DEFAULT_TEMP_TABLESPACE
TEMP
DEFAULT_PERMANENT_TABLESPACE
DEFTBS
DEFAULT_TBS_TYPE
SMALLFILE
2. Supervision du stockage dans les tablespaces
Plusieurs vues du dictionnaire de données permettent d’obtenir des informations sur le stockage à l’intérieur des
tablespaces :
●
DBA_FREE_SPACE : informations sur l’espace disponible à l’intérieur d’un tablespace ;
●
DBA_SEGMENTS : informations sur les segments alloués à l’intérieur d’un tablespace ;
●
DBA_EXTENTS : informations sur les extensions allouées à l’intérieur d’un tablespace ;
●
V$SORT_SEGMENT : supervision du stockage des segments temporaires ;
●
V$SYSAUX_OCCUPANTS : informations sur les composants qui utilisent de l’espace dans le tablespace SYSAUX.
Les colonnes intéressantes des différentes vues sont présentées ci­après.
DBA_SEGMENTS
OWNER
Nom du propriétaire du segment.
SEGMENT_NAME
Nom du segment.
SEGMENT_TYPE
Type du segment (TABLE, INDEX, ROLLBACK, TYPE2 UNDO, etc.).
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 5-
TABLESPACE_NAME
Nom du tablespace qui contient le segment.
BYTES
Taille du segment en octets.
BLOCKS
Taille du segment en blocs Oracle.
EXTENTS
Nombre d’extensions allouées au segment.
INITIAL_EXTENT
Taille initiale du segment.
Exemple :
SQL> SELECT segment_name,segment_type,
2
initial_extent/1024 initial_ko,blocks,extents
3 FROM dba_segments WHERE tablespace_name=’TEST’;
SEGMENT_NAME
SEGMENT_TYPE
INITIAL_KO
BLOCKS
EXTENTS
--------------- ------------------ ---------- ---------- ---------TABLE2M
TABLE
2048
256
2
TABLE200K
TABLE
200
32
4
DBA_FREE_SPACE
TABLESPACE_NAME
Nom du tablespace qui contient l’extension libre.
FILE_ID
Identifiant du fichier de données qui contient l’extension libre.
BLOCK_ID
Numéro du premier bloc de l’extension libre.
BYTES
Taille de l’extension libre en octets.
BLOCKS
Taille de l’extension libre en blocs Oracle.
Un tablespace qui n’a pas d’extension libre n’a pas de ligne dans DBA_FREE_SPACE.
DBA_EXTENTS
OWNER
Nom du propriétaire du segment auquel l’extension appartient.
SEGMENT_NAME
Nom du segment auquel l’extension appartient.
- 6-
© ENI Editions - All rights reserved - Algeria Educ
SEGMENT_TYPE
Type du segment (TABLE, INDEX, ROLLBACK, TYPE2 UNDO, etc.).
TABLESPACE_NAME
Nom du tablespace qui contient l’extension.
EXTENT_ID
Numéro de l’extension (0 pour la première).
FILE_ID
Identifiant du fichier de données qui contient l’extension.
BLOCK_ID
Numéro du premier bloc de l’extension.
BYTES
Taille de l’extension en octets.
BLOCKS
Taille de l’extension en blocs Oracle.
En complément, plusieurs vues possèdent une colonne TABLESPACE indiquant le nom du tablespace de stockage, par
exemple DBA_INDEXES et DBA_TABLES.
Exemple :
SQL> SELECT block_id,extent_id,segment_name,
2
blocks,bytes/1024 taille_ko
3 FROM dba_extents WHERE tablespace_name=’TEST’
4 UNION
5 SELECT block_id,NULL,’*** LIBRE ***’,
6
blocks,bytes/1024 size_ko
7 FROM dba_free_space WHERE tablespace_name=’TEST’;
BLOCK_ID EXTENT_ID SEGMENT_NAME
BLOCKS TAILLE_KO
---------- ---------- --------------- ---------- ---------9
0 TABLE200K
8
64
17
1 TABLE200K
8
64
25
2 TABLE200K
8
64
33
3 TABLE200K
8
64
41
*** LIBRE ***
96
768
137
0 TABLE2M
128
1024
265
1 TABLE2M
128
1024
393
*** LIBRE ***
888
7104
V$SORT_SEGMENT
TABLESPACE_NAME
Nom du tablespace.
EXTENT_SIZE
Taille des extensions.
TOTAL_EXTENTS
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 7-
Nombre total d’extensions dans le segment.
TOTAL_BLOCKS
Nombre total de blocs Oracle dans le segment.
USED_EXTENTS
Nombre d’extensions actuellement allouées à des tris actifs.
USED_BLOCKS
Nombre total de blocs Oracle actuellement alloués à des tris actifs.
MAX_USED_SIZE
Nombre maximum d’extensions utilisées par tous les tris (simultanément).
MAX_USED_BLOCKS
Nombre maximum de blocs utilisés par tous les tris (simultanément).
MAX_SORT_SIZE
Nombre maximum d’extensions utilisées par un tri (le plus gros tri).
MAX_SORT_BLOCKS
Nombre maximum de blocs utilisés par un tri (le plus gros tri).
Exemple :
SQL> SELECT tablespace_name,total_blocks,used_blocks,
2
max_used_blocks,max_sort_blocks
3 FROM
v$sort_segment;
TABLESPACE_NAME TOTAL_BLOCKS USED_BLOCKS MAX_USED_BLOCKS MAX_SORT_BLOCKS
--------------- ------------ ----------- --------------- --------------TEMP
256
0
256
64
Il existe aussi une vue, V$TEMPSEG_USAGE, qui peut être utile pour identifier les sessions (et les requêtes) qui utilisent
actuellement de l’espace temporaire.
Exemple :
SQL> SELECT t.username,t.tablespace,t.segtype,t.extents,t.blocks,
2
s.sql_text
3 FROM v$tempseg_usage t,v$sql s
4 WHERE t.sql_id = s.sql_id;
USERNAME
TABLESPACE SEGTYPE
EXTENTS
BLOCKS
---------- ---------- --------- ---------- ---------SQL_TEXT
----------------------------------------------------OHEU
TEMP
SORT
2
256
SELECT * FROM t ORDER BY c1,c2,c3
V$SYSAUX_OCCUPANTS
OCCUPANT_NAME
Nom du composant.
OCCUPANT_DESC
Description du composant.
- 8-
© ENI Editions - All rights reserved - Algeria Educ
SCHEMA_NAME
Nom du schéma dans lequel le composant est stocké.
MOVE_PROCEDURE
Nom de la procédure permettant de déplacer le composant dans un autre tablespace.
MOVE_PROCEDURE_DESC
Description de la procédure de déplacement.
SPACE_USAGE_KBYTES
Espace actuellement utilisé par le composant (en Ko).
Exemple :
SQL> SELECT occupant_desc,space_usage_kbytes
2 FROM v$sysaux_occupants WHERE space_usage_kbytes <0>;
OCCUPANT_DESC
SPACE_USAGE_KBYTES
---------------------------------------------------- -----------------LogMiner
7744
Logical Standby
1024
Transaction Layer - SCN to TIME mapping
448
PL/SQL Identifier Collection
384
Oracle Streams
1024
Analytical Workspace Object Table
1408
OLAP API History Tables
1408
Server Manageability - Automatic Workload Repository
29184
Server Manageability - Advisor Framework
7744
Server Manageability - Optimizer Statistics History
4608
Server Manageability - Other Components
5952
Enterprise Manager Repository
127424
Enterprise Manager Monitoring User
1536
Oracle Transparent Session Migration User
256
SQL Management Base Schema
1728
Automated Maintenance Tasks
320
Unified Job Scheduler
384
Dans une installation de base, sans options particulières, deux composants utilisent un espace important :
●
le référentiel des fonctionnalités de gestion automatique de la base de données (SM/AWR) ;
●
le référentiel du Database Control (EM).
Si un composant utilise beaucoup de place dans le tablespace SYSAUX, il est possible d’envisager de le déplacer dans
un autre tablespace. Cette opération s’effectue généralement à l’aide d’une procédure d’un package dont les
références sont données dans la colonne MOVE_PROCEDURE de la vue V$SYSAUX_OCCUPANTS. Certains composants ne
peuvent pas être déplacés (par exemple les composants relatifs à la gestion automatique de la base de données).
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 9-
Conventions d’écriture
Cet ouvrage utilise les conventions d’écriture suivantes pour les ordres SQL, les commandes SQL*Plus et les
commandes RMAN :
MOT EN MAJUSCULES
Mots clés de la commande (CREATE TABLE). Dans la pratique, ils peuvent être saisis indifféremment en majuscules ou
en minuscules.
mot en minucules
Valeurs à saisir, relatives à la base de données ou à l’application (nom de table, nom de colonne, etc).Dans la pratique,
elles peuvent être saisies indifféremment en majuscules ou en minuscules, sauf si elles figurent entre apostrophes
(dans ce cas, elles sont sensibles à la casse).
[]
Clause optionnelle.
[,...]
La clause précédente peut être répétée plusieurs fois.
|
Indique un choix entre plusieurs options.
{}
Délimite une liste d’options.
mot souligné
Valeur par défaut.
Par ailleurs, l’ouvrage fait très souvent référence à des variables d’environnement du système d’exploitation. Dans ce
cas, les notations Windows et Unix/Linux sont utilisées :
●
Windows : %VARIABLE%
●
Unix/Linux : $VARIABLE
Parfois, l’ouvrage fait aussi référence à des chemins, des noms de fichiers, des noms de menus qui peuvent contenir
une chaîne de caractères correspondant à une valeur spécifique de votre environnement, que vous avez pu définir par
exemple lors d’une installation. Dans ce cas, la chaîne à substituer avec la valeur correspondant à votre environnement
est mise en italique, et parfois même entre les signes < et > s’il y a ambiguïté.
Exemple : OracleServiceSID ou OracleService<SID>
Et pour terminer, l’éternelle question : que faut­il faire des termes techniques en anglais ? Les traduire ou pas ? Dans
les commandes, les termes techniques sont en anglais, d’où la nécessité de les connaître. Si vous utilisez les outils
graphiques en français, vous constaterez que beaucoup de ces termes ont été traduits, ce qui est parfois déroutant
(d’autant que certaines traductions sont un peu "bizarres"). Dans cet ouvrage, j’ai donc tenté de donner les
correspondances systématiquement, mais en essayant de ne pas trop alourdir mon propos.
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Utiliser le Database Control
1. Espace disque logique (tablespace)
Dans le Database Control, cliquez sur le lien Serveur sur la page d’accueil puis sur le lien Espaces disque logiques
(cadre Stockage) pour accéder à la page de gestion des tablespaces :
À partir de cette page, vous pouvez effectuer diverses actions sur les tablespaces :
●
créer un nouveau tablespace (bouton Créer ou menu Créer comme) ;
●
supprimer un tablespace (bouton Supprimer) ;
●
modifier un tablespace (bouton Modifier) ;
●
ajouter un fichier de données à un tablespace (menu Ajouter un fichier de données) ;
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
●
placer un tablespace en lecture seule (menu Mettre en lecture seule), en lecture écriture (menu Rendre
accessible en écriture), l’activer (menu Mettre en ligne), le désactiver (menu Mettre hors ligne).
En cliquant sur le lien du nom de tablespace, ou en cliquant sur les boutons Créer, Modifier ou Visualiser, vous
arrivez sur la page de définition d’un tablespace.
L’onglet Général permet de définir le nom et les caractéristiques générales du table­ space : mode de gestion, type,
statut.
L’onglet Stockage permet de préciser des informations relatives au stockage : gestion uniforme ou automatique des
extensions, mode de gestion de l’espace dans les segments, taille de bloc.
Dans la terminologie du Database Control, en français, un "ensemble de blocs contigus" est une extension.
L’onglet Seuils permet de définir des seuils d’alerte sur le remplissage du tablespace<, cet onglet est présent
uniquement lors de la consultation ou modification d’un tablespace. Par défaut, le Database Control utilise un seuil
d’avertissement à 85 % et un seuil critique à 97 %. Les alertes sont visible sur la page d’accueil du Database Control.
2. Fichier de données
Dans le Database Control, cliquez sur le lien Serveur sur la page d’accueil puis sur le lien Fichiers de données (cadre
Stockage) pour accéder à la page de gestion des fichiers de données :
- 2-
© ENI Editions - All rights reserved - Algeria Educ
À partir de cette page, vous pouvez effectuer diverses actions sur les fichiers de données :
■
ajouter un fichier de données à un tablespace (menu Créer comme) ;
■
modifier le fichier de données (bouton Modifier) ;
■
supprimer le fichier de données (bouton Supprimer).
En cliquant sur le lien du nom du fichier de données, ou en cliquant sur les boutons Modifier ou Visualiser, vous
arrivez sur la page de définition d’un fichier de données :
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Si vous modifiez le nom d’un fichier de données, ou si vous le changez de répertoire, le Database Control va
simplement réaliser un ALTER DATABASE RENAME FILE ; il ne va effectuer aucune action sur le fichier physique.
L’opération échouera si le fichier de données n’a pas été au préalable renommé et/ou déplacé.
3. Groupe de tablespace temporaire
Dans le Database Control, cliquez sur le lien Serveur sur la page d’accueil puis sur le lien Groupes d’espaces disque
logiques temporaires (cadre Stockage) pour accéder à la page de gestion des groupes de tablespaces temporaires.
Pour créer un nouveau groupe, cliquez sur le bouton Créer ; vous arrivez sur la page de définition d’un groupe :
- 4-
© ENI Editions - All rights reserved - Algeria Educ
Indiquez le nom du groupe puis cliquez sur le bouton Ajouter/Enlever pour ajouter un tablespace temporaire au
nouveau groupe.
Le Database Control exécutera tout simplement un ordre SQL ALTER TABLESPACE ... TABLESPACE GROUP qui aura pour
effet, de créer implicitement le groupe s’il n’existait pas.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 5-
Problèmes courants et solutions
Ce n’est qu’un début. Nous verrons d’autres problèmes possibles, relatifs au stockage dans un tablespace
dans le chapitre Gestion des tables et des index (stockage des tables et des index).
ORA-01652: impossible d’étendre le segment temporaire deN
dans le tablespace X
Explication
Le segment temporaire n’arrive pas à s’étendre (lors d’un tri par exemple).
Cause(s)
Le segment temporaire n’arrive pas à s’étendre car le tablespace dans lequel il est stocké n’a pas suffisamment
d’espace disponible et ne peut lui­même s’étendre.
Action(s)
Il faut augmenter l’espace disponible dans le tablespace :
­ soit en lui allouant un nouveau fichier de données (ALTER TABLESPACE... ADD TEMPFILE ...) ;
­ soit en augmentant la taille d’un fichier de données du tablespace (ALTER DATABASE TEMPFILE ... RESIZE ...) ;
­ soit en autorisant un fichier de données du tablespace à s’étendre automatiquement (ALTER DATABASE TEMPFILE ...
AUTOEXTEND ON ...).
En cas de besoin, la vue V$TEMPSEG_USAGE peut être employée pour superviser en temps réels les opérations qui
utilisent de l’espace temporaire.
Ce problème peut se produire sur toute requête qui sollicite un tri.
ORA-01630: nbre max. d’ensembles de blocs contigus (N) atteint
dans segment temp, tablespace X
Explication
Le segment temporaire n’arrive pas à s’étendre (lors d’un tri par exemple).
Cause(s)
Le segment temporaire n’arrive pas à s’étendre car il atteint son nombre maximum d’extensions, défini par le
MAXEXTENTS de la clause DEFAULT STORAGE du tablespace dans lequel il est stocké. Ne peut se produire que lorsque le
tablespace utilisé pour stocker les segments temporaires est permanent (SYSTEM, par exemple).
Action(s)
Interroger la colonne CONTENTS de la vue DBA_TABLESPACES pour savoir s’il existe un tablespace temporaire dans la base
de données. Si oui, l’affecter aux utilisateurs (chapitre Gestion des utilisateurs et de leurs droits) et/ou le définir comme
tablespace temporaire par défaut (ALTER DATABASE DEFAULT TEMPORARY TABLESPACE...). Si non, en créer un (CREATE
TEMPORARY TABLESPACE...) et l’affecter aux utilisateurs (cf. Chapitre Gestion des utilisateurs et de leur droits) et/ou le
définir comme tablespace temporaire par défaut.
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Vue d’ensemble
1. Définitions
Lorsque des modifications de données sont en cours, Oracle génère des informations d’annulation qui seront
utilisées, si nécessaire, pour annuler les modifications. Ces informations d’annulation contiennent essentiellement la
valeur précédente des données qui sont modifiées par la transaction ("image avant", "before image" en anglais) et
l’identification des blocs concernés.
Les informations d’annulation sont stockées dans des segments d’annulation.
Elles sont principalement utilisées pour :
●
l’annulation de la transaction (ROLLBACK) ;
●
la lecture cohérente ;
●
certaines fonctionnalités de flashback;
●
la récupération de la base de données (RECOVER).
Le segment d’annulation est une structure utilisée par Oracle pour stocker temporairement la version précédente des
données en cours de modification dans une transaction. Si la transaction est validée (COMMIT), l’espace occupé sera
libéré ; si la transaction est annulée (ROLLBACK), la version précédente des données sera remise à la place de la
nouvelle.
Les segments d’annulation sont par ailleurs utilisés par Oracle pour le mécanisme de lecture cohérente. La notion de
lecture cohérente correspond au fait que les données en cours de modification dans une transaction ne sont pas vues
des autres utilisateurs tant que la transaction n’est pas validée ; les autres utilisateurs voient les données telles
qu’elles étaient avant le début de la transaction, dans un état cohérent vis­à­vis des transactions et des règles de
gestion. Si un utilisateur interroge une table en cours de mise à jour dans une autre transaction, Oracle utilisera la
valeur précédente des données, stockée dans les segments d’annulation, pour répondre à la requête.
Les segments d’annulation sont aussi utilisés par certaines fonctionnalités de flashback qui permettent de lire (et
récupérer) les données telles qu’elles étaient à un instant donné dans le passé (voir chapitre Sauvegarde et
récupération).
Enfin, les segments d’annulation sont utilisés lors d’une récupération de la base de données pour annuler les
modifications non validées qui avaient déjà été écrites dans les fichiers de données (voir les principes au chapitre
Sauvegarde et récupération).
Les besoins en informations d’annulation varient énormément, en fonction de la nature de la mise à jour et de la
présence ou non d’index (les valeurs précédentes des entrées d’index sont aussi stockées dans les informations
d’annulation).
Ce qu’il faut retenir :
●
●
Un INSERT est peu coûteux en espace d’annulation : c’est normal, il n’y a pas d’image avant, juste des
informations de contrôle.
Un UPDATE ou un DELETE est plus coûteux en espace d’annulation et d’autant plus coûteux que l’image avant
(les valeurs précédentes des colonnes mises à jour pour un UPDATE et la ligne complète pour un DELETE) est de
taille importante.
2. Gestion
Avant Oracle9i, les segments d’annulation devaient être gérés par le DBA. Pour dimensionner correctement les
segments d’annulation (nombre et taille), le DBA devait posséder une connaissance assez précise du fonctionnement
de la base de données et des besoins de l’application. Cette connaissance était généralement difficile à maîtriser a
priori, et il était souvent nécessaire de redimensionner les segments d’annulation en cours d’exploitation. Un mauvais
dimensionnement pouvait être à l’origine d’erreurs (ORA-01552, ORA-01562, ORA-01555, etc.) ou de problèmes de
performance.
Depuis Oracle9i, Oracle propose une gestion "automatique" des informations/segments d’annulation, à l’aide d’un
tablespace d’annulation (tablespace de type UNDO).
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Pour des raisons de compatibilité ascendante, il est toujours possible d’utiliser une gestion "manuelle" des segments
d’annulation, mais ce n’est pas recommandé par Oracle qui conseille vivement l’emploi de la gestion automatique.
Seule la gestion automatique est présentée dans cet ouvrage. C’est le mode par défaut depuis la version 11.
Dans la documentation Oracle, en anglais, cette fonctionnalité est appelée Automatic Undo Management et souvent
désignée par le sigle AUM ; la terminologie System Managed Undo (SMU) est aussi utilisée.
3. Structure
Comme tous les segments, un segment d’annulation est stocké dans un tablespace et est, composé d’extensions.
Il est important de comprendre que les segments d’annulation correspondent avant tout à une structure physique (un
segment) dont les blocs sont chargés en mémoire (dans le Database Buffer Cache) en fonction des besoins ; si
l’instance a besoin d’espace dans le Database Buffer Cache, les blocs de segments d’annulations sont susceptibles
d’être écrits sur disque.
Pour mémoire (chapitre Les bases de l’architecture Oracle), les modifications apportées aux blocs de segments
d’annulations dans le Database Buffer Cache sont enregistrées dans les fichiers de journalisation. De cette manière, en
cas de restauration d’instance ou de restauration de média, Oracle est en mesure de reconstituer les segments
d’annulation et d’annuler les modifications déjà écrites dans les fichiers de données, pour des transactions non
validées au moment de l’incident.
4. Le segment d’annulation SYSTEM
Quel que soit le mode de gestion des informations d’annulation, il existe toujours un segment d’annulation nommé
SYSTEM, créé lors de la création de la base de données, et stocké dans le tablespace SYSTEM.
Ce segment d’annulation est utilisé pour les transactions sur les segments stockés dans le tablespace SYSTEM.
L’existence de ce segment d’annulation permet toujours à la base de données de démarrer, même si les structures
adaptées au mode de gestion choisi (tablespace d’annulation dans le cas de la gestion automatique) n’existent pas.
Cependant, les structures adaptées doivent être créées pour permettre l’exécution de transactions dans d’autres
tablespaces que le tablespace SYSTEM. Si la base de données ne contient que le segment d’annulation SYSTEM, une
erreur (ORA-01552) se produira lors de la première transaction dans un tablespace autre que le tablespace SYSTEM.
5. Durée de rétention des informations d’annulation
Lorsqu’une transaction se termine, les informations d’annulation la concernant ne sont plus nécessaires pour effectuer
une annulation de la transaction (ROLLBACK). Par contre, ces informations peuvent encore être utiles pour une lecture
cohérente.
En effet, une lecture cohérente longue qui a commencé avant ou pendant une transaction peut encore avoir besoin de
l’image avant, après la fin de la transaction. Si cette image avant ancienne n’est plus disponible (l’espace a été
réutilisé par une autre transaction), une erreur ORA-01555 (la "fameuse" erreur snapshot too old) est retournée.
De même, une opération flashback peut avoir besoin d’informations d’annulation anciennes.Pour ces deux raisons, il
est souhaitable de conserver les informations d’annulation aussi longtemps que possible après la fin de la transaction.
Avec la gestion automatique de l’annulation, il existe une durée de conservation (rétention) des informations
d’annulation (undo retention period) ; c’est la durée minimale pendant laquelle Oracle tente de conserver les
informations d’annulation des transactions validées, avant de réutiliser l’espace. Les informations d’annulation des
transactions validées sont dites expirées (expired) si elles sont plus anciennes que la période de conservation actuelle,
et l’espace qu’elles occupent peut être réutilisé par de nouvelles transactions. À l’inverse, les informations d’annulation
des transactions validées sont dites non expirées (unexpired) si elles sont plus récentes que la période de
conservation actuelle, et Oracle tente de préserver l’espace qu’elles occupent pour satisfaire les lectures cohérentes
et les opérations flashback.
En version 9, la durée de conservation des informations d’annulation était définie par le paramètre
UNDO_RETENTION.Depuis la version 10, la durée de conservation des informations d’annulation est réglée
automatiquement par Oracle. Deux cas se présentent :
●
●
- 2-
Si le tablespace d’annulation est auto­extensible, Oracle règle la durée de conservation à une valeur
légèrement supérieure à la durée de la requête la plus longue. Dans ce cas, si le paramètre UNDO_RETENTION
est défini, il impose une valeur minimum à Oracle.
Si le tablespace d’annulation est de taille fixe, Oracle règle la durée de conservation à la plus grande valeur
© ENI Editions - All rights reserved - Algeria Educ
possible, compte tenu de la taille du tablespace et de l’activité de la base de données. Dans ce cas, si le
paramètre UNDO_RETENTION est défini, il est ignoré (sauf si le tablespace d’annulation est défini avec la garantie
de rétention ­ voir ci­dessous). Il faut noter que pour le calcul, Oracle utilise le seuil d’alerte du remplissage du
tablespace d’annulation (85% par défaut) et non 100% de la taille du tablespace. Modifier la taille du
tablespace d’annulation ou son seuil d’alerte a donc, un impact direct sur la durée de conservation.
Dans le premier cas, l’erreur snapshot too old ne doit normalement jamais se produire lors d’une lecture cohérente. Par
contre, une erreur est toujours possible lors d’une opération flashback ; dans ce cas, il faut augmenter la valeur du
paramètre UNDO_RETENTION pour conserver plus longtemps les informations d’annulation. Si nécessaire, Oracle agrandit
automatiquement le tablespace d’annulation pour honorer la durée de conservation. Si une taille maximum est définie
pour le tablespace et que cette taille maximum soit atteinte, Oracle est susceptible de ne plus pouvoir satisfaire la
durée de conservation, et l’erreur snapshot too old peut survenir.
Dans le deuxième cas, l’erreur snapshot too old peut se produire si le tablespace d’annulation est trop petit et donc la
durée de conservation trop faible. De même, cette durée de conservation peut être insuffisante pour les opérations
flashback.
Dans les deux configurations, en cas de manque d’espace dans le tablespace d’annulation (taille fixe trop faible ou
taille maximum atteinte), la priorité est donnée par défaut aux transactions ; Oracle est alors susceptible de réutiliser
l’espace occupé par des informations d’annulation non expirées, ce qui peut provoquer l’apparition d’erreurs snapshot
too old.
Pour résoudre ce problème, depuis la version 10, il est possible d’activer une "garantie de rétention" au niveau du
tablespace d’annulation. Dans ce cas, il est garanti qu’une information d’annulation ne sera pas écrasée tant qu’elle
n’est pas expirée (sa durée de conservation n’est pas écoulée). Si Oracle manque de place dans le tablespace
d’annulation, il fera échouer les ordres de mises à jour pour garantir la durée de rétention. La priorité est en quelque
sorte donnée aux lectures.
6. Fonctionnement d’un segment d’annulation
Lorsqu’une transaction démarre, un segment d’annulation lui est automatiquement attribué par Oracle. Les segments
d’annulation sont utilisés de manière concurrente par l’ensemble des transactions de la base de données. Lorsque
une transaction commence à utiliser un segment d’annulation, elle inscrit son identifiant dans l’en­tête du segment
puis utilise les blocs dont elle a besoin dans le reste du segment. À partir du moment où une transaction est inscrite
dans un segment d’annulation, elle ne peut pas en changer ni en utiliser un deuxième. Dans la mesure du possible,
Oracle s’arrange pour avoir un nombre suffisants de segments d’annulation afin d’y répartir les transactions (dans
l’idéal une seule transaction par segment d’annulation). Si aucun segment d’annulation n’est libre (pas de transaction
active), Oracle tentera d’activer un segment d’annulation inactif ou créera un nouveau segment d’annulation s’il n’y en
a pas. Une extension d’un segment d’annulation peut avoir trois états :
●
active : l’extension contient des informations d’annulation d’au moins une transaction active.
●
non expirée : l’extension n’est plus active mais elle contient des informations d’annulation non expirées.
●
expirée : l’extension n’est plus active et elle contient des informations d’annulation expirées.
Si un segment d’annulation est plein, et qu’une transaction a encore besoin d’espace dans ce segment, Oracle tentera
d’allouer une extension au segment en respectant l’ordre suivant :
●
Utilisation d’une extension expirée du segment d’annulation.
●
Allocation d’une extension libre (allouée à aucun segment) du tablespace d’annulation.
●
Acquisition (transfert) d’une extension expirée d’un autre segment d’annulation.
●
●
●
Extension d’un fichier de données du tablespace d’annulation (si possible) puis allocation d’une extension
libre.
Utilisation d’une extension non expirée du segment d’annulation, si le tablespace d’annulation n’est pas défini
avec la garantie de rétention.
Acquisition (transfert) d’une extension non expirée d’un autre segment d’annulation, si le tablespace
d’annulation n’est pas défini avec la garantie de rétention.
Si aucune extension ne peut être allouée au segment, une erreur (ORA-30036) est générée.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Il faut noter qu’avec la gestion automatique de l’annulation, une extension expirée (voire non expirée) d’un segment
d’annulation peut être transférée à un autre segment d’annulation qui a besoin d’espace supplémentaire. Ce
mécanisme n’existe pas avec la gestion manuelle. Il permet de retarder le moment où le tablespace d’annulation est
agrandi ou le moment où une erreur est générée. Les extensions non expirées sont réutilisées le plus tard possible
pour satisfaire la durée de conservation.
Un segment d’annulation qui a grossi pourra rétrécir quand l’activité transactionnelle diminuera. Pour rétrécir, le
segment d’annulation libère des extensions expirées en commençant par les plus anciennes.
- 4-
© ENI Editions - All rights reserved - Algeria Educ
Mise en œuvre de la gestion automatique
1. Principe
Pour mettre en œ uvre la gestion automatique des informations d’annulation, il faut :
●
●
positionner le paramètre UNDO_MANAGEMENT à AUTO, et éventuellement affecter des valeurs aux paramètres
UNDO_TABLESPACE et UNDO_RETENTION ;
créer au moins un tablespace d’annulation, lors de la définition de la base de données, ou ultérieurement.
2. Les paramètres d’initialisation
UNDO_MANAGEMENT
Ce paramètre indique le mode de gestion souhaité pour les informations d’annulation. Les valeurs possibles sont
AUTO (valeur par défaut) ou MANUAL. Ce paramètre est statique ; il faut redémarrer la base de données pour changer
le mode de gestion des informations d’annulation.
UNDO_TABLESPACE
Ce paramètre spécifie le nom du tablespace d’annulation à utiliser lors du démarrage de l’instance. Le nom de
n’importe quel tablespace d’annulation peut être indiqué. Par défaut, ce paramètre est vide et le premier tablespace
d’annulation trouvé dans la base de données est utilisé (voir plus loin) ; le paramètre UNDO_TABLESPACE est alors
renseigné par Oracle. Ce paramètre est dynamique.
Le paramètre UNDO_TABLESPACE est surtout intéressant si la base de données dispose de plusieurs tablespaces
d’annulation ; il permet d’indiquer le nom du tablespace d’annulation à utiliser lors du démarrage de l’instance. Ce
paramètre est particulièrement utile en configuration Real Application Clusters pour que chaque instance qui ouvre la
base de données utilise un tablespace spécifique.
En configuration standard, il est plutôt rare d’avoir plusieurs tablespaces d’annulation dans la base de données, sauf
si la base de données a des besoins spécifiques à des moments particuliers de son fonctionnement. Dans ce cas, le
paramètre peut être utilisé pour indiquer le tablespace d’annulation à utiliser au démarrage de l’instance.
Ultérieurement, en modifiant dynamiquement la valeur de ce paramètre (ALTER SYSTEM), il sera possible de changer
de tablespace d’annulation actif sans redémarrer la base de données.
UNDO_RETENTION
Ce paramètre spécifie, en secondes, la durée de rétention des <informations d’annulation dans les segments
d’annulation. La valeur doit être comprise entre 0 et 2^32­1 (plus de 49 000 jours) ; la valeur par défaut est de 900
(soit 15 minutes). Ce paramètre est dynamique.
Comme indiqué précédemment, depuis la version 10, la durée de rétention des informations d’annulation est réglée
automatiquement par Oracle. Si le tablespace d’annulation est de taille fixe, ce paramètre est ignoré (sauf si le
tablespace d’annulation est défini avec la garantie de rétention) ; si le tablespace d’annulation est auto­extensible,
ce paramètre spécifie une limite inférieure pour la durée de rétention des informations d’annulation. La durée de
rétention actuellement utilisée peut être consultée dans la colonne TUNED_ UNDORETENTION de la vue V$UNDOSTAT.
Avec le réglage automatique de la durée de rétention, définir ce paramètre ne présente réellement un intérêt que si
vous souhaitez utiliser les fonctionnalités de flashback ou si le tablespace d’annulation est défini avec la garantie de
rétention.
Par exemple, si vous souhaitez pouvoir interroger les données telles qu’elles étaient 24 heures plus tôt à l’aide d’une
requête flashback, vous devez positionner le paramètre UNDO_RETENTION à au moins 86400 (secondes) et prévoir de
l’espace dans le tablespace d’annulation.
En cas de nécessité, le paramètre UNDO_RETENTION peut être modifié dynamiquement (pas besoin de redémarrer la
base de données).
3. Démarrage de la base de données en mode automatique
Si le paramètre UNDO_TABLESPACE est défini, le tablespace indiqué est utilisé. Si le tablespace n’existe pas (ou n’est
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
pas correct ou indisponible), le démarrage échoue avec l’erreur ORA-01092 :
ORA-01092: instance ORACLE interrompue. Déconnexion imposée
La cause de l’erreur est indiquée dans le fichier des alertes :
ORA-30012<: tablespace d’annulation ’xxx’ inexistant ou de type erroné
Conclusion : si le paramètre UNDO_TABLESPACE est spécifié au démarrage de l’instance, il est important que le
tablespace indiqué existe et soit correct.
Si le paramètre UNDO_TABLESPACE n’est pas défini ou est vide, l’instance utilise le premier tablespace d’annulation
disponible et indique son nom dans le paramètre UNDO_ TABLESPACE. Si elle n’en trouve aucun, l’instance démarre
quand même et ouvre la base de données, mais uniquement avec le segment d’annulation SYSTEM. Dans ce cas, lors
de la première transaction portant sur un segment stocké dans un tablespace autre que le tablespace SYSTEM, vous
obtiendrez l’erreur ORA-01552 :
ORA-01552: imposs util. segment d’annul. système pour le tablespace
non syst. ’DATA’
Conclusion : en gestion automatique, n’oubliez pas de créer un tablespace d’annulation.
- 2-
© ENI Editions - All rights reserved - Algeria Educ
Gestion du tablespace d’annulation
1. Caractéristiques du tablespace d’annulation
Le tablespace d’annulation est obligatoirement géré localement, avec une gestion automatique des extensions
(EXTENT MANAGEMENT LOCAL AUTOALLOCATE). Il peut être SMALLFILE ou BIGFILE, et utiliser n’importe quelle taille de bloc
(pas uniquement la taille de bloc standard). Par contre, il est forcément READ WRITE, LOGGING et PERMANENT.
Il est impossible et interdit de créer d’autres segments (table, index) dans un tablespace d’annulation. Plusieurs
tablespaces d’annulation (contenant leurs propres segments d’annulation) peuvent être créés dans la base de
données mais seulement un est actif (utilisé), à un instant donné par l’instance. Il est possible de changer de
tablespace d’annulation dynamiquement. Le tablespace d’annulation actif ne peut pas être désactivé (passé OFFLINE)
ou supprimé.
2. Fonctionnement du tablespace d’annulation
Dans un tablespace d’annulation, des segments d’annulation sont automatiquement créés et gérés par Oracle (et par
lui seul). Ils sont nommés sous la forme_SYSSMU*, et dimensionnés (nombre et taille) automatiquement en fonction
des besoins.
En fonction des besoins, les segments d’annulation stockés dans le tablespace d’annulation actuellement actif sont
automatiquement activés. Oracle crée automatiquement de nouveaux segments d’annulation dans le tablespace
d’annulation actif, s’il le juge nécessaire. Les segments d’annulation ainsi créés ne sont pas supprimés ; si Oracle
estime ne plus en avoir besoin (baisse de l’activité transactionnelle), il les passe OFFLINE. Si l’instance en a de
nouveau besoin ultérieurement, elle les repassera ONLINE.
Tenter de gérer directement les segments d’annulation (ajout, suppression, activation, désactivation,
dimensionnement, etc.) est sans effet. Oracle ne retourne pas d’erreur mais ne fait rien. De toute façon, pourquoi le
faire puisque tout est automatique.
En version 9, Oracle retournait une erreur si une opération interdite était tentée. Il était possible de faire
disparaître ces erreurs en mettant le paramètre UNDO_SUPPRESS_ ERRORSà TRUE. Depuis la version 10, ce
paramètre n’existe plus et tout se passe comme s’il était à TRUE.
3. Création d’un tablespace d’annulation
Vous pouvez créer le tablespace d’annulation lors de la création de la base de données grâce à la clause UNDO
TABLESPACE de l’ordre SQL CREATE DATABASE.
Syntaxe
[ BIGFILE | SMALLFILE ] UNDO TABLESPACE nom
[ DATAFILE spécification_fichier [,...] ]
Exemple :
SMALLFILE UNDO TABLESPACE undotbs
DATAFILE ’e:\oradata\hermes\undotbs01.dbf’ SIZE 100M
AUTOEXTEND ON NEXT 10M MAXSIZE 1024M
Si un nom a été indiqué dans le paramètre d’initialisation UNDO_TABLESPACE, utilisez le même nom dans la clause UNDO
TABLESPACE. Autrement, la base sera bien créée avec le tablespace spécifié dans la clause UNDO TABLESPACE, mais
Oracle retournera une erreur à l’ouverture de la base (voir la section Mise en œ uvre de la gestion automatique).
Si le paramètre d’initialisation UNDO_MANAGEMENT est positionné à AUTO et que la clause UNDO TABLESPACE n’est pas
présente, Oracle crée un tablespace d’annulation par défaut, nommé SYS_UNDOTBS, avec un fichier de données de
10 Mo, positionné en AUTOEXTEND.
Vous pouvez créer le tablespace d’annulation après la définition de la base de données grâce à l’ordre SQL CREATE
UNDO TABLESPACE.
Syntaxe
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
CREATE [ BIGFILE | SMALLFILE ] UNDO TABLESPACE nom
DATAFILE spécification_fichier_data [,...]
[ RETENTION GUARANTEE | NOGUARANTEE ]
[ BLOCKSIZE valeur [K] ] ;
Exemple (ici utilisation d’un tablespace BIGFILE) :
CREATE BIGFILE UNDO TABLESPACE bigundotbs
DATAFILE ’e:\oradata\hermes\bigundotbs.dbf’ SIZE 10G
AUTOEXTEND ON NEXT 1G MAXSIZE 1024G
RETENTION GUARANTEE ;
Les options des deux syntaxes ont la même signification que les options de même nom de l’ordre SQL CREATE
TABLESPACE (voir la section Tablespace permanent du chapitre Gestion des tablespaces et des fichiers de données).
Dans les deux cas, la clause EXTENT MANAGEMENT n’est pas utile. Elle peut être indiquée, mais la seule valeur autorisée
est EXTENT MANAGEMENT LOCAL AUTOALLOCATE : le tablespace d’annulation est forcément géré localement, avec une
gestion automatique des extensions.
La clause RETENTION indique si la rétention est garantie (GUARANTEE) ou non (NOGUARANTEE) ; NOGUARANTEE est l’option
par défaut. Utilisez l’option GUARANTEE en connaissance de cause : en cas de problème d’espace, Oracle fera échouer
les mises à jour pour garantir la durée de rétention des informations d’annulation.L’option GUARANTEE est
généralement utilisée en conjonction avec les fonctionnalités de flashback ; elle permet de garantir la capacité à
interroger les données telles qu’elles étaient à tout instant dans le passé, dans la limite du paramètre
UNDO_RETENTION.
Si la durée de rétention est élevée et qu’il y a une forte activité de mise à jour sur la base de données, les segments
d’annulation vont grossir. Il est donc très important de dimensionner en conséquence le tablespace d’annulation
et/ou de lui permettre de grossir en cas de besoin (clause AUTOEXTEND à ON sur un des fichiers de données du
tablespace).
4. Changement de tablespace d’annulation actif
Si la base dispose de plusieurs tablespaces d’annulation, il est possible de changer de tablespace actif en modifiant
la valeur du paramètre UNDO_TABLESPACE(paramètre dynamique).
Syntaxe
ALTER SYSTEM SET UNDO_TABLESPACE = nom [ clause_SCOPE ];
Si la modification est immédiate (SCOPE = MEMORY ou BOTH), nom doit être le nom d’un tablespace d’annulation valide
(doit être ONLINE notamment). Si la modification est différée (SCOPE = SPFILE), aucune vérification n’est faite sur le
nom indiqué, mais un tablespace d’annulation portant ce nom devra exister lors du prochain redémarrage (sous peine
d’erreur ORA-01092, voir la section Mise en œ uvre de la gestion automatique).
Si nom est une chaîne vide (’’), le tablespace d’annulation courant est désactivé mais aucun n’est activé à la place.
Cette situation, normalement temporaire, peut être utilisée pour effectuer des opérations d’administration sur le
tablespace d’annulation (voir plus loin).
Lors d’un changement de tablespace d’annulation actif, les segments d’annulation stockés dans l’ancien tablespace
d’annulation sont désactivés (passés OFFLINE). Si un des segments d’annulation est utilisé par des transactions
actives, il n’est pas immédiatement passé OFFLINE mais mis PENDING OFFLINE (vue V$ROLLSTAT) ; il n’est plus utilisable
pour de nouvelles transactions et il passera définitivement OFFLINE lorsqu’il ne contiendra plus de transaction active.
Les segments d’annulation stockés dans le nouveau tablespace d’annulation sont activés (passés ONLINE).
L’ancien tablespace reste ONLINE ; ce sont les segments d’annulation qu’il contient qui sont OFFLINE. Il n’est
simplement plus le tablespace actif pour l’annulation (défini par le paramètre UNDO_TABLESPACE). Il peut être désactivé
(passé OFFLINE) si nécessaire.
Un tablespace d’annulation actif ou un tablespace d’annulation qui a des segments d’annulation PENDING
OFFLINE ne peut être ni supprimé, ni désactivé (passé OFFLINE).
5. Modification d’un tablespace d’annulation
Le tablespace d’annulation peut être modifié avec les ordres SQL habituels ALTER TABLESPACE ou ALTER DATABASE
- 2-
© ENI Editions - All rights reserved - Algeria Educ
(pour la gestion des fichiers de données).
En complément, vous pouvez modifier la clause RETENTION :
ALTER TABLESPACE nom_tablespace RETENTION GUARANTEE | NOGUARANTEE ;
Un tablespace d’annulation actif ou un tablespace d’annulation qui a des segments d’annulation PENDING OFFLINE ne
peut pas être désactivé (passé OFFLINE).
Un tablespace d’annulation peut être passé OFFLINE même s’il contient des informations d’annulation qui
n’ont pas encore expirées (vis­à­vis de la valeur du paramètre UNDO_RETENTION), cela même si le tablespace
d’annulation a été défini avec la clause RETENTION GUARANTEE.
6. Suppression d’un tablespace d’annulation
La suppression d’un tablespace d’annulation s’effectue avec l’ordre SQL habituel DROP TABLESPACE.
La clause INCLUDING CONTENTS est implicite ; les segments d’annulation stockés dans le tablespace sont
automatiquement supprimés. Par contre, la clause doit être mentionnée avec l’option AND DATAFILES pour supprimer
les fichiers de données associés.
Un tablespace d’annulation actif ou un tablespace d’annulation qui a des segments d’annulation PENDING OFFLINE ne
peut pas être supprimé.
Un tablespace d’annulation peut être supprimé même s’il contient des informations d’annulation qui n’ont pas
encore expirées (vis­à­vis de la valeur du paramètre UNDO_RETENTION), cela même si le tablespace
d’annulation a été défini avec la clause RETENTION GUARANTEE.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Trouver des informations sur la gestion de l’annulation
1. Trouver des informations sur le tablespace d’annulation
Les vues présentées au chapitre Gestion des tablespaces et des fichiers de données peuvent être utilisées pour
retrouver des informations sur les tablespaces d’annulation et leurs fichiers de données :
●
DBA_TABLESPACESou V$TABLESPACE : informations sur les tablespaces ;
●
DBA_DATA_FILESou V$DATAFILE : informations sur les fichiers de données ;
●
DBA_FREE_SPACE : informations sur l’espace disponible à l’intérieur d’un tablespace ;
●
DBA_SEGMENTS : informations sur les segments alloués à l’intérieur d’un tablespace ;
●
DBA_EXTENTS : informations sur les extensions allouées à l’intérieur d’un tablespace.
En complément, la vue DBA_UNDO_EXTENTS donne plus spécifiquement des informations sur les extensions allouées
dans les tablespaces d’annulation :
DBA_UNDO_EXTENTS
SEGMENT_NAME
Nom du segment d’annulation auquel l’extension appartient.
TABLESPACE_NAME
Nom du tablespace d’annulation qui contient l’extension.
EXTENT_ID
Numéro de l’extension (0 pour la première).
FILE_ID
Identifiant du fichier de données qui contient l’extension.
BLOCK_ID
Numéro du premier bloc de l’extension.
BYTES
Taille de l’extension en octets.
BLOCKS
Taille de l’extension en blocs Oracle.
STATUS
Statut des informations d’annulation stockées dans l’extension, vis­à­vis des transactions : ACTIVE, EXPIRED,
UNEXPIRED.
Exemple :
SQL> SELECT tablespace_name,segment_name,extent_id,blocks,status
2 FROM dba_undo_extents
© ENI Editions - All rights reserved - Algeria Educ
- 1-
3 ORDER BY tablespace_name,segment_name,extent_id;
TABLESPACE SEGMENT_NAME
EXTENT_ID
BLOCKS STATUS
---------- ------------------------- ---------- ---------- --------UNDOTBS
_SYSSMU10_1216212870$
0
8 UNEXPIRED
UNDOTBS
_SYSSMU10_1216212870$
1
8 UNEXPIRED
UNDOTBS
_SYSSMU10_1216212870$
2
128 UNEXPIRED
UNDOTBS
_SYSSMU10_1216212870$
3
128 UNEXPIRED
...
UNDOTBS
_SYSSMU7_1216212870$
0
8 EXPIRED
UNDOTBS
_SYSSMU7_1216212870$
1
8 UNEXPIRED
UNDOTBS
_SYSSMU7_1216212870$
2
128 ACTIVE
UNDOTBS
_SYSSMU8_1216212870$
0
8 UNEXPIRED
...
2. Trouver des informations sur les segments d’annulation
Plusieurs vues du dictionnaire permettent d’obtenir des informations sur les segments d’annulation :
●
DBA_ROLLBACK_SEGS : informations sur les segments d’annulation ;
●
V$ROLLNAME : liste des segments d’annulation actuellement ONLINE ou PENDING OFFLINE ;
●
V$ROLLSTAT : statistiques sur les segments d’annulation actuellement ONLINE ou PENDING OFFLINE.
Les colonnes intéressantes des différentes vues sont présentées ci­après.
DBA_ROLLBACK_SEGS
SEGMENT_NAME
Nom du segment d’annulation.
TABLESPACE_NAME
Nom du tablespace qui contient le segment d’annulation.
SEGMENT_ID
Numéro du segment d’annulation.
STATUS
Statut du segment d’annulation.
V$ROLLNAME
USN
Numéro du segment d’annulation.
NAME
Nom du segment d’annulation.
V$ROLLSTAT
USN
Numéro du segment d’annulation.
EXTENTS
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Nombre d’extensions dans le segment d’annulation.
RSSIZE
Taille actuelle utile (sans le bloc d’en­tête) en octets du segment d’annulation.
WRITES
Nombre d’octets écrits dans le segment d’annulation.
HWMSIZE
Plus grande taille jamais atteinte en octets par le segment d’annulation (High Water Mark "ligne de plus hautes
eaux").
SHRINKS
Nombre de fois où le segment d’annulation a rétréci.
WRAPS
Nombre de fois où le segment d’annulation a "tourné" (i.e. nombre de fois où les transactions ont pu changer
d’extension sans allocation d’une nouvelle extension).
EXTENDS
Nombre de fois où le segment d’annulation s’est étendu (allocation d’une nouvelle extension).
AVEACTIVE
Taille moyenne active du segment d’annulation.
STATUS
Statut (ONLINE ou PENDING OFFLINE).
Cette vue était très pratique pour superviser le fonctionnement des segments d’annulation en gestion manuelle ; elle
présente moins d’intérêt en gestion automatique.
3. Se documenter sur les informations d’annulation et les transactions
La vue V$UNDOSTAT permet de trouver des informations sur les informations d’annulation. Les colonnes intéressantes
de la vue V$UNDOSTAT sont les suivantes :
V$UNDOSTAT
BEGIN_TIME
Date/heure de début de la plage.
END_TIME
Date/heure de fin de la plage.
UNDOBLKS
Nombre de blocs d’annulation utilisés en cumulé sur la période.
TXNCOUNT
Nombre de transactions totales sur la période.
© ENI Editions - All rights reserved - Algeria Educ
- 3-
MAXQUERYLEN
Durée en secondes de la requête la plus longue sur la période.
MAXCONCURRENCY
Nombre maximum de transactions simultanées sur la période.
TUNED_UNDORETENTION
Durée de rétention compte tenu du réglage automatique réalisé par l’instance.
La vue V$UNDOSTAT donne des statistiques sur les informations d’annulation générées sur les 4 derniers jours. La
collecte est effectuée par plages de 10 minutes ; la vue contient donc 576 lignes, une pour chaque plage de 10
minutes sur les 4 derniers jours. La première ligne de la vue correspond à la plage en cours (peut faire moins de 10
minutes). Il peut exister moins de lignes si l’instance a démarré depuis moins de 4 jours. Un historique au­delà de 4
jours est disponible dans la vue DBA_HIST_UNDOSTAT.
Cette vue est utile pour estimer la taille du tablespace d’annulation (voir la section Dimensionner le tablespace
d’annulation). En complément, la vue V$TRANSACTION peut être utilisée pour identifier les transactions courantes.
Exemple
SQL> SELECT se.username,tr.start_time,tr.xidusn,tr.used_ublk,
2
sq.sql_text
3 FROM v$transaction tr,v$session se,v$sql sq
4 WHERE tr.ses_addr = se.saddr AND se.sql_id = sq.sql_id;
USERNAME
START_TIME
XIDUSN USED_UBLK
------------------------- -------------------- ---------- ---------SQL_TEXT
-------------------------------------------------------------------OHEU
07/19/08 17:24:04
5
268
DELETE FROM t
4. Dimensionner le tablespace d’annulation
La vue V$UNDOSTAT peut être utilisée pour dimensionner le tablespace d’annulation, et éventuellement le paramètre
UNDO_RETENTIONsi vous avez des erreurs snapshot too old.
La quantité totale d’espace d’annulation nécessaire pour satisfaire la durée de rétention peut être estimée par la
formule DR x QAS, DR étant la durée de rétention et QAS la quantité d’espace d’annulation par seconde.
La valeur DR peut être estimée en analysant la valeur de la colonne TUNED_ UNDORETENTION de la vue V$UNDOSTAT, et
en s’assurant que cette valeur est supérieure à la valeur de la colonne MAXQUERYLEN ; si ce n’est pas le cas, il convient
peut­être de positionner le paramètre UNDO_RETENTION en conséquence.
La valeur QAS peut être estimée en analysant la valeur de la colonne UNDOBLKS de la vue V$UNDOSTAT ; cette colonne
donne le nombre de blocs d’annulation utilisés sur chaque période analysée (soit sur 10 minutes).
SQL> SELECT
2
TO_CHAR(begin_time,’DD/MM HH24:MI’)
begin_time,
3
TO_CHAR(end_time,’DD/MM HH24:MI’)
end_time,
4
undoblks,
5
maxquerylen,
6
tuned_undoretention
7 FROM
8
v$undostat;
BEGIN_TIME END_TIME
UNDOBLKS MAXQUERYLEN TUNED_UNDORETENTION
----------- ----------- ---------- ----------- ------------------19/07 16:23 19/07 16:28
15
936
1656
19/07 16:13 19/07 16:23
37
635
1475
19/07 16:03 19/07 16:13
71
1239
2079
19/07 15:53 19/07 16:03
144
638
1479
19/07 15:43 19/07 15:53
38
1242
2082
19/07 15:33 19/07 15:43
268
641
1481
19/07 15:23 19/07 15:33
33
1244
2084
- 4-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
19/07 15:13 19/07 15:23
40
643
19/07 15:03 19/07 15:13
31
1249
19/07 14:53 19/07 15:03
156
648
19/07 14:43 19/07 14:53
33
47
...
SQL> SELECT MAX(undoblks),MAX(tuned_undoretention)
2 FROM v$undostat;
MAX(UNDOBLKS) MAX(TUNED_UNDORETENTION)
------------- ------------------------
1484
2088
1488
900
Sur cet exemple, la durée de rétention la plus longue est de 2261 secondes.
Lors d’un pic d’activité (traitement batch ?), l’instance a utilisée 79560 blocs en 10 minutes, soit un peu moins de 133
blocs par secondes.
La taille de bloc étant de 8 Ko, la quantité totale d’espace d’annulation nécessaire peut être estimée à 2261 x 133 x
8 Ko soit 2,29 Go. Le tablespace d’annulation peut être dimensionné en conséquence, en prenant un peu de marge
(10 à 20%). Cette estimation est a priori une estimation haute qui considère que le pic d’activité de mise à jour se
produit au moment où la durée de rétention est la plus longue (ce qui n’est pas forcément le cas).
© ENI Editions - All rights reserved - Algeria Educ
- 5-
Utiliser le Database Control
Le tablespace d’annulation et ses fichiers de données s’administrent à partir des pages Espaces disque logiques et
Fichiers de données (voir la section Utiliser le Database Control du chapitre Gestion des tablespaces et des fichiers de
données).
Sur la page Serveur, le lien Segments d’annulation (cadre Stockage) permet d’accéder à la page de gestion des
segments d’annulation manuels. En gestion automatique des segments d’annulation, cette page n’est d’aucune utilité.
Toujours sur la page Serveur, le lien Gestion automatique de l’annulation (cadre Configuration de base de données)
permet d’accéder à la page de gestion automatique de l’annulation.
La première partie de la fenêtre vous donne des informations sur la configuration actuelle :
Le bouton Modifier un espace disque logique permet de changer de tablespace d’annulation actif.
L’onglet Activité du système affiche des informations sur l’activité passée du système.
La deuxième partie de la fenêtre vous fournit des conseils sur la configuration :
Le bouton Modifier l’espace disque logique d’annulation (undo tablespace) permet de modifier le tablespace
d’annulation actif (ajouter un fichier de données, modifier la taille d’un fichier de données, etc.).
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Le bouton Modifier la conservation pour annulation (undo) permet de modifier la valeur du paramètre
UNDO_RETENTION.
L’analyse est basée sur une période d’analyse (par défaut les sept derniers jours) et une durée de conservation des
informations d’annulation. Vous pouvez modifier ces valeurs dans le cadre Période d’analyse puis cliquer sur le bouton
Exécuter l’analyse pour mettre à jour les résultats.
En résultat, le conseiller propose une taille minimum et une taille recommandée pour le tablespace d’annulation.
Le lien Afficher le graphique permet d’afficher un graphique qui donne une estimation de la taille du tablespace
d’annulation (en Mo) en fonction de la durée de conservation des informations d’annulation (en minutes) :
Le graphique montre notamment l’espace disque requis pour la durée de rétention actuelle réglée automatiquement
(304 Mo pour 31 minutes sur l’exemple ci­dessus), mais aussi la durée de rétention maximale possible ("meilleur choix
possible") compte tenu de la taille maximale possible du tablespace d’annulation (3371 minutes pour 1022 Mo sur
l’exemple ci­dessus).
Si vous cliquez sur un point du graphique, le champ Durée (cadre Période d’analyse) et la taille minimale du
tablespace d’annulation (cadre Résultats d’analyse) sont mis à jour en conséquence.
Si vous avez modifié le champ Durée du cadre Période d’analyse (manuellement ou en cliquant sur le graphique), un
bouton Appliquer s’affiche dans la fenêtre. Si vous cliquez sur ce bouton, vous appliquez la nouvelle durée au
paramètre UNDO_RETENTION (ALTER SYSTEM SET UNDO_RETENTION = ...).
Pour les analyses, veillez à utiliser une période d’analyse représentative de l’activité de votre base de
données.
- 2-
© ENI Editions - All rights reserved - Algeria Educ
Problèmes courants et solutions
ORA-01552: imposs util. segment d’annul. système pour le tablespace
non syst.’XXXX’
Explication
Il n’y a pas de segment d’annulation actif (ONLINE) autre que le segment d’annulation SYSTEM (vérifiable dans
V$ROLLNAME) et une transaction concerne le tablespace XXXX.
Cause(s)
La gestion automatique des segments d’annulation n’est pas active. La gestion automatique des segments
d’annulation est active mais il n’y a pas de tablespace d’annulation actif.
Action(s)
Vérifiez si la base a démarré en gestion automatique des segments d’annulation (paramètre UNDO_MANAGEMENT). Dans le
cas contraire, redémarrez la base de données en activant la gestion automatique. Vérifiez s’il existe un tablespace
d’annulation (dans la vue DBA_TABLESPACES). Dans le cas contraire, créez­en un.
ORA-30036: impossible d’étendre le segment par N dans le tablespace
d’annulation’XXXX’
Explication
Un segment d’annulation n’arrive pas à s’étendre.
Cause(s)
Le segment d’annulation n’arrive pas à s’étendre car le tablespace dans lequel il est stocké n’a pas suffisamment
d’espace disponible et ne peut lui­même s’étendre.
Action(s)
Il faut augmenter l’espace disponible dans le tablespace :­ soit en lui allouant un nouveau fichier de données (ALTER
TABLESPACE ... ADD DATAFILE ...) ; soit en augmentant la taille d’un fichier de données du tablespace (ALTER
DATABASE DATAFILE ... RESIZE ...) ; soit en autorisant un fichier de données du tablespace à s’étendre
automatiquement (ALTER DATABASE DATAFILE ... AUTOEXTEND ON ...).
ORA-01555: clichés trop vieux : rollback segment no N, nommé "XXXX",
trop petit
Explication
C’est la "fameuse" erreur snapshot too old ("cliché trop vieux"). Une lecture cohérente n’a pas pu être menée à son
terme, car elle requiert une ancienne valeur qui n’est plus présente dans le segment d’annulation.
Cause(s)
Le tablespace d’annulation n’est pas en RETENTION GUARANTEE et a manqué d’espace ; il n’a pas pu honorer la durée de
rétention.
Action(s)
Si le tablespace d’annulation est trop petit par rapport à la durée de rétention, augmentez sa taille (voir l’erreur
précédente pour les actions possibles). Si le tablespace d’annulation est déjà très volumineux, vous pouvez envisager
de le mettre en RETENTION GUARANTEE, avec le risque de voir certaines mises à jour échouer (généralement avec une
erreur ORA-30036).
Typiquement, ce problème se produit lorsqu’il y a, simultanément sur une table, une forte activité de mise à jour et des
lectures longues.
Une autre approche pour résoudre ce problème consiste à essayer de séparer, dans le temps ou dans l’espace,
l’activité de mise à jour et l’activité de lecture :
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
●
●
- 2-
dans le temps : par exemple, lancer l’édition du volumineux rapport qui pose problème à un moment plus
propice dans la journée ;
dans l’espace : par exemple, mettre en place un petit mécanisme de réplication et lancer l’édition du
volumineux rapport qui pose problème sur les tables répliquées.
© ENI Editions - All rights reserved - Algeria Educ
Principes
Pour la gestion de la sécurité, Oracle permet :
●
de définir les utilisateurs qui peuvent se connecter à la base de données (avec une identification par le
système d’exploitation ou par la base de données) ;
●
de définir dans quel(s) tablespace(s) un utilisateur peut créer des objets (éventuellement aucun) ;
●
de limiter l’utilisation des ressources système ;
●
●
d’imposer une politique de gestion de mots de passe (expiration périodique, non­ réutilisation avant un certain
temps, etc.) ;
de définir les droits de chaque utilisateur à l’intérieur de la base de données.
Dans une base de données Oracle, les droits des utilisateurs sont gérés avec la notion de privilège.
Un privilège est le droit :
●
●
d’exécuter un ordre SQL en général (par exemple, créer une table) : c’est la notion de privilège système ;
d’accéder à un objet d’un autre utilisateur (par exemple, mettre à jour les données de la table CLIENT) : c’est la
notion de privilège objet.
Les privilèges peuvent être attribués directement aux utilisateurs ou par l’intermédiaire de rôles. Un rôleest un
regroupement nommé de privilèges (systèmes et objets) qui peut être attribué en tant que tel à un utilisateur ; cet
utilisateur reçoit alors automatiquement les privilèges contenus dans le rôle. Les rôles facilitent la gestion des droits.
Oracle propose par ailleurs une fonctionnalité d’audit qui permet de tracer l’activité des utilisateurs dans la base de
données. Pour en savoir plus, vous pouvez consulter la documentation Oracle® Database Security Guide.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Créer et modifier les utilisateurs
1. Mode d’identification de l’utilisateur
Un utilisateur peut être identifié par Oracle ou par le système d’exploitation. Les deux modes d’identification sont
utilisables simultanément dans la même base de données.
a. Identification par Oracle
L’utilisateur se connecte à la base en saisissant un nom et un mot de passe. Oracle vérifie le nom et le mot de
passe de l’utilisateur.
SQL> CONNECT oheu/rx239$
Connecté.
Les fonctionnalités de gestion des mots de passe proposées par Oracle sont utilisables.
b. Identification par le système d’exploitation
L’utilisateur se connecte à la base sans saisir de nom ni de mot de passe.
SQL> CONNECT /
Connecté.
Oracle ne vérifie pas le mot de passe mais contrôle simplement que le nom de l’utilisateur, au niveau du système
d’exploitation, correspond à un nom d’utilisateur dans la base de données. L’identification initiale a été réalisée par
le système d’exploitation.
Les fonctionnalités de gestion des mots de passe proposées par Oracle ne sont pas utilisables (ce n’est pas Oracle
qui gère le mot de passe).
Pour faire le lien entre le nom de l’utilisateur dans le système d’exploitation et le nom de l’utilisateur dans la base
de données, Oracle utilise un préfixe défini par le paramètre OS_AUTHENT_PREFIX(par défaut égal à OPS$).
Par exemple, l’utilisateur ayant pour nom vdep au niveau du système d’exploitation pourra se connecter à la base
par un CONNECT / uniquement s’il existe un compte Oracle ops$vdep.
Sur plate­forme Windows, le nom de domaine, ou à défaut, le nom de la machine, fait partie du nom de
l’utilisateur : SRVWINORA\VDEP par exemple. C’est ce nom complet qui doit être préfixé pour constituer le nom du
compte Oracle (le tout en majuscules) : OPS$SRVWINORA\VDEP par exemple.
Le préfixe peut être égal à une chaîne vide (OS_AUTHENT_PREFIX = "") ; dans ce cas, le nom de l’utilisateur au niveau
du système d’exploitation et le nom de l’utilisateur dans Oracle sont identiques.
Le paramètre REMOTE_OS_AUTHENTpeut, de plus, être positionné à TRUE pour indiquer si les utilisateurs distants sont
identifiables par cette méthode (FALSE pour interdire, valeur par défaut). Mettre le paramètre REMOTE_OS_AUTHENT à
TRUE peut être dangereux si le réseau n’est pas sécurisé. Ce paramètre est déprécié en version 11.
2. Création d’un utilisateur
L’ordre SQL CREATE USER permet de créer un nouvel utilisateur.
Syntaxe
CREATE USER nom IDENTIFIED { BY mot_de_passe | EXTERNALLY }
[ DEFAULT TABLESPACE nom_tablespace ]
[ TEMPORARY TABLESPACE nom_tablespace ]
[ QUOTA { valeur [K|M] | UNLIMITED } ON nom_tablespace [,...] ]
[ PROFILE nom_profil ]
[ PASSWORD EXPIRE ]
[ ACCOUNT { LOCK | UNLOCK } ] ;
Exemple :
© ENI Editions - All rights reserved - Algeria Educ
- 1-
●
Utilisateur identifié par l’OS avec uniquement les clauses obligatoires
CREATE USER "OPS$SRVWINORA\VDEP" IDENTIFIED EXTERNALLY;
●
Utilisateur identifié par Oracle avec des clauses supplémentaires
CREATE USER oheu IDENTIFIED BY tempo
DEFAULT TABLESPACE data
QUOTA UNLIMITED ON data
PASSWORD EXPIRE;
Notez la syntaxe particulière pour spécifier le nom de l’utilisateur OPS$SRVWINORA\ VDEP : les guillemets sont
nécessaires car le nom contient des caractères non autorisés (barre oblique inverse). Par la suite, il faudra toujours
utiliser la même syntaxe pour gérer cet utilisateur.
Pour qu’un nouvel utilisateur puisse effectivement se connecter, il faut en plus lui donner le droit de le faire, en lui
attribuant le privilège système CREATE SESSION (cf. Gérer les droits).
Il est donc possible d’avoir des comptes pour les utilisateurs sans que ces derniers aient le droit de se connecter.
Cette fonctionnalité était intéressante en version 7 puisqu’elle permettait soit de préparer des comptes utilisateur
sans les activer tout de suite, soit d’interdire temporairement à un utilisateur de se connecter sans supprimer son
compte. Cette fonctionnalité peut toujours être utilisée mais il est plus simple de verrouiller/déverrouiller
explicitement le compte (ACCOUNT LOCK | UNLOCK).
Les options de l’ordre SQL CREATE USER sont :
nom
Nom de l’utilisateur. Le nom de l’utilisateur doit respecter les règles de nommage d’Oracle présentées à la section La
base de données du chapitre Les bases de l’architecture Oracle. Si ce n’est pas le cas, il faut placer le nom entre
guillemets.
IDENTIFIED
Cette clause indique si l’utilisateur est identifié par le système d’exploitation (EXTERNALLY) ou par Oracle (BY
mot_de_passe).
Dans le cas d’une identification par Oracle, le mot de passe initial de l’utilisateur est spécifié.
Pour le mot de passe, les règles de nommage d’Oracle doivent être respectées, sauf si la fonctionnalité de contrôle
de la complexité des mots de passe est mise en œ uvre (nouveauté de la version 8 ­ voir plus loin).
Depuis la version 11, les mots de passe sont par défaut, sensibles à la casse (paramètre SEC_CASE_SENSITIVE_LOGON
égal à TRUE par défaut). Si vous souhaitez avoir des mots de passe non sensibles à la casse, il suffit d’affecter la
valeur FALSE au paramètre SEC_CASE_SENSITIVE_LOGON (mais ce n’est pas conseillé pour la sécurité).
DEFAULT TABLESPACE
Cette clause indique dans quel tablespace les segments de l’utilisateur sont créés par défaut (c’est­à­dire si aucune
clause TABLESPACE n’est présente lors de la création du segment).
Si la clause est omise, le tablespace permanent par défaut de la base de données est affecté à l’utilisateur (voir la
section Tablespace permanent du chapitre Gestion des tablespaces et des fichiers de données).
La notion de tablespace par défaut n’empêche pas l’utilisateur de créer des objets dans un autre tablespace (s’il a un
quota sur le tablespace en question) ; elle permet simplement de spécifier un tablespace par défaut si l’utilisateur
omet la clause TABLESPACE lors de la création d’un segment. Cette clause présente surtout un intérêt pour les
utilisateurs qui peuvent créer des segments : les développeurs, les testeurs, plus rarement les utilisateurs finaux.
TEMPORARY TABLESPACE
Cette clause indique dans quel tablespace les segments temporaires de l’utilisateur sont créés (lors d’un tri, par
exemple). Vous pouvez indiquer le nom d’un tablespace temporaire, ou le nom d’un groupe de tablespaces
temporaires.
Si la clause est omise, le tablespace temporaire par défaut de la base de données est affecté à l’utilisateur (voir la
section Tablespace temporaire du chapitre Gestion des tablespaces et des fichiers de données).
QUOTA
Cette clause indique dans quel(s) tablespace(s) l’utilisateur peut créer des objets, et jusqu’à quelle limite.
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
La notion de QUOTA permet de limiter l’espace qu’un utilisateur peut employer dans un tablespace avec les segments
qu’il crée.
Cette fonctionnalité ne concerne que les utilisateurs qui peuvent créer des segments, et non les utilisateurs finaux
d’un applicatif qui se contentent d’employer des objets déjà existants et qui appartiennent généralement à un
compte distinct (en quelque sorte le "propriétaire" de l’application).
Par défaut, les utilisateurs n’ont aucun quota sur aucun tablespace, sauf les DBA qui ont un quota illimité sur tous les
tablespaces.
Si un utilisateur a le droit de créer des segments, il faut lui donner explicitement un quota sur au moins un
tablespace. Le fait qu’une clause DEFAULT TABLESPACE ait été utilisée ne donne aucun quota sur le tablespace en
question ; ce sont deux mécanismes différents.
Dans la pratique, il ne faut donner des quotas qu’aux utilisateurs qui en ont besoin (les développeurs, le compte
"propriétaire" de l’application) et uniquement sur les tablespaces strictement nécessaires et suffisants. En
l’occurrence, il vaut mieux éviter de donner des quotas à ces utilisateurs sur le tablespace SYSTEM ou le tablespace
SYSAUX.
La notion de quota est sans objet pour le tablespace temporaire et le tablespace d’annulation.
Si un utilisateur cherche à créer un segment dans un tablespace sur lequel il n’a pas de quota ou qui aurait pour effet
de dépasser le quota alloué à cet utilisateur, une erreur est retournée :
●
Aucun quota sur le tablespace
ORA-01950: pas de privilèges sur le tablespace ’DATA’
●
Dépassement de quota sur le tablespace
ORA-01536: dépassement du quota d’espace affecté au tablespace ’DATA’
PROFILE
Cette clause indique le profil attribué à l’utilisateur. La notion de profil est présentée à la section Utiliser les profils.
PASSWORD EXPIRE
Cette clause permet de forcer une modification du mot de passe lors de la première connexion (le mot de passe de
l’utilisateur est expiré). Cette clause est sans objet si l’utilisateur est identifié par le système d’exploitation.
Si le compte est créé avec l’option PASSWORD EXPIRE, l’utilisateur, lors de sa première connexion, sera invité à changer
le mot de passe qui lui a été attribué initialement.
ACCOUNT
LOCK : le compte est verrouillé et la connexion interdite (erreur ORA-28000: compte verrouillé).
UNLOCK : le compte n’est pas verrouillé et la connexion autorisée (valeur par défaut).
Si le compte est créé avec l’option LOCK, le compte existe mais l’utilisateur ne peut pas se connecter. L’ordre SQL
ALTER USER pourra être utilisé plus tard pour déverrouiller le compte de l’utilisateur (cf. Créer et modifier les
utilisateurs).
3. Modification d’un utilisateur
L’ordre SQL ALTER USER permet de modifier un utilisateur.
Syntaxe
ALTER USER nom
[ IDENTIFIED { BY mot_de_passe | EXTERNALLY } ]
[ DEFAULT TABLESPACE nom_tablespace ]
[ TEMPORARY TABLESPACE nom_tablespace ]
[ QUOTA { valeur [K|M] | UNLIMITED } ON nom_tablespace [,...] ]
[ PROFILE nom_profil ]
[ PASSWORD EXPIRE ]
[ ACCOUNT { LOCK | UNLOCK } ] ;
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Les clauses sont les mêmes que pour la création.
Exemples :
●
Modification du mot de passe d’un utilisateur
ALTER USER oheu
IDENTIFIED BY tempo
PASSWORD EXPIRE;
●
Modification du tablespace par défaut et attribution de quotas
ALTER USER oheu
DEFAULT TABLESPACE test
QUOTA UNLIMITED ON test
QUOTA 10M ON data;
●
Verrouillage d’un compte
ALTER USER oheu ACCOUNT LOCK;
●
Déverrouillage d’un compte
ALTER USER oheu ACCOUNT UNLOCK;
Le premier exemple permet de modifier le mot de passe d’un utilisateur en le forçant à en changer lors de sa
première connexion ; cette technique peut être employée si l’utilisateur a perdu son mot de passe (le DBA n’a aucun
moyen de connaître le mot de passe des utilisateurs).
Le deuxième exemple permet de modifier le tablespace par défaut de l’utilisateur et de lui attribuer des quotas sur
deux tablespaces.
Le troisième exemple peut être utilisé pour interdire temporairement à un utilisateur de se connecter. S’il est
actuellement connecté, il n’est pas déconnecté.
Le quatrième exemple peut être utilisé pour autoriser de nouveau un utilisateur à se connecter.
Diminuer un quota, ou le mettre à 0, ne supprime pas les objets déjà créés par l’utilisateur.
Modifier le mot de passe de SYS modifie le mot de passe de SYSDBAenregistré dans le fichier de mot de passe
(si un fichier de mot de passe est utilisé).
4. Suppression d’un utilisateur
L’ordre SQL DROP USER permet de supprimer un utilisateur.
Syntaxe
DROP USER nom [ CASCADE ] ;
Exemple :
DROP USER "OPS$SRVWINORA\VDEP" CASCADE;
Si l’utilisateur possède des objets, l’option CASCADE doit être présente pour forcer la suppression préalable des
objets. Si l’utilisateur possède des objets et que l’option CASCADE soit absente, l’erreur ORA-01922 est retournée :
ORA-01922: CASCADE à indiquer pour supprimer ’OPS$SRVWINORA\VDEP’
C’est un ordre DDL
- 4-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
: il n’a pas de ROLLBACK possible.
Un utilisateur actuellement connecté ne peut pas être supprimé :
ORA-01940: impossible de supprimer un utilisateur qui est connecté
Avant suppression d’un utilisateur, il est possible d’exporter les objets qui lui appartiennent ; ces objets pourront
ultérieurement être réimportés dans un autre schéma.
5. Trouver des informations sur les utilisateurs
Plusieurs vues du dictionnaire de données permettent d’obtenir des informations sur les utilisateurs :
●
DBA_USERS : informations sur les utilisateurs ;
●
DBA_TS_QUOTAS : informations sur les quotas des utilisateurs.
Les colonnes intéressantes des différentes vues sont présentées ci­après.
DBA_USERS
USERNAME
Nom de l’utilisateur.
USER_ID
Identifiant de l’utilisateur.
PASSWORD
Mot de passe (crypté) de l’utilisateur.
ACCOUNT_STATUS
Statut du compte (OPEN, LOCKED, UNLOCKED, EXPIRED, etc.).
LOCK_DATE
Date du verrouillage (si le compte est verrouillé).
EXPIRY_DATE
Date d’expiration du mot de passe.
DEFAULT_TABLESPACE
Tablespace par défaut de l’utilisateur.
TEMPORARY_TABLESPACE
Tablespace temporaire de l’utilisateur.
CREATED
Date de création de l’utilisateur.
PROFILE
Profil.
© ENI Editions - All rights reserved - Algeria Educ
- 5-
DBA_TS_QUOTAS
TABLESPACE_NAME
Nom du tablespace.
USERNAME
Nom de l’utilisateur qui a un quota dans le tablespace.
BYTES
Espace, en octets, actuellement utilisé par l’utilisateur.
MAX_BYTES
Quota, en octets, de l’utilisateur sur le tablespace (1).
BLOCKS
Espace, en blocs, actuellement utilisé par l’utilisateur.
MAX_BLOCKS
Quota, en blocs, de l’utilisateur sur le tablespace (1).
(1) ­1 si quota UNLIMITED
- 6-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Présentation générale
1. Notions d’instance et de base de données
Un serveur Oracle comporte deux éléments distincts, l’instance et la base de données.
La base de données se compose d’un ensemble de fichiers physiques qui contiennent notamment les données.
L’instance se compose d’une structure de mémoire partagée et d’un ensemble de processus. Ces deux éléments sont
intimement liés mais doivent être bien distingués.
De manière imagée, il est possible de considérer que l’instance représente une application (par exemple Microsoft
Word) et la base de données, le document (par exemple un document Microsoft Word) ; pour pouvoir accéder à la
base de données (l’équivalent du document Microsoft Word), il faut l’ouvrir avec une instance Oracle (l’équivalent de
l’application Microsoft Word).
Une instance ne peut ouvrir qu’une base de données à la fois et, dans la grande majorité des cas, une base de
données est ouverte par une seule instance. Néanmoins, moyennant la mise en œ uvre de l’option Real Application
Clusters (RAC), une base de données peut être ouverte par plusieurs instances situées sur des nœ uds distincts d’un
cluster de serveurs ; cette option RAC est intéressante pour la haute disponibilité.
Un fichier de paramètres est utilisé par l’instance lors de son démarrage pour se configurer et faire le lien avec la base
de données.
En dehors des processus de l’instance, il existe des processus utilisateurs correspondant à l’application utilisée par
l’utilisateur pour se connecter à la base de données (SQL*Plus, un progiciel, un logiciel spécifique, etc.). Dans une
architecture client/serveur, ces processus utilisateurs sont situés sur le poste de l’utilisateur et communiquent avec le
serveur à travers le réseau grâce à la couche Oracle Net (voir le chapitre Oracle Net pour une présentation d’Oracle
Net).
2. La base de données
Une base de données est constituée :
© ENI Editions - All rights reserved - Algeria Educ
- 1-
●
D’un ou de plusieurs fichiers de données qui contiennent les données proprement dites.
●
D’au minimum un fichier de contrôle qui contient des informations de contrôle sur la base de données.
●
D’au minimum deux groupes de fichiers de journalisation qui enregistrent toutes les modifications apportées à
la base.
Nous verrons ultérieurement que les fichiers de journalisation peuvent être archivés ; ces fichiers de journalisation
archivés ne font, à proprement parler, pas partie de la base de données.
Chaque base de données porte un nom défini lors de sa création ; ce nom est défini par le paramètre d’initialisation
DB_NAME <du fichier de paramètres (hermes par exemple). En complément, l’emplacement de la base de données sur le
réseau peut être défini grâce au paramètreDB_DOMAIN (olivier-heurtel.fr par exemple). La base de données peut
alors être aussi identifiée par son nom global défini par DB_NAME.DB_DOMAIN (hermes. olivier-heurtel.fr par
exemple). Le rôle des différents fichiers de la base de données est décrit plus en détail dans le titre La base de
données.
3. L’instance
Une instance est constituée :
●
D’une zone de mémoire partagée appelée System Global Area (SGA) ;
●
D’un ensemble de processus d’arrière­plan (background process) ayant chacun un rôle bien précis ;
●
D’un ensemble de processus serveur (server process) chargés de traiter les requêtes des utilisateurs.
Toutes les composantes de la SGA ne sont pas représentées sur le schéma ci­dessus (cf. section L’instance ­
La SGA dans ce chapitre). De même, la liste des processus d’arrière­plan présentée sur le schéma n’est pas
complète (cf. section L’instance ­ Les processus d’arrière­plan dans ce chapitre).
Par ailleurs, chaque processus a de la mémoire privée appelée PGA (Program Global Area). Plusieurs instances peuvent
être lancées simultanément sur le même serveur ; dans ce cas, chaque instance a sa propre SGA et ses propres
processus.
Lors de l’administration, le DBA désigne l’instance sur laquelle il souhaite travailler grâce à la variable
d’environnementORACLE_SID ; c’est particulièrement important si plusieurs instances sont lancées sur le serveur. Le
nom (identifiant) de l’instanceest souvent désigné par le terme SID.
Selon la plate­forme, les processus sont effectivement des processus (process) du système d’exploitation
(c’est le cas des plates­formes Unix en général) ou des threads d’un unique processus (c’est le cas de la
plate­forme Windows).
Les différentes composantes de l’instance sont décrites plus en détail dans la section L’instance.
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
4. Les différentes catégories de base de données
Très souvent, dans la documentation, Oracle fait la distinction entre les bases de données "transactionnelles" (ou
OLTP pour OnLine Transaction Processing) et les bases de données "décisionnelles" (ou DSS pour Decision Support
Systems).
Une base de données transactionnelle se caractérise par :
●
une forte activité de mise à jour (INSERT/UPDATE), généralement sous la forme de petites transactions ;
●
un nombre plus ou moins important d’utilisateurs concurrents ;
●
une exigence de temps de réponse court.
Une base de données décisionnelle se caractérise par :
●
une forte activité d’interrogation (SELECT) généralement sur des gros volumes de données (cette activité peut
être interactive et/ou batch) ;
●
une mise à jour périodique sous forme de batch avec des gros traitements de mise à jour ;
●
une exigence de temps de réponse raisonnablement court.
Et puis, il y a les bases de données "mixtes" qui sont à la fois transactionnelles et décisionnelles, le poids respectif de
chaque activité étant variable.
Beaucoup de réglages dépendent de la catégorie de la base de données, les bases de données mixtes étant les plus
difficiles à régler ; dans ce cas, il faut parfois faire des compromis et déterminer des priorités.
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Utiliser les profils
1. Présentation
Un profil est un ensemble nommé de limitations de ressources qui peut être attribué à un utilisateur.
Les ressources suivantes peuvent être limitées :
●
temps CPU par appel et/ou par session ;
●
nombre de lectures logiques par appel et/ou par session ;
●
nombre de sessions ouvertes simultanément par un utilisateur ;
●
temps d’inactivité par session ;
●
durée totale de la session ;
●
quantité de mémoire privée dans la SGA (configuration serveurs partagés uniquement).
Une lecture logique correspond à une lecture de bloc lors d’une requête, que ce bloc soit déjà présent en mémoire
(dans le Database Buffer Cache) ou lu sur disque (dans ce cas, la lecture logique correspond aussi à une lecture
physique).
Depuis la version 8, les profils peuvent aussi être utilisés pour mettre en œ uvre une politique de gestion des mots de
passe.
Les fonctionnalités suivantes peuvent être mises en oeuvre :
●
verrouillage de compte (et durée de verrouillage) au­delà d’un certain nombre d’échecs de tentative de
connexion ;
●
durée de vie des mots de passe (avec éventuellement une période de grâce) ;
●
non­réutilisation d’un mot de passe avant un certain temps ou avant un certain nombre de changements ;
●
complexité du mot de passe.
Le profil nommé DEFAULTest automatiquement créé lors de la création de la base de données. Ce profil est attribué
par défaut aux utilisateurs. Par défaut, ce profil DEFAULT n’impose aucune limite pour les ressources ; par contre,
depuis la version 11, ce profil comporte des limites pour les mots de passe (voir ci­après).
La limitation des ressources à l’aide des profils n’offre pas de nombreuses possibilités. Si vous souhaitez contrôler
plus précisément l’attribution de ressources (CPU, espace d’annulation, durée d’inactivité) à des utilisateurs ou
groupes d’utilisateurs, vous pouvez utiliser le Database Resource Manager. La mise en oeuvre de cette fonctionnalité
s’effectue grâce au packageDBMS_RESOURCE_MANAGER. Pour en savoir plus, consultez la documentation Oracle®
Database Administrator’s Guide.
2. Création d’un profil
L’ordre SQL CREATE PROFILE permet de créer un nouveau profil.
Syntaxe
CREATE PROFILE nom LIMIT
[ SESSIONS_PER_USER { valeur | UNLIMITED | DEFAULT } ]
[ CPU_PER_SESSION { valeur | UNLIMITED | DEFAULT } ]
[ CPU_PER_CALL { valeur | UNLIMITED | DEFAULT } ]
[ CONNECT_TIME { valeur | UNLIMITED | DEFAULT } ]
[ IDLE_TIME { valeur | UNLIMITED | DEFAULT } ]
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
[
[
[
[
[
[
[
[
[
[
[
LOGICAL_READS_PER_SESSION { valeur | UNLIMITED | DEFAULT } ]
LOGICAL_READS_PER_CALL { valeur | UNLIMITED | DEFAULT } ]
COMPOSITE_LIMIT { valeur | UNLIMITED | DEFAULT } ]
PRIVATE_SGA { valeur [K|M] | UNLIMITED | DEFAULT } ]
FAILED_LOGIN_ATTEMPTS { valeur | UNLIMITED | DEFAULT } ]
PASSWORD_LIFE_TIME { valeur | UNLIMITED | DEFAULT } ]
PASSWORD_REUSE_TIME { valeur | UNLIMITED | DEFAULT } ]
PASSWORD_REUSE_MAX { valeur | UNLIMITED | DEFAULT } ]
PASSWORD_LOCK_TIME { valeur | UNLIMITED | DEFAULT } ]
PASSWORD_GRACE_TIME { valeur | UNLIMITED | DEFAULT } ]
PASSWORD_VERIFY_FUNCTION { nom_fonction | NULL | DEFAULT } ] ;
Exemple :
CREATE PROFILE exploitation LIMIT
SESSIONS_PER_USER 3
IDLE_TIME 30
FAILED_LOGIN_ATTEMPTS 3
PASSWORD_LIFE_TIME 30
PASSWORD_REUSE_TIME 180
PASSWORD_LOCK_TIME UNLIMITED
PASSWORD_GRACE_TIME 3
PASSWORD_VERIFY_FUNCTION verif_mdp_exploitation ;
Les limitations de ressources sont les suivantes :
SESSIONS_PER_USER
Nombre de sessions simultanées.
CPU_PER_SESSION
CPU totale par session (1/100 s).
CPU_PER_CALL
CPU totale par appel (1/100 s).
CONNECT_TIME
Durée totale de connexion (minutes).
IDLE_TIME
Durée d’inactivité (minutes).
LOGICAL_READS_PER_SESSION
Nombre de lectures logiques par session.
LOGICAL_READS_PER_CALL
Nombre de lectures logiques par appel.
PRIVATE_SGA
Quantité de mémoire privée dans la SGA.
COMPOSITE_LIMIT
Somme pondérée de CPU_PER_SESSION, CONNECT_TIME, LOGICAL_READS_PER_SESSION et PRIVATE_SGA.
Pour la limite COMPOSITE_LIMIT, la vue RESOURCE_COST permet de consulter les pondérations utilisées et l’ordre SQL
ALTER RESOURCE COST de modifier les pondérations.
Les limitations relatives aux mots de passe sont les suivantes :
- 2-
© ENI Editions - All rights reserved - Algeria Educ
FAILED_LOGIN_ATTEMPTS
Nombre d’échecs de tentative de connexion autorisés avant verrouillage du compte, 10 dans le profil DEFAULT.
PASSWORD_LOCK_TIME
Durée du verrouillage (jours), 1 dans le profil DEFAULT.
PASSWORD_LIFE_TIME
Durée de vie du mot de passe (jours), 180 dans le profil DEFAULT.
PASSWORD_GRACE_TIME
Période de grâce après expiration du mot de passe (jours), 7 dans le profil DEFAULT.
PASSWORD_REUSE_TIME
Nombre de jours pendant lequel un mot de passe ne peut pas être réutilisé.
PASSWORD_REUSE_MAX
Nombre de changements de mot de passe avant qu’un mot de passe puisse être réutilisé.
PASSWORD_VERIFY_FUNCTION
Fonction de vérification de la complexité du mot de passe.
Les limites PASSWORD_REUSE_TIME et PASSWORD_REUSE_MAX ne peuvent pas être spécifiées simultanément : le contrôle de
la réutilisation d’un mot de passe est indiqué soit par une durée, soit par un nombre de changements. Si l’une des
deux limites a une valeur (différente de UNLIMITED), l’autre limite doit être UNLIMITED.
Pour les différentes limites spécifiées en jours, il est possible d’utiliser des nombres décimaux représentant des
fractions de jour (par exemple 1/24 = une heure).
La limite PASSWORD_VERIFY_FUNCTION permet de spécifier une fonction PL/SQL qui sera utilisée pour vérifier, si le mot de
passe saisi par l’utilisateur respecte bien certaines règles. Une valeur NULL permet de ne pas utiliser de fonction de
vérification. Cette fonction doit accepter trois paramètres en entrée (le nom de l’utilisateur, son nouveau mot de
passe et son ancien mot de passe) et retourner un booléen.
Le scriptutlpwdmg.sql (répertoire %ORACLE_HOME%\rdbms\admin ou $ORACLE_ HOME/rdbms/admin) contient un exemple de
fonction de vérification qui est affectée au profil DEFAULT si le script est exécuté.
Des mots clés peuvent être utilisés pour spécifier la valeur d’une limite :
●
UNLIMITED : aucune limitation.
●
DEFAULT : le paramètre hérite de la valeur du profil nommé DEFAULT.
Une limite non spécifiée dans un profil prend la valeur DEFAULT.
3. Modification d’un profil
L’ordre SQL ALTER PROFILE permet de modifier un profil.
Syntaxe
ALTER PROFILE nom LIMIT
[ SESSIONS_PER_USER { valeur | UNLIMITED | DEFAULT } ]
[ CPU_PER_SESSION { valeur | UNLIMITED | DEFAULT } ]
[ CPU_PER_CALL { valeur | UNLIMITED | DEFAULT } ]
[ CONNECT_TIME { valeur | UNLIMITED | DEFAULT } ]
[ IDLE_TIME { valeur | UNLIMITED | DEFAULT } ]
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
[
[
[
[
[
[
[
[
[
[
[
LOGICAL_READS_PER_SESSION { valeur | UNLIMITED | DEFAULT } ]
LOGICAL_READS_PER_CALL { valeur | UNLIMITED | DEFAULT } ]
COMPOSITE_LIMIT { valeur | UNLIMITED | DEFAULT } ]
PRIVATE_SGA { valeur [K|M] | UNLIMITED | DEFAULT } ]
FAILED_LOGIN_ATTEMPTS { valeur | UNLIMITED | DEFAULT } ]
PASSWORD_LIFE_TIME { valeur | UNLIMITED | DEFAULT } ]
PASSWORD_REUSE_TIME { valeur | UNLIMITED | DEFAULT } ]
PASSWORD_REUSE_MAX { valeur | UNLIMITED | DEFAULT } ]
PASSWORD_LOCK_TIME { valeur | UNLIMITED | DEFAULT } ]
PASSWORD_GRACE_TIME { valeur | UNLIMITED | DEFAULT } ]
PASSWORD_VERIFY_FUNCTION { nom_fonction | NULL | DEFAULT } ] ;
Exemple :
●
Modification du profil DEFAULT
ALTER PROFILE default LIMIT
SESSIONS_PER_USER 3
IDLE_TIME 30
FAILED_LOGIN_ATTEMPTS 5;
-- les autres paramètres gardent la valeur par défaut (UNLIMITED)
●
Modification d’un autre profil
ALTER PROFILE exploitation LIMIT
SESSIONS_PER_USER 5 -- passe de 3 à 5
IDLE_TIME UNLIMITED -- suppression de la limite
FAILED_LOGIN_ATTEMPTS DEFAULT; -- prend la valeur par défaut (5)
-- le reste est inchangé
Les options sont les mêmes que pour l’ordre SQL CREATE PROFILE.
La modification d’un profil n’affecte les utilisateurs qu’à leur prochaine connexion ; elle n’est pas prise en compte
immédiatement pour les utilisateurs déjà connectés.
Modifier le profil DEFAULT affecte aussi les profils qui ont des limites spécifiées à DEFAULT.
4. Affectation d’un profil à un utilisateur
Un profil peut être attribué à un utilisateur :
●
lors de la création de l’utilisateur (CREATE USER) ;
●
lors d’une modification de l’utilisateur (ALTER USER).
Exemples :
Lors de la création de l’utilisateur
CREATE USER xgeo IDENTIFIED BY tempo
TEMPORARY TABLESPACE temp
PROFILE exploitation
PASSWORD EXPIRE;
Lors d’une modification de l’utilisateur
●
Affectation d’un profil
ALTER USER oheu PROFILE exploitation;
●
- 4-
Réaffectation du profil DEFAULT
© ENI Editions - All rights reserved - Algeria Educ
ALTER USER oheu PROFILE DEFAULT;
L’affectation d’un nouveau profil à des utilisateurs ne prend effet qu’à leur prochaine connexion.
Par défaut, un utilisateur est créé avec le profil DEFAULT.
5. Activation de la limitation des ressources
Par défaut, le contrôle de la limitation des ressources n’est pas activé. Créer des profils et les affecter aux utilisateurs
n’a aucun effet.
Pour activer le contrôle de la limitation des ressources, il faut passer le paramètre RESOURCE_LIMIT à TRUE (FALSE par
défaut) :
ALTER SYSTEM SET RESOURCE_LIMIT = TRUE [ clause_SCOPE ];
N’oubliez pas d’utiliser la clause SCOPE = BOTH pour rendre la modification persistante en cas de redémarrage de la
base de données.
Les fonctionnalités de gestion des mots de passe fonctionnent même si le paramètre RESOURCE_LIMIT est à FALSE.
6. Suppression d’un profil
L’ordre SQL DROP PROFILE permet de supprimer un profil.
Syntaxe
DROP PROFILE nom [ CASCADE ] ;
Exemple :
DROP PROFILE exploitation CASCADE;
Si le profil est attribué à des utilisateurs, l’option CASCADE doit être présente. Si le profil est attribué à des utilisateurs
et que l’option CASCADE soit absente, l’erreur ORA-02382 est retournée :
ORA-02382<: Le profil EXPLOITATION a des utilisateurs, impossible
d’effectuer la suppression sans CASCADE
Le profil DEFAULT est affecté en remplacement aux utilisateurs concernés.La suppression d’un profil n’affecte les
utilisateurs qu’à leur prochaine connexion.Le profil DEFAULT ne peut pas être supprimé.
7. Trouver des informations sur les profils
Plusieurs vues du dictionnaire de données permettent d’obtenir des informations sur les profils :
●
DBA_USERS : informations sur les utilisateurs, dont le profil attribué (colonne PROFILE) ;
●
DBA_PROFILES : informations sur les profils.
Les colonnes intéressantes de la vue DBA_PROFILES sont présentées ci­après.
DBA_PROFILES
PROFILE
Nom du profil.
RESOURCE_NAME
Nom de la ressource contrôlée.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 5-
RESOURCE_TYPE
Type de la ressource contrôlée (KERNEL ou PASSWORD).
LIMIT
Limite de la ressource.
- 6-
© ENI Editions - All rights reserved - Algeria Educ
Gérer les droits
1. Privilège système
a. Définition
Un privilège système est le droit d’exécuter un ordre SQL en général, par exemple créer une table.
Chaque ordre SQL a généralement, au moins, un privilège système associé qui porte le même nom que l’ordre SQL.
Par exemple, l’ordre SQL CREATE TABLE possède un privilège système associé CREATE TABLE (donne le droit de créer
une table dans son propre schéma).
Certains privilèges système reprennent le nom de l’ordre SQL avec le mot clé ANY. Dans ce cas, le privilège système
permet d’exécuter l’ordre dans n’importe quel schéma de la base de données. Par exemple, le privilège système
CREATE ANY TABLE donne le droit de créer une table dans n’importe quel schéma de la base de données.
Lorsque l’ordre SQL concerné n’est pas relatif aux objets d’un schéma, il n’y a pas de privilège ANY (ANY veut dire
dans n’importe quel schéma) : par exemple, le privilège pour créer un tablespace est CREATE TABLESPACE ; il n’y a
pas de CREATE ANY TABLESPACE (un tablespace n’appartient pas à un schéma).
Les privilèges système sont source de pouvoir et de danger, surtout ceux qui concernent la gestion des utilisateurs
et des droits (CREATE USER, ALTER USER, DROP USER, GRANT ANY PRIVILEGE, GRANT ANY ROLE) et ceux qui permettent de
supprimer des objets (DROP ANY TABLE, DROP TABLESPACE, etc.) ; les privilèges système doivent donc être attribués
avec parcimonie (notamment les privilèges ANY).
Pensez que si vous donnez le privilège ALTER USER à un utilisateur, il pourra modifier les comptes utilisateur
(changer les mots de passe par exemple), dont le vôtre.
Quelques privilèges système particuliers :
CREATE SESSION
Donne le droit à l’utilisateur de se connecter.
SELECT ANY DICTIONARY
Donne le droit à l’utilisateur d’interroger n’importe quel objet du dictionnaire de données dans le schéma SYS. Ce
privilège est nécessaire pour les utilisateurs non DBA qui souhaitent employer le Database Control.
Si un utilisateur n’a pas le privilège CREATE SESSION, l’erreur ORA-01045 est retournée lors d’une tentative de
connexion :
ORA-01045: l’utilisateur OHEU n’a pas le privilège CREATE SESSION ;
connexion refusée
Le privilège SELECT ANY DICTIONARYest intéressant car il permet de donner à un utilisateur le droit de lire les vues
DBA sans pour autant être DBA. En version 8 ou 8i, le rôle SELECT_CATALOG_ROLE peut être utilisé pour atteindre le
même objectif ; ce rôle existe toujours en version 10 pour des raisons de compatibilité ascendante. En version 7, il
fallait donner aux utilisateurs le privilège SELECT ANY TABLE, ce qui était susceptible de poser des problèmes de
sécurité puisque l’utilisateur pouvait aller lire dans n’importe quel schéma.
Les privilèges système sont principalement utilisés pour contrôler l’emploi des ordres DDL et donc, plutôt destinés
aux administrateurs, aux développeurs, au compte propriétaire d’une application et très rarement à l’utilisateur final
d’une application.
Si un utilisateur n’a pas le privilège nécessaire pour réaliser une action, l’erreur ORA-01031 est retournée :
ORA-01031: privilèges insuffisants
La vue SYSTEM_PRIVILEGE_MAP donne la liste de tous les privilèges système.
b. Attribution d’un privilège système à un utilisateur
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
L’ordre SQL GRANT permet d’attribuer un privilège système.
Syntaxe
GRANT nom_privilège [,...]
TO { nom_utilisateur | PUBLIC } [,...]
[ WITH ADMIN OPTION ] ;
Exemple :
GRANT CREATE SESSION, CREATE TABLE TO oheu;
Le privilège peut être attribué à un utilisateur ou à tous les utilisateurs (PUBLIC).
La clause WITH ADMIN OPTION donne au bénéficiaire le droit de transmettre le privilège système.
Le privilège attribué est immédiatement actif.
Pour attribuer un privilège système, il faut avoir reçu :
●
le privilège en question avec la clause WITH ADMIN OPTION ;
●
ou le privilège système GRANT ANY PRIVILEGE.
Plusieurs privilèges peuvent être attribués à plusieurs utilisateurs en un seul ordre. Tous les privilèges système
peuvent être attribués d’un seul coup avec le mot clé ALL PRIVILEGES (GRANT ALL PRIVILEGES TO ...). Cette
possibilité est à manipuler avec beaucoup de précautions.
c. Révocation d’un privilège système à un utilisateur
L’ordre SQL REVOKE permet de révoquer un privilège système.
Syntaxe
REVOKE nom_privilège [,...]
FROM { nom_utilisateur | PUBLIC } [,...] ;
Exemple :
REVOKE CREATE TABLE FROM oheu;
Le privilège est immédiatement révoqué et ne peut plus être exercé.
Pour révoquer un privilège système, il faut avoir reçu :
●
le privilège en question avec la clause WITH ADMIN OPTION ;
●
ou le privilège système GRANT ANY PRIVILEGE.
Il n’y a pas de cascade dans la révocation d’un privilège système qui a été transmis grâce à la clause WITH ADMIN
OPTION. Si un privilège a été attribué à Pierre avec l’option WITH ADMIN OPTION et que Pierre l’ait transmis à Paul,
révoquer le privilège de Pierre est sans effet sur le privilège transmis par Pierre à Paul. La clause WITH ADMIN OPTION
est donc doublement dangereuse.
L’ordre REVOKE permet de révoquer uniquement les privilèges qu’un utilisateur a reçu en direct (non les privilèges
qu’il a implicitement via PUBLIC). Il en est de même pour PUBLIC : vous ne pouvez pas révoquer à PUBLIC un privilège
non attribué à PUBLIC en pensant l’enlever ainsi à tout le monde.
Si un privilège a été attribué à un utilisateur et à PUBLIC, la révocation de l’utilisateur est sans effet sur la possibilité
pour l’utilisateur de continuer à exercer le privilège : il le possède toujours via PUBLIC.
Tous les privilèges système peuvent être révoqués d’un seul coup avec le mot clé ALL PRIVILEGES (REVOKE ALL
PRIVILEGES FROM ...).
Si vous avez attribué un privilège avec l’option WITH ADMIN OPTION et que vous souhaitiez enlever cette possibilité
de transmission, il faut révoquer le privilège et l’attribuer de nouveau sans l’option.
- 2-
© ENI Editions - All rights reserved - Algeria Educ
d. Les privilèges système SYSDBA et SYSOPER
Nous avons déjà vu que les privilègesSYSDBA et SYSOPER étaient nécessaires pour réaliser certaines opérations
d’administration (démarrage/arrêt/création de base).
Ces privilèges peuvent être contrôlés, soit par une appartenance à un groupe particulier du système d’exploitation,
soit par un fichier de mot de passe.
Dans le cas de l’utilisation d’un fichier de mot de passe, par défaut, seul SYS a reçu les privilèges SYSDBA et SYSOPER.
Si le fichier de mot de passe< est exclusivement associé à la base (paramètre
REMOTE_
LOGIN_PASSWORDFILE=EXCLUSIVE), il est possible d’attribuer l’un ou l’autre de ces privilèges à d’autres utilisateurs.
L’attribution et la révocation s’effectuent avec les ordres SQL GRANT et REVOKE.
Dans la pratique, il est très rare d’attribuer les privilèges SYSOPER et surtout SYSDBA (qui donne un contrôle total sur
la base) à d’autres utilisateurs ; le compte SYSDBA/SYSOPER habituellement utilisé est le compte SYS (il est destiné à
cela).
Pour attribuer le privilège SYSDBA, il faut être connecté AS SYSDBA ; pour attribuer le privilège SYSOPER, il faut être
connecté AS SYSDBA ou AS SYSOPER.
La vue V$PWFILE_USERS <permet de lister les utilisateurs qui ont reçu les privilèges SYSDBA ou SYSOPER ; cette vue est
toujours vide siREMOTE_LOGIN_PASSWORDFILE= NONE.
2. Privilège objet
a. Définition
Un privilège objet est le droit d’accéder à un objet d’un autre utilisateur : par exemple, mettre à jour les données de
la table CLIENT.
Par défaut, seul le propriétaire d’un objet a le droit d’y accéder. Pour qu’un autre utilisateur puisse accéder à l’objet,
le propriétaire de l’objet doit lui donner un privilège objet.
Les principaux privilèges objet sont les suivants :
Privilège
Table
Vue
Séquence
SELECT
x
x
x
INSERT
x
x
UPDATE
x
x
DELETE
x
x
Programme
x
EXECUTE
Dans le tableau, la colonne "Programme" désigne les procédures et fonctions stockées et les packages.
Ces privilèges donnent les droits suivants :
SELECT
Droit de lecture des données (exécution de l’ordre SQL SELECT).
INSERT
Droit de création des données (exécution de l’ordre SQL INSERT).
UPDATE
Droit de mise à jour des données (exécution de l’ordre SQL UPDATE).
DELETE
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Droit de suppression des données (exécution de l’ordre SQL DELETE).
EXECUTE
Droit d’exécution du programme (appeler la procédure, la fonction ou le package à partir d’un autre programme).
Avoir un droit sur un objet ne dispense pas de devoir qualifier l’objet par le nom du propriétaire si l’on souhaite y
accéder (sinon, Oracle pense que vous cherchez à accéder à un objet dans votre schéma). Pour faciliter l’écriture
des requêtes et rendre le schéma propriétaire des objets transparent, il faut utiliser des synonymes, en l’occurrence
plutôt des synonymes publics.
Réciproquement, l’existence d’un synonyme, même public, ne donne aucun droit sur l’objet sous­jacent.
Les privilèges objet sont destinés à contrôler l’accès à des objets bien identifiés. Par exemple : le droit de créer une
commande (i.e. le droit de faire un INSERT dans la table COMMANDE), le droit de supprimer une fiche client (i.e. le droit
de faire un DELETE dans la table CLIENT).
Ils sont principalement employés pour permettre aux utilisateurs finaux d’une application d’accéder, directement ou
via une interface utilisateur, aux objets de l’application créés dans un compte "propriétaire" de l’application (car par
défaut, seul le propriétaire d’un objet a le droit d’y accéder).
Le message d’erreur retourné par Oracle, lorsqu’un utilisateur n’a pas le privilège requis pour réaliser une action sur
un objet, est déterminé différemment si l’utilisateur possède ou non au moins un privilège sur l’objet :
●
●
Si l’utilisateur n’a aucun privilège sur l’objet, Oracle retourne l’erreur ORA-00942: Table ou vue inexistante.
Si l’utilisateur a au moins un privilège sur l’objet, Oracle retourne l’erreur ORA-01031:
insuffisants.
privilèges
Dans le premier cas, Oracle considère que l’utilisateur n’a normalement aucun moyen de savoir que l’objet accédé
existe : il indique donc que l’objet n’existe pas. Dans le deuxième cas, Oracle considère que l’utilisateur peut savoir
que l’objet existe : il indique donc que le privilège est insuffisant.
b. Attribution d’un privilège objet à un utilisateur
L’ordre SQL GRANT permet d’attribuer un privilège objet.
Syntaxe
GRANT { nom_privilège[(liste_colonnes)] [,...] | ALL [PRIVILEGES] }
ON [nom_schéma.]nom_objet
TO { nom_utilisateur | PUBLIC } [,...]
[ WITH GRANT OPTION ] ;
Exemple :
GRANT SELECT, INSERT, UPDATE(nom,prenom) ON adherent TO oheu;
Pour les privilèges INSERT et UPDATE, une liste de colonnes peut être spécifiée afin de limiter le privilège aux
colonnes indiquées.
La clause WITH GRANT OPTION donne au bénéficiaire le droit de transmettre le privilège objet.
Le mot clé ALL permet d’attribuer tous les privilèges. Dans le cas où l’utilisateur qui attribue tous les droits n’est pas
le propriétaire de l’objet, mais un utilisateur qui a reçu certains privilèges sur l’objet avec le droit de les transmettre
(clause WITH GRANT OPTION), le mot clé ALL désigne uniquement tous les privilèges que l’utilisateur a reçus.
Le privilège peut être attribué à un utilisateur ou à tous les utilisateurs (PUBLIC).
Plusieurs privilèges peuvent être attribués à plusieurs utilisateurs en un seul ordre ; par contre, l’attribution des
privilèges objet s’effectue objet par objet.
Le privilège attribué est immédiatement actif.
Pour attribuer un privilège objet, il faut :
●
- 4-
être propriétaire de l’objet ;
© ENI Editions - All rights reserved - Algeria Educ
●
avoir reçu le privilège en question avec la clause WITH GRANT OPTION ;
●
ou avoir reçu le privilège système ANY OBJECT PRIVILEGE.
Un utilisateur qui retransmet un privilège qu’il a reçu avec l’option WITH GRANT OPTION doit qualifier le nom de l’objet
avec le nom du propriétaire (car l’objet ne lui appartient pas), sauf s’il existe un synonyme sur l’objet.
Certains privilèges système donnent implicitement des privilèges objet sur tous les objets. Exemple : SELECT ANY
TABLE.
Le DBA a les privilèges système ANY indiqués précédemment ; c’est la raison pour laquelle il peut accéder à
n’importe quel objet sans privilège objet. Depuis la version 9, il a aussi le privilège système ANY OBJECT PRIVILEGE
qui lui permet d’attribuer un privilège objet sur n’importe quel objet, sans avoir reçu le privilège en question WITH
GRANT OPTION. Avant la version 9, ce n’était pas possible.
c. Révocation d’un privilège objet à un utilisateur
L’ordre SQL REVOKE permet de révoquer un privilège objet.
Syntaxe
REVOKE { nom_privilège [,...] | ALL [PRIVILEGES] }
ON [nom_schéma.]nom_objet
FROM { nom_utilisateur | PUBLIC } [,...] ;
Exemple :
REVOKE INSERT, UPDATE ON client FROM oheu;
L’ordre REVOKE permet de révoquer à un utilisateur uniquement ce qu’il a reçu en direct (pas les privilèges qu’il a
implicitement via PUBLIC). Il en est de même pour PUBLIC : vous ne pouvez pas révoquer à PUBLIC un privilège non
attribué à PUBLIC en pensant l’enlever ainsi à tout le monde.
Si un privilège a été attribué à un utilisateur et à PUBLIC, le révoquer à l’utilisateur est sans effet ; l’utilisateur
continue d’exercer le privilège : il l’a toujours via PUBLIC.Tous les privilèges objet peuvent être révoqués d’un seul
coup avec le mot clé ALL (REVOKE ALL ON ... FROM ...). Si vous avez attribué un privilège avec l’option WITH GRANT
OPTION et que vous souhaitiez enlever cette possibilité de transmission, il faut révoquer le privilège et l’attribuer de
nouveau sans l’option. Le privilège est immédiatement enlevé et ne peut plus être exercé.
Pour enlever un privilège objet, il faut :
●
être propriétaire de l’objet ;
●
avoir reçu le privilège en question avec la clause WITH GRANT OPTION ;
●
ou avoir reçu le privilège système ANY OBJECT PRIVILEGE.
Il y a cascade dans la révocation d’un privilège objet qui a été transmis grâce à la clause WITH GRANT OPTION. Si un
privilège a été attribué à Pierre avec l’option WITH GRANT OPTION et que Pierre l’ait transmis à Paul, révoquer le
privilège de Pierre révoque également celui de Paul. Le fonctionnement n’est pas le même que pour les privilèges
système.
d. Privilèges sur les vues et les programmes stockés
Un utilisateur qui a un droit sur une vue n’a pas besoin d’avoir les droits sur les objets manipulés par la vue.
Il en est de même par défaut pour les programmes stockés : le programme stocké s’exécute avec les droits du
propriétaire (definer rights). Au besoin, le programme stocké peut être conçu pour s’exécuter avec les droits de
l’appelant (invoker rights).
Le comportement souhaité se définit lors de la création du programme stocké grâce à la clause AUTHID.
Syntaxe
AUTHID { CURRENT_USER | DEFINER }
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 5-
Le mode de fonctionnement par défaut (droits du propriétaire) est très intéressant car il permet d’utiliser les vues et
les programmes stockés comme couche intermédiaire pour l’accès aux objets de la base de données. Il est possible
de construire une application dans laquelle la partie cliente n’accède jamais directement aux tables de la base de
données mais passe par des vues et/ou des programmes stockés. Ce genre d’approche permet principalement :
●
●
de masquer la structure réelle des tables et de pouvoir la faire évoluer avec le minimum d’impacts sur la
partie cliente ;
d’implémenter des règles de gestion (contrôles, calculs, sécurité, etc.) côté serveur.
e. Nommer un objet d’un autre schéma
Même si un utilisateur a un privilège sur un objet d’un autre schéma, il doit préfixer le nom de l’objet par le nom de
son propriétaire pour pouvoir y accéder :
SELECT * FROM diane.adherent;
Des synonymes publics peuvent être définis pour simplifier l’écriture des requêtes et les rendre indépendantes du
nom du propriétaire :
CREATE PUBLIC SYNONYM adherent FOR diane.adherent;
Lorsque la requête SELECT * FROM adherent est exécutée, Oracle regarde d’abord dans le schéma courant s’il existe
un objet nommé adherent. Si c’est le cas, il l’utilise. Si ce n’est pas le cas, il recherche un synonyme public portant ce
nom. S’il en trouve un, il remplace le synonyme par sa définition.
Depuis la version 8i, Il est aussi possible de "placer" sa session dans le schéma d’un autre utilisateur. Lorsqu’un
objet est référencé dans un ordre SQL, Oracle regardera si un tel objet existe dans l’autre schéma avant de
rechercher un éventuel synonyme public.
Exemple :
ALTER SESSION SET CURRENT_SCHEMA = diane;
Il faut bien noter que les deux techniques ne donnent pas de droit en soi ; ce sont juste des techniques de
résolution de nom. Une fois que le nom est résolu, Oracle regarde si l’utilisateur a les privilèges nécessaires
pour accéder à l’objet.
f. Aller plus loin sur la gestion des droits
Oracle propose des fonctionnalités de Virtual Private Database (VPD) et de Fine­Grained Access (FGA) qui permettent
de placer des mécanismes de filtres sur les lignes des tables. Ces fonctionnalités sont décrites dans la
documentation Oracle® Database Security Guide ; elles sont basées sur l’utilisation du package DBMS_RLS.
3. Rôle
a. Définition
Un rôle est un regroupement nommé de privilèges (système et objet) qui peut être attribué à un utilisateur. Tous
les privilèges regroupés dans le rôle sont alors simultanément attribués à l’utilisateur. Les rôles permettent de
simplifier la gestion des droits.
Les principales caractéristiques des rôles sont les suivantes :
- 6-
●
Un rôle peut être attribué à un autre rôle.
●
Un utilisateur peut avoir plusieurs rôles.
●
Un rôle n’appartient à personne.
© ENI Editions - All rights reserved - Algeria Educ
La mise en œ uvre s’effectue en trois étapes :
●
création du rôle ;
●
attribution des privilèges (système et objet) au rôle ;
●
attribution du rôle aux utilisateurs.
b. Création d’un rôle
L’ordre SQL CREATE ROLE permet de créer un rôle.
Syntaxe
CREATE ROLE nom
[ IDENTIFIED { BY mot_de_passe | EXTERNALLY | USING nom_package}
| NOT IDENTIFIED ];
Exemple :
CREATE ROLE mailing;
Les options sont :
IDENTIFIED BY mot_de_passe
Indique qu’un mot de passe est nécessaire pour activer le rôle.
IDENTIFIED EXTERNALLY
Indique qu’une identification externe est nécessaire pour activer le rôle.
IDENTIFIED USING nom_package
Indique que seul le package peut activer le rôle.
NOT IDENTIFIED
Indique qu’aucune identification n’est nécessaire pour activer le rôle. C’est la valeur par défaut.
Pour créer un rôle, il faut avoir le privilège système CREATE ROLE.
Lors de la création d’un rôle, il est possible de préciser par quel mécanisme le rôle pourra être activé : un mot de
passe, une identification externe (système d’exploitation) ou un package. Le mécanisme d’activation sera présenté
dans ce chapitre, section Rôle ­ Activation ou désactivation d’un rôle.
L’ordre SQL ALTER ROLE>permet de modifier un rôle, en l’occurrence le mode d’identification pour pouvoir l’activer.
Syntaxe
ALTER ROLE nom
[ IDENTIFIED { BY mot_de_passe | EXTERNALLY | USING nom_package}
| NOT IDENTIFIED ];
c. Attribution d’un privilège à un rôle
L’ordre SQL GRANTpermet d’attribuer des privilèges système ou des privilèges objet à un rôle.
Syntaxe pour les privilèges système
GRANT nom_privilège [,...]
TO nom_rôle [,...]
[ WITH ADMIN OPTION ] ;
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 7-
Syntaxe pour les privilèges objet
GRANT { nom_privilège[(liste_colonnes)] [,...] | ALL [PRIVILEGES] }
ON [nom_schéma.]nom_objet
TO nom_rôle [,...] ;
Exemple :
GRANT CREATE SESSION, CREATE TABLE TO mailing;
GRANT SELECT, INSERT ON adherent TO mailing;
Les syntaxes sont les mêmes que pour l’attribution directe à un utilisateur, à l’exception de la clause WITH GRANT
OPTION qui n’est pas permise pour l’attribution d’un privilège objet à un rôle.
Les privilèges attribués sont immédiatement actifs pour les utilisateurs connectés qui ont le rôle actif. La notion de
rôle actif sera présentée un peu plus loins dans ce chapitre Gérer les droits, section Rôle ­ Activation ou
désactivation d’un rôle.
Tout utilisateur a le droit d’attribuer un privilège à un rôle, du moment qu’il a le droit d’attribuer le privilège ; c’est en
cela que le rôle n’appartient à personne. En l’occurrence, pour attribuer un privilège système à un rôle, il faut avoir
reçu le privilège en question avec la clause WITH ADMIN OPTION ou avoir le privilège système GRANT ANY PRIVILEGE.
Pour attribuer un privilège objet à un rôle, il faut être propriétaire de l’objet, avoir reçu le privilège en question avec
la clause WITH GRANT OPTION, ou avoir le privilège système ANY OBJECT PRIVILEGE.
d. Révocation d’un privilège à un rôle
L’ordre SQL REVOKEpermet de révoquer des privilèges système ou des privilèges objet à un rôle.
Syntaxe pour les privilèges système
REVOKE nom_privilège [ ,...]
FROM nom_rôle [,...] ;
Syntaxe pour les privilèges objet
REVOKE { nom_privilège [,...] | ALL [PRIVILEGES] }
ON [nom_schéma.]nom_objet
FROM nom_rôle [,...] ;
Exemple :
REVOKE CREATE TABLE FROM mailing;
REVOKE UPDATE ON adherent FROM mailing;
Les syntaxes sont les mêmes que pour la révocation directe à un utilisateur.D’une manière générale, l’ordre SQL
REVOKE ne permet d’enlever à une "cible" (utilisateur, rôle ou PUBLIC) que ce qui a été attribué explicitement à cette
"cible". Par exemple, si un privilège a été attribué à un rôle, il n’est pas possible de l’enlever directement à un
utilisateur qui a reçu le rôle.
Attention au mélange attribution directe et attribution à un rôle : si un privilège est attribué à un rôle et le rôle à
l’utilisateur et qu’en parallèle le privilège est attribué en direct à l’utilisateur, révoquer le privilège de l’utilisateur ne
l’empêchera pas de pouvoir continuer à l’exercer (via le rôle).
Les privilèges sont immédiatement révoqués et ne peuvent plus être exercés par les utilisateurs connectés qui ont
le rôle actif. La notion de rôle actif sera présentée un peu plus loin dans ce chapitre, section Rôle ­ Activation ou
désactivation d’un rôle.
Tout utilisateur a le droit de révoquer un privilège d’un rôle, du moment qu’il a le droit de révoquer le privilège (le
rôle n’appartient à personne). En l’occurrence, pour révoquer un privilège système d’un rôle, il faut avoir reçu le
privilège en question avec la clause WITH ADMIN OPTION ou avoir le privilège système GRANT ANY PRIVILEGE. Pour
révoquer un privilège objet d’un rôle, il faut être propriétaire de l’objet, avoir reçu le privilège en question avec la
clause WITH GRANT OPTION, ou avoir le privilège système ANY OBJECT PRIVILEGE.
e. Attribution d’un rôle à un utilisateur ou à un rôle
L’ordre SQL GRANT permet d’attribuer un rôle à un utilisateur ou à un rôle.
Syntaxe
- 8-
© ENI Editions - All rights reserved - Algeria Educ
GRANT nom_rôle [,...]
TO { nom_utilisateur | PUBLIC | nom_rôle } [,...]
[ WITH ADMIN OPTION ] ;
Exemple :
GRANT mailing TO oheu;
La syntaxe est la même que pour l’attribution d’un privilège système.
Pour attribuer un rôle, il faut avoir reçu le rôle en question avec la clause WITH ADMIN OPTION ou avoir le privilège
système GRANT ANY ROLE. Le créateur d’un rôle n’est pas propriétaire du rôle mais le rôle lui est attribué avec
l’option WITH ADMIN OPTION ; il peut donc attribuer le rôle qu’il a créé.
Le rôle attribué n’est pas immédiatement actif si l’utilisateur est déjà connecté.
La clause WITH ADMIN OPTION donne aussi le droit de modifier (ordre SQL ALTER ROLE) et de supprimer le rôle (ordre
SQL DROP ROLE).
Un utilisateur peut avoir plusieurs rôles ; dans ce cas, les privilèges se cumulent (il n’y a pas de privilège "négatif").
f. Révocation d’un rôle à un utilisateur ou à un rôle
L’ordre SQL REVOKE permet de révoquer un rôle.
Syntaxe
REVOKE nom_rôle [,...]
FROM { nom_utilisateur | PUBLIC | nom_rôle } [,...] ;
Exemple :
REVOKE mailing FROM oheu;
La syntaxe est la même que pour la révocation d’un privilège système. Pour enlever un rôle, il faut avoir reçu le rôle
en question avec la clause WITH ADMIN OPTION ou avoir le privilège système GRANT ANY ROLE. Le créateur du rôle
ayant reçu ce dernier avec la clause WITH ADMIN OPTION, il peut donc enlever le rôle.
Lorsqu’un rôle est révoqué, les utilisateurs connectés avec le rôle actif peuvent continuer à exercer les privilèges
associés, jusqu’à la fin de la session ou jusqu’à la désactivation du rôle.
g. Suppression d’un rôle
L’ordre SQL DROP ROLE permet de supprimer un rôle.
Syntaxe
DROP ROLE nom_rôle ;
Exemple :
DROP ROLE mailing;
Pour supprimer un rôle, il faut avoir reçu le rôle en question avec la clause WITH ADMIN OPTION ou avoir le privilège
système DROP ANY ROLE.
Le rôle est immédiatement enlevé aux utilisateurs ; les privilèges associés ne peuvent plus être exercés.
h. Activation ou désactivation d’un rôle
Un rôle attribué à un utilisateur (directement ou via un autre rôle) est par défaut automatiquement activé lors de la
connexion de l’utilisateur.
Si l’utilisateur est connecté au moment de l’attribution, l’activation immédiate n’est pas automatique. L’utilisateur
peut activer le rôle grâce à l’ordre SQL SET ROLE.
De plus, parmi les rôles attribués à l’utilisateur, il est possible de définir ceux qui sont effectivement
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 9-
automatiquement activés lors de la connexion de l’utilisateur. Ce sont les rôles par défaut définis par un ordre SQL
ALTER USER. L’utilisateur peut ensuite activer les autres grâce à l’ordre SQL SET ROLE.
Utiliser plusieurs rôles sans qu’ils soient tous actifs simultanément présente deux intérêts :
●
●
Il existe un paramètre, MAX_ENABLED_ROLES (30 par défaut), qui limite le nombre de rôles actifs
simultanément pour un utilisateur. Si un utilisateur est susceptible d’employer un nombre de rôles supérieur
à cette limite, il est possible d’en désactiver certains pour en activer d’autres.
Des rôles, protégés par des mots de passe, peuvent être attribués à des utilisateurs, mais inactifs par
défaut, et sans donner le mot de passe à l’utilisateur ; ce sont alors les applications qui activent les rôles
dont elles ont besoin, en fournissant le mot de passe. De cette manière, en dehors de l’application en
question, l’utilisateur n’a aucun moyen d’activer et d’utiliser le rôle (et éventuellement de faire des erreurs).
L’ordre SQL ALTER USER permet de définir les rôles par défaut d’un utilisateur.
Syntaxe
ALTER USER nom_utilisateur DEFAULT ROLE
{ nom_rôle [,...] | ALL [ EXCEPT nom_rôle [,...] ] | NONE } ;
Exemple :
ALTER USER oheu DEFAULT ROLE mailing;
ALTER USER vdep DEFAULT ROLE ALL EXCEPT mailing;
Les options sont :
ALL
Tous les rôles attribués à l’utilisateur sont activés par défaut. La clause EXCEPT permet d’en enlever certains.
NONE
Aucun des rôles attribués à l’utilisateur n’est activé par défaut.
Cet ordre SQL annule et remplace la situation actuelle des rôles par défaut ; elle n’ajoute pas ou n’enlève pas les
rôles à la liste actuelle. Les rôles attribués à un utilisateur qui a déjà des rôles par défaut, ne sont pas définis par
défaut.
L’ordre SQL SET ROLE permet d’activer ou de désactiver un rôle.
Syntaxe
SET ROLE
{ nom_rôle [ IDENTIFIED BY mot_de_passe ] [,...]
| ALL [ EXCEPT nom_rôle [,...] ] | NONE } ;
Exemple :
-- L’utilisateur VDEP active le rôle MAILING
SET ROLE mailing;
Les options sont :
IDENTIFIED BY
Donne le mot de passe qui permet d’activer le rôle.
ALL
Tous les rôles attribués à l’utilisateur sont activés. La clause EXCEPT permet d’en enlever certains.
NONE
Aucun des rôles attribués à l’utilisateur n’est activé (désactive donc tous les rôles).
- 10 -
© ENI Editions - All rights reserved - Algeria Educ
Les rôles doivent avoir préalablement été attribués à un utilisateur ; il n’est donc pas possible de s’autoattribuer un
rôle en l’activant (heureusement).
Cet ordre SQL annule et remplace les rôles actuellement actifs (pas d’ajout).
L’option ALL ne peut pas être utilisée sur des rôles protégés par un mot de passe.
Les rôles définis avec l’option IDENTIFIED USING nom_package ne peuvent être activés de la sorte qu’à partir du
package spécifié.
La procédure SET_ROLE du package DBMS_SESSION permet de faire la même chose (voir la documentation "PL/SQL
Packages and Types Reference").
i. Limitation des rôles
Pour développer un objet (une vue ou un programme stocké) qui utilise des objets d’un autre schéma, il faut avoir
reçu des droits en direct sur les objets, pas à travers un rôle.
Par ailleurs, lors de l’exécution d’un programme stocké, les rôles activés de l’utilisateur appelant ne sont pris en
compte que si le programme stocké est conçus pour s’exécuter avec les droits de l’appelant (clause AUTHID
CURRENT_USER).
j. Rôles prédéfinis
Oracle propose en standard un grand nombre de rôle prédéfinis, parmi lesquels :
CONNECT
Autorise la connexion (contient uniquement le privilège système CREATE SESSION).
RESOURCE
Permet la création des principaux objets d’un schéma (table, vue...).
DBA
Donne tous les privilèges système avec l’option WITH ADMIN OPTION.
MGMT_USER
Permet d’utiliser le Database Control en tant qu’administrateur.
Les vues DBA_SYS_PRIVS et DBA_TAB_PRIVS permettent de connaître les privilèges regroupés dans ces rôles
prédéfinis.Oracle préconise de ne pas utiliser les rôles prédéfinis CONNECT, RESOURCE et DBA mais de créer ses propres
rôles.Depuis la version 10.2 (10 g Release 2), le rôle CONNECT ne contient plus que le privilège système CREATE
SESSION. Avant cette version, ce rôle contenait d’autres privilèges qui permettaient de créer les principaux objets
d’un schéma (table, vue, etc.) ou de modifier la session (privilège système ALTER SESSION). Depuis la version 10.2, si
vous avez besoin d’attribuer de tels droits à un utilisateur, le rôle CONNECT ne suffit pas ; par contre, vous pouvez
attribuer ces droits directement à l’utilisateur ou via un rôle spécifique que vous créez.
4. Trouver des informations sur les droits
a. Privilèges système
Plusieurs vues du dictionnaire de données permettent d’obtenir des informations sur les privilèges système :
●
●
●
openmirrors.com
DBA_SYS_PRIVS : privilèges système attribués aux utilisateurs (ou aux rôles) ;
SESSION_PRIVS : privilèges système actuellement actifs dans la session (obtenus directement ou via un
rôle) ;
SYSTEM_PRIVILEGE_MAP : liste de tous les privilèges système.
© ENI Editions - All rights reserved - Algeria Educ
- 11 -
Les colonnes intéressantes des différentes vues sont présentées ci­après.
DBA_SYS_PRIVS
GRANTEE
Nom de l’utilisateur ou du rôle qui a reçu le privilège système.
PRIVILEGE
Privilège système reçu.
ADMIN_OPTION
Privilège reçu avec la clause WITH ADMIN OPTION (YES ou NO).
SESSION_PRIVS
PRIVILEGE
Nom du privilège.
SYSTEM_PRIVILEGE_MAP
NAME
Nom du privilège.
b. Privilèges objet
Plusieurs vues du dictionnaire de données permettent d’obtenir des informations sur les privilèges objet :
●
●
●
DBA_TAB_PRIVS : privilèges objet attribués aux utilisateurs (ou aux rôles) sur la totalité de l’objet
DBA_COL_PRIVS: privilèges objet attribués aux utilisateurs (ou aux rôles) sur certaines colonnes de l’objet
uniquement ;
TABLE_PRIVILEGE_MAP : liste de tous les privilèges objet.
Les colonnes intéressantes des différentes vues sont présentées ci­après.
DBA_TAB_PRIVS
GRANTEE
Nom de l’utilisateur ou du rôle qui a reçu le privilège objet.
OWNER
Nom de l’utilisateur propriétaire de l’objet.
TABLE_NAME
Nom de l’objet (pas forcément une table, malgré le nom).
GRANTOR
Nom de l’utilisateur qui a attribué le privilège.
PRIVILEGE
- 12 -
© ENI Editions - All rights reserved - Algeria Educ
Privilège objet reçu.
GRANTABLE
Privilège reçu avec la clause WITH GRANT OPTION (YES ou NO).
DBA_COL_PRIVS
GRANTEE
Nom de l’utilisateur ou du rôle qui a reçu le privilège objet.
OWNER
Nom de l’utilisateur propriétaire de l’objet.
TABLE_NAME
Nom de l’objet (table ou vue).
COLUMN_NAME
Nom de la colonne.
GRANTOR
Nom de l’utilisateur qui a attribué le privilège.
PRIVILEGE
Privilège objet reçu.
GRANTABLE
Privilège reçu avec la clause WITH GRANT OPTION (YES ou NO).
TABLE_PRIVILEGE_MAP
NAME
Nom du privilège.
c. Rôles
Plusieurs vues du dictionnaire de données permettent d’obtenir des informations sur les rôles :
●
DBA_ROLES : liste des rôles existant dans la base ;
●
DBA_APPLICATION_ROLES : description des rôles ayant une activation par un package ;
●
DBA_SYS_PRIVS : privilèges système attribués aux rôles (ou aux utilisateurs), voir précédemment ;
●
●
●
openmirrors.com
DBA_TAB_PRIVS : privilèges objet attribués aux rôles (ou aux utilisateurs) sur la totalité de l’objet, voir
précédemment ;
DBA_COL_PRIVS : privilèges objet attribués aux rôles (ou aux utilisateurs) sur certaines colonnes de l’objet
uniquement, voir précédemment ;
DBA_ROLE_PRIVS : rôles attribués aux utilisateurs ou aux rôles ;
© ENI Editions - All rights reserved - Algeria Educ
- 13 -
●
●
●
●
ROLE_SYS_PRIVS : privilèges système attribués aux rôles (uniquement pour les rôles auxquels l’utilisateur a
accès) ;
ROLE_TAB_PRIVS : privilèges objet attribués aux rôles (uniquement pour les rôles auxquels l’utilisateur a
accès) ;
ROLE_ROLE_PRIVS : rôles attribués à d’autres rôles (uniquement pour les rôles auxquels l’utilisateur a
accès) ;
SESSION_ROLES : rôles actuellement actifs dans la session.
Les colonnes intéressantes des différentes vues sont présentées ci­après.
DBA_ROLES
ROLE
Nom du rôle.
PASSWORD_REQUIRED
Indique si un mot de passe est nécessaire pour activer le rôle (YES, NO ou GLOBAL).
DBA_APPLICATION_ROLES
ROLE
Nom du rôle.
SCHEMA
Schéma du package utilisé pour l’activation.
PACKAGE
Nom du package utilisé pour l’activation.
DBA_ROLE_PRIVS
GRANTEE
Nom de l’utilisateur ou du rôle qui a reçu le rôle.
GRANTED_ROLE
Nom du rôle reçu.
ADMIN_OPTION
Rôle reçu avec la clause WITH ADMIN OPTION (YES ou NO).
ROLE_SYS_PRIVS
ROLE
Nom du rôle.
PRIVILEGE
Nom du privilège système reçu via le rôle.
- 14 -
© ENI Editions - All rights reserved - Algeria Educ
ADMIN_OPTION
Privilège reçu avec la clause WITH ADMIN OPTION (YES ou NO).
ROLE_TAB_PRIVS
ROLE
Nom du rôle.
OWNER
Nom de l’utilisateur propriétaire de l’objet.
TABLE_NAME
Nom de l’objet (pas forcément une table, malgré le nom).
COLUMN_NAME
Nom de la colonne (si applicable).
PRIVILEGE
Privilège objet reçu.
ROLE_ROLE_PRIVS
ROLE
Nom du rôle.
GRANTED_ROLE
Nom du rôle attribué au rôle.
ADMIN_OPTION
Rôle reçu avec la clause WITH ADMIN OPTION (YES ou NO).
SESSION_ROLES
ROLE
Nom du rôle.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 15 -
Synthèse
1. Les différents types de comptes
Une base Oracle contient en général quatre types de comptes.
Administration
Un tel compte a tous les privilèges système nécessaires, notamment pour la gestion des structures de stockage et la
gestion des utilisateurs. Les comptes d’administration ont, de plus, un accès complet au dictionnaire de données.
Ces privilèges peuvent être obtenus par l’intermédiaire du rôle DBA ou d’un rôle équivalent.
Développement / Hébergement du schéma applicatif
Un tel compte a les privilèges système nécessaires pour la création des différents types d’objets (tables, vues,
procédures...) et il possède un quota sur au moins un tablespace.Les privilèges système requis peuvent être obtenus
par l’intermédiaire des rôles CONNECT et RESOURCE, ou d’un rôle équivalent que vous avez créé (conseillé).
Pour les comptes de développement, il peut être judicieux de prévoir un tablespace dédié et de définir un quota
uniquement sur ce tablespace. Dans l’idéal, il est préférable d’utiliser une base de données à part pour le
développement.
Le compte "propriétaire" d’une application a généralement des quotas illimités sur les tablespaces (de tables et
d’index) dédiés à l’application.
Utilisateur final
Un tel compte a besoin de très peu de privilèges système : CREATE SESSION (obligatoire), ALTER SESSION (parfois
nécessaire), et c’est généralement tout. Par contre, il possède des privilèges objet sur les objets du schéma
applicatif, généralement par l’intermédiaire d’un rôle.
Les comptes des utilisateurs finaux n’ont besoin d’aucun quota dans les tablespaces. Ils accèdent aux objets du
schéma applicatif grâce aux privilèges objet et l’écriture des requêtes est simplifiée par l’utilisation de synonymes
publics ou par l’exécution de l’ordre SQL ALTER SESSION SET CURRENT_SCHEMA.
Les profils peuvent être utilisés en plus, pour contrôler l’utilisation de certaines ressources ou mettre en œ uvre une
politique de gestion des mots de passe.
2. Quelques conseils pour sécuriser votre base de données
Voici quelques conseils simples (souvent de bon sens) qui permettent de sécuriser votre base de données :
●
●
●
●
●
●
Limitez les accès au serveur (notamment au fichier de mot de passe, au fichier de paramètre et aux fichiers
de trace ou d’alerte de chaque instance Oracle).
Interdisez l’authentification par le système d’exploitation à travers le réseau (le paramètre REMOTE_OS_AUTHENT
doit être à FALSE).
Verrouillez et expirez le mot de passe des comptes par défaut qui ne sont pas utilisés (c’est le cas, par
défaut, lorsque vous créez une base de données avec l’assistant graphique Configuration de base de
données). Les seuls comptes par défaut qui doivent être obligatoirement ouverts sont SYS et SYSTEM, ainsi
que SYSMAN et DBSNMP si vous utilisez le Database Control.
Modifiez les mots de passe par défaut des comptes par défaut que vous utilisez (au premier rang desquels
SYS, SYSTEM, SYSMAN et DBSNMP). Vous pouvez interroger la vue DBA_USERS_WITH_DEFPWD pour avoir la liste des
utilisateurs qui ont encore leur mot de passe par défaut.
Utilisez des mots de passe complexes (10 caractères au minimum, avec des lettres majuscules, des lettres
minuscules, des chiffres et des caractères spéciaux).
Utilisez une politique de gestion de mot de passe avec un nombre limité d’échecs de tentative de connexion
autorisés et des règles sur la complexité des mots de passe.
© ENI Editions - All rights reserved - Algeria Educ
- 1-
●
Ne stockez pas les mots de passe en clair dans des tables ou des scripts.
●
Attribuez le moins de privilèges possible aux utilisateurs (notamment les privilèges système ANY).
●
●
●
Définissez vos propres rôles et n’utilisez pas les rôles prédéfinis par Oracle.
Attribuez un rôle à un utilisateur que s’il a réellement besoin de tous les privilèges contenus dans le rôle. Si
ce n’est pas le cas, créez un autre rôle plus restrictif.
●
N’attribuez aucun privilège système à PUBLIC (il n’y en a aucun par défaut).
●
N’attribuez aucun privilège objet à PUBLIC (autre que ceux attribués par défaut).
●
- 2-
Utilisez des rôles pour gérer les droits. Si le rôle est activé par une application, protégez­le par un mot de
passe.
openmirrors.com
Révoquez les privilèges EXECUTE attribués par défaut à PUBLIC sur plusieurs packages potentiellement
dangereux pour la sécurité : DBMS_LOB, DBMS_JOB, UTL_FILE, UTL_HTTP, UTL_TCP, UTL_SMTP, DBMS_SYS_SQL. Ce
point est assez complexe car ces packages sont utilisés par de nombreux comptes Oracle (SYS notamment). Si
vous enlevez le privilège EXECUTE attribués à PUBLIC sur ces packages, vous serez amenés à réattribuer les
droits nécessaires directement aux utilisateurs concernés (vous pouvez interroger la vue DBA_DEPENDANCIES
pour connaître les comptes qui utilisent ces packages).
© ENI Editions - All rights reserved - Algeria Educ
Superviser les utilisateurs connectés
La vue V$SESSION permet d’identifier les utilisateurs actuellement connectés :
SQL> SELECT sid,serial#,username,osuser,status FROM v$session;
SID
SERIAL# USERNAME
OSUSER
STATUS
---- --------- ---------- ------------------------- -------1
3
SYSTEM
ACTIVE
...
10
10494 VDEP
vdep
INACTIVE
14
450 SYSTEM
Administrateur
ACTIVE
Les sessions sans valeur dans la colonne USERNAME sont celles des processus d’arrière­plan.
Les colonnes intéressantes de la vue V$SESSION sont les suivantes :
SID
Identifiant de la session.
SERIAL#
Numéro de série de la session.
USERNAME
Nom de l’utilisateur (compte Oracle).
SCHEMANAME
Nom du schéma de l’utilisateur (peut être différent de USERNAME si la session a exécuté l’ordre SQL ALTER SESSION SET
CURRENT_ SCHEMA).
STATUS
Statut de la session (ACTIVE, INACTIVE ou KILLED).
LOGON_TIME
Date et heure de connexion.
OSUSER
Nom de l’utilisateur au niveau du système d’exploitation.
MACHINE
Nom de la machine de l’utilisateur au niveau du système d’exploitation.
TERMINAL
Nom du terminal de l’utilisateur au niveau du système d’exploitation.
PROGRAM
Nom du programme employé par l’utilisateur pour se connecter à la base de données.
SERVER
Type de processus serveur (DEDICATED ou SHARED).
© ENI Editions - All rights reserved - Algeria Educ
- 1-
SQL_ID
Identifiant de la requête SQL en cours d’exécution (une jointure avec V$SQL ou V$SQLAREA sur la même colonne permet
de voir l’ordre SQL en question).
SERVICE_NAME
Nom de service de la session (service auquel l’utilisateur s’est connecté).
Au besoin, vous pouvez aussi interroger la vue V$SESSION_LONGOPS pour obtenir des informations sur les opérations
longues (en cours depuis plus de 6 secondes).Pour déconnecter un utilisateur, vous pouvez utiliser l’ordre SQL ALTER
SYSTEM.
Syntaxe
ALTER SYSTEM KILL SESSION ’sid,serial#’;
ou
ALTER SYSTEM DISCONNECT SESSION ’sid,serial#’
{ IMMEDIATE | POST_TRANSACTION};
Exemple :
ALTER SYSTEM KILL SESSION ’10,10494’;
Les ordres SQL ALTER SYSTEM KILL SESSION et ALTER SYSTEM DISCONNECT SESSION ... IMMEDIATE sont équivalents : ils
ferment la session immédiatement, sans attendre la fin d’une éventuelle transaction en cours (cette dernière est
annulée). Par contre, l’ordre SQL ALTER SYSTEM DISCONNECT SESSION ... POST_TRANSACTION attend que la transaction
en cours se termine.
Un utilisateur en train d’exécuter une requête a un statut ACTIVE (INACTIVE sinon). Si un utilisateur est déconnecté
alors qu’il est actif, sa requête est interrompue, un message d’erreur lui indiquant qu’il a été déconnecté, lui est
retourné (ORA-00028<$I[]ORA-00028>: votre session a été fermée) et la session disparaît de V$SESSION. S’il est inactif,
la connexion est fermée mais la session reste visible dans V$SESSION avec le statut KILLED jusqu’à ce que l’utilisateur
ait été notifié de la déconnexion lors de sa prochaine action (avec la même erreur ORA-00028).
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Utiliser le Database Control
1. Utilisateurs
Sur la page d’accueil, cliquez sur le lien Serveur puis sur le lien Utilisateurs (cadre Sécurité) pour accéder à la page
de gestion des utilisateurs ci­après.
À partir de cette page, vous pouvez effectuer diverses actions sur les utilisateurs :
●
créer un nouvel utilisateur (bouton Créer ou menu Créer comme) ;
●
supprimer un utilisateur (bouton Supprimer) ;
●
modifier un utilisateur (bouton Modifier) ;
●
faire expirer le mot de passe (menu Expiration du mot de passe) ;
●
verrouiller ou déverrouiller le compte (menus Verrouiller l’utilisateur ou Déverrouiller l’utilisateur).
En cliquant sur le lien du nom de l’utilisateur, ou en cliquant sur les boutons Créer, Modifier ou Visualiser, vous
arrivez sur la page de définition d’un utilisateur :
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Les onglets (sous forme de liens) de
l’utilisateur : identification, droits, quotas.
cette
page
permettent
de
gérer
les
différentes
propriétés
de
2. Rôles
Sur la page d’accueil, cliquez sur le lien Serveur puis sur le lien Rôles (cadre Sécurité) pour accéder à la page de
gestion des rôles :
À partir de cette page, vous pouvez effectuer diverses actions sur les rôles :
●
- 2-
openmirrors.com
créer un nouveau rôle (bouton Créer ou menu Créer comme) ;
© ENI Editions - All rights reserved - Algeria Educ
●
supprimer un rôle (bouton Supprimer) ;
●
modifier un rôle (bouton Modifier) ;
●
voir les utilisateurs qui ont le rôle (menu Afficher les bénéficiaires).
En cliquant sur le lien du nom de rôle, ou en cliquant sur les boutons Créer, Modifier ou Visualiser, vous arrivez sur
la page de définition d’un rôle :
Les onglets (sous forme de liens) de cette page
rôle : authentification, rôles attribués, privilèges attribués.
permettent
de
gérer
les
différentes
propriétés
du
3. Profils
Sur la page d’accueil, cliquez sur le lien Serveur puis sur le lien Profils (cadre Sécurité) pour accéder à la page de
gestion des profils :
À partir de cette page, vous pouvez effectuer diverses actions sur les profils :
●
Créer un nouveau profil (bouton Créer ou menu Créer comme) ;
●
Supprimer un profil (bouton Supprimer) ;
© ENI Editions - All rights reserved - Algeria Educ
- 3-
●
Modifier un profil (bouton Modifier) ;
●
Voir les utilisateurs qui ont le profil (menu Afficher les dépendances).
En cliquant sur le lien du nom de profil, ou en cliquant sur les boutons Créer, Modifier ou Visualiser, vous arrivez sur
la page de définition d’un profil :
Les deux onglets (sous forme de liens) de cette page permettent de gérer les deux aspects du profil : limitation des
ressources et gestion des mots de passe.
- 4-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Vue d’ensemble
Parmi les principaux types d’objets d’un schéma, seuls les tables et les index occupent de l’espace de stockage en
dehors de leur définition dans le dictionnaire.
Cet espace de stockage doit être planifié correctement pour éviter les erreurs liées au manque d’espace ou les
problèmes de performance.
Les tables et les index sont des segments ; le stockage est donc organisé en extensions, piloté par la clause STORAGE
et par les caractéristiques du tablespace. Par ailleurs, l’organisation du stockage dans les blocs a de l’importance.
Il existe d’autres types d’objets qui occupent de l’espace de stockage, mais ces derniers sortent du périmètre de cet
ouvrage :
●
●
●
●
Vues matérialisées : structure analogue à une table et dont le contenu est périodiquement mis à jour à partir
d’une requête SELECT.
IOT (Index Organised Table ­ table organisée en index) : table dont le stockage est organisé dans l’index de la
clé primaire de la table.
Clusters : structures qui permettent de stocker physiquement ensemble des tables fréquemment interrogées
par jointure.
Tables et index partitionnées : depuis la version 8, l’option partitionnement permet de découper le stockage
physique des tables et des index en morceaux plus petits appelés partitions.
De même, il existe plusieurs types d’index :
●
●
●
●
Index B­tree : index classique qui sera étudié dans cet ouvrage.
Index Bitmap : index dont le stockage est organisé différemment des index B­tree et qui est plutôt destiné à
l’indexation des colonnes à faible cardinalité dans un environnement décisionnel (l’index bitmap est très
coûteux en mise à jour).
Index à clé inversée : index B­tree qui indexe non pas la valeur de la colonne mais une valeur résultant de
l’inversion des octets de la colonne (intéressant pour l’indexation de colonnes qui sont insérées en ordre
croissant et interrogées par égalité).
Index basé sur des fonctions : index B­tree qui indexe non pas la valeur de la colonne mais le résultat de
l’application d’une fonction SQL (UPPER, LOWER, etc.) à la valeur de la colonne. Il est intéressant lorsque la
colonne n’est pas interrogée directement (colonne opérateur valeur) mais avec la fonction (fonction(colonne)
opérateur valeur).
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Gestion des tables
1. Organisation du stockage dans les blocs
a. Principes
Structure du bloc
L’en­tête du bloc contient l’adresse du bloc, le type de segment, un répertoire des tables, un répertoire des lignes et
des entrées pour les transactions. La taille de l’en­tête du bloc est variable, de l’ordre de 100 octets à 200 octets. Le
reste du bloc contient les données (une à plusieurs lignes de la table) et de l’espace libre.
L’en­tête est stocké dans la partie haute du bloc et les données sont insérées à partir du bas. L’en­tête est
susceptible de grossir (vers le bas) en fonction de l’activité dans le bloc ; il ne rétrécit jamais. Par exemple, si 100
lignes sont insérées dans le bloc, le répertoire des lignes situé dans l’en­tête grossit ; si les lignes sont ensuite
supprimées, le répertoire des lignes ne rétrécit pas (l’espace est conservé et pourra être réutilisé si des lignes sont
de nouveaux insérées dans le bloc).
Structure d’une ligne
L’en­tête d’une ligne contient quelques informations sur la ligne (nombre de colonnes, chaînage éventuel, verrou). La
taille de l’en­tête de lignes est variable (3 octets minimum). Ensuite, chaque colonne est stockée avec un en­tête de
colonne (qui donne la longueur de la colonne sur 1 à 3 octets) suivi de la valeur de la colonne.
La longueur totale d’une ligne dépend du nombre de colonnes et de la valeur stockée dans chaque colonne, la
longueur de la colonne dépendant du type de données.
Exemple :
Type
Longueur du stockage
CHAR(n)
Longueur fixe (n octets), quelle que soit la valeur stockée dans la
colonne.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
VARCHAR2(n)
Longueur variable (0 à n octets), dépendant de la valeur stockée dans la
colonne.
NUMBER(x,y)
Longueur variable (entre 1 et 21 octets) dépendant de la valeur stockée
dans la colonne.
DATE
Longueur fixe (8 octets).
CLOB, BLOB
Longueur variable, jusqu’à 2^32 blocs Oracle.
Une valeur NULL occupe un octet en milieu de ligne et aucun en fin de ligne.
Les fonctions SQL VSIZE et DUMP appliquées à une valeur (colonne, résultat d’une expression) permettent de
connaître respectivement la taille en octets du stockage interne de la valeur et la représentation interne de la valeur.
Ce qu’il faut retenir, c’est que le bloc ne contient pas que des données utiles ; il y a des données de
contrôle, de surcharge, utilisées en interne par Oracle. À titre d’exemple, une ligne comprenant 3 colonnes
stockant 30 octets de données utiles emploiera en moyenne 35 octets d’espace dans le bloc et une ligne
comprenant 15 colonnes stockant 145 octets de données utiles emploiera en moyenne 160 octets d’espace dans
le bloc.
b. Gestion de l’espace dans les blocs
L’espace libre à l’intérieur du segment peut être géré automatiquement ou manuellement.
Dans le cas de la gestion "manuelle", pour chaque segment, Oracle gère une liste de blocs disponibles pour
l’insertion de lignes (freelist). La disponibilité ou la non­disponibilité d’un bloc pour l’insertion est contrôlée par deux
paramètres de la définition de la table : PCTFREE et PCTUSED.
Dans le cas de la gestion "automatique", pour chaque segment, Oracle utilise une bitmap afin de connaître le taux de
remplissage de chaque bloc alloué au segment et en déduire ceux dans lesquels il peut insérer des données. Dans
ce cas, le paramètre PCTUSED est sans objet. La gestion automatique est apparue en version 9.
La gestion automatique de l’espace dans les segments (Automatic Segment­Space Management ­ ASSM) présente de
nombreux avantages : facilité d’utilisation (pas de paramètre PCTUSED à spécifier), meilleure utilisation de l’espace,
meilleure concurrence d’accès pour les insertions simultanées. La gestion automatique de l’espace dans les
segments est disponible uniquement dans les tablespaces gérés localement et spécifiée au niveau du tablespace
(pas du segment individuel) par la clause SEGMENT SPACE MANAGEMENT AUTO (voir le chapitre Gestion des tablespaces
et des fichiers de données) ; elle est activée par défaut.
PCTFREE
Dans la définition d’une table, le paramètre PCTFREE spécifie le pourcentage de l’espace du bloc laissé libre pour les
modifications des lignes stockées dans le bloc :
La clause PCTFREE permet de ne pas remplir les blocs à 100 % et de conserver de l’espace disponible à l’intérieur du
bloc, pour les futures mises à jour des lignes stockées dans le bloc. En effet, lorsqu’une ligne est modifiée, Oracle
cherche à réaliser la modification en conservant la ligne à l’intérieur du bloc où elle est stockée : cela ne pose pas de
problème si la longueur globale de la ligne diminue (remplacement de PIERRE par PAUL dans une colonne) mais peut
en poser si la ligne grossit (remplacement de PAUL par PIERRE dans une colonne). Dans ce dernier cas, s’il n’y a pas
suffisamment d’espace disponible à l’intérieur du bloc, Oracle va déplacer la ligne dans un autre bloc avec des
impacts négatifs sur les performances que nous verrons dans la suite de cet ouvrage.
Gestion manuelle : PCTUSED
Dans la définition d’une table, en gestion manuelle uniquement, le paramètre PCTUSED spécifie le pourcentage
- 2-
© ENI Editions - All rights reserved - Algeria Educ
d’occupation auquel le bloc doit redescendre avant de redevenir candidat à l’insertion :
Lorsque le bloc atteint un taux de remplissage correspondant à la clause PCTFREE, aucune insertion n’est possible
avant que de l’espace dans le bloc soit libéré, par suppression de ligne ou diminution de la taille d’une ligne lors
d’une modification. Le paramètre PCTUSED permet de contrôler le moment où le bloc redeviendra candidat à
l’insertion, suite à la libération d’espace. Ce paramètre permet d’éviter que le bloc ne redevienne immédiatement
candidat à l’insertion dès que le moindre octet se libère, d’une part, car l’espace libéré n’est peut­être pas suffisant
pour réellement insérer une ligne et d’autre part, car le bloc risque de redevenir non disponible dès la première
insertion ; or, cette gestion interne du bloc (disponible ou non pour l’insertion) est coûteuse en temps de traitement.
PCTUSED va donc permettre d’attendre que suffisamment d’espace ait été libéré dans le bloc avant d’autoriser de
nouvelles insertions dans le bloc.
Gestion automatique
En gestion automatique, Oracle utilise une bitmap pour connaître le taux de remplissage de chaque bloc alloué au
segment : 0 % d’espace libre (plein), entre 0 et 25 % d’espace libre, entre 25 et 50 % d’espace libre, entre 50 et
75 % d’espace libre, entre 75 et 100 % d’espace libre.
Lors de l’insertion d’une nouvelle ligne, Oracle utilisera la bitmap pour déterminer dans quel bloc il peut insérer la
ligne.
Dans la suite de ce chapitre, nous considérerons que la gestion automatique est utilisée. Nous n’évoquerons
pas PCTUSED et ne donnerons aucun conseil sur sa valeur.
c. Compression des données dans les blocs
Depuis Oracle9i Release 2, il est possible de compresser les données dans les blocs des tables.
Avant la version 11, la compression s’effectue uniquement au moment de la création du bloc, lors d’opérations
comme la création d’une table à partir d’une requête (ordre SQL CREATE TABLE ... AS SELECT), la reconstruction
d’une table (ordre SQL ALTER TABLE ... MOVE) ou les insertions en chemin direct (ordre SQL INSERT /*+ APPEND
*/ ...). Pour les insertions ou modifications individuelles ultérieures (ordres SQL INSERT et UPDATE), les données ne
sont pas compressées. Dans ce cas, la compression est plutôt destinée à des tables accédées en lecture, une fois
qu’elles ont été construites ou reconstruites (par exemple, dans une base décisionnelle).
Depuis la version 11, il est possible d’activer la compression pour toutes les opérations, y compris les insertions ou
modifications individuelles. Ce type de compression peut donc aussi être utilisé dans une base transactionnelle.
Cette fonctionnalité, intitulé OLTP Table Compression, nécessite l’option Advanced Compression.
Oracle compresse les données au niveau du bloc en factorisant dans une table de symboles, les valeurs répétées
stockées dans le bloc. Un exemple est donné à la section Réorganiser le stockage d’une table.
2. Le ROWID
Le ROWID est une colonne virtuelle présente dans chaque table qui donne l’adresse physique de stockage de la ligne.
Cette colonne virtuelle peut être interrogée comme les autres colonnes de la table :
SQL> SELECT ROWID, numero, nom, prenom FROM adherent;
SQL> UPDATE adherent SET prenom = ’Olivier’
2 WHERE ROWID = ’AAAER2AACAAADdiAAA’;
Le ROWID permet de localiser physiquement la ligne ; il est utilisé en interne par Oracle dans les index. S’il est connu,
c’est le moyen le plus rapide pour accéder à une ligne.
Dans la structure interne du ROWID, Oracle a toutes les informations nécessaires à la localisation physique de la ligne
dans un fichier de données (fichier, numéro de bloc, position dans le bloc). Un ROWID n’est pas directement
compréhensible ; par contre, le package DBMS_ROWID offre plusieurs fonctions qui permettent d’extraire les différentes
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
composantes du ROWID.
Utiliser le ROWID dans une application (dans les clauses WHERE des ordres SQL) se révèle très intéressant du point de
vue des performances : Oracle obtient directement l’adresse physique de la ligne à lire ou modifier, sans devoir lire
toute la table ni passer par un index.
Le ROWID d’une ligne ne change jamais, tant que la ligne n’est pas supprimée. Modifier une ligne ne change pas son
ROWID puisque la ligne est, a priori, modifiée à l’intérieur du bloc où elle a été insérée ; ce sera aussi le cas si la ligne
est migrée vers un autre bloc par manque d’espace disponible (ce qui n’est pas bénéfique comme nous le verrons ci­
après).
3. Chaînage et migration
En règle générale, une ligne d’une table est stockée en totalité à l’intérieur d’un bloc. Pour lire la ligne, Oracle n’a
besoin de lire qu’un seul bloc.
Si la ligne est intrinsèquement trop grande pour tenir dans un seul bloc, Oracle la stocke dans plusieurs blocs chaînés
par des pointeurs : c’est le phénomène de chaînage d’une ligne. Pour lire cette ligne, Oracle a alors besoin de lire
plusieurs blocs.
Si une ligne grandit suite à une modification, et qu’il ne reste plus suffisamment d’espace libre dans le bloc, Oracle
déplace la ligne dans un autre bloc pointé par l’en­tête de la ligne resté dans le bloc d’origine : c’est le phénomène de
migration d’une ligne. Le ROWID de la ligne modifiée et migrée n’a pas changé, mais pour lire cette ligne, Oracle a
besoin de lire deux blocs, ce qui dégrade les performances des accès par index. L’intérêt de cette technique est
qu’Oracle n’a pas besoin de modifier le ROWID de la ligne dans les index lors d’une mise à jour de la ligne.
Le phénomène de chaînage est difficilement évitable, sauf en augmentant la taille des blocs. Il faut donc y penser lors
de la création de la base de données ou du tablespace. Cela peut être insuffisant pour les très grandes lignes.
Le phénomène de migration peut (et même doit) être évité, en laissant suffisamment d’espace disponible dans les
blocs pour les mises à jour. Le paramètre PCTFREE sera donc positionné avec soin sur les tables pour lesquelles la taille
des lignes insérées est sensiblement inférieure à la taille des lignes après modification(s).
4. Spécifier le stockage d’une table
Le stockage d’une table peut être spécifié lors de la création de la table, dans l’ordre SQL CREATE TABLE.
Syntaxe simplifiée
CREATE TABLE nom_table
(spécification des colonnes)
[ TABLESPACE nom_tablespace ]
[ PCTFREE valeur ]
[ PCTUSED valeur ]
[ clause_stockage ]
[ NOCOMPRESS | COMPRESS [ FOR { ALL | DIRECT_LOAD } OPERATIONS ]]
[ LOGGING | NOLOGGING ] ;
- clause_stockage
STORAGE ( [ INITIAL valeur [K|M] ]
[ NEXT valeur [K|M] ]
[ MINEXTENTS valeur ]
[ MAXEXTENTS { valeur | UNLIMITED } ]
[ PCTINCREASE valeur ] )
Exemple :
CREATE TABLE adherent
(numero
NUMBER(6),
nom
VARCHAR2(40),
prenom
VARCHAR2(30))
TABLESPACE data
PCTFREE 30
STORAGE ( INITIAL 10M ) ;
Les clauses TABLESPACE et STORAGE ont déjà été présentées au chapitre Gestion des tablespaces et des fichiers de
données. N’oubliez pas que la clause STORAGE est traitée différemment selon que le tablespace est géré par le
dictionnaire ou localement. Dans un tablespace géré localement, seule l’option INITIAL est utile.
La clause PCTFREE donne la valeur du PCTFREE (entre 0 et 99, 10 par défaut).
- 4-
© ENI Editions - All rights reserved - Algeria Educ
La clause PCTUSED donne la valeur du PCTUSED (entre 0 et 99, 40 par défaut). Cette clause est ignorée si la table est
stockée dans un tablespace géré localement avec une gestion automatique de l’espace dans les segments.
Par définition, PCTFREE+PCTUSED doit être strictement inférieur à 100.
La clause COMPRESS permet de compresser les données dans les blocs. L’option DIRECT_LOAD indique que les blocs sont
compressés, uniquement lors des opérations de chargement direct (création de la table à partir d’une sous­requête,
reconstruction de la table ou chargement par des insertions en chemin direct) ; c’est la valeur par défaut. L’option ALL
indique que les blocs sont compressés pour toutes les opérations (y compris les insertions ou modifications
individuelles). Par défaut, la table hérite de l’option COMPRESS ou NOCOMPRESS, éventuellement définie au niveau du
tablespace dans lequel elle est stockée.
La clause NOLOGGING permet de ne pas journaliser certaines opérations effectuées sur la table (création à partir d’une
sous­requête et insertion en chemin direct essentiellement) ; les mises à jour individuelles sont, par contre, toujours
journalisées. La clause NOLOGGING est sans effet si la table est stockée dans un tablespace défini en mode FORCE
LOGGING, ou si la base de données elle­même est en mode FORCE LOGGING. Par défaut, la table hérite de l’option
LOGGING ou NOLOGGING, éventuellement définie au niveau du tablespace dans lequel elle est stockée. La clause
NOLOGGING est intéressante pour améliorer les performances de certaines opérations mais rend la table irrécupérable
en cas d’incident ; après une opération NOLOGGING, il est souvent pertinent de réaliser une sauvegarde de la base de
données. L’ordre SQL ALTER TABLEpeut être utilisé pour modifier certaines caractéristiques du stockage de la table.
Syntaxe simplifiée
ALTER TABLE nom_table
[ PCTFREE valeur ]
[ PCTUSED valeur ]
[ NOCOMPRESS | COMPRESS [ FOR { ALL | DIRECT_LOAD } OPERATIONS ] ]
[ LOGGING | NOLOGGING ]
[ clause_stockage_restreinte ] ;
clause_stockage_restreinte
STORAGE ( [ NEXT valeur [K|M] ]
[ MAXEXTENTS { valeur | UNLIMITED } ]
[ PCTINCREASE valeur ] )
L’ordre SQL ALTER TABLE n’a pas d’effet rétroactif sur le stockage déjà alloué à la table. Il n’est donc pas possible, de
cette manière, de changer la table de tablespace, de modifier l’espace initialement alloué à la table ou le remplissage
ou la compression des blocs déjà utilisés.
Les caractéristiques modifiées sont prises en compte uniquement pour les futures opérations. Plus tard, nous
étudierons la clause MOVE de l’ordre SQL ALTER TABLE qui permet de reconstruire physiquement le stockage d’une
table.
5. Recommandations pour le stockage des tables
a. Vue d’ensemble
La recommandation numéro un est de stocker les tables dans un ou plusieurs tablespaces dédiés, de préférence
gérés localement (c’est le cas par défaut) avec une gestion automatique de l’espace dans les segments (c’est le cas
par défaut).
Si cette recommandation numéro un est respectée, vous allez bénéficier de nombreux mécanismes de gestion
automatique du stockage qui permettent éventuellement de ne rien faire de plus. Dans ce cas, utilisez de préférence
des tablespaces gérés localement avec une gestion automatique de la taille des extensions (EXTENT MANAGEMENT
LOCAL AUTOALLOCATE, c’est le cas par défaut).
Néanmoins, si vous le souhaitez ou le pouvez, deux recommandations supplémentaires peuvent être étudiées, au
moins pour les tables les plus importantes de l’application :
●
●
recommandation numéro deux : régler PCTFREE avec soin (voir Estimation de PCTFREE) ;
recommandation numéro trois : allouer un espace initial à la table, adapté à la volumétrie estimée à une
échéance donnée, si possible lointaine (6 mois, 1 an, 2 ans ou plus).
Si vous souhaitez contrôler plus précisément le stockage des tables (ou de certaines tables), vous pouvez utiliser
des tablespaces gérés localement avec une gestion uniforme de la taille des extensions (EXTENT MANAGEMENT LOCAL
UNIFORM) et/ou spécifier avec soin l’option INITIAL de la clause STORAGE.
L’idée est de choisir des caractéristiques de stockage adaptées à la nature de la table (petite, volumineuse,
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 5-
statique, à croissance régulière, etc.) et d’anticiper à une échéance suffisamment lointaine pour être tranquille
pendant quelque temps, et donc avoir le temps nécessaire pour réagir si l’estimation initiale est mauvaise.
Le fait qu’une table soit stockée dans un grand nombre d’extensions ne pose pas de problème du point de
vue des performances.
Par ailleurs, il ne faut pas hésiter à dédier des tablespaces au stockage des tables volumineuses.
Dans un tablespace géré localement avec une gestion automatique de l’espace dans les segments, les
extensions doivent avoir une taille d’au moins 5 blocs.
b. Estimer la volumétrie d’une table à une échéance donnée
La méthode la plus simple (et la plus pragmatique) pour estimer la volumétrie d’une table à une échéance donnée
consiste à :
●
estimer le nombre de lignes attendues ;
●
créer la table dans les conditions d’exploitation (taille de bloc et PCTFREE notamment) ;
●
charger la table avec un jeu de données représentatives ;
●
●
calculer le nombre de blocs occupés par ce jeu d’essai (par exemple à partir des statistiques de la table ou à
l’aide du package DBMS_SPACE ­ voir ci­après) ;
en déduire le nombre de blocs pour le nombre de lignes attendues (règle de trois).
Cette méthode ne donne qu’une estimation, pas un résultat exact à l’octet près, car il y a de nombreuses
incertitudes :
●
●
sur le nombre de lignes estimé à l’échéance (N +/­ 10% par exemple) ;
sur la représentativité du jeu de données, notamment sur la longueur moyenne des données saisies (le nom
du client stocké sous la forme d’un VARCHAR2(80) comprendra­t­il en moyenne 40 caractères, 50, 60 ?).
Supposons par exemple que la table ADHERENT (schéma DIANE) ait été chargée avec 10 000 lignes et qu’elle doive en
contenir 1 000 000 à une échéance de 2 ans. Nous pouvons réaliser le calcul suivant :
SQL> EXEC dbms_stats.gather_table_stats(’DIANE’,’ADHERENT’)
Procédure PL/SQL terminée avec succès.
SQL> SELECT blocks FROM dba_tables
2 WHERE table_name=’ADHERENT’;
BLOCKS
---------138
SQL> SELECT 138/10000*1000000 estimation FROM dual;
ESTIMATION
---------13800
Le jeu de données utilise 138 blocs, donc, par règle de trois, nous pouvons estimer que la table utilisera 13 800
blocs dans deux ans.
L’utilisation du package DBMS_STATS sera présenté à la section Superviser l’espace occupé par une table.
En production, un calcul de ce genre peut être effectué à intervalles réguliers pour voir la tendance et vérifier
si les hypothèses de départ étaient bonnes.
- 6-
© ENI Editions - All rights reserved - Algeria Educ
c. Estimation de PCTFREE
Avec calcul
La valeur optimale de PCTFREE peut être estimée par la formule suivante :
PCTFREE = 100 x (1 -Ti / Tf)
Ti = taille moyenne initiale de la ligne en octets (au moment de l’insertion) ;
Tf = taille moyenne finale de la ligne en octets (après les mises à jour).
Les valeurs de Ti et Tf peuvent être estimées à partir des statistiques de la table (AVG_ROW_LEN). Cette formule est
surtout destinée à calculer la valeur de PCTFREE concernant les tables pour lesquelles, la taille des lignes insérées
initialement n’est pas représentative de la taille finale de la ligne après modification(s). Pour les autres tables,
l’estimation sans calcul, présentée ci­après, peut être utilisée.
Sans calcul
Pour une table "statique" ou faisant uniquement l’objet d’insertions, mettre un PCTFREE faible pour obtenir un bon
remplissage des blocs (0 à 5). Pour une table faisant l’objet d’insertion et de mises à jour, mettre un PCTFREE plus
élevé pour éviter les phénomènes de migration (10 à 50 en fonction du risque que les mises à jour fassent grossir
plus ou moins les lignes).
6. Surveiller l’utilisation d’une table
En version 9, Oracle a introduit une fonctionnalité permettant de mettre une table "sous surveillance". Dans ce mode,
Oracle trace le nombre approximatif d’ordres SQL INSERT, UPDATE et DELETE exécutés sur la table.
En version 9, cette fonctionnalité devait être activée explicitement ; depuis la version 10, les tables sont, par défaut,
sous surveillance (sauf si le paramètre STATISTICS_LEVEL est égal à BASIC, ce qui est déconseillé).
Ce mécanisme de surveillance est avant tout destiné à la fonctionnalité de calcul automatique des statistiques ; les
informations ainsi collectées permettent à Oracle de déterminer les tables dont les statistiques ne sont plus à jour.
Ce mécanisme de surveillance peut aussi être utilisé pour analyser l’activité sur les tables et identifier les tables les
plus sollicitées en mise à jour ; ce sont les tables sur lesquelles vous devez plus particulièrement porter votre
attention en ce qui concerne le stockage (réglage de PCTFREE notamment).
Les informations sur les tables surveillées peuvent être consultées dans la vue DBA_TAB_ MODIFICATIONS (et
consœ urs).
Les principales colonnes de la vue sont les suivantes :
TABLE_OWNER
propriétaire de la table.
TABLE_NAME
nom de la table.
INSERTS
nombre approximatif de lignes insérées.
UPDATES
nombre approximatif de lignes modifiées.
DELETES
nombre approximatif de lignes supprimées.
TIMESTAMP
date/heure de la dernière mise à jour de la statistique.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 7-
TRUNCATED
indication pour savoir si la table a été tronquée (YES ou NO).
Les statistiques sur l’utilisation d’une table ne sont pas déversées en temps réel dans le dictionnaire. Le délai
annoncé est entre quelques secondes et plusieurs heures. La colonne TIMESTAMP de la vue DBA_TAB_MODIFICATIONS
permet de connaître la fraîcheur de l’information.
Au besoin, la procédure FLUSH_DATABASE_MONITORING_INFO du packageDBMS_ STATS peut être utilisée pour forcer la mise
à jour immédiate du dictionnaire.
Il faut bien noter que les statistiques de surveillance sont supprimées lors de la génération des statistiques. Les
statistiques de surveillance sont donc collectées et cumulées depuis la dernière génération de statistiques sur la table
(voir la colonne LAST_ANALYZED de la vue DBA_TABLES).
Pour une bonne analyse, il est important de réaliser des relevés périodiques afin de voir l’évolution de l’activité et
identifier d’éventuelles périodes de pointes.
7. Superviser l’espace occupé par une table
a. Vue d’ensemble
Les vues DBA_SEGMENTS et DBA_EXTENTS présentées au chapitre Gestion des tablespaces et des fichiers de données
permettent de voir l’espace global alloué à la table, mais elles ne donnent pas d’informations sur le nombre de blocs
réellement utilisés.
Pour chaque table (et plus généralement chaque segment), Oracle connaît le dernier bloc utilisé par la table : c’est la
high water mark (HWM ­ "ligne de plus hautes eaux").
La HWM augmente lors des insertions mais ne diminue pas lors des suppressions :
La HWM permet donc de connaître le nombre total maximum de blocs utilisés par la table dans toute son existence,
mais pas le nombre de blocs actuellement utilisés, ni leur remplissage.
La HWM marque pour Oracle l’emplacement du dernier bloc où il est susceptible de trouver une ligne ; au­delà de la
HWM, une seule chose est sûre, il n’y a pas de ligne. Lorsque Oracle réalise un parcours complet de la table, il ne
parcourt pas tous les blocs alloués à la table mais uniquement ceux situés sous la HWM.
Pour obtenir des informations plus détaillées sur le stockage d’une table, vous pouvez utiliser le package DBMS_SPACE.
Ce dernier propose plusieurs procédures qui permettent notamment de calculer des informations sur l’espace libre et
l’espace utilisé à l’intérieur d’un segment.
Par ailleurs, pour les besoins de l’optimiseur, Oracle calcule périodiquement des statistiques sur les tables (et les
index), à l’aide du package DBMS_STATS ; certaines de ces statistiques donnent des informations relatives au
stockage.
Pour obtenir des informations plus détaillées sur le stockage d’une table, vous pouvez utiliser les statistiques de la
table, générées par le package DBMS_STATS ou calculer des informations à l’aide du package DBMS_SPACE.
b. Le package DBMS_SPACE
Le package DBMS_SPACE propose plusieurs procédures qui peuvent être utilisées pour superviser le stockage d’une
table (plus généralement d’un segment) :
FREE_BLOCKS
informations sur les blocs libres dans un segment dont l’espace est géré manuellement.
SPACE_USAGE
informations sur l’occupation des blocs dans un segment dont l’espace est géré automatiquement.
- 8-
© ENI Editions - All rights reserved - Algeria Educ
UNUSED_SPACE
informations sur les blocs inutilisés d’un segment.
Le package DBMS_SPACE possède d’autres procédures ou fonctions qui permettent d’estimer la taille d’une table ou
d’un index ou la tendance de croissance d’un segment. Ces procédures et fonctions, plus complexes à utiliser, ne
sont pas présentées dans cet ouvrage. Par contre, nous présenterons leur utilisation à travers l’interface graphique
du Database Control.
Pour plus d’informations sur le package DBMS_SPACE, reportez­vous à la documentation PL/SQL Packages and Types
Reference.
Exemple :
SQL> SET SERVEROUTPUT ON
SQL> DECLARE
2
v_unformatted_blocks NUMBER;
3
v_unformatted_bytes NUMBER;
4
v_fs1_blocks
NUMBER;
5
v_fs1_bytes
NUMBER;
6
v_fs2_blocks
NUMBER;
7
v_fs2_bytes
NUMBER;
8
v_fs3_blocks
NUMBER;
9
v_fs3_bytes
NUMBER;
10
v_fs4_blocks
NUMBER;
11
v_fs4_bytes
NUMBER;
12
v_full_blocks
NUMBER;
13
v_full_bytes
NUMBER;
14
PROCEDURE p(v_texte VARCHAR2) IS
15
BEGIN
16
dbms_output.put_line(v_texte);
17
END;
18 BEGIN
19
dbms_space.space_usage
20
(
21
segment_owner
=> ’DIANE’,
22
segment_name
=> ’ADHERENT’,
23
segment_type
=> ’TABLE’,
24
unformatted_blocks => v_unformatted_blocks,
25
unformatted_bytes => v_unformatted_bytes,
26
fs1_blocks
=> v_fs1_blocks,
27
fs1_bytes
=> v_fs1_bytes,
28
fs2_blocks
=> v_fs2_blocks,
29
fs2_bytes
=> v_fs2_bytes,
30
fs3_blocks
=> v_fs3_blocks,
31
fs3_bytes
=> v_fs3_bytes,
32
fs4_blocks
=> v_fs4_blocks,
33
fs4_bytes
=> v_fs4_bytes,
34
full_blocks
=> v_full_blocks,
35
full_bytes
=> v_full_bytes
36
);
37
p(’Blocs :’);
38
p(’. Pleins
= ’||v_full_blocks);
39
p(’. 0 à 25% d’’espace libre = ’||v_fs1_blocks);
40
p(’. 25 à 50% d’’espace libre = ’||v_fs2_blocks);
41
p(’. 50 à 75% d’’espace libre = ’||v_fs3_blocks);
42
p(’. 75 à 100% d’’espace libre = ’||v_fs4_blocks);
43
p(’. Non formatés
= ’||v_unformatted_blocks);
44 END;
45 /
Blocs :
. Pleins
= 128
. 0 à 25% d’espace libre = 0
. 25 à 50% d’espace libre = 40
. 50 à 75% d’espace libre = 4
. 75 à 100% d’espace libre = 33
. Non formatés
= 0
Procédure PL/SQL terminée avec succès.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 9-
SQL> DECLARE
2
v_total_blocks
NUMBER;
3
v_total_bytes
NUMBER;
4
v_unused_blocks
NUMBER;
5
v_unused_bytes
NUMBER;
6
v_last_extent_file
NUMBER;
7
v_last_extent_block NUMBER;
8
v_last_used_block
NUMBER;
9
PROCEDURE p(v_texte VARCHAR2) IS
10
BEGIN
11
dbms_output.put_line(v_texte);
12
END;
13 BEGIN
14
dbms_space.unused_space (
15
segment_owner
=> ’DIANE’,
16
segment_name
=> ’ADHERENT’,
17
segment_type
=> ’TABLE’,
18
total_blocks
=> v_total_blocks,
19
total_bytes
=> v_total_bytes,
20
unused_blocks
=> v_unused_blocks,
21
unused_bytes
=> v_unused_bytes,
22
last_used_extent_file_id => v_last_extent_file,
23
last_used_extent_block_id => v_last_extent_block,
24
last_used_block
=> v_last_used_block
25
);
26
p(’Blocs :’);
27
p(’. Total
= ’||v_total_blocks);
28
p(’. Inutilisés
= ’||v_unused_blocks);
29
p(’. Utilisés
= ’||(v_total_blocks-v_unused_blocks));
30 END;
31 /
Blocs :
. Total
= 224
. Inutilisés
= 7
. Utilisés
= 217
Procédure PL/SQL terminée avec succès.
SQL> SELECT blocks FROM dba_segments
2 WHERE segment_name=’ADHERENT’ AND owner=’DIANE’;
BLOCKS
-----------224
Sur cet exemple, nous voyons que la table ADHERENT a 224 blocs alloués. Sur ces 224 blocs, 217 sont utilisés (c’est la
HWM) et 7 sont inutilisés (jamais aucun ligne insérée à l’intérieur). Sur les blocs utilisés, il y en a 128 qui sont pleins,
40 qui ont entre 25 et 50% d’espace libre, 4 qui ont entre 50 et 75% d’espace libres et 33 qui ont entre 75 et 100%
d’espace libre, soit un total de 205 blocs. Les 12 blocs manquants pour arriver à 217 sont des blocs de bitmap
utilisés pour la gestion automatique (ils ne sont pas comptabilisés par la procédure SPACE_USAGE).
c. Les statistiques sur une table
La procédure GATHER_TABLE_STATS du package DBMS_STATS permet de calculer des statistiques sur une table.
Cette procédure a deux paramètres obligatoires en entrée :
ownname
Nom du schéma propriétaire de la table.
tabname
Nom de la table.
Exemple :
EXECUTE dbms_stats.gather_table_stats(’DIANE’,’ADHERENT’)
La procédure GATHER_TABLE_STATS a beaucoup d’autres paramètres dont la valeur par défaut est généralement
- 10 -
© ENI Editions - All rights reserved - Algeria Educ
adaptée.
Au point Les statistiques et l’optimiseur Oracle, nous verrons que les statistiques sont calculées automatiquement
par Oracle à intervalles réguliers. En temps normal, il n’est donc pas nécessaire d’utiliser cette procédure. Générer
manuellement des statistiques peut, par contre, s’avérer utile si vous venez de créer et de charger une table, ou
après une mise à jour massive des données d’une table (insertion, modification, suppression).
Le calcul de statistiques est effectué sur un échantillon des données. La taille de l’échantillon est choisie
automatiquement par Oracle en fonction des caractéristiques de la table (au besoin, la taille de l’échantillon peut
être spécifiée grâce au paramètre estimate_percent).
Historiquement, les statistiques peuvent aussi être calculées à l’aide des clauses COMPUTE ou ESTIMATE de
l’ordre SQL ANALYZE TABLE. Cette possibilité est maintenue pour des raisons de compatibilité ascendante.
Pour calculer les statistiques sur les tables et les index, il faut utiliser le package DBMS_STATS (depuis Oracle8i).
Les statistiques d’une table peuvent être consultées dans la vueDBA_TABLES (et "consœ urs") :
NUM_ROWS
Nombre de lignes dans la table.
BLOCKS
Nombre de blocs sous la High Water Mark (HWM).
AVG_ROW_LEN
Longueur moyenne d’une ligne, y compris les informations d’en­tête.
SAMPLE_SIZE
Nombre de lignes dans l’échantillon utilisé pour le calcul des statistiques.
LAST_ANALYZED
Date/heure de la dernière analyse de la table.
La valeur BLOCKS est toujours exacte, même si les statistiques ne sont pas calculées sur la totalité de la
table.
Exemple :
SQL> EXEC dbms_stats.gather_table_stats(’DIANE’,’ADHERENT’)
Procédure PL/SQL terminée avec succès.
SQL> SELECT num_rows,blocks,avg_row_len,sample_size,
2
TO_CHAR(last_analyzed,’DD/MM HH24:MI’) last_analyzed
3 FROM dba_tables WHERE table_name=’ADHERENT’ and owner=’DIANE’;
NUM_ROWS
BLOCKS AVG_ROW_LEN SAMPLE_SIZE LAST_ANALYZED
---------- ---------- ----------- ----------- ------------11488
217
91
11488 20/07 15:47
Nous retrouvons les 217 blocs utilisés, calculés à l’aide du package DBMS_SPACE.
d. Problèmes possibles sur le stockage
Les problèmes possibles sur le stockage d’une table sont les suivants :
●
espace inutilisé alloué à une table ;
●
faible taux d’occupation moyen des blocs.
Espace inutilisé alloué à une table
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 11 -
Il y a de l’espace inutilisé alloué à la table si le nombre de blocs occupés (sous la HWM) est faible par rapport au
nombre de blocs alloués, et si la table ne va plus grossir (ou peu).
Le nombre de blocs occupés est donné par la valeur de la colonne BLOCKS de la vue DBA_TABLES (ou par un calcul à
l’aide du package DBMS_SPACE) et le nombre de blocs alloués par la valeur de la colonne BLOCKS de la vue
DBA_SEGMENTS.
Exemple :
SQL> SELECT t.blocks "occupés",s.blocks "alloués"
2 FROM dba_tables t, dba_segments s
3 WHERE
s.segment_name=t.table_name
4
AND s.owner=t.owner
5
AND t.table_name=’ADHERENT’ AND t.owner=’DIANE’;
occupés
alloués
---------- ---------217
224
Ce premier problème n’a pas d’incidence sur les performances (les blocs au­delà de la HWM ne sont jamais lus) ; il
conduit juste à un gaspillage d’espace disque.
Faible taux d’occupation moyen des blocs
Pour les tables dont l’espace est géré automatiquement, le taux d’occupation moyen des blocs peut être analysé à
l’aide du résultat donné par la procédure SPACE_USAGE du package DBMS_SPACE.
Exemple :
Blocs :
. Pleins
= 71
. 0 à 25% d’espace libre = 0
. 25 à 50% d’espace libre = 38
. 50 à 75% d’espace libre = 31
. 75 à 100% d’espace libre = 65
. Non formatés
= 0
Dans cet exemple, nous voyons que la table a 71 blocs pleins, 38 blocs moyennement remplis et 96 faiblement
remplis.
Si la proportion de blocs moyennement remplis ou faiblement remplis est importante, si les lignes actuelles ne vont
pas grossir, et si peu de nouvelles lignes vont être insérées, nous pouvons considérer qu’il y a un problème de
remplissage des blocs.
Ce mauvais remplissage des blocs peut être lié à une valeur inadaptée de PCTFREE ou à une suppression importante
de données.
Ce deuxième problème a des incidences sur les performances et sur l’utilisation de l’espace dans le Database Buffer
Cache. Pour un nombre de lignes donné, un taux de remplissage élevé nécessite moins de blocs pour le stockage,
donc moins de blocs à lire et moins de blocs dans le Database Buffer Cache.
8. Détecter les problèmes de migration ou de chaînage
La clause LIST CHAINED ROWS de l’ordre SQL ANALYZE TABLE permet d’identifier les lignes migrées ou chaînées.
Syntaxe
ANALYZE TABLE nom_table LIST CHAINED ROWS;
Au préalable, la table CHAINED_ROWS doit être créée à l’aide du scriptutlchain.sql, qui se trouve dans le répertoire %
ORACLE_HOME%\rdbms\admin ou $ORACLE_ HOME/rdbms/admin. Après exécution de l’ordre SQL ANALYZE, cette table
contient les ROWID des lignes migrées ou chaînées.
Exemple :
SQL> @?\rdbms\admin\utlchain.sql
Table créée.
SQL> ANALYZE TABLE diane.adherent LIST CHAINED ROWS;
Table analysée.
- 12 -
© ENI Editions - All rights reserved - Algeria Educ
SQL> SELECT COUNT(head_rowid) FROM chained_rows
2 WHERE table_name=’ADHERENT’ AND owner_name=’DIANE’;
COUNT(HEAD_ROWID)
----------------16
SQL> SELECT head_rowid FROM chained_rows
2 WHERE table_name=’ADHERENT’ AND owner_name=’DIANE’
3
AND ROWNUM = 1;
HEAD_ROWID
-----------------AAACmIAAKAAAA3sAAf
SQL> SELECT * FROM diane.adherent
2 WHERE ROWID = ’AAACmIAAKAAAA3sAAf’;
...
La table CHAINED_ROWS contient notamment les colonnes suivantes :
OWNER_NAME
Nom du schéma propriétaire de la table analysée.
TABLE_NAME
Nom de la table analysée.
HEAD_ROWID
ROWID de la ligne qui a un problème de migration ou de chaîne.
ANALYZE_TIMESTAMP
Date/heure de l’analyse.
Dans la table CHAINED_ROWS, l’analyse stocke le ROWID des lignes qui ont un problème de chaînage ou de migration ; à
l’aide d’une sous­requête, il est possible de lister les lignes proprement dites. Les résultats s’accumulent dans la
table ; lors d’une nouvelle analyse d’une table préalablement analysée, il convient dont de supprimer de CHAINED_ROWS
l’ancien résultat ou d’utiliser la colonne ANALYZE_TIMESTAMP pour extraire le résultat.
Pour savoir s’il s’agit d’un problème de chaînage ou de migration, il faut interroger la ligne. Si la ligne est plus courte
que la taille du bloc, il s’agit d’un problème de migration (la ligne pourrait tenir dans un bloc) ; si la ligne est plus
longue que la taille du bloc, il s’agit d’un problème de chaînage. La statistique AVG_ROW_LEN dans DBA_TABLES donne
une indication a priori ; si la longueur moyenne des lignes est assez largement inférieure à la taille de bloc, il s’agit
sûrement d’un problème de migration.
Déterminer à partir de quel pourcentage de lignes chaînées ou migrées il faut agir n’est pas simple. Le pourcentage en
soi n’est pas suffisant ; cela dépend aussi de l’activité qui existe sur les lignes en question. S’il y a 90 % de lignes
migrées ou chaînées mais que ces lignes ne sont jamais interrogées, il n’y a pas de problème de performance ; à
l’inverse, s’il n’y a que 1 % de lignes migrées ou chaînées mais que ces lignes soient utilisées dans toutes les
requêtes, il risque d’y avoir un problème de performance.
9. Réorganiser le stockage d’une table
a. Vue d’ensemble
Les besoins de réorganisation d’une table sont variés :
●
libérer de l’espace libre au­dessus de la HWM ;
●
améliorer le taux de remplissage des blocs ;
●
corriger un problème de migration ;
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 13 -
●
réorganiser plus globalement le stockage de la table : changement de tablespace, réduction du nombre
d’extensions, changement de PCTFREE, etc.
Libérer de l’espace situé au­dessus de la HWM permet de récupérer de l’espace alloué à la table mais jamais utilisé
(et estimé jamais utilisable).
Améliorer le taux de remplissage des blocs permet aussi éventuellement de libérer de l’espace inutilisé (l’espace libre
des blocs), situé cette fois au­dessous de la HWM.
Plusieurs techniques sont à notre disposition pour réorganiser le stockage d’une table :
●
ordre SQL ALTER TABLE ... DEALLOCATE UNUSED ;
●
recréer la table / des lignes de la table ;
●
export/import ;
●
ordre SQL ALTER TABLE ... SHRINK SPACE ;
●
ordre SQL ALTER TABLE ... MOVE.
Le tableau suivant résume les techniques envisageables (√) et indique lesquelles sont les mieux adaptées (☺) à tel
ou tel besoin :
DEALLOCATE
Recréer
Export/
Import
SHRINK
MOVE
☺
√
√
√
√
Améliorer le taux de
remplissage des blocs
√
√
☺
☺
Corriger un problème
de migration
☺
√
☺
Réorganisation plus
globale
√
√
☺
Libérer de l’espace au­
dessus de la HWM
À l’exception de l’ordre SQL ALTER TABLE ... DEALLOCATE UNUSED, les techniques citées peuvent a priori être utilisés
indifféremment pour régler les différents problèmes ; néanmoins, certaines techniques sont mieux adaptées que
d’autres à tel ou tel besoin.
Historiquement, l’export/import est la technique de base pour les réorganisations un peu massives ; c’est d’ailleurs
toujours la bonne technique pour une réorganisation complète de la base, notamment en cas de changement de la
taille du bloc.
Pour le reste, les ordres SQL ALTER TABLE ... MOVE (depuis la 8i) et ALTER TABLE ... SHRINK SPACE (depuis la 10)
sont a priori les bons outils pour "reconstruire" une table.
b. L’ordre SQL ALTER TABLE ... DEALLOCATE UNUSED
L’ordre SQL ALTER TABLE ... DEALLOCATE UNUSED permet de libérer l’espace d’une table situé au­dessus de la HWM.
Syntaxe
ALTER TABLE nom_table DEALLOCATE UNUSED [ KEEP valeur [K|M] ] ;
Exemple :
ALTER TABLE adherent DEALLOCATE UNUSED;
ALTER TABLE adherent DEALLOCATE UNUSED KEEP 0;
ALTER TABLE adherent DEALLOCATE UNUSED KEEP 1M;
L’option KEEP indique l’espace à conserver au­dessus de la HWM.
- 14 -
© ENI Editions - All rights reserved - Algeria Educ
Sans clause KEEP, la taille initiale de la table est préservée : l’ordre ne libérera pas d’espace si la HWM est inférieure
à la taille initiale de la table (valeur de la colonne INITIAL_EXTENT de la vue DBA_SEGMENTS).
Avec la clause KEEP, l’espace spécifié est conservé (éventuellement aucun avec KEEP 0) et la taille initiale de la table,
éventuellement ajustée dans le dictionnaire de données.
Par ailleurs, lorsque la table est stockée dans un tablespace géré localement, avec une gestion uniforme des
extensions, Oracle ne libérera que des extensions entières ; une extension ne peut pas être "coupée" en deux. Si la
table est stockée dans un tablespace géré localement, avec une gestion automatique des extensions, Oracle peut
"couper" une extension en tenant compte des règles internes qu’il applique sur la taille des extensions.
L’espace libéré est rendu disponible pour d’autres segments (vue DBA_FREE_SPACE).
Cet ordre ne peut pas être utilisé pour libérer de l’espace au­dessous de la HWM (espace potentiel libre
suite à des suppressions de lignes, par exemple).
c. Recréer la table ou des lignes de la table
Supprimer la table puis la récréer permet évidemment d’en réorganiser le stockage.
Au préalable, il faudra sauvegarder les données dans une table de travail (ordre SQL CREATE TABLE ... AS SELECT).
Cette méthode présente un inconvénient majeur : les objets dépendants sont supprimés (triggers, contraintes,
privilèges, index) ou invalidés (procédures stockées, vues). Il faut donc bien penser à tout recréer avec la table.
Exemple :
-- créer une table de travail avec les bonnes clauses de stockage
CREATE TABLE temp
TABLESPACE ...
PCTFREE ...
STORAGE ...
AS SELECT * FROM adherent;
DROP TABLE adherent;
RENAME temp TO adherent;
-- recréer les objets dépendants
La table étant recréée avec de bonnes clauses de stockage, cette variante peut être utilisée pour réorganiser
complètement le stockage de la table, améliorer le taux de remplissage des blocs, résoudre un problème de
migration. Par contre, il faut penser à recréer tous les objets dépendants et remettre les droits. De plus, le
traitement peut être long sur une table volumineuse.
Une première variante possible consiste à ne pas supprimer la table mais à la tronquer (ordre SQL TRUNCATE
TABLE) ; dans ce cas, les objets dépendants sont préservés.
Exemple :
CREATE TABLE temp AS SELECT * FROM adherent;
TRUNCATE TABLE adherent;
INSERT INTO adherent SELECT * FROM temp;
Cette variante offre moins de possibilités pour la réorganisation puisque la table n’est pas recréée ; néanmoins, elle
permet d’améliorer le taux de remplissage des blocs (de libérer de l’espace sous la HWM) et de résoudre un
problème de migration. La table n’étant pas supprimée, il n’y a pas de difficulté avec les objets dépendants.
Par contre, il n’est pas possible de tronquer une table qui possède une contrainte de clé primaire référencée par
ailleurs ; il faut au préalable désactiver les contraintes de clé étrangère concernées. De plus, lors de l’insertion, les
contraintes d’intégrités sont vérifiées et les triggers sont déclenchés, ce qui peut aussi poser des problèmes : là
encore, il convient de désactiver les contraintes et/ou les triggers qui posent des difficultés.
Une autre variante, utilisable pour corriger un problème de migration sur un petit nombre de lignes, consiste à ne
supprimer et recréer que les lignes fautives. La table n’étant pas supprimée, il n’y a pas de problème avec les objets
dépendants. Par contre, là encore, cette méthode peut poser des difficultés avec les contraintes de clé étrangère et
les triggers.
Exemple :
CREATE TABLE temp AS SELECT * FROM adherent WHERE ...;
DELETE FROM TABLE adherent WHERE ...;
INSERT INTO adherent SELECT * FROM temp;
Pour ces différentes variantes, les outils d’export/import peuvent être utilisés pour sauvegarder les données puis les
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 15 -
réinsérer.
Dans la pratique, aucune de ces différentes variantes n’est vraiment simple à mettre en œ uvre. De plus, avec les
deux premières variantes, la table n’est pas disponible pendant la réorganisation.
d. L’ordre SQL ALTER TABLE ... SHRINK SPACE
L’ordre SQL ALTER TABLE ... SHRINK SPACE permet de compacter les lignes d’une table, mais uniquement pour une
table stockée dans un tablespace géré localement avec une gestion automatique de l’espace dans les segments. Par
défaut, Oracle compacte aussi le segment, ajuste la HWM et libère l’espace ainsi récupéré.
Syntaxe
ALTER TABLE nom_table SHRINK SPACE [COMPACT] [CASCADE] ;
Avec l’option COMPACT, Oracle se contente de compacter les lignes, mais sans ajuster la HWM ni libérer d’espace.
L’exécution ultérieure d’un autre ordre SQL ALTER TABLE ... SHRINK SPACE permettra de terminer l’opération.
L’option CASCADE permet de réaliser la même opération sur les segments dépendants de la table, notamment les
index.
Cette opération nécessite un déplacement des lignes et donc une modification du ROWID des lignes déplacées. Par
défaut, un tel déplacement n’est pas autorisé. Pour autoriser le déplacement des lignes de la table, vous pouvez
exécuter l’ordre SQL ALTER TABLE nom_table ENABLE ROW MOVEMENT. Lors du déplacement des lignes et de la
modification du ROWID, Oracle met à jour les index.
L’opération de SHRINK peut être effectuée en ligne et des mises à jour parallèles sont possibles ; un verrou exclusif
est posé sur la table uniquement au moment du compactage du segment proprement dit (déplacement de la HWM et
libération de l’espace récupéré).
Le compactage du segment peut poser des problèmes si des longues requêtes de lecture sont en cours sur la
table ; c’est la raison pour laquelle il est possible de dissocier les deux phases du traitement.
Exemple
SQL> -- situation de départ
SQL> @dbms_space TEST
Blocs :
. Pleins
= 216
. 0 à 25% d’espace libre = 0
. 25 à 50% d’espace libre = 0
. 50 à 75% d’espace libre = 0
. 75 à 100% d’espace libre = 0
. Non formatés
= 0
Blocs :
. Total
= 256
. Inutilisés
= 28
. Utilisés
= 228
SQL> -- suppression d’une ligne sur deux
SQL> DELETE FROM test WHERE MOD(n,2) = 0;
7655 ligne(s) supprimée(s).
SQL> COMMIT;
Validation effectuée.
SQL> -- la table est pleine de trous !
SQL> @dbms_space TEST
Blocs :
. Pleins
= 0
. 0 à 25% d’espace libre = 0
. 25 à 50% d’espace libre = 2
. 50 à 75% d’espace libre = 214
. 75 à 100% d’espace libre = 0
. Non formatés
= 0
Blocs :
. Total
= 256
. Inutilisés
= 28
. Utilisés
= 228
SQL> -- tentative de SHRINK
SQL> ALTER TABLE test SHRINK SPACE;
- 16 -
© ENI Editions - All rights reserved - Algeria Educ
ALTER TABLE test SHRINK SPACE
*
ERREUR à la ligne 1 :
ORA-10636: ROW MOVEMENT is not enabled
SQL> -- => erreur
SQL> -- il faut autoriser le déplacement de ligne
SQL> ALTER TABLE test ENABLE ROW MOVEMENT;
Table modifiée.
SQL> -- cette fois c’est bon
SQL> ALTER TABLE test SHRINK SPACE;
Table modifiée.
SQL> @dbms_space TEST
Blocs :
. Pleins
= 107
. 0 à 25% d’espace libre = 0
. 25 à 50% d’espace libre = 1
. 50 à 75% d’espace libre = 0
. 75 à 100% d’espace libre = 0
. Non formatés
= 0
Blocs :
. Total
= 120
. Inutilisés
= 2
. Utilisés
= 118
Le script dbms_space.sql appelle les procédures SPACE_USAGE et UNUSED_SPACE du package DBMS_SPACE pour afficher
des informations sur l’espace utilisé dans un segment, dont le nom est passé en paramètre.
Sur cet exemple, nous voyons que le SHRINK SPACE a bien compacté les lignes dans des blocs et libéré l’espace.
e. L’ordre SQL ALTER TABLE ... MOVE
L’ordre SQL ALTER TABLE ... MOVEpermet de réorganiser complètement le stockage physique d’une table sans la
supprimer.
Syntaxe
ALTER TABLE nom_table MOVE
[ TABLESPACE nom_tablespace ]
[ PCTFREE valeur ]
[ clause_stockage ]
[ NOCOMPRESS | COMPRESS [ FOR { ALL | DIRECT_LOAD } OPERATIONS ] ]
[ LOGGING | NOLOGGING ] ;
- clause_stockage
STORAGE ( [ INITIAL valeur [K|M] ]
[ NEXT valeur [K|M] ]
[ MINEXTENTS valeur ]
[ MAXEXTENTS { valeur | UNLIMITED } ]
[ PCTINCREASE valeur ] )
Exemple :
ALTER TABLE adherent MOVE
PCTFREE 20
STORAGE (INITIAL 10M) ;
Les options sont les mêmes que celles de l’ordre SQL CREATE TABLE.L’ordre SQL ALTER TABLE ... MOVE est très
intéressant car toutes les options de stockage peuvent être modifiées, dont le tablespace. De plus, les objets
dépendants sont préservés.
Le principe mis en œ uvre est de recopier physiquement les données des extensions actuellement allouées vers une
ou plusieurs nouvelles extensions allouées ailleurs. Les extensions initiales sont libérées à la fin du traitement : la
table initiale est donc intacte en cas d’échec, mais il faut un espace disponible au moins égal à la taille initiale de la
table pendant la reconstruction.
Les lignes étant physiquement déplacées, les ROWID changent mais les index ne sont pas mis à jour en temps réel
par Oracle ; ils sont invalidés (statut UNUSABLE).Après avoir reconstruit la table, il faudra reconstruire les index (ordre
SQL ALTER INDEX ... REBUILD). De même, les statistiques de la table deviennent invalides et de nouvelles
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 17 -
statistiques doivent être collectées.
Pendant le traitement, la table n’est pas disponible en mise à jour ; par contre, elle est accessible en lecture (le
segment initial est préservé). Cette technique de reconstruction est plus simple à mettre en œ uvre, et donc moins
risquée, que les techniques de recréation. C’est sans conteste LA technique à utiliser depuis la version 8i pour
réorganiser le stockage d’une table (ou d’un tablespace, en réalisant l’opération sur toutes les tables du
tablespace).
Exemple 1
●
Situation de départ
SQL> SELECT tablespace_name,blocks,extents FROM dba_segments
2 WHERE segment_name=’ADHERENT’ AND owner=’DIANE’;
TABLESPACE_NAME
BLOCKS
EXTENTS
------------------------------ ---------- ---------SYSTEM
768
21
SQL> SELECT num_rows,blocks,avg_row_len,sample_size,
2
TO_CHAR(last_analyzed,’DD/MM HH24:MI’) last_analyzed
3 FROM dba_tables WHERE table_name=’ADHERENT’ and owner=’DIANE’;
NUM_ROWS
BLOCKS AVG_ROW_LEN SAMPLE_SIZE LAST_ANALYZED
---------- ---------- ----------- ----------- ------------49907
659
86
49907 20/07 19:20
SQL> SELECT COUNT(head_rowid) FROM chained_rows
2 WHERE table_name=’ADHERENT’ AND owner_name=’DIANE’;
COUNT(HEAD_ROWID)
----------------5894
●
Reconstruction
SQL> ALTER TABLE diane.adherent MOVE
2 TABLESPACE data
3 PCTFREE 20;
●
Situation à l’arrivée (après calcul des statistiques et analyse des lignes chaînées ou migrées)
SQL> SELECT tablespace_name,blocks,extents FROM dba_segments
2 WHERE segment_name=’ADHERENT’ AND owner=’DIANE’;
TABLESPACE_NAME
BLOCKS
EXTENTS
------------------------------ ---------- ---------DATA
1280
1
SQL> SELECT num_rows,blocks,avg_row_len,sample_size,
2
TO_CHAR(last_analyzed,’DD/MM HH24:MI’) last_analyzed
3 FROM dba_tables WHERE table_name=’ADHERENT’ and owner=’DIANE’;
NUM_ROWS
BLOCKS AVG_ROW_LEN SAMPLE_SIZE LAST_ANALYZED
---------- ---------- ----------- ----------- ------------49907
751
86
49907 20/07 19:20
SQL> SELECT COUNT(head_rowid) FROM chained_rows
2 WHERE table_name=’ADHERENT’ AND owner_name=’DIANE’;
COUNT(HEAD_ROWID)
----------------0
Dans la situation de départ, la table ADHERENT présente deux problèmes majeurs :
●
●
- 18 -
Elle est stockée dans le tablespace SYSTEM.
Elle a plus de 10 % de lignes migrées (les lignes sont petites donc il ne s’agit pas d’un problème de
chaînage).
© ENI Editions - All rights reserved - Algeria Educ
La table est donc reconstruite :
●
dans le tablespace DATA ;
●
avec un PCTFREE plus élevé.
Par ailleurs, le tablespace DATA est un tablespace géré localement avec une gestion uniforme des extensions (10 Mo,
soit 1 280 blocs) et une gestion automatique de l’espace dans les segments ; il peut être mieux adapté à la
volumétrie future de la table.
Exemple 2
●
Situation de départ
SQL> SELECT num_rows,blocks,avg_row_len,sample_size,
2
TO_CHAR(last_analyzed,’DD/MM HH24:MI’) last_analyzed
3 FROM dba_tables WHERE table_name=’ADHERENT’ and owner=’DIANE’;
NUM_ROWS
BLOCKS AVG_ROW_LEN SAMPLE_SIZE LAST_ANALYZED
---------- ---------- ----------- ----------- -----------50966
602
86
50966 20/07 19:41
●
Reconstruction avec compression
SQL> ALTER TABLE diane.adherent MOVE
2 COMPRESS;
●
Situation à l’arrivée (après calcul des statistiques)
SQL> SELECT num_rows,blocks,avg_row_len,sample_size,
2
TO_CHAR(last_analyzed,’DD/MM HH24:MI’) last_analyzed
3 FROM dba_tables WHERE table_name=’ADHERENT’ and owner=’DIANE’;
NUM_ROWS
BLOCKS AVG_ROW_LEN SAMPLE_SIZE LAST_ANALYZED
---------- ---------- ----------- ----------- -----------50966
92
86
50966 20/07 19:41
Cet exemple illustre le gain, parfois spectaculaire, obtenu avec la compression.
10. Trouver des informations sur les tables
Plusieurs vues du dictionnaire de données permettent d’obtenir des informations sur les tables :
●
DBA_TABLES : informations sur les tables ;
●
DBA_TAB_COLUMNS : informations sur les colonnes des tables ;
●
DBA_SEGMENTS : informations sur les segments (dont ceux de type table) ;
●
DBA_EXTENTS : informations sur les extensions allouées aux segments (dont ceux de type table) ;
●
DBA_TAB_MODIFICATIONS : informations sur les tables surveillées.
Les vues DBA_SEGMENTS et DBA_EXTENTS ont été présentées à la section Trouver des informations sur les tablespaces et
les fichiers de données du chapitre Gestion des tablespaces et des fichiers de données.
Les colonnes intéressantes des différentes vues sont présentées ci­après.
DBA_TABLES
TABLE_NAME
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 19 -
Nom de la table.
OWNER
Propriétaire de la table.
TABLESPACE_NAME
Nom du tablespace dans lequel la table est stockée.
PCT_FREE
Valeur du PCTFREE.
NUM_ROWS
Nombre de lignes dans la table.
BLOCKS
Nombre de blocs sous la HWM.
AVG_ROW_LEN
Longueur moyenne d’une ligne en octets, en tenant compte des informations de contrôle.
SAMPLE_SIZE
Taille de l’échantillon utilisé lors du calcul des statistiques.
LAST_ANALYZED
Date et heure de la dernière analyse réalisée sur la table.
LOGGING
Indique si le mode LOGGING est actif ou non pour la table (YES ou NO).
COMPRESSION
Indique si la table est compressée (DISABLED ou ENABLED).
TEMPORARY
Indique s’il s’agit d’une table temporaire (Y ou N).
ROW_MOVEMENT
Indique si le déplacement de lignes est autorisé (ENABLED ou DISABLED).
DBA_TAB_COLUMNS
TABLE_NAME
Nom de la table.
OWNER
Propriétaire de la table.
COLUMN_NAME
- 20 -
© ENI Editions - All rights reserved - Algeria Educ
Nom de la colonne.
DATA_TYPE
Type de données.
DATA_LENGTH
Longueur.
DATA_PRECISION
Précision.
DATA_SCALE
Échelle.
NULLABLE
Indique si la colonne accepte les valeurs NULL (Y ou N).
COLUMN_ID
Numéro de la colonne.
DATA_DEFAULT
Valeur par défaut de la colonne.
NUM_DISTINCT *
Nombre de valeurs distinctes dans la colonne.
NUM_NULLS *
Nombre de valeurs NULL dans la colonne.
AVG_COL_LEN *
Longueur moyenne de la colonne.
LAST_ANALYZED *
Taille de l’échantillon utilisé lors du calcul des statistiques.
SAMPLE_SIZE *
Date et heure de la dernière analyse réalisée sur la table.
* Statistiques sur les colonnes, calculées par défaut lorsque les statistiques sont générées sur la table.
DBA_TAB_MODIFICATIONS
TABLE_OWNER
Propriétaire de la table.
TABLE_NAME
Nom de la table.
INSERTS
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 21 -
Nombre approximatif de lignes insérées.
UPDATES
Nombre approximatif de lignes modifiées.
DELETES
Nombre approximatif de lignes supprimées.
TIMESTAMP
Date/heure de la dernière mise à jour de la statistique.
TRUNCATED
Indique si la table a été tronquée (YES ou NO).
- 22 -
© ENI Editions - All rights reserved - Algeria Educ
Gestion des index B­tree
1. Vue d’ensemble
Un index est une structure définie sur une ou plusieurs colonnes d’une table ; la (les) colonne(s) constitue(nt) la clé
de l’index.
L’index permet un accès rapide aux lignes de la table lors d’une recherche basée sur la clé de l’index. La notion
d’index est analogue à celle de l’index d’un livre : pour rechercher un mot dans un livre, il est plus rapide de regarder
d’abord dans l’index, ce dernier donnant les numéros des pages qui contiennent le mot. Un index est physiquement
et logiquement indépendant de la table. Il peut être créé/supprimé sans affecter la table de base (sauf impact sur les
performances lorsque l’index est supprimé). Un index nécessite son propre espace de stockage.
Les index sont automatiquement actualisés et utilisés par Oracle :
●
utilisés lors des recherches si une clé d’index est mentionnée dans la clause WHERE d’une requête ;
●
actualisés à chaque mise à jour (INSERT, UPDATE, DELETE).
La présence ou l’absence d’un index est complètement transparente pour l’application ; c’est Oracle qui utilise (ou
non) les index automatiquement.
La maintenance des index dégrade les performances des mises à jour.
Un index peut être unique ou non unique :
●
Unique: une valeur de la clé d’index n’est présente qu’une fois dans la table.
●
Non unique : une valeur de la clé d’index peut être présente plusieurs fois dans la table.
Oracle préconise de ne pas créer d’index unique explicitement mais de définir des contraintes d’intégrité (PRIMARY KEY
ou UNIQUE) pour lesquelles Oracle crée automatiquement des index uniques. Les index non uniques, par contre,
doivent être créés explicitement.
Un index peut être composé (concaténé). Dans ce cas, la clé d’index contient plusieurs colonnes de la table ; elles ne
sont pas toujours adjacentes dans la table, ni forcément placées dans le même ordre que dans la table.
Les valeurs NULL ne sont pas stockées dans les index B­tree et ne sont donc pas prises en compte vis­à­vis de
l’unicité : deux lignes de la table peuvent avoir la valeur NULL dans la colonne concernée.
2. Structure d’un index B­tree
Structure générale
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Les données sont stockées dans des blocs Oracle.
Les blocs branches (branch blocks) contiennent des données qui pointent vers des blocs de niveau inférieur. Les blocs
branches permettent d’assurer un aiguillage d’un bloc racine vers les blocs feuilles, en éliminant des branches à
chaque niveau.
Les blocs feuilles (leaf blocks) contiennent les différentes valeurs de la clé d’index avec les ROWID des lignes de la table
correspondante. Pour un index unique, il existe un seul ROWID par valeur de clé ; pour un index non unique, plusieurs
ROWID sont possibles pour chaque valeur de clé. Les blocs feuilles pointent vers les lignes de la table.
Lorsque l’index est utilisé pour rechercher une valeur de clé, le bloc racine est lu, puis le bloc feuille de niveau
inférieur correspondant à la branche qui contient la valeur de clé est lu à son tour, et ainsi de suite jusqu’au bloc
feuille qui contient la valeur de clé ; associé à cette valeur de clé, Oracle va trouver le(s) ROWID(s) de la ou les lignes
qui contiennent la valeur de la clé et pouvoir ainsi les lire directement dans la table.
Les blocs feuilles sont doublement chaînés pour faciliter le parcours de l’index.
Les valeurs de clé NULL ne sont pas présentes dans l’index.
Dans les blocs feuilles d’un index non unique, les données sont triées sur la clé puis sur le ROWID ; la valeur de la clé
est répétée à chaque fois.
Structure d’un bloc
À l’image de la table, un bloc d’index comprend les données proprement dites et des informations de contrôle (en­
tête de bloc, en­tête de ligne, etc.).
Le remplissage du bloc, à la création de l’index uniquement, peut être contrôlé par le paramètrePCTFREE. Le
paramètre PCTFREE est donc important lors de la création d’un index sur une colonne non vide. Dans les autres cas,
ou pour la suite de la vie de l’index, le paramètre n’est pas utilisé.
Il n’y a pas de PCTUSED pour les index.
3. Avantages et inconvénients des index B­tree
Avantages
L’index améliore la performance des requêtes (SELECT, UDATE et DELETE) qui utilisent la clé de l’index dans la clause
WHERE.
L’arbre est maintenu équilibré par Oracle. Dans "B­tree", "B" signifie balanced (balancé), c’est­à­dire qu’Oracle
s’arrange pour maintenir son arbre équilibré au fur et à mesure des mises à jour de l’index. Pour cela, Oracle peut
couper des blocs en cas de besoin (notion de split).
En conséquence, toutes les valeurs de la clé dans les blocs feuilles sont situées à la même profondeur de l’arbre et
donc accessibles en parcourant le même nombre de blocs. La recherche de n’importe quelle valeur de clé prend
toujours à peu près le même temps.
Pourquoi un index B­tree est­il performant ?
Prenons l’exemple d’un index sur une date :
- 2-
© ENI Editions - All rights reserved - Algeria Educ
●
●
La longueur d’une ligne de l’index est égale à 8 octets (longueur du type DATE) + 6 octets (longueur du ROWID)
+ quelques octets pour les informations de contrôle (arrondi à 6 octets) = 20 octets.
Avec une taille de bloc (DB_BLOCK_SIZE) de 8 Ko, l’espace disponible dans le bloc est égal à 8 192 octets ­
taille de l’en­tête (entre 100 et 200 octets, prenons 192 octets pour notre exemple) = 8 000 octets, rempli à
90 % = 7 200 octets.
●
Un bloc peut donc stocker environ 7 200 / 20 = 360 clés.
●
Un arbre d’une profondeur de 3 peut donc gérer 360 x 360 x 360 = 466 millions de clés.
●
Pour retrouver une valeur parmi les 466 millions, 3 entrées/sorties sont suffisantes dans l’index plus une
entrée/sortie dans la table afin de lire chaque ligne.
De plus, si les colonnes utilisées dans les différentes clauses de la requête sont toutes présentes dans l’index, Oracle
n’a pas besoin d’accéder à la table. Si un index composé existe sur les colonnes (NOM,PRENOM) de la table ADHERENT, la
requête suivante n’accède pas à la table :
SELECT nom, prenom FROM adherent
WHERE nom = ’HEURTEL’;
Inconvénients
Le premier inconvénient d’un index est qu’il nécessite un volume de stockage important.Le second inconvénient d’un
index est qu’il dégrade les performances des mises à jour. Pour des mises à jour unitaires, cela ne devient sensible
que si la table comprend un grand nombre d’index ; pour une mise à jour massive, cette dégradation est sensible dès
l’existence du premier index. Ces deux inconvénients sont deux bonnes raisons pour ne pas indexer toutes les
colonnes d’une table.
4. Directives pour la création des index B­tree
a. Principes généraux
Les colonnes candidates à l’indexation sont les colonnes fréquemment présentes dans les clauses WHERE, comme
critère de sélection ou de jointure.
En complément, il faut s’assurer que les requêtes correspondantes sont sélectives et ramènent moins de 5 à 10 %
des lignes de la table. Cela implique donc, que les valeurs de la colonne soient relativement uniques (beaucoup de
valeurs distinctes), et que les conditions qui les utilisent soient elles­mêmes sélectives. Il ne faut donc pas indexer
les colonnes ayant peu de valeurs distinctes (la colonne sexe par exemple).
Il est inutile d’indexer les petites tables.
Pour trouver les bonnes colonnes candidates à l’indexation, il faut analyser les requêtes SELECT, UPDATE et DELETE,
et rechercher les colonnes les plus fréquemment utilisées dans les clauses WHERE (critère de sélection et jointure).
La performance d’un index dépend de sa sélectivité intrinsèque et de la sélectivité des requêtes qui l’utilisent. La
sélectivité peut être définie comme, le nombre moyen de lignes ramenées par une requête divisé par le nombre
total de lignes.
Prenons l’exemple de la table ADHERENT comprenant 100 000 personnes avec une répartition homogène
homme/femme. Considérons les clauses WHERE suivantes :
Clause WHERE
Sélectivité
WHERE numero =12345
1 / 100 000 = 0,001 %
WHERE numero BETWEEN 1 AND 20000
20 000 / 100 000 = 20 %
WHERE sexe = ’F’
50 000 / 100 000 = 50 %
Ces exemples montrent que la colonne NUMERO est intrinsèquement sélective mais que certaines requêtes basées
sur cette colonne peuvent ne pas l’être ; par contre, la colonne SEXE n’est pas intrinsèquement sélective.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Une colonne ayant peu de valeurs distinctes est intrinsèquement non sélective. Parmi les colonnes candidates à
l’indexation, il faut donc identifier celles qui sont intrinsèquement sélectives et utilisées dans des requêtes elles­
mêmes sélectives ; une colonne sera effectivement une bonne candidate à l’indexation si la sélectivité (de la
colonne et des requêtes qui l’utilisent) est inférieure à environ 5 à 10 %. Dans les grandes lignes, si une requête
utilisant un index ramène plus de 10 % des lignes, Oracle se révèlera plus performant en réalisant un parcours
complet de la table qu’en passant par l’index.
Cette règle des 5 à 10 % n’est pas en soi une garantie de performance effective de l’index ; de nombreux autres
facteurs entrent en ligne de compte. C’est néanmoins un bon critère de départ, qu’il faut valider en réalisant des
tests.
Parmi les colonnes candidates, il faudra d’abord identifier les colonnes qui sont systématiquement présentes
ensembles dans la clause WHERE : ce sont de bonnes candidates à la création d’un index composé qui est
généralement plus sélectif qu’un index simple. En effet, si les colonnes C1 et C2 d’une table sont fréquemment
utilisées ensembles dans les clauses WHERE et qu’il existe 10 valeurs distinctes pour C1 (sélectivité de 10 %) et 10
valeurs distinctes pour C2 (sélectivité de 10 %), la sélectivité théorique du couple (C1,C2) est de 1 % (dans
l’hypothèse où il n’y a pas de corrélation entre C1 et C2).
Indexer les petites tables ne sert à rien car le nombre minimum d’entrées/sorties lors d’un accès par index est de 2
(1 entrée/sortie au minimum pour l’index et 1 entrée/sortie au minimum pour la table). Or, grâce au
paramètreDB_FILE_MULTIBLOCK_READ_COUNT (DBFMRC ci­après), Oracle peut lire DBFMRC blocs en une entrée/sortie lors
d’un parcours complet de table. Donc, si la taille de la table est inférieure à DBFMRC blocs, un index est moins
performant que le parcours complet ; si la taille de la table est inférieure à 2 x DBFMRC blocs, un index est aussi
performant (mais pas plus) que le parcours complet. Ainsi, en général, indexer des tables comprenant quelques
dizaines de blocs n’apporte rien.
Les valeurs NULL ne sont pas stockées dans les index B­tree ; donc, indexer une colonne pour améliorer les
recherches IS NULL ne sert à rien. Hormis les index uniques, il n’est jamais certain qu’un index soit réellement
performant ; il faut donc le tester. Lors des tests sur les index, il ne faut pas oublier de vérifier si les index ne
dégradent pas trop les performances des mises à jour.
b. Compléments sur les index composés
L’ordre des colonnes est important dans un index composé. Un index composé est utilisé si les colonnes de tête de
la clé d’index sont présentes dans la condition.
Si un index composé existe sur les colonnes (NOM,PRENOM) de la table ADHERENT, les trois requêtes suivantes utilisent
l’index :
SELECT * FROM adherent
WHERE nom = ’HEURTEL’ AND prenom = ’Olivier’;
SELECT * FROM adherent
WHERE prenom = ’Olivier’ AND nom = ’HEURTEL’;
SELECT * FROM adherent
WHERE nom = ’HEURTEL’;
Par contre, la requête suivante n’utilise pas l’index :
SELECT * FROM adherent
WHERE prenom = ’Olivier’;
L’ordre des colonnes n’a pas d’importance dans la clause WHERE.
Dans certains cas, si la première colonne de l’index a très peu de valeurs distinctes (par exemple 2), Oracle
est susceptible de subdiviser l’index en sous­index (un pour chaque valeur de la première colonne) et de
parcourir chaque sous­index.
Dans certaines situations, il peut être intéressant d’ajouter dans la clé d’index des colonnes présentes dans la
clause SELECT, pour éviter d’accéder à la table.
Pour la requête suivante, ajouter la colonne NUMERO_TELEPHONE dans l’index composé qui existe sur les colonnes
(NOM,PRENOM) permet d’éviter l’accès à la table
SELECT numero_telephone FROM adherent
WHERE nom = ’HEURTEL’ AND prenom = ’Olivier’;
Abuser de cette astuce et placer de nombreuses colonnes dans la clé d’index peut rendre l’index moins
performant. Plus la clé d’index est longue, moins il y a de clés par bloc, et plus l’index est volumineux et
- 4-
© ENI Editions - All rights reserved - Algeria Educ
profond, ce qui augmente le nombre d’entrées/sorties pour parcourir l’index.
c. S’assurer que les requêtes sont bien écrites
Par ailleurs, il faut s’assurer que l’écriture des requêtes n’empêche pas l’index d’être utilisé.
Exemples de clauses WHERE où l’index présent sur la colonne nom n’est pas utilisé :
nom IS NULL
Les valeurs NULL ne sont pas dans l’index.
nom NOT IN(’DUPONT’,’DUPOND’)nom < > ’HEURTEL’
Les recherches "différent de" n’utilisent pas l’index.
nom LIKE ’%TEL’
Les recherches LIKE n’utilisent pas l’index si le début de la chaîne n’est pas connu (recherches du type "contient",
"se termine par").
SUBSTR(nom,1,1) =’H’
Et plus généralement, lorsqu’une fonction est appliquée à la colonne, ou que la colonne est utilisée dans une
expression.
Par contre, exemples de clauses WHERE où l’index est utilisé :
nom > ’HEURTEL’
Les recherches de type "inférieur", "supérieur", "entre" utilisent l’index.
nom LIKE ’H%’
Le début de la chaîne est connu.
Ce n’est pas parce qu’une requête n’empêche pas l’utilisation d’un index, que l’index est réellement utilisé.
C’est l’optimiseur Oracle qui décidera d’utiliser ou non un index, en fonction des caractéristiques de la
requête, de la table et des index (c’est un vaste sujet).
5. Spécifier le stockage d’un index
a. Index indépendant
Le stockage d’un index peut être spécifié lors de la création de l’index, dans l’ordre SQL CREATE INDEX.
Syntaxe simplifiée
CREATE [UNIQUE] INDEX nom_index ON nom_table(liste_colonnes)
[ TABLESPACE nom_tablespace ]
[ PCTFREE valeur ]
[ clause_stockage ]
[ ONLINE ]
[ NOCOMPRESS | COMPRESS [n] ]
[ LOGGING | NOLOGGING ] ;
- clause_stockage
STORAGE ( [ INITIAL valeur [K|M] ]
[ NEXT valeur [K|M] ]
[ MINEXTENTS valeur ]
[ MAXEXTENTS { valeur | UNLIMITED } ]
[ PCTINCREASE valeur ] )
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 5-
Exemple :
CREATE INDEX adherent$nom#prenom ON adherent(nom,prenom)
TABLESPACE indx
PCTFREE 20
STORAGE ( INITIAL 2M ) ;
Les clauses TABLESPACE et STORAGE ont déjà été présentées au chapitre Gestion des tablespaces et des fichiers de
données. N’oubliez pas que la clause STORAGE est traitée différemment selon que le tablespace est géré par le
dictionnaire ou localement. Dans un tablespace géré localement, seule l’option INITIAL est utile.
La clause PCTFREE donne la valeur du PCTFREE (entre 0 et 99, 10 par défaut).
La clause ONLINE permet d’autoriser les mises à jour sur la table pendant la construction de l’index.
La clause COMPRESS [n] permet de compresser la clé d’index, uniquement dans le cas d’un index composé. Pour
compresser la clé d’index, Oracle élimine les occurrences répétées des valeurs des colonnes de la clé. L’option n
permet de préciser le nombre de colonnes de la clé à compresser. Par défaut, n est égal au nombre de colonnes
moins un pour un index unique et au nombre de colonnes pour un index non unique. Compresser la clé des index
composés peut permettre de réduire sensiblement la taille de l’index. Pour obtenir un résultat optimal, il faut
compresser sur la portion de tête de la clé comprenant le plus grand nombre de répétitions (cette information peut
être obtenue avec l’ordre SQL ANALYZE INDEX ... VALIDATE STUCTURE présenté plus loin).
La clause NOLOGGING permet de ne pas journaliser la création de l’index ; les mises à jour individuelles sont, par
contre, toujours journalisées. Les considérations sont les mêmes que pour une table (cf. Gestion des tables) mais
un index est moins critique qu’une table ; si un index n’est pas récupérable, il est toujours possible de le
reconstruire.
Il existe aussi un ordre SQL ALTER INDEX mais, comme pour une table, il n’a pas d’effet rétroactif sur ce qui est déjà
alloué ; généralement, en cas de besoin, l’index sera plutôt reconstruit.
b. Index d’une contrainte de clé primaire ou unique
Le stockage de l’index d’une clé primaire ou unique peut être spécifié lors de la définition de la contrainte grâce à
l’option USING INDEX de la clause CONSTRAINT.
Syntaxe
CONSTRAINT nom_contrainte { PRIMARY KEY | UNIQUE } (liste_colonnes)
USING INDEX<$ICONSTRAINT;USING INDEX>
[ spécification_stockage | nom_index | (ordre_création_index) ]
- spécification_stockage
[ TABLESPACE nom_tablespace ]
[ PCTFREE valeur ]
[ clause_stockage ]
[ ONLINE ]
[ NOCOMPRESS | COMPRESS [n] ]
[ LOGGING | NOLOGGING ] ;
●
nom_index : nom d’un index qui existe déjà.
●
ordre_création_index : ordre SQL de création d’index tel que vu précédemment.
Exemple :
●
Définition des clauses de stockage de l’index
ALTER TABLE adherent ADD CONSTRAINT adherent$pk PRIMARY KEY(numero)
USING INDEX
TABLESPACE indx
PCTFREE 0
STORAGE (INITIAL 2M) ;
●
Spécification d’un index déjà existant
ALTER TABLE adherent ADD CONSTRAINT adherent$uk01
UNIQUE (nom,prenom,telephone)
USING INDEX adherent$ix01 ;
- 6-
© ENI Editions - All rights reserved - Algeria Educ
●
Création complète de l’index
ALTER TABLE adherent ADD CONSTRAINT adherent$uk01
UNIQUE (nom,prenom,telephone)
USING INDEX
(
CREATE INDEX adherent$ix01
ON adherent(nom,prenom,telephone)
TABLESPACE indx
PCTFREE 25
STORAGE (INITIAL 10M)
) ;
Par défaut, lorsqu’une contrainte de clé primaire ou de clé unique est créée ou activée, Oracle regarde s’il existe un
index utilisable pour vérifier la contrainte. Cet index peut être unique ou non unique, mais doit posséder une clé
égale à ou commençant par la clé de la contrainte. Si un tel index n’existe pas, Oracle crée un index unique pour
vérifier la contrainte, index dont la clé est égale à la clé de la contrainte. Dans ce cas, l’option USING INDEX de la
clause CONSTRAINT permet de spécifier les caractéristiques de stockage de cet index.
Depuis Oracle9i, la clause USING INDEX peut :
●
mentionner explicitement le nom d’un index à utiliser pour vérifier la contrainte ;
●
inclure un ordre SQL CREATE INDEX pour créer explicitement l’index associé à la contrainte.
Dans les deux cas, les autres options de la clause USING INDEX sont interdites.
L’index mentionné ou créé peut être unique ou non unique mais il doit être "compatible" avec la contrainte de clé
primaire ou unique. Si l’index est unique, la clé de l’index doit être égale à la clé de la contrainte (mêmes colonnes,
dans le même ordre). Si l’index est non unique, la clé de l’index doit être égale à ou commencer par la clé de la
contrainte.
Exemple :
CREATE INDEX adherent$ix01 ON adherent(nom,prenom,telephone)
TABLESPACE indx ;
ALTER TABLE adherent
ADD CONSTRAINT adherent$pk PRIMARY KEY (nom,prenom)
USING INDEX adherent$ix01 ;
Fonctionnellement, créer l’index avant la contrainte et le mentionner dans l’ordre de création de la contrainte
équivaut strictement à créer l’index dans l’ordre de définition de la contrainte.
Utiliser une des deux clauses USING INDEX apparues dans Oracle9i permet :
●
d’être plus explicite ;
●
de désigner un index précis si plusieurs index peuvent être utilisés pour vérifier la contrainte ;
●
de créer un autre index que celui qui serait utilisé par défaut (avec une autre clé) ;
●
●
si aucun index n’existe déjà, de créer un index avec un nom précis, sur une clé précise, généralement plus
"longue" que la clé de la contrainte ;
de créer explicitement un index non unique (voir l’intérêt ci­après).
La vue DBA_CONSTRAINTScontient deux colonnes, INDEX_OWNER et INDEX_NAME, qui permettent de faire le lien
entre une contrainte de clé primaire ou de clé unique et son index associé (vue DBA_INDEXES).
Par défaut, lorsqu’une clé primaire ou unique est supprimée :
●
openmirrors.com
L’index associé est supprimé s’il est unique.
© ENI Editions - All rights reserved - Algeria Educ
- 7-
●
L’index associé est conservé s’il est non unique.
L’origine de l’index (créé par Oracle, déjà existant, créé dans l’ordre de définition de la contrainte) n’a pas d’impact.
Depuis Oracle9i, il est possible d’indiquer explicitement si l’index associé à une contrainte supprimée doit être
conservé ou supprimé.
Syntaxe
ALTER TABLE DROP CONSTRAINT { nom_contrainte | PRIMARY KEY }
KEEP INDEX | DROP INDEX ;
A priori, conserver un index unique lors de la suppression d’une contrainte de clé primaire ou unique n’a pas de
sens : l’unicité est toujours vérifiée au niveau de l’index.
L’approche par défaut d’Oracle est relativement logique. Si une contrainte de clé primaire ou de clé unique est
supprimée, c’est notamment que l’unicité n’est plus souhaitée ; supprimer l’index associé est donc logique. Par
contre, un index non unique ne vérifie pas l’unicité et peut donc être conservé, même lorsque la contrainte est
supprimée.
La nouvelle clause est intéressante pour aller à l’encontre du fonctionnement par défaut : supprimer un index qui
serait conservé ou conserver un index qui serait supprimé. Elle permet aussi d’être plus explicite et de ne pas se
préoccuper du fonctionnement par défaut.
Créer systématiquement des index non uniques pour gérer les contraintes de clé primaire et de clé unique
est intéressant, et laisse en tout état de cause le choix de conserver ou non l’index lors de la suppression
ou de la désactivation de la contrainte.
6. Recommandations pour le stockage des index
a. Vue d’ensemble
Les recommandations sont les mêmes que pour les tables (section Gestion des tables) :
●
●
●
recommandation numéro un (fondamentale) : stocker les index dans un ou plusieurs tablespaces dédiés, de
préférence gérés localement (c’est le cas par défaut) avec une gestion automatique de l’espace dans les
segments (c’est le cas par défaut) ;
recommandation numéro deux (moins importante) : régler PCTFREE avec soin (voir Estimation de PCTFREE),
au moins pour les index les plus importants ;
recommandation numéro trois (moins importante) : allouer un espace initial à l’index, adapté à la volumétrie
estimée à une échéance donnée (pas forcément très lointaine, car très souvent, les index sont reconstruits
à intervalles réguliers).
Définir un index en spécifiant un INITIAL adapté à la volumétrie estimée de l’index, peut améliorer la
performance de création de l’index, en diminuant le nombre d’extensions allouées pendant l’opération.
b. Estimer la volumétrie d’un index à une échéance donnée
Là encore, le plus simple et le plus pragmatique consiste à procéder comme pour une table :
- 8-
●
estimer le nombre de lignes attendues ;
●
créer l’index dans les conditions d’exploitation (taille de bloc et PCTFREE notamment) ;
●
charger la table avec un jeu de données représentatives ;
© ENI Editions - All rights reserved - Algeria Educ
●
●
calculer le nombre de blocs d’index occupés par ce jeu d’essai (par exemple, à partir des statistiques de
l’index ou à l’aide du package DBMS_SPACE, voir ci­après) ;
en déduire le nombre de blocs pour le nombre de lignes attendues (règle de trois).
Supposons, par exemple, que la table ADHERENT (schéma DIANE) ait été chargée avec 10 000 lignes et qu’elle doit en
contenir 250 000 à une échéance de 6 mois. Nous pouvons réaliser le calcul suivant pour un de ces index :
SQL> ANALYZE INDEX adherent$ix01 VALIDATE STRUCTURE;
Index analysé.
SQL> SELECT lf_blks+br_blks FROM index_stats
2 WHERE name=’ADHERENT$IX01’;
LF_BLKS+BR_BLKS
--------------59
SQL> SELECT 59/10000*250000 estimation FROM dual;
ESTIMATION
---------1475
L’index pour le jeu de données utilise 59 blocs, donc par règle de trois, nous pouvons estimer que l’index utilisera 1
475 blocs dans 6 mois.
L’emploi de l’ordre SQL ANALYZE INDEX ... VALIDATE STRUCTURE est présenté plus loin.
c. Estimation de PCTFREE
Vous n’avez pas besoin de vous préoccuper de PCTFREE si la colonne indexée est vide lors de la création de l’index.
Pour mémoire, PCTFREE est pris en compte uniquement à la création de l’index et n’est effectivement utilisé que si la
colonne à indexer est non vide.
Vous pouvez positionner PCTFREE à une valeur faible (éventuellement 0) dans les cas suivants :
●
●
Si l’index est créé sur une colonne qui sera rarement mise à jour (ni UPDATE ni INSERT).
Si l’index est créé sur une colonne qui va continuer à faire l’objet d’insertions avec des valeurs en dehors de
la plage des valeurs actuelles (ces entrées d’index iront dans de nouveaux blocs).
Dans le cas où l’index est créé sur une colonne non vide, l’objectif de PCTFREE est simple : réserver de l’espace dans
les blocs pour les éventuelles futures insertions de clés dans les blocs d’index initialement utilisés (les clés sont
triées dans les blocs feuilles). Si pour une raison quelconque, les futures insertions de clés ne risquent pas de venir
dans les blocs déjà utilisés, il est possible de mettre un PCTFREE faible ou nul.
Vous devez par contre positionner PCTFREE à une valeur élevée dans les cas suivants :
●
●
Si l’index est créé sur une colonne qui sera souvent mise à jour (UPDATE).
Si l’index est créé sur une colonne qui va continuer à faire l’objet d’insertions avec des valeurs appartenant
à la plage des valeurs actuelles (ces entrées viendront s’intercaler dans les blocs existants).
Dans ce cas, PCTFREE peut être estimé par la formule suivante :
PCTFREE = 100 x (1 -Ni / Nf)
Ni = nombre initial de lignes ;
Nf = nombre final de lignes (à une échéance donnée).
Nf est une valeur relativement arbitraire, Nf - Ni étant le nombre de lignes à insérer dans l’index avant que tout
l’espace laissé libre initialement soit occupé (statistiquement), et que Oracle doit commencer à réorganiser son
arbre d’index.
Une valeur arbitraire de PCTFREE peut être utilisée (10 à 20 %), sachant qu’il est facile de superviser le stockage
d’un index et de le reconstruire en cas de besoin.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 9-
Lorsqu’une clé d’index est modifiée, l’entrée correspondante est supprimée et recréée. Lorsque des
entrées sont supprimées dans un bloc d’index, l’espace libéré ne peut être réutilisé que pour des entrées
dont c’est la place (les données sont triées dans les blocs feuilles). Pour pouvoir réutiliser un bloc et y placer des
valeurs complètement différentes, il faut que le bloc soit complètement vide.
7. Superviser l’espace occupé par un index
a. Vue d’ensemble
Là encore, vous trouverez de nombreuses similitudes avec les tables ...
Les vues DBA_SEGMENTS et DBA_EXTENTS présentées au chapitre Gestion des tablespaces et des fichiers de données
permettent de voir l’espace global alloué à l’index, mais elles ne donnent pas d’informations sur le nombre de blocs
réellement utilisés.
Pour obtenir des informations plus détaillées sur le stockage d’un index, vous pouvez :
●
utiliser les informations calculées par le package DBMS_SPACE (voir le point Gestion des tables) ;
●
employer les statistiques générées par le package DBMS_STATS ;
●
utiliser d’autres statistiques calculées par l’ordre SQL ANALYZE INDEX ... VALIDATE STRUCTURE.
Les statistiques générées par le package DBMS_STATS ne sont pas suffisantes pour réaliser une analyse détaillée du
stockage de l’index (mais elles sont suffisantes pour l’optimiseur) ; nous ne les évoquerons donc, pas ici (description
de la vue DBA_INDEXES au point Trouver des informations sur les index).
Nous allons par contre, présenter l’utilisation de l’ordre SQL ANALYZE INDEX ... VALIDATE STRUCTURE.
b. L’ordre SQL ANALYZE INDEX ... VALIDATE STRUCTURE
L’ordre SQL ANALYZE INDEX ... VALIDATE STRUCTURE permet de vérifier l’intégrité de l’index et d’obtenir des
informations détaillées sur le stockage de l’index.
Syntaxe
ANALYZE INDEX nom_index VALIDATE STRUCTURE;
Exemple :
ANALYZE INDEX adherent$ix01 VALIDATE STRUCTURE;
L’ordre SQL ANALYZE INDEX ... VALIDATE STRUCTURE ne vérifie pas la cohérence de l’index vis­à­vis de la table ; pour
vérifier une telle cohérence, il faut ajouter l’option CASCADE. Le résultat peut être consulté dans la vue INDEX_STATS :
NAME
nom de l’index.
HEIGHT
hauteur de l’arbre.
BLOCKS
nombre de blocs alloués au segment.
LF_BLKS
nombre de blocs feuilles dans l’index.
- 10 -
© ENI Editions - All rights reserved - Algeria Educ
BR_BLKS
nombre de blocs branches dans l’index.
LF_ROWS
nombre de lignes (valeurs) dans l’index.
DEL_LF_ROWS
nombre de lignes supprimées dans l’index.
PCT_USED
pourcentage de l’espace alloué à l’index qui est utilisé (entre 0 et 100).
OPT_CMPR_COUNT
Nombre de colonnes de la clé d’index à utiliser pour avoir une compression optimale.
OPT_CMPR_PCTSAVE
Pourcentage d’espace qui peut être économisé en compressant la clé d’index selon le nombre de colonnes indiqué.
La vue INDEX_STATS ne donne que le résultat du dernier ANALYZE INDEX ... VALIDATE STRUCTURE.
Les statistiques générées par l’ordre SQL ANALYZE INDEX ... VALIDATE STRUCTURE ne sont pas utilisées par
l’optimiseur.
La somme LF_BLKS+BR_BLKS donne le nombre de blocs utilisés par l’index, c’est­à­dire le nombre de blocs dans
lequel il existe au moins une ligne ; PCT_USED donne le pourcentage moyen d’occupation des blocs utilisés.
Exemple :
●
Situation de départ (juste après la création de l’index)
SQL> SELECT height,lf_blks,br_blks,blocks,pct_used,
2
lf_rows,del_lf_rows
3 FROM index_stats WHERE name=’ADHERENT$IX01’;
HEIGHT LF_BLKS BR_BLKS
BLOCKS PCT_USED LF_ROWS DEL_LF_ROWS
-------- -------- -------- -------- -------- -------- ----------2
57
1
64
89
9949
0
●
Situation après une forte activité de mises à jour (uniquement UPDATE) sur la table
SQL> SELECT height,lf_blks,br_blks,blocks,pct_used,
2
lf_rows,del_lf_rows
3 FROM index_stats WHERE name=’ADHERENT$IX01’;
HEIGHT LF_BLKS BR_BLKS
BLOCKS PCT_USED LF_ROWS DEL_LF_ROWS
-------- -------- -------- -------- -------- -------- ----------2
115
1
128
70
13177
3228
Dans cet exemple, nous voyons que des blocs supplémentaires ont été alloués à l’index et ont été utilisés, mais
avec une dégradation du taux d’occupation. La colonne DEL_LF_ROWS montre que des entrées ont été supprimées,
alors qu’il n’y a eu aucune suppression dans la table ; mais, comme nous l’avions indiqué précédemment, une
modification de clé d’index se traduit par une suppression (d’où les DEL_LF_ROWS) puis une insertion (d’où l’utilisation
éventuelle de nouveaux blocs).
c. Problèmes possibles sur le stockage
Les problèmes possibles sur le stockage d’un index sont les suivants :
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 11 -
●
espace inutilisé alloué à l’index ;
●
faible taux d’occupation moyen des blocs et/ou profondeur importante de l’arbre.
Espace inutilisé alloué à un index
Il y a de l’espace inutilisé alloué à un index si le nombre de blocs occupés est faible par rapport au nombre de blocs
alloués, et si l’index ne va plus grossir (ou peu).
Le nombre de blocs occupés est donné par la somme de la valeur des colonnes LF_BLKS et BR_BLKS de la vue
INDEX_STATS et le nombre de blocs alloués par la valeur de la colonne BLOCKS de la vue INDEX_STATS.
Exemple :
SQL> SELECT lf_blks+br_blks "occupés",blocks "alloués"
2 FROM index_stats WHERE name=’ADHERENT$IX01’;
occupés alloués
-------- -------116
128
Ce premier problème n’a pas d’incidence sur les performances (les blocs au­delà de la HWM ne sont jamais lus) ; il
conduit juste à un gaspillage d’espace disque.
Faible taux d’occupation moyen des blocs et/ou profondeur importante de l’index
Le stockage interne d’un index peut être considéré comme dégradé si une ou plusieurs des conditions suivantes
sont vérifiées :
●
Le rapport DEL_LF_ROWS/LF_ROWS est élevé (supérieur à 10 % ou 20 %).
●
Le pourcentage d’occupation (PCT_USED) est faible (inférieur à 70 %).
●
La profondeur de l’arbre d’index (HEIGHT) est élevée (strictement supérieure à 5).
Un mauvais remplissage des blocs peut être lié à une valeur inadaptée de PCTFREE lors de la création de l’index
et/ou à un index très volatile (nombreuses mises à jour). Ce deuxième problème a des incidences sur les
performances et sur l’utilisation de l’espace dans le Database Buffer Cache. Moins les blocs sont pleins, plus l’index
est volumineux et profond, ce qui augmente le nombre d’entrées/sorties pour le parcours de l’arbre.
Un index créé sur une table très volumineuse peut avoir un arbre profond. Ce qu’il faut donc surveiller, c’est
davantage la dégradation au fil du temps (surtout si la volumétrie de la table reste par ailleurs, stable) qu’une
situation à un instant donné.
Exemple :
●
Avant
SQL SELECT height,pct_used,ROUND(del_lf_rows/lf_rows*100) PCT_DEL
2 FROM index_stats WHERE name=’ADHERENT$IX01’;
HEIGHT PCT_USED PCT_DEL
-------- -------- -------2
89
0
●
Après
SQL> SELECT height,pct_used,ROUND(del_lf_rows/lf_rows*100) PCT_DEL
2 FROM index_stats WHERE name=’ADHERENT$IX01’;
HEIGHT PCT_USED PCT_DEL
-------- -------- -------2
70
24
Sur cet exemple, le stockage de l’index s’est dégradé au fil du temps (alors que la volumétrie de la table n’a
pratiquement pas changé).
- 12 -
© ENI Editions - All rights reserved - Algeria Educ
8. Réorganiser le stockage d’un index
a. Vue d’ensemble
Les besoins de réorganisation d’un index sont variés :
●
libérer de l’espace libre au­dessus de la HWM ;
●
réorganiser un index dont la structure s’est dégradée ;
●
réorganiser plus globalement le stockage de l’index : changement de tablespace, réduction du nombre
d’extensions, changement de PCTFREE, etc.
Libérer de l’espace situé au­dessus de la HWM permet de récupérer de l’espace alloué à l’index mais jamais utilisé
(et estimé jamais utilisable). Améliorer le taux de remplissage des blocs permet aussi éventuellement de libérer de
l’espace inutilisé (l’espace libre des blocs) situé cette fois, en dessous de la HWM.
Plusieurs techniques sont à notre disposition pour réorganiser le stockage d’un index :
●
Ordre SQL ALTER INDEX ... DEALLOCATE UNUSED ;
●
Ordre SQL ALTER INDEX ... COALESCE ;
●
Ordre SQL ALTER INDEX ... SHRINK SPACE ;
●
Ordre SQL ALTER INDEX ... REBUILD.
Il est évidemment aussi possible de supprimer l’index (ordre SQL DROP INDEX) puis de le créer de nouveau (ordre
SQL CREATE INDEX), mais une reconstruction (ordre SQL ALTER INDEX ... REBUILD) se révèle généralement plus
intéressante.
Le tableau suivant résume les techniques envisageables (√) et celles qui sont les mieux adaptées (☺) à tel ou tel
besoin :
DEALLOCATE
Libérer de l’espace au­dessus de la
HWM
COALESCE
☺
Améliorer le taux de remplissage des
blocs
☺
Réorganiser plus globalement
SHRINK
REBUILD
√
√
☺
☺
☺
Réorganiser le stockage d’un index est moins compliqué que réorganiser le stockage d’une table car les données ne
sont pas affectées et la table est toujours accessible et pleinement opérationnelle.
Lors d’un traitement massif sur une table (chargement, purge), il peut être intéressant de supprimer tout
ou partie des index de la table avant le traitement et de les recréer ensuite. La performance globale est
meilleure et l’index est neuf (non dégradé) à l’arrivée.
b. L’ordre SQL ALTER INDEX ... DEALLOCATE UNUSED
L’ordre SQL ALTER INDEX ... DEALLOCATE UNUSED permet de libérer l’espace d’un index situé au­dessus de la HWM.
Syntaxe
ALTER INDEX nom_index DEALLOCATE UNUSED [ KEEP valeur [K|M] ] ;
Exemple :
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 13 -
ALTER INDEX adherent$pk DEALLOCATE UNUSED;
ALTER INDEX adherent$pk DEALLOCATE UNUSED KEEP 0;
ALTER INDEX adherent$pk DEALLOCATE UNUSED KEEP 1M;
Le fonctionnement est le même que pour une table (Gestion des tables). N’oubliez pas que l’espace initialement
alloué est par défaut préservé ; il faut utiliser la clause KEEP pour libérer de l’espace à l’intérieur de l’espace
initialement alloué à l’index.
c. L’ordre SQL ALTER INDEX ... COALESCE
L’ordre SQL ALTER INDEX ... COALESCE permet de fusionner le contenu de blocs feuilles adjacents qui contiennent
de l’espace libre. Grosso modo, deux blocs feuilles adjacents qui ont 50 % d’espace libre peuvent être fusionnés en
un seul bloc, ce qui libère un bloc.
Syntaxe
ALTER INDEX nom_index COALESCE ;
L’ordre SQL ALTER INDEX ... COALESCE n’effectue, par contre, aucune opération sur les blocs branches ; la
profondeur de l’arbre ne change pas. Cette opération est relativement rapide et ne nécessite pas d’espace de
stockage supplémentaire.
Exemple :
●
Situation de départ
SQL> SELECT height,lf_blks,br_blks,blocks,pct_used,
2
lf_rows,del_lf_rows
3 FROM index_stats WHERE name=’ADHERENT$IX01’;
HEIGHT LF_BLKS BR_BLKS
BLOCKS PCT_USED LF_ROWS DEL_LF_ROWS
-------- -------- -------- -------- -------- -------- ----------2
257
1
384
90
64000
0
●
Situation après des modifications importantes dans la table : l’index est dégradé (la profondeur a changé)
SQL> SELECT height,lf_blks,br_blks,blocks,pct_used,
2
lf_rows,del_lf_rows
3 FROM index_stats WHERE name=’ADHERENT$IX01’;
HEIGHT LF_BLKS BR_BLKS
BLOCKS PCT_USED LF_ROWS DEL_LF_ROWS
-------- -------- -------- -------- -------- -------- ----------3
580
3
640
78
83580
33785
●
Opération de COALESCE
SQL> ALTER INDEX diane.adherent$ix01 COALESCE;
●
Situation à l’arrivée (après ANALYZE INDEX ... VALIDATE STRUCTURE)
SQL> SELECT height,lf_blks,br_blks,blocks,pct_used,
2
lf_rows,del_lf_rows
3 FROM index_stats WHERE name=’ADHERENT$IX01’;
HEIGHT LF_BLKS BR_BLKS
BLOCKS PCT_USED LF_ROWS DEL_LF_ROWS
-------- -------- -------- -------- -------- -------- ----------3
370
3
640
88
49838
43
L’opération de COALESCE a permis de réduire le nombre de blocs utilisés, et de retrouver un pourcentage
d’occupation satisfaisant et un faible taux de lignes supprimées (il en reste quelques­unes). Par contre, la
profondeur de l’arbre n’a pas changé.
Dans de nombreuses situations, cette simple opération de COALESCE est suffisante pour retrouver un index
performant.
- 14 -
© ENI Editions - All rights reserved - Algeria Educ
d. L’ordre SQL ALTER INDEX ... SHRINK SPACE
L’ordre SQL ALTER INDEX ... SHRINK SPACE est analogue à l’ordre SQL ALTER TABLE ... SHRINK SPACE : il permet de
compacter les lignes d’un index, mais uniquement pour un index stocké dans un tablespace géré localement avec
une gestion automatique de l’espace dans les segments. Par défaut, Oracle compacte aussi le segment, ajuste la
HWM et libère l’espace ainsi récupéré.
Syntaxe
ALTER INDEX nom_index SHRINK SPACE [COMPACT] ;
Avec l’option COMPACT, Oracle se contente de compacter les lignes, mais sans ajuster la HWM ni libérer d’espace.
L’exécution ultérieure d’un autre ordre SQL ALTER TABLE ... SHRINK SPACE permettra de terminer l’opération.
L’ordre SQL ALTER INDEX ... SHRINK SPACE COMPACT est équivalent à l’ordre SQL ALTER INDEX ... COALESCE.
Exemple
●
Situation après des modifications importantes dans la table : l’index est dégradé.
SQL> SELECT height,lf_blks,br_blks,blocks,pct_used,
2
lf_rows,del_lf_rows
3 FROM index_stats WHERE name=’ADHERENT$IX01’;
HEIGHT LF_BLKS BR_BLKS
BLOCKS PCT_USED LF_ROWS DEL_LF_ROWS
-------- -------- -------- -------- -------- -------- ----------3
580
3
640
78
83580
33785
●
Opération de SHRINK SPACE
SQL> ALTER INDEX diane.adherent$ix01 SHRINK SPACE;
●
Situation à l’arrivée (après ANALYZE INDEX ... VALIDATE STRUCTURE)
SQL> SELECT height,lf_blks,br_blks,blocks,pct_used,
2
lf_rows,del_lf_rows
3 FROM index_stats WHERE name=’ADHERENT$IX01’;
HEIGHT LF_BLKS BR_BLKS
BLOCKS PCT_USED LF_ROWS DEL_LF_ROWS
-------- -------- -------- -------- -------- -------- ----------3
374
3
400
87
49800
0
À quelques blocs près, l’opération de SHRINK SPACE donne le même résultat que l’opération de COALESCE, sauf sur les
blocs utilisés (400 contre 640) ; l’espace a été libéré.
L’opération de COALESCE est légèrement plus rapide que l’opération de SHRINK SPACE.
e. L’ordre SQL ALTER INDEX ... REBUILD
L’ordre SQL ALTER INDEX ... REBUILD permet de reconstruire en totalité un index (blocs branches et blocs feuilles)
et donc, de réorganiser son stockage.
Syntaxe
ALTER INDEX nom_index REBUILD
[ TABLESPACE nom_tablespace ]
[ PCTFREE valeur ]
[ clause_stockage ]
[ ONLINE ]
[ NOCOMPRESS | COMPRESS [n] ]
[ LOGGING | NOLOGGING ] ;
- clause_stockage
STORAGE ( [ INITIAL valeur [K|M] ]
[ NEXT valeur [K|M] ]
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 15 -
[ MINEXTENTS valeur ]
[ MAXEXTENTS { valeur | UNLIMITED } ]
[ PCTINCREASE valeur ] )
Exemple :
ALTER INDEX adherent$pk REBUILD
PCTFREE 40
STORAGE ( INITIAL 10M ) ;
Les options sont les mêmes que celles de l’ordre SQL CREATE INDEX.
Sans option, l’ordre SQL ALTER INDEX ... REBUILD reconstruit l’index avec les mêmes clauses de stockage. Cette
syntaxe peut être utilisée pour reconstruire un index dont les clauses de stockage sont bonnes mais qui s’est
dégradé au fil du temps, du fait d’une forte activité de mise à jour.
L’ordre SQL ALTER INDEX ... REBUILD est plus intéressant que la recréation (DROP+CREATE) pour deux raisons :
●
L’index est reconstruit à partir de l’index existant : aucun tri n’est nécessaire.
●
L’ancien index est toujours disponible : les requêtes peuvent l’utiliser.
Les performances sont donc globalement améliorées pour tout le monde.
Ces deux avantages disparaissent si l’index d’origine est UNUSABLE(suite à l’exécution d’un ordre SQL ALTER
TABLE ... MOVE par exemple).
L’inconvénient majeur par rapport à une recréation est qu’il faut de l’espace disponible pour faire cohabiter
temporairement l’ancien index et le nouveau.
Exemple 1
●
Situation après des modifications importantes dans la table : l’index est dégradé
SQL> SELECT height,lf_blks,br_blks,blocks,pct_used,
2
lf_rows,del_lf_rows
3 FROM index_stats WHERE name=’ADHERENT$IX01’;
HEIGHT LF_BLKS BR_BLKS
BLOCKS PCT_USED LF_ROWS DEL_LF_ROWS
-------- -------- -------- -------- -------- -------- ----------3
580
3
640
78
83580
33785
●
Opération de REBUILD
SQL> ALTER INDEX diane.adherent$ix01 REBUILD;
Index modifié.
●
Situation à l’arrivée (après ANALYZE INDEX ... VALIDATE STRUCTURE)
SQL> SELECT height,lf_blks,br_blks,blocks,pct_used,
2
lf_rows,del_lf_rows
3 FROM index_stats WHERE name=’ADHERENT$IX01’;
HEIGHT LF_BLKS BR_BLKS
BLOCKS PCT_USED LF_ROWS DEL_LF_ROWS
-------- -------- -------- -------- -------- -------- ----------2
364
1
384
89
49805
0
L’index a été complètement reconstruit : il a retrouvé une profondeur de 2 et utilise un peu moins de blocs.
Exemple 2
●
Situation de départ : index non compressé
SQL> SELECT lf_blks,br_blks,blocks,opt_cmpr_count,opt_cmpr_pctsave
2 FROM index_stats WHERE name=’ADHERENT$IX01’;
LF_BLKS BR_BLKS
BLOCKS OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
-------- -------- -------- -------------- ---------------- 16 -
© ENI Editions - All rights reserved - Algeria Educ
58
●
1
72
2
28
Compression sur les deux premières colonnes
SQL> ALTER INDEX diane.adherent$ix01 REBUILD COMPRESS 2;
●
Situation à l’arrivée (après ANALYZE INDEX ... VALIDATE STRUCTURE)
SQL> SELECT lf_blks,br_blks,blocks,opt_cmpr_count,opt_cmpr_pctsave
2 FROM index_stats WHERE name=’ADHERENT$IX01’;
LF_BLKS BR_BLKS
BLOCKS OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
-------- -------- -------- -------------- ---------------41
1
48
2
0
L’index a été reconstruit avec une compression sur les deux premières colonnes. Le gain annoncé était de 28 % ; il
est de 28,8 %.
f. Conclusion
Si le fait que le REBUILD nécessite temporairement de l’espace ne vous pose pas de problème, utilisez en priorité
cette technique pour réorganiser le stockage d’un index : vous obtiendrez le meilleur résultat.
Par contre, si vous avez des problèmes de place, vous pouvez employer le COALESCE pour un résultat généralement
très satisfaisant, mais vous ne libérez pas d’espace pour d’autres segments. Dans ce cas, le SHRINK SPACE peut être
envisagé ; il présente l’avantage de libérer l’espace récupéré.
9. Surveiller l’utilisation d’un index
Depuis Oracle9i, il est possible de surveiller les index afin de déterminer s’ils sont utilisés ou non. Un index non utilisé
peut être supprimé pour libérer de l’espace et améliorer les performances des mises à jour.
L’ordre SQL ALTER INDEX permet d’activer ou de désactiver la surveillance d’un index :
ALTER INDEX nom_index MONITORING USAGE | NOMONITORING USAGE ;
Exemple :
ALTER INDEX adherent$ix01 MONITORING USAGE ;
La clause MONITORING USAGE peut aussi être utilisée dans l’ordre SQL CREATE INDEX pour activer la surveillance dès la
création de l’index (NOMONITORING par défaut).
La vue V$OBJECT_USAGE sera ensuite interrogée pour déterminer si un index a été utilisé pendant qu’il était sous
surveillance :
INDEX_NAME
Nom de l’index.
TABLE_NAME
Nom de la table sur laquelle l’index est créé.
MONITORING
Indique si l’index est actuellement sous surveillance (YES ou NO).
USED
Indique si l’index a été utilisé au moins une fois pendant sa surveillance (YES ou NO).
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 17 -
START_MONITORING
Date/heure du début de la surveillance de l’index.
END_MONITORING
Date/heure de la fin de la surveillance de l’index (vide si la surveillance est en cours).
La vue V$OBJECT_USAGE doit être interrogée sous le compte du propriétaire de l’index.
Exemple :
SQL> SELECT * FROM v$object_usage
2 WHERE index_name = ’ADHERENT$IX01’ ;
INDEX_NAME
TABLE_NAME
MONITORING USED
--------------- --------------- ---------- ---START_MONITORING
END_MONITORING
------------------- ------------------ADHERENT$IX01
ADHERENT
YES
YES
01/04/2005 10:37:40
Dans cet exemple, l’index ADHERENT$IX01 créé sur la table ADHERENT a été utilisé au moins une fois depuis que l’index
est sous surveillance ; l’index est toujours sous surveillance (la colonne END_MONITORING est vide).
10. Trouver des informations sur les index
Plusieurs vues du dictionnaire de données permettent d’obtenir des informations sur les index :
●
DBA_INDEXES : informations sur les index ;
●
DBA_IND_COLUMNS : informations sur les colonnes des index ;
●
INDEX_STATS : résultat du dernier ANALYZE INDEX ... VALIDATE STRUCTURE ;
●
DBA_SEGMENTS : informations sur les segments (dont ceux de type index) ;
●
DBA_EXTENTS : informations sur les extensions allouées aux segments (dont ceux de type index)
Les vues DBA_SEGMENTS et DBA_EXTENTS ont été présentées à la section Trouver des informations sur les tablespaces
et les fichiers de données du chapitre Gestion des tablespaces et des fichiers de données.
La vue INDEX_STATS a été présentée à la section Gestion des index B­tree. L’ordre SQL ANALYZE INDEX ... VALIDATE
STRUCTURE.
Les colonnes intéressantes des différentes autres vues sont présentées ci­après.
DBA_INDEXES
INDEX_NAME
Nom de l’index.
OWNER
Nom du propriétaire de l’index.
TABLE_NAME
Nom de la table sur laquelle l’index est créé.
- 18 -
© ENI Editions - All rights reserved - Algeria Educ
TABLE_OWNER
Nom du propriétaire de la table.
UNIQUENESS
Nature de l’index (UNIQUE ou NONUNIQUE).
TABLESPACE_NAME
Nom du tablespace dans lequel l’index est stocké.
PCT_FREE
Valeur du PCTFREE.
COMPRESSION
Indique si la compression de l’index est active (ENABLED ou DISABLED).
PREFIX_LENGTH
Nombre de colonnes dans le préfixe de la compression.
LOGGING
Indique si le mode LOGGING est actif ou non pour l’index (YES ou NO).
STATUS
Statut de l’index (VALID ou UNUSABLE).
BLEVEL *
Profondeur de l’arbre au niveau des branches (ne tient pas compte des feuilles). 0 si le bloc racine est égal au bloc
feuille.
LEAF_BLOCKS *
Nombre de blocs feuilles dans l’index.
NUM_ROWS *
Nombre de lignes dans l’index.
CLUSTERING_FACTOR *
Facteur de regroupement des données dans la table.
AVG_LEAF_BLOCKS_PER_KEY *
Nombre moyen de blocs feuilles par valeur de la clé.
AVG_DATA_BLOCKS_PER_KEY *
Nombre moyen de blocs de données (table) par valeur de la clé.
DISTINCT_KEYS *
Nombre de valeurs distinctes dans l’index.
SAMPLE_SIZE *
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 19 -
Taille de l’échantillon utilisé lors du calcul des statistiques.
LAST_ANALYZED *
Date et heure de la dernière analyse réalisée sur l’index.
* Statistiques sur l’index, calculées par défaut lorsque les statistiques sont générées sur la table. Ces dernières sont
utilisées par l’optimiseur.
DBA_IND_COLUMNS
INDEX_NAME
Nom de l’index.
OWNER
Nom du propriétaire de l’index.
TABLE_NAME
Nom de la table sur laquelle l’index est créé.
TABLE_OWNER
Nom du propriétaire de la table.
COLUMN_NAME
Nom de la colonne utilisée dans la clé de l’index.
COLUMN_POSITION
Position de la colonne dans la clé de l’index.
- 20 -
© ENI Editions - All rights reserved - Algeria Educ
Les statistiques et l’optimiseur Oracle
L’optimiseur Oracle est chargé de déterminer le plan d’exécution des requêtes, c’est­à­dire la manière dont Oracle va
exécuter la requête.
Depuis maintenant plusieurs versions, Oracle recommande de faire fonctionner l’optimiseur dans le mode CBO (Cost
Based Optimizer ­ Optimiseur basé sur les coûts). Depuis la version 10, seul le mode CBO est supporté ; le mode RBO
(Rule Based Optimizer ­ Optimiseur basé sur les règles) n’est plus supporté.
Pour fonctionner, l’optimiseur dans le mode CBO a besoin de statistiques sur les tables, les colonnes et les index. Ces
statistiques sont calculées avec le package DBMS_STATS.
Dans les versions précédentes, il était de la responsabilité du DBA de programmer une tâche périodique de collecte des
statistiques, afin que l’optimiseur ne travaille pas avec des données obsolètes.
Depuis la version 10, les statistiques sont automatiquement collectées par Oracle. En version 11, cette collecte
s’effectue par l’intermédiaire d’une tâche de maintenance automatisée (cf. Oracle Enterprise Manager Database Control
du chapitre Les Outils d’administration).
Par défaut, cette tâche de maintenance collecte les statistiques sur les objets de la base de données qui n’ont pas de
statistiques ou qui ont des statistiques jugées obsolètes (si plus de 10% des lignes de l’objet sous­jacent ont été
modifiées) ; la procédure traite en priorité les objets qui en ont le plus besoin. Les paramètres de cette tâche
automatique peuvent être configurées dans le Database Control (cf. Oracle Enterprise Manager Database Control du
chapitre Les Outils d’administration).
Vous pouvez collecter les statistiques en exécutant manuellement certaines procédures du package DBMS_STATS :
●
GATHER_TABLE_STATS(owname,tabname) : statistiques sur une table (et par défaut sur les colonnes et index de la
table) ;
●
GATHER_INDEX_STATS(owname,indname) : statistiques sur un index ;
●
GATHER_SCHEMA_STATS(owname) : statistiques sur toutes les tables et index d’un schéma.
Les paramètres sont les suivants :
ownname
Nom du schéma (NULL pour le schéma courant).
tabname
Nom de la table.
indname
Nom de l’index.
Ces procédures ont d’autres paramètres dont les valeurs par défaut sont a priori satisfaisantes (au moins dans un
premier temps).
Les statistiques peuvent êtres consultées dans les vuesDBA_TABLES, DBA_TAB_ COLUMNSet DBA_INDEXES.
Exemple :
SQL> EXEC dbms_stats.gather_schema_stats(’DIANE’)
Procédure PL/SQL terminée avec succès.
SQL> SELECT num_rows,blocks,sample_size,last_analyzed
2 FROM dba_tables WHERE table_name=’ADHERENT’ AND owner=’DIANE’;
NUM_ROWS
BLOCKS SAMPLE_SIZE LAST_ANA
---------- ---------- ----------- -------9964
137
9964 20/07/08
Le Database Control permet de gérer les statistiques de l’optimiseur. Pour accéder à la page de gestion des
statistiques de l’optimiseur, cliquez sur le lien Serveur sur la page d’accueil puis sur le lien Gérer les statistiques de
l’optimiseur (cadre Optimiseur d’interrogation).
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Utiliser le Database Control
1. Les tables
Dans le Database Control, cliquez sur le lien Schéma sur la page d’accueil puis sur le lien Tables (cadre Objets de
base de données) pour accéder à la page de gestion des tables.
La section Rechercher permet de rechercher des objets selon leur type, leur schéma ou leur nom.
À partir de cette page, vous pouvez effectuer diverses actions sur les tables :
●
créer une nouvelle table (bouton Créer ou menu Créer comme ) ;
●
supprimer une table (bouton Supprimer avec des options) ;
●
modifier une table (bouton Modifier) ;
●
créer un index sur une table (menu Créer un index) ;
●
extraire la définition d’une table (menu Générer du code DDL) ;
●
collecter les statistiques sur une table (menu Gérer les statistiques de l’optimiseur) ;
© ENI Editions - All rights reserved - Algeria Educ
- 1-
●
réorganiser une table (menu Réorganiser) ;
●
exécuter le conseiller sur les segments (menu Exécuter la fonction de conseil sur les segments) ;
●
compacter (SHRINK) la table (menu Réduire le segment).
En cliquant sur le lien du nom de table, ou en cliquant sur les boutons Créer, Modifier ou Visualiser, vous arrivez sur
la page de définition d’une table :
Cette page propose plusieurs onglets (sous forme de liens) permettant de gérer les différentes caractéristiques de la
table.
L’onglet Segments permet de voir l’espace utilisé par la table et ces index :
Le graphique donne la tendance d’utilisation de l’espace pour le segment sélectionné dans la liste et la période
indiquées. Il peut être utilisé pour estimer la volumétrie d’une table ou d’un index à une échéance donnée.
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
2. Les index
Dans le Database Control, cliquez sur le lien Schéma sur la page d’accueil puis sur le lien Index (cadre Objet de base
de données) pour accéder à la page de gestion des index.
La section Rechercher permet de rechercher des objets selon leur type, leur schéma ou leur nom.
À partir de cette page, vous pouvez effectuer diverses actions sur les index :
●
créer un nouvel index (bouton Créer ou menu Créer comme) ;
●
supprimer un index (bouton Supprimer) ;
●
modifier un index (bouton Modifier) ;
●
extraire la définition d’un index (menu Générer du code DDL) ;
●
collecter les statistiques sur l’index (menu Gérer les statistiques de l’optimiseur) ;
●
réorganiser un index (menu Réorganiser) ;
●
exécuter le conseiller sur les segments (menu Exécuter la fonction de conseil sur les segments) ;
●
compacter (SHRINK) un index (menu Réduire le segment).
En cliquant sur le lien du nom d’index, ou en cliquant sur les boutons Créer, Modifier ou Visualiser, vous arrivez sur
la page de définition d’un index :
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Cette page propose plusieurs onglets (sous forme de liens) permettant de gérer les différentes caractéristiques de
l’index. L’onglet Segments permet de voir l’espace utilisé par l’index (comme pour une table).
3. Réorganiser une table ou un index
Le menu Réorganiser disponible sur les tables, les index et les tablespace permet d’exécuter un assistant de
réorganisation du stockage des objets. Cet assistant peut aussi être appelé en cliquant sur le lien Réorganiser les
objets dans le cadre Objets de base de données de l’onglet Schéma.
Les principales étapes de l’assistant sont les suivantes :
Définir la liste des objets à réorganiser
Sur cette page, vous pouvez définir la liste des objets à réorganiser en cliquant sur les boutons Ajouter et Enlever.
Les boutons Définir les attributs et Définir les attributs par type permettent de spécifier les caractéristiques de
stockage : nouveau tablespace, taille initiale, PCTFREE, etc.
Définir les caractéristiques de la réorganisation
Cette page permet notamment d’indiquer si la réorganisation doit s’effectuer en ligne ou hors ligne. La réorganisation
en ligne privilégie la disponibilité de l’objet au détriment de la vitesse ; c’est l’inverse pour la réorganisation hors
ligne.
Rapport d’impact
Cette page donne des informations sur les problèmes potentiels qui peuvent survenir au cours de la réorganisation
(manque d’espace par exemple) ; si c’est le cas, il faut réaliser les modifications nécessaires avant de lancer
l’opération.
Programmation
Cette page permet de nommer le travail, de fournir les informations d’identification et de connexion, et de
programmer l’exécution du travail (maintenant ou ultérieurement).
Récapitulatif
- 4-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Cette page donne un récapitulatif du travail qui va être effectué. En cliquant sur le bouton radio Script complet, vous
pouvez consulter (et récupérer) le script complet de la réorganisation. Cliquez sur le bouton Soumettre un travail
pour lancer l’opération.
Cet assistant utilise une des techniques suivantes :
●
réorganisation d’un index : ordre SQL ALTER INDEX ... REBUILD ;
●
réorganisation d’une table hors ligne : ordre SQL ALTER TABLE ... MOVE ;
●
réorganisation d’une table en ligne : package DBMS_REDEFINITION.
Le résultat du travail peut être consulté en cliquant sur le lien Travaux de la page d’accueil (cadre Liens associés en
bas).
4. Le conseiller sur les segments
Le Database Control dispose d’un conseiller sur les segments (Segment Advisor). Ce conseiller donne des
recommandations sur l’opportunité ou non de compacter (SHRINK) un segment.
Cet assistant peut être appelé en utilisant le menu Exécuter la fonction de conseil sur les segments disponible sur
les tables, les index et les tablespace ou en cliquant sur le lien Fonction de conseil sur les segments sur la page
Centre de conseil (accessible par le lien Centre de conseil à partir de la page d’accueil).
Par défaut, cet assistant est aussi programmé pour s’exécuter en tâche de maintenance automatisée (cf. Oracle
Enterprise Manager Database Control du chapitre Les Outils d’administration). Vous serez donc rarement amené à
lancer le conseiller manuellement.
Sur la page d’accueil du Database Control, dans le cadre Récapitulatif de l’espace, pour pouvez voir rapidement s’il y
a des recommandations sur les segments :
© ENI Editions - All rights reserved - Algeria Educ
- 5-
En cliquant sur le lien associé, vous pouvez afficher la liste des recommandations :
Si vous cliquez sur le bouton Détails des recommandations, vous pouvez consulter le détail de la recommandation
sélectionnée :
Pour implémenter les recommandations, il vous suffit de sélectionner une ou plusieurs tâches dans la liste et de
cliquer sur le bouton Implémenter, ou de cliquer directement sur le bouton Réduire d’une tâche. Le Database Control
affiche alors la page suivante :
Cette page vous permet de choisir une option de réduction (SHRINK SPACE ou SHRINK SPACE COMPACT) et de soumettre
le travail (bouton Implémenter). Le résultat du travail peut être consulté en cliquant sur le lien Travaux de la page
Serveur (cadre Oracle Scheduler).
D’une manière plus générale, les résultats des différents conseillers sont visibles lorsque vous affichez la page
Centre de conseil :
- 6-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
En cliquant sur le lien correspondant à une tâche, vous pouvez visualiser les recommandations du conseiller.
© ENI Editions - All rights reserved - Algeria Educ
- 7-
La base de données
1. Fichier de contrôle
Le fichier de contrôle contient des informations de contrôle sur la base de données :
●
le nom de la base de données ;
●
la date/heure de création de la base de données ;
●
l’emplacement des autres fichiers de la base de données (fichiers de données et fichiers de journalisation) ;
●
le numéro de séquence actuel des fichiers de journalisation ;
●
des informations sur les points de reprise (checkpoint), etc.
Le fichier de contrôle est automatiquement mis à jour par Oracle lors de chaque modification de la structure de la base
de données (ajout ou déplacement d’un fichier par exemple). La taille du fichier de contrôle est déterminée par Oracle.
Lorsqu’une instance est lancée pour ouvrir une base de données, le fichier de contrôle est le premier fichier ouvert. Il
permet ensuite à l’instance de localiser et d’ouvrir les autres fichiers de la base de données. Si le fichier de contrôle ne
peut pas être trouvé (ou est endommagé), la base de données ne peut pas être ouverte, même si les autres fichiers
de la base de données sont présents (l’instance reste dans le statut NOMOUNT ­ voir le chapitre Démarrage et arrêt).
Différents scénarios de restauration sont alors disponibles en fonction de la situation (présence ou non d’une
sauvegarde du fichier de contrôle notamment) pour redémarrer la base de données, mais ce sont des scénarios
relativement complexes.
Pour des raisons de sécurité, il est donc conseillé de multiplexer le fichier de contrôle, c’est­à­dire d’en avoir plusieurs
copies gérées en miroir (multiplexées) par Oracle. Techniquement, il est possible de créer une base de données avec
un seul fichier de contrôle mais il est vivement conseillé d’utiliser plusieurs copies, même si le serveur ne comporte
qu’un disque (cela met à l’abri d’une suppression accidentelle).
Plusieurs fichiers de contrôle peuvent être spécifiés lors de la création de la base (chapitre Création d’une nouvelle
base de données) ou ultérieurement (chapitre Gestion des fichiers de contrôle et de journalisation).
2. Fichier de journalisation
Les fichiers de journalisation (redo log) enregistrent toutes les modifications apportées à la base de données. Ils sont
organisés en groupes écrits de manière circulaire ; les informations sauvegardées sont donc périodiquement écrasées.
Les fichiers de journalisation sont utilisés pour la récupération de l’instance après un arrêt anormal et pour la
récupération de média si un fichier de données est perdu ou endommagé ; dans ce cas, ils sont appliqués à une
sauvegarde de fichier de données, pour rejouer toutes les modifications survenues entre la sauvegarde et l’incident
ayant endommagé le fichier.
Les fichiers de journalisation sont organisés en groupes (au minimum 2) composés d’un ou de plusieurs membres
(minimum un) ; ils sont créés lors de la création de la base (cf. Chapitre Création d’une nouvelle base de données). À
l’intérieur d’un groupe, les membres sont écrits simultanément en miroir par l’instance Oracle (processus LGWR) et
contiennent la même information. Tous les membres d’un groupe ont la même taille, définie lors de la création du
groupe ; un fichier de journalisation contient donc une quantité maximale d’informations. De même, le nombre de
groupes est déterminé ; il n’augmente pas dynamiquement.
Lorsqu’un groupe est plein (c’est­à­dire lorsque les membres sont pleins), l’instance Oracle passe au groupe suivant et
ainsi de suite jusqu’au dernier ; lorsque le dernier groupe est plein, l’instance Oracle repasse au premier. Le passage
d’un groupe à un autre est appelé basculement (switch).
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Lorsque l’instance Oracle revient dans le premier groupe, elle écrase les informations qui y sont stockées ; ces
informations ne sont donc plus disponibles en cas de besoin, par exemple pour une récupération de média. Pour
garantir cette possibilité d’effectuer des récupérations complètes, il faut activer le mécanisme d’archivage (chapitre
Sauvegarde et récupération) qui permet d’archiver les fichiers de journalisation (en l’occurrence un membre du groupe)
lorsqu’ils sont pleins, avant que l’instance ne les réutilise.
Si un groupe comporte plusieurs membres et qu’un des membres est indisponible, la base de données peut continuer
à fonctionner.
Les fichiers de journalisation sont très importants pour la sécurité de la base de données. Il est donc conseillé
d’utiliser au minimum deux ou trois membres par groupe (multiplexage), si possible sur des disques différents.
Les fichiers de journalisation seront abordés dans les chapitres Création d’une nouvelle base de données (création
initiale) et Gestion des fichiers de contrôle et de journalisation (manipulation ultérieure).
3. Fichiers de données
a. Définitions
Les fichiers de données contiennent les données proprement dites de la base de données (tables et index
notamment). Ils sont logiquement regroupés en tablespaces :
Un tablespace est une unité logique de stockage composée d’un ou plusieurs fichiers physiques. La quasi­totalité
des opérations d’administration relatives au stockage s’effectue en travaillant sur le tablespace et non sur le fichier
de données.
En version 10, Oracle a introduit la notion de tablespace bigfile. Un tablespace bigfile est un tablespace qui ne
contient qu’un seul fichier de données, mais qui peut être beaucoup plus gros qu’un fichier de données traditionnel.
Les tablespaces bigfile permettent de gérer des volumes de données beaucoup plus importants, tout en simplifiant la
gestion du stockage (moins de fichiers, transparence du fichier de données). Par opposition, le tablespace
traditionnel est maintenant, parfois appelé tablespace smallfile.
Une base de données comporte au minimum deux fichiers de données appartenant à deux tablespaces réservés
pour Oracle (le tablespace SYSTEM et le tablespace SYSAUX, apparu en version 10). Les tablespaces SYSTEM et SYSAUX
ne doivent normalement contenir aucune donnée applicative.
Dans la pratique, une base de données comportera donc d’autres fichiers de données appartenant à d’autres
tablespaces.
La gestion des tablespaces et des fichiers de données est présentée dans le chapitre Gestion des tablespaces et
des fichiers de données.
b. Organisation du stockage
- 2-
© ENI Editions - All rights reserved - Algeria Educ
Les fichiers de données sont découpés en blocs d’une taille donnée (4 Ko, 8 Ko...).
L’espace occupé par un objet dans un tablespace est désigné par le terme générique de segment. Il y a quatre
types principaux de segments :
●
les segments de table : espace occupé par les tables ;
●
les segments d’index : espace occupé par les index ;
●
●
les segments d’annulation : espace temporaire utilisé pour stocker les informations permettant d’annuler une
transaction ;
les segments temporaires : espace temporaire utilisé notamment lors d’un tri.
Un segment appartient à un tablespace et est constitué d’extensions (extents). Une extension est un ensemble de
blocs contigus dans un fichier de données.
Dans Oracle Enterprise Manager, les extensions sont appelées "ensembles de blocs contigus".
La notion de "bloc Oracle" est fondamentale ; nous allons la retrouver partout. Un bloc Oracle est la plus petite unité
d’entrée/sortie utilisée par Oracle. Tous les fichiers de données sont organisés en blocs Oracle et ont donc une taille
multiple de la taille du bloc. Le bloc Oracle est aussi l’unité d’organisation du cache de données (Database Buffer
Cache) dans la SGA. Lorsqu’une instance Oracle lit un fichier de données, elle lit les blocs Oracle du fichier et les
charge dans des blocs Oracle du cache de données.
Le segment d’annulation est une structure utilisée par Oracle pour stocker temporairement la version précédente
des données en cours de modification dans une transaction. Si la transaction est validée (COMMIT), l’espace occupé
sera libéré ; si la transaction est annulée (ROLLBACK), la version précédente des données sera remise à la place de la
nouvelle.
Les segments temporaires et les segments d’annulation seront étudiés plus en détail dans les chapitres Gestion des
tablespaces et des fichiers de données et Gestion des informations d’annulation.
En dehors des tablespaces destinés aux données proprement dites de notre application (tables, index), nous serons
donc amenés à créer deux autres tablespaces "techniques", utilisés en interne par Oracle : le tablespace
d’annulation (pour les segments d’annulation) et le tablespace temporaire (pour les segments temporaires).
Lorsqu’un segment (table, index, etc.) est créé, il est placé (explicitement par le créateur ou implicitement par Oracle)
dans un tablespace ; c’est Oracle, ensuite, qui se charge d’allouer de l’espace à ce segment dans l’un des fichiers de
données du tablespace.
Lors de la création d’un segment, une ou plusieurs extensions lui sont allouées. Lorsque ces premières extensions
sont pleines (suite à l’insertion de données par exemple), une nouvelle extension est allouée ; cette extension est
située dans le même tablespace, mais pas forcément à côté de la première (d’autres segments ont peut­être été
créés entre­temps), ni même dans le même fichier de données (si le tablespace a plusieurs fichiers de données).
Lorsque cette nouvelle extension est pleine, le processus se reproduit.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Dans l’ordre SQL de création du segment, il existe des clauses qui permettent d’indiquer dans quel tablespace créer
le segment et de définir la taille initiale du segment.
Ces différents mécanismes seront revus dans le chapitre Gestion des tablespaces et des fichiers de données.
Depuis la version 9 d’Oracle, il est possible d’utiliser plusieurs tailles de bloc dans la base de données :
●
●
Une taille de bloc "standard" est définie par le paramètre d’initialisation DB_BLOCK_SIZE.
Jusqu’à 5 autres tailles de bloc peuvent être utilisées : les valeurs permises sont 2 Ko, 4 Ko, 8 Ko, 16 Ko et
32 Ko (certaines plates­formes sont plus restrictives).
Cette possibilité d’utiliser plusieurs tailles de bloc est surtout intéressante pour la fonctionnalité de transport de
tablespace. Cette fonctionnalité, apparue dans Oracle8i, permet de transporter un tablespace d’une base de
données source vers une base de données cible et de le rattacher à la base de données cible ; cette opération
s’effectue grâce à l’utilitaire Data Pump, avec l’option TRANSPORT_TABLESPACES. Un des pré­requis pour l’utilisation de
cette fonctionnalité dans Oracle8i est que les deux bases doivent utiliser la même taille de bloc. Cette limitation est
levée depuis Oracle9i puisque différents tablespaces d’une même base de données peuvent utiliser des tailles de
bloc différentes : un tablespace ayant une taille de bloc de 4 Ko peut être transporté dans une base de données
utilisant des blocs de 8 ko.
4. Système de stockage
Les fichiers de données d’une base de données Oracle peuvent être stockés dans un système de fichiers (cas
classique), dans des raw device (directement dans des partitions, sans système de fichier) ou à l’aide d’ASM (Automatic
Storage Management).
ASM, apparu en version 10, est en quelque sorte un gestionnaire de volumes spécialement conçu pour Oracle, qui va
chercher à exploiter au mieux les disques qui lui sont attribués (répartition des entrées/sorties notamment). Pour
fonctionner, ASM utilise une instance spéciale (instance ASM).
Lors de l’utilisation d’un système de fichiers, il est conseillé d’utiliser plusieurs disques. Cela permet d’améliorer les
performances en répartissant les entrées/sorties, et d’améliorer la sécurité en multiplexant les fichiers de contrôle et
les fichiers de journalisation. Par ailleurs, beaucoup de nouvelles fonctionnalités apparues en version 10, relatives à la
sécurité des données, aux sauvegardes et aux restaurations, sont basées sur la mise en place d’une zone de
récupération rapide (flash recovery area). Cette zone de récupération rapide peut être stockée dans un système de
fichiers ou à l’aide d’ASM. Dans le cas de l’utilisation d’un système de fichiers, il est conseillé d’utiliser un disque séparé
des disques contenant les données, car c’est la destination par défaut des sauvegardes.
5. Notion de schéma
Le terme schéma désigne l’ensemble des objets qui appartiennent à un utilisateur.
Les principaux types d’objets sont les suivants :
●
Table
●
Vue
●
Synonyme
●
Index
●
Séquence
●
Programme PL/SQL (procédure, fonction, package, trigger)
Chaque utilisateur d’une base de données Oracle a un schéma potentiel, mais seuls les utilisateurs habilités pourront
effectivement créer des objets dans ce schéma. Ces différentes notions seront étudiées plus en détail dans le chapitre
Gestion des utilisateurs et de leurs droits.
Sur les différents types d’objets présentés ci­dessus, seuls les tables et les index stockent des données et occupent
de l’espace de stockage dans des tablespaces. Les autres types d’objet n’ont qu’une définition stockée dans le
dictionnaire de données Oracle.
- 4-
© ENI Editions - All rights reserved - Algeria Educ
La notion de schéma est une notion purement logique. Physiquement, les objets des différents schémas sont
mélangés, soit dans le dictionnaire de données Oracle, soit dans les tablespaces, mais Oracle sait s’y retrouver.
Des schémas d’exemple sont fournis par Oracle, dont le fameux (mais réduit) schéma SCOTT (mot de passe TIGER,
propriétaire des tables EMP et DEPT). Des schémas d’exemple plus évolués sont décrits dans la documentation Oracle®
Database Sample Schemas. Ils peuvent être installés lors de la création d’une base de données ou ultérieurement.
6. Règles de nommage
Un nom de structure Oracle (table, tablespace, etc.) doit respecter les règles suivantes :
●
contenir 30 caractères maximum ;
●
doit commencer par une lettre ;
●
peut contenir des lettres, des chiffres et trois caractères spéciaux (_$#) ;
●
n’est pas sensible à la casse ;
●
ne doit pas être un mot réservé Oracle.
Il y a évidemment des exceptions à ces règles de nommage, notamment pour le nom de la base de données
qui est limité à 8 caractères.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 5-
Problèmes courants et solutions
ORA-01653: impossible d’étendre la table X. de N dans le tablespace Y
ORA-01654: impossible d’étendre l’index X. de N dans le tablespace Y
Explication
Un segment (table ou index) n’arrive pas à s’étendre.
Cause(s)
Le segment (table ou index) n’arrive pas à s’étendre car le tablespace dans lequel il est stocké n’a pas suffisamment
d’espace disponible et ne peut pas s’étendre lui­même.
Action(s)
Il faut augmenter l’espace disponible dans le tablespace :
­ soit en lui allouant un nouveau fichier de données (ALTER TABLESPACE ... ADD DATAFILE ...) ;
­ soit en augmentant la taille d’un fichier de données du tablespace (ALTER DATABASE DATAFILE ... RESIZE ...) ;
­ soit en autorisant un fichier de données du tablespace à s’étendre automatiquement (ALTER DATABASE DATAFILE ...
AUTO- EXTEND ON ...).
ORA-01631: nbre max. d’ensembles de blocs contigus (N) atteint dans table X.
ORA-01632: nbre max. d’ensembles de blocs contigus (N) atteint dans index X.
Explication
Un segment (table ou index) n’arrive pas à s’étendre.
Cause(s)
Le segment (table ou index) n’arrive pas s’étendre car il est stocké dans un tablespace géré par le dictionnaire et il a
atteint son nombre maximum d’extensions défini par MAXEXTENTS. Ce problème ne peut pas se produire si le segment
est stocké dans un tablespace géré localement (nombre d’extensions illimité).
Action(s)
Utilisez un tablespace géré localement et choisissez éventuellement une taille d’extension adaptée à la volumétrie du
segment.
ORA-01502: l’index ’xxx.yyy’ ou sa partition est inutilisable
Explication
Un index est inutilisable (UNUSABLE) et ne peut pas être utilisé pour exécuter une requête.
Cause(s)
La table a peut­être été reconstruite par un ALTER TABLE … MOVE, ce qui a rendu les index de la table inutilisables.
À noter que cette erreur se produit uniquement si le paramètre SKIP_UNUSABLE_INDEXES est à FALSE. S’il est à TRUE
(valeur par défaut), l’optimiseur ne tente pas d’utiliser les index inutilisables et l’erreur ne se produit pas ; par contre,
les performances risquent de se dégrader fortement (parcours complet de table).
Action(s)
Reconstruisez l’index (ALTER INDEX … REBUILD).
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Si vous obtenez une erreur ORA-01630 ou ORA-01652 lors de la création ou de la reconstruction d’un index, c’est
qu’il y a un problème avec le segment temporaire nécessaire au tri (voir les problèmes courants et solution du
chapitre Gestion des tablespaces et des fichiers de données).
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Principes
1. Vue d’ensemble
Assurer la sécurité des données est une des tâches principales de l’administrateur.
Cette sécurité est assurée par :
●
●
la mise en œ uvre d’une protection des fichiers sensibles de la base :
●
fichiers de contrôle ;
●
fichiers de journalisation.
la mise en place d’une stratégie de sauvegarde/restauration :
●
adaptée aux contraintes de l’entreprise ;
●
testée et documentée.
La protection des fichiers de contrôle et des fichiers de journalisation s’effectue par multiplexage (voir le chapitre
Gestion des fichiers de contrôle et des fichiers de journalisation).
Les questions à se poser pour définir la stratégie sont les suivantes :
●
Est­il acceptable de perdre des données ?
●
Est­il possible d’arrêter périodiquement la base ?
●
Est­il possible de réaliser une sauvegarde complète de la base pendant l’arrêt ?
La réponse à la question "est­il acceptable de perdre des données ?" est rarement "oui". Si exceptionnellement, la
réponse est "oui", il faut déterminer jusqu’à quelle limite : 1 jour, 2 jours, 1 semaine ?
Il est également nécessaire de déterminer la nature de l’activité sur la base :
●
●
Les données sont­elles mises à jour quotidiennement par les utilisateurs ? C’est typiquement le cas dans une
application transactionnelle.
Les données sont­elles mises à jour périodiquement (toutes les nuits, toutes les semaines) et simplement
consultées dans la journée ? C’est typiquement le cas avec une application décisionnelle.
2. L’archivage des fichiers de journalisation
Comme nous l’avons déjà vu, les fichiers de journalisation constituent un journal des modifications apportées à la
base. Ils sont organisés en groupes écrits de manière circulaire : les informations sauvegardées sont donc par défaut
périodiquement écrasées.
Ces fichiers de journalisation peuvent être réappliqués à une sauvegarde de fichier de données, pour rejouer toutes
les modifications survenues entre la sauvegarde et un incident ayant endommagé le fichier (restauration de média), à
condition d’avoir conservé tous les fichiers de journalisation ; ceci est possible en faisant fonctionner la base de
données en mode ARCHIVELOG. Ce mode de fonctionnement permet de garantir zéro perte de données en cas
d’incident sur un fichier de données.
Le principe de récupération en mode ARCHIVELOG est le suivant :
© ENI Editions - All rights reserved - Algeria Educ
- 1-
À un instant T0, une sauvegarde d’un fichier de données est réalisée. Après T0, l’activité de mise à jour se poursuit,
générant des entrées dans les fichiers de journalisation. L’archivage étant activé, les fichiers de journalisation pleins
sont archivés.
À l’instant T1, un incident se produit et le fichier de données est perdu. La récupération du fichier de données
consiste à prendre la dernière sauvegarde du fichier (qui ne contient évidemment pas les modifications effectuées
depuis) et à appliquer sur cette sauvegarde les fichiers de journalisation archivés (qui eux, contiennent la trace des
modifications apportées depuis la dernière sauvegarde), afin de ramener le fichier de données dans l’état où il se
trouvait juste avant l’incident (pour être plus précis, dans l’état de la dernière transaction validée).
3. Solutions de sauvegarde et récupération
Pour effectuer des sauvegardes et des récupérations, vous avez deux possibilités :
●
utiliser l’outil Recovery Manager (RMAN) fourni par Oracle : c’est la méthode recommandée ;
●
procéder "à la main" avec des commandes du système d’exploitation et des scripts SQL.
RMAN est un outil ligne de commande qui facilite grandement les opérations de sauvegarde et de récupération, en
limitant notamment les risques de fausse manoeuvre. RMAN peut être utilisé à travers une interface graphique dans
le Database Control. Toutes les opérations de sauvegarde et de récupération présentées dans cet ouvrage sont
basées sur l’utilisation du Recovery Manager.
4. Stratégies de sauvegarde disponibles
Une sauvegarde peut être cohérente ou incohérente.
Une sauvegarde cohérente est une sauvegarde de la totalité de la base de données après un arrêt propre de la
base de données (pas après un SHUTDOWN ABORT ou un arrêt anormal de l’instance) ; ce type de sauvegarde est aussi
souvent appelé "sauvegarde base fermée". Après un arrêt propre de la base de données, toutes les modifications
ont été écrites dans les fichiers de données qui sont bien synchrones. Une base de données restaurée à partir d’une
sauvegarde cohérente peut être ouverte immédiatement : il est inutile d’appliquer les fichiers de journalisation. C’est
le seul mode de sauvegarde disponible lorsque la base de données fonctionne en mode NOARCHIVELOG.
Une sauvegardeincohérente est une sauvegarde effectuée alors que la base de données est ouverte et que l’activité
de mise à jour se poursuit pendant la sauvegarde ; ce type de sauvegarde est aussi souvent appelé "sauvegarde
base ouverte". Les fichiers sauvegardés ne sont pas synchrones du point de vue des modifications enregistrées.
Lorsqu’une base de données est restaurée à partir d’une sauvegarde incohérente, il faut appliquer les fichiers de
journalisation pour rendre les fichiers cohérents. Les sauvegardes incohérentes ne sont possibles que lorsque la
base de données fonctionne en mode ARCHIVELOG.
Une sauvegarde peut être complète, partielle ou incrémentale. Une sauvegarde complète est une sauvegarde de
la totalité de la base de données. Une sauvegarde partielle est une sauvegarde incluant uniquement une partie de
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
la base de données. Les sauvegardes partielles sont forcément incohérentes entre elles. Pour qu’elles soient
exploitables en restauration (ce qui est normalement l’objectif), il faut que la base de données fonctionne en mode
ARCHIVELOG. Une sauvegarde incrémentale est une sauvegarde qui ne contient que les blocs modifiés depuis la
dernière sauvegarde ; une sauvegarde incrémentale peut être complète ou partielle.
Une sauvegarde cohérente complète nécessite de pouvoir arrêter la base de données et la sauvegarder en totalité
pendant l’arrêt.
5. Quelle stratégie pour le mode de fonctionnement de la base ?
Le tableau suivant résume les possiblités :
Pertes de données acceptables
Sauvegarde base
fermée possible
Oui
Non
Oui
ARCHIVELOG
NOARCHIVELOG
ARCHIVELOG
Non
ARCHIVELOG
ARCHIVELOG
Le mode ARCHIVELOG est obligatoire si au moins une des contraintes suivantes existe :
●
Aucune perte de donnée n’est autorisée.
●
La base de données ne peut pas être fermée pour être sauvegardée.
Le mode NOARCHIVELOG est possible si :
●
Des pertes de données sont acceptables.
●
La base de données peut être fermée pour être sauvegardée.
Un autre avantage du mode ARCHIVELOG est que la base de données peut rester ouverte lorsqu’un incident survient
sur un fichier de données qui n’appartient ni au tablespace SYSTEM, ni au tablespace UNDO actif.
6. Quelle stratégie pour la sauvegarde ?
La première règle est de réaliser des sauvegardes fréquentes (au minimum tous les jours) et de conserver plusieurs
cycles de sauvegarde (en cas de problème avec une sauvegarde).
Si la base de données fonctionne en mode ARCHIVELOG, vous pouvez réaliser des sauvegardes bases ouvertes ; il n’y
a pas de raison de s’en priver.
Si la durée de sauvegarde et la taille des sauvegardes ne posent pas de problème (même en conservant plusieurs
sauvegardes), vous pouvez réaliser systématiquement (tous les jours) des sauvegardes complètes.
Si la durée de sauvegarde et/ou la taille des sauvegardes posent un problème, vous pouvez réaliser des
sauvegardes incrémentales et/ou des sauvegardes partielles. Dans le cas de sauvegardes partielles, vous devez
simplement être très rigoureux dans le suivi et veiller à tout sauvegarder sur un cycle complet de sauvegardes
partielles.
Il est important de réaliser des sauvegardes très fréquemment pour pouvoir procéder à une restauration en un
temps raisonnable : partir d’une sauvegarde datant d’un mois et réappliquer tous les fichiers de journalisation
archivés depuis un mois risque de se révéler très long si la base de données est activement mise à jour.
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Archivage des fichiers de journalisation
1. Vue d’ensemble
Activer l’archivage des fichiers de journalisation s’effectue en mettant la base de données dans le
modeARCHIVELOG : ce mode permet de garantir qu’un groupe de fichiers de journalisation ne sera pas réutilisé tant
qu’il n’a pas été archivé.
Depuis la version 10, placer la base de données en mode ARCHIVELOG démarre automatiquement deux processus
d’archivage (ARC0 et ARC1) lors de l’ouverture de la base de données ; dans les versions précédentes, il fallait le faire
explicitement. Par contre, il est toujours opportun, même en version 10, de positionner certains paramètres
d’initialisation qui concernent les processus d’archivage.
La base de données peut être créée d’entrée de jeu en mode ARCHIVELOG. Généralement, la base de données est
créée en mode NOARCHIVELOG puis passée en ARCHIVELOG. Archiver les fichiers de journalisation générés par la création
de la base de données présente un faible intérêt (mais un volume d’archives important).
2. Mode opératoire
Le mode opératoire est le suivant :
●
SQL>
2
3
SQL>
2
3
●
Modifier dans le fichier de paramètres serveur les paramètres d’initialisation qui concernent les processus
d’archivage
ALTER SYSTEM SET
log_archive_format=’redo_%S_%R_%T.arc’
SCOPE=SPFILE;
ALTER SYSTEM SET
log_archive_dest_1=’LOCATION=h:\oradata\arch\HERMES’
SCOPE=SPFILE;
Arrêter proprement la base de données (pas ABORT)
SQL> SHUTDOWN IMMEDIATE
●
Monter la base de données
SQL> STARTUP MOUNT
●
Passer la base de données en mode ARCHIVELOG
SQL> ALTER DATABASE ARCHIVELOG;
●
●
Sauvegarder la base de données (permet une sauvegarde T0 du nouveau mode de fonctionnement de la
base de données)
Ouvrir la base de données
SQL> ALTER DATABASE OPEN;
Le mode ARCHIVELOG/NOARCHIVELOG est une propriété de la base qui se modifie par l’ordre SQL ALTER
DATABASE. Ce mode de fonctionnement est mémorisé dans le fichier de contrôle de la base de données ; il
n’est pas nécessaire de le repréciser à chaque démarrage.
L’ordre SQL ALTER DATABASE NOARCHIVELOGpermet, au besoin, de repasser en mode NOARCHIVELOG.
3. Les paramètres du processus d’archivage
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
LOG_ARCHIVE_FORMAT
Ce paramètre définit le format souhaité pour le nom des archives.
Le format doit inclure les variables suivantes :
%s ou %S
Numéro de séquence du fichier de journalisation.
%t ou %T
Numéro d’instance (thread).
%r ou %R
Identifiant de remise à zéro des fichiers de journalisation (voir la section Récupération).
Lorsque le nom de la variable est en majuscules, le nombre est complété à gauche par des 0.
Exemple :
LOG_ARCHIVE_FORMAT = "redo_%S_%R_%T.arc"
LOG_ARCHIVE_DEST et LOG_ARCHIVE_DUPLEX_DEST
Le paramètre LOG_ARCHIVE_DEST définit une première destination de l’archivage et le paramètre
LOG_ARCHIVE_DUPLEX_DEST une deuxième destination d’archivage (dupliquée). Ces paramètres sont utilisables en
Standard Edition.
Syntaxe
LOG_ARCHIVE_[DUPLEX_]DEST = "chemin_local"
Exemple :
LOG_ARCHIVE_DEST = "h:\oradata\arch\HERMES"
LOG_ARCHIVE_DEST_n (n de 1 à 10)
Ces paramètres définissent jusqu’à 10 destinations parallèles d’archivage. Ils sont utilisables uniquement en
Enterprise Edition.
Syntaxe simplifiée pour une destination locale (au moins une obligatoire)
LOG_ARCHIVE_DEST_n = "LOCATION=chemin_local"
Exemple :
LOG_ARCHIVE_DEST_1 = "LOCATION=h:\oradata\arch\HERMES"
Les paramètres LOG_ARCHIVE_DEST_n permettent de spécifier plusieurs destinations parallèles pour les
archives ; parmi les destinations, une au moins doit être locale. En dehors d’une destination disque ou bande, il est
possible de désigner une base de secours comme cible (configuration Data Guard) ; cette technique avancée permet
d’avoir une base de données sur un deuxième serveur vers laquelle il est possible de basculer en cas de problème
sur la base de données source : la base de données de secours est mise à jour par transfert et application des
fichiers de journalisation archivés.
Dans la spécification de la destination, il ne faut pas mettre d’espace autour du signe = dans la clause
LOCATION.
D’autres paramètres permettent de piloter le fonctionnement des destinations multiples (destinations obligatoires,
facultatives, nombre minimum de destinations réussies, etc.).
Remarques sur les destinations d’archivage
- 2-
© ENI Editions - All rights reserved - Algeria Educ
L’archivage direct sur bande pouvant être long (et bloquer >LGWR si l’archivage d’un fichier de journalisation n’est
pas terminé), une technique classique consiste à archiver sur disque, au niveau d’Oracle, puis à transférer les
archives sur bande au niveau du système d’exploitation (par un processus non Oracle à mettre en place).
Les répertoires de destination ne sont pas créés par Oracle ; c’est à vous de le faire.
Si aucune destination d’archivage n’est définie, mais qu’une zone de récupération rapide soit spécifiée (paramètre
DB_RECOVERY_FILE_DEST), la zone de récupération rapide est utilisée comme destination d’archivage.
ARCHIVE_LAG_TARGET
Ce paramètre permet de définir une durée maximale en secondes entre deux archivages.
Une valeur nulle désactive la fonctionnalité (valeur par défaut). Les valeurs autorisées sont comprises entre 60 (une
minute) et 7 200 (2 heures). Ce paramètre permet de forcer l’archivage de façon périodique et donc de garantir une
périodicité d’archivage stable, indépendante de la fréquence de basculement des fichiers de journalisation qui peut
varier en fonction du moment de la journée.
Exemple :
ARCHIVE_LAG_TARGET = 1800 # 30 minutes
S’il n’y a rien à archiver, Oracle ne génère pas d’archive.
À l’origine, ce paramètre est destiné au fonctionnement de l’instance dans une configuration Data Guard. Dans cette
configuration, le paramètre ARCHIVE_LAG_TARGET détermine la durée maximale d’informations de journalisation qui
seraient perdues (non transférées sur la base de données de secours) en cas de plantage de la base de données
principale.
Le paramètre fonctionne même si la configuration Data Guard n’est pas utilisée, et même s’il n’y a pas
archivage ; dans ce dernier cas, le paramètre conditionne la fréquence de basculement des fichiers de journalisation.
4. Trouver des informations sur l’archivage
Dans SQL*Plus, vous pouvez utiliser la commande ARCHIVE LOG LIST(dans une connexion SYSDBA) pour obtenir des
informations sur l’archivage ;
SQL> CONNECT / AS SYSDBA
Connecté.
SQL> ARCHIVE LOG LIST
mode Database log
mode Archive
Archivage automatique
Activé
Destination de l’archive
h:\oradata\arch\HERMES
Séquence de journal en ligne la plus ancienne
19
Séquence de journal suivante à archiver
21
Séquence de journal courante
21
Plusieurs vues du dictionnaire de données permettent d’obtenir des informations sur l’archivage :
●
V$DATABASE : mode de fonctionnement de la base de données (colonne LOG_MODE) ;>
●
V$LOG : statut des groupes vis­à­vis de l’archivage (colonne ARCHIVED) ;<
●
V$ARCHIVED_LOG : informations sur les fichiers de journalisation archivés ;
●
V$ARCHIVE_DEST : informations sur les destinations d’archivage.
Les colonnes intéressantes de la vue V$ARCHIVED_LOG sont les suivantes :
RECID
Identifiant de l’enregistrement.
NAME
Chemin complet de l’archive.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
SEQUENCE#
Numéro de séquence du fichier de journalisation correspondant.
FIRST_CHANGE#
Plus petit numéro SCN écrit dans l’archive.
FIRST_TIME
Date et heure du plus petit numéro SCN.
NEXT_CHANGE#
Plus grand numéro SCN écrit dans l’archive.
NEXT_TIME
Date et heure du plus grand numéro SCN.
COMPLETION_TIME
Date et heure de l’archivage.
Les colonnes intéressantes de la vue V$ARCHIVE_DEST sont les suivantes :
DEST_NAME
Nom de la destination.
DESTINATION
Chemin de la destination.
STATUS
Statut de la destination (VALID, ERROR, etc.).
ERROR
Message d’erreur (en cas d’erreur).
Exemple :
SQL> SELECT log_mode FROM v$database;
LOG_MODE
-----------ARCHIVELOG
SQL> SELECT group#,sequence#,status,archived
2 FROM v$log;
GROUP# SEQUENCE# STATUS
ARC
---------- ---------- ---------------- --1
25 INACTIVE
YES
2
26 CURRENT
NO
3
24 INACTIVE
YES
SQL> SELECT sequence#,name FROM v$archived_log;
SEQUENCE# NAME
---------- ---------------------------------------------------20 H:\ORADATA\ARCH\HERMES\REDO_00020_0545650779_001.ARC
...
SQL> SELECT destination,status,error FROM v$archive_dest
2 WHERE dest_name=’LOG_ARCHIVE_DEST_1’;
- 4-
© ENI Editions - All rights reserved - Algeria Educ
DESTINATION
--------------------------------------------------------STATUS
ERROR
--------- ----------------------------------------------h:\oradata\arch\HERMES
ERROR
ORA-19504: échec de création du fichier ""
5. Problème courant et solution
L’archivage peut être bloqué lorsqu’il y a un problème avec la destination d’archivage :
●
plus d’espace disponible ;
●
destination inaccessible.
Cela peut conduire à un blocage de LGWR si tous les fichiers de journalisation en ligne ont besoin d’être archivés.
Une telle situation est détectable grâce à la vue V$ARCHIVE_DEST (colonne STATUS) ou par des messages dans le fichier
des alertes de l’instance :
Sun Aug 3 12:43:25 2008
Errors in file d:\oracle\admin\hermes\bdump\hermes_arc1_1504.trc:
ORA-19504: échec de création du fichier "H:\ORADATA\ARCH\HERMES\
REDO_00029_0545650779_001.ARC"
ORA-27044: impossible d’écrire le bloc d’en-tête du fichier
OSD-04008: échec de Writefile() ; écriture impossible dans le fichier
O/S-Error: (OS 112) Espace insuffisant sur le disque.
Pour débloquer la situation, il suffit de résoudre le problème qui existe sur la destination d’archivage, par exemple en
déplaçant des archives vers une autre destination afin de libérer de l’espace.
Si vous ne pouvez pas résoudre le problème avec la destination d’archivage, modifiez temporairement la destination
d’archivage :
ALTER SYSTEM SET
log_archive_dest_1=’LOCATION=d:\temp’
SCOPE=MEMORY;
Il peut être nécessaire ensuite d’exécuter l’ordre SQL ALTER SYSTEM ARCHIVE LOG START pour relancer le processus
d’archivage.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 5-
Présentation du Recovery Manager
1. Introduction
RMAN est un outil ligne de commande qui permet de réaliser des sauvegardes et des récupérations d’une base de
données appelée base de données cible (target database).
RMAN utilise un référentiel (repository) pour stocker des informations sur sa configuration, les sauvegardes réalisées,
la structure de la base cible, les fichiers de journalisation archivés, etc.
Ce référentiel est toujours stocké dans le fichier de contrôle de la base cible. La durée de conservation des
informations
dans
le
fichier
de
contrôle
est
déterminée
par
le
paramètre
d’initialisation
CONTROL_FILE_RECORD_KEEP_TIME (7 jours par défaut).
Le référentiel peut aussi être stocké dans un catalogue de récupération (recovery catalog) qui se matérialise par un
schéma dans une autre base de données. Un seul catalogue de récupération peut être utilisé pour centraliser les
référentiels RMAN de plusieurs bases de données cibles. Employer un catalogue de récupération séparé est
intéressant car les informations de sauvegarde sont préservées si tous les fichiers de contrôle de la base cible sont
perdus.
Les fichiers de contrôle sont donc encore plus importants lorsque vous utilisez RMAN sans catalogue de
récupération. Si vous perdez tous les fichiers de contrôle de la base cible, RMAN n’a plus d’informations sur
les sauvegardes disponibles. Si vous repartez d’une sauvegarde de fichier de contrôle, RMAN n’aura pas
d’informations sur les sauvegardes réalisées après la sauvegarde du fichier de contrôle. Si vous n’utilisez pas de
catalogue de récupération, vous avez également intérêt à augmenter la valeur du paramètre
CONTROL_FILE_RECORD_KEEP_TIME (au moins 10 à 15 jours).
Si vous définissez une zone de récupération rapide (flash recovery area), à l’aide des paramètres
DB_RECOVERY_FILE_DEST et DB_RECOVERY_FILE_DEST_SIZE, vous pouvez bénéficier des fonctionnalités de sauvegarde et
de restauration automatiques sur disque proposées par RMAN. En complément, vous pouvez définir une politique de
conservation (retention policy) indiquant combien de temps une sauvegarde doit être conservée. RMAN se charge
alors de gérer l’espace de la zone de récupération rapide en supprimant, si nécessaire, les sauvegardes obsolètes ou
les sauvegardes recopiées sur bande.
Pour chaque opération de sauvegarde, copie, restauration, RMAN utilise un canal (channel). Un canal est une
connexion entre le client RMAN et un processus serveur de la base de données cible qui accède à un périphérique
(disque ou bande).
Une sauvegarde RMAN peut se faire sous la forme d’une copie image (image copy) ou d’un jeu de sauvegarde
(backup set). Une copie image est une copie à l’identique du fichier (analogue à une copie par une commande du
système d’exploitation). Un jeu de sauvegarde contient un ou plusieurs fichiers sauvegardés. Un jeu de sauvegarde
comprend un ou plusieurs fichiers ; chaque fichier d’un jeu est appelé élément de sauvegarde (backup piece). Par
défaut, un jeu de sauvegarde comprend un seul élément de sauvegarde, mais il est possible de limiter la taille de ces
éléments ; dans ce cas, un jeu de sauvegarde peut contenir plusieurs éléments de sauvegarde si la taille totale de la
sauvegarde est supérieure à la limite. Le jeu de sauvegarde a un format propriétaire RMAN.
Pour réaliser des sauvegardes sur bande, RMAN s’interface avec un logiciel de gestion de média fourni par le vendeur
du système de sauvegarde.
RMAN offre un très grand nombre de fonctionnalités et d’options et peut être utilisé de différentes manières. Dans cet
ouvrage, nous présenterons les fonctionnalités de base de RMAN, nécessaires et suffisantes pour mettre en place
des stratégies de sauvegarde/récupération simples, adaptées à un grand nombre de cas. Nous supposerons
notamment qu’une zone de récupération rapide a été définie, ce qui permet de simplifier un grand nombre
d’opérations, et qu’aucun catalogue de récupération séparé n’a été mis en place.
Les fonctionnalités de base de RMAN sont décrites dans la documentation Oracle® Database Backup and Recovery
User’s Guide.
2. Lancer RMAN
Pour lancer RMAN, il suffit d’exécuter la commande rman à l’invite du système d’exploitation.
Syntaxe
rman [liste_options]
Les options suivantes peuvent être utilisées :
© ENI Editions - All rights reserved - Algeria Educ
- 1-
TARGET [=] connexion
Chaîne de connexion à la base de données cible.
CATALOG [=] connexion
Chaîne de connexion à la base de données du catalogue de récupération.
CMDFILE [=] fichier
Chemin vers un fichier contenant des commandes RMAN à exécuter.
LOG [=] fichier
Chemin vers un fichier journal de l’activité RMAN.
APPEND
Indique que le fichier journal doit être ouvert en mode ajout.
USING valeur [...]
Définit une ou plusieurs valeurs pour des variables de substitution qui peuvent être utilisées dans un fichier de
commandes RMAN. Dans le fichier de commande RMAN, les variables de substitution sont définies par la syntaxe &n
(éventuellement suivi d’un point), n étant un entier.
Les principes de connexion à la base cible sont les mêmes qu’avec SQL*Plus : utilisation par défaut des
variables d’environnement (ORACLE_SID, LOCAL, TWO_TASK), utilisation d’un nom de service réseau, etc. Les
variables d’environnement comme NLS_DATE_FORMATetNLS_LANG influent aussi sur le format des dates et la langue
des messages affichés par RMAN. Par ailleurs, la connexion à la base cible s’effectue implicitement AS SYSDBA.
Exemple :
●
Lancer RMAN sans se connecter
> rman
Recovery Manager: Release 11.1.0.6.0 - Production
on Lun. Août 4 07:37:14 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
RMAN>
●
Lancer RMAN en se connectant à la base cible (utilisation des variables d’environnement et authentification
SYSDBA par le système d’exploitation)
> rman target /
Recovery Manager: Release 11.1.0.6.0 - Production
on Lun. Août 4 07:48:22 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connecté à la base de données cible : H E R M E S ( D B I D = 3 5 3 5 8 9 2 6 4 7 )
●
Lancer RMAN en se connectant à la base cible (utilisation d’un nom de service réseau et authentification
SYSDBA par un fichier de mot de passe)
> rman target sys/wX#12@hermes
...
●
Lancer RMAN et exécuter un fichier de commande (qui effectue la connexion)
> rman cmdfile=backup.rcv log=backup.log append
...
Si vous n’utilisez pas l’option CMDFILE, RMAN est lancé en mode interactif ; il affiche une invite et vous pouvez saisir
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
des commandes. Avec l’option CMDFILE, RMAN est lancé en mode batch ; il exécute les commandes contenues dans le
fichier de commande puis quitte.
Chaque base de données possède un identifiant unique appelé DBID. Le DBID de la base cible est affiché par
RMAN lorsque vous vous connectez. Vous avez intérêt à noter ce DBID quelque part, il peut en effet se
révéler utile pour certaines opérations.
3. Quelques commandes utiles
Certaines commandes RMAN doivent se terminer par un point­virgule, d’autres non (point­virgule optionnel). Les
commandes RMAN nécessitant un point­virgule peuvent être saisies sur plusieurs lignes, les autres non. Les
commandes RMAN sont saisies indifféremment en majuscules ou en minuscules.
Les commandes suivantes peuvent être utilisées dans RMAN :
@fichier
Exécute un fichier de commande.
@@fichier
Exécute un fichier de commande dans le même répertoire que le fichier de commande actuel.
SET ECHO ON | OFF
Active ou désactive l’écho des commandes.
SPOOL LOG TO fichier [APPEND]
Écrit la sortie RMAN dans un fichier.
SPOOL LOG OFF
Arrête l’écriture de la sortie RMAN dans un fichier.
STARTUP [option]
Démarre la base de données ; les options sont les mêmes que dans SQL*Plus.
SHUTDOWN [option]
Arrête la base de données ; les options sont les mêmes que dans SQL*Plus.
ALTER DATABASE MOUNT | OPEN ;
Monte ou ouvre une base de données.
CONNECT CATALOG connexion
Établit une connexion à la base de données du catalogue.
CONNECT TARGET connexion
Établit une connexion à la base de données cible.
HOST [’commande’] ; HOST ["commande"] ;
Exécute une commande du système d’exploitation ou ouvre une session du système d’exploitation (si aucune
commande n’est spécifiée).
SQL ’requête’ ; SQL "requête" ;
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Exécute une requête SQL sur la base de données cible. La requête ne doit pas se terminer par un point­virgule ; si
elle contient des apostrophes, elles doivent être doublées.
EXIT ou QUIT
Quitte RMAN.
Exemple de script RMAN:
# ceci est un commentaire
SPOOL LOG TO d:\rman.log
SET ECHO ON
CONNECT TARGET /
SHUTDOW MOUNT
SQL "ALTER DATABASE ARCHIVELOG";
ALTER DATABASE OPEN;
SPOOL LOG OFF
SET ECHO OFF
Si vous souhaitez placer un commentaire en fin de ligne, vous devez terminer la commande par un point­virgule
(même si le point­virgule est optionnel pour la commande).
Par ailleurs, il est possible de grouper des commandes RMAN dans un bloc délimité par des accolades et d’exécuter ce
bloc avec la commande RUN :
RUN
{
...
}
Certaines commandes (ALLOCATE CHANNEL, SET) exécutées à l’intérieur d’un bloc ont une portée limitée au bloc. Par
ailleurs, si une commande du bloc échoue, l’exécution du bloc s’arrête.
Certaines commandes RMAN doivent être exécutées à l’intérieur d’un bloc (ALLOCATE CHANNEL par exemple) ; d’autres
ne peuvent pas être exécutées dans un bloc (SPOOL par exemple).
4. Configurer RMAN
RMAN dispose de plusieurs réglages persistants utilisés par défaut lors des différentes opérations.
La configuration actuelle peut être visualisée en exécutant la commande SHOW ALL.
Exemple :
RMAN> SHOW ALL ;
utilisation du fichier de contrôle de la base
de données cible au lieu du catalogue de récupération
les paramètres de configuration RMAN de la base
de données ayant le db_unique_name HERMES sont les suivants :
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ’%F’; #
default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM ’AES128’; # default
CONFIGURE COMPRESSION ALGORITHM ’BZIP2’; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO ’D:\APP\ORACLE\PRODUCT\11.1.0\DB_1\
DATABASE\SNCFHERMES.ORA’; # default
Le commentaire # default indique que le paramètre est égal à sa valeur par défaut.
- 4-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
La commande CONFIGURE permet de modifier les réglages persistants ; la commande SHOW ALL montre la valeur des
réglages en utilisant la syntaxe de la commande CONFIGURE.
Les principaux réglages sont les suivants :
Configurer les canaux et les périphériques
Par défaut, le périphérique utilisé est le disque (paramètre DEFAULT DEVICE TYPE), la destination par défaut des
sauvegardes étant la zone de récupération rapide. Si cette dernière n’est pas définie, RMAN utilise une destination
par défaut qui dépend de la plate­forme.
Si vous souhaitez configurer la destination de sauvegarde, vous pouvez utiliser la commande suivante :
CONFIGURE CHANNEL DEVICE TYPE DISK options ;
La clause options peut prendre une ou plusieurs valeurs dont :
FORMAT ’format’
Chemin et format de nom de fichier pour la sauvegarde.
MAXPIECESIZE taille [K|M|G]
Taille maximale des éléments de sauvegarde. Aucune limite par défaut.
Exemple :
CONFIGURE CHANNEL DEVICE TYPE DISK
FORMAT ’h:\backup\%U’
MAXPIECESIZE 2G ;
Dans cet exemple, la taille des éléments de sauvegarde est limitée à 2 Go. Si la taille de la sauvegarde est supérieure
à 2 Go, le jeu de sauvegarde contiendra plusieurs éléments de sauvegarde.
L’option format comprend un chemin et un format de fichier. Le format de fichier utilise généralement une ou plusieurs
des variables suivantes :
%U
Nom de fichier unique dont la composition dépend de la nature de la sauvegarde :
­ %u_%p_%c pour un élément de sauvegarde ;
­ data-D-%d_id-%I_TS-%N_FNO-%f_%u pour une copie image d’un fichier de données ;
­ arch-D_%d-id-%I_S-%e_T-%h_A-%a_%u pour une copie image d’un fichier de journalisation archivé ;
­ cf-D_%d-id-%I_%u pour une copie image du fichier de contrôle.
%d
Nom de la base de données.
%I
Identifiant de la base de données (DBID).
%h
Numéro d’activation de la base de données.
%N
Nom du tablespace.
%f
Numéro de fichier de données.
© ENI Editions - All rights reserved - Algeria Educ
- 5-
%e
Numéro de séquence du fichier de journalisation archivé.
%h
Numéro d’instance (thread) du fichier de journalisation archivé.
%s
Numéro du jeu de sauvegarde (backup set).
%p
Numéro de l’élément de sauvegarde (backup piece) à l’intérieur d’un jeu de sauvegarde.
%c
Numéro de copie de l’élément de sauvegarde (cas d’une sauvegarde multiplexée). 1 si la sauvegarde n’est pas
multiplexée.
%u
Chaîne unique de 8 caractères basée sur le numéro du jeu de sauvegarde ou de la copie image et de la date/heure
de la sauvegarde/copie.
Si vous utilisez des formats personnalisés, assurez­vous que le nom de fichier généré est unique, sous peine
d’écraser d’autres sauvegardes.
Dans la commande CONFIGURE CHANNEL DEVICE TYPE DISK, une option non spécifiée est remise à sa valeur par
défaut ; la valeur précédente n’est pas conservée.
Pour modifier la taille maximale des éléments de sauvegarde, en remettant le format par défaut, vous pouvez utiliser
la commande suivante :
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 4G ;
Pour revenir à la configuration par défaut, vous pouvez employer la commande suivante :
CONFIGURE CHANNEL DEVICE TYPE DISK CLEAR ;
Configurer la politique de conservation
La politique de conservation peut être définie en termes de fenêtre de restauration ou de redondance.
Une fenêtre de restauration indique jusqu’à combien de jours dans le passé vous souhaitez pouvoir revenir. Une
redondance indique combien de sauvegardes de chaque fichier doivent être conservées ; c’est la politique par défaut
(avec une redondance de 1).
Pour définir la politique de conservation, utilisez une des commandes suivantes :
●
Fenêtre de restauration
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF n DAYS ;
●
Redondance
CONFIGURE RETENTION POLICY TO REDUNDANCY n ;
Lorsque la zone de récupération rapide est utilisée, RMAN supprime automatiquement les sauvegardes obsolètes (s’il
a besoin de place), en s’appuyant sur la politique de conservation par défaut et sur la taille allouée à la zone de
récupération rapide (paramètre DB_RECOVERY_FILE_DEST_SIZE).
Pour revenir à la configuration par défaut, vous pouvez utiliser la commande suivante :
- 6-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
CONFIGURE RETENTION POLICY CLEAR ;
Configurer la sauvegarde automatique du fichier de contrôle
La sauvegarde automatique du fichier de contrôle peut être activée grâce à la commande suivante :
CONFIGURE CONTROLFILE AUTOBACKUP ON ;
Lorsque la sauvegarde automatique du fichier de contrôle est activée, le fichier de contrôle est, par défaut,
sauvegardé dans la zone de récupération rapide.
Si vous souhaitez définir une destination de sauvegarde par défaut spécifique, vous pouvez utiliser la commande
suivante :
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ’format’ ;
L’option format ne peut et ne doit inclure que la variable %F (nom unique basé sur l’identifiant de la base de données,
la date et un numéro de séquence hexadécimal). Remplacez TO ’format’ par CLEAR pour revenir au format par défaut.
Activer la sauvegarde automatique du fichier de contrôle active aussi la sauvegarde automatique du fichier de
paramètres serveur. Lorsque la sauvegarde automatique est activée, ces deux fichiers sont automatiquement
sauvegardés à chaque fois qu’une modification de structure de la base de données ou une sauvegarde RMAN est
enregistrée dans le fichier de contrôle.
Activer la sauvegarde automatique du fichier de contrôle est vivement conseillé, surtout si vous n’utilisez pas
de catalogue de récupération séparé pour RMAN. En cas de perte de tous les fichiers de contrôle, RMAN
pourra restaurer ces derniers à partir d’une sauvegarde automatique.
5. Utilisation de la zone de récupération rapide
Oracle conseille vivement d’utiliser une zone de récupération rapide pour bénéficier d’un certain nombre de
fonctionnalités automatiques relatives aux opérations de sauvegarde et de récupération.
Si une zone de récupération rapide est configurée, elle est utilisée comme destination par défaut des sauvegardes et
de plusieurs autres fichiers (par exemple, les fichiers de journalisation archivés si aucune destination d’archivage
n’est définie).
Le quota d’espace alloué à la zone de récupération rapide (paramètre DB_RECOVERY_ FILE_DEST_SIZE) doit être
spécifié avec soin, en tenant compte de la taille des fichiers qui y sont stockés (sauvegardes notamment) et de la
politique de conservation des sauvegardes.
Du point de vue de la sécurité, il est vivement conseillé d’utiliser un disque séparé pour la zone de
récupération rapide.
Les fichiers générés par Orale dans la zone de récupération rapide sont stockés dans différents sous­répertoires,
avec des formats de nom de fichiers spécifiques. Ce sont des fichiers "gérés par Oracle" (Oracle­Managed Files).
Les différents répertoires sont définis sous la forme suivante :
●
<DB_UNIQUE_NAME>/<type>[/<date>] (Unix/Linux) ;
●
<DB_UNIQUE_NAME>\<TYPE>[\<date>] (Windows).
Avec :
<DB_UNIQUE_NAME>
Nom unique de la base de données tel que défini par le paramètre DB_UNIQUE_NAME (par défaut égal au paramètre>
DB_NAME).
<type>
Sous­répertoire correspondant au type de fichier : archivelog (fichier de journalisation archivé), autobackup
(sauvegarde automatique du fichier de contrôle et du fichier de paramètres serveur), backupset (jeu de sauvegarde),
© ENI Editions - All rights reserved - Algeria Educ
- 7-
controlfile (copie image de fichier de contrôle), datafile (copie image de fichier de données).
<TYPE>
Identique à <type> mais en majuscules.
<date>
Sous­répertoire correspondant à la date (au format AAAA_MM_JJ). N’existe pas pour les répertoires controlfile et
datafile.
Les règles de nommage des fichiers gérés par Oracle sont les suivantes :
Type de fichier
Format
Fichier de journalisation archivé
o1_mf_<i>_<s>_<u>_.log
Copie image de fichier de données
o1_mf_<t>_<u>_.dbf
Copie image de fichier de contrôle
o1_mf_<a>_<u>_.ctl
Jeu de sauvegarde
o1_mf_<c>_<a>_<u>_.bkp
Sauvegarde automatique
o1_mf_s_<h>_<u>_.bkp
Avec :
<t>
nom du tablespace ;
<u>
chaîne de 8 caractères qui garantit l’unicité ;
<g>
numéro de groupe pour les fichiers de journalisation ;
<i>
numéro d’instance (thread) pour les fichiers de journalisation archivés ;
<s>
numéro de séquence pour les fichiers de journalisation archivés ;
<a>
nom donné à la sauvegarde (option TAG de la commande BACKUP) ;
<c>
chaîne de 5 caractères correspondant au contenu du jeu de sauvegarde ;
<h>
horodatage de la sauvegarde automatique (nombre de secondes écoulées depuis une date interne fixe).
Exemple :
H:\ORADATA\FLASH_RECOVERY_AREA\HERMES
ARCHIVELOG
- 8-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
2008_08_05
O1_MF_1_35_49HPDHY8_.ARC
AUTOBACKUP
2008_08_05
O1_MF_S_661934919_49HPX9N0_.BKP
BACKUPSET
2008_08_05
O1_MF_NNNDF_TAG20080805T064838_49HPX6TV_.BKP
CONTROLFILE
O1_MF_TAG20080805T065123_49HQ2C9R_.CTL
DATAFILE
O1_MF_TEST_49HQ0498_.DBF
La même zone de récupération rapide peut être partagée par plusieurs bases de données, sous réserve que ces
dernières aient un nom unique de base de données (paramètre DB_UNIQUE_NAME) différent.
6. La commande VALIDATE
La commande VALIDATE peut être utilisée dans différentes situations (à titre préventif, avant une sauvegarde, avant
une restauration, etc.) pour détecter d’éventuels problèmes de corruption ou de fichiers manquants.
Syntaxe simplifiée
VALIDATE quoi ;
La clause quoi peut prendre une des valeurs suivantes (non exhaustif) :
DATABASE
Vérification de la totalité de la base de données (fichiers de données, fichiers de contrôle et fichier de paramètre
serveur).
TABLESPACE liste_noms
Vérification d’un ou plusieurs tablespaces.
DATAFILE liste_numéros_ou_noms
Vérification d’un ou plusieurs fichiers de données.
CURRENT CONTROLFILE
Vérification du fichier de contrôle courant.
SPFILE
Vérification du fichier de paramètres serveur.
ARCHIVELOG ALL
Vérification de tous les fichiers de journalisation archivés (ALL peut être remplacé par différentes clauses permettant
de sélectionner les fichiers de journalisation archivés à vérifier).
BACKUPSET liste_clés
Vérification d’un ou plusieurs jeux de sauvegarde.
RECOVERY AREA
Vérification de tous les fichiers stockés dans la zone de récupération rapide.
Exemples
VALIDATE DATABASE ;
© ENI Editions - All rights reserved - Algeria Educ
- 9-
VALIDATE DATAFILE 1,’E:\ORADATA\HERMES\DATA01.DBF’ ;
VALIDATE TABLESPACE system,sysaux ;
VALIDATE BACKUPSET 47,52 ;
- 10 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Sauvegarde
1. Généralités
La commande BACKUP permet d’effectuer une sauvegarde. Pour que cette commande fonctionne, il faut que la base de
données soit montée ou ouverte car RMAN a besoin d’accéder au fichier de contrôle de la base cible, notamment pour
y enregistrer l’existence de la sauvegarde. Les sauvegardes base ouverte ne sont possibles que si la base de
données fonctionne en mode ARCHIVELOG. Si la base de données fonctionne en mode NOARCHIVELOG, il faut au
préalable arrêter la base de données (proprement) puis la monter :
SHUTDOWN IMMEDIATES
TARTUP MOUNT
BACKUP ... ;
RMAN peut sauvegarder des fichiers de données, des fichiers de contrôle, des fichiers de journalisation archivés, le
fichier de paramètres serveur ou des éléments de sauvegarde (d’une sauvegarde précédente). Comme indiqué
précédemment, une sauvegarde RMAN peut être réalisée sous la forme d’une copie image (image copy) ou d’un jeu
de sauvegarde (backup set). Par défaut, la sauvegarde s’effectue dans un jeu de sauvegarde.
Lorsque RMAN effectue une sauvegarde de fichiers de données dans un jeu de sauvegarde, il ne sauvegarde pas les
blocs jamais utilisés des fichiers, ce qui permet de gagner de la place. En complément, il est possible de compresser le
jeu de sauvegarde ; cela ralentit légèrement la sauvegarde, consomme un peu de CPU, mais diminue la taille de la
sauvegarde de manière importante (typiquement, division par 5). Ces deux fonctionnalités ne sont pas disponibles
dans le cas d’une copie image (copie bit à bit du fichier d’origine).
La syntaxe générale de la commande BACKUP est la suivante :
BACKUP [comment] quoi [option]
La commande BACKUP propose un très grand nombre d’options. Dans cet ouvrage, nous ne présenterons que
les options les plus couramment utilisées.
La clause comment peut prendre une ou plusieurs des valeurs suivantes :
INCREMENTAL LEVEL n [CUMULATIVE]
Indique que la sauvegarde est une sauvegarde incrémentale.
VALIDATE
Indique simplement de vérifier que la sauvegarde peut être réalisée (teste la présence des fichiers et leur non­
corruption). Cette option est équivalente à l’utilisation de la commande VALIDATE.
AS COPY ou AS [COMPRESSED] BACKUPSET
Indique s’il faut faire une sauvegarde sous la forme d’une copie image ou d’un jeu de sauvegarde, éventuellement
compressé.
La clause quoi peut prendre une ou plusieurs des valeurs suivantes :
DATABASE
Sauvegarde de la totalité de la base de données.
TABLESPACE cible
Sauvegarde d’un ou plusieurs tablespaces.
DATAFILE cible
Sauvegarde d’un ou plusieurs fichiers de données.
CURRENT CONTROLFILE
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Sauvegarde du fichier de contrôle courant.
SPFILE
Sauvegarde du fichier de paramètres serveur.
ARCHIVELOG cible
Sauvegarde des fichiers de journalisation archivés.
La clause option peut prendre une ou plusieurs des valeurs suivantes :
INCLUDE CURRENT CONTROLFILE
Inclure le fichier de contrôle courant dans la sauvegarde.
PLUS ARCHIVELOG
Inclure les fichiers de journalisation archivés dans la sauvegarde.
DELETE [ALL] INPUT
Supprimer les éléments sauvegardés (valable uniquement pour une sauvegarde de fichiers de journalisation archivés
ou une sauvegarde de jeu de sauvegarde).
FORMAT [=] ’format’
Spécifier un format pour la sauvegarde (chemin et format de nom de fichier).
TAG [=] ’nom’
Associer un nom à la sauvegarde.
NOT BACKED UP clause_depuis
Indiquer de ne sauvegarder que les éléments qui n’ont pas été sauvegardés un certain nombre de fois ou depuis un
certain temps.
Dans la commande BACKUP, la seule clause obligatoire est la clause quoi qui indique ce qu’il faut sauvegarder. Toutes
les autres clauses sont optionnelles et ont des valeurs par défaut.
Certaines valeurs par défaut proviennent de la configuration persistante de RMAN. C’est le cas notamment de la
destination de la sauvegarde et du format du nom des fichiers (canal par défaut). L’option FORMAT de la commande
BACKUP permet de spécifier une destination différente pour la sauvegarde. Sauf modification de la configuration, la
sauvegarde sur disque s’effectue par défaut dans un jeu de sauvegarde non compressé (équivalent à l’option AS
BACKUPSET). Pour effectuer une sauvegarde dans un jeu de sauvegarde compressé, il faut utiliser l’option AS
COMPRESSED BACKUPSET (BACKUP AS COMPRESSED BACKUPSET ...). Pour effectuer une sauvegarde sous la forme d’une
copie image, il faut utiliser l’option AS COPY (BACKUP AS COPY ...).
Avec l’option VALIDATE, la commande BACKUP n’effectue en fait aucune sauvegarde ; elle vérifie simplement qu’une
sauvegarde pourrait être réalisée, c’est­à­dire que les fichiers à sauvegarder sont bien accessibles et ne sont pas
corrompus.
L’optionTAG permet d’associer un nom à la sauvegarde, ce qui permet par la suite d’identifier facilement des
sauvegardes ou des catégories de sauvegarde. Ce nom est inclus dans les noms de fichiers générés par RMAN lors
d’une sauvegarde dans la zone de récupération rapide.
L’option NOT BACKED UP propose deux syntaxes :
●
NOT BACKED UP SINCE TIME = ’date’ ;
●
NOT BACKED UP n TIMES.
La première syntaxe permet de ne sauvegarder que les éléments qui n’ont pas été sauvegardés depuis un certain
temps. L’option date peut être une constante conforme au format de date par défaut (NLS_DATE_FORMATde la session
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
RMAN) ou une expression (du type ’SYSDATE-1’). La deuxième syntaxe permet de ne sauvegarder que les éléments
qui n’ont pas été sauvegardés un certain nombre de fois ; cette syntaxe ne peut être utilisée que pour les fichiers de
journalisation archivés.
Les autres clauses sont détaillées dans les points suivants.
Lors de chaque sauvegarde, RMAN affiche de nombreuses informations sur les opérations effectuées.
Exemple
RMAN> BACKUP AS COMPRESSED BACKUPSET DATABASE TAG=’DBF’;
Démarrage de backup dans 05/08/08
utilisation du canal ORA_DISK_1
canal ORA_DISK_1 : démarrage de l’ensemble de sauvegarde compressé de tous
les fichiers de données
canal ORA_DISK_1 : insertion du(des) fichier(s) de données dans l’ensemble
de sauvegarde
fichier de données en entrée, numéro=00001,
nom=E:\ORADATA\HERMES\SYSTEM01.DBF
fichier de données en entrée, numéro=00002,
nom=E:\ORADATA\HERMES\SYSAUX01.DBF
fichier de données en entrée, numéro=00003,
nom=E:\ORADATA\HERMES\UNDOTBS01.DBF
fichier de données en entrée, numéro=00005,
nom=E:\ORADATA\HERMES\DATA01.DBF
fichier de données en entrée, numéro=00006,
nom=E:\ORADATA\HERMES\INDX01.DBF
fichier de données en entrée, numéro=00004,
nom=E:\ORADATA\HERMES\DEFTBS01.DBF
canal ORA_DISK_1 : démarrage de l’élément 1 dans 05/08/08
canal ORA_DISK_1 : élément 1 terminé dans 05/08/08
descripteur d’élément=H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\BACKUPSET\
2008_08_05\O1_MF_NNNDF_DBF_49HRPOC7_.BKP balise=DBF commentaire=NONE
canal ORA_DISK_1 : ensemble de sauvegarde terminé, temps écoulé : 00:00:55
Fin de backup dans 05/08/08
Démarrage de Control File and SPFILE Autobackup dans 05/08/08
descripteur d’élément=H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\AUTOBACKUP\
2008_08_05\O1_MF_S_661936812_49HRRFXS_.BKP commentaire=NONE
Fin de Control File and SPFILE Autobackup dans 05/08/08
Dans le compte rendu d’une sauvegarde, nous trouvons les informations suivantes :
●
●
●
les fichiers sauvegardés (par exemple "fichier de données en entrée …" pour une sauvegarde de fichier de
données) ;
le nom complet du fichier de sauvegarde généré (par exemple "descripteur d’élément=" pour un élément de
sauvegarde) ;
le fait qu’il y ait eu ou non une sauvegarde automatique du fichier de contrôle et du fichier de paramètres
serveur.
Les fichiers de données temporaires (fichiers de données des tablespaces temporaires gérés localement) ne
sont pas sauvegardés (c’est inutile).
2. Sauvegarde de la totalité de la base de données
Pour sauvegarder la totalité de la base, il suffit d’utiliser l’option DATABASE dans la commande BACKUP :
BACKUP DATABASE ;
RMAN utilise les informations du fichier de contrôle de la base cible pour définir la liste des fichiers de données à
sauvegarder. En complément, il sauvegarde le fichier de contrôle et le fichier de paramètres serveur (voir ci­après).
La commande BACKUP VALIDATE DATABASE peut être utilisée pour vérifier que la base de données est en "bon
état" (aucun fichier inaccessible, aucun fichier corrompu).
© ENI Editions - All rights reserved - Algeria Educ
- 3-
3. Sauvegarde de tablespaces ou de fichiers de données individuels
Pour sauvegarder individuellement quelques tablespaces ou quelques fichiers de données, vous pouvez utiliser les
options TABLESPACE et/ou DATAFILE dans la commande BACKUP.
Exemple :
BACKUP TABLESPACE data,indx ;
BACKUP DATAFILE 1,2,’E:\ORADATA\HERMES\DEFTBS01.DBF’ ;
BACKUP TABLESPACE system DATAFILE 5 ;
Les options TABLESPACE et DATAFILE peuvent être utilisées simultanément dans la même commande. Un tablespace
est désigné par son nom et un fichier de données par son numéro ou par son nom. Lors de la sauvegarde d’un
tablespace, RMAN utilise les informations du fichier de contrôle de la base cible pour définir la liste des fichiers de
données du tablespace et les sauvegarder.
4. Sauvegarde du fichier de contrôle et du fichier de paramètres serveur
Le fichier de contrôle et le fichier de paramètres serveur sont sauvegardés automatiquement dans deux cas :
●
Lorsque la sauvegarde automatique du fichier de contrôle a été activée.
●
Lorsque le fichier de données numéro 1 (le premier fichier de données du tablespace SYSTEM) est sauvegardé.
Dans les autres cas, le fichier de contrôle peut être explicitement sauvegardé en utilisant les options CURRENT
CONTROLFILE ou INCLUDE CURRENT CONTROLFILE dans la commande BACKUP. De même, le fichier de paramètres serveur
peut être explicitement sauvegardé en utilisant l’option SPFILE.
Exemple :
BACKUP TABLESPACE data,indx INCLUDE CURRENT CONTROLFILE ;
BACKUP CURRENT CONTROLFILE ;
BACKUP AS COPY CURRENT CONTROLFILE ;BACKUP SPFILE ;
Si la sauvegarde automatique du fichier de contrôle a été activée, le fichier de contrôle ou le fichier de paramètres
serveur sont sauvegardés en double lorsqu’ils sont explicitement sauvegardés.
Le fichier de contrôle et le fichier de paramètres serveur sont sauvegardés dans un jeu de sauvegarde séparé.
La sauvegarde automatique du fichier de contrôle est plus intéressante qu’une sauvegarde manuelle,
notamment car RMAN peut la restaurer automatiquement en cas de besoin (ce n’est pas le cas avec une
sauvegarde manuelle). De plus, dans cette configuration, le fichier de contrôle est automatiquement sauvegardé
lorsque la configuration des fichiers de la base de données change.
5. Sauvegarde des fichiers de journalisation archivés
Si les fichiers de journalisation ne sont pas archivés en double sur des disques séparés, ou ne sont pas archivés
dans la zone de récupération rapide (qui doit normalement être un disque séparé), il est vivement conseillé de les
sauvegarder ; ce sont eux en effet qui permettent de garantir une restauration complète.
Les fichiers de journalisation archivés peuvent être sauvegardés en utilisant les options ARCHIVELOG ou PLUS
ARCHIVELOG dans la commande BACKUP.
Exemple :
BACKUP ARCHIVELOG ALL ;<$IRMAN;BACKUP ARCHIVELOG>
BACKUP ARCHIVELOG FROM TIME ’SYSDATE-1’ DELETE ALL INPUT ;
BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG FROM TIME ’SYSDATE-7’
NOT BACKED UP 2 TIMES ;
BACKUP DATABASE PLUS ARCHIVELOG ;
BACKUP DATABASE PLUS ARCHIVELOG DELETE ALL INPUT ;
- 4-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Dans les deux cas, si les fichiers de journalisation sont archivés vers plusieurs destinations, une seule copie est
sauvegardée pour chaque numéro de séquence de journalisation.
La commande BACKUP ARCHIVELOG cible permet de sauvegarder les fichiers de journalisation désignés par la clause
cible. La clause cible offre différentes possibilités parmi lesquelles :
ALL
Tous les fichiers de journalisation archivés. Ne peut pas être combinée avec d’autres options.
FROM TIME ’date’
Tous les fichiers de journalisation archivés depuis une certaine date.
UNTIL TIME ’date’
Tous les fichiers de journalisation archivés avant une certaine date.
TIME BETWEEN ’date1’ AND ’date2’
Tous les fichiers de journalisation archivés entre deux dates.
Si la commande inclut le fichier de journalisation le plus récent (option ALL ou absence d’option UNTIL) et que la base
de donnée est ouverte, RMAN commence par archiver tous les fichiers de journalisation en ligne qui n’ont pas encore
été archivés (et donc notamment le courant). De cette manière, toute l’activité de journalisation générée avant le
début de la commande est sauvegardée.
La commande BACKUP ... PLUS ARCHIVELOG permet de sauvegarder les fichiers de journalisation en plus d’autres
éléments (mais dans un jeu de sauvegarde séparé). Cette commande effectue les opérations suivantes :
●
●
archivage du fichier de journalisation courant ;
sauvegarde de tous les fichiers de journalisation archivés (équivalent à la commande BACKUP ARCHIVELOG
ALL) ;
●
sauvegarde des autres éléments ;
●
de nouveau, archivage du fichier de journalisation courant ;
●
sauvegarde des fichiers de journalisation archivés générés depuis le début de la sauvegarde.
De cette manière, toutes les sauvegardes de fichiers de données effectuées pendant l’opération (dans un état
incohérent) sont exploitables car tous les fichiers de journalisation nécessaires ont été sauvegardés.
Utilisation de l’option NOT BACKED UP
L’option NOT BACKED UP peut être utilisée en plus, pour ne sauvegarder que les fichiers de journalisation archivés qui
n’ont pas déjà été sauvegardés un certain nombre de fois ou depuis un certain temps.
Utilisation de l’option DELETE [ALL] INPUT
L’option DELETE [ALL] INPUT peut être utilisée pour supprimer les fichiers de journalisation archivés qui viennent
d’être sauvegardés.
Si les fichiers de journalisation sont archivés dans une seule destination, il n’y a pas de différence entre l’option
DELETE INPUT et l’option DELETE ALL INPUT.
Si les fichiers de journalisation sont archivés vers plusieurs destinations, il y a une différence entre les deux options :
●
DELETE INPUT supprime uniquement la copie du fichier de journalisation qui a été utilisé pour la sauvegarde.
●
DELETE ALL INPUT supprime toutes les copies du fichier de journalisation sauvegardé.
© ENI Editions - All rights reserved - Algeria Educ
- 5-
6. Sauvegarde incrémentale
Avec RMAN, il est possible de réaliser des sauvegardes incrémentales, de la totalité de la base de données, de
tablespaces individuels ou de fichiers de données individuels. L’objectif est de ne sauvegarder que les blocs qui ont
été modifiés depuis la dernière sauvegarde. Les sauvegardes incrémentales présentent comme principal intérêt de
réduire la taille des sauvegardes, notamment lorsque l’activité de mise à jour est relativement faible sur la base de
données.
Pour réaliser une sauvegarde incrémentale, il suffit d’inclure l’option INCREMENTAL LEVEL n [CUMULATIVE] dans la
commande BACKUP.
Exemple :
BACKUP INCREMENTAL LEVEL 0 DATABASE TAG=’dbinc0’ ;
BACKUP INCREMENTAL LEVEL 1 DATABASE TAG=’dbinc1’ ;
Une sauvegarde incrémentale peut être de niveau 0 ou de niveau 1, différentielle ou cumulative :
●
●
●
Une sauvegarde incrémentale de niveau 0 sauvegarde toujours, tous les blocs utilisés des fichiers de
données. Elle est équivalente à une sauvegarde complète (mais une sauvegarde complète n’est pas
considérée par RMAN comme une sauvegarde incrémentale de niveau 0).
Une sauvegarde incrémentale différentielle de niveau 1 sauvegarde tous les blocs modifiés depuis la
dernière sauvegarde incrémentale de niveau 0 ou 1. C’est le comportement par défaut.
Une sauvegarde incrémentale cumulative de niveau 1 sauvegarde tous les blocs modifiés depuis la dernière
sauvegarde incrémentale de niveau 0.
Les sauvegardes incrémentales cumulatives sont plus intéressantes pour la rapidité de récupération (moins de
sauvegardes intermédiaires à appliquer), mais nécessitent plus d’espace disque.
Lors d’une sauvegarde incrémentale de niveau 1, RMAN est obligé de lire tous les blocs utilisés pour trouver ceux qui
ont été modifiés et doivent donc être sauvegardés. En conséquence, la durée de la sauvegarde n’est pas
sensiblement réduite par rapport à une sauvegarde de niveau 0 (pas de gain sur la lecture, simple gain sur l’écriture).
Si vous souhaitez réduire la durée de la sauvegarde, vous pouvez activer la fonctionnalité de trace des blocs modifiés
(block change tracking). Lorsque cette fonctionnalité est activée, Oracle garde une trace des blocs modifiés dans un
fichier. Lors d’une sauvegarde incrémentale de niveau 1, RMAN n’a plus besoin de parcourir tous les blocs utilisés ; il
emploie le fichier de trace des blocs modifiés pour identifier les blocs à sauvegarder.
Pour activer la fonctionnalité de trace des blocs modifiés, vous pouvez utiliser l’ordre SQL suivant (ce n’est pas une
commande RMAN) :
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE ’fichier’;
fichier donne le chemin complet et le nom du fichier de trace.
- 6-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Exemple d’activation à partir de RMAN en utilisant la commande SQL :
RMAN> SQL "ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE ’
’F:\oradata\HERMES\block_change_tracking.trc’’";
Il n’y a pas de recommandation particulière concernant l’emplacement du fichier ; vous pouvez le placer dans
l’environnement de la base de données ou dans la zone de récupération rapide.
Le fichier de trace des blocs modifiés n’est pas spécialement volumineux ; Oracle annonce une taille de 1/30 000 de la
taille de tous les blocs à tracer, indépendante de la fréquence de mise à jour. Le fichier a une taille minimum de 10 Mo
et grossit par pas de 10 Mo.
La vue V$BLOCK_CHANGE_TRACKING <donne des informations sur la trace des blocs modifiés :
SQL> SELECT * FROM v$block_change_tracking;
STATUS
FILENAME
BYTES
---------- ------------------------------------------- --------ENABLED
F:\ORADATA\HERMES\BLOCK_CHANGE_TRACKING.TRC 11599872
Si le fichier de trace est perdu ou endommagé, la base de données ne pourra pas être ouverte (elle restera en état
MOUNT). Pour ouvrir la base, il faut désactiver la trace, et éventuellement la réactiver si vous souhaitez continuer à
utiliser la fonctionnalité. Il n’existe pas de possibilité de sauvegarde et de restauration du fichier de trace.
Pour déplacer le fichier de trace, vous pouvez utiliser l’ordre SQL ALTER DATABASE RENAME FILE, base montée.
Pour désactiver la fonctionnalité de trace des blocs modifiés, vous pouvez utiliser l’ordre SQL suivant :
ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
Après activation de la trace, la première sauvegarde incrémentale de niveau 0 devra parcourir tous les blocs utilisés
car le fichier de trace ne reflète pas encore le statut des blocs. Il en est de même après une recréation du fichier de
trace.
Employer ou non un fichier de trace des blocs modifiés ne change rien aux commandes à utiliser pour réaliser des
sauvegardes incrémentales. Si la fonctionnalité est active, RMAN l’exploite ; sinon il s’en passe.
Il existe une autre fonctionnalité intéressante concernant les sauvegardes incrémentales : la possibilité de réaliser
une sauvegarde sous forme de copie image et de mettre cette copie image à jour par application régulière de
sauvegardes incrémentales (Incrementally Updated Backup). Pour en savoir plus, consultez la documentation Oracle®
Database Backup and Recovery User’s Guide.
7. Exemples de scénario
a. Préambule
Les scénarios présentés ici s’appuient sur deux hypothèses :
●
Une zone de récupération rapide est utilisée.
●
La sauvegarde automatique des fichiers de contrôle a été activée.
b. Sauvegarde complète base fermée (cohérente)
Les commandes suivantes permettent de réaliser une sauvegarde complète base fermée (donc cohérente) :
SHUTDOWN IMMEDIATE ;
STARTUP MOUNT ;
BACKUP DATABASE ;
SQL "ALTER DATABASE OPEN" ;
#
#
#
#
arrêter la base
monter la base
sauvegarder la base
ouvrir la base
Cette sauvegarde est un exemple typique de ce qui est fait lorsque la base fonctionne en mode NOARCHIVELOG.
c. Sauvegarde complète base ouverte (incohérente)
© ENI Editions - All rights reserved - Algeria Educ
- 7-
La commande suivante permet de réaliser une sauvegarde complète base ouverte (donc incohérente), avec
sauvegarde des fichiers de journalisation archivés, et suppression des fichiers de journalisation archivés
sauvegardés :
BACKUP DATABASE PLUS ARCHIVELOG DELETE ALL INPUT;
Cette sauvegarde ne peut être effectuée que lorsque la base fonctionne en mode ARCHIVELOG.
d. Sauvegarde partielle base ouverte
Dans ce scénario, la totalité de la base est sauvegardée en trois fois sur trois jours :
●
Sauvegarde 1 : fichiers de données 1 et 2
BACKUP DATAFILE 1,2 PLUS ARCHIVELOG DELETE ALL INPUT;
●
Sauvegarde 2 : fichiers de données 3 et 4
BACKUP DATAFILE 3,4 PLUS ARCHIVELOG DELETE ALL INPUT;
●
Sauvegarde 3 : le reste
BACKUP DATABASE NOT BACKED UP SINCE TIME=’SYSDATE-3’
PLUS ARCHIVELOG DELETE ALL INPUT;
Sur le principe, c’est une variante du scénario précédent. La commande pour la troisième sauvegarde permet de
sauvegarder tout ce qui n’a pas été sauvegardé depuis trois jours, y compris tout nouveau fichier de données.
Il est techniquement possible de réaliser des sauvegardes partielles, base fermée, mais ces sauvegardes ne sont
exploitables que si la base de données fonctionne en mode ARCHIVELOG. Donc, autant les réaliser base ouverte.
e. Sauvegarde incrémentale
Dans ce scénario, des sauvegardes incrémentales cumulatives sont réalisées sur un cycle d’une semaine :
●
Dimanche : sauvegarde incrémentale de niveau 0
BACKUP INCREMENTAL LEVEL 0 DATABASE ;
●
Lundi au samedi : sauvegarde incrémentale cumulative de niveau 1
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE ;
Dans cet exemple, nous supposons que la base de données fonctionne en mode ARCHIVELOG, ce qui nous permet de
réaliser la sauvegarde base ouverte ; pour être tout à fait rigoureux, il faudrait en plus s’occuper des fichiers de
journalisation archivés (ajouter une clause PLUS ARCHIVELOG par exemple).
Ce type de sauvegarde peut aussi être réalisé si la base de données fonctionne en mode NOARCHIVELOG, en
ajoutant les commandes suivantes :
SHUTDOWN IMMEDIATE ;
STARTUP MOUNT ;
BACKUP INCREMENTAL... ;
SQL "ALTER DATABASE OPEN" ;
- 8-
openmirrors.com
#
#
#
#
arrêter la base
monter la base
sauvegarder la base ici
ouvrir la base
© ENI Editions - All rights reserved - Algeria Educ
Le référentiel RMAN
1. Trouver des informations sur les sauvegardes
a. La commande LIST
La commande LIST permet d’interroger le référentiel RMAN pour afficher des informations sur les sauvegardes et les
fichiers de journalisation archivés.
Syntaxe 1
LIST cible [ BY FILE | SUMMARY ] [ filtre_sauvegarde ];
- cible
{ BACKUP | COPY } [ OF objets ]
BACKUPSET
- objets
DATABASE
DATAFILE liste_numéros_ou_noms
TABLESPACE liste_noms
CONTROLFILE
SPFILE
ARCHIVELOG { ALL | filtre_archive }
- filtre_archive
FROM TIME ’date’
UNTIL TIME ’date’
TIME BETWEEN ’date1’ AND ’date2’
- filtre_sauvegarde
TAG [=] ’nom’
COMPLETED { AFTER ’date1’
| BEFORE ’date2’
| BETWEEN ’date1’ AND ’date2’ }
Syntaxe 2
LIST { BACKUPSET | BACKUPPIECE } { liste_clés | TAG [=] ’nom’ };
Syntaxe 3
LIST ARCHIVELOG { ALL | filtre_archive } [info_sauvegarde];
- info_sauvegarde
BACKED UP n TIMES TO DEVICE TYPE [DISK | ’media’]
Toutes les options possibles ne sont pas présentées ici.
Première syntaxe
La première syntaxe permet d’afficher des informations sur les sauvegardes enregistrées dans le référentiel RMAN.
Par défaut, les commandes LIST BACKUP, LIST COPY et LIST BACKUPSET listent tous les éléments enregistrés dans le
référentiel RMAN.
Dans le cas des commandes LIST BACKUP et LIST COPY, il est possible de spécifier un ou plusieurs objets pour
n’afficher que les sauvegardes des objets en question.
Exemple :
LIST BACKUP OF DATABASE ; # n’importe quel fichier de la base
LIST BACKUP OF DATAFILE 1,’E:\ORADATA\HERMES\DATA01.DBF’ ;
LIST BACKUP OF TABLESPACE system,sysaux ;
LIST BACKUP OF CONTROLFILE SPFILE ;
LIST BACKUP OF ARCHIVELOG ALL ;
LIST BACKUP OF ARCHIVELOG UNTIL TIME ’SYSDATE-1’ ;
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Le dernier exemple liste les sauvegardes des fichiers de journalisation archivés il y a plus d’un jour, quelle que soit
la date de la sauvegarde (peut dater de moins d’un jour) ; il ne faut pas confondre le filtre de date d’archivage
(option filtre_archive) et le filtre de date de sauvegarde (option filtre_sauvegarde).
L’option filtre_sauvegarde permet de filtrer la liste grâce à un critère portant sur la sauvegarde : date de la
sauvegarde et/ou nom associé à la sauvegarde (option TAG de la commande BACKUP).
Exemple :
LIST BACKUP TAG=’DBINC0’ ;
LIST BACKUP COMPLETED AFTER ’SYSDATE-1’ ;
LIST BACKUP TAG=’DBINC0’ COMPLETED AFTER ’SYSDATE-1’ ;
LIST BACKUP OF ARCHIVELOG UNTIL TIME ’SYSDATE-1’
COMPLETED AFTER ’SYSDATE-1’ ;
Le dernier exemple liste les sauvegardes des fichiers de journalisation archivés il y a plus d’un jour mais
sauvegardés il y a moins d’un jour.
Les commandes LIST BACKUP OF et LIST BACKUPSET listent les sauvegardes par jeu de sauvegarde, avec un
affichage détaillé donnant le contenu de chaque sauvegarde.
Exemple (extrait)
RMAN> LIST BACKUP OF DATABASE;
Liste des ensembles de sauvegarde
===================
BS Key Type LV Size
Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ --------------17
Full
75.78M
DISK
00:00:45
05/08/08
BP Key: 17
Status: AVAILABLE Compressed: YES Tag:
TAG20080805T080633
Piece Name: H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\BACKUPSET\
2008_08_05\O1_MF_NNNDF_TAG20080805T080633_49HVH9KL_.BKP
Liste des fichiers de données dans l’ensemble de sauvegarde 17
File LV Type Ckp SCN
Ckp Time Name
---- -- ---- ---------- -------- ---1
Full 410531
05/08/08 E:\ORADATA\HERMES\SYSTEM01.DBF
2
Full 410531
05/08/08 E:\ORADATA\HERMES\SYSAUX01.DBF
3
Full 410531
05/08/08 E:\ORADATA\HERMES\UNDOTBS01.DBF
4
Full 410531
05/08/08 E:\ORADATA\HERMES\DEFTBS01.DBF
5
Full 410531
05/08/08 E:\ORADATA\HERMES\DATA01.DBF
6
Full 410531
05/08/08 E:\ORADATA\HERMES\INDX01.DBF
La colonne "Clé BS" donne le numéro (clé) attribué par RMAN au jeu de sauvegarde.
L’option SUMMARY permet d’obtenir un affichage résumé (pas de détail sur le contenu des sauvegardes), organisé par
jeu de sauvegarde.
L’option BY FILE permet d’obtenir un affichage résumé, organisé par fichier sauvegardé.
Deuxième syntaxe
La deuxième syntaxe permet d’afficher des informations sur des jeux de sauvegarde (BACKUPSET) ou éléments de
sauvegarde (BACKUPPIECE) précis (soit par une liste de clés, soit par le nom associé à la sauvegarde grâce à l’option
TAG de la commande BACKUP).
Exemples
LIST BACKUPSET 8;
LIST BACKUPSET TAG=’DBINC0’ ;
LIST BACKUPPIECE 76 ;
La clé d’un élément de sauvegarde ("Clé BP") n’est pas forcément égale à la clé du jeu de sauvegarde ("Clé BS"),
car un jeu de sauvegarde peut avoir plusieurs éléments de sauvegarde, ce qui génère un décalage dans la
numérotation.
Troisième syntaxe
La troisième syntaxe permet d’afficher des informations sur les fichiers de journalisation archivés considérés comme
disponibles par RMAN, c’est­à­dire non supprimés par RMAN (avec l’option DELETE INPUT).
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Exemples
LIST ARCHIVELOG ALL ; # tous
LIST ARCHIVELOG FROM TIME ’SYSDATE-1/24’ ; # dans la dernière heure
LIST ARCHIVELOG ALL BACKED UP 2 TIMES
TO DEVICE TYPE DISK ; # archives sauvegardées 2 fois sur disque
LIST ARCHIVELOG ALL BACKED UP 0 TIMES
TO DEVICE TYPE DISK ; # archives jamais sauvegardées sur disque
b. La commande REPORT
La commande REPORT permet de réaliser des interrogations plus évoluées sur le référentiel RMAN.
Il existe trois utilisations principales de la commande REPORT :
●
lister les éléments qui nécessitent une sauvegarde ;
●
lister les sauvegardes obsolètes ;
●
afficher la liste des fichiers de données de la base de données.
Lister les éléments qui nécessitent une sauvegarde
Syntaxe
REPORT NEED BACKUP [condition] [objets];<$IRMAN;REPORT NEED BACKUP>
- condition
DAYS [=] n
INCREMENTAL [=] n
RECOVERY WINDOW OF n DAYS
REDUNDANCY [=] n
- objets
DATABASE
DATAFILE liste_numéros_ou_noms
TABLESPACE liste_noms
Par défaut, la commande REPORT NEED BACKUP affiche la liste des fichiers qui nécessitent une sauvegarde, en tenant
compte de la politique de conservation configurée (CONFIGURE RETENTION POLICY).
L’option condition permet de préciser le critère que la commande REPORT doit utiliser pour déterminer si un fichier a
besoin d’être sauvegardé. Les conditions possibles sont :
DAYS [=] n
Fichiers de données qui nécessitent plus de n jours d’application de fichiers de journalisation archivés pour être
récupérés en cas d’incident.
INCREMENTAL [=] n
Fichiers de données qui nécessitent plus de n applications de sauvegardes incrémentales pour être récupérés en
cas d’incident.
RECOVERY WINDOW OF n DAYS
Une fenêtre de récupération particulière (même syntaxe que dans la commande CONFIGURE RETENTION POLICY).
REDUNDANCY [=] n
Une redondance particulière (même syntaxe que dans la commande CONFIGURE RETENTION POLICY).
L’option objets permet de s’intéresser à des tablespaces ou des fichiers de données précis.
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Avant d’exécuter cette commande, il peut être utile d’exécuter la commande CROSSCHECK (voir plus loin) pour
mettre à jour le statut des sauvegardes dans le référentiel RMAN.
Lister les sauvegardes obsolètes
Syntaxe
REPORT OBSOLETE [condition];
- condition
RECOVERY WINDOW OF n DAYS
REDUNDANCY [=] n
Par défaut, la commande REPORT OBSOLETE affiche les sauvegardes obsolètes en tenant compte de la politique de
conservation configurée (CONFIGURE RETENTION POLICY).
L’option condition permet de préciser le critère que la commande REPORT doit utiliser pour déterminer si une
sauvegarde est obsolète. La syntaxe est la même que dans la commande CONFIGURE RETENTION POLICY.
Avant d’exécuter cette commande, il peut être utile d’exécuter la commande CROSSCHECK (voir plus loin) pour
mettre à jour le statut des sauvegardes dans le référentiel RMAN.
Afficher la liste des fichiers de données de la base de données
Syntaxe
REPORT SCHEMA ;
2. Gérer le référentiel RMAN
a. La commande CROSSCHECK
La commande CROSSCHECK permet de vérifier que les informations enregistrées dans le référentiel RMAN
correspondent bien à des fichiers qui existent physiquement. Un décalage peut se produire si un fichier est
directement supprimé au niveau du système d’exploitation. La commande CROSSCHECK met à jour le statut de
l’élément dans le référentiel RMAN mais ne supprime rien (ni fichier physique, ni enregistrement dans le référentiel).
Les statuts possibles sont les suivants :
EXPIRED
L’objet n’a pas été trouvé au niveau du système d’exploitation.
AVAILABLE
L’objet est disponible et peut être utilisé par RMAN.
UNAVAILABLE
L’objet n’est pas disponible et ne peut pas être utilisé par RMAN (suite à l’utilisation de la commande CHANGE ...
UNAVAILABLE ­ voir la documentation Oracle).
Un enregistrement qui a été marqué EXPIRED lors d’un CROSSCHECK peut repasser AVAILABLE lors d’un nouveau
CROSSCHECK s’il n’a été que temporairement inaccessible. Vous pouvez aussi utiliser la commande CHANGE ...
AVAILABLE pour remettre le statut AVAILABLE à un enregistrement si le fichier physique est de nouveau accessible
(voir la documentation Oracle).
Syntaxe 1
CROSSCHECK cible [ filtre_sauvegarde ] ;
- cible
{ BACKUP | COPY } [ OF objets ]
BACKUPSET
- objets
- 4-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
DATABASE
DATAFILE liste_numéros_ou_noms
TABLESPACE liste_noms
CONTROLFILE
SPFILE
ARCHIVELOG { ALL | filtre_archive }
Syntaxe 2
CROSSCHECK { BACKUPSET | BACKUPPIECE } { liste_clés | TAG [=] ’nom’ };
Syntaxe 3
CROSSCHECK ARCHIVELOG { ALL | filtre_archive };
Toutes les options possibles ne sont pas présentées ici.
Les variantes de syntaxe et options sont les mêmes que pour la commande LIST.Le statut est affiché dans le
résultat de la commande LIST. La commande LIST EXPIRED, variante de la commande LIST, permet de lister les
éléments qui ont le statut EXPIRED.
Exemple 1
RMAN> CROSSCHECK BACKUP ;
utilisation du canal ORA_DISK_1
élément de sauvegarde vérifié : repéré comme étant ’EXPIRED’
descripteur d’élément de sauvegarde=H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\
BACKUPSET\2008_08_05\O1_MF_NNNDF_TAG20080805T080633_49HVH9KL_.BKP RECID=17
STAMP=661939593
élément de sauvegarde vérifié : repéré comme étant ’AVAILABLE’
descripteur d’élément de sauvegarde=H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\
AUTOBACKUP\2008_08_05\O1_MF_S_661939648_49HVK1Z7_.BKP RECID=18 STAMP=661939649
2 objets contre-vérifiés
RMAN> LIST EXPIRED BACKUP ;
Liste des ensembles de sauvegarde
===================
BS Key Type LV Size
Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ --------------17
Full
75.78M
DISK
00:00:45
05/08/08
BP Key: 17
Status: EXPIRED
Compressed: YES Tag: TAG20080805T080633
Piece Name: H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\BACKUPSET\
2008_08_05\O1_MF_NNNDF_TAG20080805T080633_49HVH9KL_.BKP
...
Exemple 2
RMAN> CROSSCHECK ARCHIVELOG ALL ;
canal libéré : ORA_DISK_1
canal affecté : ORA_DISK_1
canal ORA_DISK_1 : SID=186 type d’unité=DISK
échec de la validation du journal d’archivage
nom de journal d’archivage=H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\
ARCHIVELOG\2008_08_05\O1_MF_1_40_49HWKM2G_.ARC RECID=12 STAMP=661940692
validation réussie du journal d’archivage
nom de journal d’archivage=H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\
ARCHIVELOG\2008_08_05\O1_MF_1_41_49HWKN89_.ARC RECID=14 STAMP=661940692
...
RMAN> LIST EXPIRED ARCHIVELOG ALL ;
Liste des copies des journaux d’archivage dont le nom est db_unique_name
HERMES
========================================================================
Key
Thrd Seq
S Low Time
------- ---- ------- - -------12
1
40
X 05/08/08
© ENI Editions - All rights reserved - Algeria Educ
- 5-
Name: H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\ARCHIVELOG\
2008_08_05\O1_MF_1_40_49HWKM2G_.ARC
b. La commande DELETE
La commande DELETE peut être utilisée pour supprimer des sauvegardes. Elle supprime les fichiers physiques et
l’enregistrement dans le référentiel RMAN.
La commande DELETE propose deux variantes principales pour :
●
supprimer des sauvegardes ou des fichiers de journalisation spécifiques ;
●
supprimer les sauvegardes obsolètes.
Supprimer des sauvegardes ou des fichiers de journalisation spécifiques
Syntaxe 1
DELETE [FORCE] [NOPROMPT] [EXPIRED] cible [ filtre_sauvegarde ] ;
- cible
{ BACKUP | COPY } [ OF objets ]
BACKUPSET
- objets
DATABASE
DATAFILE liste_numéros_ou_noms
TABLESPACE liste_noms
CONTROLFILE
SPFILE
ARCHIVELOG { ALL | filtre_archive }
- filtre_archive
FROM TIME ’date’
UNTIL TIME ’date’
TIME BETWEEN ’date1’ AND ’date2’
- filtre_sauvegarde
TAG [=] ’nom’
COMPLETED { AFTER ’date1’
| BEFORE ’date2’
| BETWEEN ’date1’ AND ’date2’ }
Syntaxe 2
DELETE [FORCE] [NOPROMPT] [EXPIRED] { BACKUPSET | BACKUPPIECE }
{ liste_clés | TAG [=] ’nom’ };
Syntaxe 3
DELETE [FORCE] [NOPROMPT] [EXPIRED] ARCHIVELOG { ALL | filtre_archive }
[info_sauvegarde];
- info_sauvegarde
BACKED UP n TIMES TO DEVICE TYPE [DISK | ’media’]
Les variantes de syntaxe et options sont les mêmes que pour la commande LIST.
L’option EXPIRED permet de supprimer les éléments marqués EXPIRED dans le référentiel RMAN (éventuellement,
combinée à d’autres critères).
Par défaut, RMAN liste les fichiers qu’il s’apprête à supprimer et demande confirmation de la suppression. L’option
NOPROMPT permet de supprimer la demande de confirmation (mais la liste des fichiers supprimés est toujours
affichée).
La commande DELETE génère une erreur s’il n’existe pas de concordance entre le référentiel et les fichiers
physiques :
●
- 6-
openmirrors.com
Un fichier est marqué EXPIRED dans le référentiel mais existe physiquement.
© ENI Editions - All rights reserved - Algeria Educ
●
Un fichier est marqué AVAILABLE dans le référentiel mais n’existe pas physiquement.
Pour résoudre ce problème, vous pouvez au choix :
●
exécuter la commande CROSSCHECK pour mettre à jour le statut des fichiers dans le référentiel ;
●
utiliser l’option FORCE de la commande DELETE ;
●
utiliser la commande CHANGE ... UNCATALOG pour supprimer du référentiel une référence à un fichier qui
n’existe plus (voir la documentation Oracle).
Réfléchissez bien avant de supprimer quoi que ce soit.
Exemples d’appel
# supprimer les sauvegardes ayant un certain nom
DELETE BACKUP OF DATABASE TAG=’DBINC0’ ;
# supprimer les sauvegardes du fichier de paramètres serveur
# réalisées il y a plus de 7 jours
DELETE NOPROMPT BACKUP OF SPFILE COMPLETED BEFORE ’SYSDATE-7’ ;
# supprimer toutes les sauvegardes marquées EXPIRED
DELETE EXPIRED BACKUP ;
# supprimer tous les fichiers de journalisation archivés générés
# il y plus d’un jour et sauvegardé trois fois sur disque
DELETE ARCHIVELOG UNTIL TIME ’SYSDATE-1’ BACKED UP 3 TIMES TO DISK ;
Supprimer les sauvegardes obsolètes
Syntaxe 2
DELETE [FORCE] [NOPROMPT] OBSOLETE [ condition ] ;
- condition
RECOVERY WINDOW OF n DAYS
REDUNDANCY [=] n
Lorsque la commande est appelée sans option, RMAN supprime les sauvegardes obsolètes en tenant compte de la
politique de conservation configurée (CONFIGURE RETENTION POLICY).
L’option condition permet de préciser le critère que la commande DELETE doit utiliser pour déterminer si une
sauvegarde est obsolète. La syntaxe est la même que dans la commande CONFIGURE RETENTION POLICY.
Si vous utilisez une zone de récupération rapide, RMAN supprimera automatiquement les sauvegardes obsolètes
(compte tenu de la politique de conservation configurée), mais uniquement s’il manque de place.
c. La commande CATALOG
La commande CATALOG permet d’indiquer à RMAN l’existence de fichiers de journalisation archivés ou d’éléments de
sauvegarde qui ne sont pas enregistrés dans le référentiel RMAN.
Cette situation peut se produire dans plusieurs cas :
●
●
●
●
Vous avez utilisé la commande DELETE à mauvais escient et vous avez toujours le fichier physique.
Vous avez effectué une récupération avec une sauvegarde du fichier de contrôle, qui ne contient donc pas
les informations sur ce qui a été fait avec RMAN depuis la sauvegarde en question.
Vous avez recréé le fichier de contrôle (il ne contient plus rien).
Un enregistrement a été supprimé du fichier de contrôle du fait de la valeur du paramètre
CONTROL_FILE_RECORD_KEEP_TIME, mais le fichier physique existe toujours et vous en avez besoin pour une
récupération.
© ENI Editions - All rights reserved - Algeria Educ
- 7-
●
Vous avez déplacé un fichier physique.
Syntaxe
CATALOG { ARCHIVELOG | BACKUPPIECE } liste_fichiers ;
CATALOG { RECOVERY AREA | DB_RECOVERY_FILE_DEST } [NOPROMPT] ;
CATALOG START WITH ’chemin’ [NOPROMPT] ;
La première syntaxe permet de cataloguer des fichiers précis. Si vous cataloguez un élément déjà catalogué, RMAN
supprime l’ancienne référence avant de créer la nouvelle.
La deuxième syntaxe permet de cataloguer tous les fichiers stockés dans la zone de récupération rapide (RECOVERY
AREA et DB_RECOVERY_FILE_DEST sont synonymes).
La troisième syntaxe permet de cataloguer tous les fichiers dont le nom complet commence par une certaine chaîne
de caractères (ne peut pas contenir de caractères joker).
Avec les deux dernières syntaxes, RMAN demande confirmation avant de cataloguer un fichier ; l’option NOPROMPT
permet de supprimer la demande de confirmation. Par ailleurs, RMAN ne catalogue pas les fichiers déjà catalogués.
- 8-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Récupération
1. Vue d’ensemble
La stratégie de récupération dépend de plusieurs facteurs :
●
●
●
De la nature du(des) fichier(s) endommagé(s) ou perdu(s) :
●
fichier de données ;
●
fichier de contrôle ;
●
fichier de paramètres serveur ;
●
fichier de journalisation.
Du mode de fonctionnement de la base :
●
ARCHIVELOG
●
NOARCHIVELOG.
Des sauvegardes disponibles.
Que faire en cas de problème ?
1. identifier la nature du problème ;
2. définir le mode opératoire en tenant compte du mode de fonctionnement de la base et des sauvegardes
disponibles.
Surtout, ne vous précipitez pas et n’hésitez pas à vous faire aider par le support Oracle.
Depuis la version 11, Oracle propose un conseiller pour la récupération des données (le Data Recovery Advisor) qui
permet de diagnostiquer et résoudre facilement les incidents (perte ou corruption) des données sur disque. Ce
nouvel outil est présenté dans la section Data Recovery Advisor.
Dans la suite du document, les termes "perdu" et "endommagé" seront indifféremment utilisés pour désigner
l’incident ; dans la pratique, que le fichier soit perdu ou simplement endommagé, les procédures de restauration sont
les mêmes.
Une opération de récupération s’effectue essentiellement avec RMAN. Pour certaines étapes, SQL*Plus peut être
nécessaire, essentiellement pour interroger quelques vues du dictionnaire de données ; une connexion AS SYSDBA
sera nécessaire si la base n’est pas ouverte.
Un conseil, avant de commencer toute opération de récupération, réalisez si possible une sauvegarde
complète de la base endommagée. Cela peut fournir un point de retour en cas d’aggravation de la situation
par une mauvaise manipulation. Au minimum, réalisez une sauvegarde du fichier de contrôle et des fichiers de
journalisation en ligne (par simple copie au niveau du système d’exploitation).
Dans une opération de "restauration" ou de "récupération", il existe en fait deux étapes bien précises et bien
distinctes :
■
■
L’étape de restauration (restore) consiste à extraire d’une sauvegarde les fichiers nécessaires.
L’étape de récupération (recover) consiste à appliquer les fichiers de journalisation aux fichiers récupérés de la
sauvegarde.
Pour être rigoureux, il faudrait donc évoquer une opération de "restauration et récupération".
© ENI Editions - All rights reserved - Algeria Educ
- 1-
2. Principes généraux de la récupération
a. En mode NOARCHIVELOG
En mode NOARCHIVELOG, le mode opératoire est on ne peut plus simple :
●
restaurer la dernière sauvegarde complète de la base ;
●
redémarrer la base.
Toutes les modifications apportées depuis la dernière sauvegarde sont perdues.
A priori, la restauration en mode NOARCHIVELOG ne permet pas de ramener la base de données à l’état où elle se
trouvait juste avant l’incident ; elle permet juste de ramener la base de données à l’état où elle se trouvait au
moment de la sauvegarde.
Néanmoins, dans certaines situations, il peut être possible de récupérer tout ou partie des modifications apportées
depuis la dernière sauvegarde.
L’objectif des indications données ci­après est de montrer que tout n’est pas forcément perdu. En cas de
problème en mode NOARCHIVELOG, il ne faut pas hésiter à appeler le support Oracle pour tenter avec eux de
réaliser la récupération la plus complète possible. Par contre, pour être certain de garantir une récupération
complète dans toutes les situations (et simplifier le processus de récupération), il faut faire fonctionner la base en
mode ARCHIVELOG.
Les situations sont les suivantes :
●
●
●
Un cycle complet de basculement des fichiers de journalisation n’a pas eu lieu depuis la sauvegarde.
Le fichier de données perdu n’est pas critique pour la base de données (n’appartient pas au tablespace
SYSTEM, ni à au tablespace d’annulation actif), ni pour l’application (ce n’est pas le tablespace principal de
l’application).
Tous les fichiers de contrôle sont perdus mais les autres fichiers (données et journalisation) sont intacts.
Si les fichiers de journalisation n’ont pas subi un cycle complet de basculements depuis la sauvegarde utilisée,
toutes les mises à jour effectuées depuis la sauvegarde en question sont encore "disponibles" dans les fichiers de
journalisation. Dans ce cas, il faut réaliser une récupération comme si la base de données était en mode ARCHIVELOG
(voir les scénarios correspondants).
Si le fichier de données perdu n’est pas critique pour la base de données ni pour l’application, et que le problème
soit survenu alors que la base de données était arrêtée, la situation est plutôt favorable car les fichiers qui restent
sont cohérents entre eux : si ce problème de fichier n’existait pas, le prochain démarrage ne nécessiterait pas de
récupération de l’instance.
Dans ce cas, il est possible :
●
De démarrer la base de données en état MOUNT
SQL> CONNECT / AS SYSDBA
SQL> STARTUP MOUNT
●
De mettre les fichiers de donnés concernés OFFLINE avec l’option DROP
SQL> ALTER DATABASE DATAFILE
2 ’e:\oradata\HERMES\indx01.dbf’ OFFLINE DROP;
●
D’ouvrir la base de données
SQL> ALTER DATABASE OPEN;
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
●
De supprimer le tablespace
SQL> DROP TABLESPACE indx;
●
Puis de recréer le tablespace (et éventuellement son contenu)
SQL> CREATE TABLESPACE indx ... ;
SQL> CREATE INDEX ... ;
À l’arrivée, le tablespace est supprimé : cette technique n’est donc pas applicable si le fichier de données perdu est
critique pour la base de données ou pour l’application. Elle est, par contre, envisageable pour des tablespaces
contenant uniquement des index (les données, elles, ne sont pas perdues).
Si le problème est survenu alors que la base était en fonctionnement, la situation est plus problématique car les
fichiers de données restants ne sont peut­être pas cohérents et il n’existe pas vraiment de moyens de le savoir.
S’ils ne sont pas cohérents, Oracle aura besoin des fichiers de journalisation en ligne pour les rendre cohérents
(c’est la récupération de l’instance "classique"). Si les fichiers de journalisation sont présents, ou si seuls les fichiers
de journalisation INACTIVE sont perdus, la technique présentée précédemment pourra être utilisée ; si les fichiers
de journalisation CURRENT ou ACTIVE sont perdus, la technique ne pourra pas être employée (il faut repartir de la
dernière sauvegarde).
Tous les fichiers de contrôle sont perdus. Dans cette situation critique et délicate, pour laquelle il existe différentes
possibilités de récupération, la documentation Oracle recommande de contacter le support Oracle.
b. En mode ARCHIVELOG
En mode ARCHIVELOG, le mode opératoire de base pour une perte de fichier(s) de données est le suivant :
●
restaurer la dernière sauvegarde de chaque fichier perdu ;
●
appliquer les fichiers de journalisation (archives puis ceux en ligne) ;
●
redémarrer la base (si la récupération n’a pas été faite base ouverte).
Toutes les modifications apportées depuis les sauvegardes utilisées sont récupérées. La récupération est dite
complète.
Ce type de récupération est simple et ne pose pas de problème s’il reste au moins un fichier de contrôle, un
membre par groupe de fichier de journalisation et que toutes les archives de fichiers de journalisation sont
disponibles.
Sur la base de ce scénario, différentes situations peuvent conduire à une récupération incomplète :
●
●
volontairement, pour s’arrêter avant un ordre SQL malencontreux ;
involontairement, si des fichiers de journalisation sont perdus (une archive ou tout un groupe de fichiers de
journalisation en ligne).
Dans la terminologie Oracle, une récupération incomplète est appelée point­in­time recovery.
Si tous les fichiers de contrôle sont perdus, si tout un groupe de fichiers de journalisation est perdu, ou s’il manque
une archive de fichiers de journalisation, la récupération complète sera plus délicate et dans certains cas impossible
(par exemple, s’il manque une archive de fichier de journalisation) ; une récupération incomplète reste alors
possible et la base n’est pas ramenée à l’état où elle se trouvait juste avant l’incident mais à un état antérieur.
Dans certaines situations (suppression de table malencontreuse par exemple), la récupération incomplète peut être
volontaire ; là encore, la base de données n’est pas ramenée à l’état où elle se trouvait juste avant l’incident mais à
un état antérieur.
Quelle que soit l’origine de la récupération incomplète, tout ce qui a été fait, après le moment qui correspond à l’état
de récupération de la base, est perdu et doit être repris à la main : dans une séquence d’application des fichiers de
journalisation, Oracle ne peut pas "sauter" quelques ordres puis continuer.
Lors de la restauration des sauvegardes, si les sauvegardes sont partielles, il faut prendre la sauvegarde la plus
récente de chaque fichier endommagé.
© ENI Editions - All rights reserved - Algeria Educ
- 3-
3. Les incidents sur les fichiers de contrôle et de journalisation
Les incidents sur les fichiers de contrôle et les fichiers de journalisation peuvent être classés en deux
catégories : "peu graves" et "très graves".
Incidents peu graves :
●
perte d’un ou plusieurs fichiers de contrôle, du moment qu’il en reste au moins un ;
●
perte d’un ou plusieurs fichiers de journalisation, du moment qu’il en reste au moins un par groupe.
Incidents plus graves et plus complexes à traiter :
●
●
perte de tous les fichiers de contrôle : moyennement grave si les autres fichiers sont intacts ;
perte de tous les membres d’un groupe de fichiers de journalisation : la gravité dépend du statut du groupe
perdu (CURRENT, ACTIVE, INACTIVE).
Ces situations sont évitées si l’on multiplexe correctement les fichiers de contrôle et les fichiers de journalisation. La
perte de tous les fichiers de contrôle n’est pas la situation la plus complexe à traiter, s’il existe des sauvegardes
récentes du fichier de contrôle et si les autres fichiers (particulièrement, les fichiers de journalisation) sont
intacts ; dans ce cas, une récupération complète est possible.
La perte de tous les membres d’un groupe de fichiers de journalisation est bien plus complexe à traiter ; la situation
de départ doit être analysée avec soin (statut du groupe perdu, état des autres fichiers, etc.), afin de choisir le bon
mode opératoire. Pour les situations complexes, il est vivement conseillé de se faire aider par le support Oracle.
4. Identifier la nature du problème
a. Message d’erreur concernant les fichiers de contrôle
Les messages d’erreurs les plus fréquents sur les fichiers de contrôle sont les suivants :
ORA-00204: erreur lors
du fichier de contrôle
ORA-00205: erreur lors
de contrôle; consultez
ORA-00206: erreur lors
du fichier de contrôle
de la lecture (bloc, nbre blocs)
de l’identification du fichier
le journal des alertes
de l’écriture (bloc, nbre blocs)
Ces messages indiquent qu’au moins un fichier de contrôle est endommagé ou perdu ; il faut consulter le fichier des
alertes de l’instance pour en savoir plus, notamment pour déterminer les fichiers endommagés et en déduire les
fichiers intacts, s’il en reste. En cas de problème sur un fichier de contrôle, l’instance s’arrête. Au redémarrage,
l’instance reste en état NOMOUNT.
b. Message d’erreur concernant les fichiers de journalisation
Les messages d’erreur les plus fréquents sur les fichiers de journalisation sont les suivants :
ORA-00313: échec d’ouverture des membres du groupe de journaux n, thread p
ORA-00315: journal n, thread p, numéro de thread x incorrect
dans en-tête
ORA-00316: le journal n dans le thread p, type x dans l’en-tête,
n’est pas un fichier journal
ORA-00317: le type de fichier x dans l’en-tête n’est pas un fichier journal
ORA-00318: journal n, thread p, taille x de fich. attendue
ne correspond pas à y
ORA-00319: journal n du thread p a un état de réinitialisation incorrect
ORA-00320: impossible lire en-tête de fichier du journal n thread p
ORA-00321: fichier n, thread p, impossible de mettre à jour l’en-tête
du fichier journal
- 4-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Ces messages s’accompagnent d’un ou plusieurs messages ORA-00312 donnant le nom du fichier :
ORA-00312: journal en ligne n thread p : fichier
En cas de problème sur tout un groupe de fichiers de journalisation, l’instance s’arrête. Au redémarrage, l’instance
reste en état MOUNT.
En cas de problème, il faut consulter le fichier d’alerte de l’instance et le fichier de trace du processus LGWR.
c. Message d’erreur concernant les fichiers de données
Il y a de nombreux messages d’erreur possibles concernant les fichiers de données, par exemple :
ORA-01157: impossible d’identifier ou de verrouiller le fichier
de données n - voir le fichier de trace DBWR
Ces messages s’accompagnent d’un ou plusieurs messages ORA-01110 donnant le nom du fichier :
ORA-01110: fichier de données n : fichier
En mode NOARCHIVELOG, si la base de données est ouverte et qu’un problème se produise sur un fichier de données,
l’instance s’arrête. En mode ARCHIVELOG, il en est de même mais uniquement si le fichier de données incriminé est un
fichier du tablespace SYSTEM ou un fichier de données du tablespace d’annulation actif.
Au démarrage, l’instance reste en état MOUNT.
En cas de problème, il faut consulter le fichier d’alerte de l’instance et le fichier de trace du processus DBWR.
D’autres fichiers, eux aussi endommagés, peuvent être cités.
Lorsque la base de données est montée ou ouverte, vous pouvez interroger la vue V$RECOVER_FILE pour déterminer
la liste des fichiers de données sur lesquels il existe un problème.
Les colonnes intéressantes de la vue V$RECOVER_FILE sont les suivantes :
FILE#
Identifiant du fichier (jointure sur V$DATAFILE.FILE# pour récupérer des informations complémentaires sur le fichier).
ONLINE_STATUS
Statut du fichier (ONLINE ou OFFLINE).
ERROR
Nature de l’erreur. Vide si l’erreur est inconnue et OFFLINE NORMAL si le fichier est hors ligne sans erreur (pas besoin
de restauration dans ce cas).
Exemple
SQL> SELECT file#,error,online_status FROM v$recover_file;
FILE# ERROR
ONLINE_
---------- ------------------------------ ------5 FILE NOT FOUND
ONLINE
Sur cet exemple, le fichier de données 5 doit être restauré.
La commande VALIDATE
endommagés.
DATABASE peut aussi être utilisée pour identifer les fichiers de données perdus ou
5. Les commandes RMAN
a. Introduction
Dans RMAN, les opérations de restauration et de récupération vont s’effectuer respectivement avec les commandes
RESTORE et RECOVER.
© ENI Editions - All rights reserved - Algeria Educ
- 5-
La commande RESTORE permet de restaurer les fichiers à partir des sauvegardes. La commande RECOVER permet de
procéder à une récupération complète ou incomplète.
La syntaxe générale de ces deux commandes est du type :
{ RESTORE | RECOVER } cible [options] ;
Votre principale responsabilité, lorsque vous utilisez ces commandes, est de bien choisir la cible en fonction de la
nature du problème. Ensuite, RMAN se charge normalement de tout : identifier les sauvegardes à utiliser, et en
extraire les fichiers requis ; identifier les fichiers de journalisation archivés nécessaires et les extraire d’une
sauvegarde s’ils ont été sauvegardés puis supprimés.
Les options de ces deux commandes ne seront nécessaires que pour traiter des cas particuliers : sauvegarde non
disponible, volonté de revenir à un instant dans le passé (récupération incomplète), etc. Dans la grande majorité
des cas, vous ne devriez pas en avoir besoin.
Les principes de fonctionnement généraux de ces commandes vont d’abord être présentés, puis nous verrons
comment les utiliser dans différents scénarios de restauration.
Les commandes RESTORE et RECOVER proposent un très grand nombre d’options. Dans cet ouvrage, nous
présenterons uniquement les options les plus couramment utilisées.
b. La commande RESTORE
La syntaxe simplifiée de la commande RESTORE est la suivante :
RESTORE cibles [options]
- cibles
DATABASE
DATAFILE liste_numéros_ou_noms
TABLESPACE liste_noms
CONTROLFILE [TO ’destination’] [FROM AUTOBACKUP | ’sauvegarde’]
SPFILE [TO ’destination’] [FROM AUTOBACKUP | ’sauvegarde’]
ARCHIVELOG { ALL | filtre_archive }
- filtre_archive
FROM TIME ’date’
UNTIL TIME ’date’
TIME BETWEEN ’date1’ AND ’date2’
- options
PREVIEW [SUMMARY]
VALIDATE
L’option cibles permet d’indiquer ce qu’il convient de restaurer. L’option DATABASE permet de restaurer la totalité de
la base de données ; elle ne doit être utilisée que si vous souhaitez ou devez effectivement restaurer la totalité de
la base de données. En mode ARCHIVELOG, si un fichier de données est endommagé, vous ne devrez restaurer que
le fichier en question, en utilisant les options DATAFILE ou TABLESPACE.
L’option PREVIEW est intéressante pour lister les sauvegardes dont RMAN a besoin pour réaliser l’opération de
restauration correspondante. L’option SUMMARY permet d’obtenir un affichage résumé. L’affichage est le même
qu’avec la commande LIST.
L’option VALIDATE permet de tester si la restauration correspondante peut être réalisée. RMAN accède aux
sauvegardes et vérifie qu’il peut en extraire les fichiers nécessaires. Il existe aussi une commande VALIDATE
BACKUPSET qui permet de tester des jeux de sauvegarde spécifiques (voir la documentation Oracle).
c. La commande RECOVER
La syntaxe simplifiée de la commande RECOVER est la suivante :
RECOVER cible [options]
- cible
DATABASE
DATAFILE liste_numéros_ou_noms
TABLESPACE liste_noms
- options
DELETE ARCHIVELOG [MAXSIZE taille [K|M|G]]
- 6-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
L’option cible permet d’indiquer ce qu’il convient de récupérer : la base de données dans sa totalité, ou des
tablespaces ou fichiers de données spécifiques.
Lors de l’opération de récupération, RMAN recherche les fichiers de journalisation archivés dont il a besoin, en
premier lieu sur le disque. Les fichiers de journalisation archivés manquants sont automatiquement restaurés à
partir de sauvegardes, vers le répertoire d’archivage défini par le paramètre LOG_ARCHIVE_DEST_1 (où vers une autre
destination ­ voir la commande SET ARCHIVELOG DESTINATION dans la documentation).
À la fin de l’opération, les fichiers de journalisation archivés restaurés ailleurs que dans la zone de récupération
rapide, ne sont pas supprimés par défaut. L’option DELETE ARCHIVELOG permet de supprimer les fichiers de
journalisation archivés restaurés qui ne sont plus nécessaires, au fur et à mesure de leur application. L’option
MAXSIZE permet au besoin, de limiter l’espace utilisé par RMAN pour les fichiers de journalisation archivés restaurés.
Si cette option est spécifiée, RMAN procédera à la restauration des fichiers de journalisation archivés en plusieurs
étapes, pour ne pas dépasser la taille indiquée. Assurez­vous que la taille indiquée est supérieure à la taille des
fichiers de journalisation archivés, sinon vous obtiendriez une erreur.
La récupération peut utiliser des sauvegardes incrémentales ou des fichiers de journalisation archivés. Si RMAN a le
choix, il utilise en priorité les sauvegardes incrémentales.
6. Scénarios de récupération
a. Présentation
Dans cet ouvrage, nous allons présenter les scénarios de récupération de base suivants :
●
récupération du fichier de paramètres serveur ;
●
récupération d’un fichier de contrôle ;
●
récupération d’un fichier de journalisation ;
●
récupération complète de la totalité de la base de données en mode ARCHIVELOG ;
●
récupération complète d’une partie de la base de données en mode ARCHIVELOG ;
●
récupération de tous les fichiers de contrôle en mode ARCHIVELOG ;
●
récupération incomplète en mode ARCHIVELOG ;
●
récupération en mode NOARCHIVELOG.
En complément, nous évoquerons deux cas particuliers :
●
récupération à un emplacement différent ;
●
tablespace temporaire géré localement.
Dans un cas de récupération réel, vous serez peut­être amenés à combiner plusieurs de ces scénarios de base. Par
exemple, si vous avez perdu un fichier de contrôle et un tablespace, et si vous êtes en mode ARCHIVELOG, vous
appliquerez les scénarios suivants, dans l’ordre :
●
récupération d’un fichier de contrôle ;
●
récupération complète d’une partie de la base de données en mode ARCHIVELOG.
En règle générale, si vous avez perdu le fichier de paramètres serveur, un fichier de contrôle et/ou un fichier de
journalisation, vous devez d’abord résoudre ces problèmes avant de traiter le cas des fichiers de données.
Tous ces scénarios sont basés sur les hypothèses suivantes :
© ENI Editions - All rights reserved - Algeria Educ
- 7-
●
Vous avez activé la sauvegarde automatique du fichier de contrôle et du fichier de paramètres serveur.
●
Vous utilisez une zone de récupération rapide.
●
Vous n’utilisez pas de base de données annexe pour stocker le catalogue RMAN.
Quel que soit le scénario, si le fichier est en fait simplement temporairement inaccessible (contrôleur disque
en panne par exemple), une restauration n’est pas nécessaire ; il suffit de corriger le problème pour rendre
le fichier de nouveau disponible et de redémarrer la base. Une restauration est néanmoins envisageable s’il n’est
pas possible d’attendre que le problème soit corrigé.
b. Récupération du fichier de paramètres serveur
En cas de perte du fichier de paramètres serveur, vous avez deux possibilités :
●
Le recréer à partir d’un fichier de paramètres texte (voir le chapitre 7).
●
Le récupérer à partir d’une sauvegarde RMAN.
Pour le récupérer à partir d’une sauvegarde automatique RMAN située dans la zone de récupération rapide, le mode
opératoire est le suivant :
●
Démarrer l’instance sans monter la base de données (notez que RMAN va utiliser un fichier de paramètres
"temporaire" pour démarrer l’instance)
RMAN> STARTUP NOMOUNT
échec du démarrage : ORA-01078: failure in processing system parameters
LRM-00109: impossible d’ouvrir le fichier de paramètres
’D:\APP\ORACLE\PRODUCT\11.1.0\DB_1\DATABASE\INITHERMES.ORA’
démarrage de l’instance Oracle sans fichier de paramètres
pour extraction de SPFILE
instance Oracle démarrée
Total System Global Area (SGA)
159019008 octets
Fixed Size
1331852 octets
Variable Size
67112308 octets
Database Buffers
88080384 octets
Redo Buffers
2494464 octets
●
Restaurer le fichier de paramètres serveur à partir d’une sauvegarde automatique en spécifiant
l’emplacement de la zone de récupération rapide et le nom (ou le nom unique) de la base de données
RMAN> RESTORE SPFILE FROM AUTOBACKUP
2>
DB_RECOVERY_FILE_DEST ’H:\oradata\flash_recovery_area’
3>
DB_NAME ’HERMES’;
Démarrage de restore dans 05/08/08
utilisation du canal ORA_DISK_1
destination de la zone de récupération : H:\oradata\flash_recovery_area
nom de base de données (ou nom unique de base de données) utilisé pour
la recherche : HERMES
canal ORA_DISK_1 : AUTOBACKUP H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\
AUTOBACKUP\2008_08_05\O1_MF_S_661968988_49JR5XWS_.BKP trouvé
dans la zone de récupération
canal ORA_DISK_1 : recherche de AUTOBACKUP effectuée le : 20080805
canal ORA_DISK_1 : restauration du fichier SPFILE à partir
de AUTOBACKUP H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\AUTOBACKUP\
2008_08_05\
O1_MF_S_661968988_49JR5XWS_.BKP
canal ORA_DISK_1 : restauration de SPFILE depuis AUTOBACKUP terminée
Fin de restore dans 05/08/08
●
- 8-
openmirrors.com
Redémarrer l’instance et ouvrir la base de données
© ENI Editions - All rights reserved - Algeria Educ
RMAN> SHUTDOWN
...
RMAN> STARTUP
...
Si la sauvegarde automatique n’est pas stockée dans la zone de récupération rapide, le mode opératoire est
différent. Il faut positionner le DBID correspondant à la base de données (SET DBID …), spécifier le format utilisé
pour les sauvegardes automatiques (SET CONTROLFILE AUTOBACKUP FORMAT …) avant de restaurer la sauvegarde par
un RESTORE SPFILE FROM AUTOBACKUP (sans autre option).
Il est aussi possible de restaurer le fichier de paramètre serveur en spécifiant la sauvegarde à utiliser : RESTORE
SPFILE FROM ’sauvegarde’.
c. Récupération d’un fichier de contrôle
Dans le cas où vous avez perdu un ou plusieurs fichiers de contrôle, mais qu’il vous en reste encore au moins un,
vous ne devez pas repartir d’une sauvegarde de fichier de contrôle. Vous allez simplement dupliquer un des fichiers
de contrôle restants pour remplacer les fichiers perdus.
Nous supposons que l’instance est arrêtée.
Le mode opératoire est le suivant :
●
●
●
utiliser le fichier d’alerte de l’instance pour identifier les fichiers de contrôle endommagés ou perdus et en
déduire qu’il reste bien au moins un fichier de contrôle valide ;
dupliquer une version valide du fichier de contrôle pour la mettre à la place du (des) fichier(s) de contrôle
endommagé(s) ;
redémarrer la base de données (STARTUP).
Si un fichier de contrôle est dupliqué à un autre emplacement que l’emplacement d’origine, il faut modifier le
paramètre CONTROL_FILES dans le fichier de paramètres serveur. Au lieu de redémarrer directement la base de
données, il faudra procéder de la manière suivante :
●
Démarrer l’instance, sans monter la base de données
SQL> STARTUP NOMOUNT
●
Modifier le paramètre CONTROL_FILES dans le fichier de paramètres serveur :
SQL> ALTER SYSTEM SET CONTROL_FILES=
2 ’f:\oradata\HERMES\control01.ctl’,
3 ’h:\oradata\HERMES\control02.ctl’ -- changement
4 SCOPE=SPFILE;
●
Redémarrer l’instance
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP
La duplication d’une version valide du fichier de contrôle peut s’effectuer dans RMAN, à l’aide d’une variante de la
commande RESTORE CONTROLFILE. Exemple :
RMAN> RESTORE CONTROLFILE FROM ’F:\oradata\HERMES\control01.ctl’ ;
La commande traite d’un seul coup tous les fichiers de contrôle manquants en se basant sur la valeur du paramètre
CONTROL_FILES.
Il est également possible de démarrer temporairement avec moins de fichiers de contrôle ; dans ce cas, il sera aussi
nécessaire de modifier la paramètre CONTROL_FILES dans le fichier de paramètres serveur.
d. Récupération d’un fichier de journalisation
© ENI Editions - All rights reserved - Algeria Educ
- 9-
Si vous avez perdu un ou plusieurs fichiers de journalisation, mais qu’il vous en reste au moins un par groupe, vous
n’avez pas besoin de réaliser de restauration ou de récupération de la base de données. Vous allez simplement
recréer les fichiers de journalisation perdus.
Le mode opératoire est le suivant :
●
●
Identifier le (les) fichier(s) de journalisation endommagé(s) dans le fichier d’alerte de l’instance, dans le
fichier de trace de LGWR ou dans la vue V$LOGFILE.
Supprimer le membre endommagé
SQL> ALTER DATABASE DROP LOGFILE MEMBER ’nom_fichier’;
●
Ajouter un nouveau membre au groupe concerné
SQL> ALTER DATABASE ADD LOGFILE MEMBER ’nom_fichier’
2 TO GROUP numéro;
●
Réitérer les deux opérations précédentes avec tous les membres endommagés.
Les fichiers de journalisation endommagés ont une colonne STATUS à INVALID dans la vue V$LOGFILE.
Le fichier de journalisation ajouté peut être mis à un autre emplacement ; s’il est remis au même emplacement que
le précédent, il faudra peut­être au préalable supprimer physiquement l’ancien fichier (s’il est présent, le mettre
simplement de côté au cas où) ou utiliser la clause REUSE dans l’ordre SQL.
Vous ne pourrez pas supprimer le membre s’il appartient au groupe courant. Dans ce cas, il faut changer de groupe
courant en exécutant l’ordre SQL ALTER SYSTEM SWITCH LOGFILE. Cet ordre SQL ne peut être exécuté que si la base
de données est ouverte. Si la base de données est fermée, et qu’elle ne puisse pas être ouverte tout de suite,
vous pouvez reporter la correction du problème à plus tard ou vous contenter de recréer le membre ; la suppression
pourra avoir lieu plus tard, une fois la base de données ouverte.
Il peut être possible aussi de fonctionner temporairement avec moins de membres dans un groupe de fichiers de
journalisation.
e. Récupération complète de la totalité de la base de donnéesc en mode ARCHIVELOG
Ce scénario émet l’hypothèse que vous avez perdu tous les fichiers de données. L’instance est arrêtée.
Le mode opératoire est le suivant :
●
Monter la base de données
RMAN> STARTUP MOUNT
●
Restaurer la base de données
RMAN> RESTORE DATABASE ;
Démarrage de restore dans 05/08/08
...
Fin de restore dans 05/08/08
●
Récupérer la base de données
RMAN> RECOVER DATABASE ;
Démarrage de recover dans 05/08/08
...
Fin de recover dans 05/08/08
●
Ouvrir la base de données
RMAN> ALTER DATABASE OPEN ;
Si vous n’utilisez pas la zone de récupération rapide pour l’archivage, vous pouvez spécifier l’option DELETE
ARCHIVELOG dans la commande RECOVE pour supprimer les fichiers de journalisation archivés restaurés au fur et à
- 10 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
mesure de leur application et éventuellement limiter l’espace utilisé par ces fichiers.
f. Récupération complète d’une partie de la base de données en mode ARCHIVELOG
Ce scénario émet l’hypothèse que vous avez perdu un ou plusieurs fichiers de données (mais pas tous).
Cette opération peut être réalisée base fermée ou base ouverte, selon la nature du problème.
●
●
Si un fichier de données du tablespace SYSTEM, ou un fichier du tablespace d’annulation actif est perdu,
l’instance s’est arrêtée et vous ne pourrez pas ouvrir la base de données sans récupérer les fichiers en
question.
S’il s’agit d’un autre fichier de données, la base de données peut rester ouverte. Par contre, si elle était
fermée, elle ne peut pas être ouverte.
Récupération base de données fermée
Dans cet exemple, le fichier de données du tablespace SYSTEM est perdu ; l’instance est arrêtée.
Le mode opératoire est le suivant :
●
Monter la base de données :
RMAN> STARTUP MOUNT
instance Oracle démarrée
...
●
Restaurer les fichiers de données souhaités soit par un RESTORE TABLESPACE, soit par un RESTORE DATAFILE
RMAN> RESTORE TABLESPACE system ;
●
Récupérer les fichiers de données soit par un RECOVER TABLESPACE, soit par un RECOVER DATAFILE
RMAN> RECOVER TABLESPACE system ;
●
Ouvrir la base de données
RMAN> ALTER DATABASE OPEN ;
Récupération base de données ouverte
Dans cet exemple, le fichier de données du tablespace INDX est perdu (fichier de données numéro 6).
Si la base de données est fermée, mais que vous souhaitiez réaliser la récupération base ouverte (pour que les
utilisateurs puissent recommencer à travailler), commencez par la première partie du mode opératoire. Si la base de
données est déjà ouverte, passez directement à la deuxième partie du mode opératoire.
La première partie du mode opératoire est la suivante :
●
Monter la base de données
RMAN> STARTUP MOUNT
●
Mettre OFFLINE les fichiers de données perdus
RMAN> SQL "ALTER DATABASE DATAFILE 6 OFFLINE";
●
Ouvrir la base de données
RMAN> ALTER DATABASE OPEN;
La deuxième partie du mode opératoire est la suivante :
© ENI Editions - All rights reserved - Algeria Educ
- 11 -
●
Passer OFFLINE les tablespaces concernés ; vous devez utiliser l’option IMMEDIATE, car un fichier de données
n’est pas accessible
RMAN> SQL "ALTER TABLESPACE indx OFFLINE IMMEDIATE";
●
Restaurer les fichiers de données souhaités soit par un RESTORE TABLESPACE, soit par un RESTORE DATAFILE
RMAN> RESTORE DATAFILE 6 ;
●
Récupérer les fichiers de données soit par un RECOVER TABLESPACE, soit par un RECOVER DATAFILE
RMAN> RECOVER DATAFILE 6 ;
●
Passer ONLINE les tablespaces concernés
RMAN> SQL "ALTER TABLESPACE indx ONLINE";
g. Récupération de tous les fichiers de contrôle en mode ARCHIVELOG
Dans ce scénario, nous supposons que nous avons perdu tous les fichiers de contrôle ainsi qu’un fichier de
données. Il ne s’agit pas d’une catastrophe car nous disposons de sauvegardes automatiques du fichier de contrôle
(dans la zone de récupération rapide) et les fichiers de journalisation en ligne sont disponibles. L’instance est
arrêtée.
Le mode opératoire est le suivant :
●
Démarrer l’instance sans monter la base de données
RMAN> STARTUP NOMOUNT
●
Restaurer les fichiers de contrôle à partir d’une sauvegarde automatique (dans la zone de récupération
rapide).
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;
●
Monter la base de données
RMAN> ALTER DATABASE MOUNT ;
■
Restaurer les fichiers de données perdus (déjà vu)
RMAN> RESTORE DATAFILE 5 ;
●
Récupérer la base de données (pas uniquement les fichiers de données car nous repartons d’une
sauvegarde de fichiers de contrôle)
RMAN> RECOVER DATABASE ;
●
Ouvrir la base de données avec l’option RESETLOGS (obligatoire)
RMAN> ALTER DATABASE OPEN RESETLOGS ;
●
Vous obtenez une nouvelle "incarnation" de la base de données
RMAN> LIST INCARNATION OF DATABASE ;
Liste des incarnations de base de données
DB Key Inc Key DB Name DB ID
------- ------- -------- ---------------1
1
HERMES
3535892647
2
2
HERMES
3535892647
- 12 -
openmirrors.com
STATUS
------PARENT
CURRENT
Reset SCN
---------1
460308
© ENI Editions - All rights reserved - Algeria Educ
Reset Time
---------16/07/08
05/08/08
Dans la commande
RESTORE
CONTROLFILE
FROM
AUTOBACKUP, vous pouvez spécifier les options
DB_RECOVERY_FILE_DEST et DB_NAME (ou DB_UNIQUE_NAME) si les valeurs actuelles ne sont pas correctes. Par contre, si
la sauvegarde automatique du fichier de contrôle n’est pas stockée dans la zone de récupération rapide, le mode
opératoire est différent. Il faut positionner le DBID correspondant à la base de données (SET DBID …), spécifier le
format utilisé pour les sauvegardes automatiques (SET CONTROLFILE AUTOBACKUP FORMAT …) avant de restaurer la
sauvegarde par un RESTORE CONTROLFILE FROM AUTOBACKUP.
Lorsque vous repartez d’une sauvegarde de fichier de contrôle, RMAN effectue automatiquement un CROSSCHECK et
un CATALOG RECOVERY AREA pour mettre à jour le référentiel dans les fichiers de contrôle (qui ne sont pas à jour
puisqu’ils proviennent d’une sauvegarde), en fonction de la réalité physique des fichiers.
Par ailleurs, vous devez ouvrir la base de donénes avec l’option RESETLOGS. Même si la récupération est complète,
Oracle considère que c’est une nouvelle vie de la base de données, une nouvelle « incarnation » de la base de
données. Les numéros de séquence des fichiers de journalisation vont repartir de zéro.
Dans les versions précédentes d’Oracle, toutes les sauvegardes et tous les fichiers de journalisation archivés
antérieurs à l’ouverture en mode RESETLOGS étaient pratiquement inexploitables.
Depuis la version 10, ce n’est plus le cas. Lors d’une ouverture en mode RESETLOGS, Oracle associe un numéro
d’activation à la "nouvelle" base de données. Ce numéro d’activation est utilisé par Oracle à différents endroits,
dont le nom des fichiers de journalisation archivés (variable %r dans le paramètre LOG_ARCHIVE_FORMAT). De cette
manière, Oracle est capable d’associer n’importe quel fichier à une incarnation de la base de données.
Le numéro d’activation courant peut être consulté dans la colonne INCARNATION# de la vueV$DATABASE. L’historique
des incarnations d’une base de données peut être consulté dans la vue V$DATABASE_INCARNATION. Dans RMAN, la
commande LIST INCARNATION donne la liste des incarnations de la base de données.
Dans le fichier des alertes de l’instance, vous trouverez aussi des messages du type :
RESETLOGS after complete recovery through change 460307
Resetting resetlogs activation ID 3535886503 (0xd2c158a7)
Tue Aug 05 18:09:16 2008
Setting recovery target incarnation to 2
La notion d’incarnation de base de données est l’un des sujets les plus complexes d’Oracle.
h. Récupération incomplète en mode ARCHIVELOG
Ce scénario va illustrer la technique de récupération incomplète, en partant d’une situation catastrophe : tout est
perdu (fichier de paramètres serveur, fichiers de contrôle, fichiers de données et fichiers de journalisation en ligne).
L’instance est arrêtée.
Une récupération incomplète est nécessaire dans plusieurs cas :
●
perte de tous les fichiers de journalisation en ligne (c’est le cas dans ce scénario) ;
●
perte d’un fichier de journalisation archivé, nécessaire à une récupération ;
●
retour avant un ordre SQL malencontreux (DROP TABLE, DROP TABLESPACE, DROP USER, etc.).
Dans tous les cas, il faudra identifier le point de retour souhaité par une date/heure, un numéro SCN ou un numéro
de séquence de fichier de journalisation.
À la fin de la récupération, il faudra, là encore, ouvrir la base de données avec l’option RESETLOGS : c’est une
nouvelle incarnation de la base de données.
Ce scénario est une combinaison de scénarios déjà étudiés.
Le mode opératoire est le suivant :
●
Démarrer l’instance sans monter la base de données (RMAN utilise un fichier de paramètres "temporaire" car
le fichier de paramètres serveur est perdu) :
RMAN> STARTUP NOMOUNT
échec du démarrage : ...
démarrage de l’instance Oracle sans fichier de paramètres ...
instance Oracle démarrée
© ENI Editions - All rights reserved - Algeria Educ
- 13 -
...
●
Restaurer le fichier de paramètres serveur à partir d’une sauvegarde automatique (stockée dans la zone de
récupération rapide pour cet exemple) :
RMAN> RESTORE SPFILE FROM AUTOBACKUP
2>
DB_RECOVERY_FILE_DEST ’H:\oradata\flash_recovery_area’
3>
DB_NAME ’HERMES’;
●
Redémarrer l’instance sans monter la base de données (démarrage avec le fichier de paramètres serveur
restauré) :
RMAN> STARTUP NOMOUNT FORCE
●
Restaurer les fichiers de contrôle à partir d’une sauvegarde automatique (stockée dans la zone de
récupération rapide pour cet exemple) :
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP ;
●
Monter la base de données :
RMAN> ALTER DATABASE MOUNT ;
●
Restaurer et récupérer la base de données :
RMAN> RESTORE DATABASE ;
...
RMAN> RECOVER DATABASE ;
Démarrage de recover dans 06/08/08
...
RMAN-03002: échec de la commande recover à 08/06/2008 07:37:00
RMAN-06054: la récupération après défaillance matérielle requiert
un journal inconnu : thread 1, séquence 7 et SCN de début 475124
●
Ouvrir la base de données avec l’option RESETLOGS :
RMAN> ALTER DATABASE OPEN RESETLOGS ;
Dans ce scénario, avec le mode opératoire utilisé ici, il est normal que la commande RECOVER se termine avec une
erreur puisqu’il manque un fichier de journalisation. Au préalable, la commande RESTORE a effectué automatiquement
un CROSSCHECK et un CATALOG RECOVERY AREA pour mettre à jour le référentiel (notamment les fichiers de
journalisation archivés disponibles) dans les fichiers de contrôle ; la commande RECOVER est donc, allée le plus loin
possible avec les éléments à sa disposition. Avant d’ouvrir la base dans le mode RESETLOGS, assurez­vous que le
numéro de séquence du dernier fichier de journalisation appliqué est conforme à vos attentes.
Dans le cas où nous souhaitons préciser explicitement le point de retour, il est possible d’utiliser une clause UNTIL
dans les commandes RESTORE et RECOVER ; cette clause offre plusieurs options :
UNTIL SCN [=] n
Jusqu’à un numéro SCN (non compris).
UNTIL SEQUENCE[=] n
Jusqu’à un numéro de séquence d’un fichier de journalisation (non compris).
UNTIL TIME [=]’date’
Jusqu’à une date/heure (non comprise). Peut être spécifié sous la forme d’une constante (au format de date
courant) ou une expression du type ’SYSDATE-1’ ou "TO_DATE(…)".
Dans un bloc RUN, il est aussi possible d’utiliser la commande SET UNTIL avant d’exécuter les commandes RESTORE et
RECOVER :
- 14 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
RUN
{
SET UNTIL ... ;
RESTORE DATABASE ;
RECOVER DATABASE ;}
i. Récupération en mode NOARCHIVELOG
Dans ce scénario, nous supposons que nous avons perdu tout ou partie de la base de données et que cette
dernière fonctionne en mode NOARCHIVELOG.
Dans ce cas, normalement, la seule solution de récupération consiste à ramener la base de données à l’état où elle
se trouvait lors de la dernière sauvegarde complète base fermée, cette dernière pouvant être une sauvegarde
incrémentale.
Néanmoins, comme nous l’avions indiqué précédemment, il est peut être envisageable de réaliser une récupération
complète si les fichiers de journalisation sont disponibles et qu’il n’y ait pas eu un cycle complet de basculement des
fichiers de journalisation depuis la dernière sauvegarde. Vous pouvez alors tenter une restauration de type
ARCHIVELOG (points e. ou f.) :
●
restauration des fichiers de données endommagés ;
●
récupération des fichiers de données endommagés.
Si la récupération ne signale pas d’erreur, c’est gagné. Par contre, si la récupération signale une erreur du type
suivant, la situation est a priori désespérée :
journal d’archivage introuvable
journal d’archivage, thread=1, séquence=7
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: échec de la commande recover à 08/06/2008 07:37:00
RMAN-06054: la récupération après défaillance matérielle requiert un
journal inconnu : thread 1, séquence 7 et SCN de début 475124
Dans ce cas, il ne reste plus qu’à réaliser une récupération en mode NOARCHIVELOG, à l’aide du mode opératoire
suivant :
●
Démarrer l’instance sans monter la base de données
RMAN> STARTUP NOMOUNT
●
Restaurer les fichiers de contrôle à partir d’une sauvegarde automatique (stockée dans la zone de
récupération rapide pour cet exemple)
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;
●
Monter la base de données
RMAN> ALTER DATABASE MOUNT ;
●
Restaurer la base de données
RMAN> RESTORE DATABASE;
●
Si vous utilisez des sauvegardes incrémentales cohérentes (base fermée) de la totalité de la base de
données, la commande RESTORE précédente aura ramené la dernière sauvegarde de niveau 0. Vous pouvez
alors réaliser une récupération (RECOVER) avec l’option NOREDO, pour que RMAN applique les sauvegardes
incrémentales de niveau 1 postérieur à la sauvegarde de niveau 0, sans appliquer les fichiers de
journalisation.
RMAN> RECOVER DATABASE NOREDO;
© ENI Editions - All rights reserved - Algeria Educ
- 15 -
●
Ouvrir la base de données avec l’option RESETLOGS (obligatoire)
RMAN> ALTER DATABASE OPEN RESETLOGS ;
Là encore, vous obtenez une nouvelle incarnation de la base de données ; c’est normal puisque vous être revenu à
un instant donné du passé.
j. Récupération à un emplacement différent
Dans certains cas, il peut être impossible de restaurer les fichiers de données dans l’arborescence d’origine. Il
faudra alors utiliser deux commandes supplémentaires dans le processus de restauration :
●
Avant la restauration (RESTORE) : SET NEWNAME FOR DATAFILE pour indiquer à RMAN le nouvel emplacement
d’un fichier de données
SET NEWNAME FOR DATAFILE ’ancien_chemin’ | numéro_fichier
TO ’nouveau_chemin’ ;
●
Après la restauration (RESTORE) et avant la récupération (RECOVER) : SWITCH DATAFILE pour mettre à jour le
fichier de contrôle (équivalent à l’ordre SQL ALTER DATABASE RENAME FILE)
SWITCH DATAFILE ALL ;
Ces deux commandes doivent être exécutées dans un bloc RUN.
Exemple pour restaurer un fichier de données à un autre emplacement
RUN
{
# si l’instance est arrêtée, la démarrer
# et monter la base de données
STARTUP MOUNT
#
# si la base de données est ouverte,
# mettre le tablespace OFFLINE
# SQL "ALTER TABLESPACE data OFFLINE IMMEDIATE" ;
#
SET NEWNAME FOR DATAFILE ’e:\oradata\HERMES\data01.dbf’
TO ’f:\oradata\HERMES\data01.dbf’ ;
RESTORE TABLESPACE data ;
SWITCH DATAFILE ALL ;
RECOVER TABLESPACE data ;
# si la base de données est montée, l’ouvrir
ALTER DATABASE OPEN ;
#
# si la base de données est ouverte,
# mettre le tablespace ONLINE
# SQL "ALTER TABLESPACE data ONLINE" ;
}
k. Cas particulier du tablespace temporaire géré localement
Les fichiers de données des tablespaces temporaires gérés localement ne sont jamais sauvegardés par RMAN et ne
peuvent donc pas être restaurés.
Si vous perdez un fichier de données d’un tablespace temporaire géré localement, vous n’avez normalement rien de
particulier à faire car Oracle le recrée, si besoin, automatiquement lors de l’ouverture de la base de données. Dans
le fichier d’alerte de l’instance, vous trouverez alors des messages du type suivant :
2008-08-07 06:58:51.171000 +02:00
Re-creating tempfile E:\ORADATA\HERMES\TEMP01.DBF
Pour vérifier que les fichiers de données des tablespaces temporaire gérés localement sont bien présents, vous
pouvez interroger la vue V$TEMPFILE ou exécuter la commande RMAN REPORT SCHEMA.
- 16 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
En cas de besoin, vous pouvez explicitement recréer les fichiers de données des tablespaces gérés localement.
Exemple :
SQL> ALTER TABLESPACE temp
2 ADD TEMPFILE ’e:\oradata\HERMES\temp01.dbf’ SIZE 100M
3
AUTOEXTEND ON NEXT 100M MAXSIZE 1G;
7. Data Recovery Advisor
a. Vue d’ensemble
Le Data Recovery Advisor est un outil qui permet de simplifier et d’automatiser le diagnostic et la résolution des
problèmes (perte ou corruption) sur les fichiers de la base données. Cet outil est apparu en version 11.
Le conseiller peut être utilisé en ligne de commande dans RMAN ou avec une interface graphique dans le Database
Control (cf. Utiliser le Database Control).
Dans la terminologie du conseiller, un échec (failure en anglais) sur un fichier est identifié par un numéro unique et
est caractérisé par un statut (OPEN ou CLOSED) et une priorité (LOW, HIGH ou CRITICAL).
Le statut est OPEN tant que le problème n’a pas été résolu ; il passe à CLOSED ensuite.
La priorité est CRITICAL lorsque la base de données est totalement indisponible et HIGH si elle est partiellement
indisponible ; dans les deux cas, il convient de résoudre le problème rapidement. La priorité LOW n’est pas attribuée
par le conseiller. Par contre, si vous jugez qu’une priorité HIGH a peu d’impact sur le fonctionnement de la base de
données et ne nécessite pas de traitement immédiat, vous pouvez descendre manuellement la priorité à LOW.
Les informations relatives aux échecs sont stockées dans le référentiel de diagnostic automatique. Pour fonctionner,
le Data Recovery Advisor nécessite que l’instance soit démarrée (mais la base de donnée peut ne pas être montée
ce qui permet de diagnostiquer et résoudre les incidents sur les fichiers de contrôle).
b. Utilisation
Dans RMAN, les étapes pour diagnostiquer et résoudre les problèmes à l’aide du conseiller sont les suivantes :
●
Afficher les échecs actuels (statut OPEN) : LIST FAILURE.
●
Déterminer les actions à effectuer pour résoudre le(s) problème(s) : ADVISE FAILURE.
●
Résoudre le(s) problème(s) : REPAIR FAILURE.
●
Retourner à l’étape 1 pour confirmer que les problèmes ont été résolus ou voir s’il reste encore des
problèmes.
Au préalable, il est possible d’exécuter la commande VALIDATE DATABASE pour vérifier la totalité de la base de
données (mais il faut que la base de données soit montée).
En complément des commandes LIST FAILURE, ADVISE FAILURE et REPAIR FAILURE, il existe une commande CHANGE
FAILURE qui permet de modifier le statut ou la priorité. Cette commande, moins utile, n’est pas présentée dans cet
ouvrage (voir la documentation "Oracle® Database Backup and Recovery Reference").
La première étape consiste donc à afficher les échecs actuels avec la commande LIST FAILURE.
Syntaxe simplifiée
LIST FAILURE [quoi] [DETAIL] ;
La clause quoi peut prendre une ou plusieurs des valeurs suivantes : ALL, CRITICAL, HIGH, LOW, CLOSED ou un numéro
d’échec.
Par défaut, la commande LIST FAILURE affiche tous les échecs de statut OPEN et de priorité CRITICAL ou HIGH.
L’option CLOSED permet d’afficher les échecs de statut CLOSED. Les options CRITICAL, HIGH, LOW ou ALL permettent
d’afficher les échecs ayant une priorité donnée (ALL = toutes les priorités).
Pour simplifier, les échecs de même nature sont regroupés dans un seul échec "parent" et seuls ces derniers sont
affichés par défaut par la commande LIST FAILURE. Pour afficher tous les échecs "enfants", vous pouvez utiliser
© ENI Editions - All rights reserved - Algeria Educ
- 17 -
l’option DETAIL.
Exemple
RMAN> LIST FAILURE ;
utilisation du fichier de contrôle de la base de données
cible au lieu du catalogue de récupération
Liste des échecs de base de données
=========================
ID d’échec Priority Status Time Detected Summary
---------- -------- ------ ------------- ------565
HIGH
OPEN
07/08/08
Un ou plusieurs fichiers de
données non système sont absents
RMAN> LIST FAILURE 565 DETAIL;
utilisation du fichier de contrôle de la base de données cible
au lieu du catalogue de récupération
Liste des échecs de base de données
=========================
ID d’échec Priority Status
Time Detected Summary
---------- -------- ------ ------------- ------565
HIGH
OPEN
07/08/08
Un ou plusieurs fichiers
de données non système sont absents
Impact : Voir l’impact des échecs des enfants
Liste des échecs enfant de l’ID d’échec parent 565
ID d’échec Priority Status Time Detected Summary
---------- ------ ------ ------------- ------1859
HIGH
OPEN
07/08/08
Le fichier
de données 6: ’E:\ORADATA\HERMES\INDX01.DBF’ est absent
Impact : Il se peut que certains objets dans
le tablespace INDX soient indisponibles
1853
HIGH
OPEN
07/08/08
Le fichier
de données 5: ’E:\ORADATA\HERMES\DATA01.DBF’ est absent
Impact : Il se peut que certains objets dans
le tablespace DATA soient indisponibles
Sur cet exemple, un problème a été détecté sur deux fichiers de données.
Pour générer et afficher les actions à effectuer pour traiter les échecs, vous devez utiliser la commande ADVISE
FAILURE.
Syntaxe simplifiée
ADVISE FAILURE [quoi] ;
La clause quoi peut prendre une ou plusieurs des valeurs suivantes : ALL, CRITICAL, HIGH, LOW ou un numéro
d’échec.
La commande ADVISE FAILURE sans option peut être utilisée uniquement si une commande LIST FAILURE a été
exécutée au préalable dans la session RMAN. Dans ce cas, la commande ADVISE FAILURE affiche des informations de
résolution pour tous les échecs de statut OPEN et de priorité CRITICAL ou HIGH enregistrés dans le référentiel de
diagnostic automatique.
Les options de la clause quoi permettent d’afficher les informations de résolution pour un sous­ensemble
d’échecs ; la signification des différentes options de cette clause est la même que pour la commande LIST FAILURE.
Exemple
RMAN> ADVISE FAILURE ;
Liste des échecs de base de données
=========================
ID d’échec Priority Status Time Detected Summary
---------- -------- ------ ------------- ------565
HIGH
OPEN
07/08/08
Un ou plusieurs fichiers
de données non système sont absents
...
analyse des options de réparation automatique ; cette opération
peut prendre un certain temps
canal affecté : ORA_DISK_1
canal ORA_DISK_1 : SID=208 type d’unité=DISK
analyse des options de réparation automatique terminée
Actions manuelles obligatoires
- 18 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
========================
aucune action manuelle n’est disponible
Actions manuelles facultatives
=======================
1. Si le fichier E:\ORADATA\HERMES\DATA01.DBF a été renommé ou déplacé
involontairement, restaurez-le
2. Si le fichier E:\ORADATA\HERMES\INDX01.DBF a été renommé ou déplacé
involontairement, restaurez-le
Options de réparation automatique
========================
Option Repair Description
------ -----------------1
Restaurez et récupérez le fichier de données 5; Restaurez
et récupérez le fichier de données 6
Stratégie : La réparation comprend une récupération après défaillance
matérielle sans perte de données
Script de réparation : d:\app\oracle\diag\rdbms\hermes\hermes\hm\
reco_499244267.hm
Après avoir affiché des informations sur les échecs trouvés (résultat de la commande LIST FAILURE), la commande
ADVISE FAILURE affiche trois sections :
Actions manuelles obligatoires : cette section liste les opérations qui doivent obligatoirement être faites
manuellement pour résoudre le problème. Des actions manuelles obligatoires peuvent, par exemple, être
nécessaires si une sauvegarde ou un fichier de journalisation archivé requis par la réparation automatique sont
manquants.
Actions manuelles facultatives : cette section liste les opérations manuelles facultatives qui peuvent permettre de
résoudre le problème. Par exemple, si un fichier de données est manquant, le conseiller suggère que ce fichier a
peut­être été involontairement renommé ou déplacé et qu’il peut donc être restauré sans devoir repartir d’une
sauvegarde.
Options de réparation automatique : cette section liste les différentes options de réparation automatique. Pour
chaque option, la commande affiche un numéro, une description, une stratégie (avec ou sans perte de données) et
le chemin du script qui contient les commandes de réparation. Les options correspondant à une stratégie sans
perte de données sont toujours proposées en premier.
Pour réparer automatiquement les échecs identifiés par le Data Recovery Advisor, vous pouvez utiliser la commande
REPAIR FAILURE.
Syntaxe
REPAIR FAILURE [USING ADVISE OPTION numéro] [PREVIEW] [NOPROMPT];
Par défaut, la commande REPAIR FAILURE exécute les actions de la première option de réparation automatique,
identifiée par la commande ADVISE FAILURE la plus récente exécutée dans la session RMAN ; si aucune commande
ADVISE FAILURE n’a été exécutée dans la session RMAN, une erreur est retournée.
L’option USING ADVISE OPTION permet d’appliquer une option de réparation automatique spécifique, identifiée par
son numéro d’option.
L’option PREVIEW permet de ne pas exécuter les actions, mais simplement de les prévisualiser à l’écran.
L’option NOPROMPT permet de supprimer la demande de confirmation, lors de l’exécution effective de la commande.
Exemple
RMAN> REPAIR FAILURE PREVIEW ;
Stratégie : La réparation comprend une récupération après défaillance
matérielle sans perte de données
Script de réparation : d:\app\oracle\diag\rdbms\hermes\hermes\hm\
reco_499244267.hm
contenu du script de réparation :
# restore and recover datafile
restore datafile 5, 6;
recover datafile 5, 6;
RMAN> REPAIR FAILURE NOPROMPT ;
Stratégie : La réparation comprend une récupération après défaillance
matérielle sans perte de données
Script de réparation : d:\app\oracle\diag\rdbms\hermes\hermes\hm\
reco_499244267.hm
contenu du script de réparation :
© ENI Editions - All rights reserved - Algeria Educ
- 19 -
# restore and recover datafile
restore datafile 5, 6;
recover datafile 5, 6;
exécution du script de réparation
Démarrage de restore dans 07/08/08
...
Fin de restore dans 07/08/08
Démarrage de recover dans 07/08/08
...
Fin de recover dans 07/08/08
réparation de l’échec terminée
base de données ouverte
Lors de l’exécution effective des actions de réparation, RMAN affiche le résultat des différentes commandes
exécutées (RESTORE, RECOVER, etc.).
c. Considérations
Le Data Recovery Advisor est un outil très puissant qui permet de diagnostiquer et résoudre un grand nombre de
problèmes sur les fichiers de contrôle, les fichiers de journalisation ou les fichiers de données.
Le seul problème que le Data Recovery Advisor ne sait pas résoudre est la perte du fichier de paramètres serveur. Si
besoin, vous devrez restaurer manuellement le fichier de paramètre serveur (cf. Récupération)
Avant d’utiliser le conseiller, assurez­vous que l’instance a bien démarré avec un fichier de paramètres à jour. Si ce
n’est pas le cas, le conseiller risque de signaler un faux problème sur les fichiers de contrôle si la valeur du
paramètre CONTROL_FILES n’est pas correcte. Vous pouvez notamment rencontrer cette situation si RMAN a démarré
l’instance avec un fichier de paramètre "temporaire" (message démarrage de l’instance Oracle sans fichier de
paramètres pour extraction de SPFILE).
Dans le cas où tous les fichiers de contrôle sont perdus, le Data Recovery Advisor commencera par signaler ce
problème et ne sera pas forcément en mesure d’identifier tout de suite d’autres problèmes (sur les fichiers de
données par exemple). Vous devrez donc, d’abord traiter le problème sur les fichiers de contrôle (LIST FAILURE, puis
ADVISE FAILURE puis REPAIR FAILURE) avant de faire de nouveau appel au conseiller pour identifier les autres
problèmes éventuels (LIST FAILURE) et si besoin, les résoudre (ADVISE FAILURE puis REPAIR FAILURE).
Cette situation peut se produire dans le scénario catastrophe où vous avez perdu la totalité de la base de données
(tous les fichiers de contrôle, tous les fichiers de journalisation et tous les fichiers de données).
Là encore, utiliser une zone de récupération rapide, et faire des sauvegardes automatiques du fichier de contrôle
vers cette zone de récupération rapide, facilite la résolution des problèmes par le Data Recovery Advisor.
Si la situation l’exige (récupération incomplète ou récupération à partir d’une sauvegarde des fichiers de contrôle),
le Data Recovery Advisor ouvrira la base de données dans le mode RESETLOGS.
- 20 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Les techniques de flashback
1. Vue d’ensemble
Les techniques de flashback sont un ensemble de fonctionnalités proposées par Oracle qui permettent de voir l’état
passé des données, ou de ramener une table ou la totalité de la base de données dans le passé.
Les fonctionnalités proposées sont les suivantes :
●
●
●
●
●
●
●
●
Flashback Query: permet de lire les données telles qu’elles étaient à un instant dans le passé (apparu en
version 9).
Flashback Version Query : permet de voir toutes les versions d’une ligne sur un certain intervalle de temps
(apparu en version 10).
Flashback Transaction Query : permet de voir les modifications réalisées par une ou plusieurs transactions sur
un certain intervalle de temps (apparu en version 10).
Flashback Transaction: permet d’annuler les modifications d’une transaction, et de ses transactions
dépendantes (apparu en version 11).
Flashback Data Archive (Oracle Total Recall) : permet de conserver sur le long terme, toutes les modifications
apportées à une table (apparu en version 11).
Flashback Table : permet de ramener une table dans l’état où elle était, à un certain moment dans le passé
(apparu en version 10).
Flashback Drop: permet de ramener la table dans l’état où elle était, juste avant sa suppression (apparu en
version 10).
Flashback Database : permet de ramener la totalité de la base de données dans l’état où elle était à un
certain moment dans le passé (apparu en version 11).
Seule la fonctionnalité Flashback Query est disponible dans toutes les éditions de la base de données (et donc
notamment en Standard Edition).
La fonctionnalité Flashback Data Archive (Oracle Total Recall) est une option de l’Enterprise Edition et nécessite donc,
une licence supplémentaire. Cette fonctionnalité n’est pas présentée dans cet ouvrage.
Les autres fonctionnalités de flashback nécessitent l’Enterprise Edition, mais sans option supplémentaire.
Ces fonctionnalités utilisent des techniques différentes mais pour répondre au même objectif : récupérer une erreur
d’utilisation.
Les fonctionnalités de flashback de requête (Flashback Query, Flashback Version Query et Flashback Transaction Query),
et la fonctionnalité de flashback de table, utilisent les informations d’annulation pour revenir en arrière. Le paramètre
UNDO_RETENTION et le tablespace d’annulation doivent donc être correctement dimensionnés, si vous souhaitez
pouvoir retourner loin dans le passé.
La fonctionnalité de flashback de transaction (Flashback Transaction) utilise les fichiers de journalisation (en ligne et
archivés, donc la base de données doit fonctionner dans le mode ARCHIVELOG). Cette fonctionnalité, un peu avancée,
n’est pas présentée dans cet ouvrage.
La fonctionnalité de flashback de base de données (Flashback Database) utilise un fichier journal spécifique, différent
des fichiers de journalisation.
La fonctionnalité de flashback avant suppression d’une table (Flashback Drop) utilise le fait que le stockage d’une table
n’est pas physiquement supprimé lorsque la table est supprimée.
2. Niveau ligne
Flashback Query
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Pour lire les données telles qu’elles étaient à un instant donné du passé, vous pouvez utiliser l’option AS OF sur une
table présente dans la clause FROM d’une requête SELECT.
Syntaxe
nom_table AS OF { TIMESTAMP | SCN } expression
L’option TIMESTAMP permet de retourner à un instant donné du passé en indiquant une date et une heure ; dans ce
cas, l’expression doit être de type TIMESTAMP. L’option SCN permet de retourner à un instant donné du passé en
indiquant un numéro SCN ; dans ce cas, l’expression doit être un nombre.
Exemple
-- situation de départ
SQL> SELECT prenom FROM adherent WHERE numero = 1;
PRENOM
---------------------------------------Sébastien
SQL> SELECT TO_CHAR(SYSDATE,’DD/MM/YYYY HH24:MI:SS’) "SYSDATE",
2
dbms_flashback.get_system_change_number "SCN"
3 FROM dual;
SYSDATE
SCN
-------------------- ---------08/08/2008 11:28:00
176032
SQL> -- un peu plus tard
SQL> UPDATE adherent SET prenom = ’Olivier’ WHERE numero = 1;
1 ligne mise à jour.
SQL> COMMIT;
Validation effectuée.
SQL> -- un peu plus tard
SQL> SELECT TO_CHAR(SYSDATE,’DD/MM/YYYY HH24:MI:SS’) "SYSDATE",
2
dbms_flashback.get_system_change_number "SCN"
3 FROM dual;
SYSDATE
SCN
-------------------- ---------08/08/2008 11:28:20
176123
SQL> SELECT prenom
2 FROM adherent AS OF TIMESTAMP SYSTIMESTAMP - INTERVAL ’30’ SECOND
3 WHERE numero = 1;
PRENOM
---------------------------------------Sébastien
SQL> SELECT prenom
2 FROM adherent AS OF SCN 176032
3 WHERE numero = 1;
PRENOM
---------------------------------------Sébastien
SQL> SELECT prenom FROM adherent WHERE numero = 1;
PRENOM
---------------------------------------Olivier
La fonction GET_SYSTEM_CHANGE_NUMBER du package DBMS_FLASHBACK retourne le numéro SCN courant. Il faut le
privilège EXECUTE sur le package pour l’utiliser.
La donnée lue dans le passé peut être utilisée pour réaliser une mise à jour dans le présent :
SQL> UPDATE adherent
2 SET nom = (SELECT prenom FROM adherent AS OF SCN 176032
3
WHERE numero = 1)
4 WHERE numero = 1;
Flashback Version Query
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Pour lire les différentes versions d’une ligne sur un certain intervalle de temps, vous pouvez utiliser l’option VERSIONS
BETWWEN sur une table présente dans la clause FROM d’une requête SELECT.
Syntaxe
nom_table VERSIONS BETWEEN { TIMESTAMP | SCN }
{ expression1 | MINVALUE } AND { expression2 | MAXVALUE }
La signification des options TIMESTAMP et SCN est la même que dans la clause AS OF. MINVALUE et MAXVALUE permettent
d’obtenir la plus ancienne ligne et la plus récente.En complément, vous pouvez utiliser plusieurs pseudo­colonnes qui
vous donneront des informations sur les différentes versions de la ligne :
VERSIONS_STARTTIME
Date/heure de début de validité de la version de la ligne.
VERSIONS_STARTSCN
Numéro SCN de début de validité de la version de la ligne.
VERSIONS_ENDTIME
Date/heure de fin de validité de la version de la ligne.
VERSIONS_ENDSCN
Numéro SCN de fin de validité de la version de la ligne.
VERSIONS_XID
Identifiant de la transaction à l’origine de la version de la ligne.
VERSIONS_OPERATION
Opération à l’origine de la version de la ligne : I pour INSERT, U pour UPDATE et D pour DELETE.
Exemple
SQL> BEGIN
2
INSERT INTO adherent(numero,prenom) VALUES(24,’Olivier’);
3
COMMIT;
4
UPDATE adherent SET prenom = ’David’ WHERE numero = 24;
5
COMMIT;
6
DELETE FROM adherent WHERE numero = 24;
7
COMMIT;
8 END;
9 /
Procédure PL/SQL terminée avec succès.
SQL> SELECT versions_startscn, versions_endscn,
2
versions_xid, versions_operation,
3
prenom
4 FROM adherent VERSIONS BETWEEN SCN MINVALUE AND MAXVALUE
5 WHERE numero = 24
6 ORDER BY versions_startscn;
VERSIONS_STARTSCN VERSIONS_ENDSCN VERSIONS_XID
V PRENOM
----------------- --------------- ---------------- - ---------177002
177003 030012000D010000 I Olivier
177003
177004 020019000E010000 U David
177004
01000D0008010000 D David
Une nouvelle version d’une ligne est créée lors d’un COMMIT.
Flashback Transaction Query
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Pour voir les modifications réalisées par une ou plusieurs transactions sur un certain intervalle de temps, vous pouvez
interroger la vue FLASHBACK_TRANSACTION_QUERY. Cette vue donne des informations sur toutes les transactions de la
base de données pouvant faire l’objet d’un flashback. Les principales colonnes de cette vue sont les suivantes :
XID
Identifiant de la transaction.
START_SCN
Numéro SCN de début de la transaction.
START_TIMESTAMP
Date/heure de début de la transaction.
COMMIT_SCN
Numéro SCN du COMMIT de la transaction (vide pour la transaction en cours).
COMMIT_TIMESTAMP
Date/heure du COMMIT de la transaction (vide pour la transaction en cours).
LOGON_USER
Compte utilisateur de la session.
OPERATION
Opération réalisée dans la transaction : INSERT, UPDATE, DELETE.
TABLE_NAME
Nom de la table concernée par l’opération.
TABLE_OWNER
Propriétaire de la table concernée par l’opération.
ROW_ID
ROWID de la ligne concernée par l’opération.
UNDO_SQL
Ordre SQL permettant d’annuler l’opération.
Vous pouvez interroger cette vue de différentes manières :
●
par le nom d’une table sur laquelle vous avez noté un problème ;
●
par le ROWID d’une ligne sur laquelle vous avez noté un problème ;
●
par un identifiant de transaction relevé en analysant les différents versions d’une ligne (pseudo­colonne
VERSIONS_XID).
Exemple
SQL> SELECT xid, start_scn,commit_scn, logon_user, undo_sql
2 FROM flashback_transaction_query
3 WHERE table_name=’ADHERENT’ AND table_owner=’DIANE’
- 4-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
4
AND operation =’DELETE’ AND start_timestamp > SYSDATE-1;
XID
START_SCN COMMIT_SCN LOGON_USER
---------------- ---------- ---------- --------------UNDO_SQL
----------------------------------------------------------------...
030006000D010000 176702 176712 DIANE
insert into "DIANE"."ADHERENT"("NUMERO","NOM","PRENOM","SEXE","DATE_
NAISSANCE","TELEPHONE","REF_CATEGORIE") values (’22’,NULL,
’Olivier’,NULL,NULL,NULL,NULL);
030006000D010000 176702 176712 DIANE
insert into "DIANE"."ADHERENT"("NUMERO","NOM","PRENOM","SEXE","DATE_
NAISSANCE","TELEPHONE","REF_CATEGORIE") values (’21’,’HEURTEL’
,NULL,NULL,NULL,NULL,NULL);
...
Sur cet exemple, nous recherchons toutes les transactions qui ont fait un DELETE sur la table ADHERENT du schéma
DIANE, la dernière journée. Les deux lignes affichées appartiennent à la même transaction (même XID). La colonne
UNDO_SQL donne l’ordre SQL qui peut être utilisé pour récréer la ligne.
3. Niveau table
Flashback Table
Pour ramener une table à l’état où elle était à un moment donné du passé, vous pouvez utiliser l’ordre SQL FLASHBACK
TABLE.
Syntaxe
FLASHBACK nom_table [,…] TO instant
[ENABLE TRIGGERS] ;
instant
{ TIMESTAMP | SCN } expression
| RESTORE POINT nom
La signification des options TIMESTAMP et SCN est la même que dans la clause AS OF. L’option RESTORE POINT permet de
revenir à un point de retour créé au préalable avec l’ordre SQL CREATE RESTORE POINT ; les points de retour sont
visibles dans la vue V$RESTORE_POINT. L’option ENABLE TRIGGERS permet d’autoriser le déclenchement des triggers qui
existent et qui sont actuellement actifs ; par défaut, ils ne sont pas déclenchés.
Pour réaliser cette opération, il faut :
●
●
●
avoir le privilège objet FLASHBACK sur la table ou le privilège système FLASHBACK ANY TABLE ;
détenir les privilèges objet SELECT, INSERT, et ALTER sur la table (ou les privilèges système ANY
correspondants) ;
que le déplacement de lignes soit autorisé sur la table (ROW MOVEMENT).
Exemple
-- je supprime toutes les lignes d’une table
SQL> DELETE FROM diane.adherent;
20 lignes supprimées.
SQL> COMMIT;
Validation effectuée.
SQL> SELECT COUNT(*) FROM diane.adherent;
COUNT(*)
---------0
-- 5 minutes plus tard, je m’aperçoit de mon erreur ...
SQL> FLASHBACK TABLE diane.adherent
© ENI Editions - All rights reserved - Algeria Educ
- 5-
2 TO TIMESTAMP SYSTIMESTAMP - INTERVAL ’5’ MINUTE;
FLASHBACK TABLE diane.adherent TO TIMESTAMP SYSTIMESTAMP - INTERVAL
’5’ MINUTE
*
ERROR at line 1:
ORA-08189: opération Flashback impossible sur la table : le mouvement
de ligne n’est pas activé
-- il faut autoriser le déplacement de lignes
SQL> ALTER TABLE diane.adherent ENABLE ROW MOVEMENT;
Table modifiée.
SQL> FLASHBACK TABLE diane.adherent
2 TO TIMESTAMP SYSTIMESTAMP - INTERVAL ’5’ MINUTE;
Flashback terrminé.
SQL> SELECT COUNT(*) FROM diane.adherent;
COUNT(*)
---------20
-- c’est cool ...
Flashback Drop
Depuis la version 10, lorsqu’une table est supprimée, elle ne l’est pas complètement, sauf si vous utilisez l’option
PURGE de l’ordre SQL DROP TABLE ; elle est placée dans une "corbeille". Dans les grandes lignes, une table supprimée
est en fait renommée par Oracle, et l’espace associé n’est pas récupéré immédiatement (bien qu’il apparaisse dans la
vue DBA_FREE_SPACE) ; Oracle fait la même chose avec les dépendances de l’objet, notamment les index. L’espace de
stockage des objets se trouvant dans la corbeille n’est pas réutilisé, sauf en cas de manque d’espace dans le
tablespace.
Si Oracle a besoin d’allouer une nouvelle extension dans un tablespace, et qu’il n’y ait plus suffisamment de place,
Oracle récupèrera l’espace correspondant aux objets de la corbeille, en commençant par les objets les plus anciens
(FIFO : First In First Out). Oracle réalise cette récupération avant de faire grandir le fichier de données du tablespace
si celui­ci a la propriété AUTOEXTEND.
La "corbeille" se matérialise tout simplement par une table du dictionnaire de données qui peut être interrogée à
l’aide des vues USER_RECYCLEBIN et DBA_RECYCLEBIN, ou à l’aide de la commande SQL*Plus SHOW RECYCLEBIN (interroge
la vue USER_ RECYCLEBIN).
Les colonnes les plus intéressantes de la vue DBA_RECYCLEBIN sont les suivantes :
OWNER
Nom du propriétaire de l’objet.
OBJECT_NAME
Nom de l’objet dans la corbeille.
ORIGINAL_NAME
Nom d’origine de l’objet.
TYPE
Type de l’objet (TABLE, INDEX, TRIGGER, etc.).
TS_NAME
Nom du tablespace dans lequel l’objet est stocké.
CREATETIME
Date de création de l’objet.
DROPTIME
- 6-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Date de suppression de l’objet.
CAN_UNDROP
Indique si l’objet peut être sorti de la corbeille (YES ou NO).
CAN_PURGE
Indique si l’objet peut être définitivement supprimé (YES ou NO).
SPACE
Nombre de blocs utilisés par l’objet.
En complément, les vues DBA_INDEXES et DBA_TABLES contiennent une colonne DROPPED indiquant si la table ou l’index
est supprimé (YES ou NO).
Pour "annuler" la suppression d’une table, vous pouvez utiliser une variante de l’ordre SQL FLASHBACK TABLE.
Syntaxe
FLASHBACK TABLE nom_table TO BEFORE DROP [RENAME TO nouveau_nom] ;
Dans la commande FLASHBACK TABLE, vous pouvez utiliser le nom d’origine de l’objet ou le nom de l’objet dans la
corbeille.
Si plusieurs tables dans la corbeille ont le même nom d’origine (table supprimée, puis recréée puis de nouveau
supprimée), et que vous utilisiez le nom d’origine, Oracle ressortira de la corbeille la dernière table supprimée portant
ce nom (LIFO : Last In First Out). Pour ressortir spécifiquement une version plus ancienne, vous pouvez utiliser le nom
unique généré par Oracle pour placer la table dans la corbeille.
Lorsque vous sortez une table de la corbeille, vous pouvez lui attribuer un nouveau nom, ce qui est pratique si une
table portant le même nom existe dans le schéma. Les objets associés sont également ressortis de la corbeille, mais
ils gardent le nom qu’ils avaient dans la corbeille.
L’espace utilisé par les objets stockés dans la corbeille peut être explicitement et définitivement récupéré grâce à
l’ordre SQL PURGE.
Syntaxe
●
Purger une table ou un index (avec le nom d’origine ou le nom dans la corbeille, et un principe FIFO si vous
utilisez le nom d’origine et que plusieurs objets portent ce nom)
PURGE { INDEX | TABLE } nom ;
●
Purger les tables et les index d’un tablespace, en vous limitant éventuellement aux objets d’un schéma
PURGE TABLESPACE nom_tablespace [USER nom_utilisateur] ;
●
Purger toutes les tables et les index de l’utilisateur courant
PURGE RECYCLEBIN ;
●
Purger toutes les tables et les index
PURGE DBA_RECYCLEBIN ;
Vous pouvez noter les restrictions suivantes :
●
Les tables supprimées par un DROP TABLESPACE ou un DROP USER ne sont pas placées dans la corbeille.
●
Il n’y a pas de corbeille pour le tablespace SYSTEM.
●
Il n’y a pas de corbeille pour les tablespaces gérés par le dictionnaire (uniquement pour les tablespaces
gérés localement).
© ENI Editions - All rights reserved - Algeria Educ
- 7-
Exemple
-- je supprime la table
SQL> DROP TABLE diane.adherent;
Table supprimée.
-- elle est dans la corbeille (avec ces dépendances)
SQL> SELECT original_name,object_name,type,
2
ts_name,can_undrop,can_purge
3 FROM dba_recyclebin WHERE owner=’DIANE’;
CAN_
CAN_
ORIGINAL_NAME OBJECT_NAME
TYPE
TS_NAME UNDROP PURGE
-------------- ------------------------------ ------- ------- ----- ----ADHERENT$PK
BIN$y3LFL/MFTs28v7JjGLBSjQ==$0 INDEX
INDX
NO
YES
ADHERENT$UK01 BIN$iDjv77eKRHGEDyAfQ+Hdnw==$0 INDEX
INDX
NO
YES
NUMEROADHERENT BIN$sPGkld1PR3+w2PbWRdhz8A==$0 TRIGGER
NO
NO
ADHERENT
BIN$2tvUDS05RV+Rj2ogvU1aUg==$0 TABLE
DATA
YES YES
-- il y a bien une table supprimée
SQL> SELECT owner,table_name,dropped FROM dba_tables
2 WHERE table_name=’BIN$2tvUDS05RV+Rj2ogvU1aUg==$0’;
OWNER
TABLE_NAME
DRO
------------------------------ ------------------------------ --DIANE
BIN$2tvUDS05RV+Rj2ogvU1aUg==$0 YES
-- et un segment associé
SQL> SELECT segment_name,blocks FROM dba_segments
2 WHERE segment_name=’BIN$2tvUDS05RV+Rj2ogvU1aUg==$0’;
SEGMENT_NAME
BLOCKS
------------------------------ ---------BIN$2tvUDS05RV+Rj2ogvU1aUg==$0
8
-- la table dans la corbeille peut être interrogée
SQL> SELECT COUNT(*) FROM diane."BIN$2tvUDS05RV+Rj2ogvU1aUg==$0";
COUNT(*)
---------20
-- je ressors la table de la corbeille
SQL> FLASHBACK TABLE diane.adherent TO BEFORE DROP;
Flashback terminé.
-- c’est tout bon
SQL SELECT COUNT(*) FROM diane.adherent;
COUNT(*)
---------20
-- il faut juste renommer les index (et les triggers)
SQL> SELECT index_name FROM dba_indexes
2 WHERE owner=’DIANE’ AND table_name=’ADHERENT’;
INDEX_NAME
-----------------------------BIN$y3LFL/MFTs28v7JjGLBSjQ==$0
BIN$iDjv77eKRHGEDyAfQ+Hdnw==$0
Une table qui est dans la corbeille peut être interrogée.
4. Niveau base de données
a. Principes
La fonctionnalité de Flashback Database permet de ramener la base de données à l’état où elle était à un moment
- 8-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
donné du passé. Cela équivaut à une récupération incomplète à un instant donné, mais sans repartir d’une
sauvegarde, ce qui est beaucoup plus rapide. Pour pouvoir utiliser cette fonctionnalité, il faut faire fonctionner la
base de données dans un mode particulier, le mode FLASHBACK.
Lorsque la base de données fonctionne dans le mode FLASHBACK, elle génère des fichiers journaux supplémentaires
(flashback log), dans lesquels elle enregistre une copie des blocs modifiés. Ces fichiers journaux sont
obligatoirement stockés dans la zone de récupération rapide (sous­répertoire nommé flashback).
La durée de conservation des informations dans le fichier journal flashback est définie par le paramètre
d’initialisation DB_FLASHBACK_RETENTION_TARGET (en minutes, 1 440 par défaut, soit un jour). Comme le nom du
paramètre l’indique, la durée de conservation indiquée est un objectif. S’il n’y a pas suffisamment de place dans la
zone de récupération, Oracle réduira la durée de conservation. Vous devez donc, là encore, dimensionner avec soin
la zone de récupération rapide.
Lors d’une opération de flashback vers un instant T dans le passé, les blocs seront restaurés à partir du fichier
journal flashback, à l’état où ils étaient à cet instant ou quelques instants avant ; ensuite, les fichiers de
journalisation seront appliqués. Ceux­ci doivent donc être disponibles et la base de données fonctionner également
dans le mode ARCHIVELOG.
La fonctionnalité de Flashback Database est disponible uniquement en Enterprise Edition.
b. Activer le mode FLASHBACK
Pour >mettre la base de données dans le mode FLASHBACK, vous devez monter la base de données et exécuter
l’ordre SQL ALTER DATABASE FLASHBACK ON :
SQL> SHUTDOWN IMMEDIATE
...
SQL> STARTUP MOUNT
SQL> ALTER DATABASE FLASHBACK ON;
Base de données modifiée.
SQL> ALTER DATABASE OPEN;
Base de données modifiée.
SQL> SELECT flashback_on FROM v$database;
FLA
--YES
Par ailleurs, le paramètre DB_FLASHBACK_RETENTION_TARGET peut être modifié dynamiquement par un ordre SQL ALTER
SYSTEM.
La vue V$FLASHBACK_DATABASE_LOG donne des informations sur les journaux flashback :
OLDEST_FLASHBACK_SCN
Numéro SCN le plus ancien dans les journaux flashback.
OLDEST_FLASHBACK_TIME
Date/heure du numéro SCN le plus ancien.
RETENTION_TARGET
Durée de conservation objectif, telle que définie par le paramètre DB_FLASHBACK_RETENTION_TARGET.
FLASHBACK_SIZE
Taille actuelle des données flashback.
ESTIMATED_FLASHBACK_SIZE
Taille estimée des données flashback nécessaire pour la durée de conservation objectif actuellement définie.
La taille ESTIMATED_FLASHBACK_SIZE est estimée sur la base de l’activité de la base de données depuis que le mode
© ENI Editions - All rights reserved - Algeria Educ
- 9-
FLASHBACK a été activé (il faut attendre un peu, avant que cette colonne soit renseignée).
Si la fenêtre de flashback actuelle, donnée par la valeur de la colonne OLDEST_ FLASHBACK_TIME, est plus courte que
la durée objectif, c’est que la zone de récupération rapide est trop petite et qu’Oracle ne peut pas conserver un
historique suffisant (ou que le passage dans le mode FLASHBACK est récent). Vous devez, dans ce cas, augmenter le
quota d’espace alloué à la zone de récupération rapide (paramètre DB_RECOVERY_ FILE_DEST_SIZE).
Il est possible d’exclure un tablespace du mode FLASHBACK, grâce à la clause FLASHBACK ON | OFF qui peut être
utilisée lors de la création ou de la modification du tablespace (ON par défaut).
c. Procéder à un flashback de la base de données
Vous pouvez utiliser l’ordre SQL FLASHBACK DATABASE ou la commande RMAN FLASHBACK DATABASE pour procéder à une
opération flashback sur la base de données.
Syntaxe
●
Ordre SQL
FLASHBACK DATABASE TO [BEFORE] { TIMESTAMP | SCN } expression ;
FLASHBACK DATABASE TO BEFORE RESETLOGS ;
FLASHBACK DATABASE TO RESTORE POINT nom ;
●
Commande RMAN
FLASHBACK DATABASE TO [BEFORE] { TIME | SCN | SEQUENCE } [=] expression ;
FLASHBACK DATABASE TO BEFORE RESETLOGS ;
FLASHBACK DATABASE TO RESTORE POINT nom ;
Dans le cas de la commande RMAN, il est possible de préciser un numéro de séquence de fichier de journalisation
comme point de retour ; la base de données est alors, ramenée jusqu’au dernier numéro SCN enregistré dans le
fichier de journalisation (ou le précédent si l’option BEFORE est présente).
Dans les deux cas, la base de données doit être montée (pas ouverte).
Ensuite, la base de données doit être ouverte dans le mode RESETLOGS : c’est une nouvelle incarnation de la base
de données.
Exemple dans SQL*Plus
SQL> SHUTDOWN IMMEDIATE
...
SQL> STARTUP MOUNT
...
SQL> FLASHBACK DATABASE TO TIMESTAMP SYSDATE-1/24;
Flashback terminé.
SQL> ALTER DATABASE OPEN RESETLOGS;
Base de données modifiée.
Si vous souhaitez vérifier que vous être bien revenu au moment souhaité, vous pouvez ouvrir la base de données
en mode lecture seule :
ALTER DATABASE OPEN READ ONLY;
Si le résultat est satisfaisant, vous pouvez arrêter l’instance, la redémarrer en montant la base de données, puis
ouvrir la base de données avec l’option RESETLOGS. Si le résultat n’est pas satisfaisant, vous pouvez réaliser un
nouveau FLASHBACK DATABASE pour remonter un peu plus loin en arrière ou un RECOVER DATABASE UNTIL pour aller
légèrement en avant.
Si un tablespace a été exclu du mode FLASHBACK, vous devez le passer OFFLINE avant de procéder au
flashback. Ensuite, vous devez supprimer le tablespace ou le récupérer par un moyen traditionnel.
- 10 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Utiliser le Database Control
1. Configurer les paramètres de récupération
Sur la page d’accueil, cliquez sur le lien Disponibilité puis sur le lien Paramètres de récupération pour accéder à la
page de configuration des paramètres de récupération.
Cette page comporte plusieurs sections qui permettent :
●
De régler la durée de récupération maximale de l’instance (paramètre FAST_START_ MTTR_TARGET) :
●
De configurer l’archivage des fichiers de journalisation :
© ENI Editions - All rights reserved - Algeria Educ
- 1-
●
De configurer la zone de récupération rapide et la journalisation pour la fonction de flashback de la base de
données :
2. Configurer les paramètres de sauvegarde
Sur la page d’accueil, cliquez sur le lien Disponibilité puis sur le lien Paramètres de sauvegarde pour accéder à la
page de configuration des paramètres de sauvegarde :
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
L’onglet Périphérique permet de configurer les périphériques (canaux) par défaut. Le cadre Paramètre de disque
permet notamment de configurer l’emplacement par défaut des sauvegardes (la zone de récupération rapide si rien
d’autre n’est indiqué) et le type de sauvegarde par défaut : jeu de sauvegarde, jeu de sauvegarde compressé ou
copie image.
L’onglet Ensemble de sauvegarde permet de configurer les paramètres par défaut des jeux de sauvegarde, dont la
taille maximale d’un élément de sauvegarde.
L’onglet Règle permet :
●
De configurer la sauvegarde automatique du fichier de contrôle et du fichier de paramètres serveur, et
d’activer le suivi des blocs modifiés pour les sauvegardes incrémentales :
© ENI Editions - All rights reserved - Algeria Educ
- 3-
●
De configurer la politique de conservation des sauvegardes et de suppression des fichiers de journalisation
archivés :
3. Sauvegardes
a. Introduction
- 4-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Sur la page d’accueil, cliquez sur le lien Disponibilité puis sur le lien Programmer la sauvegarde pour accéder à la
page de gestion des sauvegardes :
Cette page propose deux possibilités :
●
Programmer une sauvegarde proposée par Oracle ;
●
Programmer une sauvegarde personnalisée.
b. Stratégie de sauvegarde proposée par Oracle
Lorsque vous choisissez l’option Sauvegarde proposée par Oracle, la première page permet de sélectionner la
destination des sauvegardes.
© ENI Editions - All rights reserved - Algeria Educ
- 5-
Sur la page suivante, Oracle vous indique la stratégie proposée ; celle­ci peut varier en fonction de la configuration
de la base de données. La stratégie usuelle proposée par Oracle en Enterprise Edition est basée sur des
sauvegardes incrémentales :
●
sauvegarde par copie image de la base de données la première fois ;
●
sauvegarde incrémentale de niveau 1 ensuite ;
●
application régulière des sauvegardes incrémentales à la copie image pour la faire progresser dans le
temps.
La page suivante permet de programmer la sauvegarde.
- 6-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
La dernière page donne un récapitulatif de la sauvegarde et montre le script RMAN correspondant. Vous pouvez
cliquer sur le bouton Soumettre le travail si la stratégie proposée par Oracle vous convient.
c. Stratégie de sauvegarde personnalisée
Lorsque vous choisissez l’option Sauvegarde personnalisée, la première page permet de sélectionner le type
d’objet à sauvegarder (totalité de la base, tablespaces, etc.) et de saisir les informations d’identification et de
connexion à l’hôte.
En fonction du type d’objet sélectionné, la page suivante permet de préciser la sélection. Si vous sélectionnez
l’intégralité de la base de données, vous arrivez directement sur la page de choix des options.
© ENI Editions - All rights reserved - Algeria Educ
- 7-
La page Options permet de préciser plusieurs options sur la sauvegarde :
- 8-
●
sauvegarde complète ou sauvegarde incrémentale ;
●
sauvegarde en ligne (base ouverte) ou hors ligne (base fermée) ;
●
sauvegarde ou non des fichiers de journalisation archivés, etc.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
La page suivante permet de désigner l’emplacement de la sauvegarde et de modifier les paramètres de la
sauvegarde (bouton Remplacer les paramètres en cours), ceci uniquement pour la sauvegarde en cours.
La page suivante permet de programmer la sauvegarde (immédiatement ou ultérieurement, répétition, etc.).
La dernière page donne un récapitulatif de la sauvegarde. Vous pouvez cliquer sur le bouton Modifier le script
RMAN pour voir le script RMAN correspondant, et au besoin le modifier. Vous pouvez cliquer sur le bouton
Soumettre le travail pour soumettre ce nouveau travail à l’ordonnanceur (scheduler).
d. Supervision des sauvegardes
Dernière sauvegarde
Sur la page d’accueil, dans le cadre Haute disponibilité, vous pouvez voir directement la date et l’heure de la
dernière sauvegarde :
© ENI Editions - All rights reserved - Algeria Educ
- 9-
Travaux
Sur la page d’accueil, cliquez sur le lien Travaux dans le cadre Liens associés pour afficher la liste des travaux :
Sauvegardes
Sur la page d’accueil, cliquez sur le lien Disponibilité puis sur le lien Gérer les sauvegardes en cours pour accéder
à la page de gestion des sauvegardes :
Cette page permet de rechercher des sauvegardes et de réaliser différentes actions :
●
●
vérifier la cohérence entre le référentiel RMAN et les fichiers physiques (bouton Tout contre­vérifier) ;
●
supprimer les sauvegardes obsolètes (bouton Supprimer tous les éléments obsolètes) ;
●
- 10 -
cataloguer des fichiers non connus du référentiel RMAN (bouton Ecrire des fichiers supplémentaires dans
le catalogue) ;
openmirrors.com
supprimer tous les objets ayant le statut EXPIRED (bouton Supprimer tous les éléments arrivés à
expiration).
© ENI Editions - All rights reserved - Algeria Educ
4. Récupération
a. Démarrer une récupération
Si la base de données n’est pas ouverte, vous accédez à l’assistant récupération, grâce au bouton Effectuer la
récupération qui est proposé sur la page donnant le statut de la base de données :
Après saisie des informations d’’identification et de connexion à l’hôte puis à la base de données (connexion
SYSDBA), vous accédez à la page de récupération (voir ci­dessous).
Si la base de données est ouverte, vous accédez à l’assistant récupération en cliquant sur le lien Disponibilité puis
sur le lien Effectuer la récupération.
Si un échec sur un fichier a été détecté, Oracle déclenche une alerte critique dans la catégorie "Echec de données".
Ces alertes peuvent être visualisées dans le cadre Alertes de la page d’accueil :
b. L’assistant de récupération
© ENI Editions - All rights reserved - Algeria Educ
- 11 -
Les informations affichées en haut de la page dépendent de la nature du problème. Sur l’exemple ci­dessus, un
échec a été détecté mais la base de données est ouverte. Si la base de données est fermée, l’affichage le
mentionne. Exemple :
Si vous ouvrez cette page alors qu’il n’y a aucun problème, aucune information n’est affichée en haut.
Normalement, en cas de problème, des informations de diagnostic provenant du Data Recovery Advisor sont
affichées et le bouton Conseiller et récupérer est actif ; vous pouvez cliquer ce bouton pour effectuer la
récupération à l’aide du Data Recovery Advisor (cf. Exemple de récupération avec le Data Recovery Advisor). C’est la
méthode la plus simple pour effectuer la récupération.
Si le problème n’est pas considéré comme un échec par le Data Recovery Advisor, des informations de diagnostic sont
quand même affichées en haut de la page, mais le bouton Conseiller et récupérer est inactif :
Dans ce cas, en cliquant dans l’ordre sur les liens affichés, le Database Control vous guide pour effectuer la
récupération (cf. Exemple de récupération ordonnée par l’utilisateur).
Si vous souhaitez effectuer une récupération alors qu’aucun problème n’a été détecté par Oracle (par exemple pour
revenir avant un ordre SQL malencontreux), ou si vous souhaitez résoudre un problème avec votre propre
stratégie, vous pouvez démarrer une récupération dite "ordonnée par l’utilisateur" :
- 12 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Pour cela, vous devez sélectionner l’étendue de la récupération et un type d’opération, puis cliquer sur le bouton
Récupérer (cf. Exemple de récupération ordonnée par l’utilisateur).
Avant de démarrer la récupération avec une des méthodes présentées ci­dessus, vérifiez que des
informations d’identification et de connexion à l’hôte sont correctement saisies dans le bas de la page.
c. Exemple de récupération avec le Data Recovery Advisor
Vous pouvez accéder à la page du Data Recovery Advisor de différentes manières :
●
en cliquant sur le bouton Conseiller et récupérer de la page de récupération ;
●
en cliquant sur le lien Data Recovery Advisor du centre de conseil ;
●
en cliquant sur le bouton Lancer Recovery Advisor des pages de résultat de l’exécution des outils de
vérification (cf. Chapitre Les outils d’administration section Diagnostiquer les problèmes).
Cette page affiche les échecs détectés par le Data Recovery Advisor. Par défaut, seuls les échecs de statut OPEN et
de priorité CRITICAL ou HIGH sont affichés ; vous pouvez utiliser le petit formulaire de recherche pour filtrer les
échecs affichés.
Un clic sur le bouton Conseil permet d’afficher les conseils de résolution pour les échecs sélectionnés dans la liste.
© ENI Editions - All rights reserved - Algeria Educ
- 13 -
Le conseiller commence par afficher les actions manuelles qui peuvent être réalisées pour effectuer la récupération :
Pour afficher les actions de récupération automatique identifiées par le Data Recovery Advisor, vous pouvez cliquer
sur le bouton Poursuivre avec les conseils.
Pour exécuter les actions de récupération automatique identifiées par le Data Recovery Advisor, vous pouvez cliquer
sur le bouton Continuer.
Cliquez sur le bouton Soumettre le travail de récupération pour lancer la récupération.
Si la base de données est ouverte, le Data Recovery Advisor lance le travail de récupération et vous rend la main :
- 14 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Vous pouvez retrouver ce travail en cliquant sur le lien Travaux (cadre Liens associés situé dans le bas de la page
d’accueil de chaque onglet).
Si la base de données est fermée, le Data Recovery Advisor attend que le travail se termine puis affiche le résultat :
À ce stade, deux cas se présentent en général :
La base de données était montée (pas de problème avec les fichiers de contrôle)
Si la récupération a réussi, un bouton Ouvrir la base de données est présent et il ne reste plus qu’à cliquer sur ce
bouton pour ouvrir la base de données.
La base de données n’était pas montée (problème avec les fichiers de contrôle)
Si la récupération a réussi, la base de données est montée mais le Data Recovery Advisor ne sait pas encore si elle
peut être ouverte ; le bouton Ouvrir la base de données n’est pas présent.
Si vous cliquez sur le bouton OK, vous revenez sur la page de statut de la base de données et vous pouvez de
nouveau cliquer sur le bouton Effectuer la récupération pour revenir sur la page de récupération.
S’il n’y a plus d’échec de fichier, la page se présente ainsi :
Pour ouvrir la base de données, cliquez sur le lien Instance de base de données pour revenir à la page de statut,
puis sur le bouton Démarrer (cf. section Démarrage du chapitre Démarrage et arrêt).
© ENI Editions - All rights reserved - Algeria Educ
- 15 -
S’il y a des échecs de fichier, la page se présente ainsi et une nouvelle opération de récupération est nécessaire :
Parfois les informations du Data Recovery Advisor ne s’affichent pas correctement ; cliquer sur le lien Statut
en cours résout, généralement, ce problème. Vous pouvez aussi cliquer sur le lien Echecs de base de
données pour afficher la page du Data Recovery Advisor.
d. Exemple de récupération ordonnée par l’utilisateur
Pour illustrer le fonctionnement de l’assistant, nous allons prendre le cas d’une récupération d’un fichier de
données :
■
Cliquez sur le bouton Récupérer.
La page suivante permet de sélectionner les fichiers de données à récupérer (bouton Ajouter) ; les fichiers
endommagés détectés par Oracle sont proposés par défaut dans la liste.
- 16 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
La page suivante permet d’indiquer s’il faut restaurer les fichiers de données à leur emplacement d’origine ou
ailleurs.
La dernière page donne un récapitulatif de la récupération. Vous pouvez cliquer sur le bouton Modifier le script
RMAN pour voir le script RMAN correspondant, et au besoin le modifier. Vous pouvez cliquer sur le bouton
Soumettre pour lancer l’opération. L’opération n’est pas lancée sous la forme d’un travail détaché ; vous restez sur
la page tout le temps de l’opération, sans aucune information sur son degré d’avancement.
Lorsque l’opération est terminée, le rapport RMAN est affiché.
e. Flashback
Base de données
L’assistant vous permet de faire une récupération de toute la base de données jusqu’à l’heure en cours ou jusqu’à
un point antérieur dans le temps (base montée uniquement) :
© ENI Editions - All rights reserved - Algeria Educ
- 17 -
Dans ce cas, si la journalisation flashback est active sur votre base de données, Oracle vous indique qu’il peut
utiliser la fonctionnalité de flashback de la base de données, si l’heure de retour demandée est compatible avec les
journaux. Cliquez sur le bouton Récupérer et laissez­vous guider.
Table
Parmi les types d’objets d’une récupération, vous pouvez choisir « Tables » :
Dans ce cas, Oracle vous propose de faire un flashback soit pour ramener la table dans un état antérieur, soit pour
annuler la suppression d’une table. Là encore, cliquez sur le bouton Récupérer et laissez­vous guider.
Ligne
Les fonctionnalités de flashback de niveau ligne, mais aussi de niveau table, sont accessibles à partir de la page de
gestion des tables, via les menus Interrogation de versions Flashback et Table Flashback :
- 18 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Vue d’ensemble
Les outils Data Pump, Export, Import et SQL*Loader sont des outils très puissants comportant de nombreuses
fonctionnalités ; un ouvrage entier pourrait leur être consacré.
L’objectif de ce chapitre est donc de présenter les principes de fonctionnement généraux de ces différents outils, de
donner quelques conseils sur leur utilisation, illustrés par quelques exemples classiques d’utilisation.Pour approfondir
le sujet, vous pouvez consulter la documentation Oracle® Database Utilities.
Oracle propose trois utilitaires permettant d’administrer les données dans une base :
●
●
●
Data Pump Export : permet d’exporter dans un fichier binaire propriétaire Oracle tout ou une partie des objets
(structure et/ou données) d’une base de données ;
Data Pump Import : permet d’importer dans une base de données tout ou une partie des objets (structure
et/ou données) préalablement exportés par l’outil Data Pump Export ;
SQL*Loader : permet de charger dans des tables d’une base de données, des données stockées dans des
fichiers ASCII.
Les outils Data Pump sont apparus en version 10. Dans les versions précédentes, il existait deux outils équivalents
simplement appelés Export et Import. Ces outils existent toujours pour des raisons de compatibilité ascendantes, mais
les outils Data Pump offrent bien plus de fonctionnalités (voir les remarques ci­après).
Pour utiliser ces outils, la base de données doit être ouverte.
Tous ces outils peuvent être utilisés par l’intermédiaire du Database Control.
Les outils Data Pump (ou les anciens outils d’export et d’import) servent essentiellement à échanger des objets
(structure et/ou données) entre deux bases de données Oracle, qui peuvent être sur des plates­formes différentes, et
qui peuvent avoir des versions différentes. Les outils Data Pump présentent de nombreux avantages par rapport aux
anciens outils d’export et d’import :
●
plus rapides ;
●
possibilité d’arrêter un travail Data Pump, puis de redémarrer ;
●
possibilité de détacher sa session d’un travail Data Pump, puis de la rattacher ultérieurement ;
●
possibilité de faire des transferts directs, à travers le réseau, entre deux bases de données ;
●
plus de finesse dans la sélection des objets à exporter ou importer ;
●
possibilité d’avoir une estimation de l’espace nécessaire lors d’un export ;
●
possibilité de paralléliser une opération (Enterprise Edition uniquement).
Data Pump n’est pas compatible avec les outils d’export et d’import des versions précédentes : un fichier exporté à
l’aide de l’outil d’export d’une version précédente ne peut pas être lu avec l’outil d’import Data Pump (et
réciproquement). Pour échanger des données entre une base Oracle version 10 ou 11 et une base d’une version
précédente, il faut utiliser les outils d’export et d’import traditionnels.
Dans ce chapitre, nous ne présenterons pas les anciens outils d’export et d’import. Par contre, nous présenterons les
outils Data Pump.
L’outil SQL*Loader sert essentiellement à charger des données provenant d’une autre application non Oracle.
Parmi les fonctionnalités de SQL*Loader, les suivantes sont particulièrement intéressantes :
●
Il y a peu de limitation sur le format des données du fichier externe (largeur fixe, avec séparateur, etc.) ;
●
Plusieurs fichiers externes peuvent être chargés dans la même session ;
●
Plusieurs tables peuvent être chargées dans la même session ;
© ENI Editions - All rights reserved - Algeria Educ
- 1-
●
Des critères peuvent être définis pour éliminer certaines données du fichier externe ;
●
Les données peuvent être transformées avec des fonctions SQL pendant le chargement ;
●
Des numéros séquentiels uniques peuvent être générés pour certaines colonnes.
Oracle ne propose pas réellement d’outil pour extraire des données dans un fichier ASCII. Il faut développer des scripts
SQL (avec des requêtes SELECT; et la commande SPOOL pour l’écriture dans un fichier) ou des programmes en PL/SQL.
Nous en donnerons des exemples en fin de chapitre.
Depuis la version 10, Oracle propose aussi le package DBMS_FILE_TRANSFER; qui permet d’effectuer des copies
de fichiers binaires, soit localement, soit entre bases de données. Ce package peut être intéressant pour des
procédures de transfert de données. Voir la documentation PL/SQL Packages and Types Reference.
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
L’instance
1. La SGA
a. Vue d’ensemble
La SGA (System Global Area) est une zone de mémoire partagée par les différents processus de l’instance.
La SGA est allouée au démarrage de l’instance et libérée lors de l’arrêt de l’instance. Elle est dimensionnée par un
ensemble de paramètres définis dans le fichier de paramètres.
Depuis la version 9 d’Oracle, la SGA est redimensionnable à chaud. Depuis la version 10 d’Oracle, certaines
structures de la SGA peuvent être gérées automatiquement (cf. section La gestion de la mémoire dans ce chapitre).
La taille maximale de la SGA est limitée par le paramètre SGA_MAX_SIZE.
La SGA comporte les structures suivantes :
●
Database Buffer Cache : cache de données ;
●
Redo Log Buffer : mémoire tampon pour l’enregistrement des modifications apportées à la base de données ;
●
Shared Pool : zone de partage des requêtes et du dictionnaire Oracle ;
●
Java Pool : mémoire utilisée par la machine virtuelle Java intégrée ;
●
●
●
Large Pool : zone de mémoire optionnelle utilisée par différents processus dans des configurations
particulières ;
Streams Pool : zone de mémoire utilisée par la fonctionnalité Streams (fonctionnalité qui permet de faire
circuler des informations entre processus) ;
Result Cache (nouveau en version 11) : cache pour le résultat des requêtes SQL ou des fonctions PL/SQL.
La SGA contient aussi une structure appelé "SGA fixe" qui contient des informations sur l’état de la base de données
et de l’instance, et sur les verrous. Cette SGA fixe n’est pas dimensionnée par le DBA ; sa taille est faible (quelques
centaines de Ko).
Dans Oracle Enterprise Manager, en français, Oracle utilise la terminologie suivante :
Database Buffer Cache : Cache de tampon
Shared Pool : Pool partagé
Java Pool : Pool java
Large Pool : Zone de mémoire LARGE POOL
Généralement, plus la SGA est grande, meilleures sont les performances... sous réserve que la SGA tienne
en mémoire physique !
b. La Shared Pool
La Shared Pool est composée principalement de deux structures :
●
le Library Cache ;
●
le Dictionary Cache.
Le Library Cache contient des informations sur les ordres SQL et PL/SQL les plus récemment exécutés :
© ENI Editions - All rights reserved - Algeria Educ
- 1-
●
le texte de l’ordre ;
●
sa version analysée ;
●
le plan d’exécution.
Le Dictionary Cache contient les informations du dictionnaire de données Oracle les plus récemment utilisées :
●
description des tables ;
●
droits des utilisateurs ;
●
etc.
La Shared Pool est globalement dimensionnée par le paramètre d’initialisation SHARED_ POOL_SIZE. La répartition entre
le Library Cache et le Dictionary Cache est assurée par Oracle. La taille de Shared Pool est typiquement comprise
entre quelques dizaines de Mo et quelques centaines de Mo.
Le Library Cache
Lorsqu’une requête doit être exécutée, Oracle doit d’abord l’analyser (étape de parse) pour vérifier qu’elle est
syntaxiquement correcte (FROM après le SELECT) et sémantiquement correcte (les tables et colonnes existent et
l’utilisateur a le droit d’y accéder), puis déterminer le plan d’exécution de la requête (différentes étapes permettant
de traiter la requête).
Comme cette étape d’analyse prend un peu de temps et que le résultat consomme de la mémoire, Oracle cherche à
partager les requêtes entre les utilisateurs de manière à gagner du temps et économiser de la mémoire si un
utilisateur exécute une requête déjà exécutée au préalable (par lui ou par un autre utilisateur).
Lorsqu’une requête est exécutée pour la première fois, Oracle stocke le résultat de l’analyse dans le Library Cache
puis exécute la requête. Lorsque la même requête est de nouveau exécutée plus tard, Oracle est en mesure de la
retrouver dans le Library Cache et de l’exécuter directement sans refaire l’analyse (ou tout du moins en faisant une
analyse plus légère). Dans la pratique, le Library Cache ayant une taille finie, Oracle utilise un algorithme LRU (Least
Recently Used) pour gérer le cache : en cas de manque de place, Oracle supprime du cache la requête utilisée la
moins récemment.
Pour Oracle, deux requêtes sont les mêmes si elles sont identiques au caractère près (y compris
majuscules/minuscules, espaces, etc.). Les requêtes suivantes sont toutes différentes les unes des autres :
select
select
SELECT
SELECT
*
*
*
*
from
from
FROM
FROM
client
client
client
client
where
where
WHERE
WHERE
id
id
id
id
=
=
=
=
1;
1;
1;
2;
Lorsque les requêtes sont générées par un applicatif, il n’y a généralement pas de problème sur les majuscules et
les minuscules ou sur les espaces ; lorsqu’un utilisateur demande une fiche client dans l’application, la requête sous­
jacente est toujours écrite de la même manière... sauf peut­être pour des valeurs utilisées dans la clause WHERE (voir
les deux derniers exemples ci­dessus).
Dans ce cas, l’identité parfaite peut être obtenue en utilisant des variables bind dans le texte de la requête.
Exemple :
SELECT * FROM client WHERE id = :v;
L’utilisation de variables bind dans le texte de la requête lors du développement permet d’améliorer le partage des
requêtes et peut améliorer de manière importante les performances d’un système accédé simultanément par un
grand nombre d’utilisateurs.
Les principaux middleware utilisés pour interfacer Oracle et les outils de développement permettent d’utiliser les
variables bind : OLE DB, Oracle Objects For OLE (OO4O), JDBC, Bibliothèque Oracle de PHP, etc.
Le paramètre d’initialisation CURSOR_SHARING permet éventuellement d’indiquer à Oracle dans quelles
conditions deux requêtes peuvent partager le même curseur. Voir la documentation Oracle® Database
Reference.
Le Dictionary Cache
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Comme nous le verrons au point Le dictionnaire de données tout Oracle... est dans Oracle, en l’occurrence dans le
dictionnaire de données.
Dans le dictionnaire de données, Oracle stocke toutes les informations relatives à la base de données : liste des
tables et des colonnes, liste des utilisateurs et de leurs droits, informations sur le stockage, etc.
Lors de la phase d’analyse d’une requête, Oracle utilise le dictionnaire de données pour vérifier que les objets
demandés existent, que l’utilisateur a le droit d’y accéder, pour déterminer où sont stockés les objets, etc.
Pour garantir un bon niveau de performance, Oracle cherche à maintenir tout ou partie du dictionnaire de données
en mémoire, dans le Dictionary Cache.
Le Dictionary Cache est aussi appelé Row Cache dans la documentation.
c. Le Database Buffer Cache
Le Database Buffer Cache contient les blocs de données les plus récemment utilisés :
●
blocs de tables ;
●
blocs d’index ;
●
blocs de segments d’annulation, contenant la version précédente des données en cours de modification.
Les blocs sont lus en mémoire par les processus serveur et écrits dans les fichiers de données par le ou les
processus d’arrière­plan DBWn.
Toute modification (INSERT, UPDATE, DELETE) d’un bloc s’effectue en mémoire et l’écriture sur disque est différée.
Le Database Buffer Cache est un cache de données qui joue le même rôle que la Shared Pool mais pour les données.
Les données de la base de données ne sont accessibles, en lecture ou en mise à jour, qu’après avoir été chargées
dans le Database Buffer Cache.
Dans la pratique, le Database Buffer Cache ayant une taille finie, Oracle utilise un algorithme LRU (Least Recently Used)
pour gérer le cache : en cas de manque de place, Oracle supprime du cache les données utilisées le moins
récemment.
Le Database Buffer Cache est dimensionné par les paramètres suivants :
■
DB_CACHE_SIZE : taille du cache pour la taille de bloc par défaut (poolDEFAULT)
■
DB_nK_CACHE_SIZE : taille du cache pour les blocs de n Ko (n valant 2, 4, 8, 16 ou 32).
Dans le cas où la base de données utilise des tablespaces ayant des tailles de blocs différentes de la taille de bloc
standard, il faut dimensionner d’autres pools dans le Database Buffer Cache, pour les blocs en question ; cette
opération s’effectue grâce aux paramètres DB_nK_CACHE_SIZE.
Dans certaines configurations plus avancées, il est possible aussi de définir deux autres pools au sein du Database
Buffer Cache :
■
■
Le pool KEEP destiné à stocker des données qui doivent rester le plus longtemps possible en mémoire. Ce pool est
dimensionné par le paramètre DB_KEEP_ CACHE_SIZE.
Le pool RECYCLE destiné à stocker des données qui n’ont pas vocation à rester longtemps en mémoire. Ce pool est
dimensionné par le paramètre DB_RECYCLE_ CACHE_SIZE.
Avant Oracle9i, la taille du Database Buffer Cache était définie en nombres de blocs (d’une taille définie par
DB_BLOCK_SIZE) grâce au paramètre DB_BLOCK_BUFFERS. Ce paramètre existe toujours pour des raisons de
compatibilité ascendante mais il est déprécié.
Généralement, augmenter la taille du Database Buffer Cache améliore les performances.
d. Le Redo Log Buffer
© ENI Editions - All rights reserved - Algeria Educ
- 3-
Le Redo Log Buffer stocke les informations sur les modifications apportées à la base de données, avant leur écriture
dans un fichier de journalisation.
Ce buffer est utilisé de manière séquentielle (les modifications de plusieurs transactions se mélangent) et circulaire
(quand il est plein, il repart au début... après avoir été écrit sur disque dans un fichier de journalisation).
Pour chaque modification, une entrée redo (redo entry) est écrite dans le buffer.
Une entrée redo est composée d’un ensemble de vecteurs (change vector) qui décrivent chacun une modification
atomique d’un bloc (table, index ou segment d’annulation). La nouvelle valeur, mais aussi l’ancienne, sont ainsi
enregistrées dans le fichier de journalisation. Ainsi, les tables, les index, mais aussi les segments d’annulation, sont
"protégés" par les fichiers de journalisation. Lors d’une récupération, les fichiers de journalisation contiennent les
informations nécessaires pour refaire une transaction perdue (notion de roll forward) ou annuler une transaction en
cours au moment de l’incident (notion de roll back).
Le Redo Log Buffer est dimensionné par le paramètre LOG_BUFFER.
e. Autres pools de la SGA
La Java Pool
La Java Pool est dimensionnée par le paramètre JAVA_POOL_SIZE (24 Mo par défaut). Ce paramètre peut être mis à 0
si la machine virtuelle Java intégrée à Oracle n’est pas utilisée. Vous pouvez consulter la documentation Oracle®
Database Java Developer’s Guide pour les considérations sur la mémoire utilisée par la machine virtuelle Java
intégrée.
La Large Pool
La Large Pool est notamment utilisée dans la configuration serveur partagé (voir plus loin). Elle est dimensionnée par
le paramètre LARGE_POOL_SIZE. La valeur par défaut du paramètre est dérivée d’autres paramètres.
La Streams Pool
La Streams Poolest dimensionnée par le paramètre STREAMS_POOL_SIZE (0 par défaut). Vous pouvez consulter la
documentation Oracle® Streams Concepts and Administration pour en savoir plus sur le fonctionnement de la
fonctionnalité Streams.
Le Result Cache
La taille maximum du Result Cache est dimensionnée par défaut par Oracle en fonction de la quantité de mémoire
totale disponible pour la SGA et du mode de gestion de la mémoire actuellement utilisé (voir plus loin). En cas de
besoin, cette taille maximum peut être définie par le paramètre RESULT_CACHE_MAX_SIZE. Vous pouvez consulter la
documentation Oracle® Database Performance Tuning Guide pour obtenir plus d’informations sur l’utilisation du
Result Cache.
f. La notion de granule
Un granule est une quantité de mémoire qui peut être allouée à une structure de la SGA. La taille du granule dépend
de la taille totale de la SGA :
●
●
4 Mo si la taille totale de la SGA est inférieure ou égale à 1 Go ;
8 Mo (plate­forme Windows) ou 16 Mo (autres plates­formes) si la taille totale de la SGA est strictement
supérieure à 1 Go.
L’allocation de mémoire aux structures de la SGA s’effectue en nombre entier de granules (avec un arrondi
automatique au granule supérieur si la valeur d’un paramètre n’est pas un multiple de la taille du granule).
2. Les processus d’arrière­plan
a. Introduction
Les processus d’arrière­plan ont chacun un rôle bien précis dans le fonctionnement de l’instance. La plupart des
processus d’arrière­plan sont lancés au démarrage de l’instance et arrêtés lors de l’arrêt de l’instance. Certains
processus peuvent être lancés et arrêtés au cours du fonctionnement de l’instance.
- 4-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Il existe, en tout, une trentaine de processus d’arrière­plan différents, mais certains processus d’arrière­plan
peuvent être lancés en plusieurs exemplaires. Chaque processus d’arrière­plan a un nom de 4 caractères,
éventuellement de la forme ABCn, n étant un numéro ou une lettre variable pour les processus multiples.
Les principaux processus d’arrière­plan pour une instance standard sont les suivants :
DBWn
LGWR
CKPT
SMON
ARCn
CJQn
PMON
b. DBWn
Les processus d’arrière­plan DBWn (Database Writer) sont chargés d’écrire les blocs modifiés du Database Buffer
Cache dans les fichiers de données.
Généralement, une instance a un seul processus Database Writer désigné par DBW0. Sur les systèmes
multiprocesseurs et multidisques ayant une forte activité de mise à jour, il est possible, voire conseillé, de démarrer
plusieurs processus Database Writer (jusqu’à 20).
Les processus DBWn réalisent des écritures multiblocs, en différé par rapport aux modifications en mémoire.
L’écriture est déclenchée par un des événements suivants :
●
●
Un processus serveur ne trouve pas de place dans le cache.
Périodiquement, pour faire avancer le point de reprise (position dans les fichiers de journalisation à partir de
laquelle la récupération de l’instance est susceptible de démarrer).
Il est donc important de noter qu’il n’y a pas de synchronisation entre la modification d’un bloc en mémoire, même
validée (COMMIT), et l’écriture sur disque des blocs en question.
À un instant donné, il est donc possible de se trouver dans la situation suivante :
●
●
Un fichier de données peut ne pas contenir les données modifiées de transactions validées (COMMITées).
Inversement, si le Database Buffer Cache est petit, si la validation tarde, si d’autres processus serveurs ont
besoin de place dans le cache, des données modifiées de transactions non validées peuvent être écrites
dans les fichiers de données.
Que se passe­t­il en cas de plantage de l’instance à cet instant précis ? Nous verrons dans la suite que, pour les
deux situations précédentes, les informations nécessaires sont présentes dans les fichiers de journalisation et
permettent à l’instance, lorsqu’elle redémarre, de remettre les fichiers de données en état (c’est la "récupération de
l’instance " déjà évoquée précédemment).
c. LGWR
Le processus d’arrière­plan LGWR (Log Writer) est chargé d’écrire le Redo Log Buffer dans le fichier de journalisation
courant.
LGRW écrit séquentiellement dans les fichiers de journalisation.
L’écriture est déclenchée par un des événements suivants :
●
Une transaction est validée (COMMIT).
●
Le Redo Log Buffer est au tiers plein.
●
Database Writer s’apprête à écrire des blocs modifiés de transactions non validées dans les fichiers de
données.
© ENI Editions - All rights reserved - Algeria Educ
- 5-
●
Un délai est dépassé (3 secondes).
L’écriture dans les fichiers de journalisation du Redo Log Buffer est la seule chose qui se produit lors de la validation
(COMMIT) d’une transaction. Cette opération d’écriture étant normalement rapide, la validation est rapide (notion de
fast commit).
Inversement, si DBWn écrit dans les fichiers de données des blocs modifiés de transactions pas encore validées
(COMMITées), le Redo Log Buffer est écrit dans les fichiers de journalisation.
Nous avons vu précédemment que le Redo Log Buffer contient les anciennes valeurs des données modifiées (dans
des blocs de segment d’annulation) et les nouvelles valeurs (dans des blocs de tables et d’index).
En cas d’arrêt anormal de l’instance, le fait qu’un fichier de données puisse ne pas contenir les données modifiées de
transactions validées ou contenir des données modifiées de transactions non validées, ne pose pas de problème :
grâce au processus d’écriture décrit ci­dessus, les fichiers de journalisation contiennent forcément les informations
nécessaires pour refaire les transactions validées (mettre dans les fichiers de données les données modifiées des
transactions validées) ou défaire les modifications non validées (remettre dans les fichiers de données les anciennes
données pour les modifications non validées). Cette récupération de l’instance après un arrêt anormal est un
processus automatique qui ne requiert aucune intervention.
Lors de la validation d’une transaction, Oracle affecte un numéro SCN (System Change Number) à la transaction. Ce
numéro SCN est enregistré dans le fichier de journalisation et à d’autres endroits. Ce numéro est fondamental pour
la capacité du système à savoir où il en est.
d. CKPT
Périodiquement, tous les blocs modifiés du Database Buffer Cache sont écrits dans les fichiers de données : c’est le
mécanisme de synchronisation (checkpoint). Par ce biais, les fichiers de données et les fichiers de contrôle sont
rendus cohérents (même numéro SCN). Cela permet de garantir que les blocs modifiés en mémoire sont bien écrits
dans les fichiers de données.
Ce mécanisme définit aussi un point de reprise dans les fichiers de journalisation (correspondant à un numéro SCN) :
cette position correspond à la modification de bloc la plus ancienne qui n’a pas encore été écrite dans un fichier de
données. En cas d’arrêt anormal de l’instance, ce point marque le début des données à utiliser pour la récupération
de l’instance.
Une synchronisation se déclenche notamment lors d’un basculement de fichier de journalisation. Cela provoque dans
ce cas, l’écriture dans les fichiers de données des blocs modifiés (non encore écrits) relatifs aux informations
présentes dans le fichier de journalisation.
Le processus d’arrière­plan LGWR s’interdit de commencer à écrire dans un fichier de journalisation dont la
synchronisation n’est pas terminée. En effet, tant que cette synchronisation n’est pas terminée, le fichier de
journalisation contient des informations qui seraient nécessaires pour une récupération de l’instance en cas d’arrêt
anormal.
Une synchronisation se produit aussi lors de l’arrêt de la base de données et lors de la mise hors ligne d’un
tablespace. Avant ces opérations de "fermeture", les blocs modifiés qui se trouvent encore en mémoire sont écrits
dans les fichiers de données.
Le processus d’arrière­plan CKPT (Checkpoint) a simplement pour rôle d’enregistrer le point de reprise dans l’en­tête
des fichiers de données et dans le fichier de contrôle.
e. SMON
Le processus d’arrière­plan SMON (System Monitor) est principalement chargé de faire la récupération de l’instance
après un arrêt anormal.
Il est aussi chargé de libérer les segments temporaires inutilisés et de compacter l’espace contigu disponible dans
les tablespaces gérés par le dictionnaire (voir le chapitre Gestion des tablespaces et des fichiers de données). Au
cours de la récupération de l’instance, SMON effectue deux opérations :
●
●
Un roll forward pour appliquer aux fichiers de données les modifications non enregistrées des transactions
validées.
Puis un roll back pour enlever des fichiers de données les modifications enregistrées des transactions non
validées.
f. PMON
- 6-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Le processus d’arrière­plan PMON (Process Monitor) est principalement chargé du nettoyage lors du plantage d’un
processus utilisateur :
●
Annulation (ROLLBACK) de la transaction.
●
Libération des verrous et des ressources.
PMON est capable de détecter les situations où un processus utilisateur qui a ouvert une session sur le serveur n’est
plus "présent" et n’a pas fermé la session. La cause de la non "présence" du processus utilisateur est variable : fin
anormale de l’application sur le poste de l’utilisateur, coupure réseau, etc.
Dans tous les cas, PMON se charge du nettoyage en effectuant une annulation (ROLLBACK) de la transaction, cette
annulation libérant notamment les verrous posés par la transaction. Du point de vue de l’intégrité des données dans
la base de données, la disparition du processus utilisateur ne pose pas de problème.
g. CJQn
Les processus d’arrière­plan CJQn (Job Queue) sont chargés d’exécuter périodiquement les tâches programmées sur
le système.
Un processus coordinateur (CJQ0) surveille s’il y a des travaux à exécuter. Si c’est le cas, il démarre un processus
esclave (J000 à J999) qui va se charger d’exécuter le travail.
Des travaux (traitements PL/SQL par exemple) peuvent être programmés
DBMS_SCHEDULER ou des fonctions de programmation d’Oracle Enterprise Manager.
à
l’aide
du
package
h. ARCn
Les processus d’arrière­plan ARCn (Archiver) sont chargés de l’archivage des fichiers de journalisation pleins.
Le fonctionnement de ces processus sera présenté plus en détail dans le chapitre Sauvegarde et récupération.
3. Les processus serveurs
Les processus serveurs sont chargés de traiter les requêtes des utilisateurs, et notamment de charger les données
nécessaires dans le Database Buffer Cache.
Le processus serveur communique (localement ou à travers le réseau) avec un processus utilisateur correspondant à
l’application de l’utilisateur.
Dans la configuration par défaut, Oracle lance un processus serveur dédié pour chaque utilisateur (dedicated server
configuration). Ce processus ne traite que les requêtes de l’utilisateur en question.
Si besoin, Oracle peut être configuré en serveur partagé (shared server configuration) de manière à avoir des
processus serveurs partagés par plusieurs processus utilisateurs.
Dans une configuration serveur partagé, un petit nombre de processus serveurs sont partagés entre les différents
processus utilisateurs et peuvent traiter indifféremment les requêtes de n’importe quel processus utilisateur. Cette
configuration permet de limiter le nombre de processus lancés sur le serveur et d’optimiser l’utilisation des ressources
systèmes. Cette configuration est une configuration avancée qui n’est pas couverte dans cet ouvrage. La mise en
œ uvre de cette configuration est présentée dans la documentation Oracle® Database Administrator’s Guide.
Dans les deux cas, la communication entre le processus utilisateur et le processus serveur est locale, si l’application
est lancée sur le serveur ou s’effectue à travers le réseau (grâce à la couche Oracle Net), si l’application est lancée sur
un poste du réseau.
4. La PGA
La PGA (Program Global Area) est la mémoire privée des différents processus.
Pour un processus serveur, la PGA contient :
●
une zone de travail SQL (SQL work area) allouée dynamiquement pour certaines opérations (tri par exemple) ;
© ENI Editions - All rights reserved - Algeria Educ
- 7-
●
des informations sur la session ;
●
des informations sur le traitement des requêtes de la session ;
●
les variables de session.
La PGA totale, allouée à tous les processus serveurs, est appelée PGA agrégée (aggregated PGA) ou PGA de l’instance
(instance PGA).
Dans une configuration serveur partagé, une partie de la PGA est en fait stockée dans la SGA, dans la Large Pool, ou, à
défaut, dans la Shared Pool.
Dans une configuration serveur partagé, ce n’est pas forcément le même processus serveur qui va traiter deux
requêtes successives du même processus utilisateur. Les informations relatives à cette session utilisateur doivent
donc être accessibles à l’ensemble des processus serveurs ; c’est la raison pour laquelle, dans cette configuration, une
partie de la PGA des processus serveurs est en fait stockée dans la SGA ; lorsqu’un processus serveur traite la
requête d’un processus utilisateur, il "recharge" le contexte du processus utilisateur à partir de la SGA. En
configuration serveur partagé, il faut donc augmenter la taille de la SGA (de préférence en prévoyant une Large Pool),
mais les besoins globaux en mémoire sont à peu près identiques (puisque les processus serveurs utilisent en propre
moins de mémoire).
Historiquement, la taille de la zone de travail SQL est contrôlée par plusieurs paramètres : SORT_AREA_SIZE (pour les
tris), HASH_AREA_SIZE (jointure par hachage), BITMAP_ MERGE_AREA_SIZE (fusion de bitmap d’index bitmap) et
CREATE_BITMAP_AREA_SIZE (création d’index bitmap). Ces différents paramètres sont complexes à régler car les besoins
peuvent varier d’une session à l’autre.
Depuis la version 9, un nouveau mécanisme permet de gérer automatiquement et globalement la PGA agrégée des
processus serveurs. ll suffit de définir la quantité de mémoire totale qui peut être utilisée par la PGA agrégée et laisser
Oracle répartir cette mémoire entre les différents processus en fonction des besoins. Avec ce mode de fonctionnement,
tous les paramètres présentés ci­dessus sont ignorés.
La taille de la PGA agrégée des processus serveurs est définie par le paramètre PGA_ AGGREGATE_TARGET (voir la
section Création de la base de données à la main dans le chapitre Création d’une nouvelle base de données).
En version 11, la PGA peut aussi être gérée automatiquement au sein de la mémoire totale de l’instance (cf. section La
gestion de la mémoire dans ce chapitre).
5. La gestion de la mémoire
a. Vue d’ensemble
La gestion de la mémoire évolue à chaque version afin de proposer au DBA des possibilités de réglage automatique
de plus en plus poussées :
Version
Oracle9i
Oracle10g
SGA
PGA
SGA dynamique
Gestion automatique de la PGA
Le DBA doit dimensionner
individuellement les différentes
composantes de la SGA, mais
ces composantes sont
redimensionnables à chaud.
Le DBA alloue une quantité de
mémoire totale pour la PGA
agrégée des processus serveurs
et Oracle répartit cette mémoire
automatiquement entre les
différents processus en fonction
des besoins.
Gestion automatique de la
mémoire partagée
Le DBA alloue une quantité de
mémoire totale pour la SGA et
Oracle répartit cette mémoire
automatiquement entre les
différentes composantes de la
SGA en fonction des besoins.
Oracle11g
Gestion automatique de la
mémoire
Le DBA alloue une quantité de
- 8-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
mémoire totale pour l’instance et
Oracle répartit cette mémoire
automatiquement entre la SGA
(et ces différentes composantes)
et la PGA en fonction des
besoins.
Pour que la gestion automatique de la mémoire ou de la mémoire partagée soit opérationnelle, il faut que le
paramètreSTATISTICS_LEVEL soit à TYPICAL (sa valeur par défaut) ou ALL.
Les principes de la gestion automatique de la PGA ont été présentés dans la section La PGA dans ce chapitre.
b. La gestion automatique de la mémoire partagée
Lorsque la gestion automatique de la mémoire partagée est activée (Automatic Shared Memory Management ­ ASMM),
les composantes suivantes de la SGA sont dimensionnées automatiquement par Oracle, en fonction de leurs besoins
respectifs, et adaptées dynamiquement en fonction de la charge du système :
●
Database Buffer Cache (paramètre DB_CACHE_SIZE),
●
Shared Pool (paramètre SHARED_POOL_SIZE),
●
Large Pool (paramètre LARGE_POOL_SIZE),
●
Java Pool (paramètre JAVA_POOL_SIZE),
●
Streams Pool (paramètre STREAMS_POOL_SIZE),
●
SGA fixe (pas de paramètre).
Les autres composantes de la SGA ne sont pas prises en charge par la gestion automatique de la mémoire partagée
et il convient de les dimensionner à la main si besoin :
●
●
Redo Log Buffer (paramètre LOG_BUFFER),
Autres
pools du
Database
DB_RECYCLE_CACHE_SIZE).
Buffer
Cache
(paramètres
DB_nK_CACHE_SIZE,
DB_KEEP_CACHE_SIZE,
Pour activer la gestion automatique de la mémoire partagée, il suffit de définir le paramètre SGA_TARGET. Ce
paramètre spécifie la quantité de mémoire totale allouée à la SGA, pas uniquement la quantité de mémoire allouée
aux composantes prises en charge par la gestion automatique ; la mémoire allouée manuellement aux autres
composantes est déduite de SGA_TARGET. Si besoin, la taille de la SGA peut être modifiée à chaud, en modifiant la
valeur du paramètre SGA_TARGET, dans la limite de SGA_MAX_SIZE.
Dans cette configuration, si les paramètres DB_CACHE_SIZE, SHARED_POOL_SIZE, LARGE_POOL_SIZE, JAVA_POOL_SIZE et
STREAMS_POOL_SIZE ne sont pas spécifiés, ils sont mis à zéro par Oracle et la taille du composant correspondant est
automatiquement et dynamiquement ajustée en interne par Oracle. Si ces paramètres sont spécifiés, ils imposent
une taille minimum au composant.
Si SGA_TARGET est égal à zéro (réglage automatique désactivé), les paramètres DB_CACHE_SIZE, SHARED_POOL_SIZE,
JAVA_POOL_SIZE et STREAMS_POOL_SIZE doivent être définis manuellement ; s’ils ne le sont pas, une valeur par défaut
leur est affectée.N’oubliez pas non plus que la mémoire est allouée aux composantes de la SGA en nombre entier de
granules. La taille d’un granule est de 4 Mo si SGA_MAX_SIZE est inférieur ou égal à 1 Go et de 16 Mo (8 Mo sur plate­
forme Windows) si SGA_MAX_SIZE est supérieur à 1 Go. En cas de besoin, Oracle arrondit la valeur des paramètres au
granule supérieur.
L’instance utilise généralement un granule pour le Redo Log Buffer et la SGA fixe.
Exemple 1 :
SGA_MAX_SIZE = 900M
SGA_TARGET = 800M
LOG_BUFFER = 524288
DB_16K_CACHE_SIZE = 64M
© ENI Editions - All rights reserved - Algeria Educ
- 9-
DB_CACHE_SIZE = 256M
Sur cet exemple, la gestion automatique de la mémoire partagée est activée. Un pool de 64 Mo est alloué dans le
Database BufferCache pour les blocs de 16 Ko et un minimum de 256 Mo est demandé pour le pool standard du
Database Buffer Cache.
La taille de la SGA est 800 Mo (SGA_TARGET).
La mémoire disponible pour le réglage automatique est égal à SGA_TARGET ­ DB_16K_CACHE_SIZE ­ un granule (SGA fixe
et Redo Log Buffer) soit 800 ­ 64 ­ 4 = 732. Cette quantité de mémoire est répartie automatiquement et
dynamiquement par Oracle entre les paramètres DB_CACHE_SIZE, SHARED_POOL_SIZE, LARGE_POOL_ SIZE,
JAVA_POOL_SIZE et STREAMS_POOL_SIZE, en fonction des besoins, mais avec un minimum garanti de 256 Mo pour le pool
standard du Database Buffer Cache.
La mémoire libre est de 100 Mo (SGA_MAX_SIZE ­ SGA_TARGET) ; en cas de besoin SGA_TARGET peut être augmenté pour
tirer parti de cette mémoire disponible.
Exemple 2 :
SGA_MAX_SIZE = 900M
SGA_TARGET = 0
LOG_BUFFER = 524288
DB_CACHE_SIZE = 512M
SHARED_POOL_SIZE = 64M
Sur cet exemple, la gestion automatique de la mémoire partagée n’est pas activée. Le Database Buffer Cache est
dimensionné à 512 Mo et la Shared Pool à 64 Mo. La Java Pool et la Large Pool sont dimensionnées par défaut.
La taille de la SGA est égale à DB_CACHE_SIZE + SHARED_POOL_SIZE + JAVA_POOL_SIZE (défaut) + LARGE_POOL_SIZE
(défaut) + un granule (SGA fixe et Redo Log Buffer) = 512 + 64 + 24 + 0 + 4 = 604 Mo
La mémoire libre est de 296 Mo (SGA_MAX_SIZE ­ taille de la SGA) ; en cas de besoin les différents paramètres
pourront être augmentés pour tirer parti de cette mémoire disponible.
c. La gestion automatique de la mémoire de l’instance
En version 10, la SGA et la PGA peuvent être gérées automatiquement par Oracle, mais c’est de la responsabilité du
DBA de répartir la mémoire disponible pour Oracle entre les deux structures (SGA_TARGET pour la SGA et
PGA_AGGREGATE_TARGET pour la PGA).
La version 11 d’Oracle introduit la gestion automatique de la mémoire (Automatic Memory Management ­ AMM) qui
étend la fonctionnalité de gestion automatique de la mémoire partagée apparue en version 10. Cette fonctionnalité
est supportée uniquement sur les plates­formes suivantes : Linux, Solaris, Windows, HP­UX et AIX. Si vous tentez
d’activer cette fonctionnalité sur une plate­forme non supportée, vous obtiendrez le message d’erreur suivant : ORA00845: MEMORY_TARGET non pris en charge sur ce système.
Lorsque la gestion automatique de la mémoire est activée, la mémoire allouée à l’instance est répartie
automatiquement par Oracle entre la SGA (avec ces différentes composantes) et la PGA. Cette répartition est
adaptée dynamiquement en fonction de la charge du système et des besoins des différentes structures.
Pour activer la gestion automatique de la mémoire, il suffit de définir le paramètre MEMORY_TARGET. Ce paramètre fixe
la taille de la mémoire allouée à l’instance. En complément, il est possible de définir la taille maximum de la mémoire
utilisable par l’instance avec le paramètre <MEMORY_MAX_TARGET.
Si besoin, la taille de la mémoire allouée à l’instance peut être modifiée à chaud, en modifiant la valeur du paramètre
MEMORY_TARGET, dans la limite de MEMORY_MAX_TARGET.
La SGA est gérée selon les mêmes principes qu’avec la gestion automatique de la mémoire partagée. Ainsi, comme
avec la gestion automatique de la mémoire partagée, le Redo Log Buffer et les autres pools du Database Buffer Cache
ne sont pas pris en charge par la gestion automatique et il convient de les dimensionner à la main si besoin.
Normalement, lorsque la gestion automatique de la mémoire est utilisée, tous les autres paramètres relatifs à une
composante de mémoire gérée automatiquement doivent être mis à zéro ou supprimés.
Néanmoins, si les paramètres SGA_TARGET et/ou PGA_AGGREGATE_TARGET sont définis, ils imposent une taille minimum
respectivement pour la SGA et la PGA. De même, comme dans la gestion automatique de la mémoire partagée, si un
des paramètres DB_CACHE_SIZE, SHARED_POOL_SIZE, LARGE_POOL_SIZE, JAVA_POOL_SIZE ou STREAMS_POOL_SIZE est
spécifié, il impose une taille minimum au composant.
À l’inverse, si le paramètre SGA_MAX_SIZE est défini, il impose une taille maximum pour la SGA.
Exemple :
MEMORY_MAX_TARGET = 900M
MEMORY_TARGET = 800M
- 10 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
SGA_MAX_SIZE = 500M
SGA_TARGET = 300M
DB_CACHE_SIZE = 128M
DB_16K_CACHE_SIZE = 64M
PGA_AGGREGATE_TARGET = 64M
Sur cet exemple, la gestion automatique de la mémoire est activée.
La mémoire allouée à l’instance est de 800 Mo (MEMORY_TARGET).
La mémoire disponible pour le réglage automatique est égale à MEMORY_TARGET ­ DB_16K_CACHE_SIZE ­ un granule
(SGA fixe et Redo Log Buffer) soit 800 ­ 64 ­ 4 = 732. Cette quantité de mémoire est répartie automatiquement et
dynamiquement par Oracle entre la PGA et les composantes de la SGA gérées automatiquement, en fonction des
besoins, mais avec un minimum garanti de 128 Mo (DB_CACHE_SIZE) pour le pool standard du Database Buffer Cache,
64 Mo (PGA_AGGREGATE_TARGET) pour la PGA, et une SGA comprise entre 300 Mo (SGA_TARGET) et 500 Mo
(SGA_MAX_SIZE).
La mémoire libre est de 100 Mo (MEMORY_MAX_SIZE ­ MEMORY_TARGET) ; en cas de besoin MEMORY_TARGET peut être
augmenté pour tirer parti de cette mémoire disponible.
Cet exemple est donné dans un but pédagogique. Dans la pratique, si la gestion automatique de la mémoire
est utilisée, il est conseillé de ne spécifier aucun paramètre relatif à une composante de mémoire gérée
automatiquement autre que MEMORY_TARGET et MEMORY_MAX_TARGET.
d. Gestion manuelle : conseil sur la répartition SGA/PGA
Si vous choisissez de gérer manuellement la répartition de la mémoire entre la SGA et la PGA, Oracle donne les
indications suivantes :
●
●
Pour les systèmes transactionnels (OLTP)
●
SGA : environ 80% de la mémoire disponible pour l’instance
●
PGA : environ 20% de la mémoire disponible pour l’instance
Pour les systèmes décisionnels (DSS)
●
SGA : entre 50% et 30% de la mémoire disponible pour l’instance
●
PGA : entre 50% et 70% de la mémoire disponible pour l’instance
Cette recommandation est un point de départ. Il est nécessaire de surveiller ensuite le fonctionnement de l’instance
pour affiner ces valeurs.
En règle générale, les requêtes exécutées par les systèmes transactionnels effectuent des petits tris ; les processus
serveurs n’ont donc pas besoin d’une grosse zone de travail. Privilégier la SGA est alors opportun.
À l’inverse, les requêtes des systèmes décisionnels effectuent de gros tris ; les processus serveurs ont donc besoin
d’une grosse zone de travail. Privilégier la PGA est alors opportun.
Ces directives peuvent être utilisées pour dimensionner la SGA et la PGA sur un système dont la mémoire physique
est imposée.
Supposons par exemple que le système dispose de 1 Go de mémoire physique. Nous pouvons faire le raisonnement
suivant pour un système transactionnel :
●
●
●
●
Réserver 20% de la mémoire pour le système d’exploitation (plus si d’autres applications s’exécutent sur le
serveur), soit 204 Mo arrondis à 224 Mo (un peu de marge).
Il reste donc environ 800 Mo disponibles pour Oracle.
Attribuer 80% de cette mémoire à la SGA et 20% à la PGA, ce qui permet de spécifier SGA_MAX_SIZE = 640M et
PGA_AGGREGATE_TARGET = 160M.
Si nous décidons d’utiliser la fonctionnalité de gestion automatique de la mémoire partagée, et de laisser
© ENI Editions - All rights reserved - Algeria Educ
- 11 -
Oracle faire complètement, nous pouvons aussi spécifier SGA_TARGET = 640M (autant utiliser toute la
mémoire).
●
Si nous souhaitons nous­même régler la taille des différentes structures de la SGA, nous pouvons par
exemple spécifier SHARED_POOL_SIZE = 128M, JAVA_POOL_SIZE = 0 (pas besoin de Java Pool), LARGE_POOL_SIZE
= 0 (pas besoin de Large Pool), réserver un granule pour la SGA fixe et le Redo Log Buffer et allouer toute le
reste au Database Buffer Cache, soit DB_CACHE_SIZE = 508M.
6. Le fichier de paramètres
Au démarrage, l’instance lit un fichier de paramètres qui contient des paramètres d’initialisation. Les paramètres
d’initialisation permettent notamment à l’instance d’allouer la mémoire souhaitée aux différentes structures de la SGA,
et de trouver le nom et l’emplacement des fichiers de contrôle de la base de données à ouvrir. Ce fichier est géré par
le DBA.
Lors du démarrage de l’instance, le fichier de paramètres est lu ; ce fichier contient notamment un paramètre qui
donne l’emplacement des fichiers de contrôle de la base de données à ouvrir, ce qui permet ensuite à l’instance
d’ouvrir les fichiers de contrôle en question et d’y trouver le nom et l’emplacement des autres fichiers de la base de
données.
Historiquement, Oracle utilise un fichier de paramètres de type texte pour le démarrage de l’instance de base de
données. Ce fichier doit se trouver sur la(les) machine(s) qui démarre(nt) la base de données, ce qui peut poser des
problèmes pour le démarrage à partir du réseau, et engendrer des duplications du fichier sur plusieurs machines et
des problèmes de synchronisation en cas de mise à jour.
Depuis la version 9, il est possible d’utiliser un fichier de paramètres binaire stocké sur le serveur (server parameter file
=SPFILE). Ce fichier peut être considéré comme une sorte de référentiel centralisé des paramètres d’initialisation, qui
élimine la nécessité de dupliquer le fichier de paramètres sur plusieurs machines.
Les modifications de paramètres effectuées dynamiquement pendant le fonctionnement de l’instance peuvent aussi
persister dans ce fichier de paramètres serveur.
Le fichier de paramètres serveur est un fichier binaire qui ne peut pas être consulté ou modifié avec un éditeur de
texte ; d’autres moyens seront utilisés pour cela.
Il ne faut jamais modifier un fichier de paramètres serveur avec un éditeur de texte, au risque de le
corrompre, voire de provoquer un arrêt de l’instance.
Nous verrons que le fichier de paramètres serveur est créé à partir d’un fichier de paramètres texte.
Dans un fichier de paramètres texte, les paramètres sont spécifiés sous la forme nom_ paramètre = valeur. Tous les
paramètres sont optionnels et ont une valeur par défaut. Des commentaires peuvent être inclus et commencent par le
caractère #. La valeur peut être spécifiée entre des guillemets doubles si elle contient des caractères spéciaux (égal,
espace, etc.). Les valeurs multiples peuvent être spécifiées entre parenthèses, séparées par des virgules.
Exemple :
db_name = hermes
# nom de la base de données
# fichiers de contrôle de la base
control_files = ("f:\oradata\HERMES\control01.ctl",
"g:\oradata\HERMES\control02.ctl")
7. Infrastructure pour la gestion automatique
Depuis la version 10, Oracle comporte beaucoup de fonctionnalités qui facilitent l’administration de la base de données
et dans certains cas, l’automatise.
Ces nouvelles fonctionnalités reposent sur une infrastructure que nous allons décrire brièvement ici ; il n’est en effet
pas nécessaire de connaître cette infrastructure dans le détail pour pouvoir tirer parti des nouvelles fonctionnalités.
De nouveaux processus d’arrière­plan sont chargés de collecter en mémoire des statistiques sur le fonctionnement du
système. Toutes les 60 minutes (valeur modifiable), ces statistiques sont déversées dans le référentiel AWR
(Automatic Workload Repository), qui se matérialise par un ensemble de tables dans le tablespace SYSAUX. Par défaut,
ces statistiques sont conservées 8 jours.
À chaque fois qu’une collecte est déversée dans le référentiel AWR, ADDM (Automatic Database Diagnostic Monitor)
effectue un diagnostic des performances du système, détecte les éventuels problèmes et propose des solutions. Le
résultat de l’analyse ADDM est stocké dans le référentiel et peut être consulté dans Enterprise Manager Database
Control.
- 12 -
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
En complément, plusieurs conseillers sont disponibles pour avoir des recommandations sur l’optimisation des requêtes
SQL, l’indexation, la gestion de la mémoire, etc. Ces conseillers exploitent, eux aussi, les données stockées dans le
référentiel AWR.
© ENI Editions - All rights reserved - Algeria Educ
- 13 -
Data Pump
1. Présentation
a. Architecture
Data Pump est un utilitaire serveur qui peut être utilisé pour déplacer des données et/ou des métadonnées
(définitions) entre des bases Oracle.
Data Pump comporte trois éléments :
●
un package PL/SQL DBMS_DATAPUMP ;
●
un package PL/SQL DBMS_METADATA ;
●
deux outils clients ligne de commande expdp (export) et impdp (import).
Les outils clients expdp et impdp servent d’interface avec le package DBMS_DATAPUMP, qui est, en quelque sorte, l’API
(Application Programming Interface) de Data Pump. Ce package est complètement documenté, ce qui permet d’utiliser
directement les fonctionnalités Data Pump dans un programme. Data Pump peut aussi être utilisé à partir du
Database Control.
Les opérations proprement dites d’export et d’import sont effectuées par le package DBMS_DATAPUMP et donc, sur le
serveur Oracle. Cela inclut notamment la lecture et/ou l’écriture des fichiers : les fichiers générés lors d’un export
sont écrits sur le serveur et les fichiers chargés lors d’un import sont lus sur le serveur. L’accès aux fichiers sur le
serveur s’effectue grâce à des objets DIRECTORY ; un objet DIRECTORY est un alias vers un répertoire du système
d’exploitation. Ces objets DIRECTORY doivent être créés par le DBA (cf. L’objet DIRECTORY).
Lorsqu’un travail Data Pump est créé, Oracle crée différentes structures pour gérer l’opération, parmi lesquelles :
●
●
une table dite "maître" dans le schéma de l’utilisateur qui crée le travail (cette table porte le même nom que
le travail) ;
un processus de contrôle maître (nommé DMnn) qui contrôle l’exécution du travail.
La table "maître" contient différentes informations sur le travail, utilisées notamment pour redémarrer le travail. La
table "maître" est supprimée lorsque le travail se termine normalement, ou lorsque le travail est supprimé avec la
commande KILL_JOB (voir plus loin) ; en cas de besoin, cette table peut être directement supprimée à la main, à
l’aide d’un ordre SQL DROP TABLE
b. Les modes d’export ou d’import
Data Pump propose cinq niveaux (modes) pour les opérations d’export et d’import :
●
Complet : totalité de la base de données ;
●
Schéma : un ou plusieurs schémas ;
●
Table : une ou plusieurs tables ;
●
Tablespace : toutes les tables stockées dans un ou plusieurs tablespaces ;
●
Tablespace transportable : permet le transport de tablespaces entre deux bases de données.
Par la suite, nous verrons que pour chaque mode, il est possible de préciser très finement le contenu de l’export ou
de l’import, en filtrant les objets et/ou les données.
c. Les privilèges nécessaires
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Aucun privilège particulier n’est requis pour exporter des objets de son schéma, ou importer dans son schéma des
objets préalablement exportés de son schéma.
Par contre, pour exporter des objets d’un autre schéma, il faut avoir le rôle EXP_FULL_DATABASE. De même, pour
importer dans un autre schéma, ou pour importer dans son schéma des objets en provenance d’un autre schéma, il
faut avoir le rôle IMP_FULL_DATABASE. Ces rôles sont attribués au DBA.
d. L’objet DIRECTORY
Un objet DIRECTORY est un alias vers un répertoire du système d’exploitation. Cet objet est utilisé par beaucoup de
fonctionnalités du serveur Oracle qui ont besoin d’accéder à des fichiers du système d’exploitation hôte.
Syntaxe pour la création/modification
CREATE[ OR REPLACE ] DIRECTORY nom_directory AS ’chemin’ ;
Syntaxe pour la suppression
DROP DIRECTORY nom_directory ;
Les privilèges systèmes CREATE ANY DIRECTORY et DROP ANY DIRECTORY sont requis pour créer et supprimer un objet
DIRECTORY
Syntaxe pour l’attribution de droits sur cet objet
GRANT privilège [,…] ON DIRECTORY nom_directory
TO utilisateur [,…] ;
Les privilèges objets possibles sont READ pour l’accès en lecture et WRITE pour l’accès en écriture.
La vue DBA_DIRECTORIES permet de lister tous les objets DIRECTORY qui existent dans la base de données.
2. Utilisation des outils lignes de commande
Les outils lignes de commande expdp et <$I[]impdp>impdp peuvent être utilisés de trois façons :
●
en passant les paramètres du travail à réaliser sur la ligne de commande ;
●
en utilisant un fichier de paramètres contenant les paramètres du travail a réaliser
●
en interactif.
Syntaxe :
expdp connexion paramè
t res
impdp connexion paramè
t res
connexion est une chaîne de connexion habituelle (nom, mot de passe, nom de service réseau).
Il est déconseillé d’utiliser une connexion AS SYSDBA
paramètres est une liste de paramètres. Les paramètres peuvent être regroupés dans un fichier de paramètres, dont
le nom est indiqué sur la ligne de commande grâce au paramètre PARFILE Les paramètres sont présentés plus loin.
Exemples
expdp system/az#78@hermes DIRECTORY=dir_exp FULL=y DUMPFILE=exp.dmp
expdp system/az#78@hermes PARFILE=exp_param.txt JOB_NAME=exp_full
expdp system/az#78@hermes ATTACH=exp_job
expdp HELP=y
L’utilisation en interactif peut être activée de deux manières :
- 2-
© ENI Editions - All rights reserved - Algeria Educ
●
●
en tapant les touches [Ctrl] C pendant le déroulement d’une opération lancée à partir de la ligne de
commande ou à l’aide d’un fichier de paramètres ;
en attachant sa session à un travail en cours d’exécution ou arrêté (paramètre ATTACH).
Lorsque vous entrez dans le mode interactif et qu’un travail est cours, l’affichage à l’écran de l’avancement s’arrête
(mais le travail continue en arrière­plan).
En mode interactif, vous disposez de plusieurs commandes qui permettent d’arrêter le travail, de le redémarrer, de le
supprimer, etc. :
CONTINUE_CLIENT
Redémarre l’affichage de l’avancement sur le terminal.
EXIT_CLIENT
Quitte l’outil (mais le travail continu, s’il n’a pas été arrêté).
KILL_JOB
Supprime le travail.
START_JOB
Redémarre le travail.
STOP_JOB[=IMMEDIATE]
Arrête le travail mais ne le supprime pas (il peut être relancé par la commande START_JOB). Sans option, la tâche en
cours se termine ; l’option IMMEDIATE permet d’arrêter le travail immédiatement.
Il existe d’autres commandes. Voir la documentation "Oracle® Database Utilities".
La vue DBA_DATAPUMP_JOBS permet de superviser les travaux Data Pump en cours dans la base de données.
3. Paramètres de l’export et de l’import
Data Pump propose un grand nombre de paramètres. Dans ce chapitre, nous ne présentons que les paramètres les
plus souvent utilisés pour les opérations usuelles d’export et d’import. Reportez­vous à la documentation "Oracle®
Database Utilities" pour avoir la liste de tous les paramètres.
a. Paramètres communs à l’export et à l’import
ATTACH[=[schéma.]nom_travail]
Ce paramètre permet d’attacher sa session à un travail existant. Les rôles EXP_FULL_DATABASE ou
IMP_FULL_DATABASE sont nécessaires pour s’attacher à un travail d’un autre schéma. Si aucun nom n’est spécifié, la
session s’attache au travail en cours du schéma de l’utilisateur, s’il n’y en a qu’un. Lorsque ce paramètre est utilisé,
aucun autre paramètre ne peut être spécifié.
CONTENT=ALL | DATA_ONLY | METADATA_ONLY}
Ce paramètre permet de définir le contenu de l’export ou de l’import (voir ci­après).
DIRECTORY=objet_directory
Ce paramètre permet de définir le nom de l’objet DIRECTORY, correspondant au répertoire par défaut dans lequel les
fichiers vont être écrits ou lus (DATA_PUMP_DIR par défaut). Cet objet DIRECTORY est créé lors de la création de la
base de données et il peut être utilisé par le DBA.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
DUMPFILE=nom_fichier
Ce paramètre permet de définir le nom du fichier utilisé pour l’export ou l’import. Lors de l’export, si le fichier existe
déjà, une erreur est retournée. Il existe une syntaxe évoluée qui permet de spécifier plusieurs fichiers, pour
paralléliser l’export sur plusieurs processus et/ou répartir l’export sur plusieurs fichiers dont la taille est limitée.
EXCLUDE=type_objet[:filtre] [, ...]
Ce paramètre permet d’exclure des objets de l’export ou de l’import (voir plus loin).
FULL={y | n
Si ce paramètre est égal à y, un export ou un import de niveau complet est réalisé.
INCLUDE=object_type[:name_clause] [, ...]
Ce paramètre permet d’inclure des objets dans l’export ou l’export (voir plus loin).
JOB_NAME=nom_travail
Ce paramètre permet de donner un nom au travail. En cas d’absence, un nom est généré par le système (du type
SYS_<opération>_<mode>_<NN>).
LOGFILE=nom_fichier
Ce paramètre permet de définir le nom du fichier journal. Un fichier journal est toujours généré (export.log ou
import.log, par défaut) sauf si le paramètre NOLOGFILE=y est spécifié.
NETWORK_LINK=nom_database_link
Ce paramètre permet de spécifier le nom d’un lien de base de données (database link) à utiliser pour l’opération.
Dans le cas d’un export, les données sont extraites de la base de données distante, et un fichier d’export est
généré sur le système local. Dans le cas d’un import, les données sont extraites de la base de données distante et
importées directement dans la base de données "locale" (celle à laquelle l’outil impdp est connecté).
NOLOGFILE={y | n
Si ce paramètre est égal à y, le fichier journal n’est pas généré.
PARFILE=chemin_fichier
Ce paramètre permet de définir l’emplacement du fichier de paramètres à utiliser pour l’opération. À la différence du
fichier d’export, du fichier d’import, ou du fichier journal, le fichier de paramètres doit être présent sur la machine qui
exécute le programme expdp ou impdp
QUERY=[schéma.][nom_table:]clause_WHERE
Ce paramètre permet de filtrer les données exportées ou importées (voir ci­après).
SCHEMAS=schéma [, ...]
Ce paramètre permet de faire un export ou un import de niveau schéma et de définir le ou les schémas à exporter
ou importer. C’est le mode d’export par défaut (sur le schéma de l’utilisateur).
TABLES=[schéma.]nom_table[:partition] [, ...]
Ce paramètre permet de faire un export ou un import de niveau table et de définir une ou plusieurs tables à
exporter ou importer.
TABLESPACES=nom_tablespace [, ...]
Ce paramètre permet de faire un export ou un import de niveau tablespace et de définir un ou plusieurs
tablespaces à exporter ou importer.
- 4-
© ENI Editions - All rights reserved - Algeria Educ
TRANSPORT_FULL_CHECK={y | n
Si ce paramètre est égal à y, Data Pump vérifie les dépendances entre les objets stockés à l’intérieur des
tablespaces transportés.
TRANSPORT_TABLESPACES=nom_tablespace [, ...]
Ce paramètre permet de faire un export ou un import de niveau transport de tablespace et de définir un ou
plusieurs tablespaces à transporter.
b. Paramètres spécifiques à l’export
COMPRESSION={ALL | DATA_ONLY | METADATA_ONLY| NONE}
Permet d’activer la compression des métadonnées et/ou des données.
ESTIMATE_ONLY={y | n
Si ce paramètre est égal à y, l’export effectue simplement une estimation de l’espace nécessaire pour l’export, mais
sans faire l’export.
c. Paramètres spécifiques à l’import
REMAP_DATAFILE=fichier_source:fichier_cible
Ce paramètre permet de changer les chemins des fichiers de données lors de l’import (par exemple, lorsque l’import
crée un tablespace). Plusieurs paramètres peuvent être spécifiés pour effectuer plusieurs changements (avec un
fichier source différent à chaque fois).
REMAP_SCHEMA=schéma_source:schéma_cible
Ce paramètre permet de charger les objets d’un schéma d’origine dans un autre schéma. Plusieurs paramètres
peuvent être spécifiés pour effectuer plusieurs changements (avec un schéma source différent à chaque fois). Si le
schéma cible n’existe pas, il peut être créé lors de l’import s’il y a les informations suffisantes dans le fichier importé.
REMAP_TABLESPACE=tablespace_source:tablespace_cible
Ce paramètre permet de changer les objets de tablespace lors de l’import. Plusieurs paramètres peuvent être
spécifiés pour effectuer plusieurs changements (avec un tablespace source différent à chaque fois).
SQLFILE=nom_fichier
Ce paramètre permet de générer un fichier SQL contenant tous les ordres DDL qui seraient exécutés, si l’import
était réalisé (mais l’import n’est pas réalisé). Si le fichier existe déjà, il est remplacé.
TABLE_EXISTS_ACTION={SKIP | APPEND | TRUNCATE | REPLACE}
Ce paramètre permet de spécifier ce que l’outil d’import doit faire si, une table qu’il doit créer existe déjà :
SKIP : ne fait rien et passe à l’objet suivant (non autorisé, si CONTENT=DATA_ONLY, valeur par défaut sinon).
APPEND : ajoute les données à la table (valeur par défaut, si CONTENT=DATA_ONLY).
TRUNCATE : tronque la table avant de charger les données.
REPLACE : supprime la table et la recrée, puis charge les données (interdit, si CONTENT=DATA_ONLY).
TRANSPORT_DATAFILES=fichiers
Ce paramètre permet de spécifier l’emplacement des fichiers de données des tablespaces transportés (les fichiers
doivent avoir été copiés au préalable).
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 5-
d. Contenu d’un export ou d’un import
Par défaut, Data Pump exporte ou importe les données et les métadonnées des tables, avec toutes les
dépendances (index, triggers, droits, contraintes, etc.).
Cependant, Data Pump permet de filtrer précisément ce qui doit être exporté ou importé :
●
données et/ou métadonnées ;
●
filtre sur les données ;
●
filtre sur les objets.
Ne s’applique pas au transport de tablespace.
Données et/ou métadonnées
Le paramètre CONTENT permet de préciser globalement ce qui doit être exporté ou importé :
●
ALL : les données et les métadonnées ;
●
DATA_ONLY : les données uniquement ;
●
METADATA_ONLY : les métadonnées uniquement.
Filtre sur les données
Lorsque les données sont exportées ou importées, il est possible de les filtrer grâce au paramètre QUERY :
QUERY = [schéma.][nom_table:]clause_WHERE
Exemple
QUERY = diane.adherent:"WHERE sexe = ’F’"
Le paramètre QUERY peut être spécifié plusieurs fois pour définir des filtres sur plusieurs tables.
Filtre sur les objets
Les paramètres INCLUDE et EXCLUDE peuvent être utilisés pour inclure ou exclure des objets d’une opération d’import
ou d’export :
INCLUDE = type_objet[:"filtre"]
EXCLUDE = type_objet[:"filtre"]
type_objet est le type d’objet à inclure ou à exclure
Exemple
EXCLUDE=trigger
INCLUDE=view:"LIKE ’ADH%’"
Plusieurs filtres peuvent être spécifiés lors d’une opération, un type d’objet pouvant même apparaître dans
plusieurs filtres. Bien noter que dans ce cas, les différents filtres sont combinés par un « et » logique : pour qu’un
objet soit exporté, il doit passer tous les filtres définis sur l’opération.
Par contre, les paramètres EXCLUDE et INCLUDE sont mutuellement exclusifs : soit vous travaillez par inclusion (et
tout ce qui n’est pas explicitement inclus est exclus), soit vous travaillez par exclusion (et tout ce qui n’est pas
explicitement exclus est inclus). Spécifier simultanément les paramètres EXCLUDE et INCLUDE génère une erreur.
À moins d’être explicitement exclues (par un EXCLUDE), les dépendances d’une table (contraintes, triggers, index)
sont toujours exportées, même si elles ne sont pas implicitement incluses (par un INCLUDE). Si vous avez mis
INCLUDE=table et que vous souhaitez exclure une dépendance, il faut l’inclure avec un filtre qui n’est jamais vrai, par
exemple INCLUDE=trigger:"IS NULL" (il n’y a pas de trigger dont le nom est NULL).
- 6-
© ENI Editions - All rights reserved - Algeria Educ
Les vues DATABASE_EXPORT_OBJECTS, SCHEMA_EXPORT_OBJECTS et TABLE_ EXPORT_OBJECTS donnent la liste de tous les
types d’objets qui peuvent être spécifiés dans les paramètres EXCLUDE et INCLUDE, selon le niveau de l’opération.
Exemples :
CONSTRAINT
PACKAGE_SPEC
SYNONYM
DIRECTORY
PROCEDURE
SYSTEM_GRANT
FUNCTION
REF_CONSTRAINT
TABLE
GRANT
ROLE
TABLESPACE
INDEX
ROLE_GRANT
TRIGGER
OBJECT_GRANT
SCHEMA
USER
PACKAGE
SEQUENCE
VIEW
PACKAGE_BODY
STATISTICS
4. Exemples
a. Préambule
Pour les différents exemples, nous supposons qu’il existe un objet DIRECTORY nommé DIR_PUMP, créé avec l’ordre
SQL suivant :
CREATE OR REPLACE DIRECTORY dir_pump AS ’h:\oradata\pump’;
Dans tous les exemples, un fichier de paramètres nommé pump_param.txt est utilisé, et les outils expdp et impdp
sont appelés de la manière suivante :
expdp system/az#78 PARFILE=pump_param.txt
impdp system/az#78 PARFILE=pump_param.txt
La connexion s’effectue implicitement à l’instance définie par la variable d’environnement ORACLE_SID, ou LOCAL, ou
TWO_TASK
b. Export complet
Dans cet exemple, nous allons faire un export complet.
Dans un premier temps, nous allons faire une simple estimation de l’espace à l’aide du fichier de paramètres
suivant :
FULL=y
ESTIMATE_ONLY=y
NOLOGFILE=y
Résultat
Export: Release 11.1.0.6.0 - Production on Dimanche, 10 Août, 2008 15:50:12
...
Estimation en cours à l’aide de la méthode BLOCKS ...
Traitement du type d’objet DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA
...
. estimation de "DIANE"."ADHERENT"
64 KB
. estimation de "DIANE"."CATEGORIE"
64 KB
...
Estimation totale à l’aide le la méthode BLOCKS : 44,39 MB
Tâche "SYSTEM"."SYS_EXPORT_FULL_01" exécutée avec succès à 15:52:07
Nous pouvons ensuite procéder à l’export à l’aide du fichier de paramètres suivants :
JOB_NAME=exp_full
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 7-
FULL=y
DIRECTORY=dir_pump
DUMPFILE=exp-full.dmp
LOGFILE=exp-full.log
Extraits du fichier journal
Export: Release 11.1.0.6.0 - Production on Dimanche, 10 Août, 2008 15:59:10
...
Démarrage de "SYSTEM"."EXP_FULL" : system/******** parfile=pump_param.txt
Estimation en cours à l’aide de la méthode BLOCKS ...
Traitement du type d’objet DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA
Estimation totale à l’aide le la méthode BLOCKS : 44,39 MB
Traitement du type d’objet DATABASE_EXPORT/TABLESPACE
…
. . export : "SYSMAN"."MGMT_METRICS_RAW"
2.564 MB
45088 lignes
. . export : "SYSMAN"."MGMT_MESSAGES"
3.406 MB
19070 lignes
...
*************************************************************************
L’ensemble de fichiers de vidage de SYSTEM.EXP_FULL est :
h:\oradata\pump\exp-full.dmp
Tâche "SYSTEM"."EXP_FULL" exécutée avec succès à 16:06:20
c. Export sélectif
Dans cet exemple, un export sélectif du schéma DIANE est réalisé à l’aide du fichier de paramètres suivant :
JOB_NAME=exp_diane
SCHEMAS=diane
INCLUDE=table:"< > ’CATEGORIE’"
INCLUDE=view
INCLUDE=procedure
INCLUDE=trigger:"IS NULL"
QUERY=diane.adherent:"WHERE sexe = ’F’"
DIRECTORY=dir_pump
DUMPFILE=exp-diane.dmp
LOGFILE=exp-diane.log
Seules les tables (sauf la table CATEGORIE), les vues et les procédures sont explicitement exportées. Comme les
tables sont exportées, par défaut, les contraintes, les index et les triggers le sont aussi ; pour ne pas exporter les
triggers, le paramètre INCLUDE=trigger:"IS NULL" est utilisé (inclusion avec une condition fausse). Les données de
la table ADHERENT sont filtrées.
Résultat
Export: Release 11.1.0.6.0 - Production on Dimanche, 10 Août, 2008 16:19:01
...
Démarrage de "SYSTEM"."EXP_DIANE" : system/******** parfile=pump_param.txt
Estimation en cours à l’aide de la méthode BLOCKS ...
Traitement du type d’objet SCHEMA_EXPORT/TABLE/TABLE_DATA
Estimation totale à l’aide le la methode BLOCKS : 64 KB
Traitement du type d’objet SCHEMA_EXPORT/TABLE/TABLE
Traitement du type d’objet SCHEMA_EXPORT/TABLE/INDEX/INDEX
Traitement du type d’objet SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Traitement du type d’objet SCHEMA_EXPORT/PROCEDURE/PROCEDURE
Traitement du type d’objet SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE
Traitement du type d’objet SCHEMA_EXPORT/VIEW/VIEW
Traitement du type d’objet SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT. .
export : "DIANE"."ADHERENT"
7.976 KB
10 lignes
ORA-39168: Le chemin d’objet TRIGGER est introuvable.
Table maître "SYSTEM"."EXP_DIANE" chargée/déchargée avec succès
***************************************************************************
Le fichier de vidage défini pour SYSTEM.EXP_DIANE est :
h:\oradata\pump\exp-diane.dmp
Tâche "SYSTEM"."EXP_DIANE" exécutée avec 1 erreur(s) à 16:19:19
Sur le résultat, nous voyons que les contraintes et les index ont été exportés ; l’erreur signale que rien n’a été
trouvé pour les triggers.
- 8-
© ENI Editions - All rights reserved - Algeria Educ
d. Import sélectif
À partir de l’export réalisé dans l’exemple précédent, nous allons faire un import sélectif, en effectuant quelques
transformations :
●
Les contraintes d’intégrités référentielles ne seront pas importées ;
●
Les objets vont être chargés dans le schéma MERCURE ;
●
Tout ce qui était stocké dans le tablespace DATA va aller dans le table DEFTBS ;
●
Les données de la table ADHERENT sont de nouveau filtrées.
Le fichier de paramètre est le suivant :
JOB_NAME=imp_diane
SCHEMAS=diane
REMAP_SCHEMA=diane:mercure
REMAP_TABLESPACE=data:deftbs
EXCLUDE=ref_constraint
QUERY=mercure.adherent:"WHERE EXTRACT(YEAR FROM date_naissance) >= 1970"
DIRECTORY=dir_pump
DUMPFILE=exp-diane.dmp
LOGFILE=imp-diane.log
Notez que le filtre QUERY porte sur la table dans le schéma cible.
Résultat
Import: Release 11.1.0.6.0 - Production on Dimanche, 10 Août, 2008 16:27:07
...
Table maître "SYSTEM"."IMP_DIANE" chargée/déchargée avec succès
Démarrage de "SYSTEM"."IMP_DIANE" : system/******** parfile=param.txt
Traitement du type d’objet SCHEMA_EXPORT/TABLE/TABLE
Traitement du type d’objet SCHEMA_EXPORT/TABLE/TABLE_DATA
... import de "MERCURE"."ADHERENT"
7.976 KB
4 sur 10 lignes
Traitement du type d’objet SCHEMA_EXPORT/TABLE/INDEX/INDEX
Traitement du type d’objet SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Traitement du type d’objet SCHEMA_EXPORT/PROCEDURE/PROCEDURE
Traitement du type d’objet SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE
Traitement du type d’objet SCHEMA_EXPORT/VIEW/VIEW
Tâche "SYSTEM"."IMP_DIANE" exécutée avec succès à 16:27:17
Nous voyons que les données ont bien été de nouveau filtrées.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 9-
SQL*Loader
1. Vue d’ensemble
a. Présentation
SQL*Loader est un outil très puissant qui permet de charger des données :
●
à partir d’un ou plusieurs fichiers externes ;
●
avec des enregistrements de longueur fixe ou de longueur variable (avec délimiteurs) ;
●
dans une ou plusieurs tables ;
●
en appliquant des traitements, des contrôles ou des filtres sur les données.
b. Fonctionnement général
En entrée, SQL*Loader prend un fichier de contrôle (rien à voir avec le fichier de contrôle d’une base de données)
qui pilote le chargement, et un ou plusieurs fichiers de données ASCII (pas des fichiers de données d’une base de
données Oracle).
En sortie, SQL*Loader alimente la base de données Oracle et génère un fichier journal (log), un fichier des rejets
(bad ­ données erronées) et un fichier des refus (discard ­ données écartées).
Pour des petits volumes, les données peuvent être directement incluses dans le fichier de contrôle.
Le fichier discard contient des enregistrements qui ont été refusés (écartés) par SQL*Loader car ils ne respectaient
pas des conditions spécifiées dans le fichier de contrôle.
Le fichier bad contient des enregistrements qui ont été rejetés soit par SQL*Loader (format de l’enregistrement non
valide par rapport à la description du fichier de contrôle), soit par Oracle (violation d’une contrainte d’intégrité, type
de données non valide, etc.).
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Les enregistrements rejetés ou refusés sont écrits tels quels dans les fichiers bad et discard qui ont donc, la même
structure que les fichiers de données utilisés en entrée ; après correction éventuelle des enregistrements, les
fichiers bad et discard peuvent être utilisés comme fichiers d’entrée.
Le fichier journal donne énormément d’informations sur le résultat du chargement :
●
date ;
●
nom des fichiers utilisés ;
●
paramètres utilisés ;
●
tables cibles et mode d’alimentation ;
●
conditions éventuelles sur les enregistrements ;
●
nombre d’enregistrements chargés ;
●
nombre d’enregistrements écartés ;
●
nombre d’enregistrements rejetés ;
●
messages d’erreurs relatifs aux rejets.
c. Les chemins du chargement
SQL*Loader peut effectuer le chargement selon deux "chemins" :
●
●
Chemin conventionnel : les données sont chargées en mémoire et insérées dans les tables par des ordres
SQL INSERT classiques ;
Chemin direct : les données sont chargées en mémoire, formatées dans des blocs qui sont écrits
directement dans la base de données.
Avec le chemin conventionnel, tous les mécanismes classiques sont appliqués (contraintes, triggers, …).
Le chemin direct est plus performant mais a les conséquences suivantes :
●
Seules les contraintes NOT NULL, PRIMARY KEY et UNIQUE sont appliquées ;
●
Les triggers INSERT ne sont pas exécutés ;
●
D’autres utilisateurs ne peuvent pas apporter de modifications aux tables pendant le chargement.
Sur un chargement important, si les caractéristiques évoquées ci­dessus sont acceptables, il faut choisir un
chargement par chemin direct.
Lors d’un chargement en chemin direct, il existe d’autres options qui permettent de faire le chargement en
mode NOLOGGING Dans ce cas, les performances sont encore améliorées.
2. Mise en œuvre
SQL*Loader s’utilise uniquement en mode ligne de commande (pas de mode interactif). Vous pouvez mettre les
paramètres sur la ligne de commande, ou les regrouper dans un fichier de paramètres dont le nom seul est passé sur
la ligne de commande :
> sqlldr USERID=system/az#78 CONTROL=balance.ctl LOG=balance.log
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
> sqlldr PARFILE=balance.par
Il y deux catégories de paramètres à ne pas confondre :
●
●
les paramètres du fichier de contrôle ;
les paramètres de la ligne de commande qui peuvent être listés dans un fichier de paramètres (paramètre de
ligne de commande PARFILE).
Certains paramètres de la ligne de commande peuvent être inclus dans le fichier de contrôle (paramètre de
fichier de contrôle OPTIONS) ou sont redondants avec des paramètres du fichier de contrôle.
Comme pour les outils d’export et d’import, le plus simple est d’utiliser un fichier de paramètres dont le nom est
spécifié sur la ligne de commande.
Les paramètres du fichier de contrôle sont essentiellement destinés à décrire la structure des enregistrements en
entrée, les tables cibles et la nature des contrôles/traitements à réaliser sur les enregistrements.
Les paramètres de la ligne de commande, ou du fichier de paramètres indiqué sur la ligne de commande, contrôlent le
fonctionnement général de l’outil.
Les principaux paramètres de la ligne de commande sont les suivants :
BAD
Nom du fichier bad (avec éventuellement un chemin complet).Par défaut, égal au nom du fichier de contrôle, mais avec
l’extension .bad
CONTROL
Nom du fichier de contrôle (avec éventuellement un chemin complet).
DATA
Nom du fichier de données à traiter (généralement plutôt indiqué dans le fichier de contrôle). Par défaut, égal au nom
du fichier de contrôle, mais avec l’extension .dat
DIRECT
TRUE : chemin direct. FALSE : chemin conventionnel (défaut).
DISCARDFILE
Nom du fichier discard (avec éventuellement un chemin complet). Par défaut, égal au nom du fichier de contrôle, mais
avec l’extension .dsc
DISCARDMAX
Nombre maximum de rejets autorisés avant l’arrêt du chargement (1 = arrêt au premier). Par défaut, pas d’arrêt.
ERRORS
Nombre d’erreurs d’insertion autorisées avant l’arrêt du chargement (50, par défaut ; 0 = aucune erreur autorisée ;
mettre un très grand nombre pour ne pas s’arrêter en cas d’erreur). Les enregistrements incriminés sont écrits dans
le fichier bad.
LOAD
Nombre maximum d’enregistrements à charger (après SKIP).
LOG
Nom du fichier journal (avec éventuellement un chemin complet). Par défaut, égal au nom du fichier de contrôle, mais
avec l’extension .log
© ENI Editions - All rights reserved - Algeria Educ
- 3-
PARFILE
Nom du fichier de paramètres (avec éventuellement, un chemin complet).
SKIP
Nombre d’enregistrements à éliminer avant de commencer le chargement (aucun, par défaut).
USERID
Paramètres d’ouverture de la session sous la forme : utilisateur[/mot_de_passe][@nom_service]
Une invite s’affiche pour saisir le mot de passe s’il est non spécifié.
Dans le fichier de contrôle, certaines directives (voir ci­dessous) permettent de spécifier des paramètres
redondants avec les paramètres de la ligne de commande. En cas de conflit, c’est le paramètre de la ligne de
commande qui l’emporte.
Exemples de fichiers de paramètres
●
Cas où toutes les informations sont dans le fichier de contrôle :
userid=system/az#78
control=balance.ctl
●
Cas où le fichier de contrôle peut s’appliquer sur des fichiers de données de diverses origines (d’où un seul
fichier de contrôle et plusieurs fichiers de paramètres) :
userid=system/az#78
control=balance.ctl
data=balance_lyon.dat
log=balance_lyon.log
bad=balance_lyon.bad
discardfile=balance_lyon.dsc
Un fichier de contrôle type a la structure suivante :
[ OPTIONS(liste d’options) ]
LOAD DATA
[ INFILE fichier | *
[ BADFILE fichier ] [ DISCARDFILE fichier ] [ DISCARDMAX valeur ] ]
[ INSERT | APPEND | REPLACE | TRUNCATE ]
INTO TABLE nom
[ INSERT | APPEND | REPLACE | TRUNCATE ]
[ WHEN condition ]
[ FIELDS TERMINATED BY ’x’ [ OPTIONALLY ENCLOSED BY ’y’ ] ]
[ TRAILING NULLCOLS ]
( colonne [ POSITION(x:y) ] [ type ] [ clause_SQL ],
…
)
[ BEGINDATA données ]
La syntaxe n’est pas complète, mais les clauses les plus usuelles sont présentées.
Les clauses doivent apparaître dans l’ordre indiqué.
Les lignes de commentaire doivent commencer par deux signes moins (­­).
OPTIONS
La clause OPTIONS permet de spécifier, dans le fichier de contrôle, les options de ligne commande suivantes :
●
- 4-
openmirrors.com
SKIP
© ENI Editions - All rights reserved - Algeria Educ
●
LOAD
●
ERRORS
●
ROWS
●
SILENT
●
DIRECT
En cas de conflit avec la ligne de commande, c’est le paramètre de la ligne de commande qui l’emporte.
Exemple
OPTIONS (SKIP=10,LOAD=900,ERRORS=100)
LOAD DATA
La clause INFILE donne l’emplacement d’un fichier de données à traiter ou est égale au caractère * si les données
sont dans le fichier de contrôle (clause BEGINDATA).
De manière optionnelle, cette clause peut spécifier un fichier bad (option BADFILE), un fichier discard (option
DISCARDFILE) et un nombre maximum de rejets autorisés avant l’arrêt du chargement (option DISCARDMAX) ; si les
paramètres équivalents de la ligne de commande ont été indiqués, ce sont ces derniers qui s’appliquent.
S’il y a plusieurs fichiers à charger en une seule session, plusieurs clauses INFILE peuvent être présentes, chaque
clause pouvant spécifier ses propres options BADFILE, DISCARDFILE et DISCARDMAX
Si le fichier de données est indiqué en paramètre de la ligne de commande (DATA), la clause est vide (mais il faut
laisser le mot clé LOAD DATA).
INSERT | APPEND | REPLACE | TRUNCATE
La clause suivante précise le mode de chargement dans les tables :
INSERT
Ajout, mais uniquement pour une table vide (erreur sinon).
APPEND
Ajout à la table (peut être vide ou non).
REPLACE
Remplace tout le contenu de la table (un ordre SQL DELETE est exécuté avant).
TRUNCATE
Remplace tout le contenu de la table (un ordre SQL TRUNCATE est exécuté avant).
INTO TABLE
La clause INTO TABLE donne le nom d’une table à charger et décrit comment effectuer le chargement dans cette table.
Si plusieurs tables sont chargées à partir d’un même fichier de données, plusieurs clauses INTO TABLE peuvent être
spécifiées.
Pour chaque table, il est possible d’indiquer les options suivantes :
INSERT | APPEND | REPLACE | TRUNCATE
Mode de l’import pour la table
WHEN
Indique une condition sur l’enregistrement pour qu’il soit effectivement chargé dans cette table.
© ENI Editions - All rights reserved - Algeria Educ
- 5-
La condition peut porter soit sur une colonne de la table cible, soit sur un champ de l’enregistrement source, défini
par la position de son caractère de début et la position de son caractère de fin sous la forme début:fin
FIELDS TERMINATED BY ’x’ [ OPTIONALLY ENCLOSED BY ’y’ ]
Pour des enregistrements de longueur variable (avec séparateur), indique comment sont délimités les champs :
TERMINATED BY ’x’ : caractère séparateur des enregistrements (typiquement, une virgule, un point­virgule, etc.).
OPTIONALLY ENCLOSED BY ’y’ : caractère optionnel pouvant entourer les enregistrements (typiquement, des
apostrophes, des guillemets, etc.).
TRAILING NULLCOLS
Les colonnes non présentes à la fin de l’enregistrement sont mises à NULL (si l’option est absente et que des
colonnes vides existent à la fin, l’enregistrement est rejeté).
colonne [ POSITION(x:y) ] [ type ] [ clause_SQL ]
Liste des colonnes à alimenter dans la table :
colonne : le nom de la colonne cible.
POSITION(x:y) ; position du champ correspondant dans l’enregistrement source (cas d’un enregistrement de
longueur fixe). Pour des enregistrements avec séparateur, la correspondance colonne/enregistrement est
positionnelle (1ère colonne de la liste = 1er enregistrement, …)
type : type de données (en cas d’ambiguïté).
clause_SQL : clause SQL à appliquer. Pour référencer une colonne X dans la clause SQL, utiliser la syntaxe :X
(caractère deux­points devant le nom de la colonne).Il existe d’autres options sur la spécification des colonnes.
BEGINDATA
La clause BEGINDATA marque le début des données si celles­ci sont incluses dans le fichier de contrôle (INFILE *).
3. Exemples
a. Préambule
Les différents exemples sont présentés avec des données incluses (INFILE * + BEGINDATA) pour mieux visualiser la
correspondance entre les données et les paramètres du fichier de contrôle.
Ces exemples sont très simples à adapter au chargement d’un fichier externe :
●
copier les données, sans le BEGINDATA, dans un fichier ;
●
mettre le nom du fichier dans la clause INFILE (à la place du caractère *) ;
●
supprimer la clause BEGINDATA
Sur chaque exemple, un chargement par ajout à la table existante est utilisé (APPEND).
Par ailleurs, nous supposons l’existence des tables suivantes :
●
tables des adhérents
SQL> DESC adherent
Name
Null?
Type
----------------------------------------- -------- -------------NUMERO
NUMBER(6)
- 6-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
NOM
PRENOM
SEXE
DATE_NAISSANCE
●
VARCHAR2(40)
VARCHAR2(40)
CHAR(1)
DATE
tables des adhérents masculins (pas de colonne SEXE)
SQL> DESC adherent_m
Name
Null?
----------------------------------------- -------NUMERO
NOM
PRENOM
DATE_NAISSANCE
●
Type
-------------NUMBER(6)
VARCHAR2(40)
VARCHAR2(40)
DATE
tables des adhérentes féminines (pas de colonne SEXE, ni de colonne DATE_NAISSANCE)
SQL> DESC adherent_f
Name
Null?
----------------------------------------- -------NUMERO
NOM
PRENOM
Type
-------------NUMBER(6)
VARCHAR2(40)
VARCHAR2(40)
Enfin, une séquence S_ADHERENT permet d’alimenter les numéros d’adhérent.
b. Longueur variable
LOAD DATA
INFILE *
INTO TABLE adherent
APPEND
FIELDS TERMINATED BY ’,’ OPTIONALLY ENCLOSED BY ’"’
TRAILING NULLCOLS
(
prenom,
nom,
sexe,
date_naissance
"TO_DATE(:date_naissance,’YYYYMMDD’)",
numero
"s_adherent.NEXTVAL"
)
BEGINDATA
Olivier,HEURTEL,M,19660826
Valérie,MARTIN,F
Jean,"PEYRAC (de)",M,19631204
Pour cet exemple, les enregistrements ont une longueur variable, avec séparateur.
Spécifications des données en entrée :
●
●
●
●
●
Les champs sont délimités par une virgule : clause TERMINATED BY ’,’ ;
Ils peuvent éventuellement entre être entourés de guillemets (c’est le cas du nom dans la troisième
ligne) : clause OPTIONALLY ENCLOSED BY ’"’;
Ils peuvent être manquants en fin de ligne (pas de date de naissance sur la deuxième ligne) ; dans ce cas
mettre un NULL : clause TRAILING NULLCOLS ;
La date de naissance est fournie sous forme de chaîne au format YYYYMMDD mais doit être stockée dans une
colonne de type DATE : clause SQL "TO_DATE(:date_ naissance,’YYYYMMDD’)" ;
Le numéro d’adhérent n’est pas fourni ; il doit être calculé à l’aide d’une séquence :
"s_adherent.NEXTVAL"
© ENI Editions - All rights reserved - Algeria Educ
clause SQL
- 7-
Sur cet exemple, la correspondance entre les champs et les colonnes est positionnelle ; les colonnes qui ne sont
pas alimentées par un champ de l’enregistrement doivent forcément être spécifiées en dernier dans la liste des
colonnes.
c. Longueur fixe
LOAD DATA
INFILE *
INTO TABLE adherent
APPEND
TRAILING NULLCOLS
(
numero
"s_adherent.NEXTVAL",
prenom
POSITION(01:10),
nom
POSITION(11:22),
sexe
POSITION(23:23),
date_naissance POSITION(24:31) "TO_DATE(:date_naissance,’YYYYMMDD’)"
)
BEGINDATA
Olivier
HEURTEL
M19660826
Valérie
MARTIN
F
Jean
PEYRAC (de) M19631204
Pour cet exemple, les enregistrements ont une longueur fixe. Les autres spécifications sont inchangées.
Avec des enregistrements de longueur fixe, la correspondance entre les champs et les colonnes est définie par la
clause POSITION ; les colonnes, qui ne sont pas alimentées par un champ de l’enregistrement, peuvent être
spécifiées n’importe où dans la liste des colonnes.
d. Longueur fixe avec élimination d’enregistrements
LOAD DATA
INFILE *
INTO TABLE adherent
APPEND
WHEN (sexe = ’M’)
TRAILING NULLCOLS
(
numero
"s_adherent.NEXTVAL",
prenom
POSITION(01:10),
nom
POSITION(11:22),
sexe
POSITION(23:23),
date_naissance POSITION(24:31) "TO_DATE(:date_naissance,’YYYYMMDD’)"
)
BEGINDATA
Olivier
HEURTEL
M19660826
Valérie
MARTIN
F
Jean
PEYRAC (de) M19631204
Pour cet exemple, les enregistrements ont une longueur fixe mais les adhérents de sexe féminin ne doivent pas
être chargés. Les autres spécifications sont inchangées.
Une clause WHEN (sexe = ’M’) est ajoutée pour spécifier les enregistrements à conserver.
e. Chargement dans deux tables
LOAD DATA
INFILE *
INTO TABLE adherent_m
APPEND
WHEN (sexe = ’M’)
TRAILING NULLCOLS
(
numero
"s_adherent.NEXTVAL",
prenom
POSITION(01:10),
nom
POSITION(11:22),
- 8-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
sexe
F I L L E R POSITION(23:23),
date_naissance
POSITION(24:31) "TO_DATE(:date_naissance,’YYYYMMDD’)"
)
INTO TABLE adherent_f
APPEND
WHEN (sexe = ’F’)
TRAILING NULLCOLS
(
numero
"s_adherent.NEXTVAL",
prenom
POSITION(01:10),
nom
POSITION(11:22),
sexe
F I L L E R POSITION(23:23)
)
BEGINDATA
Olivier
HEURTEL
M19660826
Valérie
MARTIN
F
Jean
PEYRAC (de) M19631204
Pour cet exemple, les enregistrements ont une longueur fixe mais les adhérents doivent être répartis entre deux
tables en fonction de leur sexe. Les deux tables n’ont pas de colonne SEXE et la table des adhérents de sexe
féminin, pas de colonne DATE_NAISSANCE non plus. Les autres spécifications sont inchangées.
Le fichier de contrôle utilise deux clauses INTO TABLE pour spécifier comment alimenter les deux tables.
Dans chaque clause INTO TABLE, une clause WHEN (sexe= ’X’) permet d’indiquer si l’enregistrement courant doit
être chargé dans la table ou non. Par ailleurs, chaque clause INTO TABLE a sa propre liste de colonnes.
Comme les tables n’ont pas de colonne SEXE, il est possible de spécifier une colonne dans la liste des colonnes avec
la propriété FILLER ("remplissage"). Cette "colonne" peut ensuite être manipulée comme si c’était une colonne de la
table (utilisée dans une clause WHEN, dans une clause SQL) mais elle n’est pas chargée dans la table.
Cette technique peut aussi être utilisée avec des enregistrements de longueur variable (avec séparateur), lorsqu’un
champ de l’enregistrement ne doit pas être chargé dans une colonne de la table.
© ENI Editions - All rights reserved - Algeria Educ
- 9-
Extraire des données dans un fichier texte
1. En SQL
En SQL, il suffit d’écrire un script avec la requête SELECT souhaitée et de rediriger la sortie vers un fichier (SPOOL). En
complément, il est nécessaire de passer un certain nombre de commandes SQL*Plus pour supprimer les affichages
jugés indésirables (titres des colonnes, nombre de lignes sélectionnées, etc.).
Exemple de script SQL : export avec des enregistrements de longueur fixe
-- un peu de configuration de l’environnement SQL*Plus
-- pas d’echo des requêtes
SET ECHO OFF
-- masquer les titres de colonnes
SET HEADING OFF
-- masquer l’affichage du nombre de lignes dans le résultat
SET FEEDBACK OFF
-- dimensionner la largeur de la ligne à 1000 caractères
-- (pas utile ici, mais c’est à titre d’exemple)
SET LINESIZE 1000
-- supprimer le saut de ligne à chaque changement de page
SET NEWPAGE NONE
-- suppression des espaces en fin de ligne
SET TRIMSPOOL ON
-- pas d’affichage à l’écran (plus rapide)
SET TERMOUT OFF
-- rediriger la sortie vers un fichier .txt
SPOOL adherent.txt
-- faire une requête SELECT qui concatène les différentes colonnes et
-- utilise si besoin la fonction SQL RPAD pour ajouter des espaces aux
-- colonnes de longueur variable et les rendre ainsi de longueur fixe
SELECT
-- première méthode avec largeurs fixes
RPAD(prenom,10,’ ’)
||
RPAD(nom,12,’ ’)
||
NVL(sexe,’X’)
||
TO_CHAR(date_naissance,’YYYYMMDD’)
ligne
FROM
adherent
/
-- fermer le fichier d’export
SPOOL OFF
-- remette la configuration habituelle de l’environnement SQL*Plus
SET HEADING ON
SET FEEDBACK ON
SET LINESIZE 80
SET NEWPAGE 1
SET TERMOUT ON
Pour faire un export avec des enregistrements de longueur variable, vous pouvez utiliser la requête suivante :
-- faire une requête SELECT qui concatène les différentes colonnes en
-- intercalant des virgules comme séparateur
SELECT
-- deuxième méthode avec séparateur
prenom
|| ’,’ || nom
|| ’,’ || NVL(sexe,’X’)
|| ’,’ || TO_CHAR(date_naissance,’YYYYMMDD’)
ligne
FROM
adherent
/
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
2. En PL/SQL
En PL/SQL, il suffit d’écrire un bloc qui sélectionne les données via un curseur et écrit le résultat dans un fichier avec
le package UTL_FILE
Exemple
DECLARE
-- extraire les données à l’aide d’un curseur
CURSOR cur_adherent IS
SELECT * FROM adherent;
-- pointeur de fichier d’export
v_fichier
utl_file.file_type;
-- buffer pour l’écriture
v_ligne
VARCHAR2(1023);
BEGIN
-- ouvrir le fichier d’export (le répertoire doit être spécifié
-- par l’intermédiaire d’un objet DIRECTORY - bien mettre le
-- nom de l’objet DIRECTORY en majuscules)
v_fichier := utl_file.fopen(’DIR_PUMP’,’adhérents.txt’,’w’);
-- boucler sur le curseur
FOR rec_adherent IN cur_adherent LOOP
-- construire la ligne à exporter
-- (ici, enregistrement avec séparateur)
v_ligne
:=
rec_adherent.prenom
|| ’,’ || rec_adherent.nom
|| ’,’ || NVL(rec_adherent.sexe,’X’)
|| ’,’ || TO_CHAR(rec_adherent.date_naissance,’YYYYMMDD’);
-- écrire la ligne dans le fichier
utl_file.put_line(v_fichier,v_ligne);
END LOOP;
-- fermer le fichier
utl_file.fclose(v_fichier);
END;
/
- 2-
© ENI Editions - All rights reserved - Algeria Educ
Utiliser le Database Control
1. Export
Sur la page d’accueil, cliquez sur le lien Mouvement de données puis sur le lien Exporter vers des fichiers d’export
(cadre Transférer des données de ligne) pour accéder à la page permettant de réaliser des exports.
La première page permet de sélectionner le niveau de l’export et de saisir les informations d’identification et de
connexion à l’hôte. Les pages proposées par la suite dépendent du niveau sélectionné.
Par exemple, dans le cas d’un export de niveau Schémas, l’assistant vous propose successivement :
●
de sélectionner un ou plusieurs schémas à exporter ;
●
de définir les options de l’export (degré de parallélisme, fichier journal, contenu de l’export, etc.) ;
●
de définir le nom et l’emplacement du fichier d’export ;
●
de programmer le travail ;
●
de soumettre le travail.
2. Import
Sur la page d’accueil, cliquez sur le lien Mouvement de données puis sur le lien Import à partir de fichiers d’export
(cadre Transférer des données de ligne) pour accéder à la page permettant de réaliser des imports à partir d’un
fichier.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Cette page permet d’abord d’indiquer si le fichier d’export provient d’une version 10g ou supérieure ou d’une version
antérieure. En fonction de la réponse, l’assistant utilisera l’outil Data Pump Import ou l’ancien outil Import ; les écrans
proposés par l’assistant sont différents.
Si vous effectuez un import à partir d’un export Data Pump, les écrans proposés par l’assistant sont très proches de
ceux proposés pour l’export.
Pour effectuer un import directement à partir d’une base de données, vous pouvez cliquer sur le lien Import depuis la
base (cadre Transférer des données de ligne de l’onglet Mouvement de données).
3. SQL*Loader
Sur la page d’accueil, cliquez sur le lien Mouvement de données puis sur le lien Charger des données à partir de
fichiers utilisateur (cadre Transférer des données de ligne) pour accéder à la page permettant de charger des
données avec SQL*Loader :
La première page permet d’indiquer si l’assistant doit générer le fichier de contrôle ou utiliser un fichier de contrôle
existant, et de saisir les informations d’identification et de connexion à l’hôte. Les pages proposées par la suite
dépendent de l’option choisie pour le fichier de contrôle.
- 2-
© ENI Editions - All rights reserved - Algeria Educ
Si le fichier de contrôle est déjà défini, l’assistant va simplement permettre de définir un travail de chargement avec
ces différents paramètres (emplacement des fichiers de données, méthode de chargement, etc.).
Si le fichier de contrôle n’existe pas, l’assistant va vous aider à construire le fichier de contrôle à l’aide du fichier de
données à charger. Cette fonctionnalité est très intéressante car la partie complexe de l’utilisation de SQL*Loader
est justement la création du fichier de contrôle.
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
- 3-
L’administrateur de base de données
1. Principales tâches
Les principales tâches de l’administrateur de base de données (DBA<) sont les suivantes :
●
installation des produits ;
●
création/démarrage/arrêt des bases de données ;
●
gestion des structures de stockage ;
●
gestion des utilisateurs (et de leurs droits) ;
●
sauvegarde/restauration.
2. Comptes Oracle d’administration
Après création, une base de données Oracle contient toujours deux comptes ayant les privilèges d’administrateur :
●
SYS (mot de passe par défaut : change_on_install) ;
●
SYSTEM(mot de passe par défaut : manager).
SYS est le propriétaire du dictionnaire de données ; SYSTEM peut être propriétaire de tables complémentaires utilisées
par les outils Oracle.
Depuis Oracle9i Release 2, ces mots de passe par défaut peuvent être changés lors de la création de la base de
données.
Ces comptes peuvent être utilisés indifféremment pour l’administration courante (gestion des utilisateurs, du
stockage, etc.) uniquement lorsque la base est démarrée.
Un privilège supplémentaire particulier (SYSDBAou<SYSOPER) est nécessaire pour certaines opérations (démarrage,
arrêt, etc.). De plus, l’activation de ce privilège SYSDBA ou SYSOPER nécessite un mécanisme d’authentification
particulier, puisque la base de données peut ne pas être disponible. Cette authentification s’effectue soit par le
système d’exploitation, soit par un fichier de mot de passe.
Dans le chapitre Gestion des utilisateurs et de leurs droits, nous verrons que la notion de "DBA" correspond à un rôle
(ensemble de privilèges regroupés sous un nom) qui peut être attribué à un compte utilisateur.
3. Identification privilégiée SYSDBA et SYSOPER
a. Par le système d’exploitation
Pour utiliser l’authentification par le système d’exploitation, vous devez mettre l’utilisateur souhaité du système
d’exploitation dans un groupe de droits spécial. Sur plate­forme Unix, ce groupe s’appelle généralementdba (ou
oper) ; sur plate­forme Windows, ce groupe s’appelle ORA_DBA (ou ORA_OPER).
Ensuite, vous pouvez vous connecter au système d’exploitation avec l’utilisateur en question, lancer l’outil
d’administration et vous connecter, sans nom d’utilisateur et sans mot de passe, avec le privilège SYSDBA (ou
SYSOPER).
Syntaxe (dans SQL*Plus)
CONNECT / AS { SYSDBA | SYSOPER }
Exemple :
© ENI Editions - All rights reserved - Algeria Educ
- 1-
CONNECT / AS SYSDBA
Sur plate­forme Unix, le groupe doit être créé lors de l’installation d’Oracle ; il est possible de lui attribuer un autre
nom que dba et/ou de définir un autre groupe pour séparer les privilèges SYSDBA et SYSOPER.
Sur plate­forme Windows, le groupe ORA_DBA est automatiquement créé et seul le privilège SYSDBA est disponible. Il
est possible par la suite de créer un autre groupe ORA_OPER pour le privilège SYSOPER et/ou de créer des groupes
ORA_<SID>_OPER|DBA spécifiques à certaines instances (<SID> désignant le nom de l’instance).
Sur plate­forme Windows, pour que ce mode d’authentification soit autorisé, il faut qu’il y ait la ligne suivante dans
le fichier sqlnet.ora(répertoire %ORACLE_HOME%\network\ admin ­ voir le Chapitre Oracle Net pour la configuration
Oracle Net) :
SQLNET.AUTHENTICATION_SERVICES= (NTS)
Les outils d’administration seront présentés plus en détail dans le chapitre Les outils d’administration.
b. Par un fichier de mot de passe
Pour utiliser l’authentification par un fichier de mot de passe, vous devez mettre le paramètre d’initialisation
REMOTE_LOGIN_PASSWORDFILE à EXCLUSIVE (défaut) ou SHARED et créer un fichier de mot de passe à l’aide de
l’utilitaireorapwd fourni par Oracle.
Exemple :
C:\ > orapwd file=D:\Oracle\Product\10.1.0\Db_1\database\pwdHERMES.ora
password=dur_a_trouver entries=4
Ensuite, vous pouvez vous connecter au système d’exploitation avec n’importe quel utilisateur, lancer l’outil
d’administration et vous connecter, en tant que SYS, à l’aide du mot de passe défini précédemment, avec le privilège
SYSDBA (ou SYSOPER).
Syntaxe (dans SQL*Plus)
CONNECT sys/mot_de_passe AS { SYSDBA | SYSOPER }
Exemple :
CONNECT sys/dur_a_trouver AS SYSDBA
Avec un fichier de mot de passe, par défaut, seul le compte SYS a le droit de se connecter avec le privilège SYSDBA ou
SYSOPER. Si le paramètre REMOTE_LOGIN_PASSWORDFILE est égal à EXCLUSIVE, il est possible de donner le privilège
SYSDBA ou SYSOPER à d’autres utilisateurs (voir le chapitre Gestion des utilisateurs et de leurs droits). Si le paramètre
REMOTE_LOGIN_PASSWORD FILE est égal à SHARED, seul le compte SYS peut utiliser les privilèges SYSDBA ou SYSOPER.
Ce mécanisme est présenté plus en détail dans le chapitre Création d’une nouvelle base de données.
c. Remarques
Le privilège SYSDBA permet toutes les opérations "lourdes" d’administration, notamment, la création d’une base de
données, les arrêts et les démarrages, la création d’un fichier de paramètre serveur, les récupérations, etc. Il donne
un accès à toutes les données de la base de données. La connexion s’effectue implicitement dans le schéma de SYS.
Le privilège SYSOPER donne à peu près les mêmes droits que SYSDBA, à l’exception notable de la création de la base
de données. Par contre, l’accès est restreint aux seules données du dictionnaire de données. La connexion
s’effectue implicitement dans le schéma PUBLIC.
Avec une authentification par le système d’exploitation, il est possible de se connecter en tapant une commande du
type CONNECT nimportequoi/nimportequoi AS SYSDBA, car le nom et le mot de passe ne sont en fait pas utilisés.
Ce fonctionnement est un peu troublant, notamment si un vrai compte Oracle est utilisé, d’autant plus que la
session est ouverte dans le schéma SYS :
Exemple :
SQL> CONNECT nimportequoi/nimportequoi AS SYSDBA
Connecté.
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
SQL> SHOW USER
USER est "SYS"
SQL> CONNECT scott/tiger AS SYSDBA
Connecté.
SQL> SHOW USER
USER est "SYS"
SQL> CONNECT nimportequoi/nimportequoi
ERREUR :
ORA-01017: nom d’utilisateur/mot de passe non valide; connexion refusée
Attention : vous n’êtes plus connecté à ORACLE.
SQL> CONNECT scott/tiger
Connecté.
SQL> SHOW USER
USER est "SCOTT"
Depuis la version 9, la connexion sous le compte SYS sans le privilège SYSDBA n’est plus possible.
Dans le cas de l’utilisation d’un fichier de mot de passe, si vous modifiez le mot de passe de SYS par un
ordre SQL (voir le Chapitre Gestion des utilisateurs et de leurs droits), la modification est répercutée dans
le fichier de mot de passe.
L’administration courante ne nécessite pas le privilège SYSDBA ou SYSOPER ; elle s’effectue généralement avec le
compte SYSTEM :
●
gestion des structures de stockage ;
●
gestion des utilisateurs ;
●
gestion des schémas.
Le privilège SYSDBA est, par contre, nécessaire pour :
●
l’arrêt et le démarrage de la base de données ;
●
la création d’une base de données ;
●
les opérations de récupération d’une base de données.
Dans les anciennes versions d’Oracle, il était possible d’utiliser un CONNECT INTERNAL pour obtenir ces privilèges
particuliers. Cette connexion n’est plus supportée depuis la version 9. À la place, il faut utiliser une connexion AS
SYSDBA (équivalente en terme de droits).
L’authentification SYSDBA ou SYSOPER par le système d’exploitation n’est pas autorisée pour les connexions à travers
le réseau (sauf utilisation d’un réseau sécurisé) ; dans ce cas, il faut utiliser une authentification par un fichier de
mot de passe.
Pour l’administration locale de la base de données (directement sur la console du serveur ou en émulation de
terminal), vous pouvez indifféremment utiliser une authentification par le système d’exploitation ou par fichier de
mot de passe. Dans le premier cas, vous devez vous assurer que les groupes et comptes correspondants du
système d’exploitation sont bien protégés. Dans le deuxième cas, vous devez vous assurer que le fichier de mot de
passe et l’utilitaire orapwd sont bien protégés.
4. Autres comptes Oracle
Lors de la création d’une base de données, d’autres comptes Oracle peuvent être créés, notamment SYSMAN et
DBSNMP.
SYSMAN (mot de passe par défaut CHANGE_ON_INSTALL) est un compte qui peut être utilisé pour effectuer des tâches
d’administration dans Oracle Enterprise Manager. SYSMAN est un compte DBA.
DBSNMP (mot de passe par défaut DBSNMP) est un compte utilisé par l’agent d’Oracle Enterprise Manager pour superviser
et gérer une base de données.
De nombreux autres comptes "administratifs" peuvent être créés selon les options installées dans la base de
© ENI Editions - All rights reserved - Algeria Educ
- 3-
données.
- 4-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
Le dictionnaire de données
1. Présentation
Le dictionnaire de données est un ensemble de tables et de vues qui donnent des informations sur le contenu d’une
base de données :
●
les structures de stockage ;
●
les utilisateurs et les droits ;
●
les objets (tables, vues, index, procédures, fonctions, etc.).
●
etc.
Le dictionnaire de données appartient à SYS et est stocké dans le tablespace SYSTEM. Il est créé lors de la création de
la base de données et mis à jour automatiquement par Oracle lorsque des ordres SQL DDL (Data Definition Language)
sont exécutés (CREATE, ALTER, DROP).
Pour l’utiliser, il suffit de l’interroger grâce à des requêtes SELECT. Sauf exception, toutes les informations sont
stockées en majuscules dans le dictionnaire de données ; tenez en compte dans l’écriture de vos clauses WHERE !
Le dictionnaire de données est chargé en mémoire dans la partie Dictionary Cache de la Shared Pool et est utilisé en
interne par Oracle pour traiter les requêtes.
Le dictionnaire de données est créé lors de la création de la base. D’un point de vue pratique, les tables proprement
dites du dictionnaire de données ne sont pas documentées par Oracle et donc difficiles à utiliser. Par contre, grâce à
des scripts fournis par Oracle, il est possible de créer des vues (et des synonymes publics) qui, elles, sont
documentées et permettent effectivement d’exploiter le dictionnaire de données ; cette étape de la création d’une
base sera présentée dans le chapitre Création d’une nouvelle base de données.
Il y a deux grands groupes de tables/vues dans le dictionnaire de données :
●
les tables et vues statiques ;
●
les tables et vues dynamiques de performance.
Les tables et vues statiques sont basées sur de vraies tables stockées dans le tablespace SYSTEM. Elles sont
accessibles uniquement quand la base de données est ouverte "complètement". Les tables et vues dynamiques de
performance ne sont en fait pas basées sur de vraies tables mais sur des informations en mémoire ou extraites du
fichier de contrôle. Elles s’interrogent néanmoins comme de vraies tables/vues et donnent des informations sur le
fonctionnement de la base de données, notamment sur les performances. Pour la plupart, elles sont accessibles
même lorsque la base de données n’est pas complètement ouverte.
La notion de "niveau d’ouverture" d’une base de données sera présentée dans le chapitre Démarrage et
arrêt.
2. Les vues statiques
Il y a trois grandes catégories de vues statiques caractérisées par leur préfixe :
●
●
●
USER_% : informations sur les objets qui appartiennent à l’utilisateur ;
ALL_% : informations sur les objets auxquels l’utilisateur a accès (les siens et ceux sur lesquels il a reçu des
droits) ;
DBA_% :informations sur tous les objets de la base de données.
Derrière le préfixe, le reste du nom de la vue est représentatif de l’information accessible.
© ENI Editions - All rights reserved - Algeria Educ
- 1-
Ces trois catégories de vues permettent de filtrer les informations du dictionnaire de données par rapport aux droits
des utilisateurs. Les informations accessibles dans les vues USER_ forment un sous­ensemble des informations
accessibles dans les vues ALL_ qui elles­mêmes forment un sous­ensemble des informations accessibles dans les
vues DBA_.
Un utilisateur "lambda" a le droit d’interroger les vues USER_ et ALL_ et il n’y voit que les informations auxquelles il a
droit.
Certaines vues de la catégorie DBA_ peuvent ne pas avoir d’équivalent dans les catégories USER_ ou ALL_. Exemple :
DBA_DATA_FILES.
Dans les vues ALL_ et DBA_ concernant les objets des schémas, la colonne OWNER permet de connaître le propriétaire
de l’objet.
Les vues suivantes sont particulièrement utiles pour la description d’un schéma :
%_OBJECTS
%_CONSTRAINTS
%_TABLES
%_CONS_COLUMNS
%_TAB_COLUMNS
%_VIEWS
%_INDEXES
%_SYNONYMS
%_IND_COLUMNS
%_SEQUENCES
%_TRIGGERS
%_SOURCE
Dans les différents chapitres, les principales vues du dictionnaire de données relatives au sujet traité seront
présentées.
Oracle propose des synonymes sur certaines vues :
Synonyme
Vue correspondante
COLS
USER_TAB_COLUMNS
DICT
DICTIONARY
IND
USER_INDEXES
OBJ
USER_OBJECTS
SEQ
USER_SEQUENCES
SYN
USER_SYNONYMS
TABS
USER_TABLES
Par ailleurs, les vues DICTIONARY et DICT_COLUMNS donnent la description de toutes les tables et vues du dictionnaire
de données.
La vue DICTIONARY est très pratique pour retrouver le nom des vues qui traitent d’un sujet donné. En effet, le nom de
la vue contient une chaîne de caractères représentative de l’information présentée par la vue (TAB ou TABLE pour les
tables, IND ou INDEX pour les index, COL ou COLUMN pour les colonnes, etc.) ; il suffit donc de faire une recherche à
l’aide de l’opérateur LIKE.
Exemple
SQL> SELECT * FROM dictionary WHERE table_name LIKE ’USER%SEQ%’;
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
TABLE_NAME
COMMENTS
--------------- -------------------------------------------------USER_SEQUENCES Description of the user’s own SEQUENCEs
SQL> SELECT column_name,comments FROM dict_columns
2 WHERE table_name = ’USER_SEQUENCES’;
COLUMN_NAME
COMMENTS
-------------------- --------------------------------------------SEQUENCE_NAME
SEQUENCE name
MIN_VALUE
Minimum value of the sequence
MAX_VALUE
Maximum value of the sequence
INCREMENT_BY
Value by which sequence is incremented
CYCLE_FLAG
Does sequence wrap around on reaching limit?
ORDER_FLAG
Are sequence numbers generated in order?
CACHE_SIZE
Number of sequence numbers to cache
LAST_NUMBER
Last sequence number written to disk
3. Les vues dynamiques de performance (v$)
Les vues dynamiques de performance sont préfixées par V$. Derrière le préfixe, le reste du nom de la vue est
représentatif de l’information accessible.
Sauf exception, ces vues ne sont accessibles qu’aux DBA.
Les vues relatives aux sujets abordés dans ce chapitre sont les suivantes :
V$I[]NSTANCE
Informations sur l’instance
V$DATABASE
Informations sur la base de données
V$S[]GA et V$S[]GAINFO
Informations sur la SGA
V$PARAMETER
Informations sur les paramètres.
La vue V$PARAMETER est une des rares vues du dictionnaire de données qui stocke des informations en
minuscules.
Les vues dynamiques de performance sont aussi décrites dans les vues DICTIONARY et DICT_COLUMNS. En complément,
les vues V$FIXED_TABLEet V$FIXED_VIEW_DEFINITION donnent des informations sur la définition interne des vues
dynamiques.
Exemple
SQL> SELECT name,value FROM v$parameter WHERE name LIKE ’%block%’;
NAME
VALUE
------------------------------ -------------------db_block_buffers
0
db_block_checksum
TYPICAL
db_block_size
8192
db_file_multiblock_read_count 95
db_block_checking
FALSE
Dans les différents chapitres, les principales vues dynamiques relatives au sujet traité seront présentées.
© ENI Editions - All rights reserved - Algeria Educ
- 3-