124 81 15MB
French Pages 466 Year 2008
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 plateforme Windows mais sont un peu plus avancées pour les autres platesformes. Dans tous les cas, il est impératif de se référer à la documentation Oracle spécifique à la plateforme : ●
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 ;
●
postinstallation : terminer l’installation et configurer certains composants Oracle.
Sur plateforme 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 plateforme 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 platesformes 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 (plateforme 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 postinstallation 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 plateforme 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 plateforme 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 ciaprè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 plateforme (voir la documentation "Oracle® Database Installation Guide" de votre plateforme). 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 sousré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 plateforme 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 plateforme 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 plateforme 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 plateforme 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 plateforme 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 sousré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 sousré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 plateforme 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 plateforme 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 plateforme Windows Server 2003 Entreprise Edition. L’installation sur les autres platesformes 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 plateforme 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 plateforme 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 (reportezvous au manuel d’installation de votre plateforme). 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 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 Plateforme Windows Sur plateforme 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.
Plateforme Unix ou Linux Sur plateforme 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 plateforme 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 plateforme et la documentation de votre système d’exploitation sur les processus de démarrage et d’arrêt). Connectezvous 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/) 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é cidessus 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, reportezvous à la documentation Oracle spécifique à votre plateforme ●
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 plateforme (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 plateforme à 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 plateforme Linux ou Unix) ;
●
désignation de l’emplacement des fichiers (Oracle Home) ;
●
choix d’un type d’installation (voir cidessous) ;
●
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 plateforme). Administrateur : installe la quasitotalité 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 plateforme 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 plateforme Windows et LD_LIBRARY_PATH sur plateforme 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 plateforme Windows et un processus sur plateforme 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 plateforme Windows ou script shell netmgr sur plateforme 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 (plateforme Unix ou Linux) ou %ORACLE_HOME%\network\admin (plateforme 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///trace (plateforme Unix ou Linux) ou %ORACLE_BASE% \diag\tnslsnr\//trace (plateforme 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 = ) (DESCRIPTION (ADDRESS = )
= (PROTOCOL = IPC)(KEY = EXTPROC1521)) = (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 (OracleTNSListener) sur plateforme Windows et par un processus (tnslsnr) sur plateforme Unix ou Linux. Le processus d’écoute s’administre grâce à l’utilitaire lsnrctl, disponible sur toutes les platesformes. 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 plateforme 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 plateforme 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 , 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 plateforme Windows, le processus d’écoute peut être démarré automatiquement lors du démarrage du système, en positionnant le service associé (OracleTNSListener) en démarrage automatique. Sur plateforme 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 (plateforme Unix ou Linux) ou %ORACLE_HOME%\network\admin (plateforme 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 plateforme Windows ou script shell netmgr sur plateforme 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_ 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 plateforme 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 ciaprès) ou être définis dans une variable d’environnement : ●
TWO_TASK sur plateforme Linux ou Unix ;
●
LOCAL sur plateforme 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, reportezvous à 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 sqlplus sqlplus sqlplus
/nolog system/xy$78@orcl @info.sql "/ 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 plateforme 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 plateforme 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 plateforme Windows, Oracle SQL Developer peut être lancé par le menu Démarrer Programmes Oracle nom_oracle_home Développement d’applications SQL Developer. Sur plateforme Unix ou Linux, Oracle SQL Developer peut être lancé à l’aide du $ORACLE_HOME/sqldeveloper/sqldeveloper.sh. L’application nécessite un environnement graphique.
shell
script
Sur plateforme 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 (plateforme Windows) ou $ORACLE_HOME/serveur_sid (plateforme Linux) %ORACLE_HOME%\oc4j\j2ee\OC4J_DBConsole_serveur_sid (plateforme $ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_serveur_sid (plateforme 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 plateforme Windows, le Database Control peut être démarré automatiquement lors du démarrage du système en positionnant le service associé (OracleDBConsole) en démarrage automatique. Sur plateforme 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 plateforme 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 cidessus, 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 cellesci 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 ciaprè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 sousré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 sousré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 ¦ +--- ¦ ¦ +--- ¦ ¦ +---alert ¦ ¦ +---incident ¦ ¦ +---trace ¦ ¦ +---...
© ENI Editions - All rights reserved - Algeria Educ
- 1-
¦ +---... +---tnslsnr Le répertoire diag contient un sousré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 sousrépertoire par base de données qui, luimême, contient un sousré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 sousré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_.log ; il se trouve dans le sousré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èreplan est de la forme __.trc. Le nom des fichiers de trace des processus serveur est de la forme _ora_.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 cidessus, 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 plateforme Windows car l’éditeur par défaut est vi qui n’existe pas (en standard) sur cette plateforme. 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 plateforme 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 ----------------------------ORIGINATING_TIMESTAMP NORMALIZED_TIMESTAMP ORGANIZATION_ID COMPONENT_ID HOST_ID HOST_ADDRESS MESSAGE_TYPE MESSAGE_LEVEL MESSAGE_ID MESSAGE_GROUP CLIENT_ID MODULE_ID PROCESS_ID THREAD_ID USER_ID INSTANCE_ID DETAILED_LOCATION UPSTREAM_COMP_ID DOWNSTREAM_COMP_ID EXECUTION_CONTEXT_ID EXECUTION_CONTEXT_SEQUENCE ERROR_INSTANCE_ID ERROR_INSTANCE_SEQUENCE MESSAGE_TsEXT MESSAGE_ARGUMENTS SUPPLEMENTAL_ATTRIBUTES SUPPLEMENTAL_DETAILS PARTITION RECORD_ID FILENAME PROBLEM_KEY VERSION
●
Type NULL? --------------- ----------timestamp timestamp text(65) text(65) text(65) text(17) number number text(65) text(65) text(65) text(65) text(33) text(65) text(65) text(65) text(161) text(101) text(101) text(101) number number number text(2049) text(129) text(129) text(129) number number text(513) text(65) 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èreplan 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.ora et spfile.ora. L’emplacement par défaut de ces deux fichiers dépend de la plateforme :
© 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 sousré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.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’ Si la plateforme 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 plateforme, dans l’ordre, un fichier : ●
spfile.ora
●
spfile.ora
●
init.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 connectezvous 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 ●
Plateforme Windows : C:\>set ORACLE_SID=ORCL C:\>sqlplus /nolog SQL> CONNECT / AS SYSDBA
- 2-
openmirrors.com
© ENI Editions - All rights reserved - Algeria Educ
●
Plateforme Linux : $ .oraenv 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èreplan 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 ceuxci 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 ellemê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 connectezvous 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 cidessus 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 ouvrezle à 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 plateforme Unix ou Linux a. Automatisation Sur plateforme 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 : ::{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 plateforme. 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 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) 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) Connectezvous 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) Connectezvous 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, reconnectezvous (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 plateforme Windows, le service associé à l’instance (OracleService) 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, connectezvous 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 plateforme Windows. kill des processus sur plateforme 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 (plateforme Windows) ou créer le fichier de mot de passe pour l’identification SYSDBA (plateforme 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 (plateforme 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 luimê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, celuici é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.ora (avec une inclusion du fichier init.ora) à l’emplacement par défaut de la plateforme (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. Reportezvous à 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éesoradim -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 (plateforme Unix/Linux) Sur plateforme 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 plateforme 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 plateforme Unix ou Linux, le fichier de mot de passe s’appelle généralement orapw ( désignant le nom de l’instance) et est situé dans le répertoire $ORACLE_HOME/dbs. Sur plateforme Windows, le fichier de mot de passe s’appelle généralement pwd.ora ( 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 (section L’administrateur de base de données du chapitre Les bases de l’architecture Oracle).
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 plateforme Windows (possible aussi dans la base de registre) : set ORACLE_SID=HERMES
●
Sur plateforme 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 plateforme). 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 plateforme). 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.ora (Windows) ;
●
$ORACLE_HOME/dbs/spfile.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.ora (Windows) ;
●
$ORACLE_HOME/dbs/init.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 ciaprè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 leemca -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 SELECT name,ROUND(bytes/(1024*1024),1) 2 FROM v$sgainfo; NAME SIZE_MB -------------------------------- ---------Fixed SGA Size 2 Redo Buffers 3.7 Buffer Cache Size 152 Shared Pool Size 72 Large Pool Size 4 Java Pool Size 4 Streams Pool Size 0 Shared IO Pool Size 0 Granule Size 4 Maximum SGA Size 497.8 Startup overhead in Shared Pool 44 Free SGA Memory Available 260
size_mb,resizeable RES --No No Yes Yes Yes Yes Yes Yes No No No
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 (2407244152), 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, celleci 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, celleci 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 cidessus 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 plateforme n’est pas supportée ou, sur plateforme Linux, /dev/shm n’est pas dimensionné correctement. Action(s) Si vous êtes sur une plateforme 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 UNIXBased 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 ciaprè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 ------- ------------------------------F:\ORADATA\HERMES\CONTROL01.CTL G:\ORADATA\HERMES\CONTROL02.CTL
IS_ BLOCK_SIZE FILE_SIZE_BLKS --- ---------- -------------NO 16384 618 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 ciaprè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 ellesmê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 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’entê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’entête du fichier de données et enregistre juste le nouveau nom dans le fichier de contrôle (l’entê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 ciaprè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 soimê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
- 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 ciaprè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’entê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’entête (nous verrons bientôt que l’entê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’entê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 ellemê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’entê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 entê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 -- 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 trifusion (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 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 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 --------------- --------- ---------- --------- --- ---------SYSTEM PERMANENT LOCAL SYSTEM NO 8192 UNDOTBS UNDO LOCAL SYSTEM NO 8192 SYSAUX PERMANENT LOCAL SYSTEM NO 8192 TEMP TEMPORARY LOCAL UNIFORM NO 8192 DEFTBS PERMANENT LOCAL SYSTEM NO 8192 DATA PERMANENT LOCAL UNIFORM NO 8192 INDX PERMANENT LOCAL SYSTEM NO 8192 JE_SUIS_GROS PERMANENT LOCAL SYSTEM YES 8192
STATUS -----ONLINE ONLINE ONLINE ONLINE ONLINE ONLINE ONLINE 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’entête). USER_BLOCKS Taille utile du fichier en blocs Oracle (généralement taille du fichier moins les blocs d’entê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 --------------- ---------------------------------------- --------BLOCKS USER_BLOCKS MAXBLOCKS ---------- ----------- ---------SYSTEM F:\ORADATA\HERMES\SYSTEM01.DBF AVAILABLE 29440 29432 4194302 UNDOTBS E:\ORADATA\HERMES\UNDOTBS01.DBF AVAILABLE 20480 20472 131072 SYSAUX E:\ORADATA\HERMES\SYSAUX01.DBF AVAILABLE 14080 14072 4194302 DEFTBS E:\ORADATA\HERMES\DEFTBS01.DBF AVAILABLE 6400 6392 64000 DATA F:\ORADATA\HERMES\DATA01.DBF AVAILABLE 64000 62720 102400 INDX E:\ORADATA\HERMES\INDX01.DBF AVAILABLE 64000 63992 102400 DATA F:\ORADATA\HERMES\DATA02.DBF AVAILABLE 25600 24320 64000 JE_SUIS_GROS E:\ORADATA\HERMES\JE_SUIS_GROS.DBF AVAILABLE 128 112 0 TEMP F:\ORADATA\HERMES\TEMP01.DBF AVAILABLE 12800 12672 131072
AUT ---
YES YES YES YES YES YES YES NO YES
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 ciaprè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 ; 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 s’il y a ambiguïté. Exemple : OracleServiceSID ou OracleService Et pour terminer, l’éternelle question : que fautil 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 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 cidessus), 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 cidessus). 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éezen 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 luimê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 plateforme 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 ciaprè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 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’entê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 sousrequê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 sousrequê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 ellemê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 ciaprè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) comprendratil 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 ciaprè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 ; audelà 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, reportezvous à 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’entê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 audelà 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 . 0 à 25% d’espace libre . 25 à 50% d’espace libre . 50 à 75% d’espace libre . 75 à 100% d’espace libre . Non formatés
= = = = = =
71 0 38 31 65 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 sousrequê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 audessus 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é audessus 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 audessous 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é audessus 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 audessus 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 audessous 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 = . 0 à 25% d’espace libre = . 25 à 50% d’espace libre = . 50 à 75% d’espace libre = . 75 à 100% d’espace libre = . Non formatés = 0 Blocs : . Total = 256 . Inutilisés = 28 . Utilisés = 228
216 0 0 0 0
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 . 0 à 25% d’espace libre . 25 à 50% d’espace libre . 50 à 75% d’espace libre . 75 à 100% d’espace libre . Non formatés Blocs : . Total = 120 . Inutilisés = 2 . Utilisés = 118
= = = = = =
107 0 1 0 0 0
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 ciaprè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 Btree 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 Btree 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 Btree 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, entê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 Btree 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 "Btree", "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 Btree estil 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’entê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 Btree 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 ellesmê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 ciaprè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 Btree ; 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 sousindex (un pour chaque valeur de la première colonne) et de parcourir chaque sousindex. 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 [ 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 ciaprè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 ciaprè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 audelà 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 audessus 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é audessus 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 audessus 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é audessus 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 quelquesunes). 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 Btree. L’ordre SQL ANALYZE INDEX ... VALIDATE STRUCTURE. Les colonnes intéressantes des différentes autres vues sont présentées ciaprè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 sousjacent 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 quasitotalité 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 entretemps), 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 platesformes 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 cidessus, 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 luimê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 : ●
Estil acceptable de perdre des données ?
●
Estil possible d’arrêter périodiquement la base ?
●
Estil possible de réaliser une sauvegarde complète de la base pendant l’arrêt ?
La réponse à la question "estil 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 sontelles mises à jour quotidiennement par les utilisateurs ? C’est typiquement le cas dans une application transactionnelle. Les données sontelles 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) ; 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 pointvirgule, d’autres non (pointvirgule optionnel). Les commandes RMAN nécessitant un pointvirgule 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 pointvirgule ; 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 pointvirgule (même si le pointvirgule 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 plateforme. 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, assurezvous 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 sousrépertoires, avec des formats de nom de fichiers spécifiques. Ce sont des fichiers "gérés par Oracle" (OracleManaged Files). Les différents répertoires sont définis sous la forme suivante : ●
/[/] (Unix/Linux) ;
●
\[\] (Windows).
Avec : 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). Sousré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). Identique à mais en majuscules. Sousré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____.log
Copie image de fichier de données
o1_mf___.dbf
Copie image de fichier de contrôle
o1_mf___.ctl
Jeu de sauvegarde
o1_mf____.bkp
Sauvegarde automatique
o1_mf_s___.bkp
Avec : nom du tablespace ; chaîne de 8 caractères qui garantit l’unicité ; numéro de groupe pour les fichiers de journalisation ; numéro d’instance (thread) pour les fichiers de journalisation archivés ; numéro de séquence pour les fichiers de journalisation archivés ; nom donné à la sauvegarde (option TAG de la commande BACKUP) ; chaîne de 5 caractères correspondant au contenu du jeu de sauvegarde ; 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 ciaprè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 ; 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 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 LIST LIST LIST LIST LIST
BACKUP BACKUP BACKUP BACKUP BACKUP BACKUP
OF OF OF OF OF OF
DATABASE ; # n’importe quel fichier de la base DATAFILE 1,’E:\ORADATA\HERMES\DATA01.DBF’ ; TABLESPACE system,sysaux ; CONTROLFILE SPFILE ; ARCHIVELOG ALL ; 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 LIST BACKUP LIST BACKUP LIST BACKUP COMPLETED
TAG=’DBINC0’ ; COMPLETED AFTER ’SYSDATE-1’ ; TAG=’DBINC0’ COMPLETED AFTER ’SYSDATE-1’ ; OF ARCHIVELOG UNTIL TIME ’SYSDATE-1’ 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 LIST LIST TO LIST TO
ARCHIVELOG ALL ; # tous ARCHIVELOG FROM TIME ’SYSDATE-1/24’ ; # dans la dernière heure ARCHIVELOG ALL BACKED UP 2 TIMES DEVICE TYPE DISK ; # archives sauvegardées 2 fois sur disque ARCHIVELOG ALL BACKED UP 0 TIMES 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]; - 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 ciaprè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 pointintime 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. Assurezvous 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, assurezvous 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 sousensemble 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, assurezvous 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 pseudocolonnes 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 (pseudocolonne 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 celuici 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’; ORIGINAL_NAME -------------ADHERENT$PK ADHERENT$UK01 NUMEROADHERENT ADHERENT
OBJECT_NAME -----------------------------BIN$y3LFL/MFTs28v7JjGLBSjQ==$0 BIN$iDjv77eKRHGEDyAfQ+Hdnw==$0 BIN$sPGkld1PR3+w2PbWRdhz8A==$0 BIN$2tvUDS05RV+Rj2ogvU1aUg==$0
TYPE ------INDEX INDEX TRIGGER TABLE
CAN_ CAN_ TS_NAME UNDROP PURGE ------- ----- ----INDX NO YES INDX NO YES NO NO 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 (sousré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. Ceuxci 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> ... SQL> SQL> Base
SHUTDOWN IMMEDIATE STARTUP MOUNT ALTER DATABASE FLASHBACK ON; 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 ; celleci 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 : ●
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.
- 8-
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 contrevé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 cidessous). 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 cidessus, 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 cidessus, 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 laissezvous 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 laissezvous 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 ciaprè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 platesformes 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 cidessus). 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èreplan 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 (plateforme Windows) ou 16 Mo (autres platesformes) 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èreplan a. Introduction Les processus d’arrièreplan ont chacun un rôle bien précis dans le fonctionnement de l’instance. La plupart des processus d’arrièreplan 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èreplan différents, mais certains processus d’arrièreplan peuvent être lancés en plusieurs exemplaires. Chaque processus d’arrièreplan 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èreplan pour une instance standard sont les suivants : DBWn LGWR CKPT SMON ARCn CJQn PMON
b. DBWn Les processus d’arrièreplan 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 passetil 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èreplan 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 cidessus, 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èreplan 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èreplan CKPT (Checkpoint) a simplement pour rôle d’enregistrer le point de reprise dans l’entête des fichiers de données et dans le fichier de contrôle.
e. SMON Le processus d’arrièreplan 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èreplan 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èreplan 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 à l’aide du package DBMS_SCHEDULER ou des fonctions de programmation d’Oracle Enterprise Manager.
h. ARCn Les processus d’arrièreplan 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 cidessus 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 platesformes suivantes : Linux, Solaris, Windows, HPUX et AIX. Si vous tentez d’activer cette fonctionnalité sur une plateforme 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 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 cidessous) 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 : ●
SKIP
- 4-
openmirrors.com
© 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 pointvirgule, 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 deuxpoints 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 cellesci 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 : clause SQL "s_adherent.NEXTVAL"
© ENI Editions - All rights reserved - Algeria Educ
- 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 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 sousensemble des informations accessibles dans les vues ALL_ qui ellesmêmes forment un sousensemble 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-