Oracle 11g : administration

Oracle 11g  Administration

Olivier HEURTEL  

Résumé Ce livre sur Oracle 11g s’adresse à tout informaticien désireux de maîtriser les tâches d’administration des bases de données Oracle. Après une présentation générale de l’architecture interne d’un serveur Oracle (mémoire, processus), ce livre détaille les différentes tâches d’administration d’une base de données : installation (sous Windows et sous Linux), configuration Oracle Net, création d’une nouvelle base de données, gestion de la mémoire, gestion du stockage, gestion des utilisateurs et des droits, sauvegardes et restaurations avec RMAN (Recovery Manager). Une attention particulière est apportée aux nouvelles fonctionnalités d’Oracle 11g qui facilitent le travail de l’administrateur : réglage automatique de la mémoire, référentiel de Diagnostique Automatique, mots de passe sensibles à la casse, rétrécissement d’un tablespace temporaire géré localement, nouvelle ergonomie de Oracle Entreprise Manager Database Control, etc. L’ouvrage contient de nombreux conseils pratiques et recommandations et présente les solutions qui peuvent être apportées aux problèmes les plus courants. Des exemples de scripts sont en téléchargement sur cette page.

L'auteur Après plus de huit ans passés en société de service, où il a successivement occupé les postes de développeur, chef de projet puis directeur de projet, Olivier Heurtel a démarré une activité de consultant/formateur indépendant spécialisé sur les bases de données (Oracle), le développement Web (PHP) et les systèmes décisionnels. Olivier Heurtel est certifié Oracle Certified Professional et cet ouvrage est le fruit de l'expérience acquise au cours de nombreuses prestations de mise en œuvre de bases Oracle en entreprise.

Ce livre numérique a été conçu et est diffusé dans le respect des droits d’auteur. Toutes les marques citées ont été déposées par leur éditeur respectif. La loi du 11 Mars 1957 n’autorisant aux termes des alinéas 2 et 3 de l’article 41, d’une part, que les “copies ou reproductions strictement réservées à l’usage privé du copiste et non destinées à une utilisation collective”, et, d’autre part, que les analyses et les courtes citations dans un but d’exemple et d’illustration, “toute représentation ou reproduction intégrale, ou partielle, faite sans le consentement de l’auteur ou de ses ayants droit ou ayant cause, est illicite” (alinéa 1er de l’article 40). Cette représentation ou reproduction, par quelque procédé que ce soit, constituerait donc une contrefaçon sanctionnée par les articles 425 et suivants du Code Pénal. Copyright Editions ENI

© ENI Editions - All rights reserved - Algeria Educ

- 1-

Installation du serveur  1. Introduction  L’installation d’Oracle sur un serveur nécessite une bonne compréhension de l’architecture Oracle et des compétences  minimales  sur  le  système  d’exploitation ;  ces  compétences  sont  réduites  au  strict  minimum  pour  la  plate­forme  Windows mais sont un peu plus avancées pour les autres plates­formes.  Dans tous les cas, il est impératif de se référer à la documentation Oracle spécifique à la plate­forme :  ●

Oracle® Database Installation Guide for ... 

●

Oracle® Database Quick Installation Guide for ... 

●

Oracle® Database Release Notes for ... 

La  documentation  "Quick  Installation  Guide"  décrit  comment  installer  rapidement  Oracle  en  utilisant  des  options  par  défaut. Cette documentation est en général suffisante pour une première prise en main.  L’objectif de ce chapitre est de présenter les principales étapes et options de l’installation, en se limitant aux plates­ formes Windows et Linux (en l’occurrence Red Hat Enterprise Linux 4) ; ce chapitre n’a pas vocation à remplacer les  manuels  d’installation  fournis  par  Oracle.  Par  ailleurs,  l’ouvrage  dans  son  ensemble  apporte  les  compétences  sur  l’architecture Oracle nécessaires à la compréhension des différentes phases de l’installation.  Sur  OTN  (Oracle  Technology  Network  :  http://www.oracle.com/technology/index.html),  moyennant  une  inscription  gratuite  au  site,  vous  pouvez  télécharger  les  produits  Oracle  à  des  fins  de  développement  ou  d’évaluation. 

Sur  Metalink  (site  du  support  Oracle  :  https://metalink.oracle.com/),  vous  pouvez  trouver  des  notes  d’installation  précises,  à  jour,  pour  chaque  version  d’Oracle,  chaque  système  d’exploitation  et  chaque  architecture (32/64 bits) ; n’hésitez pas à les consulter. 

2. Principales étapes de l’installation  Installer Oracle sur un serveur comporte trois grandes phases :  ●

pré­installation : préparer le système d’exploitation ; 

●

installation : installer les produits Oracle ; 

●

post­installation : terminer l’installation et configurer certains composants Oracle. 

Sur plate­forme Windows, la phase de pré­installation est réduite au strict minimum :  ●

vérifier les pré­requis logiciels et matériels ; 

●

se connecter en tant que membre du groupe Administrateur. 

Sur plate­forme  Unix  ou  Linux,  la  phase  de  pré­installation comporte par contre, plusieurs étapes. Dans les grandes  lignes, les étapes sont les suivantes :  ●

vérifier les pré­requis logiciels et matériels ; 

●

configurer le noyau (sémaphores, mémoire partagée...) ; 

●

créer les répertoires nécessaires ; 

© ENI Editions - All rights reserved - Algeria Educ

- 1-

●

créer un groupe et un compte appartenant à ce groupe. 

L’installation  des  produits  Oracle  s’effectue  avec  l’application Oracle  Universal  Installer ;  cet  installeur  est  "universel"  dans la mesure où il est identique (à peu de choses près) sur les différentes plates­formes et est utilisé par différents  produits Oracle (serveur, client, etc.).  Oracle Universal Installer permet :  ●

●

de  choisir  le  type  d’installation :  Enterprise  Edition,  Standard  Edition,  Personal  Edition  (plate­forme Windows  uniquement) personnalisé ;  de  créer  une  base  de  données  de  départ  avec  différentes  options  de  configuration  pour  le  stockage,  l’administration, la sauvegarde, etc. 

À l’issue de cette phase, si vous optez pour une installation avec base de données, vous devriez avoir :  ●

une base de données de départ lancée ; 

●

une configuration Oracle Net par défaut avec un processus d’écoute (listener) lancé ; 

●

Oracle Enterprise Manager Database Control et lancé et accessible à l’aide d’un navigateur ; 

La phase de post­installation consiste essentiellement à :  ●

télécharger et appliquer d’éventuels patchs Oracle ; 

●

recompiler les modules PL/SQL invalides ; 

●

configurer certains composants Oracle (Oracle Net, etc.) ; 

●

installer des produits supplémentaires ; 

●

configurer l’environnement de travail ; 

●

configurer  le  démarrage  et  l’arrêt  automatiques  des  différents  composants  Oracle  (base  de  données,  processus d’écoute, etc.). 

Sur  plate­forme  Windows,  si  vous  optez  pour  une  installation  avec  base  de  données  de  départ,  Oracle  Universal Installer crée automatiquement les services associés aux différents composants et les configure en  démarrage  automatique ;  si  l’installation  s’effectue  sans  base  de  départ,  ces  services  doivent  être  créés  et  configurés ultérieurement. Sur plate­forme Linux ou Unix, les services doivent être explicitement créés et configurés  par l’administrateur du système d’exploitation.  Les  différentes  phases  de  l’installation  sont  décrites  ci­après.  Ensuite,  nous  verrons  comment  configurer  l’environnement de travail et configurer le démarrage et l’arrêt automatiques des différents composants Oracle.  Avant  cela,  nous  présenterons  le  standard  Optimal  Flexible  Architecture  (OFA).  OFA  est  un  ensemble  de  recommandations sur l’arborescence et le nommage des fichiers du serveur, destinées à faciliter l’administration des  produits Oracle.  Avant toute installation, il est conseillé de sauvegarder les éléments critiques éventuellement présents sur le  serveur (bases Oracle d’une autre version d’Oracle, autres produits). 

3. Optimal Flexible Architecture (OFA)  a. Principes généraux 

- 2-

© ENI Editions - All rights reserved - Algeria Educ

OFA  est  un  ensemble  de  recommandations  sur  l’arborescence  et  le  nommage  des  fichiers  du  serveur,  destinées  à  faciliter l’administration des produits Oracle.  Un des points les plus intéressants du standard OFA est de clairement séparer le produit Oracle, les fichiers relatifs à  l’administration  et  les  fichiers  des  bases  de  données,  en  tenant  compte  de  la  possibilité  d’avoir  plusieurs  versions  d’Oracle et/ou plusieurs bases sur le serveur.  Les recommandations varient légèrement selon la plate­forme (voir la documentation "Oracle® Database Installation  Guide" de votre plate­forme).  Oracle Universal Installer est compatible OFA et propose une arborescence par défaut qui respecte ce standard.  Dans le standard OFA, deux répertoires jouent un rôle particulier : les répertoires Oracle Base et Oracle Home.  Le répertoire Oracle Base est le répertoire racine de l’arborescence Oracle.  Le répertoire Oracle Home est un sous­répertoire du répertoire Oracle Base qui contient le logiciel Oracle proprement  dit, pour une version donnée. Dans un répertoire Oracle Base, il est possible d’avoir plusieurs répertoires Oracle Home  correspondant chacun à une certaine version d’un produit Oracle donné (serveur de base de données, client, serveur  d’application, etc.).  Dans  des  configurations  avancées,  il  est  possible  d’avoir  plusieurs  répertoires  Oracle  Base,  pour  installer  plusieurs produits Oracle sur des disques différents.  Chaque  répertoire  Oracle  Home  est,  par  ailleurs,  identifié  par  un  nom,  par  défaut  sous  la  formeOraDb11g_homeN,  N  étant un numéro d’ordre.  Sur  plate­forme  Windows,  les  emplacements  de  ces  deux  répertoires  sont  définis  dans  des  entréesde  la  base  de  registre  (dans  HKEY_LOCAL_ MACHINE\SOFTWARE\ORACLE\KEY_nom,  nom  étant  le  nom  du  Oracle  Home).  Sur  plate­forme  Linux  ou  Unix,  les  emplacements  de  ces  deux  répertoires  sont  généralement  définis  dans  des  variables  d’environnement ORACLE_BASE et ORACLE_HOME du compte dans lequel Oracle est installé.  Sur plate­forme Windows, depuis la version 11, les recommandations sont les suivantes pour ces deux répertoires :  Oracle Base  X:\app\compte, X  étant  un  lecteur  de  disque  et  compte  le  nom  du  compte  utilisé  pour  l’installation.  Exemple :  d:\app\oracle  Oracle Home  ORACLE_BASE\product\ v.v.v\type_n, ORACLE_BASE désignant le répertoire Oracle Base,  product étant une constante  indiquant  que  les  produits  sont  ici,  v.v.v  le  numéro  de  version  du  produit,  type  le  type  de  produit  (db pour  un  serveur de base de données, client pour un client, etc.) et n un numéro d’ordre dans le type.  Exemple : d:\app\oracle\product\11.1.0\db_1  Avant la version 10, le chemin Oracle Base était du type X:\Oracle (par exemple D:\Oracle) et le chemin Oracle Home  du type  ORACLE_BASE\OraVV, VV  étant  le  numéro  de  version  du  produit  (par  exemple  D:\Oracle\Ora92). Le nom du  Oracle Home était de la forme OraHomeVV (par exemple OraHome 92) et la clé de la base de registre de la forme HOMEn,  n  étant  un  numéro  d’ordre  (par  exemple  HOME0).  Puis  en  version  10,  le  chemin  Oracle  Base  était  du  type  X:\oracle\product\v.v.v  et  le  chemin  Oracle  Home  du  type  ORACLE_BASE\type_n  (c’est  le  chemin  Oracle  Base  qui  comportait l’information de version).  Si  vous  installez  Oracle11g  sur  un  système  sur  lequel  une  version  précédente  d’Oracle  est  installée,  l’installeur  va  conserver  l’ancien  chemin  du  répertoire  Oracle  Base  et  adapter  en  conséquence  le  chemin  Oracle Home. En cas de doute, consultez les valeurs dans la base de registre. 

Sur  la  plate­forme  Windows,  il  n’est  pas  habituel  de  créer  un  compte  spécifique  pour  installer  Oracle.  Si  vous utilisez le compte administrateur de la machine, vous pouvez modifier le chemin proposé pour Oracle  Base par l’installeur et mettre oracle en guise de compte.  Sur  plate­forme  Unix  ou  Linux  depuis  la  version  10,  les  recommandations  sont  les  suivantes  pour  ces  deux  répertoires :  Oracle Base  / pm/ ccc/ compte,  pm  étant  un  point  de  montage  d’un  système  de  fichiers  (avec  p  une  chaîne  et  m  un  numéro  d’ordre), ccc une chaîne quelconque et compte le nom du compte utilisé pour l’installation.Exemple : /u01/app/oracle 

© ENI Editions - All rights reserved - Algeria Educ

- 3-

Oracle Home  ORACLE_BASE/product/v.v.v/type_n,ORACLE_BASE désignant le répertoire  Oracle Base,  v.v.v le numéro de version du  produit, type le type de produit (db pour un serveur de base de données, client pour un client, etc.) et n un numéro  d’ordre dans le type. Exemple : /u01/app/oracle/product/11.1.0/db_1  Avant la version 10, les recommandations étaient les mêmes, mais sans la partie type_ n.  La partie type_ n du chemin Oracle Home permet d’installer différents produits avec le même numéro de version sous  le même répertoire Oracle Base. Cela permet aussi d’installer plusieurs fois le même produit, dans la même version,  sous le même répertoire Oracle Base.  En dehors du répertoire Oracle Home, le répertoire Oracle Base est destiné à contenir quatre autres répertoires :  ●

oradata pour les fichiers des bases de données ; 

●

admin pour les fichiers d’administration des bases de données ; 

●

cfgtoollogs pour les fichiers journaux des assistants de configuration ; 

●

diag pour le Référentiel du Diagnostique Automatique (Automatic Diagnostic Repository ­ ADR). 

Puisque plusieurs bases sont susceptibles d’être présentes sur le système, le standard OFA recommande de créer  un sous­répertoire par base, portant le nom de la base (paramètre DB_NAME), dans les répertoires oradata et admin.  Exemple : 

 

- 4-

© ENI Editions - All rights reserved - Algeria Educ

  Sur ces deux exemples, deux bases (ORCL et TEST) sont présentes sur le système.  Les  différents  sous­répertoires  du  répertoire  d’administration  sont  présentés  dans  le  chapitre Création  d’une  nouvelle base de données.  En ce qui concerne les fichiers de la base de données, les recommandations de nommage sont les suivantes :  Fichier de contrôle  control.nn.ctl, nn étant un numéro d’ordre (01, 02, etc.).  Fichier de journalisation  redonn.log, nn étant le numéro du groupe (01, 02, etc.).  Fichiers de données  tablespacenn.dbf, tablespace étant le nom du tablespace et nn le numéro d’ordre du fichier au sein du tablespace  (01, 02, etc.). 

b. Répartition des fichiers de la base de données sur plusieurs disques  D’une manière générale, il est souhaitable de séparer le stockage du système d’exploitation, du logiciel Oracle et des  bases de données, chaque stockage pouvant être au choix un disque, un volume logique ou un volume RAID.  Dans le cas où vous créez une base de données sur des disques qui ne sont pas organisés en volumes logiques ou  en RAID, il est recommandé de répartir les fichiers de la base de données sur différents disques afin d’améliorer les  performances et la sécurité.  Vous  pouvez  donc  être  amenés  à  utiliser  plusieurs  répertoires oradata  situés  sur  différents  points  de  montage  ou  lecteurs de disque.  Selon la recommandation OFA, ces répertoires  oradata supplémentaires doivent être créés en respectant la même  arborescence que le répertoire oradata principal.  Exemple :  Windows  e:\app\oracle\oradata 

© ENI Editions - All rights reserved - Algeria Educ

- 5-

Unix ou Linux  /u02/app/oradata/oradata  À partir de là, selon les systèmes de stockage disponibles, plusieurs organisations sont disponibles.  Exemple : 

Axe

Nature

Contenu

1 

Disque 

Système d’exploitation 

2 

Disque 

Logiciel Oracle 

3 

N disques en RAID 0+1 

Fichiers de données des  tablespaces   Fichiers de contrôle 

4 

N disques en RAID 0+1 

Fichiers de journalisation 

5 

Disque 

Fichiers de journalisation  archivés  Sauvegardes sur disque 

Sur plate­forme Linux ou Unix, il est possible d’utiliser les liens symboliques pour faire croire que les fichiers  sont situés sous un seul point de montage alors qu’ils sont en fait répartis sur plusieurs. 

Si vous le souhaitez, vous pouvez adopter une organisation OFA non standard, du moment que vous en  respectez la philosophie (séparation des produits Oracle, séparation des bases de données). 

4. Pré­installation  a. Sur plate­forme Windows  Se connecter au système Oracle  doit  être  installé  à  l’aide  d’un  compte  membre  du  groupe  Administrateur.  Si  l’installation  s’effectue  sur  un  serveur contrôleur de domaine (principal ou secondaire), le compte doit être membre du groupe Administrateur de  domaine.  Dans  cet  ouvrage,  nous  supposerons  qu’un  compte  nommé  « oracle »,  membre  du  groupe  Administrateur,  a  été  spécialement créé pour l’occasion.  Vérifier les pré­requis logiciels et matériels Oracle11g supporte les systèmes d’exploitation Windows suivants :  ●

Windows 2000 (service pack 1 ou supérieur) ; 

●

Windows Server 2003 (toutes les éditions) ; 

●

Windows XP Professional ; 

●

Windows Vista (Business, Enterprise et Ultimate). 

Dans  cet  ouvrage,  nous  utiliserons  une  plate­forme  Windows  Server  2003  Entreprise  Edition.  L’installation  sur  les  autres plates­formes Windows est identique.  Les exigences matérielles sont les suivantes : 

- 6-

© ENI Editions - All rights reserved - Algeria Educ

●

1 Go de mémoire physique minimum ; 

●

Le double de mémoire virtuelle ; 

●

200 Mo d’espace temporaire ; 

●

Environ 3 Go d’espace disque pour les produits Oracle ; 

●

●

Environ 2 Go d’espace disque supplémentaire si vous souhaitez créer une base de données de départ lors  de l’installation ;  256 couleurs pour la vidéo. 

Si vous n’avez que 256 Mo de mémoire physique, vous n’aurez pas suffisamment de mémoire pour créer une  base de données au cours de l’installation ; vous devrez créer la base de données ultérieurement (avec une  petite SGA). 

b. Sur plate­forme Linux  Se connecter au système en tant qu’utilisateur root Les premières tâches de la phase de pré­installation doivent être effectuées en tant que root .  Vérifier les pré­requis logiciels et matériels Oracle11g supporte les systèmes d’exploitation Linux suivants :  ●

Oracle Enterprise Linux 4 ou Red Hat Enterprise Linux 4 (noyau 2.6.9) ; 

●

Oracle Enterprise Linux 5 ou Red Hat Enterprise Linux 5 (noyau 2.6.18) ; 

●

SUSE Enterprise Linux 10 (noyau 2.6.16.21). 

Dans cet ouvrage, nous utiliserons une plate­forme Red Hat Enterprise Linux 4. L’installation sur les autres plates­ formes Linux (ou Unix en général) est similaire : les principes sont les mêmes, mais certaines valeurs ou certaines  commandes peuvent différer (reportez­vous au manuel d’installation de votre plate­forme).  Pour chaque distribution, un certain nombre de packages doivent être installés (avec une version minimum).  Exemple pour Red Hat Enterprise Linux 4 :  binutils-2.15.92.0.2-18 compat-libstdc++-33.2.3-47.3 elfutils-libelf-0.97-5 elfutils-libelf-devel-0.97-5 glibc-2.3.4-2.19 glibc-common-2.3.4-2.19 glibc-devel-2.3.4-2.19 glibc-headers-2.3.4-2.19 gcc-3.4.5-2 gcc-c++-3.4.5-2 libaio-devel-0.3.105-2 libaio-0.3.105-2 libgcc-3.4.5 libstdc++-3.4.5-2 libstdc++-devel-3.4.5-2 make-3.80-5 sysstat-5.0.5 unixODBC-2.2.11 unixODBC-devel-2.2.11

© ENI Editions - All rights reserved - Algeria Educ

- 7-

Le script suivant permet de vérifier ces exigences sur Red Hat Enterprise Linux 4 :  echo "* Version du noyau" uname -r echo "* Packages" # Liste des packages listePackages=$(cat < _EOF_ binutils libaio libaio-devel gcc gcc-c++ glibc glibc-common glibc-headers glibc-devel libstdc++ libstdc++-devel compat-libstdc++-33 make sysstat elfutils-libelf elfutils-libelf-devel unixODBC unixODBC-devel _EOF_ ) # Recherche les packages et indique si le package est # installe ou pas. for package in $listePackages; do version=$(rpm -q $package --qf "%{version} %{arch}") if [ $? = 0 -a "$version" ] then printf "+ %-25s %-15s %s\n" $package $version else printf "o %-25s %s\n" $package "?" fi done Résultat :  * Version du noyau 2.6.9-67.0.15.ELsmp * Packages + binutils + libaio + libaio-devel + gcc + gcc-c++ + glibc + glibc-common + glibc-headers + glibc-devel + libstdc++ + libstdc++-devel + compat-libstdc++-33 + make + sysstat + elfutils-libelf + elfutils-libelf-devel + unixODBC + unixODBC-devel

2.15.92.0.2 0.3.105 0.3.105 3.4.6 3.4.6 2.3.4 2.3.4 2.3.4 2.3.4 3.4.6 3.4.6 3.2.3 3.80 5.0.5 0.97.1 0.97.1 2.2.11 2.2.11

i386 i386 i386 i386 i386 i686 i386 i386 i386 i386 i386 i386 i386 i386 i386 i386 i386 i386

Les exigences matérielles sont les suivantes : 

- 8-

●

1 Go de mémoire physique minimum ; 

●

Espace  swap  :  1,5  fois  la  mémoire  physique  si  cette  dernière  fait  moins  de  2  Go  ou  égal  à  la  mémoire  © ENI Editions - All rights reserved - Algeria Educ

physique si cette dernière est comprise entre 2 Go et 8 Go ;  ●

400 Mo d’espace temporaire (/tmp) ; 

●

Environ 3,5 Go d’espace disque pour les produits Oracle ; 

●

Environ 2 Go d’espace disque supplémentaire si vous souhaitez créer une base de données de départ lors  de l’installation ; 

Le script suivant permet de vérifier ces exigences sur Red Hat Enterprise Linux 4 :  echo "* Mémoire (Mo)" free -m echo "* Disque" df -h /tmp /u0* Résultat :  * Memoire (Mo) total used free shared buffers Mem: 1010 966 44 0 4 -/+ buffers/cache: 591 419 Swap: 2559 116 2443 * Disque Filesystem Size Used Avail Use% Mounted on /dev/mapper/VolGroup00-LogVol00 9.9G 2.8G 6.6G 30% / /dev/mapper/VolGroup01-LogVol100 9.9G 5.4G

4.0G

cached 370

58% /u01

Configurer le noyau

Paramètre

Valeur

Fichier

semmsl 

250 

semmns 

32000 

semopm 

100 

semmni 

128 

shmall 

2097152 

/proc/sys/kernel/shmall 

shmmax 

la moitié de la mémoire physique 

/proc/sys/kernel/shmmax 

shmmni 

4096 

/proc/sys/kernel/shmmni 

file-max 

65536 

/proc/sys/fs/file-max 

ip_local_port_range 

1024 65000 

/proc/sys/net/ipv4/ip_ 

/proc/sys/kernel/sem 

local_port_range  rmem_default 

4194304 

/proc/sys/net/core/  rmem_default 

rmem_max 

4194304 

/proc/sys/net/core/  rmem_max 

wmem_default 

262144 

/proc/sys/net/core/ 

© ENI Editions - All rights reserved - Algeria Educ

- 9-

wmem_default  wmem_max 

262144 

/proc/sys/net/core/wmem_max 

Le script suivant permet de vérifier ces paramètres sur Red Hat Enterprise Linux 4 :  listeVariables=$(cat exit ... [oracle@srvlinora ~]$ . oraenv ORACLE_SID = [ORCL] ? TEST The Oracle base for ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1 is /u01/app/oracle [oracle@srvlinora ~]$ sqlplus / as sysdba SQL*Plus: Release 10.2.0.4.0 ... ... SQL> exit ... [oracle@srvlinora ~]$

c. Configurer le démarrage et l’arrêt automatique  Plate­forme Windows Sur  plate­forme  Windows,  l’installeur  crée  automatiquement  les  services  qui  permettent  le  démarrage  et  l’arrêt 

© ENI Editions - All rights reserved - Algeria Educ

- 31 -

automatique  des  différents  composants  Oracle :  processus  d’écoute,  base  de  données,  console  Oracle  Enterprise  Manager.  Il n’y a donc rien de particulier à faire à ce stade. 

 

Nous étudierons plus en détail ces différents composants dans la suite de cet ouvrage.

Plate­forme Unix ou Linux Sur plate­forme Unix ou Linux, l’installeur ne configure aucun composant en démarrage automatique.  Il est de la responsabilité de l’administrateur du système (root) de créer un script de démarrage de ces composants  et le faire s’exécuter dans les niveaux d’exécution souhaités.  Dans cet ouvrage, nous allons présenter les actions à effectuer sur une plate­forme Red Hat Enterprise Linux ES 4.  Les  principes  sont  les  mêmes  pour  les  autres  distributions  (ou  Unix  en  général),  mais  certains  chemins,  certaines  valeurs  ou  certaines  commandes  peuvent  être  différents  (consultez  la  documentation  Oracle®  Database  Administrator’s  Reference  de  votre  plate­forme  et  la  documentation  de  votre  système  d’exploitation  sur  les  processus de démarrage et d’arrêt).  Connectez­vous en tant que root.  Dans le répertoire /etc/init.d, >créez un script nommé dbora avec un contenu similaire au suivant :  #! /bin/sh # # chkconfig: 35 99 01 # description: démarre et arrête les services Oracle # # Modifiez la valeur des variables suivantes pour tenir compte de # votre environnement : # - ORACLE_HOME # chemin vers le répertoire Oracle Home des # scripts dbstart et dbshut # - ORACLE_HOME_LISTENER # chemin vers le répertoire Oracle Home du listener # - ORACLE # nom du compte oracle # - LOG # chemin vers un fichier journal # - VAR_LOCK # chemin vers le fichier utilisé par le système pour savoir # si le service est démarré # (normalement /var/lock/subsys/<nom du service>) ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_1 ORACLE_HOME_LISTENER=$ORACLE_HOME ORACLE=oracle LOG=$ORACLE_HOME/dbora.log VAR_LOCK=/var/lock/subsys/dbora # # Si le script est appelé sans deuxième paramètre (appel initial), # on le relance sous le compte oracle (du coup avec un deuxième # paramètre) if [ ! "$2" = "ORA" ] ; then su - $ORACLE -c "$0 $1 ORA" case $1 in ’start’) # indiquer que le service a démarré (du moins a priori) touch $VAR_LOCK ;; ’stop’) # indiquer que le service a été stoppé (du moins a priori) rm -f $VAR_LOCK esac exit fi PATH=${PATH}:$ORACLE_HOME/bin export ORACLE_HOME PATH

- 32 -

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

touch $LOG chmod a+r $LOG case $1 in ’start’) echo "***** $(date) - $0 : démarrage" > $LOG $ORACLE_HOME/bin/dbstart $ORACLE_HOME_LISTENER > $LOG 2>&1 & ;; ’stop’) echo "***** $(date) - $0 : arrêt" > $LOG $ORACLE_HOME/bin/dbshut $ORACLE_HOME_LISTENER > $LOG 2>&1 & ;; *) echo "usage: $0 {start|stop}" ;; esac exit Depuis la version 11, les scripts dbstart et dbshut prennent en charge le démarrage et l’arrêt du processus  d’écoute.  En  conséquence,  le  script  présenté  ci­dessus  permet  le  démarrage  et  l’arrêt  automatique  du  processus d’écoute et des bases de données. Par contre, il doit être complété pour prendre en charge la console  Oracle Enterprise Manager.  Changer le groupe du fichier dbora en dba (ou votre groupe OSDBA s’il est différent) et modifier les permissions du  fichier :  chgrp dba dbora chmod 750 dbora Créer des liens symboliques vers le script dbora dans les répertoires des niveaux d’exécution adéquats, par exemple  pour avoir un démarrage (plutôt en dernier) dans les niveaux 3 et 5, et un arrêt (plutôt en premier) dans les niveaux  0 (arrêt du système) et 6 (redémarrage du système) :  ln ln ln ln

-s -s -s -s

/etc/init.d/dbora /etc/init.d/dbora /etc/init.d/dbora /etc/init.d/dbora

/etc/rc.d/rc0.d/K01dbora /etc/rc.d/rc3.d/S99dbora /etc/rc.d/rc5.d/S99dbora /etc/rc.d/rc6.d/K01dbora

Ces liens symboliques peuvent être créés par l’utilitaire chkconfig qui exploite les informations contenues dans les  commentaires en début de script :  chkconfig --add dbora Le système est opérationnel.  Si plusieurs versions d’Oracle sont installées sur votre serveur, il faut plutôt utiliser la version la plus récente  dans  le  script  dbora  (avec  une  variable  $ORACLE_HOME  configurée  en  conséquence).  La  seule  exception  potentielle  concerne  le  démarrage  de  la  console  Oracle  Enterprise  Manager  (cf.  Chapitre  Les  outils  d’administration).  Si  besoin,  ce  script  peut  être  adapté,  ou  scindé  en  plusieurs  scripts,  afin  d’utiliser  différents  Oracle Home. 

© ENI Editions - All rights reserved - Algeria Educ

- 33 -

Installation du client  Les  procédures  d’installation d’un  client  Oracle  ressemblent  beaucoup,  en  plus  simples,  aux  procédures  d’installation  du serveur. En conséquence, dans cet ouvrage, nous présenterons ces procédures de manière très synthétique. Pour  plus d’informations, reportez­vous à la documentation Oracle spécifique à votre plate­forme  ●

Oracle® Database Client Installation Guide for... 

●

Oracle® Database Client Quick Installation Guide for... 

●

Oracle® Database Client Release Notes for... 

Les similitudes d’installation entre un serveur et un client portent notamment sur :  ●

●

Les  différentes  étapes  de  l’installation  (pré­installation,  installation  avec  Oracle  Universal  Installer,  post­ installation) ;  Le  standard  OFA,  avec  notamment  un  répertoire  Oracle  Home  (plusieurs  clients  peuvent  être  installés  sur  la  même machine) ; 

●

Les spécificités de chaque plate­forme (variables d’environnement, base de registre, etc.) ; 

●

La possibilité d’effectuer une installation non interactive, en utilisant un fichier de réponse. 

Un client Oracle comporte généralement au minimum le composant Oracle Net qui permet d’accéder à une base Oracle  du réseau. En complément, le client peut comporter :  ●

des outils d’interrogation ou d’administration (SQL*Plus, etc.) ; 

●

des produits nécessaires pour le développement ou le déploiement d’applications. 

Les produits pour le développement ou le déploiement qui peuvent être installés, varient d’une plate­forme à l’autre.  Les principaux produits sont les suivants :  ●

OCI (Oracle Call Interface ­ API de bas niveau utilisable en C par exemple) ; 

●

Oracle Object For OLE (produit équivalent à OLE DB) ; 

●

Drivers ODBC ; 

●

Provider pour OLE DB ou .NET ; 

●

Drivers JDBC ; 

●

pré­compilateurs Pro*C/C++, Pro*COBOL... 

L’installation proprement dite s’effectue avec Oracle Universal Installer. Les principales étapes sont les suivantes :  ●

spécification du répertoire d’inventaire (première installation sur plate­forme Linux ou Unix) ; 

●

désignation de l’emplacement des fichiers (Oracle Home) ; 

●

choix d’un type d’installation (voir ci­dessous) ; 

●

choix éventuel des composants à installer (installation personnalisée uniquement) ; 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

●

affichage d’un écran de synthèse permettant de confirmer l’installation. 

Les types d’installation proposés par l’installeur sont les suivants :  InstantClient  :  n’installe  que  les  librairies  nécessaires  aux  applications  qui  utilisent  les  OCI  avec  la  fonctionnalité  de  "client instantané" (instant client). Nécessite peu d’espace disque (plus ou moins 150 Mo selon la plate­forme).  Administrateur  :  installe  la  quasi­totalité  des  composants,  y  compris  les  outils  d’administration  et  les  produits  de  développement  Runtime : installe un client simple comportant principalement Oracle Net, SQL*Plus et les drivers JDBC.  Personnalisée : permet de sélectionner précisément les composants et d’installer un client parfaitement adapté à un  besoin  précis  (développeur,  déploiement) :  avec  ou  sans  outil  (SQL*Plus  par  exemple),  avec  un  produit  de  développement précis, etc.  La  fonctionnalité  de  "client  instantané"  permet  d’établir  une  connexion  à  une  base  de  données  sans  configuration préalable d’Oracle Net (cf. Chapitre Oracle Net).  À la fin de l’installation, dans le cas d’une installation autre que InstantClient, l’assistant Configuration Oracle Net est  lancé, en mode automatique ou interactif selon le type d’installation, afin de configurer le composant Oracle Net. Dans  le  cas  d’une  installation  Runtime,  l’assistant  effectue  une  configuration  standard :  cliquez  simplement  sur  le  bouton  Suivant  puis  sur  le  bouton  Terminer.  Dans  le  cas  d’une  installation  Administrateur  ou  Personnalisée,  l’assistant  propose d’effectuer une configuration standard ou une configuration manuelle. La configuration standard est souvent  suffisante,  au  moins  pour  démarrer.  En  cas  de  besoin,  l’assistant  Configuration  Oracle  Net  peut  être  relancé  ultérieurement.  Pour  effectuer  une  configuration  standard,  cochez  la  case  Exécuter  la  configuration  standard  puis  cliquez sur le bouton Suivant (deux fois), puis sur le bouton Terminer.  Sur plate­forme Unix ou Linux, après en avoir terminé avec la configuration Oracle Net, il faut exécuter le script root.sh  dans une connexion root.  L’installation est alors terminée !  L’environnement de travail peut ensuite être configuré comme sur le serveur (cf. section Installation du serveur dans le  chapitre Installation).  À  ce  stade,  vous  pouvez  tester  une  connexion  avec  votre  base  en  utilisant  la  méthode  de  résolution  de  nom  Easy  Connect :  > sqlplus system/xxxx@//hôte/service Pour utiliser une autre méthode de résolution de nom, il faut configurer Oracle Net (cf. Chapitre Oracle Net).  Sur OTN, vous pouvez télécharger un client instantané (instant client) sous la forme d’une archive compressée  qui  s’installe  directement  par  décompression,  sans  utiliser  Oracle  Universal  Installer.  Pour  utiliser  ce  client  instantané,  il  faut  juste  ajouter  le  répertoire  d’installation  dans  la  variable  d’environnement  utilisée  pour  le  chargement des librairies (PATH sur plate­forme Windows et LD_LIBRARY_PATH sur plate­forme Unix ou Linux). 

- 2-

© ENI Editions - All rights reserved - Algeria Educ

Introduction  1. Rôle d’Oracle Net  Oracle  Net  permet  à  des  produits  Oracle  situés  sur  des  machines  différentes  de  communiquer.  Les  fonctions  essentielles d’Oracle Net sont d’établir des sessions de communication réseau entre deux machines (client ↔ serveur  ou serveur ↔ serveur) et de transférer les données entre les deux machines.  Dans  cet  ouvrage,  nous  nous  intéresserons  uniquement  à  la  communication  entre  un  client  et  un  serveur.  La  communication  entre  deux  serveurs  est  un  cas  particulier  où  un  serveur  joue  le  rôle  de  client  vis­à­vis  de  l’autre  serveur ; sur ce serveur client, Oracle Net doit être configuré à la fois en serveur et en client.  Oracle Net a pour objectif de rendre le réseau "transparent" pour les applications : les applications n’ont pas besoin  de  savoir  où  se  trouve  le  serveur,  quel  est  le  protocole  à  utiliser  pour  s’y  connecter,  etc.  Les  applications  ont  simplement besoin de connaître un nom de service réseau (sorte d’alias) qui leur permettra d’établir une connexion  avec la base de données souhaitée.  Oracle Net doit être installé côté client et côté serveur ; cette installation est réalisée par défaut par Oracle Universal  Installer. Après installation, la couche Oracle Net doit être configurée, là encore, côté client et côté serveur. 

2. Principes de fonctionnement  Le schéma suivant illustre le fonctionnement (simplifié) d’Oracle Net : 

  Lorsqu’une  application  cliente  utilise  un  nom  de  service  réseau  pour  se  connecter,  ce  nom  de  service  réseau  est  résolu par Oracle Net en un descripteur de connexion comportant l’adresse du service : protocole à utiliser, adresse  du serveur, port de communication (dans le cas du protocole TCP) et nom du service (instance dans le cas qui nous  intéresse).  Côté serveur, un processus d’écoute est chargé de recevoir les demandes de connexion et de les transmettre à la  base concernée. Ce processus d’écoute se matérialise par un service sur plate­forme Windows et un processus sur  plate­forme Unix ; il est configuré par le fichier listener.ora.  Plusieurs méthodes peuvent être utilisées pour la résolution du nom de service :  Locale (local naming)  Un  fichier  de  configuration  (tnsnames.ora),  situé  sur  le  poste  de  l’utilisateur,  se  charge  de  la  résolution.  Cette 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

méthode est la plus couramment utilisée.  Connexion simplifiée (easy connect naming)  La connexion s’effectue sans nom de service, en utilisant directement une adresse TCP/IP du type [//]hôte[:port] [/service].  Cette  méthode  est  utilisable  uniquement  en  environnement  TCP/IP.  Elle  ne  nécessite  aucune  configuration mais le réseau n’est plus transparent pour l’utilisateur. Cette méthode est apparue en version 10.  Annuaire LDAP (directory naming)  Un annuaire LDAP se charge de la résolution. Cette méthode nécessite un produit tiers.  Externe  Un produit tiers se charge de la résolution.  Par défaut (configuration standard), Oracle Net est configuré côté client pour utiliser la méthode de résolution de nom  locale et la connexion simplifiée (si TCP/IP est installé sur le poste client). 

3. Nom de service et nom d’instance  Depuis  Oracle8i,  une  instance  peut  être  identifiée  par  un  ou  plusieurs  noms  de  service,  en  plus  de  l’identifiant  de  l’instance (SID). Ces noms de service peuvent être définis grâce au paramètre SERVICE_NAMES du fichier d’initialisation.  L’identifiant de l’instance peut être vu comme étant le nom "physique" de l’instance. Le nom de service de l’instance  peut être vu comme un nom logique, correspondant à un service offert par la base de données ouverte par l’instance.  Par  exemple,  si  une  base  abrite  deux  applications  (une  application  de  paie  et  une  application  de  gestion  des  ressources humaines), il est possible de définir deux noms de service pour l’instance :  SERVICE_NAMES = paie,rh Un nom de service peut inclure une identification de domaine. Exemple : paie.olivier.fr.  Par  défaut,  le  paramètre  SERVICE_NAMES  est  égal  au  nom  global  de  la  base  de  données  (DB_NAME.DB_DOMAIN).  Si  le  paramètre DB_DOMAIN est vide (valeur par défaut), le paramètre SERVICE_NAMES est alors égal par défaut au paramètre  DB_NAME, qui est lui­ même généralement égal au nom de l’instance ; dans ce cas, nom de service et nom d’instance  sont égaux.  Lors de la définition d’un nom de service réseau, il est possible de désigner l’instance cible, soit par son identifiant,  soit par un nom de service.  Les services sont aussi utilisés par Oracle pour faire un suivi d’activité par service (charge, performance, priorité, etc.).  Ils peuvent être gérés et supervisés dans le Database Control. Ils peuvent aussi être supervisés par plusieurs vues  du dictionnaire de données (DBA_ SERVICES, V$ACTIVE_SERVICES, etc.) et gérés par le package DBMS_SERVICE. 

- 2-

© ENI Editions - All rights reserved - Algeria Educ

Configuration côté serveur  1. Configuration du processus d’écoute  La configuration côté serveur consiste à configurer le processus d’écoute LISTENER, c’est­à­dire à indiquer "comment"  et pour quelles bases il "écoute".  Cette configuration peut s’effectuer directement dans le fichier listener.oramais cela nécessite de bien comprendre  la structure de ce fichier, ce qui n’est pas immédiat (voir l’exemple plus loin). Le plus simple consiste alors à utiliser  l’application Oracle Net Manager(menu Programmes ­ Oracle ­ nom_oracle_home ­ Outils de configuration et de  migration ­ Net Manager sur plate­forme Windows ou script shell netmgr sur plate­forme Unix). 

  Si  aucune  base  de  données  n’a  été  créée  durant  l’installation  d’Oracle,  aucun  processus  d’écoute  n’a  encore  été  créé ; dans ce cas, le dossier Processus d’écoute est vide. Pour créer un processus d’écoute, sélectionnez le menu  Modifier  ­  Créer  et  donnez  un  nom  au  processus  d’écoute  (par  exemple  LISTENER)  dans  la  boîte  de  dialogue  qui  s’affiche.  Le  fichier  listener.orase  trouve  par  défaut  dans  le  répertoire  $ORACLE_HOME/ network/admin  (plate­forme  Unix  ou  Linux) ou %ORACLE_HOME%\network\admin (plate­forme Windows). Cet emplacement peut être modifié en définissant la  variable d’environnement TNS_ADMIN.  Le  processus  d’écoute  peut  aussi  être  configuré  et  administré  à  partir  de  la  console  Oracle  Enterprise  Manager. 

Paramètres généraux

  La  configuration  des  paramètres  généraux  s’effectue  dans  les  trois  onglets  Général,  Journalisation  et  trace  et  Authentification. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

L’onglet  Journalisation  et  trace  permet  d’activer  ou  de  désactiver  la  journalisation  (active  par  défaut)  et  la  trace  (inactive  par  défaut).  Le  fichier  journal  enregistre  essentiellement  des  informations  sur  le  démarrage  du  processus  d’écoute et les demandes de connexion reçues. Depuis la version 11, ce fichier (nommé listener.log) se trouve par  défaut  dans  le  Référentiel  de  Diagnostic  Automatique  (Automatic  Diagnostic  Repository)  :  répertoire  $ORACLE_BASE/diag/tnslsnr/<nom hôte>/<nom listener>/trace  (plate­forme  Unix  ou  Linux)  ou  %ORACLE_BASE% \diag\tnslsnr\<nom hôte>/<nom listener>/trace  (plate­forme  Windows).  Pour  pouvoir  modifier  l’emplacement  par  défaut, il faut désactiver l’utilisation d’ADR ; tant que ce n’est pas le cas, les éventuelles modifications effectuées dans  Oracle Net Manager ne sont pas prises en compte. La trace peut être activée pour aider à résoudre des problèmes  de fonctionnement du processus d’écoute. Là encore, depuis la version 11, les fichiers de traces sont enregistrés par  défaut dans ADR, au même emplacement que le fichier journal.  L’onglet Authentification permet de définir un mot de passe à utiliser pour lancer l’utilitaire lsnrctl (voir plus loin).  Lorsque les paramètres généraux sont personnalisés, ils sont enregistrés dans le fichier listener.ora.  Exemple :  PASSWORDS_LISTENER= (54290B53985ADB21 ) TRACE_LEVEL_LISTENER = USER Emplacements d’écoute

  Les  emplacements  d’écoute  sont  des  adresses  réseaux  utilisées  par  le  processus  d’écoute  pour  recevoir  les  demandes de connexion à une base de données.  Le  processus  d’écoute  peut  écouter  à  plusieurs  adresses  (pour  des  protocoles  différents,  pour  des  variantes  du  même protocole ­ par exemple deux ports en TCP/IP, etc.).  La configuration de l’emplacement d’écoute dépend du protocole :  ●

●

●

TCP/IP : indique le nom ou l’adresse IP du serveur et le port de communication (1521 par défaut).  IPC  (Interprocess Communication) :  indique  un  nom  unique  de  service  (nom  de  l’instance  pour  une  base  de  données).  NMP (Named Pipes) : indique le nom du serveur et le nom du canal (typiquement ORAPIPE). 

Les définitions des emplacements d’écoute sont enregistrées de la manière suivante dans le fichier listener.ora :  LISTENER = (DESCRIPTION_LIST =

- 2-

© ENI Editions - All rights reserved - Algeria Educ

(DESCRIPTION (ADDRESS = ) (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 (Oracle<nom_oracle_home>TNSListener) sur plate­forme Windows  et par un processus (tnslsnr) sur plate­forme Unix ou Linux.  Le processus d’écoute s’administre grâce à l’utilitaire lsnrctl, disponible sur toutes les plates­formes.  Syntaxe :  lsnrctl [commande]  Lorsque l’utilitaire est appelé sans commande, il se lance et affiche une invite :  LSNRCTL> Les commandes peuvent alors être saisies sur la ligne d’invite.  Les principales commandes sont les suivantes :  HELP  Affiche la liste des commandes.  HELP commande  Affiche l’aide d’une commande.  START  Démarre le processus d’écoute.  STOP  Arrête le processus d’écoute.  STATUS  Affiche  des  informations  sur  la  configuration  du  processus  d’écoute,  les  emplacements  d’écoute  et  les  services  enregistrés.  SERVICES  Affiche des informations détaillées sur les services enregistrés auprès du processus d’écoute.  RELOAD  Recharge  la  configuration  du  processus  d’écoute  (listener.ora).  Permet  d’ajouter  ou  de  modifier  les  services  enregistrés auprès du processus d’écoute, sans arrêter ce dernier.  Les commandes peuvent être saisies indifféremment en majuscules ou en minuscules. Sur plate­forme  Windows,  le  processus d’écoute peut aussi être démarré et arrêté en démarrant ou en arrêtant le service associé.  Exemple :  C:\>lsnrctl LSNRCTL for 32-bit Windows: Version 11.1.0.6.0 - Production on 22-JUIN -2008 21:26:04 Copyright (c) 1991, 2007, Oracle. All rights reserved. Bienvenue dans LSNRCTL, tapez "help" pour plus d’informations. LSNRCTL> status Connexion à (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521))) STATUT du PROCESSUS D’ECOUTE ---------------------------Alias LISTENER Version TNSLSNR for 32-bit Windows: Version 11.1.0.6.0 - Production Date de départ 22-JUIN -2008 21:12:45 Durée d’activité 0 jours 0 heures 13 min. 25 sec Sécurité ON: Local OS Authentication SNMP OFF

- 4-

© ENI Editions - All rights reserved - Algeria Educ

Fichier de paramètres du processus d’écoute D:\app\oracle\product\ 11.1.0\db_1\network\admin\listener.ora Fichier journal du processus d’écoute d:\app\oracle\diag\tnslsnr\srvwinora\listener\alert\ log.xml Récapitulatif d’écoute des points d’extrémité... (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\pipe\EXTPROC1521ipc))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=srvwinora)(PORT=1521))) Récapitulatif services... Le service "ORCL" comporte 1 instance(s). L’instance "ORCL", statut UNKNOWN, comporte 1 gestionnaire(s) pour ce service La commande a réussi LSNRCTL> Sur plate­forme Windows, si le service associé au processus d’écoute n’existe pas, un message d’erreur est affiché  lors du démarrage, mais le service est alors automatiquement créé et le processus d’écoute est bien démarré :  LSNRCTL> start Starting tnslsnr: please wait... Failed to open service , error 1060.

3. Démarrage automatique du processus d’écoute  Généralement,  il  est  souhaitable  que  le  processus  d’écoute  soit  démarré  automatiquement  lors  du  démarrage  du  système.  Sur plate­forme Windows, le processus d’écoute peut être démarré automatiquement lors du démarrage du système,  en positionnant le service associé (Oracle<nom_oracle_ home>TNSListener) en démarrage automatique.  Sur  plate­forme  Unix  ou  Linux,  le  processus  d’écoute  peut  être  démarré  automatiquement  grâce  au  script  de  démarrage  présenté  dans  la  section  Installation  du  serveur  du  chapitre  Installation  ­  Configurer  le  démarrage  et  l’arrêt  automatique.  Ce  script  de  démarrage  appelle  les  scripts  Oracle dbstart  et dbshut qui prennent en charge le  démarrage et l’arrêt du processus d’écoute depuis la version 11.  Extraits du script :  $ORACLE_HOME/bin/dbstart $ORACLE_HOME_LISTENER > $LOG 2>&1 & ... $ORACLE_HOME/bin/dbshut $ORACLE_HOME_LISTENER > $LOG 2>&1 & Les scripts dbstart et dbshut acceptent en paramètre le chemin Oracle Home du processus d’écoute à démarrer ou à  arrêter ; s’il y a plusieurs versions d’Oracle installées sur le serveur, cela permet de choisir la version du processus  d’écoute à utiliser. 

4. Enregistrement dynamique de services  Depuis Oracle8i, une instance est capable d’enregistrer automatiquement des services auprès du processus d’écoute.  Aucune configuration n’est requise dans le fichier listener.ora.  L’enregistrement  automatique  s’effectue par défaut auprès du processus d’écoute  sur  le  serveur,  en  TCP/IP,  sur  le  port  1521.  Pour  effectuer  l’enregistrement  automatique  à  une  autre  adresse,  il  faut  configurer  le  paramètre  d’initialisation  LOCAL_LISTENER  en  y  indiquant  un  nom  de  service  réseau  qui  doit  être  résolu  (par  exemple  avec  le  fichier tnsnames.ora) en une adresse de processus d’écoute.  Les noms des services automatiquement enregistrés proviennent du paramètre d’initialisation SERVICES_NAMES.  L’enregistrement  dynamique  s’effectue  en  complément  de  l’enregistrement  statique  éventuellement  défini  dans  le  fichier listener.ora.  Avec  ces  deux  mécanismes,  une  instance  peut  présenter  plusieurs  services  dans  le  processus  d’écoute, ce qui est parfois déroutant.  Avec  l’enregistrement  automatique,  une  instance  non  démarrée  n’est pas connue du processus d’écoute.  Cela  pose  un  problème  si  l’instance  doit  être  démarrée  à  partir  d’un  poste  du  réseau  car  le  processus  d’écoute  refusera  la  demande  de  connexion  (erreur  ORA-12514).  Dans  ce  cas,  il  faut  prévoir  un  enregistrement  statique dans le fichier listener.ora. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 5-

Il  peut  y  avoir  d’autres  services  enregistrés  auprès  du  processus  d’écoute  correspondant  à  des  fonctionnalités installées dans la base de données (Oracle XML DB par exemple). 

- 6-

© ENI Editions - All rights reserved - Algeria Educ

Configuration côté client  1. Introduction  Pour configurer le client, il faut :  ●

sélectionner les méthodes de résolution de noms utilisables par le client ; 

●

configurer les méthodes de résolution de noms sélectionnées. 

Les méthodes de résolution de noms utilisables par le client sont stockées dans le fichier sqlnet.ora. Si la méthode  de résolution de nom locale est utilisée, il faut en plus définir un ou plusieurs noms de service réseau dans le fichier  tnsnames.ora.  Ces deux fichiers se trouvent par défaut dans le répertoire $ORACLE_HOME/network/ admin (plate­forme Unix ou Linux)  ou  %ORACLE_HOME%\network\admin  (plate­forme  Windows).  Cet  emplacement  peut  être  modifié  en  définissant  la  variable d’environnement TNS_ADMIN.  Les fichiers sqlnet.ora et tnsnames.ora peuvent être édités directement mais cela nécessite de bien comprendre leur  structure et de bien connaître la syntaxe et le rôle des différents paramètres.  Le  plus  simple  consiste  alors  à  utiliser  l’application  Oracle  Net  Manager  (menu  Programmes ­ Oracle ­ nom_oracle_home ­ Outils  de  configuration  et  de  migration ­ Net  Manager  sur  plate­forme  Windows  ou  script  shell netmgr sur plate­forme Unix). 

2. Sélection des méthodes de résolution de noms  Pour  configurer  les  méthodes  de  résolution  de  noms  utilisables  par  le  client,  cliquez  sur  l’icône  Profil,  puis  sélectionnez l’élément Affectation de noms dans la liste déroulante : 

  Dans  une  configuration  standard,  la  méthode  de  résolution  de  nom  locale  (TNSNAMES)  et  la  méthode  de  connexion  simplifiée (EZCONNECT) sont sélectionnées par défaut. En utilisant les différents boutons de ce panneau, il est possible  d’ajouter ou de supprimer des méthodes et de modifier l’ordre dans lequel les méthodes seront utilisées : 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

  Sur l’exemple précédent, la méthode de résolution de nom d’hôte (HOSTNAME) a été ajoutée dans la liste.  La zone Domaine par défaut permet d’ajouter un nom de domaine par défaut aux noms de service réseau utilisés.  Ce  nom  de  domaine  par  défaut  est  souvent  une  source  de  problème.  S’il  est  défini  (valeur  X  par  exemple),  il  est  automatiquement ajouté au nom de service réseau lors de la connexion, si aucun domaine n’est indiqué (CONNECT ... @ORCL devient  CONNECT ... @ORCL.X). Si le nom de service ainsi constitué (ORCL.X) ne peut pas être résolu par une  des méthodes de résolution de nom, une erreur est retournée (erreurORA-12154). Pour éviter ce genre de problème,  le plus simple est de ne pas définir de nom de domaine par défaut.  Les différentes informations saisies dans cet écran sont enregistrées dans le fichier sqlnet.ora.  Exemple :  NAMES.DIRECTORY_PATH= (EZCONNECT, TNSNAMES, HOSTNAME) # NAMES.DEFAULT_DOMAIN = X Le paramètre NAMES.DIRECTORY_PATH contient la liste ordonnée des méthodes de résolution de nom utilisables.  Le paramètre NAMES.DEFAULT_DOMAIN (ici en commentaire) contient le nom de domaine par défaut. 

3. Configuration des méthodes de résolution de nom  a. Résolution de nom locale  Des  noms  de  service  réseau  peuvent  être  définis  dans  le  fichiertnsnames.ora  avec  l’application  Oracle  Net  Manager : 

  Pour afficher la liste des noms de service réseau déjà définis, double cliquez sur le dossier Résolution de noms de  service.  Pour  créer  un  nouveau  nom  de  service  réseau,  sélectionnez  le  dossier  Résolution  de  noms  de  service  puis  sélectionnez le menu Modifier ­ Créer. 

- 2-

© ENI Editions - All rights reserved - Algeria Educ

  Saisissez le nom de service réseau souhaité puis cliquez sur le bouton Suivant. 

  Sélectionnez le protocole réseau utilisé (TCP/IP dans cet exemple) puis cliquez sur le bouton Suivant. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 3-

  Les paramètres du protocole dépendent du protocole sélectionné. Dans le cas du protocole TCP/IP, saisissez le nom  du serveur Oracle ou son adresse IP et le numéro du port (1521 par défaut, mais si un autre port a été configuré  pour le processus d’écoute, utilisez le même ici).  Dans  le  cas  du  protocole  IPC,  vous  devez  indiquer  un  nom  de  clé  (reprendre  la  valeur  utilisée  pour  le  processus  d’écoute, généralement le nom de l’instance). Dans le cas du protocole Named Pipes, vous devez indiquer le nom de  la machine et le nom du canal (reprendre la valeur utilisée pour le processus d’écoute, habituellement ORAPIPE).  Cliquez sur le bouton Suivant. 

  Pour  identifier  l’instance  cible,  saisissez  au  choix  un  nom  de  service  ou  un  identifiant  d’instance  (SID).  Le  nom  de  service doit être un des noms de service enregistrés auprès du processus d’écoute (cf. section Configuration côté  serveur dans ce chapitre).  La liste déroulante Type  de  connexion permet de définir le type de connexion souhaité : Valeur par défaut de la  base de données (valeur par défaut), Serveur dédié ou Serveur partagé. Le choix de l’option Serveur dédié est  nécessaire pour forcer une connexion à un serveur dédié alors que le serveur est configuré en serveur partagé.  Cliquez sur le bouton Suivant ; l’écran suivant permet de tester le nouveau nom de service réseau. 

- 4-

© ENI Editions - All rights reserved - Algeria Educ

Cliquez  sur  le  bouton  Terminer.  Le  nouveau  nom  de  service  réseau  apparaît  dans  le  dossier ;  il  peut  être  sélectionné et modifié directement si besoin : 

  Les noms de service réseau ainsi définis, sont enregistrés dans le fichier tnsnames.ora.  Exemple :  ORCL = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = SRVWINORA)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = ORCL) ) ) Après  configuration  du  processus  d’écoute  côté  serveur,  il  est  judicieux,  en  restant  sur  le  serveur,  de  configurer  un  nom  de  service  réseau  et  de  tenter  une  connexion  à  l’aide  de  ce  nom  afin  de  tester  la  configuration.  Ensuite,  si  la  configuration  d’un  poste  ne  fonctionne  pas,  la  configuration  du  serveur  ne  sera,  a  priori,  pas  en  cause.  De  plus,  si  le  serveur  héberge  plusieurs  bases  de  données,  les  noms  de  service  réseau  pourront  être  utilisés  pour  passer  rapidement  d’une  base  à  l’autre  (pas  besoin  de  modifier  la  variable  d’environnement ORACLE_SID).  Le  fichier  tnsnames.ora  ne  contient  aucune  information  relative  au  poste ;  il  est  donc  parfaitement  possible  d’en  créer un sur un poste puis de le diffuser sur tous les autres postes. 

b. Connexion simplifiée  La méthode de résolution de nom Easy Connect ne nécessite aucune configuration côté client et peut être utilisée  directement,  si  elle  a  été,  au  préalable,  sélectionnée  comme  méthode  de  résolution  de  nom  dans  le  fichier  sqlnet.ora(cf.  section Configuration  des  méthodes  de  résolution  de  nom  dans  ce  chapitre).  Cette  méthode  est  apparue en version 10 et est utilisable uniquement en environnement TCP/IP.  L’adresse de connexion est définie de la manière suivante :  [//]hôte[:port][/service] Avec :  hôte 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 5-

Nom du serveur (éventuellement qualifié par un domaine) ou adresse IP du serveur.  port  Port utilisé par le processus d’écoute (1521 par défaut).  service  Nom  de  service  auquel  se  connecter.  Le  nom  de  service  doit  être  un  des  noms  de  service  enregistrés  auprès  du  processus d’écoute (cf. section Configuration côté serveur dans ce chapitre). Si le nom de service n’est pas spécifié,  le  processus  se  connecte  à  la  base  définie  par  le  paramètre  DEFAULT_SERVICE_<nom_listener>  dans  le  fichier  listener.ora.  Exemple :  srvwinora/orcl srvwinora:1522/test.olivier.fr

- 6-

© ENI Editions - All rights reserved - Algeria Educ

Problèmes courants et solutions  Les problèmes possibles de connexion entre un client et un serveur sont nombreux.  ORA-12541: TNS : pas de processus d’écoute TNS-12541: TNS : aucun processus d’écoute Explication  Le serveur spécifié par la chaîne de connexion a bien été trouvé, mais aucun processus d’écoute ne répond.  Cause(s)  Le processus d’écoute n’est pas lancé.Le port indiqué dans la chaîne de connexion ne correspond pas au port d’écoute  du processus d’écoute.  Action(s)  Vérifier  que  les  ports  sont  bien  configurés  de  la  même  manière  côté  client  et  côté  serveur.  Vérifier  si  le  processus  d’écoute est démarré (le démarrer si besoin (ne pas hésiter à le redémarrer en cas de doute)).  ORA-12505: TNS : le processus d’écoute ne connaît pas actuellement le SID indiqué dans le descripteur de connexion ORA-12514: TNS : le processus d’écoute ne connaît pas actuellement le service demandé dans le descripteur de connexion Explication  Le  processus  d’écoute  a  bien  été  contacté  mais  le  SID  ou  le  SERVICE_NAME  indiqué  dans  la  chaîne  de  connexion  ne  correspond à aucune instance écoutée par le processus d’écoute.  Cause(s)  Le  SID  ou  SERVICE_NAME  indiqué  dans  la  chaîne  de  connexion  n’est  pas  bon.  Le  SID_NAME  spécifié  dans  le  fichier  de  configuration du processus d’écoute n’est pas bon.  Action(s)  Vérifier que les identifiants d’instance ou les noms de service correspondent bien entre le client et le serveur (utiliser la  commande status ou services dans l’utilitaire lsnrctl). En cas de doute, utiliser un SID à la place d’un SERVICE_NAME  dans la chaîne de connexion.  ORA-12545: Connexion impossible car l’hôte ou l’objet cible n’existe pas TNS-12545: la connexion a échoué car l’hôte ou l’objet cible n’existe pas Explication  Le serveur indiqué dans la chaîne de connexion n’a pas pu être contacté.  Cause(s)  Le nom du serveur est erroné.  Action(s)  Vérifier la validité du nom du serveur. Éventuellement, remplacer le nom du serveur par son adresse IP. Vérifier si le  serveur est accessible.  ORA-12170: TNS : délai de connexion dépassé

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

TNS-12535: TNS : le délai imparti à l’opération est écoulé Explication  Le serveur indiqué dans la chaîne de connexion n’a pas pu être contacté dans le délai imparti (défini par le paramètre  SQLNET. INBOUND_CONNECT_TIMEOUT du fichier sqlnet.ora côté client).  Cause(s)  Le nom du serveur (ou l’adresse IP) est erroné. Le serveur n’est pas accessible ou il y a un problème réseau (coupure,  ralentissement).  Action(s)  Vérifier la validité du nom du serveur ou de l’adresse IP. Éventuellement, remplacer le nom du serveur par son adresse  IP.  Vérifier  si  le  serveur  est  accessible  et  s’il  n’y  a  pas  de  problème  réseau.  Modifier  la  valeur  du  paramètre  SQLNET.INBOUND_CONNECT_ TIMEOUT.  ORA-12154: TNS : l’identificateur de connexion indiqué n’a pas pu être résolu TNS-03505: Echec de la résolution du nom Explication  Le nom de service réseau utilisé pour la connexion (@) n’a pas pu être résolu par une des méthodes de résolution de  nom autorisées côté client.  Cause(s)  Le  nom  de  service  réseau  utilisé  dans  la  connexion  est  erroné  (faute  de  frappe).  Il  n’existe  par  de  nom  de  service  réseau correspondant dans le fichier tnsnames.ora (méthode de résolution locale). Le nom de service réseau n’a pas  pu être traduit en adresse IP (méthode de résolution de nom d’hôte). Le nom de service réseau n’a pas pu être résolu  en hôte[:port] [/service] (connexion simplifiée).  Action(s)  Vérifier  que  les  méthodes  de  résolution  de  nom  souhaitées  sont  bien  configurées  dans  le  fichier  sqlnet.ora.  Si  la  méthode de résolution de nom local est utilisée, vérifier que le nom de service réseau utilisé dans la connexion est bien  défini dans le fichier tnsnames.ora (penser notamment à l’existence éventuelle d’un nom de domaine par défaut défini  dans  le  fichier  sqlnet.ora).  Si  une  autre  méthode  de  résolution  de  nom  est  utilisée,  vérifier  que  la  syntaxe  et  la  configuration sont correctes.  Si  vous  obtenez  une  erreur  ORA-01033  ou  ORA-01034,  la  configuration  Oracle  Net  n’est  pas  en  cause ;  l’instance  est  arrêtée, ou elle est démarrée mais la base n’est pas ouverte.  Pour aider à établir un diagnostic, l’utilitaire tnsping peut être utilisé côté client.  Syntaxe :  tnsping nom_de_service  L’utilitaire tnsping teste si le nom de service passé en paramètre peut être résolu et si la cible peut être contactée.  En cas de succès, tnsping affiche le nom de la méthode de résolution de nom utilisée, la chaîne de connexion utilisée et  le  temps  mis  pour  contacter  la  cible.  En  cas  d’échec,  tnsping  affiche  un  message  d’erreur,  ainsi  que  le  nom  de  la  méthode de résolution de nom utilisée et la chaîne de connexion utilisée, s’il a pu résoudre le nom de service réseau.  Exemples  C:\>tnsping orcl TNS Ping Utility for 32-bit Windows: Version 11.1.0.6.0 - Production on 24-JUIN-2008 06:52:18 Copyright (c) 1997, 2007, Oracle. All rights reserved. Fichiers de paramètres utilisés : C:\app\oracle\product\11.1.0\client_1\network\admin\sqlnet.ora Adaptateur TNSNAMES utilisé pour la résolution de l’alias Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = SRVWINORA)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = ORCL))) - 2-

© ENI Editions - All rights reserved - Algeria Educ

OK (30 msec) C:\>tnsping srvwinora/orcl … Fichiers de paramètres utilisés : C:\app\oracle\product\11.1.0\client_1\network\admin\sqlnet.ora Adaptateur EZCONNECT utilisé pour la résolution de l’alias Attempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=orcl)) (ADDRESS=(PROTOCOL=TCP)(HOST=192.168.154.51)(PORT=1521))) OK (20 msec) L’utilitaire tnsping teste uniquement si un processus d’écoute peut être contacté ; il ne teste pas si le nom de  service ou l’identifiant d’instance est connu du processus d’écoute. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 3-

Introduction  Oracle propose plusieurs outils d’administration :  ●

●

●

●

SQL*Plus : outil de base permettant d’éditer et d’exécuter des requêtes SQL.  Oracle  Enterprise  Manager  Database  Control :  application  Web,  permettant  d’administrer  graphiquement  une  seule base de données.  Oracle  Enterprise  Manager  Grid  Control :  application  Web,  similaire  à  la  précédente,  permettant  d’administrer  de manière centralisée plusieurs bases de données.  Oracle SQL Developer : application graphique permettant d’exécuter des requêtes ou des scripts SQL, de gérer  les  objets  d’une  base  de  données  (tables,  vues,  etc.)  et  de  développer  et  mettre  au  point  des  programmes  PL/SQL. 

Oracle  Enterprise  Manager  Grid  Control  est  une  infrastructure  d’administration  composée  d’un  serveur  d’application,  d’un référentiel stocké dans une base de données Oracle et d’agents installés sur les différents nœ uds administrés. Ce  produit  qui  nécessite  une  installation  séparée  est  intéressant  pour  les  entreprises  ayant  un  très  grand  nombre  de  bases de données à administrer. Pour les entreprises ayant quelques bases à administrer, la version Database Control  est généralement suffisante. Oracle Enterprise Manager Grid Control n’est pas présenté dans cet ouvrage.  Sur  plate­forme  Windows,  Oracle  propose  aussi  l’application  Oracle  Administration  for  Windows  (menu  Démarrer  ­  Programmes ­  Oracle ­ nom_oracle_home  ­ Outils  de  configuration  et  de  migration ­  Assistant  d’administration  pour Windows). Cette application requiert le produit Microsoft Management Console.  Dans  cet  ouvrage,  nous  nous  intéresserons  uniquement  à  SQL*Plus,  à  Oracle  SQL  Developer  et  à  Oracle  Enterprise  Manager Database Control.  En  complément,  dans  ce  chapitre,  nous  présenterons  brièvement  la  documentation  Oracle  (un  autre  « outil »  d’administration bien pratique !) puis nous parlerons des fichiers d’alerte et de trace, ainsi que du nouveau Référentiel  de Diagnostic Automatique (Automatic Diagnostic Repository). 

© ENI Editions - All rights reserved - Algeria Educ

- 1-

SQL*Plus  1. Vue d’ensemble  Depuis  la  version  11,  SQL*Plus  est  disponible  uniquement  en  version  ligne  de  commande.  Les  anciennes  formes  SQL*Plus Windows, SQL*Plus Worksheet et iSQL*Plus n’existent plus.  SQL*Plus  permet  de  saisir  et  d’exécuter  des  ordres  SQL  ou  du  code  PL/SQL  et  dispose  en  plus  de  plusieurs  commandes, dont des commandes d’administration.  La  connexion  peut  s’effectuer  localement  à  l’instance  définie  par  la  variable  d’environnement  ORACLE_SID(section  Installation du serveur du chapitre Installation) ou bien à travers le réseau à l’instance définie par un nom de service  réseau ou une identification de >connexion simplifiée (cf. section Configuration côté client du chapitre Oracle Net).  Pour  la  connexion  à  travers  le  réseau,  le  nom  de  service  réseau  ou  l’identification  de  connexion  simplifiée  peuvent  être indiqués lors du lancement de l’outil (voir ci­après) ou être définis dans une variable d’environnement :  ●

TWO_TASK sur plate­forme Linux ou Unix ; 

●

LOCAL sur plate­forme Windows (éventuellement dans la base de registre). 

Exemple :  $ export TWO_TASK=orcl $ export TWO_TASK=srvlinora:1521/orcl C:\>set LOCAL=orcl C:\>set LOCAL=srvwinora:1521/orcl La variable d’environnement TWO_TASK ou LOCAL est prioritaire sur la variable d’environnement ORACLE_SID.  SQL*Plus propose beaucoup de commandes souvent très utiles pour écrire des scripts d’administration. Pour  plus d’informations, reportez­vous à la documentation SQL*Plus® User’s Guide and Reference. 

2. Utilisation  a. Lancer SQL*Plus  La syntaxe pour lancer SQL*Plus en ligne de commande est la suivante :  sqlplus [ connexion | /NOLOG] [@fichier_script [argument [,...]]] Syntaxe de l’option connexion :  [utilisateur]/[mot_de_passe][@service] [AS SYSDBA | AS SYSOPER] Avec :  utilisateur  Nom de l’utilisateur Oracle.  mot de passe  Mot de passe de l’utilisateur.  service  Nom de service réseau ou identification de connexion simplifiée, utilisé(e) pour la connexion. 

openmirrors.com

  © ENI Editions - All rights reserved - Algeria Educ

- 1-

AS SYSDBA |AS SYSOPER  Demande une connexion SYSDBA ou SYSOPER.  /NOLOG  Lance SQL*Plus sans établir de connexion.  fichier_script  Script à exécuter.  argument  Paramètre du script à exécuter.  Appeler SQL*Plus sans paramètre sur la ligne de commande provoque l’affichage d’une invite de connexion.  L’option /NOLOG permet de lancer SQL*Plus sans établir de connexion ; dans ce cas, la connexion peut être établie  ensuite avec la commande CONNECT.  Lorsqu’un script est soumis à SQL*Plus sur la ligne de commande, la connexion peut être assurée par la ligne de  commande ou par le script (dans ce cas, mettre l’option  /NOLOG sur la ligne de commande). Par ailleurs, à la fin du  script, SQL*Plus ne quitte pas ; en cas de besoin, il faut donc penser à mettre une commande EXIT.  Exemple :  sqlplus 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  plate­forme  Windows, SQL*Plus accepte le séparateur / (à la place de \) dans la spécification d’un chemin.  Exemple  SQL> @?/rdbms/admin/utlpwdmg

d. Exécuter une commande du système d’exploitation  La commande  HOST permet d’exécuter une commande du système d’exploitation à partir de SQL*Plus, notamment  dans un script SQL.  Syntaxe  HOST commande Exemple  SQL> HOST copy d:\app\oracle\oradata\orcl\system01.dbf g:\app\oracle\ oradata\orcl\system01.dbf 1 fichier(s) copié(s). Sur plate­forme Unix ou Linux, le point d’exclamation (!) peut être utilisé à la place de la commande HOST. 

e. Utiliser des variables de substitution  SQL*Plus  permet  d’utiliser  des  variables  de  substitution  dans  l’exécution  des  ordres  SQL,  notamment  dans  un  script.  Une variable de substitution est définie par un nom précédé du caractère &. Elle peut être utilisée pour substituer  une  valeur  à  tout  élément  de  l’ordre  SQL :  valeur  dans  une  clause  WHERE,  nom  de  colonne,  nom  de  table,  clause  WHERE complète, etc.  Lors  de  l’exécution d’un  ordre  SQL,  si  SQL*Plus  rencontre  une  variable  de  substitution  non  définie,  il  affiche  une  invite permettant de saisir une valeur.  Il est possible de contrôler l’invite et d’affecter une valeur à une variable de substitution avant l’exécution de l’ordre  SQL grâce à la commande ACCEPT.  Syntaxe  ACC[EPT] variable [NUM[BER]|CHAR|DATE] [FOR[MAT] format] [DEF[AULT] défaut] [PROMPT texte|NOPR[OMPT]] [HIDE] Avec  variable  Nom de la variable de substitution (sans le caractère &).  format 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 3-

Format de saisie (mêmes conventions que celles utilisées dans l’option FORMAT de la commande COLUMN).  défaut  Valeur par défaut si aucune valeur n’est saisie.  texte  Texte de l’invite (à mettre entre apostrophes ou entre guillemets si le texte contient des espaces).  HIDE  Permet de masquer la saisie (comme pour un mot de passe).  Une variable de substitution peut aussi être définie, sans intervention de l’utilisateur, grâce à la commande DEFINE.  Syntaxe  DEFINE variable = valeur Avec  variable  Nom de la variable de substitution (sans le caractère &).  valeur  Valeur de la variable (à mettre entre apostrophes ou entre guillemets si la valeur contient des espaces).  Par défaut, lorsque SQL*Plus effectue une substitution, il affiche un message donnant l’ordre SQL avant et après la  substitution.  Il  est  possible  d’activer  ou  de  désactiver  cette  fonctionnalité  grâce  à  la  commande SET VERIFY ON | OFF.  Exemple de script info.sql utilisant des variables de substitution  ACCEPT colonnes CHAR DEFAULT empno PROMPT "Colonne(s) : " ACCEPT nom CHAR PROMPT " Nom : "SELECT &colonnes FROM emp WHERE ename = UPPER(’&nom’); Exécution du script dans SQL*Plus (saisie en gras)  SQL> @info Colonne(s) : job Nom : blake old 1: SELECT &colonnes FROM emp WHERE ename = UPPER(’&nom’) new 1: SELECT job FROM scott.emp WHERE ename = UPPER(’blake’) JOB --------MANAGER SQL> SET VERIFY OFFSQL> @info Colonne(s) : empno,job,sal Nom : king EMPNO JOB SAL --------- --------- --------7839 PRESIDENT 5000 Notez que dans le deuxième cas, la substitution effectuée par SQL*Plus n’est pas affichée (résultat de la commande  SET VERIFY OFF).  Lorsque la variable est immédiatement suivie d’une lettre, d’un chiffre, d’un point ou d’un souligné, il est nécessaire  d’utiliser un point pour bien délimiter la fin du nom de la variable.  Exemple : 

- 4-

© ENI Editions - All rights reserved - Algeria Educ

SQL> DEFINE prefixe=user_ SQL> SELECT COUNT(*) FROM &prefixetables; Enter value for prefixetables: Sur cet exemple, SQL*Plus considère que le nom de la variable est prefixetables (et il demande sa valeur puisque  cette variable n’est pas définie).  Solution :  SQL> SELECT COUNT(*) FROM &prefixe.tables; old 1: SELECT COUNT(*) FROM &prefixe.tables new 1: SELECT COUNT(*) FROM user_tables COUNT(*) ---------638 Avec le point après le nom de la variable, le problème ne se pose plus.  Le problème ne se pose pas si le caractère qui suit est un délimiteur du type /, -, $, #, etc. En cas de doute, le point  peut de toute façon être utilisé. 

f. Passer des valeurs à un script  Les variables de substitution &1, &2, …  peuvent être utilisées pour faire référence aux paramètres présents sur la  ligne d’appel du script.  Exemple de script info.sql utilisant des paramètres passés sur la ligne d’appel du script  SET VERIFY OFF SELECT &1 FROM emp WHERE ename = UPPER(’&2’); Exécution du script dans SQL*Plus  SQL> @info job blake JOB -------MANAGER Exécution du script dans la ligne de commande SQL*Plus  > sqlplus scott/tiger @info.sql job blake ... JOB -------MANAGER La valeur passée en paramètre à un script doit être mise entre apostrophes ou entre guillemets si elle contient des  espaces (l’espace est le séparateur des paramètres). 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 5-

Oracle SQL Developer  Oracle SQL Developer est une application graphique permettant d’exécuter des requêtes ou des scripts SQL, de gérer  les  objets  d’une  base  de  données  (tables,  vues,  etc)  et  de  développer  et  mettre  au  point  des  programmes  PL/SQL.  Oracle SQL Developer est gratuit et peut être téléchargé directement sur le site OTN. La page d’accueil d’Oracle SQL  Developer  se  trouve  à  l’adresse  suivante  :  http://www.oracle.com/technology/products/database/sql_  developer/index.html. Vous trouverez notamment à cette adresse la documentation et des tutoriaux. Depuis la version  11 d’Oracle, Oracle SQL Developer est installé par défaut.  Sur  plate­forme  Windows,  Oracle  SQL  Developer  peut  être  lancé  par  le  menu  Démarrer  ­  Programmes  ­  Oracle  ­  nom_oracle_home ­ Développement d’applications ­ SQL Developer.  Sur  plate­forme  Unix  ou  Linux,  Oracle  SQL  Developer  peut  être  lancé  à  l’aide  du  $ORACLE_HOME/sqldeveloper/sqldeveloper.sh. L’application nécessite un environnement graphique. 

shell 

script 

Sur  plate­forme  Windows,  lors  du  premier  lancement,  il  est  possible  que  l’outil  demande  le  chemin  de  l’application  java.exe. Vous pouvez utiliser celle fournie par Oracle : %ORACLE_HOME%\jdk\bin\java.exe.  La fenêtre principale d’Oracle SQL Developer a l’allure suivante : 

  Dans  la  partie  gauche  de  la  fenêtre,  une  structure  arborescente  permet  de  naviguer  dans  les  objets  d’une  ou  de    plusieurs bases de données. Un clic sur le bouton  permet de définir une nouvelle connexion. Dans la partie droite de la fenêtre, la zone de travail permet d’éditer et d’exécuter des requêtes SQL et de visualiser le  résultat.  Dans l’ensemble, cet outil est très convivial et son apprentissage est aisé. Comme son nom l’indique, l’outil est plutôt  destiné  aux  développeurs  et  il  ne  propose  donc  aucune  fonctionnalité  d’administration.  Pour  plus  d’informations  sur  l’utilisation de cet outil, vous pouvez consulter la documentation "Oracle® Database SQL Developer User’s Guide". 

© ENI Editions - All rights reserved - Algeria Educ

- 1-

Oracle Enterprise Manager Database Control  1. Introduction  Oracle Enterprise Manager Database Control est un outil d’administration graphique accessible par un navigateur : il  est apparu en version 10g d’Oracle.  Lors de la création d’une base de données, Oracle vous propose d’administrer cette base de façon centralisée avec  Oracle Enterprise Manager Grid Control ou de façon locale avec Oracle Enterprise Manager Database Control.  Pour administrer la base avec le Grid Control (non traité dans cet ouvrage), il faut installer au préalable l’agent Oracle  Management Agent sur le système. Si ce n’est pas le cas, l’option n’est pas sélectionnable et l’administration avec le  Database Control est proposée par défaut.  Dans la suite de cet ouvrage, nous utiliserons principalement les expressions "Database Control" ou "console Oracle  Enterprise Manager" pour désigner l’outil Oracle Entreprise Manager Database Control.  Database Control propose toutes les fonctionnalités nécessaires à l’administration et à l’optimisation d’une base de  données Oracle. 

2. Architecture  Derrière  une  apparente  simplicité,  le  Database  Control  repose  sur  une  architecture  relativement  complexe.  Le  Database  Control  est  une  application  J2EE  qui  utilise  une  version  autonome  du  serveur  d’application  OC4J  (Oracle  Containers for J2EE). 

  Le  Database  Control  utilise  différents  composants  pour  surveiller  et  administrer  la  base  de  données  Oracle  et  son  environnement (serveur hôte, processus d’écoute) : 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

●

●

●

une  version  locale  du  service  Oracle  Management  Service  (OMS)  destiné  à  fonctionner  avec  la  base  de  données administrée ;  un référentiel (Oracle Management Repository) installé dans la base de données administrée (schémaSYSMAN),  destiné à stocker des informations utilisées par le Database Control ;  une version locale de l’agent (Oracle Management Agent) dont le rôle est de fournir des informations au service  OMS local. 

Côté client, un simple navigateur suffit pour utiliser la console ; le navigateur communique avec le service OMS, sur le  port 1158. Côté serveur, le service OMS et l’agent communiquent sur le port 3938.  Le compte  DBSNMP est utilisé par l’agent pour superviser et gérer la base de données. Le compte SYSMAN  est  utilisé  pour stocker le référentiel du Database Control ; il peut aussi être utilisé pour administrer la base de données.  Le  Database  Control  est  associé  à  une  base  de  données.  Si  plusieurs  bases  de  données  sont  présentes  sur  le  serveur, chaque base de données possède sa propre infrastructure (service OMS, agent, référentiel). Dans un tel cas  de figure, les ports utilisés sont différents : 5500 et 1830 pour la seconde base de données, par exemple.  Le fichier portlist.ini stocké dans le répertoire install donne la liste des ports utilisés par les différentes  bases de données présentes sur le serveur.  Les fichiers utilisés par le Database Control d’une base de données sont stockés dans deux répertoires :  ●

●

%ORACLE_HOME%\serveur_sid (plate­forme Windows) ou $ORACLE_HOME/serveur_sid (plate­forme Linux)  %ORACLE_HOME%\oc4j\j2ee\OC4J_DBConsole_serveur_sid  (plate­forme  $ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_serveur_sid (plate­forme Linux) 

Windows) 

ou

La  configuration  du  Database  Control  est  un  sujet  relativement  complexe  qui  est  décrit  dans  la  documentation  Oracle® Enterprise Manager Advanced Configuration. Vous trouverez notamment dans ce manuel comment effectuer  les tâches suivantes :  ●

configurer le Database Control lors de la création d’une base de données ; 

●

changer les mots de passe de SYSMAN et DBSNMP ; 

●

modifier les ports utilisés ; 

●

sécuriser le Database Control (c’est le cas par défaut en version 11). 

Sur MetaLink, vous trouverez aussi de nombreuses notes relatives au Database Control.  Dans cet ouvrage, nous verrons simplement comment Configurer le Database Control lors de la création d’une base  de données (cf. Chapitre Création d’une nouvelle base de données). 

3. Gérer le Database Control  Le Database Control peut être arrêté ou démarré grâce à l’utilitaire ligne de commande emctl.  Syntaxe :  emctl { start | stop | status } dbconsole Les commandes start et stop permettent respectivement de démarrer et d’arrêter la console ; la commande status  permet de voir le statut.  L’utilitaire  agit  sur  le  Database  Control  de  la  base  de  données  ouverte  par  l’instance  définie  par  la  variable  d’environnement ORACLE_SID ; si cette variable d’environnement n’est pas positionnée, l’utilitaire affiche un message  d’erreur.  La commande emctl status agent peut aussi être utilisée pour afficher des informations détaillées sur l’agent.   

- 2-

© ENI Editions - All rights reserved - Algeria Educ

Le démarrage du Database Control est assez long (environ 1 minute). Si  vous  utilisez  le  Database  Control  pour  administrer  la  base  de  données,  il  est  souhaitable  que  ce  dernier  soit  démarré automatiquement lors du démarrage du système.  Sur plate­forme Windows, le Database Control peut être démarré automatiquement lors du démarrage du système  en positionnant le service associé (OracleDBConsole<SID>) en démarrage automatique.  Sur  plate­forme  Unix  ou  Linux,  le  serveur  d’application  peut  être  démarré  automatiquement  grâce  au  script  de  démarrage présenté dans la section Installation du serveur du chapitre Installation.  Le  script  actuel  doit  être  modifié  pour  prendre  en  charge  le  démarrage  et  l’arrêt  de  plusieurs  Database  Control  (éventuellement dans des Oracle Home différents) à l’aide de la commande emctl.    Vous pouvez vous inspirer des scripts dbstart et dbshut pour écrire un tel script. Exemple  for ligne in $(cat /etc/oratab | egrep ’^[a-zA-Z]+:.*:Y$’) do SID=$(echo $ligne | cut -d: -f1) EM_HOME=$(echo $ligne | cut -d: -f2) export ORACLE_SID=$SID $EM_HOME/bin/emctl start dbconsole > $LOG 2>&1 & done Cet  exemple  de  code  permet  de  démarrer  le  Database  Control  pour  toutes  les  instances  définies  en  démarrage  automatique dans le fichier /etc/oratab. 

4. Débuter avec le Database Control  a. Vue d’ensemble  Dans cette partie, nous allons donner une vue d’ensemble de l’utilisation du Database Control. Dans les différents  chapitres  de  l’ouvrage,  nous  verrons  ensuite  comment  utiliser  le  Database  Control  pour  effectuer  les  différentes  tâches  d’administration.  Pourdémarrer  une  session  Database  Control,  il  suffit  d’ouvrir  une  fenêtre  de  votre  navigateur et de saisir une URL de la forme : https://serveur:port/em  serveur est le nom ou l’adresse IP du serveur de base de données. port est le numéro du port sur lequel le service  OMS communique (1158 par exemple).  Exemple :  https://srvwinora:1158/em Si  la  base  est  démarrée,  la  page  de  connexion  s’affiche.  Si  la  base  n’est  pas  démarrée,  la  page  de  démarrage  s’affiche (cf. Chapitre Démarrage et arrêt).  La page de connexion permet de saisir un nom, un mot de passe et éventuellement de demander une connexion  SYSDBAou SYSOPER(zone Se connecter en tant que) : 

openmirrors.com

 

© ENI Editions - All rights reserved - Algeria Educ

- 3-

Initialement, seuls les comptes Oracle SYS, SYSTEM et SYSMANpeuvent utiliser le Database Control.  Une fois connecté, vous arrivez sur la page d’accueil du Database Control : 

  Cette page d’accueil vous donne une vision globale du fonctionnement général de la base de données. Cette page  affiche  notamment  des  informations  synthétiques  sur  les  performances  du  système,  l’utilisation  de  l’espace  et  les  alertes signalées par le système ; différents liens permettent ensuite d’afficher des informations détaillées sur ces  différents aspects.  Les liens Performances, Disponibilité, Serveur, Schéma, Mouvement de données et Logiciel et fichiers associés  affichent des pages de navigation qui permettent d’accéder aux différents outils d’administration.  En haut de chaque page, le Database Control propose 4 liens : 

  Le lien Installation affiche une page qui permet de configurer le Database Control ; cette page permet notamment  de définir d’autres utilisateurs habilités à utiliser la console.  Le lien Préférences affiche une page qui permet de modifier les préférences de l’utilisateur courant, et notamment  de définir une adresse de courrier électronique permettant de recevoir une notification en cas de problème (voir la  section Utiliser les alertes dans ce chapitre). 

b. Informations d’identification et de connexion  Pour  certaines  tâches  d’administration  (planification  de  travaux,  sauvegarde/restauration),  le  Database  Control  vous  demandera  de  saisir  des  informations  d’identification  et  de  con­  nexion  à  la  base  de  données  et/ou  au  système hôte.  Pour éviter de devoir saisir ces informations à chaque fois, vous pouvez les enregistrer dans vos préférences.  Sur  la  page  Préférences,  cliquez  sur  le  lien  Informations  d’identification  et  de  connexion  stockées  dans  les  préférences. 

- 4-

© ENI Editions - All rights reserved - Algeria Educ

  Cliquez sur une des icônes de la dernière colonne pour saisir les informations d’identification de la cible souhaitée  (instance de base de données, hôte). 

  Pour  la  base  de  données,  vous  pouvez  enregistrer  deux  identifications  Oracle  pour  la  base  de  données  (une  identification  "normale",  par  exemple  SYSTEM,  et  une  identification  SYSDBA,  par  exemple  SYS)  ainsi  qu’une  identification pour l’hôte.  En ce qui concerne l’identification pour l’hôte, vous devez indiquer un utilisateur du système qui a le droit d’exécuter  des applications dans le répertoire Oracle Home ; c’est le cas des comptes qui sont membres du groupe OSDBA, et  donc notamment du compte utilisé pour l’installation.  Sur  plate­forme  Windows,  le  compte  utilisé  doit  par  ailleurs  être  membre  du  groupe  Administrateurs  et  avoir  le  privilège  Ouvrir  une  session  en  tant  que  tâche.  Si  ce  n’est  pas  le  cas,  vous  aurez  le  message  d’erreur  suivant  lorsque vous cliquerez sur le bouton Test : 

  Pour attribuer ce privilège, procédez de la manière suivante :  ■

Sélectionnez le menu Démarrer ­ Programmes ­ Outils d’administration ­ Stratégie de sécurité locale. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 5-

■

■

Dans l’arborescence de gauche, cliquez sur le dossier Stratégies locale ­ Attribution des droits utilisateur.  Dans  la  liste  des  stratégies,  double  cliquez  sur  la  stratégie Ouvrir  une  session  en  tant  que  tâche  et  ajoutez  l’utilisateur souhaité dans la liste. 

5. Utiliser les alertes  a. Visualiser les alertes  Par défaut, le Database Control est configuré pour signaler différents problèmes sur le fonctionnement de la base  de données : c’est la notion d’alerte. Les alertes sont visibles sur la page d’accueil du Database Control : 

  La  liste  Alertes  donne  les  alertes  de  l’instance  et  de  la  base  de  données.  La  liste  Alertes  associées  donne  les  alertes  d’autres  composants  Oracle  (Oracle  Net  par  exemple)  ou  de  l’hôte.  Lorsqu’une  alerte  est  signalée,  vous  pouvez cliquer sur le lien associé pour avoir plus d’informations ; selon la nature de l’alerte, la page affichée peut  proposer des liens pour faire des actions correctrices ou une analyse supplémentaire. 

b. Définir les seuils des alertes  Sur la page d’accueil, vous pouvez cliquer sur le lien Paramètres de mesure et de règle (cadre Liens associés en  bas), pour accéder à la page de gestion des seuils de déclenchement des alertes : 

  Cette page affiche les seuils actuels de déclenchement des alertes pour les différentes mesures. Pour les mesures 

- 6-

© ENI Editions - All rights reserved - Algeria Educ

souhaitées, vous pouvez définir un seuil d’avertissement et un seuil critique. 

c. Recevoir une notification lorsqu’une alerte survient  Il  est  possible  de  recevoir  directement  une  notification  lorsqu’une  alerte  survient,  typiquement  par  messagerie  électronique.  Pour recevoir une notification par messagerie électronique, vous devez faire deux choses :  ●

configurer les méthodes de notification du Database Control ; 

●

vous "abonner" à des notifications. 

Configurer les méthodes de notification Sur la page d’accueil, ou toute autre page, cliquez sur le lien Installation en haut à droite, puis sur le lien Méthodes  de notification pour accéder à la page de définition des méthodes de notification : 

  La première méthode de notification que vous pouvez définir est la notification par messagerie électronique. Pour la  configurer, il suffit d’indiquer l’adresse du serveur de messagerie sortant (et si besoin une authentification pour ce  serveur)  et  d’identifier  l’expéditeur  (le  Database  Control)  par  un  nom  et  une  adresse  électronique.  Si  vous  le  souhaitez,  vous  pouvez  définir  d’autres  méthodes  de  notifications :  SNMP  (Simple  Network  Management  Protocol),  commande du système d’exploitation, procédure PL/SQL.  La  configuration  de  la  méthode  de  notification  par  messagerie  électronique  peut  être  réalisée  lors  de  la  création d’une base de données à l’aide de l’assistant graphique, ou lors de la configuration du Database  Control avec l’utilitaire emca. 

S’abonner à une notification Si vous souhaitez recevoir des notifications par messagerie électronique, vous devez d’abord associer une adresse  électronique au compte Oracle que vous utilisez pour l’administration.  Sur la page d’accueil, ou toute autre page, cliquez sur le lien Préférences en haut à droite, pour accéder à la page  de gestion de vos préférences : 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 7-

  Dans le cadre Adresse email, vous pouvez indiquer une ou plusieurs adresses électroniques.  Ensuite, vous pouvez cliquer sur le lien Règles pour vous abonner à une notification : 

  Une  règle  de  notification  est  un  ensemble  de  conditions  qui  déclenche  une  notification :  cible  (base  de  données,  processus  d’écoute,  hôte,  etc.),  disponibilité  de  la  cible,  survenance  d’une  ou  plusieurs  alertes  (avec  seuil  de  gravité).  Plusieurs  règles  de  notification  sont  définies  par  défaut  lors  de  l’installation  du  Database  Control.  Par  exemple, la règle "Database Availability and Critical States" déclenche une notification lorsque la base de données  est  arrêtée,  et  un  seuil  critique  est  atteint  sur  plusieurs  mesures  (pourcentage  de  remplissage  de  la  zone  d’archivage, pourcentage de remplissage d’un tablespace, etc.).  Sur  la  page  ci­dessus,  vous  pouvez  consulter  ou  modifier  une  règle  prédéfinie  ou  créer  de  nouvelles  règles.  En  cochant  la  case  de  la  dernière  colonne  (Abonnement),  vous  pouvez  vous  "abonner"  à  la  règle,  c’est­à­dire  demander à être destinataire de la notification.  C’est le compte Oracle SYSMANqui est propriétaire des règles de notification prédéfinies, mais celles­ci sont  publiques et peuvent donc être modifiées par les autres utilisateurs habilités du Database Control. Lors de 

- 8-

© ENI Editions - All rights reserved - Algeria Educ

la  création  d’une  base  de  données  à  l’aide  de  l’assistant  graphique,  ou  lors  de  la  configuration  du  Database  Control  avec  l’utilitaire  emca,  si  vous  configurez  la  notification  par  messagerie  électronique,  l’adresse  de  messagerie  indiquée  sera  associée  au  compte  SYSMAN,  et  les  notifications  seront  automatiquement  envoyées  à  cette adresse. 

6. Les tâches de maintenance automatisées  Trois tâches de maintenance automatisées sont programmées par défaut :  ●

Collecte des statistiques pour l’optimiseur (voir Chapitre Gestion des tables et des index) ; 

●

Conseil sur le stockage des segments (voir Chapitre Gestion des tables et des index) ; 

●

Conseil sur l’optimisation des requêtes SQL. 

Les tâches de maintenance automatisées peuvent être supervisées dans le Database Control. Sur la page d’accueil,  cliquez  sur  le  lien  Serveur,  puis  sur  le  lien Tâches  de  maintenance  automatisées  (cadre Oracle  Scheduler)  pour  afficher la liste des tâches de maintenance automatisées : 

  Par  défaut,  les  tâches  de  maintenance  automatique  s’exécutent  du  lundi  au  vendredi  entre  22h00  et  2h00  et  le  samedi et le dimanche entre 6h00 et 2h00.  Si  vous  cliquez  sur  le  lien  correspondant  au  nom  de  la  tâche,  vous  pouvez  visualiser  le  résultat  de  la  dernière  exécution (sauf pour la collecte des statistiques).  Si vous cliquez sur le bouton Configurer, la page de configuration des tâches de maintenance s’affiche : 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 9-

  À  partir  de  cette  page,  vous  pouvez  activer  ou  désactiver  les  tâches,  modifier  leur  planification  ou  les  configurer  (bouton Configurer).  Dans  ces  deux  pages,  il  y  a  une  inversion  entre  les  termes  "Désactivé"  et  "Activé"  :  "Désactivé"  veut  dire  "Activé" et réciproquement. 

- 10 -

© ENI Editions - All rights reserved - Algeria Educ

Objectifs de l’ouvrage  Cet ouvrage a pour objectif de vous présenter toutes les bases de l’administration d’une base de données Oracle11g :  ●

compréhension minimale de l’architecture ; 

●

procédures d’installation en environnement Windows et Unix/Linux ; 

●

configuration d’Oracle Net ; 

●

arrêt et démarrage ; 

●

création d’une nouvelle base de données ; 

●

gestion de la mémoire ; 

●

gestion du stockage (fichiers de données, tablespaces, tables, index, etc.) ; 

●

gestion de la sécurité (utilisateurs et droits) ; 

●

sauvegardes et restaurations avec RMAN (Recovery Manager) ; 

Ce  livre  contient  de  nombreux  conseils  pratiques  et  de  nombreuses  recommandations,  et  présente  les  solutions  qui  peuvent  être  apportées  aux  problèmes  courants.  Le  tout  est  abondamment  illustré  par  une  quantité  d’exemples  sur  l’utilisation  des  commandes  et  autres  ordres  SQL,  mais  aussi  par  de  nombreuses  copies  d’écrans  d’Oracle  Enterprise  Manager Database Control. Les différents exemples de cet ouvrage peuvent être téléchargés sur le site des Editions ENI.  Cet ouvrage s’adresse à la fois aux débutants qui souhaitent devenir administrateur Oracle, mais aussi aux nombreux  administrateurs formés sur le tas, et qui souhaitent mettre à jour leurs connaissances, les consolider et découvrir les  nombreuses nouvelles fonctionnalités d’Oracle 11g.  Pour  pouvoir  profiter  pleinement  de  ce  livre,  il  est  conseillé  d’avoir  des  connaissances  préalables  sur  les  bases  de  données relationnelles (savoir ce qu’est une table, une vue, un index) et sur le SQL (ordres SELECT, INSERT, UPDATE et  DELETE).  Dans cet ouvrage, nous emploierons souvent le terme couramment utilisé de DBA pour désigner l’administrateur  de la base de données. En anglais, DBA signifie DataBase Administrator. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

La documentation Oracle  1. Où la trouver ?  Le média d’installation contient essentiellement la documentation relative à l’installation, notamment :  ●

Oracle® Database Release Notes ; 

●

Oracle® Database Quick Installation Guide ; 

●

Oracle® Database Installation Guide. 

La  documentation  Oracle  est  accessible  http://www.oracle.com/technology/documentation/index.html 

en 

ligne 

à 

l’adresse 

suivante : 

2. Organisation  La documentation comporte plusieurs "livres" (format HTML ou PDF) regroupés par thème. 

  La zone Search permet d’effectuer des recherches, notamment sur un numéro d’erreur Oracle.  Le lien Master Book List affiche la liste de tous les livres.  Les principaux livres sont identifiés par des codes proposés sous forme de lien dans le tableau de synthèse de la liste  des livres. Les livres les plus utiles pour l’administration sont les suivants :  Oracle® Database Concepts (CON)  Concepts sur l’architecture et les fonctionnalités d’Oracle.  Oracle® Database Administrator’s Guide (ADM)  Manuel de l’administration. 

© ENI Editions - All rights reserved - Algeria Educ

- 1-

Oracle® Database Security Guide (SEC)  Gestion des utilisateurs et des droits.  Oracle® Database Reference (REF)  Manuel  de  référence  de  tous  les  paramètres  du  fichier  de  paramètres  et  de  toutes  les  vues  du  dictionnaire  de  données.  Oracle® Database SQL Language Reference (SQL)  Manuel de référence du SQL.  Oracle® Database Error Messages (ERR)  Manuel des erreurs.  Oracle® Database Utilities (UTI)  Manuel d’utilisation des outils Data Pump, Import, Export et SQL*Loader.  Oracle® Database Backup and Recovery User’s Guide (BAC)  Manuel des sauvegardes et restaurations.  Oracle® Database Backup and Recovery Reference (BAC)  Manuel de référence de l’outil RMAN.  Oracle® Database Upgrade Guide (UPG)  Manuel pour la migration d’une base Oracle d’une ancienne version.  La documentation comporte beaucoup d’autres livres relatifs au développement (PL/SQL, Java...), à la couche Oracle  Net, à l’optimisation, etc. 

- 2-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

Diagnostiquer les problèmes  1. Vue d’ensemble  Depuis la version 11, Oracle inclut une nouvelle infrastructure pour le diagnostic des problèmes.  Le  composant  principal  de  cette  infrastructure  est  le  Référentiel  de  Diagnostic  Automatique  (Automatic  Diagnostic  Repository  ­  ADR).  ADR  est  un  répertoire  qui  stocke  de  façon  structurée  et  centralisée  toutes  les  données  de  diagnostic, par exemple des fichiers de trace ou d’alerte.  Cette infrastructure introduit deux concepts : les problèmes et les incidents.  Un problème est une erreur critique de la base de données, comme les erreurs internes (ORA-00600), les erreurs du  système d’exploitation (ORA-07445) ou le manque de mémoire dans la Shared Pool (ORA-04031). Chaque problème est  identifié  par  une  clé  qui  inclut  le  code  de  l’erreur  (par  exemple  ORA-600)  et  éventuellement,  des  paramètres  supplémentaires.  Un  incident  est  une  occurrence  d’un  problème.  Chaque  incident  est  identifié  par  un  numéro  d’incident.  Lorsqu’un  incident se produit, la base de données effectue les actions suivantes :  ●

une entrée est écrite dans le fichier d’alerte de l’instance (voir ci­après) ; 

●

une alerte est envoyée à Oracle Enterprise Manager ; 

●

des  informations  de  diagnostic  sont  capturées  et  enregistrées  dans  des  fichiers  d’incident qui sont marqués  avec le numéro de l’incident et stockés dans un sous­répertoire du Référentiel de Diagnostic Automatique. 

Un autre composant de la nouvelle infrastructure est le Health Monitor qui regroupe plusieurs outils de vérification de la  bonne santé de la base de données. Ces outils de vérification sont exécutés automatiquement par Oracle lorsqu’une  erreur  critique  se  produit  ;  ils  peuvent  aussi  être  exécutés  à  la  demande.  Les  résultats  sont  stockés  dans  le  Référentiel de Diagnostic Automatique.  Pour exploiter le Référentiel de Diagnostic Automatique, Oracle propose deux outils :  ●

Le Support Workbench de la console Enterprise Manager 

●

L’outil ligne de commande adrci 

2. Le Référentiel de Diagnostic Automatique  Depuis la version 11, tous les fichiers de trace et tous les fichiers journaux des différents composants qui s’exécutent  sur le serveur (bases de données, processus d’écoute, etc.), sont stockés de façon structurée et centralisée dans un  répertoire de diagnostic : c’est le Référentiel de Diagnostic Automatique (Automatic Diagnostic Repository ­ ADR).  Le répertoire de base d’ADR est défini par le paramètre DIAGNOSTIC_DEST qui est, par défaut, égal au répertoire Oracle  Base si la variable d’environnement ORACLE_BASE est définie ; sinon, il est égal, par défaut, au sous­répertoire log du  répertoire  Oracle  Home.  Sous  ce  répertoire  de  base,  un  répertoire  diag  est  créé  avec  une  arborescence  du  type  suivant :  diag +---asm +---clients +---crs +---diagtool +---lsnrctl +---netcman +---ofm +---rdbms ¦ +---<nom unique base de données> ¦ ¦ +---<nom instance> ¦ ¦ +---alert ¦ ¦ +---incident ¦ ¦ +---trace ¦ ¦ +---...

© ENI Editions - All rights reserved - Algeria Educ

- 1-

¦ +---... +---tnslsnr Le  répertoire diag  contient  un  sous­répertoire  par  composant  Oracle,  avec  notamment  un  répertoire  rdbms  pour  les  bases  de  données  et  un  répertoire  tnslsnr  pour  le  processus  d’écoute.  Pour  les  bases  de  données,  le  répertoire  rdbms  contient  un  sous­répertoire  par  base  de  données  qui,  lui­même,  contient  un  sous­répertoire  par  instance  qui  accède  à  la  base  de  données  (en  général  une  seule  instance,  sauf  dans  le  cas  d’une  configuration  Real  Application  Clusters). Les principaux répertoires sont les suivants :  alert  Fichier d’alerte de l’instance au format XML.  incident  Fichiers relatifs aux incidents.  trace  Fichiers de trace des processus et version texte du fichier d’alerte de l’instance.  La vue V$DIAG_INFO donne des informations sur le répertoire de diagnostic :  SQL> SELECT name,value FROM v$diag_info; NAME VALUE --------------------- ----------------------------------------------------Diag Enabled TRUE ADR Base d:\app\oracle ADR Home d:\app\oracle\diag\rdbms\orcl\orcl Diag Trace d:\app\oracle\diag\rdbms\orcl\orcl\trace Diag Alert d:\app\oracle\diag\rdbms\orcl\orcl\alert Diag Incident d:\app\oracle\diag\rdbms\orcl\orcl\incident Diag Cdump d:\app\oracle\diag\rdbms\orcl\orcl\cdump Health Monitor d:\app\oracle\diag\rdbms\orcl\orcl\hm Default Trace File d:\app\oracle\diag\rdbms\orcl\orcl\trace\ orcl_ora_4088.trc Active Problem Count 1 Active Incident Count 1 Avant  la  version  11,  l’emplacement  des  fichiers  d’alerte  et  de  trace  était  défini  par  les  paramètres  BACKGROUND_DUMP_DEST (fichiers d’alerte et fichiers de trace des processus d’arrière plan) et USER_DUMP_DEST (fichiers de  trace des processus serveur). Les emplacements recommandés par le standard OFA étaient respectivement les sous­ répertoires bdump et udump du répertoire d’administration.  Depuis la version 11, les paramètres BACKGROUND_DUMP_DEST et USER_DUMP_DEST sont dépréciés et ignorés. S’ils ne sont  pas définis dans le fichier de paramètres de l’instance, ils sont automatiquement renseignés par Oracle. 

3. Les fichiers d’alerte et de trace  Oracle maintient un fichier d’alerte dans lequel il écrit des messages d’information ou d’erreur sur la vie de la base de  données : 

- 2-

●

Création de la base de données ; 

●

Démarrages et arrêts ; 

●

Modifications de la structure (tablespaces, fichiers de données) ; 

●

Erreurs critiques (incidents) ; 

●

Erreurs de bloc corrompu (ORA-01578) ; 

●

Problèmes relatifs à l’écriture ou à l’archivage des fichiers de journalisation. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

En complément, lorsqu’un processus rencontre un problème, il écrit des informations dans un fichier trace.  Le fichier d’alerte est disponible sous deux formes : une version texte et une version XML (nouveau en version 11).  Le  fichier  d’alerte  au  format  XML  se  nomme  log.xml  et  se  trouve  dans  le  sous­répertoire  alert  du  répertoire  de  diagnostic de la base de données. Il est automatiquement renommé en log_n.xml lorsqu’il atteint une certaine taille.  Le nom du fichier d’alerte au format texte est de la forme alert_<SID>.log ; il se trouve dans le sous­répertoire trace  du répertoire de diagnostic de la base de données.  Le  fichier  d’alerte au format texte, grossit sans limite. Il est conseillé de le purger régulièrement pour éviter qu’il ne  soit  trop  volumineux ;  le  mieux  est  de  l’archiver  à  intervalles  réguliers  pour  garder  l’historique  de  la  vie  de  la  base.  Vous  pouvez  supprimer  ou  renommer  le  fichier  d’alerte  au  format  texte  sans  crainte ;  Oracle  le  recréera  lorsqu’il  en  aura besoin.  Le nom des fichiers de trace des processus d’arrière­plan est de la forme <sid>_<nom_processus>_.trc.  Le  nom  des  fichiers  de  trace  des  processus  serveur  est  de  la  forme  <sid>_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 ci­dessus, l’envoi du package au support  Oracle échoue lorsqu’Oracle Configuration Manager n’a pas été correctement installé et configuré lors de l’installation  d’Oracle. Pour plus d’informations sur l’installation et la configuration de ce composant, consultez la documentation  "Oracle®  Configuration  Manager  Installation  and  Administration  Guide"  (à  ce  jour,  cette  documentation  existe  uniquement en version 10.2).  Une  fois  que  le  package  est  créé,  et  même  s’il  n’a  pas  pu  être  envoyé,  des  informations  supplémentaires  sont  affichées dans la page d’accueil du Support Workbench : 

© ENI Editions - All rights reserved - Algeria Educ

- 5-

  Pour  le  problème  concerné,  la  colonne  Packagée  contient  Oui,  et  l’onglet  Packages  permet  de  retrouver  les  packages qui ont été générés, et éventuellement de les envoyer de nouveau si l’envoi initial a échoué. 

b. Consulter le contenu du fichier d’alerte de l’instance  Dans  la  section  Liens  associés  située  dans  le  bas  des  pages  de  la  console,  le  lien  Contenu  du  journal  d’alertes  affiche une page de consultation du contenu du fichier d’alerte de l’instance. 

  Le lien Rechercher affiche un formulaire de recherche qui permet d’effectuer une recherche dans le fichier d’alerte de  l’instance (par date, texte du message, etc.). 

c. Vérificateurs  Pour  accéder  aux  outils  de  vérification  de  la  bonne  santé  de  la  base  de  données,  vous  pouvez  cliquer  sur  le  lien  Centre de conseil (section Liens associés située dans le bas de la page d’accueil de chaque onglet) puis sur le lien  (onglet) Vérificateurs. 

- 6-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

  Les liens de la section Vérificateurs permettent de lancer les différents outils de vérification.  La  section  Traitements  du  vérificateur  affiche  le  résultat  de  l’exécution  des  outils,  notamment  des  exécutions  automatiques effectuées par Oracle lorsqu’une erreur critique se produit.  Pour consulter le résultat, vous pouvez cliquer sur le bouton Détails ou sur le lien du nom du traitement. 

  La cause de l’erreur, si elle n’a pas encore été traitée, est affichée dans cette page.  La  même  information  peut  être  consultée  dans  l’onglet  Résultats  de  recherche  du  vérificateur  du  Support  Workbench. 

© ENI Editions - All rights reserved - Algeria Educ

- 7-

  Dans les deux cas, vous pouvez cliquer sur le bouton Lancer Recovery Advisor pour réparer le problème à l’aide du  Data Recovery Advisor (cf. section Utiliser le Database Control du chapitre Sauvegarde et récupération). 

5. L’outil ligne de commande adrci  L’outil ligne de commande adrci permet de consulter le contenu du Référentiel de Diagnostic Automatique.  Pour lancer l’outil en interactif, il faut s’assurer que l’environnement Oracle est correctement positionné (ORACLE_HOME  et PATH) puis saisir la commande adrci à l’invite du système d’exploitation.  Exemple  C:\>adrci ADRCI: Release 11.1.0.6.0 - Beta on Lun. Juin 30 16:40:29 2008 Copyright (c) 1982, 2007, Oracle. All rights reserved. ADR base = "d:\app\oracle"adrci> L’outil  propose  un  très  grand  nombre  de  commandes  qui  pour  certaines  d’entre elles, comportent un grand nombre  d’options.  Dans  ce  chapitre,  nous  présenterons  brièvement  les  commandes  et  options  les  plus  utiles  pour  effectuer  des  tâches  courantes.  Toutes  les  commandes  et  options  sont  décrites  dans  la  documentation  "Oracle®  Database  Utilities".  Les commandes les plus utiles sont les suivantes :  HELP   Liste toutes les commandes.  HELP commande  Affiche l’aide d’une commande.  EXIT ou QUIT  Quitte l’outil.  SHOW HOMES 

- 8-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

Affiche le chemin de la racine du répertoire de diagnostic de chaque composant présent sur le serveur.  SET HOMEPATH chemin  Définit le répertoire de diagnostic courant.  SET EDITOR programme  Définit l’éditeur externe à utiliser pour afficher le contenu des fichiers d’alerte ou de trace.  SHOW ALERT [options]  Affiche le contenu d’un  fichier  d’alerte. Sans option, la totalité du contenu du fichier d’alerte est affiché avec l’éditeur  externe.  SHOW INCIDENT [options]  Affiche des informations sur les incidents répertoriés dans ADR.  SHOW PROBLEM [options]  Affiche des informations sur les problèmes répertoriés dans ADR.  Les commandes ne sont pas sensibles à la casse.  La commande SET EDITOR doit absolument être utilisée sur une plate­forme Windows car l’éditeur par défaut  est vi qui n’existe pas (en standard) sur cette plate­forme.  Exemples  ●

Définir le répertoire de diagnostic courant (celui de l’instance ORCL) : 

adrci> SHOW HOMES ADR Homes: ... diag\rdbms\orcl\orcl diag\rdbms\test\test diag\tnslsnr\srvwinora\listener adrci> SET HOMEPATH diag\rdbms\orcl\orcl

●

Afficher les 10 dernières entrées du fichier d’alerte de l’instance : 

adrci> SHOW ALERT -TAIL 10 2008-06-27 10:07:57.375000 +02:00 SMCO started with pid=20, OS id=2856 ... 2008-06-30 12:26:09.593000 +02:00 Thread 1 advanced to log sequence 43 Current log# 1 seq# 43 mem# 0: D:\APP\ORACLE\ORADATA\ORCL\REDO01.LOG

●

Afficher,  dans  la  fenêtre  courante,  les  entrées  du  fichier  d’alerte  de  l’instance  correspondant  à  un  critère  particulier (ici, la présence d’une certaine erreur) : 

adrci> SHOW ALERT -TERM -P "message_text like ’ORA-1652%’" ADR Home = d:\app\oracle\diag\rdbms\orcl\orcl: ******************************************************************** 2008-06-24 15:33:29.312000 +02:00 ORA-1652: unable to extend temp segment by 128 in tablespace USERS 2008-06-24 15:35:07.031000 +02:00 ORA-1652: unable to extend temp segment by 128 in tablespace USERS

© ENI Editions - All rights reserved - Algeria Educ

- 9-

●

La même chose en utilisant un éditeur externe (ici sur une plate­forme Windows, ce qui nécessite de définir  l’éditeur à utiliser au préalable) : 

adrci> SET EDITOR notepad.exe adrci> SHOW ALERT -P "message_text like ’ORA-1652%’" ADR Home = d:\app\oracle\diag\rdbms\orcl\orcl: *************************************************************** Output the results to file: c:\temp\alert_2348_3036_orcl_2.ado

●

Afficher la "structure" du fichier d’alerte (liste les "colonnes" qui peuvent être utilisées dans les recherches) : 

adrci> DESCRIBE alert_ext Name ----------------------------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ère­plan sont  démarrés.  À  ce  stade,  seule  l’instance  est  lancée ;  il  n’y  a  pas  de  base  de  données  associée.  Les  vues  dynamiques  relatives à l’instance (V$INSTANCE, V$SGA, V$OPTION, V$PARAMETER, V$VERSION etc.) sont interrogeables mais pas les vues  dynamiques  relatives  à  la  base  de  données  (V$DATABASE  par  exemple).  Cet  état  est  principalement  utilisé  lors  de  la  création d’une nouvelle base.  Lors  du  montage  de  la  base  de  données,  l’instance  utilise  le  paramètreCONTROL_FILES du fichier de paramètres pour  localiser les fichiers de contrôle et les ouvrir. Dans le fichier de contrôle, l’instance extrait le nom et le statut des fichiers  de  données  et  des  fichiers  de  journalisation,  mais  ne  les  ouvre  pas  et  ne  vérifie  pas  non  plus  leur  présence ;  si  un  fichier  n’est  pas  trouvé,  aucun  message  d’erreur  n’est  affiché.  À  ce  stade,  une  base  de  données  est  associée  à  l’instance (V$DATABASE est maintenant interrogeable) mais n’est pas ouverte pour une utilisation "normale" : personne  ne peut se connecter à la base de données, à l’exception d’un utilisateur ayant le privilège SYSDBA ou SYSOPER. Les vues  statiques  du  dictionnaire  ne  sont  notamment  pas  accessibles.  Dans  cet  état,  le  DBA  peut  effectuer  certaines  tâches  d’administration :  renommer  ou  déplacer  un  fichier  de  données  ou  un  fichier  de  journalisation,  activer  ou  désactiver  l’archivage des fichiers de journalisation, effectuer une récupération de la base de données.  Lors de l’ouverture de la base de données, l’instance ouvre les fichiers de journalisation et les fichiers de données qui  étaient en ligne au moment de l’arrêt, et vérifie la cohérence de la base de données. Si l’un des fichiers de données à  ouvrir n’est pas trouvé ou est endommagé, l’instance signale une erreur et la base de données n’est pas ouverte. Si la  base  de  données  peut  être  ouverte  mais  que  le  dernier  arrêt  n’était  pas  un  arrêt  propre,  SMON  effectue  la  récupération  de  l’instance.  À  ce  stade,  la  base  de  données  est  accessible  pour  une  utilisation  "normale" :  les  utilisateurs peuvent se connecter. Le dictionnaire de données est totalement disponible. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

Démarrage  1. Utiliser SQL*Plus  a. La commande STARTUP  Dans SQL*Plus, la commande STARTUP permet de démarrer une instance et de lui associer une base avec le niveau  de disponibilité souhaité.  Syntaxe simplifiée  STARTUP [NOMOUNT | MOUNT [nom_base] | OPEN [nom_base]] [RESTRICT] [PFILE=nom_fichier] Avec  NOMOUNT | MOUNT | OPEN  niveau de disponibilité souhaité.  nom_base  nom de la base à monter ou à ouvrir.  RESTRICT  restreint l’accès à la base aux utilisateurs ayant le privilège RESTRICTED SESSION.  PFILE  nom du fichier de paramètres à utiliser.  L’option RESTRICT Une base de données peut être ouverte (OPEN) dans un mode restreint (option  RESTRICT) où seuls les utilisateurs  ayant  le  privilège  particulier  RESTRICTED SESSION  (voir  la  section  Gestion  des  droits  dans  le  chapitre  Gestion  des  utilisateurs et de leurs droits) peuvent effectivement se connecter ; généralement, ce privilège n’est donné qu’aux  administrateurs.  Ce mode restreint peut être utilisé pour effectuer certaines opérations d’administration qui nécessitent que la base  soit ouverte mais qu’il est préférable (pas obligatoire) de réaliser sans utilisateur connecté. Exemples :  ●

réorganiser le stockage d’une table, reconstruire des index ; 

●

faire un export ou un import ; 

●

faire un chargement de données avec SQL*Loader. 

Ne  pas  avoir  d’utilisateurs  connectés  pendant  ces  opérations  permet  d’éviter  des  mises  à  jour  concurrentes  intempestives et de réaliser l’opération plus rapidement.  Lorsque l’opération est terminée, il est possible de quitter le mode restreint avec l’ordre SQL :  ALTER SYSTEM DISABLE RESTRICTED SESSION; Fichier de paramètres et clause PFILE Les  noms  par  défaut  du  fichier  de  paramètres  texte  et  du  fichier  de  paramètres  serveur  d’une  instance  sont  respectivement init<SID>.ora et spfile<SID>.ora.  L’emplacement par défaut de ces deux fichiers dépend de la plate­forme : 

© ENI Editions - All rights reserved - Algeria Educ

- 1-

●

%ORACLE_HOME%\database (Windows) ; 

●

$ORACLE_HOME/dbs (Unix/Linux). 

En ce qui concerne le fichier de paramètres texte, le nom et l’emplacement recommandés par le standard OFAsont  différents :  init.ora dans le sous­répertoire  pfiledu  répertoire  d’administration.  Pour  concilier  l’emplacement par  défaut et le standard OFA, il est possible de créer un fichier init<SID>.ora dans le répertoire par défaut de la plate­ forme  et  d’y  mettre  une  simple  inclusion  vers  le  "vrai"  fichier  de  paramètres,  grâce  au  paramètre IFILE.  Exemple  (Windows) :  IFILE=’D:\app\oracle\admin\ORCL\pfile\init.ora’ Si la plate­forme le permet, il est aussi possible d’utiliser un lien symbolique.  Sans clause PFILE dans la commande STARTUP, Oracle recherche, à l’emplacement par défaut de la plate­forme, dans  l’ordre, un fichier :  ●

spfile<SID>.ora 

●

spfile.ora 

●

init<SID>.ora 

Le fichier spfile.ora (sans nom d’instance) est principalement utilisé dans le cas d’une configuration Real  Application Cluster.  En priorité, l’instance recherche donc par défaut un fichier de paramètres serveur. Spécifier la clause PFILE permet  de  démarrer  explicitement  avec  un  fichier  de  paramètres  texte,  qui  peut  éventuellement  ne  pas  respecter  le  nom  et/ou l’emplacement par défaut.  Pour démarrer avec un fichier de paramètres serveur situé à un autre emplacement ou ayant un autre nom, il faut  démarrer  avec  un  fichier  de  paramètres  texte  contenant  un  paramètre  SPFILE(pas  IFILE)  indiquant  le  chemin  d’accès complet au fichier de paramètres serveur. Exemple (Windows) :  SPFILE=’D:\app\oracle\admin\ORCL\pfile\sp.ora’ La valeur du paramètre SPFILE  peut  être  consultée  après  démarrage  de  l’instance, dans la vue V$PARAMETER  ou  à  l’aide de la commande SQL*Plus SHOW PARAMETER. Si ce paramètre n’a pas été spécifié explicitement, il est affecté en  interne par le serveur. S’il est vide, c’est que l’instance a démarré avec un fichier de paramètres texte.  Il est recommandé d’utiliser un fichier de paramètres serveur. Pour vous simplifier la vie, respectez le nom  et l’emplacement par défaut. 

b. Mode opératoire  Lancez  SQL*PLUS  et  connectez­vous  avec  le  privilège  AS SYSDBA,  en  vous  assurant  que  l’instance  souhaitée  est  correctement désignée.  Exemple :  ●

Connexion locale après avoir positionné la variable d’environnement : ORACLE_SID  ●

Plate­forme Windows :  C:\>set ORACLE_SID=ORCL  C:\>sqlplus /nolog  SQL> CONNECT / AS SYSDBA 

- 2-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

●

Plate­forme Linux :  $ .oraenv sqlplus /nolog  SQL> SET INSTANCE orcl  SQL> CONNECT / AS SYSDBA 

●

Connexion à travers le réseau en spécifiant un nom de service réseau dans la chaîne de connexion :  > sqlplus /nolog  SQL> CONNECT /@orcl AS SYSDBA 

Tapez la commande STARTUP avec les options souhaitées :  ●

Démarrer une instance sans associer de base de données (sans doute en vue d’en créer une nouvelle) :  SQL> STARTUP NOMOUNT 

●

Démarrer  une  instance  et  simplement  monter  la  base  de  données  (pour  effectuer  certaines  tâches  d’administration) :  SQL> STARTUP MOUNT 

●

Démarrer une instance et ouvrir la base de données pour la rendre accessible à tous les utilisateurs :  SQL> STARTUP 

Exemple de démarrage avec le fichier de paramètres serveur par défaut :  SQL> STARTUP Instance ORACLE lancée. Total System Global Area 313860096 bytes Fixed Size 1332892 bytes Variable Size 230689124 bytes Database Buffers 75497472 bytes Redo Buffers 6340608 bytes Base de données montée. Base de données ouverte. SQL> SELECT value FROM v$parameter WHERE name = ’spfile’; VALUE ---------------------------------------------------------D:\APP\ORACLE\PRODUCT\11.1.0\DB_1\DATABASE\SPFILEORCL.ORA

c. Modifier le niveau de disponibilité de la base de données  Si l’instance a été démarrée avec un état intermédiaire pour la base de données (NOMOUNT ou MOUNT), il est possible  de la faire passer à l’état suivant grâce à l’ordre SQL ALTER DATABASE.  ●

De NOMOUNT à MOUNT 

© ENI Editions - All rights reserved - Algeria Educ

- 3-

ALTER DATABASE [nom_base] MOUNT; ●

De MOUNT à OPEN 

ALTER DATABASE [nom_base] OPEN; Pour passer de l’état NOMOUNT à l’état OPEN, il faut passer par l’état MOUNT.  Il  existe  aussi  des  ordres  SQL ALTER DATABASE CLOSE et  ALTER DATABASE DISMOUNT  qui  permettent  de  fermer  puis  démonter  la  base  de  données.  Par  contre,  ces  ordres  ne  peuvent  pas  être  utilisés  pour  fermer  une  base  de  données puis la rouvrir sans passer par un arrêt complet. 

d. Récupérer des informations sur l’instance et sur la base de données  Plusieurs  vues  du  dictionnaire  de  données  permettent  de  récupérer  des  informations  sur  l’instance  et  la  base  de  données au cours du démarrage.  ●

●

Dès l’état NOMOUNT :  ●

V$INSTANCE : informations sur l’instance ; 

●

V$PARAMETER : liste des paramètres actifs ; 

●

V$SGA : informations sur la SGA ; 

●

V$VERSION : version des différents composants d’Oracle 

●

V$OPTION : liste des options Oracle. 

À partir de l’état MOUNT :  ●

●

V$DATABASE : information sur la base de données. 

Dans l’état OPEN :  ●

PRODUCT_COMPONENT_VERSION : version des différents composants d’Oracle. 

Dans la vue V$INSTANCE, la colonne STATUS peut prendre les valeurs suivantes :  STARTED  instance démarrée, sans base (NOMOUNT)  MOUNTED  instance démarrée, base montée (MOUNT)  OPEN  instance démarrée, base ouverte (OPEN)  La colonne LOGINS indique si les connexions sont autorisées (valeur ALLOWED) ou restreintes (RESTRICTED).  Dans la vue V$DATABASE, la colonne OPEN_MODE peut prendre les valeurs suivantes :  MOUNTED  base montée (MOUNT)  READ WRITE 

- 4-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

base ouverte (OPEN) en lecture/écriture (par défaut)  READ ONLY  base ouverte (OPEN) en lecture seule  Le  mode  d’ouverture  de  la  base  de  données  peut  être  spécifié  dans  l’ordre  SQL  ALTER DATABASE,  ou  dans  la  commande STARTUP. 

2. Utiliser le Database Control  Lorsque vous vous connectez au Database Control et que la base de données n’est pas ouverte, la page suivante  s’affiche : 

  Cette page vous permet soit de démarrer la base de données, soit d’effectuer une récupération.  Si la base est arrêtée mais qu’elle n’est pas endommagée, vous pouvez cliquer sur le bouton Démarrer ; une page  d’identification s’affiche : 

© ENI Editions - All rights reserved - Algeria Educ

- 5-

  Sur  cette  page,  saisissez  une  identification  pour  l’hôte  et  une  identification  SYSDBAou  SYSOPERpour  la  base  de  données, puis cliquez sur le bouton OK.  Si l’instance est arrêtée, la page de confirmation de démarrage s’affiche : 

  Si  l’instance  est  démarrée,  base  non  montée  (NOMOUNT)  ou  base  montée  (MOUNT),  une  page  de  choix  d’opérations  s’affiche.  Cette  page  vous  permet  de  préciser  l’opération  que  vous  souhaitez  faire :  arrêter  la  base  de  données,  monter  la  base de données, ouvrir la base de données. Sélectionnez l’option souhaitée et cliquez sur le bouton Continuer ; la  page  de  confirmation  de  démarrage  s’affiche  avec  des  informations  de  statut  et  d’opération  adaptés.  Exemple  (demande d’ouverture pour une base de données montée) : 

  Sur la page de confirmation de démarrage, vous pouvez cliquer sur le bouton Options avancées pour sélectionner les  options de démarrage (NOMOUNT, MOUNT, OPEN, RESTRICT, PFILE, etc.) ; les options proposées dépendent du contexte.  La séquence de recherche d’un fichier de paramètres est la même que pour le démarrage avec la commande  STARTUP dans SQL*Plus. 

- 6-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

Pour  lancer  l’opération,  cliquez  sur  le  bouton  Oui.  Pendant  que  l’opération  se  déroule,  une  page  d’informations  d’activité est affichée.  Une fois que l’opération est terminée, la page qui s’affiche dépend du contexte.  ●

●

Si la base de données n’est pas ouverte (non montée ou montée), la page d’informations sur le statut est de  nouveau affichée.  Si la base de données est ouverte, la page de connexion s’affiche. 

Vous pouvez alors vous reconnecter au Database Control. 

© ENI Editions - All rights reserved - Algeria Educ

- 7-

Arrêt  1. Utiliser SQL*Plus  a. La commande SHUTDOWN  Dans SQL*Plus, la commande SHUTDOWN permet de fermer la base et d’arrêter l’instance.  Syntaxe  SHUTDOWN [NORMAL | IMMEDIATE | TRANSACTIONAL | ABORT] Options :  NORMAL  Oracle  attend  que  tous  les  utilisateurs  soient  déconnectés  (pas  de  nouvelle  connexion  autorisée)  puis  ferme  proprement la base de données.  IMMEDIATE  Oracle  déconnecte  tous  les  utilisateurs  (en  effectuant  un  ROLLBACK  des  éventuelles  transactions  en  cours)  puis  ferme proprement la base de données.  TRANSACTIONAL  Oracle  attend  que  toutes  les  transactions  en  cours  se  terminent  avant  de  déconnecter  les  utilisateurs  (pas  de  nouvelle transaction autorisée) puis ferme proprement la base de données.  ABORT  Oracle  déconnecte  tous  les  utilisateurs  (sans  effectuer  de  ROLLBACK  des  éventuelles  transactions  en  cours)  puis  ferme "brutalement" la base de données, sans effectuer de point de synchronisation (checkpoint). Une récupération  de l’instance sera nécessaire lors du prochain démarrage.  Le processus de l’arrêt est le suivant :  ●

La base de données est fermée. 

●

La base de données est démontée. 

●

L’instance est arrêtée (les processus d’arrière­plan sont arrêtés et la SGA est libérée). 

Un  arrêt  est  forcément  complet ;  il  n’est  pas  possible  de  s’arrêter  dans  un  état  intermédiaire  (MOUNT  ou NOMOUNT).  Pour passer une base ouverte (OPEN) en état monté (MOUNT), il faut arrêter la base (SHUTDOWN) et la redémarrer dans  l’état souhaité (STARTUP MOUNT par exemple).  Les arrêts  NORMAL, IMMEDIATE  et TRANSACTIONAL sont propres ; un point de synchronisation (checkpoint)  est  réalisé  sur les fichiers de données. Le redémarrage ultérieur ne nécessitera pas de récupération de l’instance. Ce n’est pas  le  cas  de  l’arrêt  ABORT  pour  lequel  le  point  de  synchronisation  n’est  pas  réalisé ;  les  fichiers  de  données  sont  immédiatement  fermés.  Ce  comportement  est  similaire  à  un  arrêt  anormal  de  l’instance.  Lors  du  prochain  redémarrage, une récupération de l’instance (automatique) sera nécessaire (voir les principes dans le chapitre Les  bases de l’architecture Oracle).  L’arrêt NORMAL est souvent problématique car il attend la déconnexion des utilisateurs, même si ceux­ci sont inactifs.  Dans ce cas, l’arrêt IMMEDIATE peut être utilisé pour déconnecter les utilisateurs ; les transactions éventuellement  en  cours  sont  annulées.  L’opération d’annulation  des  transactions  peut  prendre  un  peu  de  temps  et  l’arrêt  n’est  pas aussi immédiat.  L’arrêt TRANSACTIONAL est un peu moins "violent" que l’arrêt IMMEDIATE puisqu’il attend que les transactions en cours  se  terminent  avant  d’arrêter  la  base.  Par  contre,  il  faut  avoir  conscience  que  cet  arrêt  peut  être  bloqué  par  une  transaction qui ne termine pas (la transaction est elle­même bloquée ou un utilisateur est parti en laissant un ordre 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

INSERT/ UPDATE/DELETE en suspens).  L’arrêt  ABORT  est  le  plus  rapide  (lui  est  immédiat !)  mais  ne  doit  être  utilisé  qu’en  dernier  recours :  blocage  d’un  autre type d’arrêt, besoin réel d’arrêter la base immédiatement.  Dans  un  script  d’arrêt  automatique  destiné,  par  exemple,  à  faire  une  sauvegarde,  utilisez  un  SHUTDOWN IMMEDIATE pour être certain que la base de données sera effectivement arrêtée. 

b. Mode opératoire  Lancez  SQL*PLUS  et  connectez­vous  AS SYSDBA,  en  vous  assurant  que  l’instance  souhaitée  est  correctement  désignée.  Exemple :  > sqlplus /nolog SQL> SET INSTANCE orcl SQL> CONNECT / AS SYSDBA Vérifiez éventuellement s’il y a des utilisateurs connectés et des transactions en cours :  Exemple :  SQL> SELECT sid,serial#,username,DECODE(taddr,NULL,’’,’Oui’) trans 2 FROM v$session 3 / Tapez la commande SHUTDOWN avec les options souhaitées :  ●

Arrêt sans utilisateur connecté :  SQL> SHUTDOWN 

●

Arrêt avec des utilisateurs connectés en laissant les transactions se terminer :  SQL> SHUTDOWN TRANSACTIONAL 

La vue  V$SESSIONpermet de visualiser les utilisateurs connectés ; cette vue sera présentée plus en détail dans la  section Superviser les utilisateurs connectés du chapitre Gestion des utilisateurs et de leurs droits. Les techniques  utilisables  pour  déconnecter  les  utilisateurs  seront  aussi  présentées  dans  la  section  Superviser  les  utilisateurs  connectés du chapitre Gestion des utilisateurs et de leurs droits.  Dans V$SESSION, il faut vérifier s’il existe d’autres sessions que les sessions correspondant aux processus d’arrière­ plan  (colonne username  vide)  et  que  la  session SYS  (session  utilisée  pour  l’arrêt).  La  requête  présentée  ci­dessus  permet aussi de savoir si les utilisateurs connectés ont une transaction en cours (colonne trans égale à Oui).  Dans  la  pratique,  si  le  Database  Control  est  lancé  (service  OMS  et  agent),  vous  aurez  une  ou  plusieurs  sessions  SYSMAN et  DBSNMP.  Pour  arrêter  la  base  de  données,  vous  devrez  donc,  soit  arrêter  le  Database  Control (emctl stop dbconsole), soit utiliser la commande SHUTDOWN IMMEDIATE. 

2. Utiliser le Database Control  Sur la page d’accueil du Database Control, le cadre Général donne le statut actuel et propose un bouton Arrêter qui  permet d’arrêter la base de données : 

 

- 2-

© ENI Editions - All rights reserved - Algeria Educ

Si vous cliquez sur le bouton Arrêter, la page d’identification s’affiche : 

  Sur  cette  page,  saisissez  une  identification  pour  l’hôte  et  une  identification  SYSDBA  ou  SYSOPER  pour  la  base  de  données, puis cliquez sur le bouton OK.  Les champs de cette page sont remplis par défaut si vous avez défini des informations d’identification dans  vos  préférences  (cf.  section  Oracle  Enterprise  Manager  Database  Control  du  chapitre  Les  outils  d’administration). Notez par ailleurs que c’est l’identification SYSDBA indiquée sur cette page qui sera utilisée pour  effectuer l’arrêt et non votre connexion actuelle au Database Control (qui peut être une connexion normale et pas  SYSDBA).  La page de confirmation d’arrêt est ensuite affichée : 

  Sur cette page de confirmation de démarrage, vous pouvez cliquer sur le bouton Options avancées pour sélectionner  les options de l’arrêt (NORMAL, IMMEDIATE, etc.) ; un lien est aussi proposé pour visualiser les sessions.  Cliquez  sur  le  bouton  Oui  pour  procéder  à  l’arrêt.  Pendant  que  l’opération  se  déroule,  une  page  d’informations  d’activité est affichée : 

  Au bout de quelques instants, cliquez sur le bouton Régénérer pour revenir au Database Control. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 3-

Si l’arrêt n’est pas encore terminé, la page d’accueil habituelle s’affiche. Attendez encore quelques instants avant de  rafraîchir la page.  Pour une raison inconnue, il arrive fréquemment qu’une page d’erreur soit affichée à ce stade : 

  Cliquez sur le bouton OK pour revenir à la page précédente et attendez quelques instants pour cliquer de nouveau  sur le bouton Régénérer. Si le problème persiste, quittez le Database Control puis ouvrez­le à nouveau.  Attendez encore quelques instants avant de rafraîchir la page. Lorsque l’arrêt est terminé, la page d’informations sur  le statut doit s’afficher : 

 

- 4-

© ENI Editions - All rights reserved - Algeria Educ

Automatisation et scripts  1. Sur plate­forme Unix ou Linux  a. Automatisation  Sur plate­forme Unix ou Linux, des bases de données peuvent être démarrées ou arrêtées automatiquement grâce  au  script  de  démarrage  présenté  dans  la  section  Installation  du  serveur  du  chapitre  L’installation.  Ce  script  de  démarrage appelle les scripts dbstart et dbshut fournis par Oracle.  Extraits du script :  # Démarrer les bases de données echo "** démarrage des bases de données" >> $LOG $ORACLE_HOME/bin/dbstart $ORACLE_HOME_LISTENER > $LOG 2>&1 & ... # Arrêter les bases de données echo "** arrêt des bases de données" >> $LOG $ORACLE_HOME/bin/dbshut $ORACLE_HOME_LISTENER > $LOG 2>&1 & Les scripts  dbstart et  dbshut utilisent le fichier  /etc/oratabpour déterminer quelles sont les bases de données à  démarrer ou arrêter automatiquement. Ce fichier contient une ou plusieurs lignes de la forme suivante :  ::{Y|N} Exemple :  ORCL:/u01/app/oracle/product/11.1.0/db_1:Y L’emplacement  du  fichier  oratab  peut  varier  selon  le  système  d’exploitation.  Consultez  la  documentation  Installation Guide de votre plate­forme.  Pour démarrer ou arrêter automatiquement une base de données, il suffit de mettre un Y dans le dernier champ de  la ligne correspondant à la base de données.  Le script dbstart lance SQL*Plus et utilise la commande STARTUP sans clause PFILE ; la séquence de recherche du  fichier de paramètres est donc la même que pour un démarrage manuel avec la commande STARTUP dans SQL*Plus.  Si  vous  avez  plusieurs  versions  d’Oracle  sur  votre  serveur,  utilisez  les  scripts  dbstart  et  dbshut  de  la  version la plus récente (ajustez la variable d’environnement $ORACLE_HOME en conséquence). 

b. Scripts  Les scripts dbstart et dbshut peuvent être appelés manuellement pour démarrer ou arrêter les bases de données  configurées à Y dans oratab.  Des scripts shell personnalisés similaires à dbstart et dbshut peuvent être très facilement écrits.  Exemple (script restart) :  ORACLE_SID=$1 ORAENV_ASK=NO . oraenv export ORACLE_SID ORAENV_ASK sqlplus /nolog ) en démarrage automatique.  En  complément,  il  peut  être  nécessaire  (en  cas  de  problème  notamment)  de  s’assurer  que  le  paramètre  ORA_<SID>_AUTOSTARTest  bien  à TRUE dans la base de registre. Si le service a été créé en démarrage automatique  (chapitre Création d’une nouvelle base de données), cela doit être le cas.  Pour  arrêter  automatiquement  une  base  lors  de  l’arrêt  du  système,  il  faut  s’assurer  que  le  paramètre  ORA_<SID>_SHUTDOWNest  bien  à  TRUE  dans  la  base  de  registre  et  ajuster  éventuellement  la  valeur  du  paramètreORA_<SID>_SHUTDOWN_TIMEOUT. Normalement, cela doit être le cas.  Dans  la  base  de  registre,  les  paramètres  indiqués  HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_nom_oracle_home. 

ci­dessus 

se 

trouvent 

dans 

la 

clé 

Les paramètres de la base de registre ont la signification suivante :  ORA_<SID>_AUTOSTART  Indique si l’instance identifiée par <SID> doit être démarrée (valeur TRUE) ou non (valeur FALSE) après le démarrage  du service.  ORA_<SID>_SHUTDOWN  Indique  si  l’instance  identifiée  par  <SID>  doit  être  arrêtée  (valeur  TRUE)  ou  non  (valeur  FALSE)  lors  de  l’arrêt  du  service.  ORA_<SID>_SHUTDOWNTYPE  Type  d’arrêt  effectué  sur  l’instance  identifiée  par  <SID> :  abort,  immediate  (valeur  par  défaut),  transactional  et  normal.  ORA_<SID>_SHUTDOWN_TIMEOUT  Délai  (en  secondes)  accordé  à  l’instance  identifiée  par  <SID>  pour  s’arrêter  avant  l’arrêt  du  service  (qui  est  alors  équivalent à un SHUTDOWN ABORT).  Si  votre  base  met  plus  de  90  secondes  à  s’arrêter,  augmentez  la  valeur  du  paramètre  ORA_<SID>_SHUTDOWN_TIMEOUT pour éviter d’avoir des arrêts de type ABORT.  Dans  la  base  de  registre,  il  est  possible  de  définir  un  paramètre  ORA_<SID>_PFILE  qui  donne  le  chemin  d’accès  complet vers le fichier de paramètres texte à utiliser pour le démarrage de l’instance identifiée par <SID>.  Si ce paramètre est vide, ou n’existe pas, la séquence de recherche du fichier de paramètres s’effectue comme lors  d’un  STARTUP  sans  clause  PFILE  dans  SQL*Plus.  Si  le  paramètre  est  renseigné,  le  démarrage  s’effectue  avec  le  fichier  de  paramètres  texte  indiqué.  Si  ce  paramètre  contient  une  valeur  erronée,  l’instance  ne  démarre  pas  au  redémarrage du service associé. Pour démarrer avec un fichier de paramètres serveur non standard, vous pouvez  utiliser la technique du fichier de paramètres texte contenant un paramètre SPFILE. 

b. Scripts  Plusieurs techniques sont possibles pour écrire des scripts de démarrage ou d’arrêt :  ●

- 2-

en utilisant la commande système net pour démarrer (net start) ou arrêter le service (net stop) ; 

© ENI Editions - All rights reserved - Algeria Educ

●

●

en utilisant l’utilitaire oradim fourni par Oracle ;  en utilisant un fichier de commandes (.bat) qui lance SQL*Plus avec un script SQL sur la ligne de commande  qui démarre ou arrête la base. 

Syntaxe simplifiée de l’utilitaire oradim :  ■

Pour le démarrage : 

ORADIM -STARTUP -SID sid ■

Pour l’arrêt : 

ORADIM -SHUTDOWN -SID sid [-SHUTTYPE type] [-SHUTMODE mode] Avec :  sid  Identifiant de l’instance.  type  Indique ce qui doit être arrêté. Valeurs possibles : srvc (service) ou  inst (instance, par défaut) ou srvc,inst (les  deux).  mode  Mode de l’arrêt. Valeurs possibles : i (IMMEDIATE, valeur par défaut), n (NORMAL) ou a (ABORT).  Exemple (fichier de commande restart.bat) :  set ORACLE_SID=%1% oradim -shutdown -sid %ORACLE_SID% oradim -startup -sid %ORACLE_SID% Appel :  C:\>restart ORCL Ce script permet de redémarrer une base de données dont l’identifiant d’instance est passé en paramètre.  Le  service  du  Database  Control  (OracleDBConsole<SID>)  est  dépendant  du  service  de  l’instance ;  pour  arrêter  le  service  de  l’instance,  il  faut  au  préalable  arrêter  le  service  du  Database  Control.  Inversement,  démarrer le service du Database Control démarre le service de l’instance. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 3-

Problèmes courants et solutions  ORA-01033: ORACLE initialization or shutdown in progress Explication  La base de données n’est pas ouverte.  Cause(s)  Vous  tentez  de  vous  connecter  à  une  base  de  données  non  ouverte  sans  utiliser  de  connexion  SYSDBA.  La  base  de  données  est  peut  être  effectivement  en  train  de  démarrer  ou  de  s’arrêter ;  la  base  de  données  est  peut­être aussi  tout simplement non montée ou montée.  Action(s)  Connectez­vous AS SYSDBA et interrogez la colonne STATUS de V$INSTANCE.  ORA-01034: ORACLE not available Explication  L’instance est arrêtée.  Cause(s)  Vous tentez de vous connecter à une instance Oracle arrêtée sans utiliser de connexion SYSDBA.  Action(s)  Connectez­vous AS SYSDBA et démarrez l’instance.  ORA-01081: impossible de lancer ORACLE déjà en cours - fermer d’abord le thread Explication  Vous tentez de démarrer une instance déjà démarrée.  Cause(s)  Vous n’êtes pas connecté à la bonne instance. Vous tentez de passer d’un état NOMOUNT ou MOUNT à OPEN en faisant un  STARTUP.  Action(s)  Interrogez  V$INSTANCE  pour  vérifier  à  quelle  instance  vous  êtes  connecté.  Si  vous  n’êtes  pas  sur  la  bonne  instance,  reconnectez­vous (après avoir modifié ORACLE_SID ou en utilisant le bon nom de service réseau). Pour passer une base  de données de l’état NOMOUNT ou MOUNT à OPEN, utilisez la commande ALTER DATABASE.  ORA-01109: base de données non ouverte ORA-01219: BdD fermee : demandes seulement autorisées sur des tables/vues fixes Explication  La base de données n’est pas ouverte mais simplement montée (MOUNT).  Cause(s)  Vous  tentez  de  faire  une  action  (ORA-01109)  ou  de  lire  une  vue  statique  du  dictionnaire  de  données  (ORA-01219)  qui  nécessite que la base soit ouverte. 

© ENI Editions - All rights reserved - Algeria Educ

- 1-

Action(s)  Interrogez la colonne STATUS de V$INSTANCE et si c’est le cas (valeur MOUNTED au lieu de OPEN), ouvrez d’abord la base  de données.  ORA-01507: base de données non montée Explication  La base de données n’est pas montée (NOMOUNT) ; seule l’instance est démarrée.  Cause(s)  Vous  tentez  de  faire  une  action  qui  nécessite  que  la  base  de  données  soit  montée,  par  exemple :  interrogation  de  V$DATABASE, ordre SQL ALTER DATABASE OPEN, etc.  Action(s)  Interrogez  la  colonne  STATUS de  V$INSTANCE et si c’est  le  cas  (valeur STARTED  au  lieu  de MOUNTED),  montez  d’abord la  base de données (ALTER DATABASE MOUNT).  ORA-12560: TNS : erreur d’adaptateur de protocole Explication  Le processus d’écoute n’a pas réussi à démarrer un processus pour connecter l’utilisateur à l’instance.  Cause(s)  La  variable ORACLE_SID  n’est  pas  correctement  positionnée.  Sur  plate­forme  Windows,  le  service  associé  à  l’instance  (OracleService<SID>) n’est pas lancé.  Action(s)  Vérifiez la variable et/ou le service associé.  Blocage d’un SHUTDOWN Cause(s)  Sur un  SHUTDOWN NORMAL, il y a des utilisateurs connectés. Sur un SHUTDOWN TRANSACTIONAL, il y a des transactions en  cours. Sur un SHUTDOWN IMMEDIATE, il y a une très grosse transaction à annuler... ou un autre problème.  Action(s)  Ouvrez une autre session de l’outil d’administration, connectez­vous AS SYSDBA et exécutez un SHUTDOWN ABORT. Si cela  ne marche pas, il faut "tuer" les processus :  ­ Redémarrage du service associé à l’instance sur plate­forme Windows.  ­ kill des processus sur plate­forme Unix.  Lorsqu’un SHUTDOWN est en cours, il n’est plus possible d’interroger V$SESSION et donc de déterminer si le problème est  lié à des utilisateurs connectés.  Sur un SHUTDOWN IMMEDIATE, soyez patient ! L’arrêt peut prendre plusieurs dizaines de secondes. 

- 2-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

Vue d’ensemble  1. Étapes de création d’une nouvelle base de données pour une application  Le processus complet de création d’une nouvelle base de données pour une application comporte les grandes étapes  suivantes :  Conception du modèle physique ●

●

Définir  tous  les  objets  (Oracle)  de  l’application : tables,  contraintes  d’intégrité  (clés  primaires/uniques/étrangères),  index,  vues,  programmes  stockés  (triggers,  procédures/  fonctions  stockées,  packages).  Étudier la volumétrie de l’application (nombre d’utilisateurs, nombre de lignes attendues dans les tables). 

Création de la base proprement dite (ce chapitre) ●

●

●

●

Créer une nouvelle instance.  Créer une nouvelle base de données (fichiers de contrôle, fichiers de journalisation et fichiers de données des  tablespaces "techniques" d’Oracle).  Rendre le dictionnaire de données exploitable.  À ce stade, la base de données peut être vue comme une "enveloppe" (une "boîte vide") dans laquelle des  structures vont être créées pour une ou plusieurs applications. 

Création des structures de stockage adaptées (chapitres Gestion des tablespaces et des fichiers de données et  Gestion des informations d’annulation) ●

●

Créer les tablespaces (avec leurs fichiers de données) destinés à stocker les données de l’application (tables  et index).  Les dimensionner en fonction de l’étude de volumétrie réalisée initialement. 

Création  du  compte  Oracle  qui  va  contenir  les  objets  de  l’application  (chapitre  Gestion  des  utilisateurs  et  de  leurs droits) ●

Créer le compte. 

●

Lui donner les privilèges suffisants pour créer les objets. 

●

L’autoriser à utiliser de l’espace dans les tablespaces de l’application. 

Création des objets de l’application dans ce compte Oracle (chapitre Gestion des tables et des index) ●

●

Créer les objets Oracle de l’application (généralement sous la forme d’un ou de plusieurs scripts).  Dimensionner  chaque  objet  occupant  de  l’espace  de  stockage  (table  et  index)  en  fonction  de  l’étude  de  volumétrie réalisée initialement. 

Création des utilisateurs finaux de l’application (chapitre Gestion des utilisateurs et de leurs droits)

© ENI Editions - All rights reserved - Algeria Educ

- 1-

●

●

Créer les utilisateurs.  Leur donner des droits adaptés sur les objets de l’application (i.e. sur les objets créés précédemment dans le  compte propriétaire de l’application). 

Sauvegarde de la base (chapitre Sauvegarde et récupération) ●

Sauvegarde de référence de la base. 

Comme  vous  pouvez  le  constater,  la  création  de  la  base  de  données  proprement  dite  présentée  dans  ce  chapitre  n’est qu’une petite étape du processus complet (mais une étape fondamentale). 

2. Étapes de création de la base de données proprement dite  Les grandes étapes de la création de la base de données proprement dite sont les suivantes :  ●

Créer les répertoires sur les disques, si possible en respectant les recommandations du standard OFA. 

●

Préparer un nouveau fichier de paramètres texte, généralement par copie d’un ancien. 

●

Positionner la variable d’environnement ORACLE_SID. 

●

Créer  le  service  associé  à  l’instance  (plate­forme  Windows)  ou  créer  le  fichier  de  mot  de  passe  pour  l’identification SYSDBA (plate­forme Unix ou Linux). 

●

Lancer SQL*Plus et se connecter AS SYSDBA. 

●

Créer un fichier de paramètres serveur (pas obligatoire, mais conseillé). 

●

Démarrer l’instance en état NOMOUNT. 

●

Créer la base de données (ordre SQL CREATE DATABASE). 

●

Finaliser la création du dictionnaire (quelques scripts à exécuter). 

●

Configurer Oracle Net pour la nouvelle base de données. 

●

Enregistrer la nouvelle instance dans le fichier oratab (plate­forme Unix ou Linux). 

●

Configurer le Database Control. 

La création d’une nouvelle base de données suppose l’installation préalable d’Oracle (chapitre Installation).  Si le serveur abrite déjà des bases de données Oracle, il est vivement conseillé d’effectuer une sauvegarde  de ces bases de données avant de démarrer le processus de création.  Après ces étapes, la nouvelle base de données est ouverte et contient : 

- 2-

●

les tablespaces SYSTEM et SYSAUX avec leur(s) fichier(s) de données associé(s) ; 

●

éventuellement un tablespace d’annulation et un tablespace temporaire selon les options utilisées ; 

●

les fichiers de contrôle et de journalisation ; 

●

les deux comptes DBA standard (SYS et SYSTEM) ; 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

●

le segment d’annulation SYSTEM ; 

●

le dictionnaire de données. 

À  ce  stade,  la  base  de  données  est  prête  pour  accueillir  des  structures  complémentaires  qui  vont  constituer  l’application. 

3. Méthodes disponibles  La nouvelle base de données peut être créée à la main avec les outils du système d’exploitation et SQL*Plus ; dans  ce cas, il est très simple d’écrire ou de récupérer des scripts et de les réutiliser à chaque fois. Les étapes de création  de  la  base  de  données  proprement  dite  sont  toujours  les  mêmes  et  dépendent  (relativement)  peu  des  caractéristiques  de  l’application  (et  en  tout  état  de  cause,  des  paramètres  peuvent  être  ajustés  ultérieurement  en  fonction  des  caractéristiques  de  l’application) ; utiliser  des  scripts  "génériques"  de  création  de  bases  est  donc  envisageable.  La  nouvelle  base  de  données  peut  aussi  être  créée  à  l’aide d’un  assistant  graphique,  l’assistant  Configuration de  base  de  données.  Cet  assistant  facilite  la  création  de  la  base  de  données  en  offrant  la  possibilité  d’utiliser  des  modèles de base de données prêts à l’emploi et/ou en permettant de définir très précisément les caractéristiques de  la nouvelle base de données à l’aide de plusieurs écrans. Par ailleurs, il est possible de définir ses propres modèles  de  base  de  données,  comprenant  ou  non  des  fichiers  de  données  prêts  à  l’emploi,  puis  de  les  utiliser  lors  de  la  création  ultérieure  d’une  nouvelle  base  de  données.  L’assistant  graphique  offre  aussi  la  possibilité  de  générer  les  scripts de création de la base de données, sans créer la base de données ; c’est un bon moyen pour constituer nos  scripts "génériques".  L’assistant graphique inclut les étapes suivantes de création des structures de stockage (chapitres Gestion  des fichiers de contrôle et de journalisation et Gestion des tables­ paces et des fichiers de données). 

© ENI Editions - All rights reserved - Algeria Educ

- 3-

Création de la base de données manuellement  1. Créer les répertoires sur les disques  Pour respecter les recommandations du standard OFA (voir le chapitre Installation), vous devez créer :  ●

●

un répertoire d’administration, portant le nom de la base de données, situé dans le répertoire %ORACLE_BASE% \admin(Windows) ou $ORACLE_BASE/admin (Linux/ Unix),  un répertoire de données, portant le nom de la base de données, situé dans un répertoire oradata lui­même  situé dans ORACLE_BASE ou sur un autre volume. 

Depuis  la  version  11  et  l’apparition  du  Référentiel  de  Diagnostic  Automatique,  le  répertoire  d’administration  contient moins de répertoires et de fichiers.  Le répertoire d’administration contient généralement les répertoires suivants :  adump  Répertoire pour des fichiers d’audit.  create ou scripts  Répertoire des scripts de création de la base de données.  exp ou dpdump   Répertoire pour les fichiers d’export.  pfile   Répertoire pour les fichiers de paramètres texte.  Si le serveur comporte plusieurs disques, il sera judicieux de répartir les différents fichiers de la base de données sur  ces  disques  afin  d’optimiser  les  entrées/sorties  et  d’éviter  les  contentions ; dans  ce  cas,  il  faut  créer  d’autres  répertoires de données sur les disques concernés.  Un  répertoire  supplémentaire  peut  être  créé  pour  la  zone  de  récupération  rapide  (voir  le  chapitre  Sauvegarde  et  récupération).    Généralement, la base de données et l’instance portent le même nom.

2. Préparer un nouveau fichier de paramètres texte  a. Principes  Comme indiqué dans la section La base de données du chapitre Les bases de l’architecture Oracle, il est conseillé  d’utiliser un fichier de paramètres serveur, celui­ci étant initialement créé à partir d’un fichier de paramètres texte.  Pour respecter le standard OFA, ce fichier de paramètres texte doit s’appeler init.ora et se trouver dans le sous­ répertoire pfiledu répertoire d’administration. Généralement, ce fichier de paramètres texte est créé par duplication  d’un fichier existant ou d’un fichier modèle que vous aurez défini.  Nous ne créerons pas de fichier init<SID>.ora (avec une inclusion du fichier init.ora) à l’emplacement par défaut de  la plate­forme (dbs sous Unix/Linux, database sous Windows) ; ainsi, nous ne risquons pas de démarrer par mégarde  avec un fichier de paramètres texte.  Il y a plus de 250 paramètres documentés par Oracle ! Il n’est évidemment pas question de les spécifier tous ! Sur la  totalité des paramètres, une trentaine de paramètres qu’il convient de connaître, sont suffisants pour la plupart des 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

bases de données.  Certains paramètres seront décrits brièvement dans cette partie puis présentés de manière plus détaillée dans des  chapitres ultérieurs. 

b. Les principaux paramètres  Les paramètres ne sont pas listés dans un ordre alphabétique mais dans un ordre thématique.  Reportez­vous  à  la  section Compléments  sur  les  paramètres  relatifs  à  la  mémoire  pour  avoir  plus  d’informations à ce sujet. 

DB_NAME Nom de la base (jusqu’à 8 caractères). Généralement DB_NAME est égal au nom de l’instance (ORACLE_SID).  Exemple :  DB_NAME = hermes DB_DOMAIN Localisation logique de la base sur le réseau (jusqu’à 128 caractères). Ce paramètre, associé au paramètre DB_NAME,  permet  à  Oracle  de  construire  le  nom  global  de  la  base  de  données_ AUTOSTART = TRUE dans la base  de registre).  ­ manual (par défaut) : l’instance n’est pas démarrée lorsque le service démarre (paramètre ORA_<SID>_AUTOSTART = FALSE dans la base de registre).  -SRVCSTART system | demand  Précise le mode de démarrage souhaité pour le service :  ­ system : le service est en redémarrage automatique.  ­ demand (par défaut) : le service est en redémarrage manuel.  -SPFILE  Indique  que  l’instance  n’utilise  pas  explicitement  de  fichier  de  paramètres  texte  pour  le  démarrage  automatique.  Dans ce cas, lors d’un démarrage automatique, la séquence de recherche d’un fichier paramètres s’effectue comme  indiquée  dans  la  section  Démarrage  du  chapitre  Démarrage  et  arrêt ­ La  commande  STARTUP.  Option  par  défaut  si  l’option ­PFILE n’est pas spécifiée.  -PFILE fichier  Chemin d’accès complet au fichier de paramètres texte à utiliser explicitement pour le démarrage automatique (pas  de  séquence  de  recherche  de  fichier  de  paramètres).  Ne  pas  mettre  cette  clause  si  vous  utilisez  un  fichier  de  paramètres serveur (recommandé).  -SHUTMODE normal | immediate |abort  Type  d’arrêt  effectué  sur  l’instance  lorsque  le  service  s’arrête  (voir  les  options  de  la  commande  STARTUP  dans  la  section  Démarrage  du  chapitre  Démarrage  et  arrêt ­ La  commande  STARTUP).  Est  enregistré  dans  le  paramètre  ORA_<SID>_AUTOSTART = FALSE de la base de registre.  -TIMEOUT durée  Délai  (en  secondes)  accordé  à  l’instance  pour  s’arrêter  avant  l’arrêt  du  service  (qui  est  alors  équivalent  à  un 

- 10 -

© ENI Editions - All rights reserved - Algeria Educ

SHUTDOWN ABORT). Est enregistré dans le paramètre ORA_<SID>_SHUTDOWN_TIMEOUT de la base de registre. 90 secondes  par défaut.  ORADIM -NEW crée et démarre le serviceOracleService<SID>. Il crée aussi le service  OracleJobScheduler<SID> utilisé  par l’ordonnanceur  Oracle  (scheduler) pour lancer des travaux au niveau du système d’exploitation ; par  défaut,  ce  service est désactivé.  Pour  les  options  -STARTMODE,  -SHUTMODE  et  -SRVCSTART,  la  première  lettre  des  valeurs  suffit  (STARTMODE a,  par  exemple).  Exemple :  C:\>oradim -new -sid HERMES -syspwd wX#12 -startmode a -srvcstart s -spfile Instance créée. C:\> Cet exemple crée un service avec toutes les options qui permettent d’avoir un redémarrage automatique. Un fichier  de paramètres serveur est utilisé et l’authentificationSYSDBA par un fichier de mot de passe est possible (en plus de  l’authentification par le système d’exploitation).  D’une  manière  plus  générale,  l’utilitaire  ORADIM  permet  de  gérer  le  service  associé  à  l’instance,  notamment  de  modifier certains paramètres ou de le supprimer (suite à la suppression d’une base par exemple).  Taper simplement ORADIM sur la ligne de commande permet d’obtenir l’aide de l’outil.  L’option -EDIT de ORADIM permet de modifier les caractéristiques du service et de l’instance, notamment d’activer ou  de désactiver le démarrage automatique.  Syntaxe simplifiée  ORADIM -EDIT -SID sid [-SYSPWD mot_de_passe] [-MAXUSERS nombre] [-STARTMODE auto| manual ] [-SRVCSTART system| demand ] [-PFILE fichier] [-SPFILE] [-SHUTMODE normal| immediate |abort] [-TIMEOUT durée] Les clauses sont les mêmes que pour la création. 

b. Créer le fichier de mot de passe (plate­forme Unix/Linux)  Sur plate­forme Unix ou Linux, il n’y a pas de notion de service associé à l’instance. Par contre, il peut être nécessaire  de créer le fichier de mot de passe utilisé pour l’authentification SYSDBA.  Le fichier de mot de passe est créé à l’aide de l’utilitaire orapwd.  Cet  utilitaire  existe  aussi  sur  plate­forme  Windows.  Il  permet  de  créer  ou  de  recréer  le  fichier  de  mot  de  passe sans utiliser oradim.  Syntaxe  ORAPWD FILE=fichier PASSWORD=mot_de_passe ENTRIES=nombre FORCE=y|n IGNORECASE=y|n Avec  FILE=fichier  Chemin complet vers le fichier de mot de passe à créer.  PASSWORD=mot_de_passe  Mot de passe de SYS pour le privilège SYSDBA.  ENTRIES=nombre  Indique le nombre d’utilisateurs qui pourront recevoir le privilège SYSDBA ou SYSOPER et qui seront enregistrés dans le  fichier de mot de passe. 

openmirrors.com

  © ENI Editions - All rights reserved - Algeria Educ

- 11 -

FORCE=y|n  Mettre y pour forcer la suppression préalable du fichier s’il existe déjà (utile en cas de recréation du fichier de mot de  passe).  IGNORECASE=y|n  Mettre y  pour  avoir  un  mot  de  passe  non  sensible  à  la  casse  et n (valeur par défaut) pour avoir un mot de passe  sensible à la casse. Apparu en version 11. Avant la version 11, le mot de passe n’était pas sensible à la casse.    Aucun espace ne doit être présent autour du signe =. Exemple :  ORACLE_SID=HERMES PWFILE=$ORACLE_HOME/dbs/orapw$ORACLE_SID orapwd file=$PWFILE password=wX#12 entries=4 Sur plate­forme Unix ou Linux, le fichier de mot de passe s’appelle généralement orapw<SID> (<SID> désignant le nom  de l’instance) et est situé dans le répertoire $ORACLE_HOME/dbs.  Sur plate­forme Windows, le fichier de mot de passe s’appelle généralement pwd<SID>.ora (<SID> désignant le nom  de l’instance) et est situé dans le répertoire %ORACLE_HOME%\database.  Si le fichier de mot de passe existe déjà, vous obtiendrez une erreur ; pour recréer un fichier de mot de passe, il faut  supprimer manuellement le précédent ou utiliser l’option FORCE.  N’oubliez  pas  de  positionner  le  paramètreREMOTE_LOGIN_PASSWORDFILE  en  conséquence  (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 plate­forme Windows (possible aussi dans la base de registre) :  set ORACLE_SID=HERMES 

●

Sur plate­forme Unix ou Linux (à adapter en fonction du shell) :  export ORACLE_SID=HERMES 

●

Démarrer SQL*Plus sans se connecter :sqlplus /nolog 

●

Se connecter AS SYSDBA :  ●

Authentifié par le système d’exploitation :  CONNECT / AS SYSDBA 

●

Authentifié par un fichier de mot de passe :  CONNECT sys/wX#12 AS SYSDBA 

- 12 -

© ENI Editions - All rights reserved - Algeria Educ

5. Créer le fichier de paramètres serveur  La création d’un fichier de paramètres serveur s’effectue à partir d’un fichier de paramètres texte, grâce à l’ordre SQL  CREATE SPFILE.  Syntaxe :  CREATE SPFILE [ = ’nom_spfile’ ] FROM PFILE [ = ’nom_pfile’ ] ; Avec :  nom_spfile  Chemin d’accès complet (sur le serveur) et nom du fichier de paramètres serveur à créer. Si non spécifié, un nom par  défaut et un emplacement par défaut sont utilisés (dépend de la plate­forme).  nom_pfile  Chemin d’accès complet (sur le serveur) et nom du fichier de paramètres texte d’origine. Si non spécifié, un nom par  défaut et un emplacement par défaut sont utilisés (dépend de la plate­forme).  Exemple :  SQL> CREATE SPFILE FROM 2 PFILE = ’d:\app\oracle\admin\HERMES\pfile\init.ora’; Fichier créé. Cette  opération  nécessite  une  connexion  SYSDBA  ou  SYSOPER.  Si  le  fichier  de  paramètres  serveur  existe  déjà,  il  est  remplacé.  Le nom et l’emplacement par défaut du fichier de paramètres serveur est le suivant :  ●

%ORACLE_HOME%\database\spfile<SID>.ora (Windows) ; 

●

$ORACLE_HOME/dbs/spfile<SID>.ora (Unix/Linux). 

Utiliser le nom et l’emplacement par défaut facilite l’administration ultérieure de la base, notamment le démarrage (voir  le chapitre Démarrage et arrêt).  Le nom et l’emplacement par défaut du fichier de paramètres texte est le suivant :  ●

%ORACLE_HOME%\database\init<SID>.ora (Windows) ; 

●

$ORACLE_HOME/dbs/init<SID>.ora (Unix/Linux). 

Dans ce chapitre, titre Création de la base de données à la main, section Préparer un nouveau fichier de paramètres  texte,  nous  avons  préconisé  de  ne  pas  créer  de  fichier  de  paramètres  texte  à  l’emplacement  par  défaut.  En  conséquence,  dans  l’ordre  SQL  CREATE SPFILE,  il  faut  donc  spécifier  l’emplacement  du  fichier  de  paramètres  texte  utilisé comme source (c’est la seule fois !).  Si le fichier de paramètres texte contient une erreur de syntaxe (nom de paramètre erroné, parenthèse absente ou  surnuméraire, guillemet ou apostrophe absent ou surnuméraire, etc.), l’ordre CREATE SPFILE va échouer :  ●

Nom de paramètre erroné : LRM-00101: unknown parameter name ... 

●

Syntaxe (parenthèse, guillemet, etc.) : LRM-00116: syntax error at ... 

●

Chemin du fichier texte : LRM-00109: could not open parameter file ... 

Corrigez le fichier de paramètres texte et recommencez. Bien noter qu’à ce stade, les valeurs des paramètres ne sont  pas  vérifiées ; elles  seront  vérifiées  au  démarrage  de  l’instance.  La  création  du  fichier  de  paramètres  serveur  peut  s’effectuer ultérieurement. Personnellement, je préconise de le créer dès le début ; ainsi, dès le premier démarrage de  l’instance, le fichier de paramètres serveurs est utilisé, ce qui permet si besoin de faire des modifications dynamiques  de paramètres en les rendant persistantes dans le fichier de paramètres (cf. Chapitre Gestion de l’instance). 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 13 -

6. Démarrer l’instance  L’instance peut maintenant être démarrée, en NOMOUNT puisque la base de données n’existe pas encore :  SQL> STARTUP NOMOUNT Instance ORACLE lancée. ... Si  le  fichier  de  paramètres  texte  contient  une  erreur  de  valeur  sur  un  paramètre  (valeur  en  dehors  de  la  plage  autorisée, mauvais chemin, etc.), la commande STARTUP NOMOUNT va échouer. Corrigez le fichier de paramètres texte,  recréez le fichier de paramètres serveur et recommencez. Bien noter qu’à ce stade, les valeurs de tous les paramètres  ne sont pas vérifiées ; certaines seront vérifiées ultérieurement (par exemple lors de l’exécution de l’ordre SQL CREATE DATABASE). 

7. Créer la base de données  a. L’ordre SQL CREATE DATABASE  L’ordre SQL CREATE DATABASE permet de créer la base de données.  Syntaxe :  CREATE DATABASE [nom_base] [ USER SYS IDENTIFIED BY mot_de_passe ] [ USER SYSTEM IDENTIFIED BY mot_de_passe ] [ CONTROLFILE REUSE ] [ SET DEFAULT { BIGFILE | SMALLFILE } TABLESPACE ] [ DATAFILE spécification_fichier [,...] ] [ EXTENT MANAGEMENT LOCAL ] [ SYSAUX DATAFILE spécification_fichier [,...] ] [[ BIGFILE | SMALLFILE ] UNDO TABLESPACE nom [ DATAFILE spécification_fichier [,...] ] ] [[ BIGFILE | SMALLFILE ] DEFAULT TEMPORARY TABLESPACE nom [ TEMPFILE spécification_fichier [,...] ] [ EXTENT MANAGEMENT LOCAL ] [ UNIFORM [ SIZE valeur [K|M|G|T] ] ] ] [ DEFAULT TABLESPACE nom [ DATAFILE spécification_fichier [,...] ] [ clause_extent_management ] ] [ LOGFILE [GROUP numéro] spécification_fichier_redo [,...] ] [ ARCHIVELOG | NOARCHIVELOG ] [ FORCE LOGGING ] [ CHARACTER SET jeu ] [ NATIONAL CHARACTER SET jeu ] [ SET TIME_ZONE = { ’+|- hh:mi’ | ’region’ } ] [ MAXINSTANCES nombre ] [ MAXLOGFILES nombre ] [ MAXLOGMEMBERS nombre ] [ MAXDATAFILES nombre ] ; Avec :  - spécification_fichier ’nom_fichier’ [ SIZE valeur [K|M|G|T] ] [REUSE] [ clause_auto_extend ] - clause_auto_extend AUTOEXTEND OFF | AUTOEXTEND ON [ NEXT valeur [K|M|G|T] ] [ MAXSIZE UNLIMITED | valeur [K|M|G|T] ] - clause_extent_management EXTENT MANAGEMENT DICTIONARY | EXTENT MANAGEMENT LOCAL { AUTOALLOCATE | UNIFORM [ SIZE valeur [K|M|G|T] ] } - spécification_fichier_redo (’nom_fichier’ [,...]) [ SIZE valeur [K|M|G] ] [REUSE]

- 14 -

© ENI Editions - All rights reserved - Algeria Educ

Exemple :  CREATE DATABASE hermes USER SYS IDENTIFIED BY wX#12 USER SYSTEM IDENTIFIED BY az#78 SET DEFAULT SMALLFILE TABLESPACE DATAFILE ’&chemin\system01.dbf’ SIZE 200M AUTOEXTEND ON NEXT 10M EXTENT MANAGEMENT LOCAL SYSAUX DATAFILE ’&chemin\sysaux01.dbf’ SIZE 100M AUTOEXTEND ON NEXT 10M LOGFILE GROUP 1 (’&chemin\redo01a.log’, ’&chemin\redo01b.log’) SIZE 50M, GROUP 2 (’&chemin\redo02a.log’, ’&chemin\redo02b.log’) SIZE 50M, GROUP 3 (’&chemin\redo03a.log’, ’&chemin\redo03b.log’) SIZE 50M SMALLFILE UNDO TABLESPACE undotbs DATAFILE ’&chemin\undotbs01.dbf’ SIZE 100M AUTOEXTEND ON NEXT 10M MAXSIZE 1024M SMALLFILE DEFAULT TEMPORARY TABLESPACE temp TEMPFILE ’&chemin\temp01.dbf’ SIZE 100M AUTOEXTEND ON NEXT 10M MAXSIZE 1024M DEFAULT TABLESPACE deftbs DATAFILE ’&chemin\deftbs01.dbf’ SIZE 10M AUTOEXTEND ON NEXT 10M MAXSIZE 500M EXTENT MANAGEMENT LOCAL AUTOALLOCATE NOARCHIVELOG CHARACTER SET WE8ISO8859P15 NATIONAL CHARACTER SET AL16UTF16 SET TIME_ZONE = ’Europe/Paris’ MAXINSTANCES 1 MAXLOGFILES 16 MAXLOGMEMBERS 4 MAXDATAFILES 128 / Cet exemple utilise une variable de substitution &chemin pour le chemin des fichiers de la base de données ; cette  variable est définie au préalable dans SQL*Plus, avec la syntaxe DEFINE chemin=....  L’ordre SQL CREATE DATABASE dure quelques minutes.  L’ordre SQL CREATE DATABASE crée la nouvelle base de données, en l’occurrence :  ●

création des fichiers de contrôle ; 

●

création des fichiers de journalisation ; 

●

création du tablespace SYSTEM et de son fichier de données ; 

●

création du tablespace SYSAUX et de son fichier de données ; 

●

création du dictionnaire de données (dans le tablespace SYSTEM) ; 

●

création d’un segment d’annulation (nommé SYSTEM stocké dans le tablespace SYSTEM) ; 

●

création des comptes SYS et SYSTEM (entre autres) ; 

●

création éventuelle d’un tablespace d’annulation, d’un tablespace temporaire par défaut et d’un tablespace  permanent par défaut. 

À  l’arrivée,  la  base  de  données  est  ouverte  et  parfaitement  opérationnelle.  Par  contre,  les  vues  et  synonymes  du  dictionnaire de données ne sont pas créés et le dictionnaire est donc peu exploitable. La finalisation de la création  du dictionnaire est décrite dans le point Finaliser la création du dictionnaire ci­après. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 15 -

Toutes les structures stockées dans le tablespace SYSTEM sont créées grâce au script sql.bsq qui se trouve dans le  répertoire %ORACLE_HOME%\rdbms\admin ou $ORACLE_HOME/rdbms/admin.  En ce qui concerne les fichiers de la base de données, les recommandations de nommage sont les suivantes :  Fichier de contrôle  controlnn.ctl, nn étant un numéro d’ordre (01, 02, etc.).  Fichier de journalisation  redonn.log, nn, nn étant le numéro du groupe (01, 02, etc.).  Fichiers de données  tablespacenn.dbf, tablespace étant le nom du tablespace et nn le numéro d’ordre du fichier au sein du tablespace  (01, 02, etc.).  Si l’ordre SQL CREATE DATABASE échoue pour une raison ou pour une autre, il est possible que plusieurs des fichiers  de la base de données aient déjà été créés. Dans ce cas, avant de relancer la création, il faut supprimer les fichiers  déjà créés (sous peine que le CREATE DATABASE échoue de nouveau, mais cette fois parce que des fichiers existent  déjà).  Les causes d’un échec de la création d’une base de données peuvent être multiples :  ●

manque d’espace ; 

●

chemin erroné pour un fichier (Oracle ne crée par les répertoires, ils doivent déjà exister) ; 

●

etc. 

Si le message d’erreur affiché à l’écran est sibyllin (du genre ORA-01092: instance ORACLE interrompue. Déconnexion imposée), consultez le fichier d’alerte de l’instance qui vous donnera (normalement) des informations détaillées sur la  nature du problème. 

b. Options de l’ordre SQL CREATE DATABASE  Toutes les clauses de l’ordre SQL CREATE DATABASE sont optionnelles et ont des valeurs par défaut. Dans la pratique,  il est préférable de les spécifier toutes (ou presque) afin de bien contrôler les caractéristiques de la nouvelle base.  nom_base Nom de la base de données. Par défaut égal au paramètre DB_NAME. Provoque une erreur si le nom indiqué ici est  différent de la valeur du paramètre DB_NAME.  USER { SYS | SYSTEM } IDENTIFIED BY Exemple :  USER SYS IDENTIFIED BY wX#12 USER SYSTEM IDENTIFIED BY az#78 Ces deux clauses permettent de changer les mots de passe de SYS et SYSTEM dès la création de la base de données.  Bien noter que ces deux clauses ne sont pas obligatoires (mais risquent de le devenir dans une version ultérieure).  Par contre, si l’une est spécifiée, l’autre doit l’être aussi. Si ces clauses ne sont pas spécifiées, les mots de passe par  défaut sont attribués à SYS (change_on_install) et SYSTEM (manager).  CONTROLFILE REUSE Si l’option est présente et qu’un des fichiers indiqués dans le paramètre CONTROL_FILES existe déjà, Oracle le réutilise  et l’écrase. Si l’option est absente, dans la même situation, un message d’erreur s’affiche et la création de la base  est stoppée.  Du point de vue de la sécurité, il est préférable de ne pas mettre cette option afin d’éviter d’écraser par mégarde un  fichier de contrôle utilisé par une autre base. 

- 16 -

© ENI Editions - All rights reserved - Algeria Educ

SET DEFAULT { BIGFILE | SMALLFILE } TABLESPACE Cette clause spécifie le type par défaut (BIGFILE ou SMALLFILE) des tablespaces créés lors de la création de la base  de données. Le type spécifié ici s’applique notamment aux tablespaces SYSTEM et SYSAUX, et ne peut pas être modifié  pour ces deux tablespaces. Si cette clause est omise, Oracle crée des tablespaces SMALLFILE par défaut.  Un tablespace  BIGFILE  est  un  tablespace  qui  ne  comporte  qu’un  seul  fichier  de  données  qui  peut  contenir  jusqu’à  2^32  blocs  Oracle  (plus  de  4  milliards).  Un  tablespace  SMALLFILE  est  le  tablespace  traditionnel  d’Oracle,  qui  peut  comporter jusqu’à 1022 fichiers, chaque fichier pouvant contenir jusqu’à 2^22 blocs Oracle (plus de 4 millions). Les  tablespaces BIGFILE sont apparus en version 10.  Cette  notion  de  tablespace BIGFILE  est  présentée  plus  en  détail  dans  le  chapitre  Gestion  des  tablespaces  et  des  fichiers de données.  DATAFILE spécification_fichier [,...] Exemple :  DATAFILE ’&chemin\system01.dbf’ SIZE 200M AUTOEXTEND ON NEXT 10M Cette clause permet de préciser l’emplacement, le nom et la taille d’un (ou éventuellement de plusieurs) fichiers de  données pour le tablespace SYSTEM.  La syntaxe est la suivante pour la spécification d’un fichier de données :  - spécification_fichier ’nom_fichier’ [ SIZE valeur [K|M|G|T] ] [REUSE] [ clause_auto_extend ] nom_fichier  Chemin  d’accès  complet  au  fichier  de  données,  normalement  dans  un  répertoire  de  données  (oradata)  pour  respecter le standard OFA.  SIZE  Taille initiale du fichier. La taille peut être omise uniquement si l’option REUSE est utilisée et que le fichier existe déjà.  REUSE  Si  l’option  est  présente  et  que  le  fichier  existe  déjà,  Oracle  le  réutilise  et  l’écrase.  Si  l’option  est  absente,  dans  la  même situation, un message d’erreur s’affiche et la création de la base de données est stoppée. Du point de vue de  la sécurité, il est préférable de ne pas mettre cette option afin d’éviter d’écraser par mégarde un fichier de données  utilisé par une autre base de données.  - clause_auto_extend AUTOEXTEND OFF | AUTOEXTEND ON [ NEXT valeur [K|M|G|T] ] [ MAXSIZE UNLIMITED | valeur [K|M|G|T] ] AUTOEXTEND  Indique  si  le  fichier  de  données  peut  (ON)  ou  non  (OFF)  grossir  une  fois  que  tout  l’espace  initialement  alloué  est  complètement utilisé.  NEXT  Espace minimum alloué au fichier lors de l’extension.  MAXSIZE  Taille maximale du fichier, éventuellement non limitée (UNLIMITED). 

La gestion des tablespaces et des fichiers de données sera présentée en détail dans le chapitre Gestion des  tablespaces et des fichiers de données. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 17 -

Pour 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,value FROM v$sga 2 UNION ALL 3 SELECT ’*** TOTAL ***’,SUM(value) FROM v$sga; NAME VALUE -------------------- ---------Fixed Size 2145984 Variable Size 356516160 Database Buffers 159383552 Redo Buffers 3891200 *** TOTAL *** 521936896 La vue V$SGAINFO donne des informations plus détaillées sur la SGA, et s’avère à l’usage plus intéressante que la vue  V$SGA.  SQL> SELECT name,ROUND(bytes/(1024*1024),1) 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  (240­72­4­4­152),  soit  2  granules,  réservés  pour  les  structures  non  dynamiques  de  la  SGA  (Redo Log Buffer et SGA fixe).  En  complément,  vous  pouvez  interroger  la  vue  V$MEMORY_RESIZE_OPS  pour  avoir  l’historique  des  800  dernières  opérations de redimensionnement de la mémoire et V$MEMORY_ CURRENT_RESIZE_OPS pour avoir des informations sur  un éventuel redimensionnement en cours.  Les  vues  V$MEMORY_*  sont  apparues  en  version  11  et  tiennent  compte  de  la  PGA.  Il  existe  des  vues  équivalentes,  apparues  en  version  10,  mais  limitées  à  la  SGA : V$SGA_ DYNAMIC_COMPONENTS,  V$SGA_RESIZE_OPS  et  V$SGA_CURRENT_RESIZE_OPS. 

3. Modifier la mémoire dynamiquement  a. Avec la gestion automatique de la mémoire partagée  Lorsque  la  gestion  automatique  de  la  mémoire  partagée  est  activée  (paramètre  SGA_TARGET  différent  de  zéro),  la  taille de la SGA peut être modifiée dynamiquement en modifiant la valeur du paramètre SGA_TARGET.  La  valeur  de  ce  paramètre  peut  être  augmentée  jusqu’à  la  valeur  du  paramètre  SGA_MAX_SIZE.  Elle  peut  être  diminuée  jusqu’à  une  valeur  minimale  déterminée  par  Oracle  en  tenant  de  différents  éléments,  dont  la  taille  que  vous avez éventuellement affectée aux composantes non prises en charge par la gestion automatique (paramètres  DB_nK_CACHE_SIZE  par  exemple)  mais  aussi  de  la  taille  minimale  que  vous  avez  pu  définir  pour  les  composantes  gérées automatiquement. 

© ENI Editions - All rights reserved - Algeria Educ

- 3-

Lorsque le paramètre SGA_TARGET est modifié, seules les composantes gérées automatiquement sont modifiées, et  la  répartition  entre  les  différentes  composantes  est  automatiquement  déterminée  par  Oracle ; les  composantes  gérées manuellement restent inchangées. En cas de diminution, Oracle ne descendra pas en dessous de la valeur  minimale que vous avez pu définir pour une ou plusieurs composantes.  Si vous le souhaitez, vous pouvez aussi modifier la valeur des paramètres gérés manuellement et/ou la valeur des  paramètres gérés automatiquement (dans ce dernier cas vous définissez alors un minimum pour le paramètre).  Le comportement est le suivant :  ●

●

●

●

Si vous diminuez la valeur d’un paramètre géré manuellement, vous augmentez implicitement la quantité de  mémoire  disponible  pour  la  gestion  automatique ; la  mémoire  supplémentaire  va  être  automatiquement  réattribuée aux paramètres gérés automatiquement (Oracle décide de la répartition).  Si vous augmentez la valeur d’un paramètre géré manuellement, vous diminuez implicitement la quantité de  mémoire  disponible  pour  la  gestion  automatique ; cette  quantité  de  mémoire  va  être  automatiquement  enlevée aux paramètres gérés automatiquement (Oracle décide de la répartition).  Si  vous  diminuez  la  valeur  d’un  paramètre  géré  automatiquement,  vous  ne  diminuez  en  fait  que  la  valeur  minimale de ce paramètre, mais pas sa valeur actuelle. En cas de besoin, Oracle pourra diminuer la valeur  actuelle du paramètre pour attribuer de la mémoire à une autre structure. Si vous mettez la valeur à 0, vous  n’imposez plus de minimum.  Si vous augmentez la valeur d’un paramètre géré automatiquement, vous augmentez la valeur minimale de  ce paramètre, mais pas sa valeur actuelle si, celle­ci est actuellement supérieure au nouveau minimum. Par  contre, si le nouveau minimum est supérieur à la valeur actuelle, la valeur est immédiatement augmentée,  et Oracle diminue en contrepartie les autres paramètres automatiques (Oracle décide de la répartition). 

Exemple :  SQL> -- contenu du script memoire.sql SQL> HOST more memoire.sql COL component FOR A30 SELECT component, current_size/1024/1024 current_size, user_specified_size/1024/1024 user_specified_size FROM v$memory_dynamic_components WHERE current_size 0 UNION ALL SELECT ’*** LIBRE SGA ***’,current_size/1024/1024,null FROM v$sga_dynamic_free_memory / SQL> -- situation de départ SQL> SELECT name,display_value FROM v$parameter 2 WHERE name IN (’sga_target’,’sga_max_size’); NAME DISPLAY_VALUE --------------------- ----------------sga_max_size 300M sga_target 252M SQL> @memoire COMPONENT CURRENT_SIZE USER_SPECIFIED_SIZE ------------------------------ ------------ ------------------shared pool 72 0 large pool 4 0 java pool 4 0 SGA Target 252 252 DEFAULT buffer cache 164 0 PGA Target 64 64 *** LIBRE SGA *** 48 SQL> -- augmentation de SGA_TARGET à 300M SQL> ALTER SYSTEM SET SGA_TARGET = 300M; Système modifié. SQL> @memoire COMPONENT CURRENT_SIZE USER_SPECIFIED_SIZE ------------------------------ ------------ ------------------shared pool 72 0

- 4-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

large pool java pool SGA Target DEFAULT buffer cache PGA Target *** LIBRE SGA ***

4 4 300 212 64 0

0 0 300 0 64

SQL> -- affectation d’une valeur à DB_16K_CACHE_SIZE SQL> -- et d’un minimum à SHARED_POOL_SIZE SQL> ALTER SYSTEM SET 2 DB_16K_CACHE_SIZE = 32M 3 SHARED_POOL_SIZE = 96M ; Système modifié. SQL> @memoire COMPONENT CURRENT_SIZE USER_SPECIFIED_SIZE ------------------------------ ------------ ------------------shared pool 96 0 large pool 4 0 java pool 4 0 SGA Target 300 300 DEFAULT buffer cache 156 0 DEFAULT 16K buffer cache 32 32 PGA Target 64 64 *** LIBRE SGA *** 0 SQL> -- diminution de SGA_TARGET SQL> ALTER SYSTEM SET SGA_TARGET = 168M; Système modifié. SQL> @memoire COMPONENT CURRENT_SIZE USER_SPECIFIED_SIZE ------------------------------ ------------ ------------------shared pool 96 96 large pool 4 0 java pool 4 0 SGA Target 168 168 DEFAULT buffer cache 24 0 DEFAULT 16K buffer cache 32 32 PGA Target 64 64 *** LIBRE SGA *** 132 Sur cet exemple, nous voyons les choses suivantes :  ●

●

●

Lors  de  l’augmentation  de  SGA_TARGET  à  300  Mo,  la  totalité  de  la  mémoire  supplémentaire  est  allouée  au  Buffer Cache, et il n’y a plus de mémoire libre pour la SGA.  Lors  de  l’affectation d’une  valeur  au  paramètre DB_16K_CACHE_SIZE  (géré  manuellement)  et  d’une  valeur  à  SHARED_POOL_SIZE (minimum puisque le paramètre est automatique), un cache pour les blocs de 16 Ko est  alloué  à  la  valeur  demandée  et  la  Shared  Pool  est  augmentée,  car  la  valeur  actuelle  était  inférieure  au  nouveau minimum. Le Buffer Cache est diminué en conséquence (plus de mémoire libre pour la SGA).  Lors  de  la  diminution  de  SGA_TARGET  à  168  Mo,  le  Buffer  Cache  est  diminué.  Les  autres  paramètres  ne  peuvent  pas  être  diminués : DB_16K_CACHE_SIZE  est  géré  manuellement  et  les  autres  sont  à  leur  valeur  minimale. 

b. Avec la gestion automatique de la mémoire  Lorsque  la  gestion  automatique  de  la  mémoire  est  activée  (paramètre  MEMORY_TARGET),  la  taille  de  la  mémoire  allouée  à  l’instance  (SGA  et  PGA)  peut  être  modifiée  dynamiquement  en  modifiant  la  valeur  du  paramètre  MEMORY_TARGET.  La valeur de ce paramètre peut être augmentée jusqu’à la valeur du paramètre  MEMORY_ MAX_TARGET. Il peut être  diminué jusqu’à une valeur minimale déterminée par Oracle en tenant compte de différents éléments (comme pour  la gestion automatique de la mémoire partagée).  Lorsque le paramètre MEMORY_TARGET est modifié, Oracle détermine une nouvelle répartition de la mémoire entre la  PGA  (PGA_AGGREGATE_TARGET)  et  la  SGA  (SGA_TARGET),  puis  une  nouvelle  répartition  de  la  SGA  entre  ces  différentes 

© ENI Editions - All rights reserved - Algeria Educ

- 5-

composantes, selon les mêmes règles que pour la gestion automatique de la mémoire partagée.  Du point de vue de la SGA, la gestion automatique de la mémoire n’est qu’une extension de la gestion automatique  de  la  mémoire  partagée.  Toutes  les  règles  exposées  précédemment  sur  la  modification  des  paramètres  gérés  manuellement et des paramètres gérés automatiquement demeurent valable (voir le titre précédent).  En  complément,  si  vous  le  souhaitez,  vous  pouvez  aussi  modifier  la  valeur  des  paramètres  SGA_TARGET  et  PGA_AGGREGATE_TARGET.  Dans  ce  cas,  SGA_TARGET  et  PGA_ AGGREGATE_TARGET  imposent  simplement  un  minimum  respectivement pour la SGA et pour la PGA.  Le comportement est le suivant :  ●

●

Si vous augmentez la valeur de  SGA_TARGET ou  PGA_AGGREGATE_TARGET, vous augmentez la valeur minimale  de  ces  paramètres,  mais  pas  leur  valeur  actuelle  si,  celle­ci  est  actuellement  supérieure  au  nouveau  minimum. Par contre, si le nouveau minimum est supérieur à la valeur actuelle, la valeur est immédiatement  augmentée,  et  Oracle  diminue  en  contrepartie  les  autres  paramètres  automatiques  (Oracle  décide  de  la  répartition).  Si vous diminuez la valeur de SGA_TARGET ou PGA_AGGREGATE_TARGET, vous ne diminuez en fait que la valeur  minimale  de  ces  paramètres,  mais  pas  leur  valeur  actuelle.  En  cas  de  besoin,  Oracle  pourra  diminuer  la  valeur actuelle du paramètre pour attribuer de la mémoire à une autre structure. Si vous mettez la valeur à  0, vous n’imposez plus de minimum. 

Par ailleurs, n’oubliez pas que le paramètre statique SGA_MAX_SIZE, s’il est défini, impose une taille maximum pour la  SGA.  Exemple :  SQL> -- contenu du script memoire.sql SQL> HOST more memoire.sql COL component FOR A30 SELECT component, current_size/1024/1024 current_size, user_specified_size/1024/1024 user_specified_size FROM v$memory_dynamic_components WHERE current_size 0 UNION ALL SELECT ’*** LIBRE SGA ***’,current_size/1024/1024,null FROM v$sga_dynamic_free_memory / SQL> -- situation de départ SQL> SELECT name,display_value FROM v$parameter 2 WHERE name IN (’memory_target’,’memory_max_target’); NAME DISPLAY_VALUE --------------------- ----------------memory_target 400M memory_max_target 500M SQL> @memoire COMPONENT CURRENT_SIZE USER_SPECIFIED_SIZE ------------------------------ ------------ ------------------shared pool 72 0 large pool 4 0 java pool 4 0 SGA Target 240 0 DEFAULT buffer cache 152 0 PGA Target 160 0 *** LIBRE SGA *** 260 SQL> -- augmentation de MEMORY_TARGET à 500M SQL> ALTER SYSTEM SET MEMORY_TARGET = 500M; Système modifié. SQL> @memoire COMPONENT CURRENT_SIZE USER_SPECIFIED_SIZE ------------------------------ ------------ ------------------shared pool 72 0 large pool 4 0 java pool 4 0 SGA Target 240 0 DEFAULT buffer cache 152 0 - 6-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

PGA Target 260 0 *** LIBRE SGA *** 260 SQL> -- affectation d’une valeur à DB_16K_CACHE_SIZE SQL> ALTER SYSTEM SET DB_16K_CACHE_SIZE = 32M; Système modifié. SQL> @memoire COMPONENT CURRENT_SIZE USER_SPECIFIED_SIZE ------------------------------ ------------ ------------------shared pool 72 0 large pool 4 0 java pool 4 0 SGA Target 240 0 DEFAULT buffer cache 120 0 DEFAULT 16K buffer cache 32 32 PGA Target 260 0 *** LIBRE SGA *** 260 SQL> -- affectation d’une valeur à SGA_TARGET SQL> ALTER SYSTEM SET SGA_TARGET = 300M; Système modifié. SQL> @memoire COMPONENT CURRENT_SIZE USER_SPECIFIED_SIZE ------------------------------ ------------ ------------------shared pool 72 0 large pool 4 0 java pool 4 0 SGA Target 300 300 DEFAULT buffer cache 180 0 DEFAULT 16K buffer cache 32 32 PGA Target 200 0 *** LIBRE SGA *** 200 SQL> -- diminution de MEMORY_TARGET SQL> ALTER SYSTEM SET MEMORY_TARGET = 352M; Système modifié. SQL> @memoire COMPONENT CURRENT_SIZE USER_SPECIFIED_SIZE ------------------------------ ------------ ------------------shared pool 72 0 large pool 4 0 java pool 4 0 SGA Target 300 300 DEFAULT buffer cache 180 0 DEFAULT 16K buffer cache 32 32 PGA Target 52 0 *** LIBRE SGA *** 200 Sur cet exemple, nous voyons les choses suivantes :  ●

●

●

●

Lors de l’augmentation de MEMORY_TARGET à 500 Mo, la totalité de la mémoire supplémentaire est allouée à  la PGA.  Lors de l’affectation d’une valeur au paramètre DB_16K_CACHE_SIZE (géré manuellement), un cache pour les  blocs de 16 Ko est alloué à la valeur demandée et le Buffer Cache est diminué en conséquence (comme pour  la gestion automatique de la mémoire partagée).  Lors  de  l’affectation  d’une  valeur  (minimum)  à  SGA_TARGET,  la  SGA  est  augmentée  immédiatement  car  la  valeur  actuelle  était  inférieure  au  nouveau  minimum ; la  quantité  de  mémoire  supplémentaire  est  intégralement allouée au Buffer Cache.  Lors de la diminution de  MEMORY_TARGET à 352 Mo, la PGA est diminuée. La SGA ne peut pas être diminuée  car elle est à la valeur minimale imposée par SGA_TARGET. 

c. Sans la gestion automatique 

© ENI Editions - All rights reserved - Algeria Educ

- 7-

Si vous n’utilisez pas la gestion automatique de la mémoire ni la gestion automatique de la mémoire partagée, les  modifications  apportées  aux  paramètres  sont  immédiatement  prises  en  compte,  toujours  dans  la  limite  de  SGA_MAX_SIZE et MEMORY_MAX_TARGET (s’il est défini). 

d. Conclusion et conseil  Oracle  recommande  d’utiliser  la  gestion  automatique  de  la  mémoire  qui  simplifie  beaucoup  le  travail  de  l’administrateur : il  suffit  juste  de  définir  le  paramètre  MEMORY_TARGET  (et  éventuellement  le  paramètre  MEMORY_MAX_TARGET).  Si vous utilisez la gestion automatique de la mémoire, ou simplement de la mémoire partagée, il faut, par contre,  éviter  d’imposer  trop  de  contraintes  à  Oracle  en  donnant  des  valeurs  minimums  aux  paramètres  gérés  automatiquement.  En  interne,  les  paramètres  __*  (__db_cache_size  par  exemple)  sont  utilisés  par  les  fonctionnalités  de  gestion  automatique.  Ils  donnent  la  quantité  de  mémoire  actuellement  allouée  à  chaque  structure  gérée  automatiquement ; le  paramètre  « normal »  (non  préfixé  par  les  deux  caractères  soulignés)  donne  la  valeur  minimale  du  paramètre,  telle  que  vous  avez  pu  la  définir  (0  sinon).  La  valeur  de  ces  paramètres  internes  est  enregistrée dans le fichier de paramètres serveur (s’il est utilisé) ; en cas de redémarrage, la configuration mémoire,  qui était utilisée au moment de l’arrêt (a priori optimale), sera rétablie. 

4. Utiliser le Database Control  a. Accès à la page de gestion de la mémoire  Dans le Database Control, cliquez sur le lien Serveur sur la page d’accueil puis sur le lien Fonctions de conseil sur  la  mémoire  (cadre  Configuration  de  base  de  données)  pour  accéder  à  la  page  de  gestion  des  paramètres  de  mémoire.  Le contenu de la page dépend du mode de gestion de la mémoire.  Pour affecter une valeur minimum à un paramètre de la SGA géré automatiquement, ou pour affecter une  valeur  à  un  paramètre  de  la  SGA  géré  manuellement,  vous  devez  passer  par  la  page  Paramètres  d’initialisation (cf. la section Gestion des paramètres d’initialisation). 

b. Avec la gestion automatique de la mémoire  Lorsque la gestion automatique de la mémoire est activée, le Database Control montre l’historique de la répartition  de la mémoire entre la SGA et la PGA. 

- 8-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

  Dans la deuxième partie de l’écran, l’onglet SGA affiche la répartition de la SGA entre les différentes composantes  (avec l’historique de la répartition) et l’onglet PGA, quelques informations sur la PGA : 

 

© ENI Editions - All rights reserved - Algeria Educ

- 9-

  Dans la première partie de la fenêtre, la zone Taille totale de mémoire permet de modifier la taille de la mémoire  (paramètre  MEMORY_TARGET) et la zone  Taille  maximale  de  mémoire,  la  taille  maximum  de  la  mémoire  (paramètre  MEMORY_MAX_TARGET). 

  Vous pouvez cocher la case Appliquer les modifications uniquement au fichier SPFILE (tout en bas de l’écran) si  vous souhaitez que les modifications n’affectent que le fichier de paramètres serveur (SCOPE=SPFILE). Par défaut, les  modifications  affectent  l’instance  actuelle  et  le  fichier  de  paramètres  serveur  (SCOPE=BOTH) ; le  Database  Control  vous  proposera  en  conséquence  de  redémarrer  si  vous  modifiez  la  taille  maximum  de  la  mémoire  (paramètre  statique).  Cliquez  sur  le  bouton  Désactiver  si  vous  souhaitez  désactiver  la  gestion  automatique  de  la  mémoire.  Dans la nouvelle configuration, la gestion automatique de la mémoire partagée est activée. 

c. Avec la gestion automatique de la mémoire partagée  Lorsque  la  gestion  automatique  de  la  mémoire  partagée  est  activée,  le  Database  Control  permet  de  régler  séparément la taille de la SGA et la taille de la PGA. 

- 10 -

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

  Dans  l’onglet  SGA,  le  Database  Control  affiche  la  répartition  de  la  SGA  entre  les  différentes  composantes  (avec  l’historique  de  la  répartition).  La  zone Taille  totale  de  mémoire  SGA  (Mo)  permet  de  modifier  la  taille  de  la  SGA  (paramètre SGA_TARGET) et la zone Taille maximale de mémoire SGA (MB), la taille maximum de la SGA (paramètre  SGA_MAX_SIZE). 

  Dans l’onglet PGA, le Database Control affiche quelques informations sur la PGA. La zone Cible d’agrégation de la  mémoire PGA permet de modifier la taille de la PGA (paramètre PGA_AGGREGATE_TARGET). 

© ENI Editions - All rights reserved - Algeria Educ

- 11 -

La case Appliquer les modifications uniquement au fichier SPFILE a le même rôle qu’avec la gestion automatique  de la mémoire. Le Database Control vous proposera notamment de redémarrer si vous modifiez la taille maximum  de la SGA (paramètre statique).  En haut de l’écran, vous pouvez cliquer sur le bouton Activer pour activer la gestion automatique de la mémoire. Le  Database Control vous invite alors à régler la taille de la mémoire (paramètre MEMORY_TARGET) et la taille maximum  de la mémoire (paramètre MEMORY_MAX_TARGET) : 

  À l’inverse, dans l’onglet SGA, vous pouvez cliquer sur le bouton Désactiver pour désactiver la gestion automatique  de la mémoire partagée. Le Database Control vous invite alors à régler la taille des différents composants de la SGA  qui sont gérés automatiquement : 

 

d. Sans la gestion automatique  Lorsque la gestion automatique de la mémoire partagée est désactivée, l’onglet SGA se présente ainsi : 

- 12 -

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

  La Database Control affiche la taille des structures de la SGA qui sont gérées automatiquement, ainsi que la taille  maximum de la SGA, et permet de les modifier (voir ci­dessus pour le fonctionnement).  Cliquez  sur  le  bouton  Activer  de  l’onglet  SGA  si  vous  souhaitez  activer  la  gestion  automatique  de  la  mémoire  partagée. Le Database Control vous invite alors à régler la taille de la SGA (SGA_TARGET) : 

  Comme  dans  le  point  précédent,  le  bouton  Activer  situé  tout  en  haut  de  l’écran  permet  d’activer  la  gestion  automatique de la mémoire. 

5. Problèmes courants et solutions  ORA-00845: MEMORY_TARGET non pris en charge sur ce système  Explication  La gestion automatique de la mémoire partagée ne peut pas être activée.  Cause(s)  La plate­forme n’est pas supportée ou, sur plate­forme Linux, /dev/shm n’est pas dimensionné correctement.  Action(s)  Si  vous  êtes  sur  une  plate­forme  Linux,  redimensionnez  /dev/shm  ou  diminuez  la  valeur  de  MEMORY_TARGET  (voir  la  © ENI Editions - All rights reserved - Algeria Educ

- 13 -

documentation "Administrator’s Reference for Linux and UNIX­Based Operating Systems").  Lorsque  vous  modifiez  la  valeur  d’un  paramètre  de  mémoire  avec  une  valeur  erronée  (trop  grande  ou  trop  petite)  vous  obtenez  une  erreur  ORA-02097  (cf.  section  Gestion  des  paramètres  dans  ce  chapitre),  suivie  d’une  deuxième  erreur qui précise la nature du problème.  Les principaux cas sont les suivants :  ■

MEMORY_TARGET trop grand 

ORA-00837: la valeur de MEMORY_TARGET est supérieure à celle de MEMORY_MAX_TARGET  ■

MEMORY_TARGET trop petit 

ORA-00838: la valeur de MEMORY_TARGET est trop petite ; elle doit être de nnn Mo au minimum  ORA-00846: impossible de réduire MEMORY_TARGET a la valeur indiquée  ■

SGA_TARGET trop grand 

ORA-00823: la valeur de sga_target est supérieure a celle de sga_max_size  ■

SGA_TARGET trop petit 

ORA-00827: impossible de réduire sga_target a la valeur indiquée  ■

PGA_AGGREGATE_TARGET trop grand par rapport à MEMORY_TARGET 

ORA-00840: la valeur de PGA_AGGREGATE_TARGET ne peut pas être changée pour la valeur indiquée  ■

PGA_AGGREGATE_TARGET hors limites 

ORA-00093: pga_aggregate_target doit être compris entre 10M et 4096G-1  ■

DB_CACHE_SIZE (ou DB_nk_CACHE_SIZE) trop grand par rapport à la mémoire disponible pour la SGA 

ORA-00384: mémoire insuffisante pour faire évoluer le cache  ■

*_POOL_SIZE trop grand par rapport à la mémoire disponible pour la SGA 

ORA-04033: mémoire insuffisante pour augmenter la taille du pool  ■

*_POOL_SIZE trop petit 

ORA-04034: impossible de réduire le pool a la taille indiquée. 

- 14 -

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

Gestion des fichiers de contrôle  1. Rappel sur le fichier de contrôle  Le fichier de contrôle contient des informations de contrôle sur la base de données :  ●

le nom de la base de données ; 

●

la date/heure de création de la base de données ; 

●

l’emplacement des autres fichiers de la base de données (fichiers de données et fichiers de journalisation) ; 

●

le numéro de séquence actuel des fichiers de journalisation ; 

●

des informations sur les points de reprise (checkpoint), etc. 

Le  fichier  de  contrôle  est  automatiquement  mis  à  jour  par  Oracle  lors  de  chaque  modification  de  la  structure  de  la  base de données (ajout ou déplacement d’un fichier par exemple). La taille du fichier de contrôle est déterminée par  Oracle.  Lorsqu’une instance est lancée pour ouvrir une base de données, le fichier de contrôle est le premier fichier ouvert. Il  permet ensuite, à l’instance de localiser et d’ouvrir les autres fichiers de la base de données. Si le fichier de contrôle  ne  peut  pas  être  trouvé  (ou  est  endommagé),  la  base  de  données  ne  peut  pas  être  montée,  même  si  les  autres  fichiers  de  la  base  de  données  sont  présents  (l’instance  reste  dans  le  statut  NOMOUNT).  Différents  scénarios  de  restauration  sont  alors  disponibles  en  fonction  de  la  situation  (présence  ou  non  d’une  sauvegarde  du  fichier  de  contrôle, notamment) pour redémarrer la base de données, mais ce sont des scénarios relativement complexes.  Pour  des  raisons  de  sécurité,  il  est  donc  conseillé  de  multiplexer  le  fichier  de  contrôle,  c’est­à­dire  de  disposer  de  plusieurs  copies  gérées  en  miroir  (multiplexées)  par  Oracle.  Techniquement,  il  est  possible  de  créer  une  base  de  données avec un seul fichier de contrôle mais il est vivement conseillé d’utiliser plusieurs copies, même si le serveur  ne comprend qu’un disque (cela met à l’abri d’une suppression accidentelle).  Plusieurs fichiers de contrôle peuvent être spécifiés lors de la création de la base (chapitre Création d’une nouvelle  base de données) ou ultérieurement (voir ci­après). 

2. Trouver des informations sur les fichiers de contrôle  La vue V$CONTROLFILEdonne la liste des fichiers de contrôle :  SQL> SELECT * FROM v$controlfile; STATUS NAME ------- ------------------------------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 ci­après.  V$LOG  GROUP#  Numéro du groupe. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

SEQUENCE#  Numéro de séquence du groupe (s’incrémente à chaque basculement).  BYTES  Taille en octets.  MEMBERS  Nombre de membres.  ARCHIVED  Groupe archivé (YES ou NO).  STATUS  Statut du groupe :  ●

UNUSED : groupe jamais écrit (sans doute nouveau) ; 

●

CURRENT : groupe courant (groupe en cours d’écriture) ; 

●

ACTIVE : groupe encore nécessaire en cas de restauration d’instance (point de reprise non terminé) ; 

●

INACTIVE : groupe inutile pour une restauration d’instance (point de reprise terminé). 

FIRST_CHANGE#  Plus petit numéro SCN écrit dans le groupe.  FIRST_TIME  Date et heure du plus petit numéro SCN.  V$LOGFILE  GROUP#  Numéro du groupe.  STATUS  Statut du membre :  ●

INVALID : fichier inaccessible ; 

●

STALE : fichier incomplet (statut des nouveaux membres) ; 

●

DELETED : fichier supprimé, plus utilisé ; 

●

vide : fichier utilisé. 

MEMBER  Nom complet du fichier membre  IS_RECOVERY_DEST_FILE  Indique (YES ou NO) si le membre est stocké dans la zone de récupération rapide (telle que définie par le paramètre  - 2-

© ENI Editions - All rights reserved - Algeria Educ

DB_RECOVERY_ FILE_DEST).  V$LOG_HISTORY  SEQUENCE#  Numéro de séquence du groupe.  FIRST_CHANGE#  Plus petit numéro SCN écrit dans le groupe.  NEXT_CHANGE#  Plus grand numéro SCN écrit dans le groupe.  FIRST_TIME  Date et heure du plus petit numéro SCN écrit dans le groupe.  Exemple :  SQL> SELECT group#,sequence#,bytes/(1024*1024) size_mo,members,status 2 FROM v$log; GROUP# SEQUENCE# SIZE_MO MEMBERS STATUS ------ ---------- ---------- ---------- ---------------1 16 50 2 INACTIVE 2 17 50 2 CURRENT 3 18 50 2 INACTIVE SQL> SELECT group#,status,member,is_recovery_dest_file 2 FROM v$logfile 3 ORDER BY group#; GROUP# STATUS MEMBER IS_RECOVERY_DEST_FILE ------ ------- ------------------------------ --------------------1 F:\ORADATA\HERMES\REDO01A.LOG NO 1 G:\ORADATA\HERMES\REDO01B.LOG NO 2 F:\ORADATA\HERMES\REDO02A.LOG NO 2 G:\ORADATA\HERMES\REDO02B.LOG NO 3 F:\ORADATA\HERMES\REDO03A.LOG NO 3 G:\ORADATA\HERMES\REDO03B.LOG NO SQL> SELECT sequence#,TO_CHAR(first_time,’DD/MM HH24:MI’) first_time 2 FROM v$log_history; SEQUENCE# FIRST_TIME --------- -----------1 16/07 14:53 2 16/07 14:55 3 16/07 14:56 15 16/07 15:17 16 16/07 15:19 17 16/07 15:25

3. Dimensionner les fichiers de journalisation  Déterminer le nombre de groupes et la taille des groupes est un sujet complexe pour lequel il n’existe pas de formule  de calcul. Par contre, il est possible, a posteriori, d’auditer le fonctionnement des fichiers de journalisation afin de voir  si le nombre de groupes et la taille des groupes sont satisfaisants ; en cas de problème, il est relativement simple  d’apporter des corrections en ajoutant un nouveau groupe ou en augmentant la taille des groupes (cette action est  un peu plus complexe).  L’objectif est simple :  ●

openmirrors.com

Utiliser  des  fichiers  de  journalisation  de  taille  suffisante  pour  éviter  des  basculements  trop  fréquents,  pénalisants pour les performances. La recommandation d’Oracle  est  d’avoir un basculement toutes les 20 à 

© ENI Editions - All rights reserved - Algeria Educ

- 3-

30 minutes environ.  Utiliser un nombre suffisant de groupes pour permettre aux points de reprise et à l’archivage de se terminer  avant que l’instance ne revienne sur un fichier de journalisation. Si le point de reprise ou l’archivage ne sont  pas terminés, le processus LGWR attend, ce qui est très mauvais pour les performances. 

●

Avoir des basculements peu fréquents (plus de 4 heures par exemple), et donc des points de reprise peu fréquents,  combinés à une forte activité de mise à jour (possible avec des fichiers de journalisation volumineux), est bénéfique  pour les performances mais cela risque, en cas d’arrêt anormal de l’instance, d’augmenter la durée de la récupération  de l’instance et donc, la durée du redémarrage. La recommandation d’Oracle est de trouver un bon compromis entre  la performance en fonctionnement normal et la performance du redémarrage, en cas d’arrêt anormal de l’instance.  Le  fichier  d’alerte  de  l’instance  (voir  la  section  Diagnostiquer  les  problèmes  du  chapitre  Les  outils  d’administration)  peut  être  utilisé  comme  premier  outil  d’audit  simple  de  l’activité  des  fichiers  de  journalisation.  Les  informations  à  surveiller sont les suivantes :  Basculement de fichier de journalisation : 

●

Wed Jul 16 15:25:04 2008 Thread 1 advanced to log sequence 17 Current log# 2 seq# 17 mem# 0: F:\ORADATA\HERMES\REDO02A.LOG Current log# 2 seq# 17 mem# 1: G:\ORADATA\HERMES\REDO02B.LOG Attente lors d’un basculement de fichier de journalisation : 

●

●

Point de reprise non terminé  Wed Jul 16 15:17:28 2008 Thread 1 cannot allocate new log, sequence 15 Checkpoint not complete

●

Archivage non terminé  Wed Jul 16 15:19:02 2008 Thread 1 cannot allocate new log, sequence 16 All online logs needed archiving

La vue V$LOG_HISTORY peut aussi être utilisée pour analyser la vitesse de basculement des fichiers de journalisation.  Si la durée qui sépare les messages de ce type est systématiquement courte, les fichiers de journalisation sont mal  dimensionnés. Si cette situation de basculements rapprochés (ou de basculements temporairement bloqués) est rare  (une  fois  par  jour  par  exemple),  le  dimensionnement  est  satisfaisant  (la  situation  est  peut  être  liée  à  un  batch  qui  génère un pic de l’activité transactionnelle).  En cas de basculement trop rapide (largement inférieur à 20/30 minutes), il faut augmenter la taille des groupes.  En  cas  d’attentes  fréquentes  lors  d’un  basculement,  il  faut  ajouter  un  groupe  (le  processus  LGWR  mettra  plus  de  temps  à  faire  le  tour  des  groupes,  ce  qui  laissera  plus  de  temps  au  point  de  reprise  ou  à  l’archivage  pour  se  terminer).  Les opérations d’ajout d’un groupe ou d’augmentation de la taille des groupes sont présentées dans la suite de ce  chapitre. 

4. Administrer les fichiers de journalisation  a. Vue d’ensemble  Différentes opérations d’administration peuvent être effectuées sur les fichiers de journalisation :  ●

●

- 4-

Ajouter  un  nouveau  membre  dans  un  groupe permet d’améliorer la sécurité des fichiers de journalisation  (multiplexage).  Ajouter  un  nouveau  groupe  permet  d’améliorer  la  disponibilité  des  fichiers  de  journalisation  pour  le  processus LGWR, en augmentant la durée d’un cycle complet de rotation. 

© ENI Editions - All rights reserved - Algeria Educ

●

●

●

●

Déplacer un membre permet d’améliorer la répartition des entrées/sorties par exemple.  Supprimer un groupe peut être utilisé dans une opération d’augmentation de la taille des groupes (ajout  d’un nouveau groupe plus gros puis suppression d’un ancien).  Supprimer un membre d’un groupe s’il est endommagé par exemple.  Forcer le basculement du groupe courant au suivant peut être utilisé dans l’opération d’augmentation de  taille. 

Il n’existe pas de commande pour modifier la taille des groupes ; la technique consiste à ajouter des groupes ayant  la taille souhaitée et à supprimer les anciens groupes. Supprimer un groupe ne sera pas possible si c’est le groupe  courant ; la commande permettant de forcer un basculement peut alors être utilisée pour éviter d’attendre. Sinon,  supprimer un groupe ou forcer le basculement du groupe courant au suivant sont des opérations rarement utilisées  en elles­mêmes. 

b. Ajouter un nouveau membre à un groupe (multiplexage)  Nous avons vu que le multiplexage des fichiers de journalisation pouvait être mis en œ uvre lors de la création de la  base  de  données  (voir  la  section  Création  de  la  base  de  données  à  la  main  du  chapitre  Création  d’une  nouvelle  base  de  données).  Il  suffit  de  spécifier  plusieurs  membres  pour  chaque  groupe  listé  dans  la  clause  LOGFILE  de  l’ordre SQL CREATE DATABASE.  Le multiplexage des fichiers de journalisation peut aussi être mis en œ uvre (ou renforcé) ultérieurement, à l’aide de  l’ordre SQL ALTER DATABASE.  Syntaxe simplifiée :  ALTER DATABASE ADD LOGFILE MEMBER ’nom_fichier’ [,...] TO GROUP numéro; Exemple :  ALTER DATABASE ADD LOGFILE MEMBER ’e:\oradata\HERMES\redo01c.log’ TO GROUP 1; La  taille  du  fichier  n’a  pas  besoin  d’être  spécifiée ; le  nouveau  fichier  a  forcément  la  même  taille  que  les  autres  membres du groupe. Notez aussi que le nouveau membre aura un statut INVALID dans V$LOGFILE ; c’est normal et  le statut changera lorsque le fichier sera utilisé.  Même  s’il  est  techniquement  possible  d’avoir  des  groupes  qui  n’ont  pas  le  même  nombre  de  membres,  c’est  normalement  une  situation  temporaire.  Bien  protéger  tous  les  groupes  sauf  un,  est  périlleux ; la  loi  de  Murphy  indique que si un incident doit se produire, il aura lieu sur le groupe mal protégé. 

c. Ajouter un nouveau groupe  Ajouter un nouveau groupe peut être réalisé à l’aide de l’ordre SQL ALTER DATABASE.  Syntaxe :  ALTER DATABASE ADD LOGFILE [GROUP numéro] spécification_fichier_redo [,...] ; - spécification_fichier_redo (’nom_fichier’ [,...]) [ SIZE valeur [K|M|G] ] [REUSE] Avec :  numéro  Numéro du groupe. Si l’option est absente, Oracle numérote les groupes 1, 2... (ce qui est bien).  nom_fichier  Chemin d’accès complet à un fichier membre du groupe, normalement dans un répertoire de données (oradata) pour  respecter le standard OFA. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 5-

SIZE  Taille de chaque membre du groupe en octets (pas de symbole), Ko (symbole K), Mo (symbole M) ou Go (symbole G).  La taille peut être omise uniquement si l’option REUSE est utilisée et que le fichier existe déjà.  REUSE  Si l’option est présente et que le fichier existe déjà, Oracle le réutilise et l’écrase.  Si  l’option est absente, dans la  même situation, un message d’erreur s’affiche et la création de la base de données est stoppée. Du point de vue de  la  sécurité,  il  est  préférable  de  ne  pas  utiliser  cette  option  afin  d’éviter  d’écraser  par  mégarde  un  fichier  de  journalisation utilisé par une autre base de données.  Exemple :  ALTER DATABASE ADD LOGFILE GROUP 4 (’e:\oradata\hermes\redo04a.log’, ’g:\oradata\hermes\redo04b.log’) SIZE 50M; Sauf  opération  d’augmentation de la taille des groupes, le nouveau groupe présente normalement la même taille  que les autres ; avoir des groupes de tailles différentes ne présente aucun intérêt. 

d. Déplacer un membre  Le mode opératoire pour déplacer un fichier de journalisation est le suivant :  ●

arrêter la base de données (proprement, pas ABORT) :  SQL> SHUTDOWN IMMEDIATE

●

déplacer le(s) fichier(s) de journalisation vers le nouvel emplacement :  SQL> HOST move e:\oradata\hermes\redo04a.log > f:\oradata\hermes\redo04a.log

●

monter la base de données :  SQL> STARTUP MOUNT

●

utiliser l’ordre SQL ALTER DATABASE RENAME FILE pour indiquer à Oracle le nouvel emplacement :  SQL> ALTER DATABASE 2 RENAME FILE ’e:\oradata\hermes\redo04a.log’ 3 TO ’f:\oradata\hermes\redo04a.log’;

●

ouvrir la base de données :  SQL> ALTER DATABASE OPEN;

La syntaxe de l’ordre SQL ALTER DATABASE RENAME FILE est la suivante :  ALTER DATABASE RENAME FILE ’ancien_nom_complet’ [,...] TO ’nouveau_nom_complet’ [,...]; Exemple :  ALTER DATABASE RENAME FILE ’e:\oradata\hermes\redo04a.log’ TO ’f:\oradata\hermes\redo04a.log’; Notez bien que l’ordre SQL ALTER DATABASE RENAME FILE ne renomme pas, ni ne déplace le fichier physique ; cette  opération  doit  être  effectuée  par  une  commande  du  système  d’exploitation.  L’ordre  SQL  ALTER DATABASE RENAME - 6-

© ENI Editions - All rights reserved - Algeria Educ

FILE  sert  juste  à  indiquer  à  Oracle  le  nouvel  emplacement  ou  le  nouveau  nom  d’un  fichier  (Oracle  met  à  jour  en  conséquence  le  fichier  de  contrôle).L’ancien  nom  complet  doit  correspondre  à  un  fichier  appartenant  à  la  base  de  données,  mais  il  peut  ne  plus  exister  physiquement ; par  contre,  Oracle  vérifie  que  le  fichier  existe  bien  avec  le  nouveau nom et/ou dans le nouvel emplacement (et que le fichier est valide). 

e. Supprimer un groupe  Supprimer un groupe peut être réalisé à l’aide de l’ordre SQL ALTER DATABASE.  Syntaxe :  ALTER DATABASE DROP LOGFILE GROUP numéro ; Exemple :  ALTER DATABASE DROP LOGFILE GROUP 4; La base de données doit avoir au moins 3 groupes de fichiers de journalisation pour pouvoir en supprimer un (il doit  rester au moins 2 groupes).  Seul un groupe au statut INACTIVE peut être supprimé. Le groupe courant (celui dans lequel le processus LGWR est  en  train  d’écrire)  ne  peut  pas  être  supprimé ; il  en  est  de  même  si  le  groupe  a  le  statut  ACTIVE  (groupe  encore  nécessaire en cas de restauration d’instance). En mode ARCHIVELOG, un groupe non encore archivé ne peut pas être  supprimé.  Les fichiers concernés ne sont pas physiquement supprimés par Oracle ; il faut les supprimer manuellement, à l’aide  d’une commande du système d’exploitation. 

f. Supprimer un membre d’un groupe  Supprimer un membre d’un groupe peut être réalisé à l’aide de l’ordre SQL ALTER DATABASE.  Syntaxe :  ALTER DATABASE DROP LOGFILE MEMBER ’nom_fichier’ [,...] Exemple :  ALTER DATABASE DROP LOGFILE MEMBER ’g:\oradata\hermes\redo01b.log’; Le groupe concerné doit avoir au moins 2 membres pour pouvoir en supprimer un (il doit toujours au moins exister  un membre  valide  par  groupe) ; si  le  groupe  a  deux  membres  dont  un  invalide,  vous  ne  pourrez  pas  supprimer  le  membre valide. Pour supprimer tous les membres d’un groupe, il faut en fait supprimer le groupe (point précédent).  Le tableau suivant indique si un membre peut être supprimé en fonction du statut du groupe : 

Status du groupe

Membre supprimable ?

CURRENT 

Non 

ACTIVE 

Non 

INACTIVE 

Oui 

En mode ARCHIVELOG, un membre d’un groupe non encore archivé ne peut pas être supprimé. Les fichiers concernés  ne sont pas physiquement supprimés par Oracle ; il faut les supprimer manuellement, à l’aide d’une commande du  système d’exploitation. 

g. Forcer le basculement du groupe courant au suivant  Forcer le basculement du groupe courant au suivant peut être réalisé à l’aide de l’ordre SQL ALTER SYSTEM. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 7-

Syntaxe :  ALTER SYSTEM SWITCH LOGFILE; Le basculement manuel provoque les mêmes événements qu’un basculement automatique :  ●

point de reprise ; 

●

archivage (si l’archivage est activé). 

5. Contrôler la fréquence des points de reprise  Par défaut, les points de reprise se déclenchent lors d’un basculement de fichier de journalisation.  Lorsque les fichiers de journalisation sont gros et que les basculements sont peu fréquents, cela peut conduire à des  redémarrages un peu longs en cas d’arrêt anormal de l’instance (beaucoup de modifications à apporter aux fichiers  de données pour les remettre en état).Dans ce genre de situation, il peut être intéressant de contrôler la fréquence  des  points  de  reprise  et  de  faire  en  sorte  d’avoir  des  points  de  reprise  intermédiaires,  entre  les  basculements  de  fichiers de journalisation.  La méthode recommandée consiste à utiliser le paramètre FAST_START_MTTR_TARGET qui indique le nombre maximum  de  secondes  souhaité  pour  le  redémarrage  de  l’instance,  après  un  arrêt  anormal.  Une  fois  que  ce  paramètre  est  positionné, l’instance ajuste automatiquement la fréquence des points de reprise afin de ne pas avoir trop d’activité à  rejouer dans les fichiers de données, en cas d’arrêt anormal de l’instance.  Des  points  de  reprise  trop  fréquents  peuvent  dégrader  les  performances  de  l’activité  courante ; il  faut  trouver le juste équilibre …  La vue  V$INSTANCE_RECOVERY peut être utilisée pour superviser le temps estimé de restauration de l’instance. Cette  vue contient notamment les colonnes suivantes :  TARGET_MTTR  Objectif  réel  de  durée  de  récupération  maximum,  recalculé  par  Oracle,  en  fonction  du  contexte ; tient  compte  de  la  valeur du paramètre FAST_START_MTTR_TARGET mais aussi, d’autres facteurs.  ESTIMATED_MTTR  Durée de récupération estimée actuellement compte tenu de l’activité de l’instance.  OPTIMAL_LOGFILE_SIZE  Taille  optimale  des  fichiers  de  journalisation  (en  Mo)  permettant  d’atteindre l’objectif  (valeur  actuelle  du  paramètre  FAST_START_ MTTR_TARGET)  uniquement  avec  les  points  de  reprises  liés  aux  basculements  des  fichiers  de  journalisation.  Si  le  paramètre  FAST_START_MTTR_TARGET  est  réglé  à  une  valeur  trop  basse,  la  durée  effective  de  recouvrement  est  déterminée  au  mieux  de  ce  que  le  système  est  capable  de  faire,  compte  tenu  du  contexte.  Si  le  paramètre  FAST_START_MTTR_TARGET est réglé à une valeur élevée, telle que, même dans le pire des cas, le recouvrement serait  plus  court,  la  durée  effective  de  recouvrement  est  estimée  par  rapport  au  scénario  le  pire : tous  les  blocs  sont  modifiés  dans  le  Buffer  Cache,  pour  des  transactions  validées,  et  aucun  n’a  encore  été  écrit  sur  disque,  dans  les  fichiers de données.  Exemple :  SQL> SELECT value FROM v$parameter 2 WHERE name = ’fast_start_mttr_target’; VALUE -------------------60 SQL> SELECT target_mttr,estimated_mttr,optimal_logfile_size 2 FROM v$instance_recovery; TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE ----------- -------------- --------------------

- 8-

© ENI Editions - All rights reserved - Algeria Educ

30

18

99

Si  le  paramètre  FAST_START_MTTR_TARGET n’est  pas  défini,  la  colonne  TARGET_MTTR est  égale  à  0  et  la  colonne  OPTIMAL_LOGFILE_SIZE est vide ; par contre, la colonne ESTIMATED_MTTR est renseignée. 

6. Utiliser le Database Control  Dans  le  Database  Control,  cliquez  sur  le  lien Serveur sur la page d’accueil  puis,  sur  le  lien Groupes  de  fichiers  de  journalisation (cadre Stockage) pour accéder à la page de gestion des fichiers de journalisation : 

  À partir de cette page, vous pouvez effectuer diverses actions sur les groupes de fichiers de journalisation : 

 

●

créer un nouveau groupe (bouton Créer ou menu Créer comme) ; 

●

supprimer un groupe (bouton Supprimer) ; 

●

forcer le basculement du groupe courant au suivant (menu Changer de fichier journal) ; 

●

forcer un point de reprise (menu Forcer l’application d’un point de reprise). 

En cliquant sur le lien du numéro de groupe ou en cliquant sur les boutons Modifier ou Visualiser, vous arrivez sur la  page de gestion des membres du groupe : 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 9-

  Cette page permet d’ajouter,  supprimer,  ou  modifier  un  membre.  Notez  que  le  Database  Control  n’effectue aucune  action  sur  les  fichiers  physiques  (suppression,  déplacement,  renommage) ; ces  opérations  doivent  être  effectuées  manuellement au niveau du système d’exploitation. 

- 10 -

© ENI Editions - All rights reserved - Algeria Educ

Vue d’ensemble et directives  1. Vue d’ensemble  Un  tablespace  est  une  unité  logique  de  stockage  composée  d’un  ou  plusieurs  fichiers  physiques  (fichiers  de  données).  Dans  le  Database  Control,  le  tablespace  est  appelé  "espace  disque  logique" ; dans  cet  ouvrage,  nous  utiliserons le terme "tablespace".  La  majorité  des  opérations  d’administration  relatives  au  stockage  s’effectue  au  niveau  du  tablespace,  et  non  au  niveau des fichiers de données.  À l’intérieur d’un tablespace, le stockage est organisé en segments, composés d’une ou plusieurs extensions (extent).  Ces extensions peuvent être gérées "par le dictionnaire" ou "localement". Dans le premier cas (tablespace SELECT property_value FROM database_properties 2 WHERE property_name = ’DEFAULT_TBS_TYPE’; PROPERTY_VALUE--------------------------------------------------SMALLFILE

3. Tablespace permanent par défaut  Lorsqu’un  utilisateur  crée  un  segment  sans  préciser  de  tablespace  (voir  la  section  Organisation  du  stockage  à  l’intérieur d’un tablespace), Oracle stocke le segment dans le tablespace par défaut de l’utilisateur.  Ce tablespace par défaut est défini grâce à la clause DEFAULT TABLESPACE des ordres SQL CREATE USER et ALTER USER  (voir le chapitre Gestion des utilisateurs et de leurs droits). Si cette clause est omise, c’est le tablespace SYSTEM qui  est affecté comme tablespace par défaut à l’utilisateur. Dans la pratique, ce comportement par défaut ne pose pas de  problème car les utilisateurs non DBA n’ont  pas  (normalement ­ c’est le cas par défaut) de quotas sur le tablespace  SYSTEM, et ne peuvent y créer de segments (voir le chapitre Gestion des utilisateurs et de leurs droits).  Depuis  la  version  10,  dans  le  but  de  simplifier  la  gestion  des  utilisateurs,  il  est  possible  de définir  un  tablespace  permanent par défaut. Ce tablespace est affecté par défaut aux utilisateurs lors de leur création, lorsque la clause  DEFAULT TABLESPACE  de  l’ordre  SQL  CREATE USER  est  omise.  Cette  technique  n’empêche  pas  d’utiliser  d’autres  tablespaces permanents affectés spécifiquement à des utilisateurs pour des besoins particuliers.  Le  tablespace  permanent  par  défaut  peut  être  défini  lors  de  la  création  de  la  base  de  données,  grâce  à  la  clause  DEFAULT TABLESPACE de l’ordre SQL CREATE DATABASE.  Syntaxe  [ DEFAULT TABLESPACE nom [ DATAFILE spécification_fichier [,...] ] [ clause_extent_management ] ] Exemple :  DEFAULT TABLESPACE deftbs DATAFILE ’e:\oradata\hermes\deftbs01.dbf’ SIZE 10M AUTOEXTEND ON NEXT 10M MAXSIZE 500M

- 4-

© ENI Editions - All rights reserved - Algeria Educ

EXTENT MANAGEMENT LOCAL AUTOALLOCATE Notez que le tablespace ainsi défini est obligatoirement de type SMALLFILE.  Pour créer et définir un tablespace permanent par défaut après la création de la base de données, vous devez :  créer un tablespace permanent, grâce à l’ordre SQL CREATE TABLESPACE présenté précédemment ; 

●

le définir comme tablespace permanent par défaut, grâce à la clause DEFAULT TABLESPACE de l’ordre SQL ALTER DATABASE. 

●

Syntaxe  ALTER DATABASE DEFAULT TABLESPACE nom ; nom doit désigner un tablespace permanent qui existe déjà.  Lorsque cet ordre SQL est exécuté, tous les utilisateurs à qui l’ancien tablespace permanent par défaut était affecté  se voient automatiquement attribuer le nouveau.  Pour retrouver le nom du tablespace permanent par défaut, vous pouvez interroger la vue DATABASE_PROPERTIESpour  la propriété DEFAULT_PERMANENT_TABLESPACE :  SQL> SELECT property_value FROM database_properties 2 WHERE property_name = ’DEFAULT_PERMANENT_TABLESPACE’ ; PROPERTY_VALUE -----------------------------DEFTBS

4. Modification d’un tablespace permanent  a. Vue d’ensemble  Après création, il est possible de modifier un tablespace, notamment pour :  ●

le renommer ; 

●

lui allouer de l’espace supplémentaire ; 

●

déplacer le(s) fichier(s) de données ; 

●

le passer OFFLINE / ONLINE ; 

●

le passer READ ONLY / READ WRITE ; 

●

modifier ces autres caractéristiques (LOGGING / NOLOGGING, FORCE LOGGING, FLASHBACK ON / OFF, etc.). 

Ces opérations s’effectuent selon les cas avec l’ordre SQL ALTER TABLESPACE ou ALTER DATABASE.  Il est possible d’allouer de l’espace supplémentaire à une base de données :  ●

en ajoutant un nouveau tablespace (avec un ou plusieurs fichiers de données) ; 

●

en ajoutant un fichier de données à un tablespace existant ; 

●

en augmentant la taille d’un fichier de données d’un tablespace. 

La  syntaxe  complète  de  l’ordre  SQL  ALTER TABLESPACE  est  "excessivement  longue" ; nous  n’allons  donc  pas  la  présenter dans son intégralité mais indiquer la syntaxe à utiliser pour différentes opérations. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 5-

b. Renommer un tablespace  Renommer un tablespace s’effectue avec l’ordre SQL ALTER TABLESPACE. Cette possibilité est apparue en version 10.  Syntaxe  ALTER TABLESPACE ancien_nom RENAME TO nouveau_nom; Exemple :  ALTER TABLESPACE deftbs RENAME TO tbsdef; Les tablespaces SYSTEM et SYSAUX, ainsi que les tablespaces OFFLINE, ne peuvent pas être renommés.  Notez  que  dans  le  cas  du  tablespace OFFLINE,  le  message  d’erreur  indique  en  fait,  que  le  fichier  de  données  est  "hors  ligne"  (OFFLINE),  ce  qui  empêche  Oracle  de  modifier  l’en­tête  du  fichier  de  données  pour  y  enregistrer  le  nouveau nom du tablespace. Un problème similaire pourrait se poser avec un tablespace en lecture seule, mais ce  n’est  pas  le  cas ; Oracle  ne  cherche  pas  à  modifier  l’en­tête du fichier de données et enregistre juste le nouveau  nom dans le fichier de contrôle (l’en­tête sera modifié lorsque le tablespace repassera en lecture/écriture). 

c. Ajouter un fichier de données à un tablespace  Ajouter un fichier de données à un tablespace s’effectue avec l’ordre SQL ALTER TABLESPACE.  Syntaxe  ALTER TABLESPACE nomADD DATAFILE spécification_fichier [,...]; Exemple :  ALTER TABLESPACE data ADD DATAFILE ’f:\oradata\hermes\data02.dbf’ SIZE 100M AUTOEXTEND ON NEXT 100M MAXSIZE 500M; Ajouter  un  fichier  de  données  à  un  tablespace  est  un  premier  moyen  pour  lui  allouer  de  l’espace  supplémentaire ; généralement, cette méthode est utilisée pour allouer un nouveau fichier de données sur un autre  disque  que  le  disque  actuellement  utilisé  par  le  tablespace  (sinon,  autant  modifier  la  taille  du  fichier  de  données  existant ­ voir ci­après). Cette opération est interdite pour un tablespace BIGFILE.  La spécification du fichier de données (spécification_fichier) est la même que lors de la création du tablespace  (section Création d’un tablespace permanent). 

d. Modifier la taille d’un fichier de données  Modifier la taille d’un fichier de données s’effectue avec l’ordre SQL ALTER DATABASE, ou l’ordre SQL ALTER TABLESPACE  dans le cas d’un tablespace BIGFILE.  Syntaxe  ALTER DATABASE DATAFILE ’nom_complet’ | numéro_fichier [,...] RESIZE valeur [K|M|G|T]; ALTER TABLESPACE nom_tablespace_bigfile RESIZE valeur [K|M|G|T]; Exemple :  ●

Tout type de tablespace  ALTER DATABASE DATAFILE ’f:\oradata\hermes\data02.dbf’ RESIZE 200M;

●

Tablespace BIGFILE uniquement  ALTER TABLESPACE je_suis_gros RESIZE 1T;

La clause RESIZE donne la nouvelle taille souhaitée (à la hausse ou à la baisse) pour le fichier de données. 

- 6-

© ENI Editions - All rights reserved - Algeria Educ

Modifier la taille d’un fichier de données permet :  ●

dans le cas d’une diminution, de récupérer de l’espace inutilisé alloué au tablespace ; 

●

dans le cas d’une augmentation, d’allouer de l’espace supplémentaire à un tablespace. 

Dans le cas d’une diminution, la taille du fichier de données ne peut pas descendre en dessous de la position de la  dernière  extension  occupée  par  un  segment  dans  le  tablespace  (visible  dans  la  vue  DBA_EXTENTS).  En  cas  de  tentative de cette sorte, un message d’erreur est affiché et la taille du fichier est inchangée :  ORA-03297: le fichier contient des données utilisées au-delà de la valeur RESIZE requise

e. Modifier l’extension automatique d’un fichier de données  Modifier l’extension automatique d’un fichier de données s’effectue avec l’ordre SQL ALTER DATABASE, ou l’ordre SQL  ALTER TABLESPACE dans le cas d’un tablespace BIGFILE.  Syntaxe  ALTER DATABASE DATAFILE ’nom_complet’ | numéro_fichier[,...] clause_auto_extension; ALTER TABLESPACE nom_tablespace_bigfile clause_auto_extension; La spécification de la clause d’extension automatique (clause_auto_extension) est la même que lors de la création  du tablespace (section Création d’un tablespace permanent).  Exemple :  ●

Désactivation de la clause AUTOEXTEND  ALTER DATABASE DATAFILE ’e:\oradata\hermes\data01.dbf’ AUTOEXTEND OFF;

●

Activation (ou modification) de la clause AUTOEXTEND  ALTER DATABASE DATAFILE ’e:\oradata\hermes\data01.dbf’ AUTOEXTEND ON NEXT 200M MAXSIZE 800M;

●

Exemple avec un tablespace BIGFILE  ALTER TABLESPACE je_suis_gros AUTOEXTEND ON NEXT 1G MAXSIZE 100G;

Activer l’extension automatique d’un fichier de données permet à ce dernier de grossir automatiquement en cas de  besoin  d’espace  supplémentaire  pour  un  segment  (nouveau  ou  déjà  présent)  dans  le  tablespace ; c’est  un  bon  moyen  pour  éviter  les  problèmes  et  ne  pas  avoir  à  augmenter  soi­même  la  taille  d’un  fichier  de  données  (voir  précédemment). Désactiver l’extension automatique d’un fichier de données peut être envisagé (et même conseillé)  s’il n’y a plus d’espace disponible sur un disque. 

f. Passer un tablespace OFFLINE / ONLINE  Passer un tablespace OFFLINE / ONLINE s’effectue avec l’ordre SQL ALTER TABLESPACE.  Syntaxe  ALTER TABLESPACE nom ONLINE | OFFLINE; Exemple :  ●

openmirrors.com

Désactivation 

© ENI Editions - All rights reserved - Algeria Educ

- 7-

ALTER TABLESPACE data OFFLINE; ●

Activation  ALTER TABLESPACE data ONLINE;

Désactiver  un  tablespace  peut  être  nécessaire  pour  effectuer  certaines  opérations  d’administration  sur  le  tablespace  (par  exemple,  déplacer  un  de  ces  fichiers  de  données)  ou  tout  simplement  pour  rendre  certaines  données temporairement inaccessibles.  Le  tablespace  SYSTEM  ne  peut  pas  être  mis  OFFLINE ; un  message  d’erreur  s’affiche  en  cas  de  tentative.  Le  tablespace SYSAUX peut être passé OFFLINE mais certaines fonctionnalités risquent de ne plus fonctionner.  Le  statut  d’un  tablespace  (OFFLINE / ONLINE) est conservé lors de l’arrêt ; au  prochain  démarrage  de  la  base  de  données, le tablespace sera dans l’état où il était lors de l’arrêt.  Il existe des options sur le OFFLINE qui doivent être utilisées si le tablespace à désactiver est endommagé (voir le  chapitre Sauvegarde et récupération). 

g. Renommer ou déplacer un fichier de données  Renommer ou déplacer un fichier de données s’effectue avec l’ordre SQL ALTER TABLE- SPACE ou ALTER DATABASE.  Dans  le  cas  de  l’utilisation  de  l’ordre  SQL  ALTER TABLESPACE,  la  base  de  données  doit  être  ouverte  mais  le  tablespace  concerné  doit  être  OFFLINE.  Dans  le  cas  de  l’utilisation  de  l’ordre  SQL  ALTER DATABASE,  le  tablespace  concerné doit être OFFLINE ou la base de données en état MOUNT. L’utilisation de l’ordre SQL ALTER DATABASE, base  montée, est nécessaire pour déplacer un fichier de données du tablespace SYSTEM puisque ce dernier ne peut pas  être mis OFFLINE.  Ces deux ordres SQL ne manipulent pas physiquement le fichier. Ils se contentent de mettre à jour le fichier  de contrôle. Le fichier de données doit être renommé/copié /déplacé à l’aide d’une commande du système  d’exploitation, avant d’exécuter l’ordre SQL.  Syntaxe  - ALTER TABLESPACE ALTER TABLESPACE nom RENAME DATAFILE ’ancien_nom_complet’ TO ’nouveau_nom_complet’; - ALTER DATABASE ALTER DATABASE RENAME FILE ’ancien_nom_complet’ TO ’nouveau_nom_complet’; "Renommer" un fichier de données est surtout utilisé pour déplacer le fichier. Cette possibilité est intéressante si le  tablespace  est  plein  et  qu’il  ne  reste  plus  d’espace  disponible  sur  le  disque  sur  lequel  il  est  actuellement  situé ; dans ce cas, il est envisageable de déplacer le fichier de données du tablespace vers un disque où il reste de  l’espace disponible puis de faire grossir le fichier (ou l’autoriser à grossir).  Le mode opératoire, lors de l’utilisation de l’ordre SQL ALTER TABLESPACE, est le suivant :  ●

Se connecter en tant que DBA :  SQL> CONNECT system/xxxx

●

Passer le tablespace OFFLINE :  SQL> ALTER TABLESPACE data OFFLINE;

●

Par une commande du système d’exploitation, renommer, copier ou déplacer le fichier :  SQL> HOST move e:\oradata\hermes\data01.dbf > f:\oradata\hermes\data01.dbf

●

- 8-

Exécuter l’ordre SQL ALTER TABLESPACE : 

© ENI Editions - All rights reserved - Algeria Educ

SQL> ALTER TABLESPACE data 2 RENAME DATAFILE ’e:\oradata\hermes\data01.dbf’ 3 TO ’f:\oradata\HErmes\data01.dbf’; ●

Repasser le tablespace ONLINE :  SQL> ALTER TABLESPACE data ONLINE;

Le mode opératoire, lors de l’utilisation de l’ordre SQL ALTER DATABASE, est le suivant :  ●

Se connecter AS SYSDBA :  SQL> CONNECT / AS SYSDBA

●

Passer la base de données en état MOUNT :  SQL> SHUTDOWN IMMEDIATE SQL> STARTUP MOUNT

●

Par une commande du système d’exploitation, renommer, copier ou déplacer le fichier :  SQL> HOST move e:\oradata\hermes\system01.dbf > f:\oradata\hermes\system01.dbf

●

Exécuter l’ordre SQL ALTER DATABASE :  SQL> ALTER DATABASE 2 RENAME FILE ’e:\oradata\hermes\system01.dbf’ 3 TO ’f:\oradata\hermes\system01.dbf’;

●

Ouvrir la base de données :  SQL> ALTER DATABASE OPEN;

h. Supprimer un fichier de données  Supprimer un fichier de données d’un tablespace s’effectue avec l’ordre SQL ALTER TABLESPACE.  Syntaxe  ALTER TABLESPACE nom DROP DATAFILE ’nom_complet’ | numéro_fichier; Exemple  ALTER TABLESPACE data DROP DATAFILE ’E:\ORADATA\HERMES\DATA02.DBF’; Le fichier de données est physiquement supprimé par Oracle.Les restrictions suivantes s’appliquent :  ●

Le fichier de données doit être vide (ne doit contenir aucune extension) ; 

●

Le fichier de données ne peut pas être le premier fichier créé pour le tablespace ; 

●

Le fichier de données ne doit pas appartenir à un tablespace en lecture seule ; 

●

Le fichier de données doit être en ligne (ONLINE) ; 

●

Le fichier ne doit pas appartenir au tablespace SYSTEM. 

i. Autres opérations 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 9-

L’ordre SQL ALTER TABLESPACE peut être utilisé pour modifier les caractéristiques du tablespace :  - READ ONLY / READ WRITE ALTER TABLESPACE nom { READ ONLY | READ WRITE } ; - LOGGING / NOLOGGING ALTER TABLESPACE nom LOGGING | NOLOGGING ; - FORCE LOGGING ALTER TABLESPACE nom [NO] FORCE LOGGING ; - FLASHBACK ON / OFF ALTER TABLESPACE nom FLASHBACK ON | OFF ;

5. Suppression d’un tablespace permanent  L’ordre SQL DROP TABLESPACE permet de supprimer un tablespace permanent.  Syntaxe  DROP TABLESPACE nom [ INCLUDING CONTENTS [ AND DATAFILES ] [ CASCADE CONSTRAINTS ] ]; Exemple :  DROP TABLESPACE data INCLUDING CONTENTS AND DATAFILES ; C’est  un  ordre  DDL  (Data  Definition  Language) : il  n’y  a  pas  de  ROLLBACK.  La  seule  solution  est  de  repartir  d’une  sauvegarde ; le fichier physique, même s’il n’est pas supprimé, n’est pas récupérable.  Le tablespace  SYSTEM et le tablespace permanent par défaut ne peuvent pas être supprimés.Il est recommandé de  passer le tablespace OFFLINE avant de le supprimer.  Les options de l’ordre SQL DROP TABLESPACE sont :  INCLUDING CONTENTS Cette clause est nécessaire si le tablespace n’est pas vide, pour forcer la suppression préalable des segments qui y  sont stockés. Si le tablespace n’est pas vide et que l’option n’est pas utilisée, l’erreur ORA-01549 est retournée :  ORA-01549: le tablespace n’est pas vide ; utiliser l’option INCLUDING CONTENTS AND DATAFILES Cette option de la clause précédente permet en plus, de supprimer les fichiers physiques du tablespace. Un message  est écrit dans le fichier d’alerte de l’instance pour chaque fichier physique supprimé par Oracle.    Sinon, ils ne sont pas supprimés.

CASCADE CONSTRAINTS Cette  clause  permet  en  plus,  de  supprimer  les  contraintes  d’intégrité  référentielle  définies  sur  des  tables  hors  du  tablespace et qui référencent des tables à l’intérieur du tablespace. Si de telles contraintes existent et que l’option  n’est pas utilisée, l’erreur ORA-02449 est retournée :  ORA-02449: clés uniques/primaires de la table référencées par des clés étrangères

- 10 -

© ENI Editions - All rights reserved - Algeria Educ

Organisation du stockage à l’intérieur d’un tablespace  1. Principes  L’organisation du stockage à l’intérieur d’un tablespace peut être résumée par le schéma ci­après. 

  À l’intérieur d’un tablespace, le stockage est organisé en segments contenant une ou plusieurs extensions (extents),  une extension étant un ensemble de blocs Oracle contigus.  Lorsqu’un segment est créé dans un tablespace, Oracle lui alloue une (ou plusieurs) extension(s) dans un des fichiers  de  données  du  tablespace.  Lorsque  l’espace  initialement  alloué  est  plein  (suite  à  l’insertion  de  données  par  exemple), Oracle alloue une nouvelle extension au segment, et ainsi de suite. Toutes les extensions allouées à un  segment  sont  dans  le  tablespace  de  création  du  segment,  mais  pas  forcément  côte  à  côte,  ni  forcément  dans  le  même  fichier  de  données  (si  le  tablespace  est  composé  de  plusieurs  fichiers  de  données).  Lorsqu’un  segment  est  supprimé,  les  extensions  qu’il  occupe  sont  libérées  et  rendues  disponibles  pour  d’autres  segments.  Des  créations/suppressions fréquentes de segments dans un tablespace peuvent donc conduire à une fragmentation de  l’espace disponible dans ce tablespace.  Pour mémoire, il existe quatre types principaux de segments :  ●

les segments de table : espace occupé par les tables ; 

●

les segments d’index : espace occupé par les index ; 

●

●

les segments d’annulation : espace temporaire utilisé pour stocker les informations permettant d’annuler une  transaction ;  les segments temporaires : espace temporaire utilisé notamment lors d’un tri. 

La première extension d’un segment contient au minium deux blocs, le premier étant réservé à l’en­tête du segment  (ne  contient  pas  de  données  utiles  mais  la  carte  des  extensions  allouées  au  segment).  Il  en  est  de  même  pour  chaque fichier de données du tablespace ; le premier bloc est un bloc d’en­tête (nous verrons bientôt que l’en­tête du  fichier peut contenir davantage de blocs).  Nous verrons au chapitre Gestion des tables et des index qu’il est possible, sous certaines conditions, de libérer des  extensions sans supprimer le segment.  Un tablespace peut être "géré par le dictionnaire" ou "géré localement".  Dans  un  tablespace  "géré  par  le  dictionnaire",  les  informations  relatives  à  la  gestion  de  l’espace  (extensions  libres/allouées) sont enregistrées dans le dictionnaire de données. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

Dans un tablespace "géré localement", les informations relatives à la gestion de l’espace (extensions libres/allouées)  sont  enregistrées  dans  une  bitmap,  dans  l’en­tête  de  chaque  fichier  de  données  du  tablespace.  Chaque  bit  de  la  bitmap correspond à une extension et vaut 0 ou 1 selon que l’extension est libre ou allouée.  Les  tablespaces  gérés  localement  sont  apparus  dans  Oracle8i.  Depuis  Oracle9i,  les  tablespaces  sont,  par  défaut,  gérés localement (sauf le tablespace SYSTEM qui est, par défaut, géré par le dictionnaire ­ voir plus loin).  Oracle recommande fortement d’utiliser des tablespaces gérés localement. C’est le seul type de tablespace  qui sera étudié dans cet ouvrage. Il est fort probable que les tablespaces gérés par le dictionnaire ne soient  plus supportés par Oracle dans une prochaine version.  Oracle propose deux variantes pour les tablespaces gérés localement :  ●

●

Une gestion dite "automatique" : la taille des extensions est déterminée automatiquement par Oracle.  Une  gestion  dite  "uniforme" : la  taille  des  extensions  est  uniforme,  égale  à  une  valeur  définie  lors  de  la  création du tablespace. 

Par  défaut,  un  tablespace  permanent  géré  localement  est  en  gestion  automatique  des  extensions ; la  gestion  uniforme doit être spécifiée.  Un  tablespace  temporaire  géré  localement  est  obligatoirement  en  gestion  uniforme  des  extensions  (détaillé  ultérieurement). 

2. Spécifier le stockage d’un segment  Les clauses TABLESPACE et STORAGE peuvent être utilisées dans les ordres de création des segments pour spécifier le  stockage du segment.  Syntaxe de la clause TABLESPACE  TABLESPACE nom_tablespace Syntaxe de la clause STORAGE  STORAGE ( [ [ [ [ [

INITIAL valeur [K|M] ] NEXT valeur [K|M] ] MINEXTENTS valeur ] MAXEXTENTS { valeur | UNLIMITED } ] PCTINCREASE valeur ] )

Exemple pour une table :  CREATE TABLE categorie ( identifiant NUMBER(6), intitule VARCHAR2(20) ) TABLESPACE data STORAGE (INITIAL 500K) ; Les options de la clause STORAGE sont :  INITIAL  Taille de la première extension allouée.  NEXT  Taille de la deuxième extension allouée.  MINEXTENTS  Nombre initial d’extension(s) allouée(s). 

- 2-

© ENI Editions - All rights reserved - Algeria Educ

MAXEXTENTS  Nombre maximal d’extensions allouables.  PCTINCREASE  Pourcentage  d’augmentation  (0  à  100)  de  la  taille  des  extensions,  à  partir  de  la  troisième,  par  rapport  à  la  précédente.  La manière dont la clause STORAGE est utilisée par Oracle dépend du mode de gestion des extensions à l’intérieur du  tablespace.  La clause STORAGE a vraiment beaucoup d’importance pour le stockage des segments dans un tablespace géré par le  dictionnaire, puisqu’elle permet de spécifier précisément le stockage du segment. Si une clause  MINIMUM EXTENT est  définie au niveau du tablespace, la taille des extensions est éventuellement ajustée pour devenir un multiple de cette  taille minimum. En cas d’absence de clause STORAGE, le segment hérite de la clause DEFAULT STORAGE éventuellement  définie  au  niveau  du  tablespace.  Si  cette  dernière  est  elle­même  absente,  Oracle  utilise  des  valeurs  par  défaut  (INITIAL = 5 blocs Oracle, NEXT = 5 blocs Oracle, PCTINCREASE = 50). Dans le cas d’un tablespace géré localement, la  clause STORAGE a beaucoup moins d’importance car, de par sa définition, le tablespace impose des contraintes sur la  taille des extensions (taille choisie par Oracle ou taille uniforme). Dans la pratique, seule l’option INITIAL a réellement  de l’importance puisqu’elle indique à Oracle la taille initiale souhaitée pour le segment. 

3. Spécifier le mode de gestion d’un tablespace  La  clause  EXTENT MANAGEMENT  de  l’ordre  SQL  CREATE TABLESPACE  permet  de  spécifier  le  mode  de  gestion  d’un  tablespace.  Syntaxe :  EXTENT MANAGEMENT DICTIONARY | LOCAL [ AUTOALLOCATE | UNIFORM [ SIZE valeur [K|M] ] ] Exemple :  ●

Tablespace géré localement avec des extensions uniformes  CREATE TABLESPACE tbs_local_uniform DATAFILE ’e:\oradata\hermes\tbs_local_uniform.dbf’ SIZE 10M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128K;

●

Tablespace géré localement avec des extensions gérées par Oracle  CREATE TABLESPACE tbs_local_auto DATAFILE ’d:\oradata\hermes\tbs_local_auto.dbf’ SIZE 10M EXTENT MANAGEMENT LOCAL AUTOALLOCATE;

Les options de la clause EXTENT MANAGEMENT sont :  DICTIONARY  Indique que le tablespace est géré par le dictionnaire. Des clauses DEFAULT STORAGE et MINIMUM EXTENT peuvent être  indiquées en complément.  LOCAL  Indique que le tablespace est géré localement. Les clauses DEFAULT STORAGE et MINIMUM EXTENT sont interdites.  AUTOALLOCATE  Indique que les extensions sont automatiquement gérées par Oracle.  UNIFORM 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 3-

Indique que les extensions ont une taille uniforme définie par la clause SIZE. Si la clause SIZE n’est pas spécifiée, la  taille par défaut est 1 Mo.  SIZE  Spécifie  la  taille  des  extensions  pour  les  tablespaces  LOCAL UNIFORM.  La  taille  peut  être  donnée  en  octets  (pas  de  symbole), en Ko (symbole K) ou en Mo (symbole M).  Par  défaut  (clause  EXTENT MANAGEMENT  absente),  un  tablespace  permanent  est  géré  localement  avec  une  gestion  automatique des extensions (AUTOALLOCATE).  Comme  nous  le  verrons  ultérieurement,  un  tablespace  temporaire  géré  localement  est  obligatoirement  en  gestion  uniforme des extensions (UNIFORM).  Lorsqu’un  tablespace  permanent  est  géré  localement,  la  gestion  automatique  de  l’espace  libre  à  l’intérieur  des  segments  est,  par  défaut,  activée  (clause  SEGMENT SPACE MANAGEMENT AUTO  implicite  dans  l’ordre  SQL  CREATE TABLESPACE) ; nous étudierons ce mode de gestion plus en détail dans le chapitre Gestion des tables et des index.  Compte  tenu  de  ce  mode  de  gestion,  les  extensions  doivent  contenir  au  minimum  cinq  blocs ; dans  le  cas  d’un  tablespace géré localement avec une gestion uniforme des extensions, il faut en tenir compte dans la spécification de  la clause SIZE, sous peine d’obtenir l’erreur suivante :  ORA-03249: UNIFORM SIZE pour le tablespace géré par un espace de segment AUTO doit avoir au moins 5 blocs L’en­tête  de  chaque  fichier  de  données  d’un  tablespace  géré  localement  utilise  au  minimum  trois  blocs  (contre  un  pour un tablespace géré par le dictionnaire). La taille du fichier de données doit donc être au minimum égale à trois  blocs plus la taille d’une extension (valeur explicite ou par défaut de la clause SIZE pour un tablespace UNIFORM, 64 Ko  pour un tablespace AUTOALLOCATE). Si la taille initiale du fichier de données est supérieure à 64 Ko plus la taille d’une  extension, un en­tête de 64 Ko est en fait alloué au fichier, ce qui permet de stocker une bitmap plus grande et donc  de gérer d’entrée de jeu, un plus grand nombre d’extensions.  Le  package  DBMS_SPACE_ADMIN  <propose  différentes  procédures  qui  permettent  de  diagnostiquer  et  réparer  les  tablespaces gérés localement (en cas d’endommagement de la bitmap par exemple), ou d’effectuer une migration de  tablespace  géré  par  le  dictionnaire  en  tablespace  géré  localement  (et  réciproquement).  Dans  ce  dernier  cas,  le  résultat  obtenu  est  meilleur  en  créant  un  nouveau  tablespace  géré  localement  et  en  transférant  les  segments  de  l’ancien tablespace dans le nouveau ; par contre, l’opération est plus longue. 

4. Gestion des extensions à l’intérieur d’un tablespace géré localement  Dans  le  cas  d’une  gestion  automatique  des  extensions,  Oracle  utilise  un  petit  nombre  de  tailles  d’extension  différentes  (64  Ko,  1  Mo,  8  Mo,  64  Mo)  et  tente  d’allouer  côté  à  côte  des  extensions  de  même  taille,  en  nombre  suffisant pour occuper de l’espace potentiellement utilisable pour une extension de taille supérieure (16 extensions  de  64  Ko  =   une  extension  potentielle  de  1  Mo).  Cette  technique  permet  de  limiter  les  risques  de  fragmentation  de  l’espace  disponible : si  un  segment  contenant  de  nombreuses  extensions  est  supprimé,  l’espace  libéré  peut  être  réutilisé de différentes manières.La taille d’extension initialement choisie pour un segment dépend de la taille initiale  du segment :  ●

64 Ko pour un segment de moins de 1 Mo ; 

●

1 Mo pour un segment de moins de 64 Mo ; 

●

8 Mo pour un segment de moins de 1 024 Mo, etc. 

L’algorithme utilisé par Oracle pour calculer la taille des extensions dans un tablespace géré localement, avec  une  gestion  automatique  des  extensions,  n’est  pas  documenté.  Les  valeurs  indiquées  ici  sont  des  valeurs  constatées pour la création d’une table dans un tablespace vide.  Dans le cas d’une gestion uniforme des extensions toutes les extensions ont la même taille définie par l’option SIZE  de la clause EXTENT MANAGEMENT (1 Mo par défaut).  La taille initiale du segment est calculée à l’aide des valeurs  INITIAL, NEXT, MINEXTENTS  et PCTINCREASE de la clause  STORAGE :  ●

- 4-

si MINEXTENTS = 1 alors INITIAL (c’est le cas le plus fréquent) ; 

© ENI Editions - All rights reserved - Algeria Educ

●

si MINEXTENTS = 2 alors INITIAL+NEXT ; 

●

si MINEXTENTS = 3 alors INITIAL+NEXT+NEXT*(1+PCTINCREASE/100), etc. 

La valeur calculée devient la nouvelle valeur INITIAL, telle qu’enregistrée dans le dictionnaire de données.  Oracle  alloue  alors  une  ou  plusieurs  extensions  (sans  tenir  compte  du  MINEXTENTS  initial),  de  taille  uniforme  (cas  UNIFORM) ou de taille déterminée en interne (cas AUTOALLOCATE), pour obtenir une taille initiale égale ou supérieure à  la taille calculée précédemment.  À  titre  d’exemple,  supposons  que  la  table  suivante  soit  créée  dans  un  tablespace  géré  localement  avec  des  extensions uniformes de 128 Ko :  CREATE TABLE adherent (...) TABLESPACE tbs_local_uniform STORAGE (INITIAL 400K NEXT 100K PCTINCREASE 0 MINEXTENTS 2); Oracle alloue (400+100)/128 = 3,5 arrondi à l’entier supérieur = 4 extensions de 128 Ko pour la table.  Si  la  même  table  est  créée  dans  un  tablespace  géré  localement,  avec  une  gestion  automatique  des  extensions,  Oracle  alloue  (400+100)/64  =   7,8  arrondi  à  l’entier  supérieur  =   8 extensions  de  64  Ko  pour  la  table  (une  taille  d’extension de 64 Ko est choisie par Oracle car la taille initiale du segment est inférieure à 1 Mo).  Les informations enregistrées dans le dictionnaire de données (vue DBA_TABLES et consoeurs) sont les suivantes :  ■

■

■

■

Les valeurs MINEXTENTS et MAXEXTENTS sont ignorées et forcées respectivement à 1 (même si plusieurs extensions  ont été allouées au segment) et UNLIMITED.  La valeur calculée pour la taille initiale devient la nouvelle valeur INITIAL (même si l’espace réellement alloué est  supérieur, compte tenu de l’arrondi sur le nombre d’extensions).  Pour un tablespace AUTOALLOCATE, les valeurs NEXT et PCTINCREASE sont ignorées et mises à NULL (c’est Oracle qui  décide).  Pour  un  tablespace UNIFORM, NEXT est mis égal à la taille des extensions du tablespace (option SIZE de la clause  UNIFORM du tablespace) et PCTINCREASE est mis égal à 0 (toutes les extensions ont la même taille). 

Conclusion : les  options  NEXT,  PCTINCREASE,  MINEXTENTS  et  MAXEXTENTS  ne  sont  pas  d’une  grande  utilité  pour  un  tablespace géré localement.  Lorsque  l’espace  initialement  alloué  au  segment  est  plein,  des  extensions  supplémentaires  sont  allouées  au  segment.  Si le segment est stocké dans un tablespace UNIFORM, toutes les extensions complémentaires allouées au segment  ont la même taille.  Si  le  segment  est  stocké  dans  un  tablespace  AUTOALLOCATE,  c’est  Oracle  qui  détermine  la  taille  des  nouvelles  extensions allouées au segment, selon un algorithme non documenté, Visiblement, le fonctionnement est le suivant  lorsqu’une  taille  initiale  de  64  Ko  a  été  utilisée : tant  que  le  segment  a  moins  de  16  extensions,  Oracle  alloue  des  extensions  de  64 Ko,  puis  il  passe  à  des  extensions  de  1  Mo,  jusqu’à  64  Mo,  puis  à  des  extensions  de  8 Mo.  Par  ailleurs,  Oracle  tente  d’allouer  consécutivement  des  extensions  de  même  taille,  jusqu’à  obtenir  un  nombre  d’extensions consécutives occupant un espace égal à la taille d’extension supérieure.  Exemple :  SQL> -- création d’un tablespace géré localement avec SQL> -- une gestion automatique des extensions SQL> CREATE TABLESPACE test 2 DATAFILE ’e:\oradata\hermes\test01.dbf’ SIZE 10M 3 EXTENT MANAGEMENT LOCAL AUTOALLOCATE; Tablespace créé. SQL> -- création de trois tables : deux "petites" et une "grosse" SQL> CREATE TABLE table200k(c NUMBER) 2 TABLESPACE test 3 STORAGE(INITIAL 200K); Table créée. SQL> CREATE TABLE tablexk(c NUMBER)

openmirrors.com

sans clause STORAGE

© ENI Editions - All rights reserved - Algeria Educ

- 5-

2 TABLESPACE test; Table créée. SQL> CREATE TABLE table2M(c NUMBER) 2 TABLESPACE test 3 STORAGE(INITIAL 2M); Table créée. SQL> -- supervision du stockage dans le tablespace SQL> @info_stockage_tablespace BLOCK_ID EXTENT_ID SEGMENT_NAME BLOCKS TAILLE_KO ---------- ---------- --------------- ---------- ---------9 0 TABLE200K 8 64 17 1 TABLE200K 8 64 25 2 TABLE200K 8 64 33 3 TABLE200K 8 64 41 0 TABLEXK 8 64 49 *** LIBRE *** 88 704 137 0 TABLE2M 128 1024 265 1 TABLE2M 128 1024 393 *** LIBRE *** 888 7104 Cet exemple illustre les points suivants:  ●

●

Oracle a choisi des extensions de 64 Ko pour les "petites" tables et des extensions de 1 Mo pour la "grosse"  table.  Oracle a laissé de l’espace libre entre les petites tables et la grosse table : 704 Ko, soit 11 extensions de 64  Ko.  Cet  espace  est  plutôt  réservé  à  des  extensions  de  64  Ko,  ce  qui  lui  permet  d’avoir  un  total  de  16  extensions  de  64  Ko  consécutives  (soit  potentiellement  une  extension  de  1  Mo  en  cas  de  libération  de  ces  extensions). 

5. Cas des tablespaces SYSTEM et SYSAUX  Depuis  Oracle9i  release  2  (version  9.2),  le  tablespace SYSTEM  peut  être  géré  localement,  et  dans  ce  cas,  forcément  avec une gestion automatique des extensions (EXTENT MANAGEMENT LOCAL AUTOALLOCATE) et une gestion manuelle de  l’espace dans les segments (SEGMENT SPACE MANAGEMENT MANUAL). Par défaut, il est géré par le dictionnaire. Créer un  tablespace SYSTEM géré localement a les conséquences (positives) suivantes :  ●

Tous les tablespaces doivent être gérés localement (conseillé par Oracle) ; 

●

Un tablespace temporaire par défaut doit être créé dès la création de la base (conseillé par Oracle) ; 

●

Si  la  gestion  automatique  des  segments  d’annulation  est  activée  (conseillé  par  Oracle),  un  tablespace  d’annulation doit être créé dès la création de la base de données (conseillé par Oracle). 

Dans l’ordre  SQL CREATE DATABASE,  la  clause EXTENT MANAGEMENT LOCALpermet de spécifier que le tablespace SYSTEM  est géré localement :  CREATE DATABASE hermes ... DATAFILE ’e:\oradata\hermes\system01.dbf’ SIZE 200M AUTOEXTEND ON NEXT 10M EXTENT MANAGEMENT LOCAL ... Le  tablespace  SYSAUX  est  obligatoirement  géré  localement  avec  une  gestion  automatique  des  extensions  (EXTENT MANAGEMENT LOCAL AUTOALLOCATE)  et  une  gestion  automatique  de  l’espace  dans  les  segments  (SEGMENT SPACE MANAGEMENT AUTO) ; il n’y a rien à spécifier lors de la création de la base de données.  En cas de mise à niveau d’une base de données, le tablespace SYSAUX est créé par un ordre SQL CREATE TABLESPACE.  La syntaxe suivante doit être utilisée :  CREATE TABLESPACE sysaux

- 6-

© ENI Editions - All rights reserved - Algeria Educ

DATAFILE spécification_fichier EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 7-

Tablespace temporaire  1. Rôle du tablespace temporaire  Lorsqu’une requête nécessite un tri (clause ORDER BY par exemple), Oracle tente de faire le tri en mémoire, dans la  PGA du processus serveur qui exécute la requête.  Si le tri ne tient pas en mémoire, Oracle le découpe en morceaux et trie chaque morceau individuellement en stockant  des résultats intermédiaires sur disque dans des segments temporaires.  Un  segment  temporaire  peut  être  créé  dans  n’importe  quel  tablespace  mais  ce  n’est  pas  souhaitable  pour  les  performances.  Oracle recommande donc de créer un tablespace dédié, de type TEMPORARY, pour stocker les segments temporaires,  et de préférence un tablespace temporaire géré localement. Il est possible de créer un tablespace temporaire géré  par le dictionnaire mais les performances sont alors limitées et ce choix est déprécié par Oracle ; c’est pourquoi nous  ne l’évoquerons pas davantage.  Les requêtes qui peuvent demander un tri sont les suivantes :  ●

SELECT ... ORDER BY ; 

●

SELECT ... GROUP BY ; 

●

SELECT DISTINCT ... ; 

●

requêtes ensemblistes (UNION, INTERSECT, MINUS) ; 

●

CREATE INDEX ; 

●

calcul des statistiques ; 

●

jointures par tri­fusion (sort merge join). 

Utiliser  un  tablespace  permanent  comme  tablespace  temporaire  est  possible  (c’est  ce  qui  passe  par  défaut  avec  le  tablespace  SYSTEM)  mais  ce  n’est  pas  conseillé,  notamment  du  point  de  vue  des  performances.  En  effet,  dans  un  tablespace  permanent,  les  segments  temporaires  sont  alloués  et  libérés  à  chaque  tri ; c’est  mauvais  pour  les  performances  et  cela  risque  de  fragmenter  l’espace  disponible  du  tablespace.  Dans  le  cas  de  l’utilisation  d’un  tablespace temporaire, un seul segment de tri est créé, par le premier tri, et réutilisé par les tris suivants.  Le segment temporaire peut être partagé par plusieurs tris (mais pas les extensions) et il est libéré uniquement lors  de l’arrêt de l’instance ; de cette manière, il y a moins d’allocation dynamique d’extensions, et les performances s’en  trouvent optimisées.  Un tablespace permanent géré localement ne peut pas être utilisé comme tablespace temporaire ; ce n’est  pas le cas d’un tablespace permanent géré par le dictionnaire.  Les  tablespaces  temporaires  sont  aussi  utilisés  pour  le  stockage  des  tables  temporaires  créées  par  l’ordre  SQL  CREATE GLOBAL TEMPORARY TABLE. 

2. Groupe de tablespaces temporaires  Avant la version 10, une requête ne pouvait utiliser qu’un seul tablespace temporaire, ce qui posait des problèmes de  performance si la requête s’exécutait en parallèle. Dans ce cas, plusieurs processus serveur traitaient la requête en  parallèle  et  chaque  processus  pouvait  solliciter  un  accès  au  tablespace  temporaire,  ce  qui  posait  parfois  des  problèmes de contentions au niveau des entrées/sorties.  Depuis  la  version  10,  il  est  possible  de  définir  des  groupes  de  tablespaces  temporaires.  Dans  le  cas  de  l’exécution  d’une requête en parallèle, les différents tablespaces temporaires du groupe pourront être utilisés par les différents  processus serveur qui traitent la requête. Cela ne présente réellement un intérêt du point de vue des performances  que si les fichiers de données des différents tablespaces temporaires sont stockés sur des disques différents. 

© ENI Editions - All rights reserved - Algeria Educ

- 1-

Le  nom  d’un groupe de tablespaces temporaires peut être utilisé partout où un nom de tablespace temporaire est  employé.  L’espace  de  nommage  des  groupes  de  tablespaces  temporaires  est  d’ailleurs  celui  des  tablespaces ; un  groupe de tablespace temporaires ne peut pas porter le même nom qu’un tablespace.  Un groupe de tablespaces temporaires n’est pas explicitement créé ou supprimé. Il est implicitement créé lorsqu’un  premier  tablespace  temporaire  est  affecté  au  groupe  et  implicitement  supprimé,  lorsque  le  dernier  tablespace  temporaire est retiré du groupe. 

3. Création d’un tablespace temporaire géré localement  L’ordre SQL CREATE TEMPORARY TABLESPACEpermet de créer un tablespace temporaire géré localement.  Syntaxe  CREATE [ BIGFILE | SMALLFILE ] TEMPORARY TABLESPACE nom TEMPFILE spécification_fichier [,...] [ EXTENT MANAGEMENT LOCAL ] [ UNIFORM [ SIZE valeur [K|M] ] ] [ TABLESPACE GROUP nom_groupe ] ; - spécification_fichier ’nom_fichier’ [ SIZE valeur [K|M|G|T] ] [REUSE] [ clause_auto_extend ] - clause_auto_extend AUTOEXTEND { OFF | ON [ NEXT valeur [K|M|G|T] ] [ MAXSIZE { UNLIMITED | valeur [K|M|G|T] } ] } Exemple :  CREATE TEMPORARY TABLESPACE tempo TEMPFILE ’e:\oradata\hermes\tempo01.dbf’ SIZE 100M AUTOEXTEND ON NEXT 10M MAXSIZE 1G ; Les options de l’ordre SQL CREATE TEMPORARY TABLESPACE ont la même signification que les options de même nom de  l’ordre SQL CREATE TABLESPACE (voir la section Tablespace permanent).  Vous pouvez néanmoins noter les points suivants :  ●

●

●

●

●

●

Un tablespace temporaire géré localement peut être un tablespace BIGFILE ; dans ce cas, un seul fichier de  données peut être spécifié.  Les fichiers de données d’un tablespace temporaire géré localement sont spécifiés par le mot clé TEMPFILE et  non DATAFILE.  Un tablespace temporaire géré localement présente forcément une gestion uniforme de ses extensions. Les  clauses EXTENT MANAGEMENT LOCAL et UNIFORM sont donc optionnelles. Par défaut, la taille des extensions est  de  1  Mo ; elle  est  satisfaisante  dans  une  grande  majorité  des  cas.  La  clause  SIZE  peut  être  utilisée  pour  spécifier une autre taille ; dans ce cas, le mot clé UNIFORM doit être mentionné.  Un  tablespace  temporaire  géré  localement  utilise  obligatoirement  la  taille  de  bloc  standard ; il  n’est  pas  possible d’employer une autre taille de bloc.  Un tablespace temporaire géré localement est obligatoirement ONLINE.  Les  clauses LOGGING,  NOLOGGING, FORCE LOGGING et  FLASHBACK  sont  interdites  pour  un  tablespace  temporaire  géré localement. 

La clause TABLESPACE GROUP permet d’affecter le tablespace temporaire à un groupe ; si le groupe n’existe pas, il est  implicitement créé. Par défaut, le tablespace temporaire n’appartient à aucun groupe. 

4. Tablespace temporaire par défaut  Un  tablespace  temporaire  n’est  réellement  utilisé  que  lorsqu’il  est  "affecté"  aux  utilisateurs,  grâce  à  la  clause  TEMPORARY TABLESPACE des ordres SQL CREATE USER et ALTER USER (voir le chapitre Gestion des utilisateurs et de leurs  droits).  Si  cette  clause  est  omise,  c’est  le  tablespace  SYSTEM  qui  est  affecté  comme  tablespace  temporaire  à  - 2-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

l’utilisateur, ce qui est mauvais pour les performances.  Pour résoudre ce problème et faciliter la gestion des utilisateurs, il est possible de définir un tablespace temporaire  par  défaut,  dès  la  création  de  la  base  de  données,  ou  ultérieurement.  Cette  technique  n’empêche  pas  d’utiliser  d’autres tablespaces temporaires affectés spécifiquement à des utilisateurs pour des besoins particuliers.  Un  tablespace  SYSTEM  géré  localement  ne  peut  pas  être  utilisé  comme  tablespace  temporaire  par  défaut,  d’où  la  nécessité, dans ce cas, de créer et définir un tablespace temporaire par défaut dès la création de la base.  Si  le  tablespace SYSTEM  est  géré  par  le  dictionnaire,  et  s’il  est  utilisé  comme  tablespace  temporaire  par  défaut,  un  message est écrit dans le fichier d’alerte de l’instance.  Pour  créer  et  définir  un  tablespace  temporaire  par  défaut  lors  de  la  création  de  la  base  de  données,  vous  devez  utiliser la clause DEFAULT TEMPORARY TABLESPACE de l’ordre SQL CREATE DATABASE.  Syntaxe  [ BIGFILE | SMALLFILE ] DEFAULT TEMPORARY TABLESPACE nom TEMPFILE spécification_fichier [,...] [ EXTENT MANAGEMENT LOCAL ] [ UNIFORM [ SIZE valeur [K|M] ] ] Exemple :  DEFAULT TEMPORARY TABLESPACE temp TEMPFILE ’e:\oradata\hermes\temp01.dbf’ SIZE 100M AUTOEXTEND ON NEXT 10M MAXSIZE 1024M   Cette clause doit être présente si le tablespace SYSTEM est géré localement. La  syntaxe  est  la  même  que  celle  de  l’ordre  SQL  CREATE TEMPORARY TABLESPACE.  Un  tablespace  temporaire  géré  localement  est  créé  selon  la  spécification  et  défini  comme  tablespace  temporaire  par  défaut.  Notez  bien  que  le  tablespace temporaire par défaut ainsi créé est forcément géré localement (ce qui est conseillé par Oracle).  Le tablespace temporaire ainsi créé est pris en compte dès la création de la base de données, et donc affecté comme  tablespace temporaire aux utilisateurs créés durant cette opération (notamment SYS et SYSTEM).  Pour créer et définir un tablespace temporaire par défaut après la création de la base de données, vous devez :  ●

●

créer un tablespace temporaire, grâce à l’ordre SQL CREATE TEMPORARY TABLESPACE présenté précédemment ;  le  définir  comme  tablespace  temporaire  par  défaut,  grâce  à  la  clause  DEFAULT TEMPORARY TABLESPACE  de  l’ordre SQL ALTER DATABASE. 

Syntaxe  ALTER DATABASE DEFAULT TEMPORARY TABLESPACE nom ; nom doit désigner un tablespace temporaire ou un groupe de tablespaces temporaires qui existe déjà.  Lorsque cet ordre SQL est exécuté, tous les utilisateurs qui avaient l’ancien tablespace temporaire par défaut comme  tablespace temporaire se voient automatiquement attribuer le nouveau.  Pour retrouver le nom du tablespace temporaire par défaut, vous pouvez interroger la vue DATABASE_PROPERTIES pour  la propriété DEFAULT_TEMP_TABLESPACE :  SQL> SELECT property_value FROM database_properties 2 WHERE property_name = ’DEFAULT_TEMP_TABLESPACE’ ; PROPERTY_VALUE -----------------------------TEMP

5. Administration des tablespaces temporaires géré localement  L’administration  d’un  tablespace  temporaire  géré  localement  s’effectue  avec  les  ordres  SQL  présentés  pour  les  tablespaces permanents, avec quelques restrictions : ALTER TABLESPACE, ALTER DATABASE pour la gestion des fichiers  de données et DROP TABLESPACE. 

© ENI Editions - All rights reserved - Algeria Educ

- 3-

Les  fichiers  de  données  d’un  tablespace  temporaire  géré  localement  sont  particuliers ; Oracle  les  appelle  d’ailleurs  "fichiers de données temporaires". Les différences avec un fichier de données ordinaire sont les suivantes :  ●

Ils sont toujours en mode NOLOGGING ; 

●

Ils ne peuvent pas être désactivés ; 

●

Ils ne peuvent pas être passés en lecture seule. 

Les  fichiers  de  données  temporaires  des  tablespace  temporaires  gérés  localement  étant  en  mode  NOLOGGING,  les  modifications  ne  sont  pas  enregistrées  dans  les  fichiers  de  journalisation  (intéressant  pour  les  performances).  Par  contre, en cas de perte ou d’endommagement d’un de ces fichiers, la récupération (RECOVER)  n’est pas possible. Ce  n’est  pas  très  grave  puisqu’un  tablespace  temporaire  ne  contient  pas  de  données  permanentes ; en  cas  de  problème, il suffit de supprimer le tablespace, où plus simplement le fichier de données, puis de le recréer.  Les fichiers de données temporaires sont administrés avec les ordres SQL ALTER TABLESPACE et  ALTER DATABASE, en  remplaçant le mot clé DATAFILE par le mot clé TEMPFILE.  Les opérations suivantes sont autorisées :  ●

Ajout d’un fichier de données temporaire à un tablespace temporaire géré localement  ALTER TABLESPACE nom_tablespace ADD TEMPFILE spécification_fichier ;

●

Modification de la taille d’un fichier de données temporaire  ●

Tout type de tablespace  ALTER DATABASE TEMPFILE ’nom_complet’ [,...] RESIZE valeur [K|M|G|T] ;

●

Tablespace BIGFILE uniquement  ALTER TABLESPACE nom_tablespace_bigfile RESIZE valeur [K|M|G|T];

●

Modification de la clause AUTOEXTEND d’un fichier de données temporaire  ●

Tout type de tablespace  ALTER DATABASE TEMPFILE ’nom_complet’ [,...] clause_auto_extension;

●

Tablespace BIGFILE uniquement  ALTER TABLESPACE nom_tablespace_bigfile clause_auto_extension;

Par contre, un tablespace temporaire géré localement ne peut pas être passé OFFLINE.  De même, un fichier de données temporaire ne peut pas être renommé par l’ordre SQL ALTER TABLESPACE ... RENAME DATAFILE (puisqu’il ne peut pas être passé OFFLINE). Par contre, renommer un fichier de données temporaire avec un  ALTER DATABASE RENAME FILE  est  possible  (base  montée).  Pour  renommer  un  fichier  de  données  temporaire  base  ouverte, et donc aussi pour le déplacer, il faut le supprimer et le récréer.  Exemple :  -- supprimer le fichier de données temporaire SQL> ALTER DATABASE 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’en­tête).  USER_BLOCKS  Taille utile du fichier en blocs Oracle (généralement taille du fichier moins les blocs d’en­tête).  Exemple :  SQL> SELECT tablespace_name,file_name,status,autoextensible, 2 blocks,user_blocks,maxblocks 3 FROM ( SELECT * FROM dba_data_files 4 UNION ALL SELECT * FROM dba_temp_files); TABLESPACE_NAME FILE_NAME STATUS --------------- ---------------------------------------- --------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 ci­après.  DBA_SEGMENTS  OWNER  Nom du propriétaire du segment.  SEGMENT_NAME  Nom du segment.  SEGMENT_TYPE  Type du segment (TABLE, INDEX, ROLLBACK, TYPE2 UNDO, etc.). 

openmirrors.com

  © ENI Editions - All rights reserved - Algeria Educ

- 5-

TABLESPACE_NAME  Nom du tablespace qui contient le segment.  BYTES  Taille du segment en octets.  BLOCKS  Taille du segment en blocs Oracle.  EXTENTS  Nombre d’extensions allouées au segment.  INITIAL_EXTENT  Taille initiale du segment.  Exemple :  SQL> SELECT segment_name,segment_type, 2 initial_extent/1024 initial_ko,blocks,extents 3 FROM dba_segments WHERE tablespace_name=’TEST’; SEGMENT_NAME SEGMENT_TYPE INITIAL_KO BLOCKS EXTENTS --------------- ------------------ ---------- ---------- ---------TABLE2M TABLE 2048 256 2 TABLE200K TABLE 200 32 4 DBA_FREE_SPACE  TABLESPACE_NAME  Nom du tablespace qui contient l’extension libre.  FILE_ID  Identifiant du fichier de données qui contient l’extension libre.  BLOCK_ID  Numéro du premier bloc de l’extension libre.  BYTES  Taille de l’extension libre en octets.  BLOCKS  Taille de l’extension libre en blocs Oracle. 

Un tablespace qui n’a pas d’extension libre n’a pas de ligne dans DBA_FREE_SPACE.

DBA_EXTENTS  OWNER  Nom du propriétaire du segment auquel l’extension appartient.  SEGMENT_NAME  Nom du segment auquel l’extension appartient.  - 6-

© ENI Editions - All rights reserved - Algeria Educ

 

SEGMENT_TYPE  Type du segment (TABLE, INDEX, ROLLBACK, TYPE2 UNDO, etc.).  TABLESPACE_NAME  Nom du tablespace qui contient l’extension.  EXTENT_ID  Numéro de l’extension (0 pour la première).  FILE_ID  Identifiant du fichier de données qui contient l’extension.  BLOCK_ID  Numéro du premier bloc de l’extension.  BYTES  Taille de l’extension en octets.  BLOCKS  Taille de l’extension en blocs Oracle.  En complément, plusieurs vues possèdent une colonne TABLESPACE indiquant le nom du tablespace de stockage, par  exemple DBA_INDEXES et DBA_TABLES.  Exemple :  SQL> SELECT block_id,extent_id,segment_name, 2 blocks,bytes/1024 taille_ko 3 FROM dba_extents WHERE tablespace_name=’TEST’ 4 UNION 5 SELECT block_id,NULL,’*** LIBRE ***’, 6 blocks,bytes/1024 size_ko 7 FROM dba_free_space WHERE tablespace_name=’TEST’; BLOCK_ID EXTENT_ID SEGMENT_NAME BLOCKS TAILLE_KO ---------- ---------- --------------- ---------- ---------9 0 TABLE200K 8 64 17 1 TABLE200K 8 64 25 2 TABLE200K 8 64 33 3 TABLE200K 8 64 41 *** LIBRE *** 96 768 137 0 TABLE2M 128 1024 265 1 TABLE2M 128 1024 393 *** LIBRE *** 888 7104 V$SORT_SEGMENT  TABLESPACE_NAME  Nom du tablespace.  EXTENT_SIZE  Taille des extensions.  TOTAL_EXTENTS 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 7-

Nombre total d’extensions dans le segment.  TOTAL_BLOCKS  Nombre total de blocs Oracle dans le segment.  USED_EXTENTS  Nombre d’extensions actuellement allouées à des tris actifs.  USED_BLOCKS  Nombre total de blocs Oracle actuellement alloués à des tris actifs.  MAX_USED_SIZE  Nombre maximum d’extensions utilisées par tous les tris (simultanément).  MAX_USED_BLOCKS  Nombre maximum de blocs utilisés par tous les tris (simultanément).  MAX_SORT_SIZE  Nombre maximum d’extensions utilisées par un tri (le plus gros tri).  MAX_SORT_BLOCKS  Nombre maximum de blocs utilisés par un tri (le plus gros tri).  Exemple :  SQL> SELECT tablespace_name,total_blocks,used_blocks, 2 max_used_blocks,max_sort_blocks 3 FROM v$sort_segment; TABLESPACE_NAME TOTAL_BLOCKS USED_BLOCKS MAX_USED_BLOCKS MAX_SORT_BLOCKS --------------- ------------ ----------- --------------- --------------TEMP 256 0 256 64 Il existe aussi une vue, V$TEMPSEG_USAGE, qui peut être utile pour identifier les sessions (et les requêtes) qui utilisent  actuellement de l’espace temporaire.  Exemple :  SQL> SELECT t.username,t.tablespace,t.segtype,t.extents,t.blocks, 2 s.sql_text 3 FROM v$tempseg_usage t,v$sql s 4 WHERE t.sql_id = s.sql_id; USERNAME TABLESPACE SEGTYPE EXTENTS BLOCKS ---------- ---------- --------- ---------- ---------SQL_TEXT ----------------------------------------------------OHEU TEMP SORT 2 256 SELECT * FROM t ORDER BY c1,c2,c3 V$SYSAUX_OCCUPANTS  OCCUPANT_NAME  Nom du composant.  OCCUPANT_DESC  Description du composant.    - 8-

© ENI Editions - All rights reserved - Algeria Educ

SCHEMA_NAME  Nom du schéma dans lequel le composant est stocké.  MOVE_PROCEDURE  Nom de la procédure permettant de déplacer le composant dans un autre tablespace.  MOVE_PROCEDURE_DESC  Description de la procédure de déplacement.  SPACE_USAGE_KBYTES  Espace actuellement utilisé par le composant (en Ko).  Exemple :  SQL> SELECT occupant_desc,space_usage_kbytes 2 FROM v$sysaux_occupants WHERE space_usage_kbytes ; 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<SID>  Et pour terminer, l’éternelle question : que faut­il faire des termes techniques en anglais ? Les traduire ou pas ? Dans  les  commandes,  les  termes  techniques  sont  en  anglais,  d’où  la  nécessité  de  les  connaître.  Si  vous  utilisez  les  outils  graphiques en français, vous constaterez que beaucoup de ces termes ont été traduits, ce qui est parfois déroutant  (d’autant  que  certaines  traductions  sont  un  peu  "bizarres").  Dans  cet  ouvrage,  j’ai  donc  tenté  de  donner  les  correspondances systématiquement, mais en essayant de ne pas trop alourdir mon propos. 

© ENI Editions - All rights reserved - Algeria Educ

- 1-

Utiliser le Database Control  1. Espace disque logique (tablespace)  Dans le Database Control, cliquez sur le lien Serveur sur la page d’accueil puis sur le lien Espaces disque logiques  (cadre Stockage) pour accéder à la page de gestion des tablespaces : 

  À partir de cette page, vous pouvez effectuer diverses actions sur les tablespaces : 

 

●

créer un nouveau tablespace (bouton Créer ou menu Créer comme) ; 

●

supprimer un tablespace (bouton Supprimer) ; 

●

modifier un tablespace (bouton Modifier) ; 

●

ajouter un fichier de données à un tablespace (menu Ajouter un fichier de données) ; 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

●

placer  un  tablespace  en  lecture  seule  (menu  Mettre  en  lecture  seule),  en  lecture  écriture  (menu  Rendre  accessible en écriture), l’activer (menu Mettre en ligne), le désactiver (menu Mettre hors ligne). 

En  cliquant  sur  le  lien  du  nom  de  tablespace,  ou  en  cliquant  sur  les  boutons  Créer,  Modifier  ou  Visualiser,  vous  arrivez sur la page de définition d’un tablespace. 

  L’onglet Général permet de définir le nom et les caractéristiques générales du table­ space : mode de gestion, type,  statut.  L’onglet Stockage permet de préciser des informations relatives au stockage : gestion uniforme ou automatique des  extensions, mode de gestion de l’espace dans les segments, taille de bloc.    Dans la terminologie du Database Control, en français, un "ensemble de blocs contigus" est une extension. L’onglet  Seuils  permet  de  définir  des  seuils  d’alerte  sur  le  remplissage  du  tablespace SELECT 2 TO_CHAR(begin_time,’DD/MM HH24:MI’) begin_time, 3 TO_CHAR(end_time,’DD/MM HH24:MI’) end_time, 4 undoblks, 5 maxquerylen, 6 tuned_undoretention 7 FROM 8 v$undostat; BEGIN_TIME END_TIME UNDOBLKS MAXQUERYLEN TUNED_UNDORETENTION ----------- ----------- ---------- ----------- ------------------19/07 16:23 19/07 16:28 15 936 1656 19/07 16:13 19/07 16:23 37 635 1475 19/07 16:03 19/07 16:13 71 1239 2079 19/07 15:53 19/07 16:03 144 638 1479 19/07 15:43 19/07 15:53 38 1242 2082 19/07 15:33 19/07 15:43 268 641 1481 19/07 15:23 19/07 15:33 33 1244 2084

- 4-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

19/07 15:13 19/07 15:23 40 643 19/07 15:03 19/07 15:13 31 1249 19/07 14:53 19/07 15:03 156 648 19/07 14:43 19/07 14:53 33 47 ... SQL> SELECT MAX(undoblks),MAX(tuned_undoretention) 2 FROM v$undostat; MAX(UNDOBLKS) MAX(TUNED_UNDORETENTION) ------------- ------------------------

1484 2088 1488 900

Sur cet exemple, la durée de rétention la plus longue est de 2261 secondes.  Lors d’un pic d’activité (traitement batch ?), l’instance a utilisée 79560 blocs en 10 minutes, soit un peu moins de 133  blocs par secondes.  La taille de bloc étant de 8 Ko, la quantité totale d’espace d’annulation nécessaire peut être estimée à 2261 x 133 x  8 Ko soit 2,29 Go. Le tablespace d’annulation peut être dimensionné en conséquence, en prenant un peu de marge  (10 à 20%). Cette estimation est a priori une estimation haute qui considère que le pic d’activité de mise à jour se  produit au moment où la durée de rétention est la plus longue (ce qui n’est pas forcément le cas). 

© ENI Editions - All rights reserved - Algeria Educ

- 5-

Utiliser le Database Control  Le  tablespace  d’annulation et ses fichiers de données s’administrent  à  partir  des  pages Espaces  disque  logiques et  Fichiers de données (voir la section Utiliser le Database Control du chapitre Gestion des tablespaces et des fichiers de  données).  Sur  la  page  Serveur,  le  lien  Segments  d’annulation  (cadre  Stockage)  permet  d’accéder  à  la  page  de  gestion  des  segments d’annulation manuels. En gestion automatique des segments d’annulation, cette page n’est d’aucune utilité.  Toujours sur la page Serveur, le lien Gestion automatique de l’annulation (cadre Configuration de base de données)  permet d’accéder à la page de gestion automatique de l’annulation.  La première partie de la fenêtre vous donne des informations sur la configuration actuelle : 

  Le bouton Modifier un espace disque logique permet de changer de tablespace d’annulation actif.  L’onglet Activité du système affiche des informations sur l’activité passée du système.  La deuxième partie de la fenêtre vous fournit des conseils sur la configuration : 

  Le  bouton  Modifier  l’espace  disque  logique  d’annulation  (undo  tablespace)  permet  de  modifier  le  tablespace  d’annulation actif (ajouter un fichier de données, modifier la taille d’un fichier de données, etc.). 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

Le  bouton  Modifier  la  conservation  pour  annulation  (undo)  permet  de  modifier  la  valeur  du  paramètre  UNDO_RETENTION.  L’analyse est basée sur une période d’analyse (par défaut les sept derniers jours) et une durée de conservation des  informations d’annulation. Vous pouvez modifier ces valeurs dans le cadre Période d’analyse puis cliquer sur le bouton  Exécuter l’analyse pour mettre à jour les résultats.  En résultat, le conseiller propose une taille minimum et une taille recommandée pour le tablespace d’annulation.  Le  lien  Afficher  le  graphique  permet  d’afficher  un  graphique  qui  donne  une  estimation  de  la  taille  du  tablespace  d’annulation (en Mo) en fonction de la durée de conservation des informations d’annulation (en minutes) : 

  Le graphique montre notamment l’espace disque requis pour la durée de rétention actuelle réglée automatiquement  (304 Mo pour 31 minutes sur l’exemple ci­dessus), mais aussi la durée de rétention maximale possible ("meilleur choix  possible")  compte  tenu  de  la  taille  maximale  possible  du  tablespace  d’annulation  (3371  minutes  pour  1022  Mo  sur  l’exemple ci­dessus).  Si  vous  cliquez  sur  un  point  du  graphique,  le  champ  Durée  (cadre  Période  d’analyse)  et  la  taille  minimale  du  tablespace d’annulation (cadre Résultats d’analyse) sont mis à jour en conséquence.  Si vous avez modifié le champ Durée du cadre Période d’analyse (manuellement ou en cliquant sur le graphique), un  bouton  Appliquer  s’affiche  dans  la  fenêtre.  Si  vous  cliquez  sur  ce  bouton,  vous  appliquez  la  nouvelle  durée  au  paramètre UNDO_RETENTION (ALTER SYSTEM SET UNDO_RETENTION = ...).  Pour  les  analyses,  veillez  à  utiliser  une  période  d’analyse  représentative  de  l’activité  de  votre  base  de  données. 

- 2-

© ENI Editions - All rights reserved - Algeria Educ

Problèmes courants et solutions  ORA-01552: imposs util. segment d’annul. système pour le tablespace non syst.’XXXX’ Explication  Il  n’y  a  pas  de  segment  d’annulation  actif  (ONLINE)  autre  que  le  segment  d’annulation  SYSTEM  (vérifiable  dans  V$ROLLNAME) et une transaction concerne le tablespace XXXX.  Cause(s)  La  gestion  automatique  des  segments  d’annulation  n’est  pas  active.  La  gestion  automatique  des  segments  d’annulation est active mais il n’y a pas de tablespace d’annulation actif.  Action(s)  Vérifiez si la base a démarré en gestion automatique des segments d’annulation (paramètre UNDO_MANAGEMENT). Dans le  cas  contraire,  redémarrez  la  base  de  données  en  activant  la  gestion  automatique.  Vérifiez  s’il  existe  un  tablespace  d’annulation (dans la vue DBA_TABLESPACES). Dans le cas contraire, créez­en un.  ORA-30036: impossible d’étendre le segment par N dans le tablespace d’annulation’XXXX’ Explication  Un segment d’annulation n’arrive pas à s’étendre.  Cause(s)  Le  segment  d’annulation  n’arrive  pas  à  s’étendre  car  le  tablespace  dans  lequel  il  est  stocké  n’a  pas  suffisamment  d’espace disponible et ne peut lui­même s’étendre.  Action(s)  Il faut augmenter l’espace disponible dans le tablespace :­ soit en lui allouant un nouveau fichier de données (ALTER TABLESPACE ... ADD DATAFILE ...) ;  soit  en  augmentant  la  taille  d’un  fichier  de  données  du  tablespace  (ALTER DATABASE DATAFILE ... RESIZE ...) ;  soit  en  autorisant  un  fichier  de  données  du  tablespace  à  s’étendre  automatiquement (ALTER DATABASE DATAFILE ... AUTOEXTEND ON ...).  ORA-01555: clichés trop vieux : rollback segment no N, nommé "XXXX", trop petit Explication  C’est  la  "fameuse"  erreur snapshot  too  old  ("cliché  trop  vieux").  Une  lecture  cohérente  n’a  pas  pu  être  menée  à  son  terme, car elle requiert une ancienne valeur qui n’est plus présente dans le segment d’annulation.  Cause(s)  Le tablespace d’annulation n’est pas en RETENTION GUARANTEE et a manqué d’espace ; il n’a pas pu honorer la durée de  rétention.  Action(s)  Si  le  tablespace  d’annulation  est  trop  petit  par  rapport  à  la  durée  de  rétention,  augmentez  sa  taille  (voir  l’erreur  précédente pour les actions possibles). Si le tablespace d’annulation est déjà très volumineux, vous pouvez envisager  de le mettre en RETENTION GUARANTEE, avec le risque de voir certaines mises à jour échouer (généralement avec une  erreur ORA-30036).  Typiquement, ce problème se produit lorsqu’il y a, simultanément sur une table, une forte activité de mise à jour et des  lectures longues.  Une  autre  approche  pour  résoudre  ce  problème  consiste  à  essayer  de  séparer,  dans  le  temps  ou  dans  l’espace,  l’activité de mise à jour et l’activité de lecture : 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

●

●

- 2-

dans  le  temps : par  exemple,  lancer  l’édition  du  volumineux  rapport  qui  pose  problème  à  un  moment  plus  propice dans la journée ;  dans  l’espace : par  exemple,  mettre  en  place  un  petit  mécanisme  de  réplication  et  lancer  l’édition  du  volumineux rapport qui pose problème sur les tables répliquées. 

© ENI Editions - All rights reserved - Algeria Educ

Principes  Pour la gestion de la sécurité, Oracle permet :  ●

de  définir  les  utilisateurs  qui  peuvent  se  connecter  à  la  base  de  données  (avec  une  identification  par  le  système d’exploitation ou par la base de données) ; 

●

de définir dans quel(s) tablespace(s) un utilisateur peut créer des objets (éventuellement aucun) ; 

●

de limiter l’utilisation des ressources système ; 

●

●

d’imposer une politique de gestion de mots de passe (expiration périodique, non­ réutilisation avant un certain  temps, etc.) ;  de définir les droits de chaque utilisateur à l’intérieur de la base de données. 

Dans une base de données Oracle, les droits des utilisateurs sont gérés avec la notion de privilège.  Un privilège est le droit :  ●

●

d’exécuter un ordre SQL en général (par exemple, créer une table) : c’est la notion de privilège système ;  d’accéder à un objet d’un autre utilisateur (par exemple, mettre à jour les données de la table CLIENT) : c’est la  notion de privilège objet. 

Les  privilèges  peuvent  être  attribués  directement  aux  utilisateurs  ou  par  l’intermédiaire  de  rôles.  Un  rôleest  un  regroupement  nommé  de  privilèges  (systèmes  et  objets)  qui  peut  être  attribué  en  tant  que  tel  à  un  utilisateur ; cet  utilisateur reçoit alors automatiquement les privilèges contenus dans le rôle. Les rôles facilitent la gestion des droits.  Oracle  propose  par  ailleurs  une  fonctionnalité  d’audit  qui  permet  de  tracer  l’activité  des  utilisateurs  dans  la  base  de  données. Pour en savoir plus, vous pouvez consulter la documentation Oracle® Database Security Guide. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

Créer et modifier les utilisateurs  1. Mode d’identification de l’utilisateur  Un  utilisateur  peut  être  identifié  par  Oracle  ou  par  le  système  d’exploitation.  Les  deux  modes  d’identification  sont  utilisables simultanément dans la même base de données. 

a. Identification par Oracle  L’utilisateur  se  connecte  à  la  base  en  saisissant  un  nom  et  un  mot  de  passe.  Oracle  vérifie  le  nom  et  le  mot  de  passe de l’utilisateur.  SQL> CONNECT oheu/rx239$ Connecté. Les fonctionnalités de gestion des mots de passe proposées par Oracle sont utilisables. 

b. Identification par le système d’exploitation  L’utilisateur se connecte à la base sans saisir de nom ni de mot de passe.  SQL> CONNECT / Connecté. Oracle ne vérifie pas le mot de passe mais contrôle simplement que le nom de l’utilisateur, au niveau du système  d’exploitation, correspond à un nom d’utilisateur dans la base de données. L’identification initiale a été réalisée par  le système d’exploitation.  Les fonctionnalités de gestion des mots de passe proposées par Oracle ne sont pas utilisables (ce n’est pas Oracle  qui gère le mot de passe).  Pour faire le lien entre le nom de l’utilisateur dans le système d’exploitation et le nom de l’utilisateur dans la base  de données, Oracle utilise un préfixe défini par le paramètre OS_AUTHENT_PREFIX(par défaut égal à OPS$).  Par exemple, l’utilisateur ayant pour nom vdep au niveau du système d’exploitation pourra se connecter à la base  par un CONNECT / uniquement s’il existe un compte Oracle ops$vdep.  Sur  plate­forme  Windows,  le  nom  de  domaine,  ou  à  défaut,  le  nom  de  la  machine,  fait  partie  du  nom  de  l’utilisateur : SRVWINORA\VDEP  par  exemple.  C’est  ce  nom  complet  qui  doit  être  préfixé  pour  constituer  le  nom  du  compte Oracle (le tout en majuscules) : OPS$SRVWINORA\VDEP par exemple.  Le préfixe peut être égal à une chaîne vide (OS_AUTHENT_PREFIX = "") ; dans ce cas, le nom de l’utilisateur au niveau  du système d’exploitation et le nom de l’utilisateur dans Oracle sont identiques.  Le paramètre REMOTE_OS_AUTHENTpeut, de plus, être positionné à TRUE pour indiquer si les utilisateurs distants sont  identifiables par cette méthode (FALSE pour interdire, valeur par défaut). Mettre le paramètre REMOTE_OS_AUTHENT à  TRUE peut être dangereux si le réseau n’est pas sécurisé. Ce paramètre est déprécié en version 11. 

2. Création d’un utilisateur  L’ordre SQL CREATE USER permet de créer un nouvel utilisateur.  Syntaxe  CREATE USER nom IDENTIFIED { BY mot_de_passe | EXTERNALLY } [ DEFAULT TABLESPACE nom_tablespace ] [ TEMPORARY TABLESPACE nom_tablespace ] [ QUOTA { valeur [K|M] | UNLIMITED } ON nom_tablespace [,...] ] [ PROFILE nom_profil ] [ PASSWORD EXPIRE ] [ ACCOUNT { LOCK | UNLOCK } ] ; Exemple : 

© ENI Editions - All rights reserved - Algeria Educ

- 1-

●

Utilisateur identifié par l’OS avec uniquement les clauses obligatoires 

CREATE USER "OPS$SRVWINORA\VDEP" IDENTIFIED EXTERNALLY; ●

Utilisateur identifié par Oracle avec des clauses supplémentaires 

CREATE USER oheu IDENTIFIED BY tempo DEFAULT TABLESPACE data QUOTA UNLIMITED ON data PASSWORD EXPIRE; Notez  la  syntaxe  particulière  pour  spécifier  le  nom  de  l’utilisateur  OPS$SRVWINORA\ VDEP : les  guillemets  sont  nécessaires car le nom contient des caractères non autorisés (barre oblique inverse). Par la suite, il faudra toujours  utiliser la même syntaxe pour gérer cet utilisateur.  Pour qu’un  nouvel  utilisateur  puisse  effectivement  se  connecter,  il  faut  en  plus  lui  donner  le  droit  de  le  faire,  en  lui  attribuant le privilège système CREATE SESSION (cf. Gérer les droits).  Il  est  donc  possible  d’avoir  des  comptes  pour  les  utilisateurs  sans  que  ces  derniers  aient  le  droit  de  se  connecter.  Cette  fonctionnalité  était  intéressante  en  version  7  puisqu’elle  permettait  soit  de  préparer  des  comptes  utilisateur  sans  les  activer  tout  de  suite,  soit  d’interdire  temporairement  à  un  utilisateur  de  se  connecter  sans  supprimer  son  compte.  Cette  fonctionnalité  peut  toujours  être  utilisée  mais  il  est  plus  simple  de  verrouiller/déverrouiller  explicitement le compte (ACCOUNT LOCK | UNLOCK).  Les options de l’ordre SQL CREATE USER sont :  nom Nom de l’utilisateur. Le nom de l’utilisateur doit respecter les règles de nommage d’Oracle présentées à la section La  base  de  données  du  chapitre  Les  bases  de  l’architecture  Oracle.  Si  ce  n’est  pas  le  cas,  il  faut  placer  le  nom  entre  guillemets.  IDENTIFIED Cette  clause  indique  si  l’utilisateur  est  identifié  par  le  système  d’exploitation  (EXTERNALLY)  ou  par  Oracle  (BY mot_de_passe).  Dans le cas d’une identification par Oracle, le mot de passe initial de l’utilisateur est spécifié.  Pour le mot de passe, les règles de nommage d’Oracle doivent être respectées, sauf si la fonctionnalité de contrôle  de la complexité des mots de passe est mise en œ uvre (nouveauté de la version 8 ­ voir plus loin).  Depuis la version 11, les mots de passe sont par défaut, sensibles à la casse (paramètre SEC_CASE_SENSITIVE_LOGON  égal  à TRUE  par  défaut).  Si  vous  souhaitez  avoir  des  mots  de  passe  non  sensibles  à  la  casse,  il  suffit  d’affecter  la  valeur FALSE au paramètre SEC_CASE_SENSITIVE_LOGON (mais ce n’est pas conseillé pour la sécurité).  DEFAULT TABLESPACE Cette clause indique dans quel tablespace les segments de l’utilisateur sont créés par défaut (c’est­à­dire si aucune  clause TABLESPACE n’est présente lors de la création du segment).  Si la clause est omise, le tablespace permanent par défaut de la base de données est affecté à l’utilisateur (voir la  section Tablespace permanent du chapitre Gestion des tablespaces et des fichiers de données).  La notion de tablespace par défaut n’empêche pas l’utilisateur de créer des objets dans un autre tablespace (s’il a un  quota  sur  le  tablespace  en  question) ; elle  permet  simplement  de  spécifier  un  tablespace  par  défaut  si  l’utilisateur  omet  la  clause  TABLESPACE  lors  de  la  création  d’un  segment.  Cette  clause  présente  surtout  un  intérêt  pour  les  utilisateurs qui peuvent créer des segments : les développeurs, les testeurs, plus rarement les utilisateurs finaux.  TEMPORARY TABLESPACE Cette  clause  indique  dans  quel  tablespace  les  segments  temporaires  de  l’utilisateur  sont  créés  (lors  d’un  tri,  par  exemple).  Vous  pouvez  indiquer  le  nom  d’un  tablespace  temporaire,  ou  le  nom  d’un  groupe  de  tablespaces  temporaires.  Si la clause est omise, le tablespace temporaire par défaut de la base de données est affecté à l’utilisateur (voir la  section Tablespace temporaire du chapitre Gestion des tablespaces et des fichiers de données).  QUOTA Cette clause indique dans quel(s) tablespace(s) l’utilisateur peut créer des objets, et jusqu’à quelle limite. 

- 2-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

La notion de QUOTA permet de limiter l’espace qu’un utilisateur peut employer dans un tablespace avec les segments  qu’il crée.  Cette fonctionnalité ne concerne que les utilisateurs qui peuvent créer des segments, et non les utilisateurs finaux  d’un  applicatif  qui  se  contentent  d’employer  des  objets  déjà  existants  et  qui  appartiennent  généralement  à  un  compte distinct (en quelque sorte le "propriétaire" de l’application).  Par défaut, les utilisateurs n’ont aucun quota sur aucun tablespace, sauf les DBA qui ont un quota illimité sur tous les  tablespaces.  Si  un  utilisateur  a  le  droit  de  créer  des  segments,  il  faut  lui  donner  explicitement  un  quota  sur  au  moins  un  tablespace.  Le  fait  qu’une  clause  DEFAULT TABLESPACE  ait  été  utilisée  ne  donne  aucun  quota  sur  le  tablespace  en  question ; ce sont deux mécanismes différents.  Dans  la  pratique,  il  ne  faut  donner  des  quotas  qu’aux  utilisateurs  qui  en  ont  besoin  (les  développeurs,  le  compte  "propriétaire"  de  l’application)  et  uniquement  sur  les  tablespaces  strictement  nécessaires  et  suffisants.  En  l’occurrence, il vaut mieux éviter de donner des quotas à ces utilisateurs sur le tablespace SYSTEM ou le tablespace  SYSAUX.  La notion de quota est sans objet pour le tablespace temporaire et le tablespace d’annulation.  Si un utilisateur cherche à créer un segment dans un tablespace sur lequel il n’a pas de quota ou qui aurait pour effet  de dépasser le quota alloué à cet utilisateur, une erreur est retournée :  ●

Aucun quota sur le tablespace  ORA-01950: pas de privilèges sur le tablespace ’DATA’

●

Dépassement de quota sur le tablespace  ORA-01536: dépassement du quota d’espace affecté au tablespace ’DATA’

PROFILE Cette clause indique le profil attribué à l’utilisateur. La notion de profil est présentée à la section Utiliser les profils.  PASSWORD EXPIRE Cette clause permet de forcer une modification du mot de passe lors de la première connexion (le mot de passe de  l’utilisateur est expiré). Cette clause est sans objet si l’utilisateur est identifié par le système d’exploitation.  Si le compte est créé avec l’option PASSWORD EXPIRE, l’utilisateur, lors de sa première connexion, sera invité à changer  le mot de passe qui lui a été attribué initialement.  ACCOUNT LOCK : le compte est verrouillé et la connexion interdite (erreur ORA-28000: compte verrouillé).  UNLOCK : le compte n’est pas verrouillé et la connexion autorisée (valeur par défaut).  Si  le  compte  est  créé  avec  l’option  LOCK,  le  compte  existe  mais  l’utilisateur  ne  peut  pas  se  connecter.  L’ordre  SQL  ALTER USER  pourra  être  utilisé  plus  tard  pour  déverrouiller  le  compte  de  l’utilisateur  (cf.  Créer  et  modifier  les  utilisateurs). 

3. Modification d’un utilisateur  L’ordre SQL ALTER USER permet de modifier un utilisateur.  Syntaxe  ALTER USER nom [ IDENTIFIED { BY mot_de_passe | EXTERNALLY } ] [ DEFAULT TABLESPACE nom_tablespace ] [ TEMPORARY TABLESPACE nom_tablespace ] [ QUOTA { valeur [K|M] | UNLIMITED } ON nom_tablespace [,...] ] [ PROFILE nom_profil ] [ PASSWORD EXPIRE ] [ ACCOUNT { LOCK | UNLOCK } ] ;

© ENI Editions - All rights reserved - Algeria Educ

- 3-

Les clauses sont les mêmes que pour la création.  Exemples :  ●

Modification du mot de passe d’un utilisateur  ALTER USER oheu IDENTIFIED BY tempo PASSWORD EXPIRE;

●

Modification du tablespace par défaut et attribution de quotas  ALTER USER oheu DEFAULT TABLESPACE test QUOTA UNLIMITED ON test QUOTA 10M ON data;

●

Verrouillage d’un compte  ALTER USER oheu ACCOUNT LOCK;

●

Déverrouillage d’un compte  ALTER USER oheu ACCOUNT UNLOCK;

Le  premier  exemple  permet  de  modifier  le  mot  de  passe  d’un  utilisateur  en  le  forçant  à  en  changer  lors  de  sa  première connexion ; cette technique peut être employée si l’utilisateur a perdu son mot de passe (le DBA n’a aucun  moyen de connaître le mot de passe des utilisateurs).  Le deuxième exemple permet de modifier le tablespace par défaut de l’utilisateur et de lui attribuer des quotas sur  deux tablespaces.  Le  troisième  exemple  peut  être  utilisé  pour  interdire  temporairement  à  un  utilisateur  de  se  connecter.  S’il  est  actuellement connecté, il n’est pas déconnecté.  Le quatrième exemple peut être utilisé pour autoriser de nouveau un utilisateur à se connecter.  Diminuer un quota, ou le mettre à 0, ne supprime pas les objets déjà créés par l’utilisateur.  Modifier le mot de passe de SYS modifie le mot de passe de SYSDBAenregistré dans le fichier de mot de passe  (si un fichier de mot de passe est utilisé). 

4. Suppression d’un utilisateur  L’ordre SQL DROP USER permet de supprimer un utilisateur.  Syntaxe  DROP USER nom [ CASCADE ] ; Exemple :  DROP USER "OPS$SRVWINORA\VDEP" CASCADE; Si  l’utilisateur  possède  des  objets,  l’option  CASCADE  doit  être  présente  pour  forcer  la  suppression  préalable  des  objets. Si l’utilisateur possède des objets et que l’option CASCADE soit absente, l’erreur ORA-01922 est retournée :  ORA-01922: CASCADE à indiquer pour supprimer ’OPS$SRVWINORA\VDEP’ C’est un ordre DDL  

- 4-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

: il n’a pas de ROLLBACK possible.  Un utilisateur actuellement connecté ne peut pas être supprimé :  ORA-01940: impossible de supprimer un utilisateur qui est connecté Avant  suppression  d’un  utilisateur,  il  est  possible  d’exporter  les  objets  qui  lui  appartiennent ; ces  objets  pourront  ultérieurement être réimportés dans un autre schéma. 

5. Trouver des informations sur les utilisateurs  Plusieurs vues du dictionnaire de données permettent d’obtenir des informations sur les utilisateurs :  ●

DBA_USERS : informations sur les utilisateurs ; 

●

DBA_TS_QUOTAS : informations sur les quotas des utilisateurs. 

Les colonnes intéressantes des différentes vues sont présentées ci­après.  DBA_USERS USERNAME  Nom de l’utilisateur.  USER_ID  Identifiant de l’utilisateur.  PASSWORD  Mot de passe (crypté) de l’utilisateur.  ACCOUNT_STATUS  Statut du compte (OPEN, LOCKED, UNLOCKED, EXPIRED, etc.).  LOCK_DATE  Date du verrouillage (si le compte est verrouillé).  EXPIRY_DATE  Date d’expiration du mot de passe.  DEFAULT_TABLESPACE  Tablespace par défaut de l’utilisateur.  TEMPORARY_TABLESPACE  Tablespace temporaire de l’utilisateur.  CREATED  Date de création de l’utilisateur.  PROFILE  Profil. 

© ENI Editions - All rights reserved - Algeria Educ

- 5-

DBA_TS_QUOTAS TABLESPACE_NAME  Nom du tablespace.  USERNAME  Nom de l’utilisateur qui a un quota dans le tablespace.  BYTES  Espace, en octets, actuellement utilisé par l’utilisateur.  MAX_BYTES  Quota, en octets, de l’utilisateur sur le tablespace (1).  BLOCKS  Espace, en blocs, actuellement utilisé par l’utilisateur.  MAX_BLOCKS  Quota, en blocs, de l’utilisateur sur le tablespace (1).  (1) ­1 si quota UNLIMITED 

- 6-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

Présentation générale  1. Notions d’instance et de base de données 

  Un serveur Oracle comporte deux éléments distincts, l’instance et la base de données.  La  base  de  données  se  compose  d’un  ensemble  de  fichiers  physiques  qui  contiennent  notamment  les  données.  L’instance se compose d’une structure de mémoire partagée et d’un ensemble de processus. Ces deux éléments sont  intimement liés mais doivent être bien distingués.  De  manière  imagée,  il  est  possible  de  considérer  que  l’instance  représente  une  application  (par  exemple  Microsoft  Word)  et  la  base  de  données,  le  document  (par  exemple  un  document  Microsoft  Word) ;  pour  pouvoir  accéder  à  la  base de données (l’équivalent du document Microsoft Word), il faut l’ouvrir avec une instance Oracle (l’équivalent de  l’application Microsoft Word).  Une  instance  ne  peut  ouvrir  qu’une  base  de  données  à  la  fois  et,  dans  la  grande  majorité  des  cas,  une  base  de  données  est  ouverte  par  une  seule  instance.  Néanmoins,  moyennant  la  mise  en  œ uvre  de  l’option  Real  Application  Clusters (RAC), une base de données peut être ouverte par plusieurs instances situées sur des nœ uds distincts d’un  cluster de serveurs ; cette option RAC est intéressante pour la haute disponibilité.  Un fichier de paramètres est utilisé par l’instance lors de son démarrage pour se configurer et faire le lien avec la base  de données.  En  dehors  des  processus  de  l’instance,  il  existe  des  processus  utilisateurs  correspondant  à  l’application  utilisée  par  l’utilisateur  pour  se  connecter  à  la  base  de  données  (SQL*Plus,  un  progiciel,  un  logiciel  spécifique,  etc.).  Dans  une  architecture client/serveur, ces processus utilisateurs sont situés sur le poste de l’utilisateur et communiquent avec le  serveur à travers le réseau grâce à la couche Oracle Net (voir le chapitre Oracle Net pour une présentation d’Oracle  Net). 

2. La base de données 

  Une base de données est constituée : 

© ENI Editions - All rights reserved - Algeria Educ

- 1-

●

D’un ou de plusieurs fichiers de données qui contiennent les données proprement dites. 

●

D’au minimum un fichier de contrôle qui contient des informations de contrôle sur la base de données. 

●

D’au minimum deux groupes de fichiers de journalisation qui enregistrent toutes les modifications apportées à  la base. 

Nous  verrons  ultérieurement  que  les  fichiers  de  journalisation  peuvent  être  archivés ;  ces  fichiers  de  journalisation  archivés ne font, à proprement parler, pas partie de la base de données.  Chaque base de données porte un nom défini lors de sa création ; ce nom est défini par le paramètre d’initialisation  DB_NAME  UPDATE adherent SET prenom = ’Olivier’ 2 WHERE ROWID = ’AAAER2AACAAADdiAAA’; Le ROWID permet de localiser physiquement la ligne ; il est utilisé en interne par Oracle dans les index. S’il est connu,  c’est le moyen le plus rapide pour accéder à une ligne.  Dans la structure interne du ROWID, Oracle a toutes les informations nécessaires à la localisation physique de la ligne  dans  un  fichier  de  données  (fichier,  numéro  de  bloc,  position  dans  le  bloc).  Un  ROWID  n’est  pas  directement  compréhensible ; par contre, le package DBMS_ROWID offre plusieurs fonctions qui permettent d’extraire les différentes 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 3-

composantes du ROWID.  Utiliser le ROWID dans une application (dans les clauses WHERE des ordres SQL) se révèle très intéressant du point de  vue  des  performances : Oracle  obtient  directement  l’adresse  physique  de  la  ligne  à  lire  ou  modifier,  sans  devoir  lire  toute la table ni passer par un index.  Le ROWID d’une ligne ne change jamais, tant que la ligne n’est pas supprimée. Modifier une ligne ne change pas son  ROWID puisque la ligne est, a priori, modifiée à l’intérieur du bloc où elle a été insérée ; ce sera aussi le cas si la ligne  est migrée vers un autre bloc par manque d’espace disponible (ce qui n’est pas bénéfique comme nous le verrons ci­ après). 

3. Chaînage et migration  En  règle  générale,  une  ligne  d’une  table  est  stockée  en  totalité  à  l’intérieur  d’un  bloc.  Pour  lire  la  ligne,  Oracle  n’a  besoin de lire qu’un seul bloc.  Si la ligne est intrinsèquement trop grande pour tenir dans un seul bloc, Oracle la stocke dans plusieurs blocs chaînés  par  des  pointeurs : c’est  le  phénomène  de  chaînage  d’une  ligne.  Pour  lire  cette  ligne,  Oracle  a  alors  besoin  de  lire  plusieurs blocs.  Si  une  ligne  grandit  suite  à  une  modification,  et  qu’il  ne  reste  plus  suffisamment  d’espace  libre  dans  le  bloc,  Oracle  déplace la ligne dans un autre bloc pointé par l’en­tête de la ligne resté dans le bloc d’origine : c’est le phénomène de  migration  d’une  ligne.  Le  ROWID  de  la  ligne  modifiée  et  migrée  n’a  pas  changé,  mais  pour  lire  cette  ligne,  Oracle  a  besoin  de  lire  deux  blocs,  ce  qui  dégrade  les  performances  des  accès  par  index.  L’intérêt  de  cette  technique  est  qu’Oracle n’a pas besoin de modifier le ROWID de la ligne dans les index lors d’une mise à jour de la ligne.  Le phénomène de chaînage est difficilement évitable, sauf en augmentant la taille des blocs. Il faut donc y penser lors  de la création de la base de données ou du tablespace. Cela peut être insuffisant pour les très grandes lignes.  Le  phénomène  de  migration  peut  (et  même  doit)  être  évité,  en  laissant  suffisamment  d’espace  disponible  dans  les  blocs pour les mises à jour. Le paramètre PCTFREE sera donc positionné avec soin sur les tables pour lesquelles la taille  des lignes insérées est sensiblement inférieure à la taille des lignes après modification(s). 

4. Spécifier le stockage d’une table  Le stockage d’une table peut être spécifié lors de la création de la table, dans l’ordre SQL CREATE TABLE.  Syntaxe simplifiée  CREATE TABLE nom_table (spécification des colonnes) [ TABLESPACE nom_tablespace ] [ PCTFREE valeur ] [ PCTUSED valeur ] [ clause_stockage ] [ NOCOMPRESS | COMPRESS [ FOR { ALL | DIRECT_LOAD } OPERATIONS ]] [ LOGGING | NOLOGGING ] ; - clause_stockage STORAGE ( [ INITIAL valeur [K|M] ] [ NEXT valeur [K|M] ] [ MINEXTENTS valeur ] [ MAXEXTENTS { valeur | UNLIMITED } ] [ PCTINCREASE valeur ] ) Exemple :  CREATE TABLE adherent (numero NUMBER(6), nom VARCHAR2(40), prenom VARCHAR2(30)) TABLESPACE data PCTFREE 30 STORAGE ( INITIAL 10M ) ; Les  clauses  TABLESPACE et  STORAGE  ont  déjà  été  présentées  au  chapitre  Gestion  des  tablespaces  et  des  fichiers  de  données.  N’oubliez  pas  que  la  clause  STORAGE  est  traitée  différemment  selon  que  le  tablespace  est  géré  par  le  dictionnaire ou localement. Dans un tablespace géré localement, seule l’option INITIAL est utile.  La clause PCTFREE donne la valeur du PCTFREE (entre 0 et 99, 10 par défaut). 

- 4-

© ENI Editions - All rights reserved - Algeria Educ

La clause PCTUSED donne la valeur du PCTUSED (entre 0 et 99, 40 par défaut). Cette clause est ignorée si la table est  stockée dans un tablespace géré localement avec une gestion automatique de l’espace dans les segments.  Par définition, PCTFREE+PCTUSED doit être strictement inférieur à 100.  La clause COMPRESS permet de compresser les données dans les blocs. L’option DIRECT_LOAD indique que les blocs sont  compressés, uniquement lors des opérations de chargement direct (création de la table à partir d’une sous­requête,  reconstruction de la table ou chargement par des insertions en chemin direct) ; c’est la valeur par défaut. L’option ALL  indique  que  les  blocs  sont  compressés  pour  toutes  les  opérations  (y  compris  les  insertions  ou  modifications  individuelles).  Par  défaut,  la  table  hérite  de  l’option  COMPRESS  ou  NOCOMPRESS,  éventuellement  définie  au  niveau  du  tablespace dans lequel elle est stockée.  La clause NOLOGGING permet de ne pas journaliser certaines opérations effectuées sur la table (création à partir d’une  sous­requête et insertion en chemin direct essentiellement) ; les mises à jour individuelles sont, par contre, toujours  journalisées.  La  clause  NOLOGGING  est  sans  effet  si  la  table  est  stockée  dans  un  tablespace  défini  en  mode  FORCE LOGGING,  ou  si  la  base  de  données  elle­même  est  en  mode  FORCE LOGGING.  Par  défaut,  la  table  hérite  de  l’option  LOGGING  ou  NOLOGGING,  éventuellement  définie  au  niveau  du  tablespace  dans  lequel  elle  est  stockée.  La  clause  NOLOGGING est intéressante pour améliorer les performances de certaines opérations mais rend la table irrécupérable  en cas d’incident ; après une opération NOLOGGING, il est souvent pertinent de réaliser une sauvegarde de la base de  données. L’ordre SQL ALTER TABLEpeut être utilisé pour modifier certaines caractéristiques du stockage de la table.  Syntaxe simplifiée  ALTER TABLE nom_table [ PCTFREE valeur ] [ PCTUSED valeur ] [ NOCOMPRESS | COMPRESS [ FOR { ALL | DIRECT_LOAD } OPERATIONS ] ] [ LOGGING | NOLOGGING ] [ clause_stockage_restreinte ] ; clause_stockage_restreinte STORAGE ( [ NEXT valeur [K|M] ] [ MAXEXTENTS { valeur | UNLIMITED } ] [ PCTINCREASE valeur ] ) L’ordre SQL ALTER TABLE n’a pas d’effet rétroactif sur le stockage déjà alloué à la table. Il n’est donc pas possible, de  cette manière, de changer la table de tablespace, de modifier l’espace initialement alloué à la table ou le remplissage  ou la compression des blocs déjà utilisés.  Les  caractéristiques  modifiées  sont  prises  en  compte  uniquement  pour  les  futures  opérations.  Plus  tard,  nous  étudierons  la  clause  MOVE  de  l’ordre  SQL  ALTER TABLE  qui  permet  de  reconstruire  physiquement  le  stockage  d’une  table. 

5. Recommandations pour le stockage des tables  a. Vue d’ensemble  La  recommandation  numéro  un  est  de  stocker  les  tables  dans  un  ou  plusieurs  tablespaces  dédiés,  de  préférence  gérés localement (c’est le cas par défaut) avec une gestion automatique de l’espace dans les segments (c’est le cas  par défaut).  Si  cette  recommandation  numéro  un  est  respectée,  vous  allez  bénéficier  de  nombreux  mécanismes  de  gestion  automatique du stockage qui permettent éventuellement de ne rien faire de plus. Dans ce cas, utilisez de préférence  des  tablespaces  gérés  localement  avec  une  gestion  automatique  de  la  taille  des  extensions  (EXTENT MANAGEMENT LOCAL AUTOALLOCATE, c’est le cas par défaut).  Néanmoins,  si  vous  le  souhaitez  ou  le  pouvez,  deux  recommandations  supplémentaires  peuvent  être  étudiées,  au  moins pour les tables les plus importantes de l’application :  ●

●

recommandation numéro deux : régler PCTFREE avec soin (voir Estimation de PCTFREE) ;  recommandation  numéro  trois : allouer  un  espace  initial  à  la  table,  adapté  à  la  volumétrie  estimée  à  une  échéance donnée, si possible lointaine (6 mois, 1 an, 2 ans ou plus). 

Si  vous  souhaitez  contrôler  plus  précisément  le  stockage  des  tables  (ou  de  certaines  tables),  vous  pouvez  utiliser  des tablespaces gérés localement avec une gestion uniforme de la taille des extensions (EXTENT MANAGEMENT LOCAL UNIFORM) et/ou spécifier avec soin l’option INITIAL de la clause STORAGE.  L’idée  est  de  choisir  des  caractéristiques  de  stockage  adaptées  à  la  nature  de  la  table  (petite,  volumineuse, 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 5-

statique,  à  croissance  régulière,  etc.)  et  d’anticiper  à  une  échéance  suffisamment  lointaine  pour  être  tranquille  pendant quelque temps, et donc avoir le temps nécessaire pour réagir si l’estimation initiale est mauvaise.  Le fait qu’une table soit stockée dans un grand nombre d’extensions ne pose pas de problème du point de  vue des performances.  Par ailleurs, il ne faut pas hésiter à dédier des tablespaces au stockage des tables volumineuses.  Dans  un  tablespace  géré  localement  avec  une  gestion  automatique  de  l’espace  dans  les  segments,  les  extensions doivent avoir une taille d’au moins 5 blocs. 

b. Estimer la volumétrie d’une table à une échéance donnée  La méthode la plus simple (et la plus pragmatique) pour estimer la volumétrie d’une table à une échéance donnée  consiste à :  ●

estimer le nombre de lignes attendues ; 

●

créer la table dans les conditions d’exploitation (taille de bloc et PCTFREE notamment) ; 

●

charger la table avec un jeu de données représentatives ; 

●

●

calculer le nombre de blocs occupés par ce jeu d’essai (par exemple à partir des statistiques de la table ou à  l’aide du package DBMS_SPACE ­ voir ci­après) ;  en déduire le nombre de blocs pour le nombre de lignes attendues (règle de trois). 

Cette  méthode  ne  donne  qu’une  estimation,  pas  un  résultat  exact  à  l’octet  près,  car  il  y  a  de  nombreuses  incertitudes :  ●

●

sur le nombre de lignes estimé à l’échéance (N +/­ 10% par exemple) ;  sur la représentativité du jeu de données, notamment sur la longueur moyenne des données saisies (le nom  du client stocké sous la forme d’un VARCHAR2(80) comprendra­t­il en moyenne 40 caractères, 50, 60 ?). 

Supposons par exemple que la table ADHERENT (schéma DIANE) ait été chargée avec 10 000 lignes et qu’elle doive en  contenir 1 000 000 à une échéance de 2 ans. Nous pouvons réaliser le calcul suivant :  SQL> EXEC dbms_stats.gather_table_stats(’DIANE’,’ADHERENT’) Procédure PL/SQL terminée avec succès. SQL> SELECT blocks FROM dba_tables 2 WHERE table_name=’ADHERENT’; BLOCKS ---------138 SQL> SELECT 138/10000*1000000 estimation FROM dual; ESTIMATION ---------13800 Le  jeu  de  données  utilise  138  blocs,  donc,  par  règle  de  trois,  nous  pouvons  estimer  que  la  table  utilisera  13 800  blocs dans deux ans.  L’utilisation du package DBMS_STATS sera présenté à la section Superviser l’espace occupé par une table.  En production, un calcul de ce genre peut être effectué à intervalles réguliers pour voir la tendance et vérifier  si les hypothèses de départ étaient bonnes. 

- 6-

© ENI Editions - All rights reserved - Algeria Educ

c. Estimation de PCTFREE  Avec calcul La valeur optimale de PCTFREE peut être estimée par la formule suivante :  PCTFREE = 100 x (1 -Ti / Tf)  Ti = taille moyenne initiale de la ligne en octets (au moment de l’insertion) ;  Tf = taille moyenne finale de la ligne en octets (après les mises à jour).  Les valeurs de Ti et Tf peuvent être estimées à partir des statistiques de la table (AVG_ROW_LEN). Cette formule est  surtout  destinée  à  calculer  la  valeur  de PCTFREE concernant les tables pour lesquelles, la taille des lignes insérées  initialement  n’est  pas  représentative  de  la  taille  finale  de  la  ligne  après  modification(s).  Pour  les  autres  tables,  l’estimation sans calcul, présentée ci­après, peut être utilisée.  Sans calcul Pour  une  table  "statique"  ou  faisant  uniquement  l’objet  d’insertions, mettre un  PCTFREE faible pour obtenir un bon  remplissage des blocs (0 à 5). Pour une table faisant l’objet d’insertion et de mises à jour, mettre un PCTFREE plus  élevé pour éviter les phénomènes de migration (10 à 50 en fonction du risque que les mises à jour fassent grossir  plus ou moins les lignes). 

6. Surveiller l’utilisation d’une table  En version 9, Oracle a introduit une fonctionnalité permettant de mettre une table "sous surveillance". Dans ce mode,  Oracle trace le nombre approximatif d’ordres SQL INSERT, UPDATE et DELETE exécutés sur la table.  En version 9, cette fonctionnalité devait être activée explicitement ; depuis la version 10, les tables sont, par défaut,  sous surveillance (sauf si le paramètre STATISTICS_LEVEL est égal à BASIC, ce qui est déconseillé).  Ce  mécanisme  de  surveillance  est  avant  tout  destiné  à  la  fonctionnalité  de  calcul  automatique  des  statistiques ; les  informations ainsi collectées permettent à Oracle de déterminer les tables dont les statistiques ne sont plus à jour.  Ce mécanisme de surveillance peut aussi être utilisé pour analyser l’activité sur les tables et identifier les tables les  plus  sollicitées  en  mise  à  jour ; ce  sont  les  tables  sur  lesquelles  vous  devez  plus  particulièrement  porter  votre  attention en ce qui concerne le stockage (réglage de PCTFREE notamment).  Les  informations  sur  les  tables  surveillées  peuvent  être  consultées  dans  la  vue  DBA_TAB_ MODIFICATIONS  (et  consœ urs).  Les principales colonnes de la vue sont les suivantes :  TABLE_OWNER  propriétaire de la table.  TABLE_NAME  nom de la table.  INSERTS  nombre approximatif de lignes insérées.  UPDATES  nombre approximatif de lignes modifiées.  DELETES  nombre approximatif de lignes supprimées.  TIMESTAMP  date/heure de la dernière mise à jour de la statistique. 

openmirrors.com

  © ENI Editions - All rights reserved - Algeria Educ

- 7-

TRUNCATED  indication pour savoir si la table a été tronquée (YES ou NO).  Les  statistiques  sur  l’utilisation  d’une  table  ne  sont  pas  déversées  en  temps  réel  dans  le  dictionnaire.  Le  délai  annoncé  est  entre  quelques  secondes  et  plusieurs  heures.  La  colonne  TIMESTAMP  de  la  vue  DBA_TAB_MODIFICATIONS  permet de connaître la fraîcheur de l’information.  Au besoin, la procédure FLUSH_DATABASE_MONITORING_INFO du packageDBMS_ STATS peut être utilisée pour forcer la mise  à jour immédiate du dictionnaire.  Il  faut  bien  noter  que  les  statistiques  de  surveillance  sont  supprimées  lors  de  la  génération  des  statistiques.  Les  statistiques de surveillance sont donc collectées et cumulées depuis la dernière génération de statistiques sur la table  (voir la colonne LAST_ANALYZED de la vue DBA_TABLES).  Pour  une  bonne  analyse,  il  est  important  de  réaliser  des  relevés  périodiques  afin  de  voir  l’évolution  de  l’activité  et  identifier d’éventuelles périodes de pointes. 

7. Superviser l’espace occupé par une table  a. Vue d’ensemble  Les vues DBA_SEGMENTS  et DBA_EXTENTS présentées au chapitre Gestion des tablespaces et des fichiers de données  permettent de voir l’espace global alloué à la table, mais elles ne donnent pas d’informations sur le nombre de blocs  réellement utilisés.  Pour chaque table (et plus généralement chaque segment), Oracle connaît le dernier bloc utilisé par la table : c’est la  high water mark (HWM ­ "ligne de plus hautes eaux").  La HWM augmente lors des insertions mais ne diminue pas lors des suppressions : 

  La HWM permet donc de connaître le nombre total maximum de blocs utilisés par la table dans toute son existence,  mais pas le nombre de blocs actuellement utilisés, ni leur remplissage.  La HWM marque pour Oracle l’emplacement du dernier bloc où il est susceptible de trouver une ligne ; au­delà de la  HWM, une seule chose est sûre, il n’y a pas de ligne. Lorsque Oracle réalise un parcours complet de la table, il ne  parcourt pas tous les blocs alloués à la table mais uniquement ceux situés sous la HWM.  Pour obtenir des informations plus détaillées sur le stockage d’une table, vous pouvez utiliser le package DBMS_SPACE.  Ce dernier propose plusieurs procédures qui permettent notamment de calculer des informations sur l’espace libre et  l’espace utilisé à l’intérieur d’un segment.  Par  ailleurs,  pour  les  besoins  de  l’optimiseur,  Oracle  calcule  périodiquement  des  statistiques  sur  les  tables  (et  les  index),  à  l’aide  du  package  DBMS_STATS ; certaines  de  ces  statistiques  donnent  des  informations  relatives  au  stockage.  Pour obtenir des informations plus détaillées sur le stockage d’une table, vous pouvez utiliser les statistiques de la  table, générées par le package DBMS_STATS ou calculer des informations à l’aide du package DBMS_SPACE. 

b. Le package DBMS_SPACE  Le package  DBMS_SPACE  propose  plusieurs  procédures  qui  peuvent  être  utilisées  pour  superviser  le  stockage  d’une  table (plus généralement d’un segment) :  FREE_BLOCKS  informations sur les blocs libres dans un segment dont l’espace est géré manuellement.  SPACE_USAGE  informations sur l’occupation des blocs dans un segment dont l’espace est géré automatiquement. 

- 8-

© ENI Editions - All rights reserved - Algeria Educ

UNUSED_SPACE  informations sur les blocs inutilisés d’un segment.  Le package  DBMS_SPACE  possède  d’autres procédures ou fonctions qui permettent d’estimer la taille d’une  table  ou  d’un  index  ou  la  tendance  de  croissance  d’un  segment.  Ces  procédures  et  fonctions,  plus  complexes  à  utiliser,  ne  sont pas présentées dans cet ouvrage. Par contre, nous présenterons leur utilisation à travers l’interface graphique  du Database Control.  Pour plus d’informations sur le package DBMS_SPACE,  reportez­vous à la documentation PL/SQL Packages and Types  Reference.  Exemple :  SQL> SET SERVEROUTPUT ON SQL> DECLARE 2 v_unformatted_blocks NUMBER; 3 v_unformatted_bytes NUMBER; 4 v_fs1_blocks NUMBER; 5 v_fs1_bytes NUMBER; 6 v_fs2_blocks NUMBER; 7 v_fs2_bytes NUMBER; 8 v_fs3_blocks NUMBER; 9 v_fs3_bytes NUMBER; 10 v_fs4_blocks NUMBER; 11 v_fs4_bytes NUMBER; 12 v_full_blocks NUMBER; 13 v_full_bytes NUMBER; 14 PROCEDURE p(v_texte VARCHAR2) IS 15 BEGIN 16 dbms_output.put_line(v_texte); 17 END; 18 BEGIN 19 dbms_space.space_usage 20 ( 21 segment_owner => ’DIANE’, 22 segment_name => ’ADHERENT’, 23 segment_type => ’TABLE’, 24 unformatted_blocks => v_unformatted_blocks, 25 unformatted_bytes => v_unformatted_bytes, 26 fs1_blocks => v_fs1_blocks, 27 fs1_bytes => v_fs1_bytes, 28 fs2_blocks => v_fs2_blocks, 29 fs2_bytes => v_fs2_bytes, 30 fs3_blocks => v_fs3_blocks, 31 fs3_bytes => v_fs3_bytes, 32 fs4_blocks => v_fs4_blocks, 33 fs4_bytes => v_fs4_bytes, 34 full_blocks => v_full_blocks, 35 full_bytes => v_full_bytes 36 ); 37 p(’Blocs :’); 38 p(’. Pleins = ’||v_full_blocks); 39 p(’. 0 à 25% d’’espace libre = ’||v_fs1_blocks); 40 p(’. 25 à 50% d’’espace libre = ’||v_fs2_blocks); 41 p(’. 50 à 75% d’’espace libre = ’||v_fs3_blocks); 42 p(’. 75 à 100% d’’espace libre = ’||v_fs4_blocks); 43 p(’. Non formatés = ’||v_unformatted_blocks); 44 END; 45 / Blocs : . Pleins = 128 . 0 à 25% d’espace libre = 0 . 25 à 50% d’espace libre = 40 . 50 à 75% d’espace libre = 4 . 75 à 100% d’espace libre = 33 . Non formatés = 0 Procédure PL/SQL terminée avec succès.

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 9-

SQL> DECLARE 2 v_total_blocks NUMBER; 3 v_total_bytes NUMBER; 4 v_unused_blocks NUMBER; 5 v_unused_bytes NUMBER; 6 v_last_extent_file NUMBER; 7 v_last_extent_block NUMBER; 8 v_last_used_block NUMBER; 9 PROCEDURE p(v_texte VARCHAR2) IS 10 BEGIN 11 dbms_output.put_line(v_texte); 12 END; 13 BEGIN 14 dbms_space.unused_space ( 15 segment_owner => ’DIANE’, 16 segment_name => ’ADHERENT’, 17 segment_type => ’TABLE’, 18 total_blocks => v_total_blocks, 19 total_bytes => v_total_bytes, 20 unused_blocks => v_unused_blocks, 21 unused_bytes => v_unused_bytes, 22 last_used_extent_file_id => v_last_extent_file, 23 last_used_extent_block_id => v_last_extent_block, 24 last_used_block => v_last_used_block 25 ); 26 p(’Blocs :’); 27 p(’. Total = ’||v_total_blocks); 28 p(’. Inutilisés = ’||v_unused_blocks); 29 p(’. Utilisés = ’||(v_total_blocks-v_unused_blocks)); 30 END; 31 / Blocs : . Total = 224 . Inutilisés = 7 . Utilisés = 217 Procédure PL/SQL terminée avec succès. SQL> SELECT blocks FROM dba_segments 2 WHERE segment_name=’ADHERENT’ AND owner=’DIANE’; BLOCKS -----------224 Sur cet exemple, nous voyons que la table ADHERENT a 224 blocs alloués. Sur ces 224 blocs, 217 sont utilisés (c’est la  HWM) et 7 sont inutilisés (jamais aucun ligne insérée à l’intérieur). Sur les blocs utilisés, il y en a 128 qui sont pleins,  40 qui ont entre 25 et 50% d’espace libre, 4 qui ont entre 50 et 75% d’espace libres et 33 qui ont entre 75 et 100%  d’espace  libre,  soit  un  total  de  205  blocs.  Les  12  blocs  manquants  pour  arriver  à  217  sont  des  blocs  de  bitmap  utilisés pour la gestion automatique (ils ne sont pas comptabilisés par la procédure SPACE_USAGE). 

c. Les statistiques sur une table  La procédure GATHER_TABLE_STATS du package DBMS_STATS permet de calculer des statistiques sur une table.  Cette procédure a deux paramètres obligatoires en entrée :  ownname  Nom du schéma propriétaire de la table.  tabname  Nom de la table.  Exemple :  EXECUTE dbms_stats.gather_table_stats(’DIANE’,’ADHERENT’) La  procédure  GATHER_TABLE_STATS  a  beaucoup  d’autres  paramètres  dont  la  valeur  par  défaut  est  généralement  - 10 -

© ENI Editions - All rights reserved - Algeria Educ

adaptée.  Au point Les statistiques et l’optimiseur  Oracle,  nous  verrons  que  les  statistiques  sont  calculées  automatiquement  par Oracle à intervalles réguliers. En temps normal, il n’est donc pas nécessaire d’utiliser cette procédure. Générer  manuellement  des  statistiques  peut,  par  contre,  s’avérer  utile  si  vous  venez  de  créer  et  de  charger  une  table,  ou  après une mise à jour massive des données d’une table (insertion, modification, suppression).  Le  calcul  de  statistiques  est  effectué  sur  un  échantillon  des  données.  La  taille  de  l’échantillon  est  choisie  automatiquement  par  Oracle  en  fonction  des  caractéristiques  de  la  table  (au  besoin,  la  taille  de  l’échantillon  peut  être spécifiée grâce au paramètre estimate_percent).  Historiquement,  les  statistiques  peuvent  aussi  être  calculées  à  l’aide  des  clauses  COMPUTE  ou ESTIMATE  de  l’ordre  SQL  ANALYZE TABLE.  Cette  possibilité  est  maintenue  pour  des  raisons  de  compatibilité  ascendante.  Pour calculer les statistiques sur les tables et les index, il faut utiliser le package DBMS_STATS (depuis Oracle8i).  Les statistiques d’une table peuvent être consultées dans la vueDBA_TABLES (et "consœ urs") :  NUM_ROWS  Nombre de lignes dans la table.  BLOCKS  Nombre de blocs sous la High Water Mark (HWM).  AVG_ROW_LEN  Longueur moyenne d’une ligne, y compris les informations d’en­tête.  SAMPLE_SIZE  Nombre de lignes dans l’échantillon utilisé pour le calcul des statistiques.  LAST_ANALYZED  Date/heure de la dernière analyse de la table. 

La  valeur  BLOCKS  est  toujours  exacte,  même  si  les  statistiques  ne  sont  pas  calculées  sur  la  totalité  de  la  table.  Exemple :  SQL> EXEC dbms_stats.gather_table_stats(’DIANE’,’ADHERENT’) Procédure PL/SQL terminée avec succès. SQL> SELECT num_rows,blocks,avg_row_len,sample_size, 2 TO_CHAR(last_analyzed,’DD/MM HH24:MI’) last_analyzed 3 FROM dba_tables WHERE table_name=’ADHERENT’ and owner=’DIANE’; NUM_ROWS BLOCKS AVG_ROW_LEN SAMPLE_SIZE LAST_ANALYZED ---------- ---------- ----------- ----------- ------------11488 217 91 11488 20/07 15:47 Nous retrouvons les 217 blocs utilisés, calculés à l’aide du package DBMS_SPACE. 

d. Problèmes possibles sur le stockage  Les problèmes possibles sur le stockage d’une table sont les suivants :  ●

espace inutilisé alloué à une table ; 

●

faible taux d’occupation moyen des blocs. 

Espace inutilisé alloué à une table

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 11 -

Il  y  a  de  l’espace  inutilisé  alloué  à  la  table  si  le  nombre  de  blocs  occupés  (sous  la  HWM)  est  faible  par  rapport  au  nombre de blocs alloués, et si la table ne va plus grossir (ou peu).  Le nombre de blocs occupés est donné par la valeur de la colonne BLOCKS de la vue DBA_TABLES (ou par un calcul à  l’aide  du  package  DBMS_SPACE)  et  le  nombre  de  blocs  alloués  par  la  valeur  de  la  colonne  BLOCKS  de  la  vue  DBA_SEGMENTS.  Exemple :  SQL> SELECT t.blocks "occupés",s.blocks "alloués" 2 FROM dba_tables t, dba_segments s 3 WHERE s.segment_name=t.table_name 4 AND s.owner=t.owner 5 AND t.table_name=’ADHERENT’ AND t.owner=’DIANE’; occupés alloués ---------- ---------217 224 Ce premier problème n’a pas d’incidence sur les performances (les blocs au­delà de la HWM ne sont jamais lus) ; il  conduit juste à un gaspillage d’espace disque.  Faible taux d’occupation moyen des blocs Pour les tables dont l’espace est géré automatiquement, le taux d’occupation moyen des blocs peut être analysé à  l’aide du résultat donné par la procédure SPACE_USAGE du package DBMS_SPACE.  Exemple :  Blocs : . Pleins . 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  sous­requête,  il  est  possible  de  lister  les  lignes  proprement  dites.  Les  résultats  s’accumulent  dans  la  table ; lors d’une nouvelle analyse d’une table préalablement analysée, il convient dont de supprimer de CHAINED_ROWS  l’ancien résultat ou d’utiliser la colonne ANALYZE_TIMESTAMP pour extraire le résultat.  Pour savoir s’il s’agit d’un problème de chaînage ou de migration, il faut interroger la ligne. Si la ligne est plus courte  que  la  taille  du  bloc,  il  s’agit  d’un  problème  de  migration  (la  ligne  pourrait  tenir  dans  un  bloc) ; si  la  ligne  est  plus  longue  que  la  taille  du  bloc,  il  s’agit  d’un  problème  de  chaînage.  La  statistique AVG_ROW_LEN  dans DBA_TABLES  donne  une  indication  a  priori ; si  la  longueur  moyenne  des  lignes  est  assez  largement  inférieure  à  la  taille  de  bloc,  il  s’agit  sûrement d’un problème de migration.  Déterminer à partir de quel pourcentage de lignes chaînées ou migrées il faut agir n’est pas simple. Le pourcentage en  soi  n’est  pas  suffisant ; cela  dépend  aussi  de  l’activité  qui  existe  sur  les  lignes  en  question.  S’il  y  a  90  %  de  lignes  migrées  ou  chaînées  mais  que  ces  lignes  ne  sont  jamais  interrogées,  il  n’y  a  pas  de  problème  de  performance ; à  l’inverse,  s’il  n’y  a  que  1  %  de  lignes  migrées  ou  chaînées  mais  que  ces  lignes  soient  utilisées  dans  toutes  les  requêtes, il risque d’y avoir un problème de performance. 

9. Réorganiser le stockage d’une table  a. Vue d’ensemble  Les besoins de réorganisation d’une table sont variés :  ●

libérer de l’espace libre au­dessus de la HWM ; 

●

améliorer le taux de remplissage des blocs ; 

●

corriger un problème de migration ; 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 13 -

●

réorganiser  plus  globalement  le  stockage  de  la  table : changement  de  tablespace,  réduction  du  nombre  d’extensions, changement de PCTFREE, etc. 

Libérer de l’espace situé au­dessus de la HWM permet de récupérer de l’espace alloué à la table mais jamais utilisé  (et estimé jamais utilisable).  Améliorer le taux de remplissage des blocs permet aussi éventuellement de libérer de l’espace inutilisé (l’espace libre  des blocs), situé cette fois au­dessous de la HWM.  Plusieurs techniques sont à notre disposition pour réorganiser le stockage d’une table :  ●

ordre SQL ALTER TABLE ... DEALLOCATE UNUSED ; 

●

recréer la table / des lignes de la table ; 

●

export/import ; 

●

ordre SQL ALTER TABLE ... SHRINK SPACE ; 

●

ordre SQL ALTER TABLE ... MOVE. 

Le tableau suivant résume les techniques envisageables (√) et indique lesquelles sont les mieux adaptées (☺) à tel  ou tel besoin :  DEALLOCATE 

Recréer 

Export/  Import 

SHRINK 

MOVE 

☺ 

√ 

√ 

√ 

√ 

Améliorer le taux de  remplissage des blocs 

√ 

√ 

☺ 

☺ 

Corriger un problème  de migration 

☺ 

√ 

☺ 

Réorganisation plus  globale 

√ 

√ 

☺ 

Libérer de l’espace au­ dessus de la HWM 

À l’exception de l’ordre SQL ALTER TABLE ... DEALLOCATE UNUSED, les techniques citées peuvent a priori être utilisés  indifféremment  pour  régler  les  différents  problèmes ; néanmoins,  certaines  techniques  sont  mieux  adaptées  que  d’autres à tel ou tel besoin.  Historiquement, l’export/import est la technique de base pour les réorganisations un peu massives ; c’est d’ailleurs  toujours la bonne technique pour une réorganisation complète de la base, notamment en cas de changement de la  taille du bloc.  Pour le reste, les ordres SQL ALTER TABLE ... MOVE (depuis la 8i) et ALTER TABLE ... SHRINK SPACE (depuis la 10)  sont a priori les bons outils pour "reconstruire" une table. 

b. L’ordre SQL ALTER TABLE ... DEALLOCATE UNUSED  L’ordre SQL ALTER TABLE ... DEALLOCATE UNUSED permet de libérer l’espace d’une table situé au­dessus de la HWM.  Syntaxe  ALTER TABLE nom_table DEALLOCATE UNUSED [ KEEP valeur [K|M] ] ; Exemple :  ALTER TABLE adherent DEALLOCATE UNUSED; ALTER TABLE adherent DEALLOCATE UNUSED KEEP 0; ALTER TABLE adherent DEALLOCATE UNUSED KEEP 1M; L’option KEEP indique l’espace à conserver au­dessus de la HWM. 

- 14 -

© ENI Editions - All rights reserved - Algeria Educ

Sans clause KEEP, la taille initiale de la table est préservée : l’ordre ne libérera pas d’espace si la HWM est inférieure  à la taille initiale de la table (valeur de la colonne INITIAL_EXTENT de la vue DBA_SEGMENTS).  Avec la clause KEEP, l’espace spécifié est conservé (éventuellement aucun avec KEEP 0) et la taille initiale de la table,  éventuellement ajustée dans le dictionnaire de données.  Par  ailleurs,  lorsque  la  table  est  stockée  dans  un  tablespace  géré  localement,  avec  une  gestion  uniforme  des  extensions, Oracle ne libérera que des extensions entières ; une extension ne peut pas être "coupée" en deux. Si la  table est stockée dans un tablespace géré localement, avec une gestion automatique des extensions, Oracle peut  "couper" une extension en tenant compte des règles internes qu’il applique sur la taille des extensions.  L’espace libéré est rendu disponible pour d’autres segments (vue DBA_FREE_SPACE).  Cet  ordre  ne  peut  pas  être  utilisé  pour  libérer  de  l’espace  au­dessous  de  la  HWM  (espace  potentiel  libre  suite à des suppressions de lignes, par exemple). 

c. Recréer la table ou des lignes de la table  Supprimer la table puis la récréer permet évidemment d’en réorganiser le stockage.  Au préalable, il faudra sauvegarder les données dans une table de travail (ordre SQL CREATE TABLE ... AS SELECT).  Cette  méthode  présente  un  inconvénient  majeur : les  objets  dépendants  sont  supprimés  (triggers,  contraintes,  privilèges, index) ou invalidés (procédures stockées, vues). Il faut donc bien penser à tout recréer avec la table.  Exemple :  -- créer une table de travail avec les bonnes clauses de stockage CREATE TABLE temp TABLESPACE ... PCTFREE ... STORAGE ... AS SELECT * FROM adherent; DROP TABLE adherent; RENAME temp TO adherent; -- recréer les objets dépendants La  table  étant  recréée  avec  de  bonnes  clauses  de  stockage,  cette  variante  peut  être  utilisée  pour  réorganiser  complètement  le  stockage  de  la  table,  améliorer  le  taux  de  remplissage  des  blocs,  résoudre  un  problème  de  migration.  Par  contre,  il  faut  penser  à  recréer  tous  les  objets  dépendants  et  remettre  les  droits.  De  plus,  le  traitement peut être long sur une table volumineuse.  Une  première  variante  possible  consiste  à  ne  pas  supprimer  la  table  mais  à  la  tronquer  (ordre  SQL  TRUNCATE TABLE) ; dans ce cas, les objets dépendants sont préservés.  Exemple :  CREATE TABLE temp AS SELECT * FROM adherent; TRUNCATE TABLE adherent; INSERT INTO adherent SELECT * FROM temp; Cette variante offre moins de possibilités pour la réorganisation puisque la table n’est pas recréée ; néanmoins, elle  permet  d’améliorer  le  taux  de  remplissage  des  blocs  (de  libérer  de  l’espace  sous  la  HWM)  et  de  résoudre  un  problème de migration. La table n’étant pas supprimée, il n’y a pas de difficulté avec les objets dépendants.  Par  contre,  il  n’est  pas  possible  de  tronquer  une  table  qui  possède  une  contrainte  de  clé  primaire  référencée  par  ailleurs ; il faut au préalable désactiver les contraintes de clé étrangère concernées. De plus, lors de l’insertion, les  contraintes  d’intégrités  sont  vérifiées  et  les  triggers  sont  déclenchés,  ce  qui  peut  aussi  poser  des  problèmes : là  encore, il convient de désactiver les contraintes et/ou les triggers qui posent des difficultés.  Une autre variante, utilisable pour corriger un problème de migration sur un petit nombre de lignes, consiste à ne  supprimer et recréer que les lignes fautives. La table n’étant pas supprimée, il n’y a pas de problème avec les objets  dépendants. Par contre, là encore, cette méthode peut poser des difficultés avec les contraintes de clé étrangère et  les triggers.  Exemple :  CREATE TABLE temp AS SELECT * FROM adherent WHERE ...; DELETE FROM TABLE adherent WHERE ...; INSERT INTO adherent SELECT * FROM temp; Pour ces différentes variantes, les outils d’export/import peuvent être utilisés pour sauvegarder les données puis les 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 15 -

réinsérer.  Dans  la  pratique,  aucune  de  ces  différentes  variantes  n’est  vraiment  simple  à  mettre  en  œ uvre.  De  plus,  avec  les  deux premières variantes, la table n’est pas disponible pendant la réorganisation. 

d. L’ordre SQL ALTER TABLE ... SHRINK SPACE  L’ordre SQL ALTER TABLE ... SHRINK SPACE permet de compacter les lignes d’une table, mais uniquement pour une  table stockée dans un tablespace géré localement avec une gestion automatique de l’espace dans les segments. Par  défaut, Oracle compacte aussi le segment, ajuste la HWM et libère l’espace ainsi récupéré.  Syntaxe  ALTER TABLE nom_table SHRINK SPACE [COMPACT] [CASCADE] ; Avec  l’option  COMPACT,  Oracle  se  contente  de  compacter  les  lignes,  mais  sans  ajuster  la HWM  ni  libérer  d’espace.  L’exécution ultérieure d’un autre ordre SQL ALTER TABLE ... SHRINK SPACE permettra de terminer l’opération.  L’option  CASCADE  permet  de  réaliser  la  même  opération  sur  les  segments  dépendants  de  la  table,  notamment  les  index.  Cette opération nécessite un déplacement des lignes et donc une modification du  ROWID des lignes déplacées. Par  défaut,  un  tel  déplacement  n’est  pas  autorisé.  Pour  autoriser  le  déplacement  des  lignes  de  la  table,  vous  pouvez  exécuter  l’ordre  SQL  ALTER TABLE nom_table ENABLE ROW MOVEMENT.  Lors  du  déplacement  des  lignes  et  de  la  modification du ROWID, Oracle met à jour les index.  L’opération de SHRINK peut être effectuée en ligne et des mises à jour parallèles sont possibles ; un verrou exclusif  est posé sur la table uniquement au moment du compactage du segment proprement dit (déplacement de la HWM et  libération de l’espace récupéré).  Le  compactage  du  segment  peut  poser  des  problèmes  si  des  longues  requêtes  de  lecture  sont  en  cours  sur  la  table ; c’est la raison pour laquelle il est possible de dissocier les deux phases du traitement.  Exemple  SQL> -- situation de départ SQL> @dbms_space TEST Blocs : . Pleins = . 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 ci­après.  DBA_TABLES TABLE_NAME 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 19 -

Nom de la table.  OWNER  Propriétaire de la table.  TABLESPACE_NAME  Nom du tablespace dans lequel la table est stockée.  PCT_FREE  Valeur du PCTFREE.  NUM_ROWS  Nombre de lignes dans la table.  BLOCKS  Nombre de blocs sous la HWM.  AVG_ROW_LEN  Longueur moyenne d’une ligne en octets, en tenant compte des informations de contrôle.  SAMPLE_SIZE  Taille de l’échantillon utilisé lors du calcul des statistiques.  LAST_ANALYZED  Date et heure de la dernière analyse réalisée sur la table.  LOGGING  Indique si le mode LOGGING est actif ou non pour la table (YES ou NO).  COMPRESSION  Indique si la table est compressée (DISABLED ou ENABLED).  TEMPORARY  Indique s’il s’agit d’une table temporaire (Y ou N).  ROW_MOVEMENT  Indique si le déplacement de lignes est autorisé (ENABLED ou DISABLED).  DBA_TAB_COLUMNS TABLE_NAME  Nom de la table.  OWNER  Propriétaire de la table.  COLUMN_NAME 

- 20 -

© ENI Editions - All rights reserved - Algeria Educ

Nom de la colonne.  DATA_TYPE  Type de données.  DATA_LENGTH  Longueur.  DATA_PRECISION  Précision.  DATA_SCALE  Échelle.  NULLABLE  Indique si la colonne accepte les valeurs NULL (Y ou N).  COLUMN_ID  Numéro de la colonne.  DATA_DEFAULT  Valeur par défaut de la colonne.  NUM_DISTINCT *  Nombre de valeurs distinctes dans la colonne.  NUM_NULLS *  Nombre de valeurs NULL dans la colonne.  AVG_COL_LEN *  Longueur moyenne de la colonne.  LAST_ANALYZED *  Taille de l’échantillon utilisé lors du calcul des statistiques.  SAMPLE_SIZE *  Date et heure de la dernière analyse réalisée sur la table.  * Statistiques sur les colonnes, calculées par défaut lorsque les statistiques sont générées sur la table.  DBA_TAB_MODIFICATIONS TABLE_OWNER  Propriétaire de la table.  TABLE_NAME  Nom de la table.  INSERTS 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 21 -

Nombre approximatif de lignes insérées.  UPDATES  Nombre approximatif de lignes modifiées.  DELETES  Nombre approximatif de lignes supprimées.  TIMESTAMP  Date/heure de la dernière mise à jour de la statistique.  TRUNCATED  Indique si la table a été tronquée (YES ou NO). 

- 22 -

© ENI Editions - All rights reserved - Algeria Educ

Gestion des index B­tree  1. Vue d’ensemble  Un index est une structure définie sur une ou plusieurs colonnes d’une table ; la (les) colonne(s) constitue(nt) la clé  de l’index.  L’index  permet  un  accès  rapide  aux  lignes  de  la  table  lors  d’une  recherche  basée  sur  la  clé  de  l’index.  La  notion  d’index est analogue à celle de l’index d’un livre : pour rechercher un mot dans un livre, il est plus rapide de regarder  d’abord dans l’index, ce dernier donnant les numéros des pages qui contiennent le mot. Un index est physiquement  et logiquement indépendant de la table. Il peut être créé/supprimé sans affecter la table de base (sauf impact sur les  performances lorsque l’index est supprimé). Un index nécessite son propre espace de stockage.  Les index sont automatiquement actualisés et utilisés par Oracle :  ●

utilisés lors des recherches si une clé d’index est mentionnée dans la clause WHERE d’une requête ; 

●

actualisés à chaque mise à jour (INSERT, UPDATE, DELETE). 

La  présence  ou  l’absence d’un  index  est  complètement  transparente  pour  l’application ; c’est  Oracle  qui  utilise  (ou  non) les index automatiquement.  La maintenance des index dégrade les performances des mises à jour.  Un index peut être unique ou non unique :  ●

Unique: une valeur de la clé d’index n’est présente qu’une fois dans la table. 

●

Non unique : une valeur de la clé d’index peut être présente plusieurs fois dans la table. 

Oracle préconise de ne pas créer d’index unique explicitement mais de définir des contraintes d’intégrité (PRIMARY KEY  ou  UNIQUE)  pour  lesquelles  Oracle  crée  automatiquement  des  index  uniques.  Les  index  non  uniques,  par  contre,  doivent être créés explicitement.  Un index peut être composé (concaténé). Dans ce cas, la clé d’index contient plusieurs colonnes de la table ; elles ne  sont pas toujours adjacentes dans la table, ni forcément placées dans le même ordre que dans la table.  Les  valeurs  NULL  ne  sont  pas  stockées  dans  les  index  B­tree  et  ne  sont  donc  pas  prises  en  compte  vis­à­vis  de  l’unicité : deux lignes de la table peuvent avoir la valeur NULL dans la colonne concernée. 

2. Structure d’un index B­tree  Structure générale

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

  Les données sont stockées dans des blocs Oracle.  Les blocs branches (branch blocks) contiennent des données qui pointent vers des blocs de niveau inférieur. Les blocs  branches  permettent  d’assurer  un  aiguillage  d’un  bloc  racine  vers  les  blocs  feuilles,  en  éliminant  des  branches  à  chaque niveau.  Les blocs feuilles (leaf blocks) contiennent les différentes valeurs de la clé d’index avec les ROWID des lignes de la table  correspondante. Pour un index unique, il existe un seul ROWID par valeur de clé ; pour un index non unique, plusieurs  ROWID sont possibles pour chaque valeur de clé. Les blocs feuilles pointent vers les lignes de la table.  Lorsque  l’index  est  utilisé  pour  rechercher  une  valeur  de  clé,  le  bloc  racine  est  lu,  puis  le  bloc  feuille  de  niveau  inférieur  correspondant  à  la  branche  qui  contient  la  valeur  de  clé  est  lu  à  son  tour,  et  ainsi  de  suite  jusqu’au  bloc  feuille qui contient la valeur de clé ; associé à cette valeur de clé, Oracle va trouver le(s) ROWID(s) de la ou les lignes  qui contiennent la valeur de la clé et pouvoir ainsi les lire directement dans la table.  Les blocs feuilles sont doublement chaînés pour faciliter le parcours de l’index.  Les valeurs de clé NULL ne sont pas présentes dans l’index.  Dans les blocs feuilles d’un index non unique, les données sont triées sur la clé puis sur le ROWID ; la valeur de la clé  est répétée à chaque fois.  Structure d’un bloc À l’image  de  la  table,  un  bloc  d’index comprend les données proprement dites et des informations de contrôle (en­ tête de bloc, en­tête de ligne, etc.).  Le  remplissage  du  bloc,  à  la  création  de  l’index  uniquement,  peut  être  contrôlé  par  le  paramètrePCTFREE.  Le  paramètre PCTFREE est donc important lors de la création d’un index sur une colonne non vide. Dans les autres cas,  ou pour la suite de la vie de l’index, le paramètre n’est pas utilisé.  Il n’y a pas de PCTUSED pour les index. 

3. Avantages et inconvénients des index B­tree  Avantages L’index améliore la performance des requêtes (SELECT, UDATE  et DELETE) qui utilisent la clé de l’index dans la clause  WHERE.  L’arbre  est  maintenu  équilibré  par  Oracle.  Dans  "B­tree",  "B"  signifie  balanced  (balancé),  c’est­à­dire  qu’Oracle  s’arrange pour maintenir son arbre équilibré au fur et à mesure des mises à jour de l’index. Pour cela, Oracle peut  couper des blocs en cas de besoin (notion de split).  En conséquence, toutes les valeurs de la clé dans les blocs feuilles sont situées à la même profondeur de l’arbre et  donc  accessibles  en  parcourant  le  même  nombre  de  blocs.  La  recherche  de  n’importe  quelle  valeur  de  clé  prend  toujours à peu près le même temps.  Pourquoi un index B­tree est­il performant ?  Prenons l’exemple d’un index sur une date : 

- 2-

© ENI Editions - All rights reserved - Algeria Educ

●

●

La longueur d’une ligne de l’index est égale à 8 octets (longueur du type DATE) + 6 octets (longueur du ROWID)  + quelques octets pour les informations de contrôle (arrondi à 6 octets) = 20 octets.  Avec  une  taille  de  bloc  (DB_BLOCK_SIZE)  de  8  Ko,  l’espace  disponible  dans  le  bloc  est  égal  à  8  192  octets  ­ taille de l’en­tête (entre 100 et 200 octets, prenons 192 octets pour notre exemple) = 8 000 octets, rempli à  90 % = 7 200 octets. 

●

Un bloc peut donc stocker environ 7 200 / 20 = 360 clés. 

●

Un arbre d’une profondeur de 3 peut donc gérer 360 x 360 x 360 = 466 millions de clés. 

●

Pour  retrouver  une  valeur  parmi  les  466  millions,  3  entrées/sorties  sont  suffisantes  dans  l’index  plus  une  entrée/sortie dans la table afin de lire chaque ligne. 

De plus, si les colonnes utilisées dans les différentes clauses de la requête sont toutes présentes dans l’index, Oracle  n’a pas besoin d’accéder à la table. Si un index composé existe sur les colonnes (NOM,PRENOM) de la table ADHERENT, la  requête suivante n’accède pas à la table :  SELECT nom, prenom FROM adherent WHERE nom = ’HEURTEL’; Inconvénients Le premier inconvénient d’un index est qu’il nécessite un volume de stockage important.Le second inconvénient d’un  index est qu’il dégrade les performances des mises à jour. Pour des mises à jour unitaires, cela ne devient sensible  que si la table comprend un grand nombre d’index ; pour une mise à jour massive, cette dégradation est sensible dès  l’existence  du  premier  index.  Ces  deux  inconvénients  sont  deux  bonnes  raisons  pour  ne  pas  indexer  toutes  les  colonnes d’une table. 

4. Directives pour la création des index B­tree  a. Principes généraux  Les  colonnes  candidates  à  l’indexation  sont  les  colonnes  fréquemment  présentes  dans  les  clauses WHERE,  comme  critère de sélection ou de jointure.  En complément, il faut s’assurer que les requêtes correspondantes sont sélectives et ramènent moins de 5 à 10 %  des lignes de la table. Cela implique donc, que les valeurs de la colonne soient relativement uniques (beaucoup de  valeurs distinctes), et que les conditions qui les utilisent soient elles­mêmes sélectives. Il ne faut donc pas indexer  les colonnes ayant peu de valeurs distinctes (la colonne sexe par exemple).  Il est inutile d’indexer les petites tables.  Pour trouver les bonnes colonnes candidates à l’indexation, il faut analyser les requêtes SELECT, UPDATE et DELETE,  et rechercher les colonnes les plus fréquemment utilisées dans les clauses WHERE (critère de sélection et jointure).  La  performance  d’un index dépend de sa sélectivité intrinsèque et de la sélectivité des requêtes qui l’utilisent. La  sélectivité  peut  être  définie  comme,  le  nombre  moyen  de  lignes  ramenées  par  une  requête  divisé  par  le  nombre  total de lignes.  Prenons  l’exemple  de  la  table  ADHERENT  comprenant  100  000  personnes  avec  une  répartition  homogène  homme/femme. Considérons les clauses WHERE suivantes :  Clause WHERE 

Sélectivité 

WHERE numero =12345 

1 / 100 000 = 0,001 % 

WHERE numero BETWEEN 1 AND 20000 

20 000 / 100 000 = 20 % 

WHERE sexe = ’F’ 

50 000 / 100 000 = 50 % 

Ces exemples montrent que la colonne NUMERO est intrinsèquement sélective mais que certaines requêtes basées  sur cette colonne peuvent ne pas l’être ; par contre, la colonne SEXE n’est pas intrinsèquement sélective. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 3-

Une  colonne  ayant  peu  de  valeurs  distinctes  est  intrinsèquement  non  sélective.  Parmi  les  colonnes  candidates  à  l’indexation,  il  faut  donc  identifier  celles  qui  sont  intrinsèquement  sélectives  et  utilisées  dans  des  requêtes  elles­ mêmes  sélectives ; une  colonne  sera  effectivement  une  bonne  candidate  à  l’indexation  si  la  sélectivité  (de  la  colonne et des requêtes qui l’utilisent) est inférieure à environ 5 à 10 %. Dans les grandes lignes, si une requête  utilisant  un  index  ramène  plus  de  10  %  des  lignes,  Oracle  se  révèlera  plus  performant  en  réalisant  un  parcours  complet de la table qu’en passant par l’index.  Cette règle des 5 à 10 % n’est pas en soi une garantie de performance effective de l’index ; de nombreux autres  facteurs entrent en ligne de compte. C’est néanmoins un bon critère de départ, qu’il faut valider en réalisant des  tests.  Parmi  les  colonnes  candidates,  il  faudra  d’abord  identifier  les  colonnes  qui  sont  systématiquement  présentes  ensembles  dans  la  clause  WHERE : ce  sont  de  bonnes  candidates  à  la  création  d’un  index  composé  qui  est  généralement  plus  sélectif  qu’un  index  simple.  En  effet,  si  les  colonnes  C1  et  C2  d’une  table  sont  fréquemment  utilisées ensembles dans les clauses WHERE et qu’il existe 10 valeurs distinctes pour C1 (sélectivité de 10 %) et 10  valeurs  distinctes  pour  C2  (sélectivité  de  10  %),  la  sélectivité  théorique  du  couple  (C1,C2)  est  de  1 %  (dans  l’hypothèse où il n’y a pas de corrélation entre C1 et C2).  Indexer les petites tables ne sert à rien car le nombre minimum d’entrées/sorties lors d’un accès par index est de 2  (1  entrée/sortie  au  minimum  pour  l’index  et  1  entrée/sortie  au  minimum  pour  la  table).  Or,  grâce  au  paramètreDB_FILE_MULTIBLOCK_READ_COUNT (DBFMRC ci­après), Oracle peut lire DBFMRC blocs en une entrée/sortie lors  d’un  parcours  complet  de  table.  Donc,  si  la  taille  de  la  table  est  inférieure  à  DBFMRC  blocs,  un  index  est  moins  performant  que  le  parcours  complet ; si  la  taille  de  la  table  est  inférieure  à  2 x DBFMRC  blocs,  un  index  est  aussi  performant  (mais  pas  plus)  que  le  parcours  complet.  Ainsi,  en  général,  indexer  des  tables  comprenant  quelques  dizaines de blocs n’apporte rien.  Les  valeurs  NULL  ne  sont  pas  stockées  dans  les  index  B­tree ; donc,  indexer  une  colonne  pour  améliorer  les  recherches  IS NULL  ne  sert  à  rien.  Hormis  les  index  uniques,  il  n’est  jamais  certain  qu’un  index  soit  réellement  performant ; il  faut  donc  le  tester.  Lors  des  tests  sur  les  index,  il  ne  faut  pas  oublier  de  vérifier  si  les  index  ne  dégradent pas trop les performances des mises à jour. 

b. Compléments sur les index composés  L’ordre des colonnes est important dans un index composé. Un index composé est utilisé si les colonnes de tête de  la clé d’index sont présentes dans la condition.  Si un index composé existe sur les colonnes (NOM,PRENOM) de la table ADHERENT, les trois requêtes suivantes utilisent  l’index :  SELECT * FROM adherent WHERE nom = ’HEURTEL’ AND prenom = ’Olivier’; SELECT * FROM adherent WHERE prenom = ’Olivier’ AND nom = ’HEURTEL’; SELECT * FROM adherent WHERE nom = ’HEURTEL’; Par contre, la requête suivante n’utilise pas l’index :  SELECT * FROM adherent WHERE prenom = ’Olivier’; L’ordre des colonnes n’a pas d’importance dans la clause WHERE.  Dans certains cas, si la première colonne de l’index a très peu de valeurs distinctes (par exemple 2), Oracle  est susceptible de subdiviser l’index  en  sous­index (un pour chaque valeur de la première colonne) et de  parcourir chaque sous­index.  Dans  certaines  situations,  il  peut  être  intéressant  d’ajouter  dans  la  clé  d’index  des  colonnes  présentes  dans  la  clause SELECT, pour éviter d’accéder à la table.  Pour  la  requête  suivante,  ajouter  la  colonne  NUMERO_TELEPHONE  dans  l’index  composé  qui  existe  sur  les  colonnes  (NOM,PRENOM) permet d’éviter l’accès à la table  SELECT numero_telephone FROM adherent WHERE nom = ’HEURTEL’ AND prenom = ’Olivier’;

Abuser  de  cette  astuce  et  placer  de  nombreuses  colonnes  dans  la  clé  d’index  peut  rendre  l’index  moins  performant.  Plus  la  clé  d’index  est  longue,  moins  il  y  a  de  clés  par  bloc,  et  plus  l’index  est  volumineux  et 

- 4-

© ENI Editions - All rights reserved - Algeria Educ

profond, ce qui augmente le nombre d’entrées/sorties pour parcourir l’index. 

c. S’assurer que les requêtes sont bien écrites  Par ailleurs, il faut s’assurer que l’écriture des requêtes n’empêche pas l’index d’être utilisé.  Exemples de clauses WHERE où l’index présent sur la colonne nom n’est pas utilisé :  nom IS NULL  Les valeurs NULL ne sont pas dans l’index.  nom NOT IN(’DUPONT’,’DUPOND’)nom < > ’HEURTEL’  Les recherches "différent de" n’utilisent pas l’index.  nom LIKE ’%TEL’  Les recherches LIKE n’utilisent pas l’index si le début de la chaîne n’est pas connu (recherches du type "contient",  "se termine par").  SUBSTR(nom,1,1) =’H’  Et  plus  généralement,  lorsqu’une  fonction  est  appliquée  à  la  colonne,  ou  que  la  colonne  est  utilisée  dans  une  expression.  Par contre, exemples de clauses WHERE où l’index est utilisé :  nom > ’HEURTEL’  Les recherches de type "inférieur", "supérieur", "entre" utilisent l’index.  nom LIKE ’H%’  Le début de la chaîne est connu. 

Ce n’est pas parce qu’une requête n’empêche pas l’utilisation d’un index, que l’index est réellement utilisé.  C’est  l’optimiseur  Oracle  qui  décidera  d’utiliser  ou  non  un  index,  en  fonction  des  caractéristiques  de  la  requête, de la table et des index (c’est un vaste sujet). 

5. Spécifier le stockage d’un index  a. Index indépendant  Le stockage d’un index peut être spécifié lors de la création de l’index, dans l’ordre SQL CREATE INDEX.  Syntaxe simplifiée  CREATE [UNIQUE] INDEX nom_index ON nom_table(liste_colonnes) [ TABLESPACE nom_tablespace ] [ PCTFREE valeur ] [ clause_stockage ] [ ONLINE ] [ NOCOMPRESS | COMPRESS [n] ] [ LOGGING | NOLOGGING ] ; - clause_stockage STORAGE ( [ INITIAL valeur [K|M] ] [ NEXT valeur [K|M] ] [ MINEXTENTS valeur ] [ MAXEXTENTS { valeur | UNLIMITED } ] [ PCTINCREASE valeur ] )

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 5-

Exemple :  CREATE INDEX adherent$nom#prenom ON adherent(nom,prenom) TABLESPACE indx PCTFREE 20 STORAGE ( INITIAL 2M ) ; Les clauses TABLESPACE et STORAGE ont déjà été présentées au chapitre Gestion des tablespaces et des fichiers de  données.  N’oubliez  pas  que  la  clause  STORAGE  est  traitée  différemment  selon  que  le  tablespace  est  géré  par  le  dictionnaire ou localement. Dans un tablespace géré localement, seule l’option INITIAL est utile.  La clause PCTFREE donne la valeur du PCTFREE (entre 0 et 99, 10 par défaut).  La clause ONLINE permet d’autoriser les mises à jour sur la table pendant la construction de l’index.  La  clause  COMPRESS [n]  permet  de  compresser  la  clé  d’index,  uniquement  dans  le  cas  d’un  index  composé.  Pour  compresser  la  clé  d’index,  Oracle  élimine  les  occurrences  répétées  des  valeurs  des  colonnes  de  la  clé.  L’option  n  permet de préciser le nombre de colonnes de la clé à compresser. Par défaut,  n est égal au nombre de colonnes  moins un pour un index unique et au nombre de colonnes pour un index non unique. Compresser la clé des index  composés  peut  permettre  de  réduire  sensiblement  la  taille  de  l’index.  Pour  obtenir  un  résultat  optimal,  il  faut  compresser sur la portion de tête de la clé comprenant le plus grand nombre de répétitions (cette information peut  être obtenue avec l’ordre SQL ANALYZE INDEX ... VALIDATE STUCTURE présenté plus loin).  La  clause  NOLOGGING  permet  de  ne  pas  journaliser  la  création  de  l’index ; les  mises  à  jour  individuelles  sont,  par  contre, toujours journalisées. Les considérations sont les mêmes que pour une table (cf. Gestion des tables) mais  un  index  est  moins  critique  qu’une  table ; si  un  index  n’est  pas  récupérable,  il  est  toujours  possible  de  le  reconstruire.  Il existe aussi un ordre SQL ALTER INDEX mais, comme pour une table, il n’a pas d’effet rétroactif sur ce qui est déjà  alloué ; généralement, en cas de besoin, l’index sera plutôt reconstruit. 

b. Index d’une contrainte de clé primaire ou unique  Le stockage de l’index d’une clé primaire ou unique peut être spécifié lors de la définition de la contrainte grâce à  l’option USING INDEX de la clause CONSTRAINT.  Syntaxe  CONSTRAINT nom_contrainte { PRIMARY KEY | UNIQUE } (liste_colonnes) USING INDEX [ spécification_stockage | nom_index | (ordre_création_index) ] - spécification_stockage [ TABLESPACE nom_tablespace ] [ PCTFREE valeur ] [ clause_stockage ] [ ONLINE ] [ NOCOMPRESS | COMPRESS [n] ] [ LOGGING | NOLOGGING ] ; ●

nom_index : nom d’un index qui existe déjà. 

●

ordre_création_index : ordre SQL de création d’index tel que vu précédemment. 

Exemple :  ●

Définition des clauses de stockage de l’index 

ALTER TABLE adherent ADD CONSTRAINT adherent$pk PRIMARY KEY(numero) USING INDEX TABLESPACE indx PCTFREE 0 STORAGE (INITIAL 2M) ; ●

Spécification d’un index déjà existant 

ALTER TABLE adherent ADD CONSTRAINT adherent$uk01 UNIQUE (nom,prenom,telephone) USING INDEX adherent$ix01 ; - 6-

© ENI Editions - All rights reserved - Algeria Educ

●

Création complète de l’index 

ALTER TABLE adherent ADD CONSTRAINT adherent$uk01 UNIQUE (nom,prenom,telephone) USING INDEX ( CREATE INDEX adherent$ix01 ON adherent(nom,prenom,telephone) TABLESPACE indx PCTFREE 25 STORAGE (INITIAL 10M) ) ; Par défaut, lorsqu’une contrainte de clé primaire ou de clé unique est créée ou activée, Oracle regarde s’il existe un  index  utilisable  pour  vérifier  la  contrainte.  Cet  index  peut  être  unique  ou  non  unique,  mais  doit  posséder  une  clé  égale à ou commençant par la clé de la contrainte. Si un tel index n’existe pas, Oracle crée un index unique pour  vérifier la contrainte, index dont la clé est égale à la clé de la contrainte. Dans ce cas, l’option  USING INDEX  de  la  clause CONSTRAINT permet de spécifier les caractéristiques de stockage de cet index.  Depuis Oracle9i, la clause USING INDEX peut :  ●

mentionner explicitement le nom d’un index à utiliser pour vérifier la contrainte ; 

●

inclure un ordre SQL CREATE INDEX pour créer explicitement l’index associé à la contrainte. 

Dans les deux cas, les autres options de la clause USING INDEX sont interdites.  L’index mentionné ou créé peut être unique ou non unique mais il doit être "compatible" avec la contrainte de clé  primaire ou unique. Si l’index est unique, la clé de l’index doit être égale à la clé de la contrainte (mêmes colonnes,  dans  le  même  ordre).  Si  l’index  est  non  unique,  la  clé  de  l’index  doit  être  égale  à  ou  commencer  par  la  clé  de  la  contrainte.  Exemple :  CREATE INDEX adherent$ix01 ON adherent(nom,prenom,telephone) TABLESPACE indx ; ALTER TABLE adherent ADD CONSTRAINT adherent$pk PRIMARY KEY (nom,prenom) USING INDEX adherent$ix01 ; Fonctionnellement,  créer  l’index  avant  la  contrainte  et  le  mentionner  dans  l’ordre  de  création  de  la  contrainte  équivaut strictement à créer l’index dans l’ordre de définition de la contrainte.  Utiliser une des deux clauses USING INDEX apparues dans Oracle9i permet :  ●

d’être plus explicite ; 

●

de désigner un index précis si plusieurs index peuvent être utilisés pour vérifier la contrainte ; 

●

de créer un autre index que celui qui serait utilisé par défaut (avec une autre clé) ; 

●

●

si aucun index n’existe déjà, de créer un index avec un nom précis, sur une clé précise, généralement plus  "longue" que la clé de la contrainte ;  de créer explicitement un index non unique (voir l’intérêt ci­après). 

La vue DBA_CONSTRAINTScontient deux colonnes, INDEX_OWNER  et INDEX_NAME, qui permettent de faire le lien  entre une contrainte de clé primaire ou de clé unique et son index associé (vue DBA_INDEXES).  Par défaut, lorsqu’une clé primaire ou unique est supprimée :  ●

openmirrors.com

L’index associé est supprimé s’il est unique. 

© ENI Editions - All rights reserved - Algeria Educ

- 7-

●

L’index associé est conservé s’il est non unique. 

L’origine de l’index (créé par Oracle, déjà existant, créé dans l’ordre de définition de la contrainte) n’a pas d’impact.  Depuis  Oracle9i,  il  est  possible  d’indiquer  explicitement  si  l’index  associé  à  une  contrainte  supprimée  doit  être  conservé ou supprimé.  Syntaxe  ALTER TABLE DROP CONSTRAINT { nom_contrainte | PRIMARY KEY } KEEP INDEX | DROP INDEX ; A  priori,  conserver  un  index  unique  lors  de  la  suppression  d’une  contrainte  de  clé  primaire  ou  unique  n’a  pas  de  sens : l’unicité est toujours vérifiée au niveau de l’index.  L’approche  par  défaut  d’Oracle  est  relativement  logique.  Si  une  contrainte  de  clé  primaire  ou  de  clé  unique  est  supprimée,  c’est  notamment  que  l’unicité  n’est  plus  souhaitée ; supprimer  l’index  associé  est  donc  logique.  Par  contre,  un  index  non  unique  ne  vérifie  pas  l’unicité  et  peut  donc  être  conservé,  même  lorsque  la  contrainte  est  supprimée.  La nouvelle clause est intéressante pour aller à l’encontre du fonctionnement par défaut : supprimer un index qui  serait conservé ou conserver un index qui serait supprimé. Elle permet aussi d’être plus explicite et de ne pas se  préoccuper du fonctionnement par défaut.  Créer systématiquement des index non uniques pour gérer les contraintes de clé primaire et de clé unique  est intéressant, et laisse en tout état de cause le choix de conserver ou non l’index lors de la suppression  ou de la désactivation de la contrainte. 

6. Recommandations pour le stockage des index  a. Vue d’ensemble  Les recommandations sont les mêmes que pour les tables (section Gestion des tables) :  ●

●

●

recommandation numéro un (fondamentale) : stocker les index dans un ou plusieurs tablespaces dédiés, de  préférence  gérés  localement  (c’est  le  cas  par  défaut)  avec  une  gestion  automatique  de  l’espace  dans  les  segments (c’est le cas par défaut) ;  recommandation  numéro  deux  (moins  importante) : régler  PCTFREE  avec  soin  (voir  Estimation  de  PCTFREE),  au moins pour les index les plus importants ;  recommandation numéro trois (moins importante) : allouer un espace initial à l’index, adapté à la volumétrie  estimée à une échéance donnée (pas forcément très lointaine, car très souvent, les index sont reconstruits  à intervalles réguliers). 

Définir  un  index  en  spécifiant  un  INITIAL  adapté  à  la  volumétrie  estimée  de  l’index,  peut  améliorer  la  performance de création de l’index, en diminuant le nombre d’extensions allouées pendant l’opération. 

b. Estimer la volumétrie d’un index à une échéance donnée  Là encore, le plus simple et le plus pragmatique consiste à procéder comme pour une table : 

- 8-

●

estimer le nombre de lignes attendues ; 

●

créer l’index dans les conditions d’exploitation (taille de bloc et PCTFREE notamment) ; 

●

charger la table avec un jeu de données représentatives ; 

© ENI Editions - All rights reserved - Algeria Educ

●

●

calculer  le  nombre  de  blocs  d’index  occupés  par  ce  jeu  d’essai  (par  exemple,  à  partir  des  statistiques  de  l’index ou à l’aide du package DBMS_SPACE, voir ci­après) ;  en déduire le nombre de blocs pour le nombre de lignes attendues (règle de trois). 

Supposons, par exemple, que la table ADHERENT (schéma DIANE) ait été chargée avec 10 000 lignes et qu’elle doit en  contenir 250 000 à une échéance de 6 mois. Nous pouvons réaliser le calcul suivant pour un de ces index :  SQL> ANALYZE INDEX adherent$ix01 VALIDATE STRUCTURE; Index analysé. SQL> SELECT lf_blks+br_blks FROM index_stats 2 WHERE name=’ADHERENT$IX01’; LF_BLKS+BR_BLKS --------------59 SQL> SELECT 59/10000*250000 estimation FROM dual; ESTIMATION ---------1475 L’index pour le jeu de données utilise 59 blocs, donc par règle de trois, nous pouvons estimer que l’index utilisera 1  475 blocs dans 6 mois.  L’emploi de l’ordre SQL ANALYZE INDEX ... VALIDATE STRUCTURE est présenté plus loin. 

c. Estimation de PCTFREE  Vous n’avez pas besoin de vous préoccuper de PCTFREE si la colonne indexée est vide lors de la création de l’index.  Pour mémoire, PCTFREE est pris en compte uniquement à la création de l’index et n’est effectivement utilisé que si la  colonne à indexer est non vide.  Vous pouvez positionner PCTFREE à une valeur faible (éventuellement 0) dans les cas suivants :  ●

●

Si l’index est créé sur une colonne qui sera rarement mise à jour (ni UPDATE ni INSERT).  Si l’index est créé sur une colonne qui va continuer à faire l’objet d’insertions avec des valeurs en dehors de  la plage des valeurs actuelles (ces entrées d’index iront dans de nouveaux blocs). 

Dans le cas où l’index est créé sur une colonne non vide, l’objectif de PCTFREE est simple : réserver de l’espace dans  les  blocs  pour  les  éventuelles  futures  insertions  de  clés  dans  les  blocs  d’index  initialement  utilisés  (les  clés  sont  triées dans les blocs feuilles). Si pour une raison quelconque, les futures insertions de clés ne risquent pas de venir  dans les blocs déjà utilisés, il est possible de mettre un PCTFREE faible ou nul.  Vous devez par contre positionner PCTFREE à une valeur élevée dans les cas suivants :  ●

●

Si l’index est créé sur une colonne qui sera souvent mise à jour (UPDATE).  Si l’index est créé sur une colonne qui va continuer à faire l’objet d’insertions avec des valeurs appartenant  à la plage des valeurs actuelles (ces entrées viendront s’intercaler dans les blocs existants). 

Dans ce cas, PCTFREE peut être estimé par la formule suivante :  PCTFREE = 100 x (1 -Ni / Nf) Ni = nombre initial de lignes ;  Nf = nombre final de lignes (à une échéance donnée).  Nf est une valeur relativement arbitraire, Nf - Ni étant le nombre de lignes à insérer dans l’index avant que tout  l’espace  laissé  libre  initialement  soit  occupé  (statistiquement),  et  que  Oracle  doit  commencer  à  réorganiser  son  arbre d’index.  Une valeur arbitraire de  PCTFREE  peut  être  utilisée  (10  à  20  %),  sachant  qu’il  est  facile  de  superviser  le  stockage  d’un index et de le reconstruire en cas de besoin. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 9-

Lorsqu’une  clé  d’index  est  modifiée,  l’entrée  correspondante  est  supprimée  et  recréée.  Lorsque  des  entrées sont supprimées dans un bloc d’index, l’espace libéré ne peut être réutilisé que pour des entrées  dont c’est la place (les données sont triées dans les blocs feuilles). Pour pouvoir réutiliser un bloc et y placer des  valeurs complètement différentes, il faut que le bloc soit complètement vide. 

7. Superviser l’espace occupé par un index  a. Vue d’ensemble  Là encore, vous trouverez de nombreuses similitudes avec les tables ...  Les vues DBA_SEGMENTS et DBA_EXTENTS présentées au chapitre Gestion des tablespaces et des fichiers de données  permettent de voir l’espace global alloué à l’index, mais elles ne donnent pas d’informations sur le nombre de blocs  réellement utilisés.  Pour obtenir des informations plus détaillées sur le stockage d’un index, vous pouvez :  ●

utiliser les informations calculées par le package DBMS_SPACE (voir le point Gestion des tables) ; 

●

employer les statistiques générées par le package DBMS_STATS ; 

●

utiliser d’autres statistiques calculées par l’ordre SQL ANALYZE INDEX ... VALIDATE STRUCTURE. 

Les statistiques générées par le package DBMS_STATS ne sont pas suffisantes pour réaliser une analyse détaillée du  stockage de l’index (mais elles sont suffisantes pour l’optimiseur) ; nous ne les évoquerons donc, pas ici (description  de la vue DBA_INDEXES au point Trouver des informations sur les index).  Nous allons par contre, présenter l’utilisation de l’ordre SQL ANALYZE INDEX ... VALIDATE STRUCTURE. 

b. L’ordre SQL ANALYZE INDEX ... VALIDATE STRUCTURE  L’ordre  SQL  ANALYZE INDEX ... VALIDATE STRUCTURE  permet  de  vérifier  l’intégrité  de  l’index  et  d’obtenir  des  informations détaillées sur le stockage de l’index.  Syntaxe  ANALYZE INDEX nom_index VALIDATE STRUCTURE; Exemple :  ANALYZE INDEX adherent$ix01 VALIDATE STRUCTURE; L’ordre SQL ANALYZE INDEX ... VALIDATE STRUCTURE ne vérifie pas la cohérence de l’index vis­à­vis de la table ; pour  vérifier une telle cohérence, il faut ajouter l’option CASCADE. Le résultat peut être consulté dans la vue INDEX_STATS :  NAME  nom de l’index.  HEIGHT  hauteur de l’arbre.  BLOCKS  nombre de blocs alloués au segment.  LF_BLKS  nombre de blocs feuilles dans l’index.    - 10 -

© ENI Editions - All rights reserved - Algeria Educ

BR_BLKS  nombre de blocs branches dans l’index.  LF_ROWS  nombre de lignes (valeurs) dans l’index.  DEL_LF_ROWS  nombre de lignes supprimées dans l’index.  PCT_USED  pourcentage de l’espace alloué à l’index qui est utilisé (entre 0 et 100).  OPT_CMPR_COUNT  Nombre de colonnes de la clé d’index à utiliser pour avoir une compression optimale.  OPT_CMPR_PCTSAVE  Pourcentage d’espace qui peut être économisé en compressant la clé d’index selon le nombre de colonnes indiqué.    La vue INDEX_STATS ne donne que le résultat du dernier ANALYZE INDEX ... VALIDATE STRUCTURE. Les  statistiques  générées  par  l’ordre  SQL  ANALYZE INDEX ... VALIDATE STRUCTURE  ne  sont  pas  utilisées  par  l’optimiseur.  La  somme  LF_BLKS+BR_BLKS  donne  le  nombre  de  blocs  utilisés  par  l’index,  c’est­à­dire  le  nombre  de  blocs  dans  lequel il existe au moins une ligne ; PCT_USED donne le pourcentage moyen d’occupation des blocs utilisés.  Exemple :  ●

Situation de départ (juste après la création de l’index) 

SQL> SELECT height,lf_blks,br_blks,blocks,pct_used, 2 lf_rows,del_lf_rows 3 FROM index_stats WHERE name=’ADHERENT$IX01’; HEIGHT LF_BLKS BR_BLKS BLOCKS PCT_USED LF_ROWS DEL_LF_ROWS -------- -------- -------- -------- -------- -------- ----------2 57 1 64 89 9949 0

●

Situation après une forte activité de mises à jour (uniquement UPDATE) sur la table 

SQL> SELECT height,lf_blks,br_blks,blocks,pct_used, 2 lf_rows,del_lf_rows 3 FROM index_stats WHERE name=’ADHERENT$IX01’; HEIGHT LF_BLKS BR_BLKS BLOCKS PCT_USED LF_ROWS DEL_LF_ROWS -------- -------- -------- -------- -------- -------- ----------2 115 1 128 70 13177 3228 Dans  cet  exemple,  nous  voyons  que  des  blocs  supplémentaires  ont  été  alloués  à  l’index  et  ont  été  utilisés,  mais  avec une dégradation du taux d’occupation. La colonne DEL_LF_ROWS montre que des entrées ont été supprimées,  alors  qu’il  n’y  a  eu  aucune  suppression  dans  la  table ; mais,  comme  nous  l’avions  indiqué  précédemment,  une  modification de clé d’index se traduit par une suppression (d’où les DEL_LF_ROWS) puis une insertion (d’où l’utilisation  éventuelle de nouveaux blocs). 

c. Problèmes possibles sur le stockage  Les problèmes possibles sur le stockage d’un index sont les suivants : 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 11 -

●

espace inutilisé alloué à l’index ; 

●

faible taux d’occupation moyen des blocs et/ou profondeur importante de l’arbre. 

Espace inutilisé alloué à un index Il y a de l’espace inutilisé alloué à un index si le nombre de blocs occupés est faible par rapport au nombre de blocs  alloués, et si l’index ne va plus grossir (ou peu).  Le  nombre  de  blocs  occupés  est  donné  par  la  somme  de  la  valeur  des  colonnes  LF_BLKS  et  BR_BLKS  de  la  vue  INDEX_STATS et le nombre de blocs alloués par la valeur de la colonne BLOCKS de la vue INDEX_STATS.  Exemple :  SQL> SELECT lf_blks+br_blks "occupés",blocks "alloués" 2 FROM index_stats WHERE name=’ADHERENT$IX01’; occupés alloués -------- -------116 128 Ce premier problème n’a pas d’incidence sur les performances (les blocs au­delà de la HWM ne sont jamais lus) ; il  conduit juste à un gaspillage d’espace disque.  Faible taux d’occupation moyen des blocs et/ou profondeur importante de l’index Le  stockage  interne  d’un  index  peut  être  considéré  comme  dégradé  si  une  ou  plusieurs  des  conditions  suivantes  sont vérifiées :  ●

Le rapport DEL_LF_ROWS/LF_ROWS est élevé (supérieur à 10 % ou 20 %). 

●

Le pourcentage d’occupation (PCT_USED) est faible (inférieur à 70 %). 

●

La profondeur de l’arbre d’index (HEIGHT) est élevée (strictement supérieure à 5). 

Un  mauvais  remplissage  des  blocs  peut  être  lié  à  une  valeur  inadaptée  de  PCTFREE  lors  de  la  création  de  l’index  et/ou  à  un  index  très  volatile  (nombreuses  mises  à  jour).  Ce  deuxième  problème  a  des  incidences  sur  les  performances et sur l’utilisation  de  l’espace dans le Database Buffer Cache. Moins les blocs sont pleins, plus l’index  est volumineux et profond, ce qui augmente le nombre d’entrées/sorties pour le parcours de l’arbre.  Un  index  créé  sur  une  table  très  volumineuse  peut  avoir  un  arbre  profond.  Ce  qu’il  faut  donc  surveiller,  c’est  davantage  la  dégradation  au  fil  du  temps  (surtout  si  la  volumétrie  de  la  table  reste  par  ailleurs,  stable)  qu’une  situation à un instant donné.  Exemple :  ●

Avant 

SQL SELECT height,pct_used,ROUND(del_lf_rows/lf_rows*100) PCT_DEL 2 FROM index_stats WHERE name=’ADHERENT$IX01’; HEIGHT PCT_USED PCT_DEL -------- -------- -------2 89 0

●

Après 

SQL> SELECT height,pct_used,ROUND(del_lf_rows/lf_rows*100) PCT_DEL 2 FROM index_stats WHERE name=’ADHERENT$IX01’; HEIGHT PCT_USED PCT_DEL -------- -------- -------2 70 24 Sur  cet  exemple,  le  stockage  de  l’index  s’est  dégradé  au  fil  du  temps  (alors  que  la  volumétrie  de  la  table  n’a  pratiquement pas changé). 

- 12 -

© ENI Editions - All rights reserved - Algeria Educ

8. Réorganiser le stockage d’un index  a. Vue d’ensemble  Les besoins de réorganisation d’un index sont variés :  ●

libérer de l’espace libre au­dessus de la HWM ; 

●

réorganiser un index dont la structure s’est dégradée ; 

●

réorganiser  plus  globalement  le  stockage  de  l’index : changement  de  tablespace,  réduction  du  nombre  d’extensions, changement de PCTFREE, etc. 

Libérer de l’espace situé au­dessus de la HWM permet de récupérer de l’espace alloué à l’index mais jamais utilisé  (et estimé jamais utilisable). Améliorer le taux de remplissage des blocs permet aussi éventuellement de libérer de  l’espace inutilisé (l’espace libre des blocs) situé cette fois, en dessous de la HWM.  Plusieurs techniques sont à notre disposition pour réorganiser le stockage d’un index :  ●

Ordre SQL ALTER INDEX ... DEALLOCATE UNUSED ; 

●

Ordre SQL ALTER INDEX ... COALESCE ; 

●

Ordre SQL ALTER INDEX ... SHRINK SPACE ; 

●

Ordre SQL ALTER INDEX ... REBUILD. 

Il est évidemment aussi possible de supprimer l’index  (ordre  SQL DROP INDEX) puis de le créer de nouveau (ordre  SQL  CREATE INDEX),  mais  une  reconstruction  (ordre  SQL  ALTER INDEX ... REBUILD)  se  révèle  généralement  plus  intéressante.  Le tableau suivant résume les techniques envisageables (√) et celles qui sont les mieux adaptées (☺) à tel ou tel  besoin :  DEALLOCATE  Libérer de l’espace au­dessus de la  HWM 

COALESCE 

☺ 

Améliorer le taux de remplissage des  blocs 

☺ 

Réorganiser plus globalement 

SHRINK 

REBUILD 

√ 

√ 

☺ 

☺ 

☺ 

Réorganiser le stockage d’un index est moins compliqué que réorganiser le stockage d’une table car les données ne  sont pas affectées et la table est toujours accessible et pleinement opérationnelle.  Lors d’un traitement massif sur une table (chargement, purge), il peut être intéressant de supprimer tout  ou partie des index de la table avant le traitement et de les recréer ensuite. La performance globale est  meilleure et l’index est neuf (non dégradé) à l’arrivée. 

b. L’ordre SQL ALTER INDEX ... DEALLOCATE UNUSED  L’ordre SQL ALTER INDEX ... DEALLOCATE UNUSED permet de libérer l’espace d’un index situé au­dessus de la HWM.  Syntaxe  ALTER INDEX nom_index DEALLOCATE UNUSED [ KEEP valeur [K|M] ] ; Exemple : 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 13 -

ALTER INDEX adherent$pk DEALLOCATE UNUSED; ALTER INDEX adherent$pk DEALLOCATE UNUSED KEEP 0; ALTER INDEX adherent$pk DEALLOCATE UNUSED KEEP 1M; Le  fonctionnement  est  le  même  que  pour  une  table  (Gestion  des  tables).  N’oubliez  pas  que  l’espace  initialement  alloué  est  par  défaut  préservé ; il  faut  utiliser  la  clause  KEEP  pour  libérer  de  l’espace  à  l’intérieur  de  l’espace  initialement alloué à l’index. 

c. L’ordre SQL ALTER INDEX ... COALESCE  L’ordre SQL ALTER INDEX ... COALESCE permet de fusionner le contenu de blocs feuilles adjacents qui contiennent  de l’espace libre. Grosso modo, deux blocs feuilles adjacents qui ont 50 % d’espace libre peuvent être fusionnés en  un seul bloc, ce qui libère un bloc.  Syntaxe  ALTER INDEX nom_index COALESCE ; L’ordre  SQL  ALTER INDEX ... COALESCE  n’effectue,  par  contre,  aucune  opération  sur  les  blocs  branches ; la  profondeur  de  l’arbre  ne  change  pas.  Cette  opération  est  relativement  rapide  et  ne  nécessite  pas  d’espace  de  stockage supplémentaire.  Exemple :  ●

Situation de départ 

SQL> SELECT height,lf_blks,br_blks,blocks,pct_used, 2 lf_rows,del_lf_rows 3 FROM index_stats WHERE name=’ADHERENT$IX01’; HEIGHT LF_BLKS BR_BLKS BLOCKS PCT_USED LF_ROWS DEL_LF_ROWS -------- -------- -------- -------- -------- -------- ----------2 257 1 384 90 64000 0

●

Situation après des modifications importantes dans la table : l’index est dégradé (la profondeur a changé) 

SQL> SELECT height,lf_blks,br_blks,blocks,pct_used, 2 lf_rows,del_lf_rows 3 FROM index_stats WHERE name=’ADHERENT$IX01’; HEIGHT LF_BLKS BR_BLKS BLOCKS PCT_USED LF_ROWS DEL_LF_ROWS -------- -------- -------- -------- -------- -------- ----------3 580 3 640 78 83580 33785

●

Opération de COALESCE 

SQL> ALTER INDEX diane.adherent$ix01 COALESCE;

●

Situation à l’arrivée (après ANALYZE INDEX ... VALIDATE STRUCTURE) 

SQL> SELECT height,lf_blks,br_blks,blocks,pct_used, 2 lf_rows,del_lf_rows 3 FROM index_stats WHERE name=’ADHERENT$IX01’; HEIGHT LF_BLKS BR_BLKS BLOCKS PCT_USED LF_ROWS DEL_LF_ROWS -------- -------- -------- -------- -------- -------- ----------3 370 3 640 88 49838 43 L’opération  de  COALESCE  a  permis  de  réduire  le  nombre  de  blocs  utilisés,  et  de  retrouver  un  pourcentage  d’occupation  satisfaisant  et  un  faible  taux  de  lignes  supprimées  (il  en  reste  quelques­unes).  Par  contre,  la  profondeur de l’arbre n’a pas changé.  Dans  de  nombreuses  situations,  cette  simple  opération  de  COALESCE  est  suffisante  pour  retrouver  un  index  performant. 

- 14 -

© ENI Editions - All rights reserved - Algeria Educ

d. L’ordre SQL ALTER INDEX ... SHRINK SPACE  L’ordre SQL ALTER INDEX ... SHRINK SPACE est analogue à l’ordre SQL ALTER TABLE ... SHRINK SPACE : il permet de  compacter les lignes d’un index, mais uniquement pour un index stocké dans un tablespace géré localement avec  une gestion automatique de l’espace dans les segments. Par défaut, Oracle compacte aussi le segment, ajuste la  HWM et libère l’espace ainsi récupéré.  Syntaxe  ALTER INDEX nom_index SHRINK SPACE [COMPACT] ; Avec  l’option  COMPACT,  Oracle  se  contente  de  compacter  les  lignes,  mais  sans  ajuster  la  HWM  ni  libérer  d’espace.  L’exécution ultérieure d’un autre ordre SQL ALTER TABLE ... SHRINK SPACE permettra de terminer l’opération.  L’ordre SQL ALTER INDEX ... SHRINK SPACE COMPACT est équivalent à l’ordre SQL ALTER INDEX ... COALESCE.  Exemple  ●

Situation après des modifications importantes dans la table : l’index est dégradé. 

SQL> SELECT height,lf_blks,br_blks,blocks,pct_used, 2 lf_rows,del_lf_rows 3 FROM index_stats WHERE name=’ADHERENT$IX01’; HEIGHT LF_BLKS BR_BLKS BLOCKS PCT_USED LF_ROWS DEL_LF_ROWS -------- -------- -------- -------- -------- -------- ----------3 580 3 640 78 83580 33785

●

Opération de SHRINK SPACE  

SQL> ALTER INDEX diane.adherent$ix01 SHRINK SPACE;

●

Situation à l’arrivée (après ANALYZE INDEX ... VALIDATE STRUCTURE) 

SQL> SELECT height,lf_blks,br_blks,blocks,pct_used, 2 lf_rows,del_lf_rows 3 FROM index_stats WHERE name=’ADHERENT$IX01’; HEIGHT LF_BLKS BR_BLKS BLOCKS PCT_USED LF_ROWS DEL_LF_ROWS -------- -------- -------- -------- -------- -------- ----------3 374 3 400 87 49800 0 À quelques blocs près, l’opération de SHRINK SPACE donne le même résultat que l’opération de COALESCE, sauf sur les  blocs utilisés (400 contre 640) ; l’espace a été libéré.    L’opération de COALESCE est légèrement plus rapide que l’opération de SHRINK SPACE.

e. L’ordre SQL ALTER INDEX ... REBUILD  L’ordre SQL ALTER INDEX ... REBUILD permet de reconstruire en totalité un index (blocs branches et blocs feuilles)  et donc, de réorganiser son stockage.  Syntaxe  ALTER INDEX nom_index REBUILD [ TABLESPACE nom_tablespace ] [ PCTFREE valeur ] [ clause_stockage ] [ ONLINE ] [ NOCOMPRESS | COMPRESS [n] ] [ LOGGING | NOLOGGING ] ; - clause_stockage STORAGE ( [ INITIAL valeur [K|M] ] [ NEXT valeur [K|M] ]

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 15 -

[ MINEXTENTS valeur ] [ MAXEXTENTS { valeur | UNLIMITED } ] [ PCTINCREASE valeur ] ) Exemple :  ALTER INDEX adherent$pk REBUILD PCTFREE 40 STORAGE ( INITIAL 10M ) ; Les options sont les mêmes que celles de l’ordre SQL CREATE INDEX.  Sans  option,  l’ordre SQL  ALTER INDEX ... REBUILD  reconstruit  l’index  avec  les  mêmes  clauses  de  stockage.  Cette  syntaxe  peut  être  utilisée  pour  reconstruire  un  index  dont  les  clauses  de  stockage  sont  bonnes  mais  qui  s’est  dégradé au fil du temps, du fait d’une forte activité de mise à jour.  L’ordre SQL ALTER INDEX ... REBUILD est plus intéressant que la recréation (DROP+CREATE) pour deux raisons :  ●

L’index est reconstruit à partir de l’index existant : aucun tri n’est nécessaire. 

●

L’ancien index est toujours disponible : les requêtes peuvent l’utiliser. 

Les performances sont donc globalement améliorées pour tout le monde.  Ces  deux  avantages  disparaissent  si  l’index  d’origine  est  UNUSABLE(suite  à  l’exécution  d’un  ordre  SQL  ALTER TABLE ... MOVE par exemple).  L’inconvénient  majeur  par  rapport  à  une  recréation  est  qu’il  faut  de  l’espace  disponible  pour  faire  cohabiter  temporairement l’ancien index et le nouveau.  Exemple 1  ●

Situation après des modifications importantes dans la table : l’index est dégradé 

SQL> SELECT height,lf_blks,br_blks,blocks,pct_used, 2 lf_rows,del_lf_rows 3 FROM index_stats WHERE name=’ADHERENT$IX01’; HEIGHT LF_BLKS BR_BLKS BLOCKS PCT_USED LF_ROWS DEL_LF_ROWS -------- -------- -------- -------- -------- -------- ----------3 580 3 640 78 83580 33785

●

Opération de REBUILD 

SQL> ALTER INDEX diane.adherent$ix01 REBUILD; Index modifié.

●

Situation à l’arrivée (après ANALYZE INDEX ... VALIDATE STRUCTURE) 

SQL> SELECT height,lf_blks,br_blks,blocks,pct_used, 2 lf_rows,del_lf_rows 3 FROM index_stats WHERE name=’ADHERENT$IX01’; HEIGHT LF_BLKS BR_BLKS BLOCKS PCT_USED LF_ROWS DEL_LF_ROWS -------- -------- -------- -------- -------- -------- ----------2 364 1 384 89 49805 0 L’index a été complètement reconstruit : il a retrouvé une profondeur de 2 et utilise un peu moins de blocs.  Exemple 2  ●

Situation de départ : index non compressé 

SQL> SELECT lf_blks,br_blks,blocks,opt_cmpr_count,opt_cmpr_pctsave 2 FROM index_stats WHERE name=’ADHERENT$IX01’; LF_BLKS BR_BLKS BLOCKS OPT_CMPR_COUNT OPT_CMPR_PCTSAVE -------- -------- -------- -------------- ---------------- 16 -

© ENI Editions - All rights reserved - Algeria Educ

58

●

1

72

2

28

Compression sur les deux premières colonnes 

SQL> ALTER INDEX diane.adherent$ix01 REBUILD COMPRESS 2;

●

Situation à l’arrivée (après ANALYZE INDEX ... VALIDATE STRUCTURE) 

SQL> SELECT lf_blks,br_blks,blocks,opt_cmpr_count,opt_cmpr_pctsave 2 FROM index_stats WHERE name=’ADHERENT$IX01’; LF_BLKS BR_BLKS BLOCKS OPT_CMPR_COUNT OPT_CMPR_PCTSAVE -------- -------- -------- -------------- ---------------41 1 48 2 0 L’index a été reconstruit avec une compression sur les deux premières colonnes. Le gain annoncé était de 28 % ; il  est de 28,8 %. 

f. Conclusion  Si  le  fait  que  le REBUILD  nécessite  temporairement  de  l’espace ne vous pose pas de problème, utilisez en priorité  cette technique pour réorganiser le stockage d’un index : vous obtiendrez le meilleur résultat.  Par contre, si vous avez des problèmes de place, vous pouvez employer le COALESCE pour un résultat généralement  très satisfaisant, mais vous ne libérez pas d’espace pour d’autres segments. Dans ce cas, le SHRINK SPACE peut être  envisagé ; il présente l’avantage de libérer l’espace récupéré. 

9. Surveiller l’utilisation d’un index  Depuis Oracle9i, il est possible de surveiller les index afin de déterminer s’ils sont utilisés ou non. Un index non utilisé  peut être supprimé pour libérer de l’espace et améliorer les performances des mises à jour.  L’ordre SQL ALTER INDEX permet d’activer ou de désactiver la surveillance d’un index :  ALTER INDEX nom_index MONITORING USAGE | NOMONITORING USAGE ; Exemple :  ALTER INDEX adherent$ix01 MONITORING USAGE ; La clause MONITORING USAGE peut aussi être utilisée dans l’ordre SQL CREATE INDEX pour activer la surveillance dès la  création de l’index (NOMONITORING par défaut).  La  vue  V$OBJECT_USAGE  sera  ensuite  interrogée  pour  déterminer  si  un  index  a  été  utilisé  pendant  qu’il  était  sous  surveillance :  INDEX_NAME  Nom de l’index.  TABLE_NAME  Nom de la table sur laquelle l’index est créé.  MONITORING  Indique si l’index est actuellement sous surveillance (YES ou NO).  USED  Indique si l’index a été utilisé au moins une fois pendant sa surveillance (YES ou NO). 

openmirrors.com

  © ENI Editions - All rights reserved - Algeria Educ

- 17 -

START_MONITORING  Date/heure du début de la surveillance de l’index.  END_MONITORING  Date/heure de la fin de la surveillance de l’index (vide si la surveillance est en cours). 

 

La vue V$OBJECT_USAGE doit être interrogée sous le compte du propriétaire de l’index. Exemple :  SQL> SELECT * FROM v$object_usage 2 WHERE index_name = ’ADHERENT$IX01’ ; INDEX_NAME TABLE_NAME MONITORING USED --------------- --------------- ---------- ---START_MONITORING END_MONITORING ------------------- ------------------ADHERENT$IX01 ADHERENT YES YES 01/04/2005 10:37:40 Dans cet exemple, l’index ADHERENT$IX01 créé sur la table ADHERENT a été utilisé au moins une fois depuis que l’index  est sous surveillance ; l’index est toujours sous surveillance (la colonne END_MONITORING est vide). 

10. Trouver des informations sur les index  Plusieurs vues du dictionnaire de données permettent d’obtenir des informations sur les index :  ●

DBA_INDEXES : informations sur les index ; 

●

DBA_IND_COLUMNS : informations sur les colonnes des index ; 

●

INDEX_STATS : résultat du dernier ANALYZE INDEX ... VALIDATE STRUCTURE ; 

●

DBA_SEGMENTS : informations sur les segments (dont ceux de type index) ; 

●

DBA_EXTENTS : informations sur les extensions allouées aux segments (dont ceux de type index) 

Les vues DBA_SEGMENTS et DBA_EXTENTS ont été présentées à la section Trouver des informations sur les tablespaces  et les fichiers de données du chapitre Gestion des tablespaces et des fichiers de données.  La vue INDEX_STATS a été présentée à la section Gestion des index B­tree. L’ordre SQL ANALYZE INDEX ... VALIDATE STRUCTURE.  Les colonnes intéressantes des différentes autres vues sont présentées ci­après.  DBA_INDEXES INDEX_NAME  Nom de l’index.  OWNER  Nom du propriétaire de l’index.  TABLE_NAME  Nom de la table sur laquelle l’index est créé.    - 18 -

© ENI Editions - All rights reserved - Algeria Educ

TABLE_OWNER  Nom du propriétaire de la table.  UNIQUENESS  Nature de l’index (UNIQUE ou NONUNIQUE).  TABLESPACE_NAME  Nom du tablespace dans lequel l’index est stocké.  PCT_FREE  Valeur du PCTFREE.  COMPRESSION  Indique si la compression de l’index est active (ENABLED ou DISABLED).  PREFIX_LENGTH  Nombre de colonnes dans le préfixe de la compression.  LOGGING  Indique si le mode LOGGING est actif ou non pour l’index (YES ou NO).  STATUS  Statut de l’index (VALID ou UNUSABLE).  BLEVEL *  Profondeur de l’arbre au niveau des branches (ne tient pas compte des feuilles). 0 si le bloc racine est égal au bloc  feuille.  LEAF_BLOCKS *  Nombre de blocs feuilles dans l’index.  NUM_ROWS *  Nombre de lignes dans l’index.  CLUSTERING_FACTOR *  Facteur de regroupement des données dans la table.  AVG_LEAF_BLOCKS_PER_KEY *  Nombre moyen de blocs feuilles par valeur de la clé.  AVG_DATA_BLOCKS_PER_KEY *  Nombre moyen de blocs de données (table) par valeur de la clé.  DISTINCT_KEYS *  Nombre de valeurs distinctes dans l’index.  SAMPLE_SIZE * 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 19 -

Taille de l’échantillon utilisé lors du calcul des statistiques.  LAST_ANALYZED *  Date et heure de la dernière analyse réalisée sur l’index.  * Statistiques sur l’index, calculées par défaut lorsque les statistiques sont générées sur la table. Ces dernières sont  utilisées par l’optimiseur.  DBA_IND_COLUMNS INDEX_NAME  Nom de l’index.  OWNER  Nom du propriétaire de l’index.  TABLE_NAME  Nom de la table sur laquelle l’index est créé.  TABLE_OWNER  Nom du propriétaire de la table.  COLUMN_NAME  Nom de la colonne utilisée dans la clé de l’index.  COLUMN_POSITION  Position de la colonne dans la clé de l’index. 

- 20 -

© ENI Editions - All rights reserved - Algeria Educ

Les statistiques et l’optimiseur Oracle  L’optimiseur Oracle est chargé de déterminer le plan d’exécution des requêtes, c’est­à­dire la manière dont Oracle va  exécuter la requête.  Depuis  maintenant  plusieurs  versions,  Oracle  recommande  de  faire  fonctionner  l’optimiseur  dans  le  mode  CBO  (Cost  Based Optimizer  ­ Optimiseur  basé  sur  les  coûts).  Depuis  la  version  10,  seul  le  mode  CBO  est  supporté ; le  mode  RBO  (Rule Based Optimizer ­ Optimiseur basé sur les règles) n’est plus supporté.  Pour fonctionner, l’optimiseur dans le mode CBO a besoin de statistiques sur les tables, les colonnes et les index. Ces  statistiques sont calculées avec le package DBMS_STATS.  Dans les versions précédentes, il était de la responsabilité du DBA de programmer une tâche périodique de collecte des  statistiques, afin que l’optimiseur ne travaille pas avec des données obsolètes.  Depuis  la  version  10,  les  statistiques  sont  automatiquement  collectées  par  Oracle.  En  version 11,  cette  collecte  s’effectue par l’intermédiaire d’une tâche de maintenance automatisée (cf. Oracle Enterprise Manager Database Control  du chapitre Les Outils d’administration).  Par défaut, cette tâche de maintenance collecte les statistiques sur les objets de la base de données qui n’ont pas de  statistiques  ou  qui  ont  des  statistiques  jugées  obsolètes  (si  plus  de  10%  des  lignes  de  l’objet  sous­jacent  ont  été  modifiées) ; la  procédure  traite  en  priorité  les  objets  qui  en  ont  le  plus  besoin.  Les  paramètres  de  cette  tâche  automatique  peuvent  être  configurées  dans  le  Database  Control  (cf.  Oracle  Enterprise  Manager  Database  Control  du  chapitre Les Outils d’administration).  Vous pouvez collecter les statistiques en exécutant manuellement certaines procédures du package DBMS_STATS :  ●

GATHER_TABLE_STATS(owname,tabname) : statistiques sur une table (et par défaut sur les colonnes et index de la  table) ; 

●

GATHER_INDEX_STATS(owname,indname) : statistiques sur un index ; 

●

GATHER_SCHEMA_STATS(owname) : statistiques sur toutes les tables et index d’un schéma. 

Les paramètres sont les suivants :  ownname  Nom du schéma (NULL pour le schéma courant).  tabname  Nom de la table.  indname  Nom de l’index.  Ces  procédures  ont  d’autres  paramètres  dont  les  valeurs  par  défaut  sont  a  priori  satisfaisantes  (au  moins  dans  un  premier temps).  Les statistiques peuvent êtres consultées dans les vuesDBA_TABLES, DBA_TAB_ COLUMNSet DBA_INDEXES.  Exemple :  SQL> EXEC dbms_stats.gather_schema_stats(’DIANE’) Procédure PL/SQL terminée avec succès. SQL> SELECT num_rows,blocks,sample_size,last_analyzed 2 FROM dba_tables WHERE table_name=’ADHERENT’ AND owner=’DIANE’; NUM_ROWS BLOCKS SAMPLE_SIZE LAST_ANA ---------- ---------- ----------- -------9964 137 9964 20/07/08 Le  Database  Control  permet  de  gérer  les  statistiques  de  l’optimiseur.  Pour  accéder  à  la  page  de  gestion  des  statistiques  de  l’optimiseur, cliquez sur le lien  Serveur sur la page d’accueil  puis  sur  le  lien Gérer  les  statistiques  de  l’optimiseur (cadre Optimiseur d’interrogation). 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

Utiliser le Database Control  1. Les tables  Dans le Database Control, cliquez sur le lien Schéma sur la page d’accueil puis sur le lien Tables  (cadre Objets de  base de données) pour accéder à la page de gestion des tables. 

  La section Rechercher permet de rechercher des objets selon leur type, leur schéma ou leur nom.  À partir de cette page, vous pouvez effectuer diverses actions sur les tables : 

 

●

créer une nouvelle table (bouton Créer ou menu Créer comme ) ; 

●

supprimer une table (bouton Supprimer avec des options) ; 

●

modifier une table (bouton Modifier) ; 

●

créer un index sur une table (menu Créer un index) ; 

●

extraire la définition d’une table (menu Générer du code DDL) ; 

●

collecter les statistiques sur une table (menu Gérer les statistiques de l’optimiseur) ; 

© ENI Editions - All rights reserved - Algeria Educ

- 1-

●

réorganiser une table (menu Réorganiser) ; 

●

exécuter le conseiller sur les segments (menu Exécuter la fonction de conseil sur les segments) ; 

●

compacter (SHRINK) la table (menu Réduire le segment). 

En cliquant sur le lien du nom de table, ou en cliquant sur les boutons Créer, Modifier ou Visualiser, vous arrivez sur  la page de définition d’une table : 

  Cette page propose plusieurs onglets (sous forme de liens) permettant de gérer les différentes caractéristiques de la  table.  L’onglet Segments permet de voir l’espace utilisé par la table et ces index : 

  Le  graphique  donne  la  tendance  d’utilisation  de  l’espace  pour  le  segment  sélectionné  dans  la  liste  et  la  période  indiquées. Il peut être utilisé pour estimer la volumétrie d’une table ou d’un index à une échéance donnée. 

- 2-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

2. Les index  Dans le Database Control, cliquez sur le lien Schéma sur la page d’accueil puis sur le lien Index (cadre Objet de base  de données) pour accéder à la page de gestion des index. 

  La section Rechercher permet de rechercher des objets selon leur type, leur schéma ou leur nom.  À partir de cette page, vous pouvez effectuer diverses actions sur les index : 

 

●

créer un nouvel index (bouton Créer ou menu Créer comme) ; 

●

supprimer un index (bouton Supprimer) ; 

●

modifier un index (bouton Modifier) ; 

●

extraire la définition d’un index (menu Générer du code DDL) ; 

●

collecter les statistiques sur l’index (menu Gérer les statistiques de l’optimiseur) ; 

●

réorganiser un index (menu Réorganiser) ; 

●

exécuter le conseiller sur les segments (menu Exécuter la fonction de conseil sur les segments) ; 

●

compacter (SHRINK) un index (menu Réduire le segment). 

En cliquant sur le lien du nom d’index, ou en cliquant sur les boutons Créer, Modifier ou Visualiser, vous arrivez sur  la page de définition d’un index : 

© ENI Editions - All rights reserved - Algeria Educ

- 3-

  Cette page propose plusieurs onglets (sous forme de liens) permettant de gérer les différentes caractéristiques de  l’index. L’onglet Segments permet de voir l’espace utilisé par l’index (comme pour une table). 

3. Réorganiser une table ou un index  Le  menu  Réorganiser  disponible  sur  les  tables,  les  index  et  les  tablespace  permet  d’exécuter  un  assistant  de  réorganisation du stockage des objets. Cet assistant peut aussi être appelé en cliquant sur le lien Réorganiser les  objets dans le cadre Objets de base de données de l’onglet Schéma.  Les principales étapes de l’assistant sont les suivantes :  Définir la liste des objets à réorganiser Sur cette page, vous pouvez définir la liste des objets à réorganiser en cliquant sur les boutons Ajouter et Enlever.  Les  boutons  Définir  les  attributs et  Définir  les  attributs  par  type  permettent  de  spécifier  les  caractéristiques  de  stockage : nouveau tablespace, taille initiale, PCTFREE, etc.  Définir les caractéristiques de la réorganisation Cette page permet notamment d’indiquer si la réorganisation doit s’effectuer en ligne ou hors ligne. La réorganisation  en  ligne  privilégie  la  disponibilité  de  l’objet  au  détriment  de  la  vitesse ; c’est  l’inverse  pour  la  réorganisation  hors  ligne.  Rapport d’impact Cette page donne des informations sur les problèmes potentiels qui peuvent survenir au cours de la réorganisation  (manque  d’espace  par  exemple) ; si  c’est  le  cas,  il  faut  réaliser  les  modifications  nécessaires  avant  de  lancer  l’opération.  Programmation Cette  page  permet  de  nommer  le  travail,  de  fournir  les  informations  d’identification  et  de  connexion,  et  de  programmer l’exécution du travail (maintenant ou ultérieurement).  Récapitulatif

- 4-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

  Cette page donne un récapitulatif du travail qui va être effectué. En cliquant sur le bouton radio Script complet, vous  pouvez  consulter  (et  récupérer)  le  script  complet  de  la  réorganisation.  Cliquez  sur  le  bouton  Soumettre  un  travail  pour lancer l’opération.  Cet assistant utilise une des techniques suivantes :  ●

réorganisation d’un index : ordre SQL ALTER INDEX ... REBUILD ; 

●

réorganisation d’une table hors ligne : ordre SQL ALTER TABLE ... MOVE ; 

●

réorganisation d’une table en ligne : package DBMS_REDEFINITION. 

Le résultat du travail peut être consulté en cliquant sur le lien Travaux de la page d’accueil (cadre Liens associés en  bas). 

4. Le conseiller sur les segments  Le  Database  Control  dispose  d’un  conseiller  sur  les  segments  (Segment  Advisor).  Ce  conseiller  donne  des  recommandations sur l’opportunité ou non de compacter (SHRINK) un segment.  Cet assistant peut être appelé en utilisant le menu Exécuter la fonction de conseil sur les segments disponible sur  les  tables,  les  index  et  les  tablespace  ou  en  cliquant  sur  le  lien  Fonction  de  conseil  sur  les  segments sur la page  Centre de conseil (accessible par le lien Centre de conseil à partir de la page d’accueil).  Par  défaut,  cet  assistant  est  aussi  programmé  pour  s’exécuter  en  tâche  de  maintenance  automatisée  (cf.  Oracle  Enterprise  Manager  Database  Control  du  chapitre  Les  Outils  d’administration).  Vous  serez  donc  rarement  amené  à  lancer le conseiller manuellement.  Sur la page d’accueil du Database Control, dans le cadre Récapitulatif de l’espace, pour pouvez voir rapidement s’il y  a des recommandations sur les segments : 

 

© ENI Editions - All rights reserved - Algeria Educ

- 5-

En cliquant sur le lien associé, vous pouvez afficher la liste des recommandations : 

  Si vous cliquez sur le bouton Détails  des  recommandations, vous pouvez consulter le détail de la recommandation  sélectionnée : 

  Pour  implémenter  les  recommandations,  il  vous  suffit  de  sélectionner  une  ou  plusieurs  tâches  dans  la  liste  et  de  cliquer sur le bouton Implémenter, ou de cliquer directement sur le bouton Réduire d’une tâche. Le Database Control  affiche alors la page suivante : 

  Cette page vous permet de choisir une option de réduction (SHRINK SPACE ou SHRINK SPACE COMPACT) et de soumettre  le travail (bouton Implémenter). Le résultat du travail peut être consulté en cliquant sur le lien Travaux de la page  Serveur (cadre Oracle Scheduler).  D’une  manière  plus  générale,  les  résultats  des  différents  conseillers  sont  visibles  lorsque  vous  affichez  la  page  Centre de conseil :  - 6-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

  En cliquant sur le lien correspondant à une tâche, vous pouvez visualiser les recommandations du conseiller. 

© ENI Editions - All rights reserved - Algeria Educ

- 7-

La base de données  1. Fichier de contrôle  Le fichier de contrôle contient des informations de contrôle sur la base de données :  ●

le nom de la base de données ; 

●

la date/heure de création de la base de données ; 

●

l’emplacement des autres fichiers de la base de données (fichiers de données et fichiers de journalisation) ; 

●

le numéro de séquence actuel des fichiers de journalisation ; 

●

des informations sur les points de reprise (checkpoint), etc. 

Le fichier de contrôle est automatiquement mis à jour par Oracle lors de chaque modification de la structure de la base  de données (ajout ou déplacement d’un fichier par exemple). La taille du fichier de contrôle est déterminée par Oracle.  Lorsqu’une instance est lancée pour ouvrir une base de données, le fichier de contrôle est le premier fichier ouvert. Il  permet ensuite à l’instance de localiser et d’ouvrir les autres fichiers de la base de données. Si le fichier de contrôle ne  peut pas être trouvé (ou est endommagé), la base de données ne peut pas être ouverte, même si les autres fichiers  de  la  base  de  données  sont  présents  (l’instance  reste  dans  le  statut NOMOUNT ­ voir  le  chapitre Démarrage  et  arrêt).  Différents  scénarios  de  restauration  sont  alors  disponibles  en  fonction  de  la  situation  (présence  ou  non  d’une  sauvegarde  du  fichier  de  contrôle  notamment)  pour  redémarrer  la  base  de  données,  mais  ce  sont  des  scénarios  relativement complexes.  Pour des raisons de sécurité, il est donc conseillé de multiplexer le fichier de contrôle, c’est­à­dire d’en avoir plusieurs  copies gérées en miroir (multiplexées) par Oracle. Techniquement, il est possible de créer une base de données avec  un  seul  fichier  de  contrôle  mais  il  est  vivement  conseillé  d’utiliser  plusieurs  copies,  même  si  le  serveur  ne  comporte  qu’un disque (cela met à l’abri d’une suppression accidentelle).  Plusieurs  fichiers  de  contrôle  peuvent  être  spécifiés  lors  de  la  création  de  la  base  (chapitre Création  d’une  nouvelle  base de données) ou ultérieurement (chapitre Gestion des fichiers de contrôle et de journalisation). 

2. Fichier de journalisation  Les fichiers de journalisation (redo log) enregistrent toutes les modifications apportées à la base de données. Ils sont  organisés en groupes écrits de manière circulaire ; les informations sauvegardées sont donc périodiquement écrasées.  Les  fichiers  de  journalisation  sont  utilisés  pour  la  récupération  de  l’instance  après  un  arrêt  anormal  et  pour  la  récupération  de  média  si  un  fichier  de  données  est  perdu  ou  endommagé ;  dans  ce  cas,  ils  sont  appliqués  à  une  sauvegarde de fichier de données, pour rejouer toutes les modifications survenues entre la sauvegarde et l’incident  ayant endommagé le fichier.  Les  fichiers  de  journalisation  sont  organisés  en  groupes  (au  minimum  2)  composés  d’un  ou  de  plusieurs  membres  (minimum un) ; ils sont créés lors de la création de la base (cf. Chapitre Création d’une nouvelle base de données). À  l’intérieur  d’un  groupe,  les  membres  sont  écrits  simultanément  en  miroir  par  l’instance  Oracle  (processus  LGWR)  et  contiennent  la  même  information.  Tous  les  membres  d’un  groupe  ont  la  même  taille,  définie  lors  de  la  création  du  groupe ;  un  fichier  de  journalisation  contient  donc  une  quantité  maximale  d’informations.  De  même,  le  nombre  de  groupes est déterminé ; il n’augmente pas dynamiquement.  Lorsqu’un groupe est plein (c’est­à­dire lorsque les membres sont pleins), l’instance Oracle passe au groupe suivant et  ainsi de suite jusqu’au dernier ; lorsque le dernier groupe est plein, l’instance Oracle repasse au premier. Le passage  d’un groupe à un autre est appelé basculement (switch). 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

  Lorsque  l’instance  Oracle  revient  dans  le  premier  groupe,  elle  écrase  les  informations  qui  y  sont  stockées ;  ces  informations  ne  sont  donc  plus  disponibles  en  cas  de  besoin,  par  exemple  pour  une  récupération  de  média.  Pour  garantir  cette  possibilité  d’effectuer  des  récupérations  complètes,  il  faut  activer  le  mécanisme  d’archivage  (chapitre  Sauvegarde et récupération) qui permet d’archiver les fichiers de journalisation (en l’occurrence un membre du groupe)  lorsqu’ils sont pleins, avant que l’instance ne les réutilise.  Si un groupe comporte plusieurs membres et qu’un des membres est indisponible, la base de données peut continuer  à fonctionner.  Les  fichiers  de  journalisation  sont  très  importants  pour  la  sécurité  de  la  base  de  données.  Il  est  donc  conseillé  d’utiliser au minimum deux ou trois membres par groupe (multiplexage), si possible sur des disques différents.  Les  fichiers  de  journalisation  seront  abordés  dans  les  chapitres  Création  d’une  nouvelle  base  de  données  (création  initiale) et Gestion des fichiers de contrôle et de journalisation (manipulation ultérieure). 

3. Fichiers de données  a. Définitions  Les  fichiers  de  données  contiennent  les  données  proprement  dites  de  la  base  de  données  (tables  et  index  notamment). Ils sont logiquement regroupés en tablespaces : 

  Un  tablespace  est  une  unité  logique  de  stockage  composée  d’un  ou  plusieurs  fichiers  physiques.  La  quasi­totalité  des opérations d’administration relatives au stockage s’effectue en travaillant sur le tablespace et non sur le fichier  de données.  En  version  10,  Oracle  a  introduit  la  notion  de  tablespace  bigfile.  Un  tablespace  bigfile  est  un  tablespace  qui  ne  contient qu’un seul fichier de données, mais qui peut être beaucoup plus gros qu’un fichier de données traditionnel.  Les tablespaces bigfile permettent de gérer des volumes de données beaucoup plus importants, tout en simplifiant la  gestion  du  stockage  (moins  de  fichiers,  transparence  du  fichier  de  données).  Par  opposition,  le  tablespace  traditionnel est maintenant, parfois appelé tablespace smallfile.  Une  base  de  données  comporte  au  minimum  deux  fichiers  de  données  appartenant  à  deux  tablespaces  réservés  pour Oracle (le tablespace SYSTEM et le tablespace SYSAUX, apparu en version 10). Les tablespaces SYSTEM et SYSAUX  ne doivent normalement contenir aucune donnée applicative.  Dans  la  pratique,  une  base  de  données  comportera  donc  d’autres  fichiers  de  données  appartenant  à  d’autres  tablespaces.  La gestion des tablespaces et des fichiers de données est présentée dans le chapitre Gestion des tablespaces et  des fichiers de données. 

b. Organisation du stockage 

- 2-

© ENI Editions - All rights reserved - Algeria Educ

  Les fichiers de données sont découpés en blocs d’une taille donnée (4 Ko, 8 Ko...).  L’espace  occupé  par  un  objet  dans  un  tablespace  est  désigné  par  le  terme  générique  de segment.  Il  y  a  quatre  types principaux de segments :  ●

les segments de table : espace occupé par les tables ; 

●

les segments d’index : espace occupé par les index ; 

●

●

les segments d’annulation : espace temporaire utilisé pour stocker les informations permettant d’annuler une  transaction ;  les segments temporaires : espace temporaire utilisé notamment lors d’un tri. 

Un segment appartient à un tablespace et est constitué d’extensions (extents). Une extension est un ensemble de  blocs contigus dans un fichier de données.    Dans Oracle Enterprise Manager, les extensions sont appelées "ensembles de blocs contigus". La notion de "bloc Oracle" est fondamentale ; nous allons la retrouver partout. Un bloc Oracle est la plus petite unité  d’entrée/sortie utilisée par Oracle. Tous les fichiers de données sont organisés en blocs Oracle et ont donc une taille  multiple  de  la  taille  du  bloc.  Le  bloc  Oracle  est  aussi  l’unité  d’organisation  du  cache  de  données  (Database  Buffer  Cache)  dans  la  SGA.  Lorsqu’une  instance  Oracle  lit  un  fichier  de  données,  elle  lit  les  blocs  Oracle  du  fichier  et  les  charge dans des blocs Oracle du cache de données.  Le  segment  d’annulation  est  une  structure  utilisée  par  Oracle  pour  stocker  temporairement  la  version  précédente  des données en cours de modification dans une transaction. Si la transaction est validée (COMMIT), l’espace occupé  sera libéré ; si la transaction est annulée (ROLLBACK), la version précédente des données sera remise à la place de la  nouvelle.  Les segments temporaires et les segments d’annulation seront étudiés plus en détail dans les chapitres Gestion des  tablespaces et des fichiers de données et Gestion des informations d’annulation.  En dehors des tablespaces destinés aux données proprement dites de notre application (tables, index), nous serons  donc  amenés  à  créer  deux  autres  tablespaces  "techniques",  utilisés  en  interne  par  Oracle :  le  tablespace  d’annulation (pour les segments d’annulation) et le tablespace temporaire (pour les segments temporaires).  Lorsqu’un segment (table, index, etc.) est créé, il est placé (explicitement par le créateur ou implicitement par Oracle)  dans un tablespace ; c’est Oracle, ensuite, qui se charge d’allouer de l’espace à ce segment dans l’un des fichiers de  données du tablespace.  Lors de la création d’un segment, une ou plusieurs extensions lui sont allouées. Lorsque ces premières extensions  sont pleines (suite à l’insertion de données par exemple), une nouvelle extension est allouée ; cette extension est  située  dans  le  même  tablespace,  mais  pas  forcément  à  côté  de  la  première  (d’autres segments ont peut­être  été  créés  entre­temps),  ni  même  dans  le  même  fichier  de  données  (si  le  tablespace  a  plusieurs  fichiers  de  données).  Lorsque cette nouvelle extension est pleine, le processus se reproduit. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 3-

Dans l’ordre SQL de création du segment, il existe des clauses qui permettent d’indiquer dans quel tablespace créer  le segment et de définir la taille initiale du segment.  Ces différents mécanismes seront revus dans le chapitre Gestion des tablespaces et des fichiers de données.  Depuis la version 9 d’Oracle, il est possible d’utiliser plusieurs tailles de bloc dans la base de données :  ●

●

Une taille de bloc "standard" est définie par le paramètre d’initialisation DB_BLOCK_SIZE.  Jusqu’à 5 autres tailles de bloc peuvent être utilisées : les valeurs permises sont 2 Ko, 4 Ko, 8 Ko, 16 Ko et  32 Ko (certaines plates­formes sont plus restrictives). 

Cette  possibilité  d’utiliser  plusieurs  tailles  de  bloc  est  surtout  intéressante  pour  la  fonctionnalité  de  transport  de  tablespace.  Cette  fonctionnalité,  apparue  dans  Oracle8i,  permet  de  transporter  un  tablespace  d’une  base  de  données  source  vers  une  base  de  données  cible  et  de  le  rattacher  à  la  base  de  données  cible  ;  cette  opération  s’effectue grâce à l’utilitaire Data Pump, avec l’option TRANSPORT_TABLESPACES. Un des pré­requis pour l’utilisation de  cette fonctionnalité dans Oracle8i est que les deux bases doivent utiliser la même taille de bloc. Cette limitation est  levée  depuis  Oracle9i  puisque  différents  tablespaces  d’une  même  base  de  données  peuvent  utiliser  des  tailles  de  bloc différentes : un tablespace ayant une taille de bloc de 4 Ko peut être transporté dans une base de données  utilisant des blocs de 8 ko. 

4. Système de stockage  Les  fichiers  de  données  d’une  base  de  données  Oracle  peuvent  être  stockés  dans  un  système  de  fichiers  (cas  classique), dans des raw device (directement dans des partitions, sans système de fichier) ou à l’aide d’ASM (Automatic  Storage Management).  ASM, apparu en version 10, est en quelque sorte un gestionnaire de volumes spécialement conçu pour Oracle, qui va  chercher  à  exploiter  au  mieux  les  disques  qui  lui  sont  attribués  (répartition  des  entrées/sorties  notamment).  Pour  fonctionner, ASM utilise une instance spéciale (instance ASM).  Lors  de  l’utilisation d’un  système  de  fichiers,  il  est  conseillé  d’utiliser  plusieurs  disques.  Cela  permet  d’améliorer  les  performances en répartissant les entrées/sorties, et d’améliorer la sécurité en multiplexant les fichiers de contrôle et  les fichiers de journalisation. Par ailleurs, beaucoup de nouvelles fonctionnalités apparues en version 10, relatives à la  sécurité  des  données,  aux  sauvegardes  et  aux  restaurations,  sont  basées  sur  la  mise  en  place  d’une  zone  de  récupération  rapide  (flash  recovery  area).  Cette  zone  de  récupération  rapide  peut  être  stockée  dans  un  système  de  fichiers ou à l’aide d’ASM. Dans le cas de l’utilisation d’un système de fichiers, il est conseillé d’utiliser un disque séparé  des disques contenant les données, car c’est la destination par défaut des sauvegardes. 

5. Notion de schéma  Le terme schéma désigne l’ensemble des objets qui appartiennent à un utilisateur.  Les principaux types d’objets sont les suivants :  ●

Table 

●

Vue 

●

Synonyme 

●

Index 

●

Séquence 

●

Programme PL/SQL (procédure, fonction, package, trigger) 

Chaque utilisateur d’une base de données Oracle a un schéma potentiel, mais seuls les utilisateurs habilités pourront  effectivement créer des objets dans ce schéma. Ces différentes notions seront étudiées plus en détail dans le chapitre  Gestion des utilisateurs et de leurs droits.  Sur les différents types d’objets présentés ci­dessus, seuls les tables et les index stockent des données et occupent  de  l’espace  de  stockage  dans  des  tablespaces.  Les  autres  types  d’objet  n’ont  qu’une  définition  stockée  dans  le  dictionnaire de données Oracle. 

- 4-

© ENI Editions - All rights reserved - Algeria Educ

La  notion  de  schéma  est  une  notion  purement  logique.  Physiquement,  les  objets  des  différents  schémas  sont  mélangés, soit dans le dictionnaire de données Oracle, soit dans les tablespaces, mais Oracle sait s’y retrouver.  Des  schémas  d’exemple  sont  fournis  par  Oracle,  dont  le  fameux  (mais  réduit)  schéma  SCOTT  (mot  de  passe  TIGER,  propriétaire des tables EMP et DEPT). Des schémas d’exemple plus évolués sont décrits dans la documentation Oracle®  Database Sample Schemas. Ils peuvent être installés lors de la création d’une base de données ou ultérieurement. 

6. Règles de nommage  Un nom de structure Oracle (table, tablespace, etc.) doit respecter les règles suivantes :  ●

contenir 30 caractères maximum ; 

●

doit commencer par une lettre ; 

●

peut contenir des lettres, des chiffres et trois caractères spéciaux (_$#) ; 

●

n’est pas sensible à la casse ; 

●

ne doit pas être un mot réservé Oracle. 

Il y a évidemment des exceptions à ces règles de nommage, notamment pour le nom de la base de données  qui est limité à 8 caractères. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 5-

Problèmes courants et solutions  ORA-01653: impossible d’étendre la table X. de N dans le tablespace Y ORA-01654: impossible d’étendre l’index X. de N dans le tablespace Y Explication  Un segment (table ou index) n’arrive pas à s’étendre.  Cause(s)  Le segment (table ou index) n’arrive pas à s’étendre car le tablespace dans lequel il est stocké n’a pas suffisamment  d’espace disponible et ne peut pas s’étendre lui­même.  Action(s)  Il faut augmenter l’espace disponible dans le tablespace :  ­ soit en lui allouant un nouveau fichier de données (ALTER TABLESPACE ... ADD DATAFILE ...) ;  ­ soit en augmentant la taille d’un fichier de données du tablespace (ALTER DATABASE DATAFILE ... RESIZE ...) ;  ­ soit en autorisant un fichier de données du tablespace à s’étendre automatiquement (ALTER DATABASE DATAFILE ... AUTO- EXTEND ON ...).  ORA-01631: nbre max. d’ensembles de blocs contigus (N) atteint dans table X. ORA-01632: nbre max. d’ensembles de blocs contigus (N) atteint dans index X. Explication  Un segment (table ou index) n’arrive pas à s’étendre.  Cause(s)  Le segment (table ou index) n’arrive pas s’étendre car il est stocké dans un tablespace géré par le dictionnaire et il a  atteint son nombre maximum d’extensions défini par MAXEXTENTS. Ce problème ne peut pas se produire si le segment  est stocké dans un tablespace géré localement (nombre d’extensions illimité).  Action(s)  Utilisez un tablespace géré localement et choisissez éventuellement une taille d’extension adaptée à la volumétrie du  segment.  ORA-01502: l’index ’xxx.yyy’ ou sa partition est inutilisable Explication  Un index est inutilisable (UNUSABLE) et ne peut pas être utilisé pour exécuter une requête.  Cause(s)  La table a peut­être été reconstruite par un ALTER TABLE … MOVE, ce qui a rendu les index de la table inutilisables.  À  noter  que  cette  erreur  se  produit  uniquement  si  le  paramètre  SKIP_UNUSABLE_INDEXES  est  à  FALSE.  S’il  est  à  TRUE  (valeur par défaut), l’optimiseur ne tente pas d’utiliser les index inutilisables et l’erreur ne se produit pas ; par contre,  les performances risquent de se dégrader fortement (parcours complet de table).  Action(s)  Reconstruisez l’index (ALTER INDEX … REBUILD). 

© ENI Editions - All rights reserved - Algeria Educ

- 1-

Si vous obtenez une erreur ORA-01630 ou ORA-01652 lors de la création ou de la reconstruction d’un index, c’est  qu’il y a un problème avec le segment temporaire nécessaire au tri (voir les problèmes courants et solution du  chapitre Gestion des tablespaces et des fichiers de données). 

- 2-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

Principes  1. Vue d’ensemble  Assurer la sécurité des données est une des tâches principales de l’administrateur.  Cette sécurité est assurée par :  ●

●

la mise en œ uvre d’une protection des fichiers sensibles de la base :  ●

fichiers de contrôle ; 

●

fichiers de journalisation. 

la mise en place d’une stratégie de sauvegarde/restauration :  ●

adaptée aux contraintes de l’entreprise ; 

●

testée et documentée. 

La  protection  des  fichiers  de  contrôle  et  des  fichiers  de  journalisation  s’effectue  par  multiplexage  (voir  le  chapitre  Gestion des fichiers de contrôle et des fichiers de journalisation).  Les questions à se poser pour définir la stratégie sont les suivantes :  ●

Est­il acceptable de perdre des données ? 

●

Est­il possible d’arrêter périodiquement la base ? 

●

Est­il possible de réaliser une sauvegarde complète de la base pendant l’arrêt ? 

La réponse à la question "est­il acceptable de perdre des données ?" est rarement "oui". Si exceptionnellement, la  réponse est "oui", il faut déterminer jusqu’à quelle limite : 1 jour, 2 jours, 1 semaine ?  Il est également nécessaire de déterminer la nature de l’activité sur la base :  ●

●

Les données sont­elles mises à jour quotidiennement par les utilisateurs ? C’est typiquement le cas dans une  application transactionnelle.  Les  données  sont­elles  mises  à  jour  périodiquement  (toutes  les  nuits,  toutes  les  semaines)  et  simplement  consultées dans la journée ? C’est typiquement le cas avec une application décisionnelle. 

2. L’archivage des fichiers de journalisation  Comme  nous  l’avons  déjà  vu,  les  fichiers  de  journalisation  constituent  un  journal  des  modifications  apportées  à  la  base. Ils sont organisés en groupes écrits de manière circulaire : les informations sauvegardées sont donc par défaut  périodiquement écrasées.  Ces fichiers de journalisation peuvent être réappliqués à une sauvegarde de fichier de données, pour rejouer toutes  les modifications survenues entre la sauvegarde et un incident ayant endommagé le fichier (restauration de média), à  condition  d’avoir  conservé  tous  les  fichiers  de  journalisation ; ceci  est  possible  en  faisant  fonctionner  la  base  de  données  en  mode  ARCHIVELOG.  Ce  mode  de  fonctionnement  permet  de  garantir  zéro  perte  de  données  en  cas  d’incident sur un fichier de données.  Le principe de récupération en mode ARCHIVELOG est le suivant : 

© ENI Editions - All rights reserved - Algeria Educ

- 1-

  À un instant T0, une sauvegarde d’un fichier de données est réalisée. Après T0, l’activité de mise à jour se poursuit,  générant des entrées dans les fichiers de journalisation. L’archivage étant activé, les fichiers de journalisation pleins  sont archivés.  À  l’instant  T1,  un  incident  se  produit  et  le  fichier  de  données  est  perdu.  La  récupération  du  fichier  de  données  consiste  à  prendre  la  dernière  sauvegarde  du  fichier  (qui  ne  contient  évidemment  pas  les  modifications  effectuées  depuis) et à appliquer sur cette sauvegarde les fichiers de journalisation archivés (qui eux, contiennent la trace des  modifications  apportées  depuis  la  dernière  sauvegarde),  afin  de  ramener  le  fichier  de  données  dans  l’état  où  il  se  trouvait juste avant l’incident (pour être plus précis, dans l’état de la dernière transaction validée). 

3. Solutions de sauvegarde et récupération  Pour effectuer des sauvegardes et des récupérations, vous avez deux possibilités :  ●

utiliser l’outil Recovery Manager (RMAN) fourni par Oracle : c’est la méthode recommandée ; 

●

procéder "à la main" avec des commandes du système d’exploitation et des scripts SQL. 

RMAN est un outil ligne de commande qui facilite grandement les opérations de sauvegarde et de récupération, en  limitant notamment les risques de fausse manoeuvre. RMAN peut être utilisé à travers une interface graphique dans  le  Database  Control.  Toutes  les  opérations  de  sauvegarde  et  de  récupération  présentées  dans  cet  ouvrage  sont  basées sur l’utilisation du Recovery Manager. 

4. Stratégies de sauvegarde disponibles  Une sauvegarde peut être cohérente ou incohérente.  Une  sauvegarde cohérente  est  une  sauvegarde  de  la  totalité  de  la  base  de  données  après  un arrêt  propre  de  la  base de données (pas après un SHUTDOWN ABORT ou un arrêt anormal de l’instance) ; ce type de sauvegarde est aussi  souvent appelé "sauvegarde base fermée". Après un arrêt propre de la base de données, toutes les modifications  ont été écrites dans les fichiers de données qui sont bien synchrones. Une base de données restaurée à partir d’une  sauvegarde cohérente peut être ouverte immédiatement : il est inutile d’appliquer les fichiers de journalisation. C’est  le seul mode de sauvegarde disponible lorsque la base de données fonctionne en mode NOARCHIVELOG.  Une sauvegardeincohérente est une sauvegarde effectuée alors que la base de données est ouverte et que l’activité  de  mise  à  jour  se  poursuit  pendant  la  sauvegarde ; ce  type  de  sauvegarde  est  aussi  souvent  appelé  "sauvegarde  base  ouverte".  Les  fichiers  sauvegardés  ne  sont  pas  synchrones  du  point  de  vue  des  modifications  enregistrées.  Lorsqu’une  base  de  données  est  restaurée  à  partir  d’une  sauvegarde  incohérente,  il  faut  appliquer  les  fichiers  de  journalisation  pour  rendre  les  fichiers  cohérents.  Les  sauvegardes  incohérentes  ne  sont  possibles  que  lorsque  la  base de données fonctionne en mode ARCHIVELOG.  Une sauvegarde peut être complète, partielle ou incrémentale. Une sauvegarde complète est une sauvegarde de  la totalité de la base de données. Une sauvegarde partielle est une sauvegarde incluant uniquement une partie de 

- 2-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

la  base  de  données.  Les  sauvegardes  partielles  sont  forcément  incohérentes  entre  elles.  Pour  qu’elles  soient  exploitables en restauration (ce qui est normalement l’objectif), il faut que la base de données fonctionne en mode  ARCHIVELOG.  Une  sauvegarde  incrémentale  est  une  sauvegarde  qui  ne  contient  que  les  blocs  modifiés  depuis  la  dernière sauvegarde ; une sauvegarde incrémentale peut être complète ou partielle.  Une sauvegarde cohérente complète nécessite de pouvoir arrêter la base de données et la sauvegarder en totalité  pendant l’arrêt. 

5. Quelle stratégie pour le mode de fonctionnement de la base ?  Le tableau suivant résume les possiblités :  Pertes de données acceptables 

Sauvegarde base  fermée possible 

Oui 

Non 

Oui 

ARCHIVELOG NOARCHIVELOG 

ARCHIVELOG 

Non 

ARCHIVELOG 

ARCHIVELOG 

Le mode ARCHIVELOG est obligatoire si au moins une des contraintes suivantes existe :  ●

Aucune perte de donnée n’est autorisée. 

●

La base de données ne peut pas être fermée pour être sauvegardée. 

Le mode NOARCHIVELOG est possible si :  ●

Des pertes de données sont acceptables. 

●

La base de données peut être fermée pour être sauvegardée. 

Un autre avantage du mode ARCHIVELOG est que la base de données peut rester ouverte lorsqu’un incident survient  sur un fichier de données qui n’appartient ni au tablespace SYSTEM, ni au tablespace UNDO actif. 

6. Quelle stratégie pour la sauvegarde ?  La première règle est de réaliser des sauvegardes fréquentes (au minimum tous les jours) et de conserver plusieurs  cycles de sauvegarde (en cas de problème avec une sauvegarde).  Si la base de données fonctionne en mode ARCHIVELOG, vous pouvez réaliser des sauvegardes bases ouvertes ; il n’y  a pas de raison de s’en priver.  Si la durée de sauvegarde et la taille des sauvegardes ne posent pas de problème (même en conservant plusieurs  sauvegardes), vous pouvez réaliser systématiquement (tous les jours) des sauvegardes complètes.  Si  la  durée  de  sauvegarde  et/ou  la  taille  des  sauvegardes  posent  un  problème,  vous  pouvez  réaliser  des  sauvegardes  incrémentales  et/ou  des  sauvegardes  partielles.  Dans  le  cas  de  sauvegardes  partielles,  vous  devez  simplement  être  très  rigoureux  dans  le  suivi  et  veiller  à  tout  sauvegarder  sur  un  cycle  complet  de  sauvegardes  partielles.  Il  est  important  de  réaliser  des  sauvegardes  très  fréquemment  pour  pouvoir  procéder  à  une  restauration  en  un  temps  raisonnable : partir  d’une  sauvegarde  datant  d’un  mois  et  réappliquer  tous  les  fichiers  de  journalisation  archivés depuis un mois risque de se révéler très long si la base de données est activement mise à jour. 

© ENI Editions - All rights reserved - Algeria Educ

- 3-

Archivage des fichiers de journalisation  1. Vue d’ensemble  Activer  l’archivage  des  fichiers  de  journalisation  s’effectue  en  mettant  la  base  de  données  dans  le  modeARCHIVELOG : ce mode permet de garantir qu’un  groupe  de  fichiers  de  journalisation  ne  sera  pas  réutilisé  tant  qu’il n’a pas été archivé.  Depuis  la  version  10,  placer  la  base  de  données  en  mode  ARCHIVELOG  démarre  automatiquement  deux  processus  d’archivage (ARC0 et ARC1) lors de l’ouverture de la base de données ; dans les versions précédentes, il fallait le faire  explicitement.  Par  contre,  il  est  toujours  opportun,  même  en  version  10,  de  positionner  certains  paramètres  d’initialisation qui concernent les processus d’archivage.  La  base  de  données  peut  être  créée  d’entrée  de  jeu  en  mode ARCHIVELOG.  Généralement,  la  base  de  données  est  créée en mode NOARCHIVELOG puis passée en ARCHIVELOG. Archiver les fichiers de journalisation générés par la création  de la base de données présente un faible intérêt (mais un volume d’archives important). 

2. Mode opératoire  Le mode opératoire est le suivant :  ●

SQL> 2 3 SQL> 2 3 ●

Modifier  dans  le  fichier  de  paramètres  serveur  les  paramètres  d’initialisation  qui  concernent  les  processus  d’archivage  ALTER SYSTEM SET log_archive_format=’redo_%S_%R_%T.arc’ SCOPE=SPFILE; ALTER SYSTEM SET log_archive_dest_1=’LOCATION=h:\oradata\arch\HERMES’ SCOPE=SPFILE; Arrêter proprement la base de données (pas ABORT) 

SQL> SHUTDOWN IMMEDIATE ●

Monter la base de données 

SQL> STARTUP MOUNT ●

Passer la base de données en mode ARCHIVELOG 

SQL> ALTER DATABASE ARCHIVELOG; ●

●

Sauvegarder  la  base  de  données  (permet  une  sauvegarde  T0  du  nouveau  mode  de  fonctionnement  de  la  base de données)  Ouvrir la base de données 

SQL> ALTER DATABASE OPEN;

Le  mode  ARCHIVELOG/NOARCHIVELOG  est  une  propriété  de  la  base  qui  se  modifie  par  l’ordre  SQL  ALTER DATABASE.  Ce  mode  de  fonctionnement  est  mémorisé  dans  le  fichier  de  contrôle  de  la  base  de  données ; il  n’est pas nécessaire de le repréciser à chaque démarrage.  L’ordre SQL ALTER DATABASE NOARCHIVELOGpermet, au besoin, de repasser en mode NOARCHIVELOG. 

3. Les paramètres du processus d’archivage 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

LOG_ARCHIVE_FORMAT Ce paramètre définit le format souhaité pour le nom des archives.  Le format doit inclure les variables suivantes :  %s ou %S  Numéro de séquence du fichier de journalisation.  %t ou %T  Numéro d’instance (thread).  %r ou %R  Identifiant de remise à zéro des fichiers de journalisation (voir la section Récupération).  Lorsque le nom de la variable est en majuscules, le nombre est complété à gauche par des 0.  Exemple :  LOG_ARCHIVE_FORMAT = "redo_%S_%R_%T.arc" LOG_ARCHIVE_DEST et LOG_ARCHIVE_DUPLEX_DEST Le  paramètre  LOG_ARCHIVE_DEST  définit  une  première  destination  de  l’archivage  et  le  paramètre  LOG_ARCHIVE_DUPLEX_DEST  une  deuxième  destination  d’archivage  (dupliquée).  Ces  paramètres  sont  utilisables  en  Standard Edition.  Syntaxe  LOG_ARCHIVE_[DUPLEX_]DEST = "chemin_local" Exemple :  LOG_ARCHIVE_DEST = "h:\oradata\arch\HERMES" LOG_ARCHIVE_DEST_n (n de 1 à 10) Ces  paramètres  définissent  jusqu’à  10  destinations  parallèles  d’archivage.  Ils  sont  utilisables  uniquement  en  Enterprise Edition.  Syntaxe simplifiée pour une destination locale (au moins une obligatoire)  LOG_ARCHIVE_DEST_n = "LOCATION=chemin_local" Exemple :  LOG_ARCHIVE_DEST_1 = "LOCATION=h:\oradata\arch\HERMES" Les  paramètres  LOG_ARCHIVE_DEST_n  permettent  de  spécifier  plusieurs  destinations  parallèles  pour  les  archives ; parmi les destinations, une au moins doit être locale. En dehors d’une destination disque ou bande, il est  possible de désigner une base de secours comme cible (configuration Data Guard) ; cette technique avancée permet  d’avoir une base de données sur un deuxième serveur vers laquelle il est possible de basculer en cas de problème  sur  la  base  de  données  source : la  base  de  données  de  secours  est  mise  à  jour  par  transfert  et  application  des  fichiers de journalisation archivés.  Dans  la  spécification  de  la  destination,  il  ne  faut  pas  mettre  d’espace  autour  du  signe  =   dans  la  clause  LOCATION.  D’autres  paramètres  permettent  de  piloter  le  fonctionnement  des  destinations  multiples  (destinations  obligatoires,  facultatives, nombre minimum de destinations réussies, etc.).  Remarques sur les destinations d’archivage

- 2-

© ENI Editions - All rights reserved - Algeria Educ

L’archivage  direct  sur  bande  pouvant  être  long  (et  bloquer  >LGWR  si  l’archivage d’un  fichier  de  journalisation  n’est  pas  terminé),  une  technique  classique  consiste  à  archiver  sur  disque,  au  niveau  d’Oracle,  puis  à  transférer  les  archives sur bande au niveau du système d’exploitation (par un processus non Oracle à mettre en place).  Les répertoires de destination ne sont pas créés par Oracle ; c’est à vous de le faire.  Si  aucune  destination  d’archivage  n’est  définie,  mais  qu’une  zone  de  récupération  rapide  soit  spécifiée  (paramètre  DB_RECOVERY_FILE_DEST), la zone de récupération rapide est utilisée comme destination d’archivage.  ARCHIVE_LAG_TARGET Ce paramètre permet de définir une durée maximale en secondes entre deux archivages.  Une valeur nulle désactive la fonctionnalité (valeur par défaut). Les valeurs autorisées sont comprises entre 60 (une  minute) et 7 200 (2 heures). Ce paramètre permet de forcer l’archivage de façon périodique et donc de garantir une  périodicité d’archivage stable, indépendante de la fréquence de basculement des fichiers de journalisation qui peut  varier en fonction du moment de la journée.  Exemple :  ARCHIVE_LAG_TARGET = 1800 # 30 minutes S’il n’y a rien à archiver, Oracle ne génère pas d’archive.  À l’origine, ce paramètre est destiné au fonctionnement de l’instance dans une configuration Data Guard. Dans cette  configuration,  le  paramètre  ARCHIVE_LAG_TARGET  détermine  la  durée  maximale  d’informations  de  journalisation  qui  seraient perdues (non transférées sur la base de données de secours) en cas de plantage de la base de données  principale.  Le  paramètre  fonctionne  même  si  la  configuration  Data  Guard  n’est  pas  utilisée,  et  même  s’il  n’y  a  pas  archivage ; dans ce dernier cas, le paramètre conditionne la fréquence de basculement des fichiers de journalisation. 

4. Trouver des informations sur l’archivage  Dans SQL*Plus, vous pouvez utiliser la commande  ARCHIVE LOG LIST(dans une connexion  SYSDBA) pour obtenir des  informations sur l’archivage ;  SQL> CONNECT / AS SYSDBA Connecté. SQL> ARCHIVE LOG LIST mode Database log mode Archive Archivage automatique Activé Destination de l’archive h:\oradata\arch\HERMES Séquence de journal en ligne la plus ancienne 19 Séquence de journal suivante à archiver 21 Séquence de journal courante 21 Plusieurs vues du dictionnaire de données permettent d’obtenir des informations sur l’archivage :  ●

V$DATABASE : mode de fonctionnement de la base de données (colonne LOG_MODE) ;> 

●

V$LOG : statut des groupes vis­à­vis de l’archivage (colonne ARCHIVED) ; SELECT log_mode FROM v$database; LOG_MODE -----------ARCHIVELOG SQL> SELECT group#,sequence#,status,archived 2 FROM v$log; GROUP# SEQUENCE# STATUS ARC ---------- ---------- ---------------- --1 25 INACTIVE YES 2 26 CURRENT NO 3 24 INACTIVE YES SQL> SELECT sequence#,name FROM v$archived_log; SEQUENCE# NAME ---------- ---------------------------------------------------20 H:\ORADATA\ARCH\HERMES\REDO_00020_0545650779_001.ARC ... SQL> SELECT destination,status,error FROM v$archive_dest 2 WHERE dest_name=’LOG_ARCHIVE_DEST_1’;

- 4-

© ENI Editions - All rights reserved - Algeria Educ

DESTINATION --------------------------------------------------------STATUS ERROR --------- ----------------------------------------------h:\oradata\arch\HERMES ERROR ORA-19504: échec de création du fichier ""

5. Problème courant et solution  L’archivage peut être bloqué lorsqu’il y a un problème avec la destination d’archivage :  ●

plus d’espace disponible ; 

●

destination inaccessible. 

Cela peut conduire à un blocage de LGWR si tous les fichiers de journalisation en ligne ont besoin d’être archivés.  Une telle situation est détectable grâce à la vue V$ARCHIVE_DEST (colonne STATUS) ou par des messages dans le fichier  des alertes de l’instance :  Sun Aug 3 12:43:25 2008 Errors in file d:\oracle\admin\hermes\bdump\hermes_arc1_1504.trc: ORA-19504: échec de création du fichier "H:\ORADATA\ARCH\HERMES\ REDO_00029_0545650779_001.ARC" ORA-27044: impossible d’écrire le bloc d’en-tête du fichier OSD-04008: échec de Writefile() ; écriture impossible dans le fichier O/S-Error: (OS 112) Espace insuffisant sur le disque. Pour débloquer la situation, il suffit de résoudre le problème qui existe sur la destination d’archivage, par exemple en  déplaçant des archives vers une autre destination afin de libérer de l’espace.  Si vous ne pouvez pas résoudre le problème avec la destination d’archivage, modifiez temporairement la destination  d’archivage :  ALTER SYSTEM SET log_archive_dest_1=’LOCATION=d:\temp’ SCOPE=MEMORY; Il peut être nécessaire ensuite d’exécuter  l’ordre SQL  ALTER SYSTEM ARCHIVE LOG START  pour  relancer  le  processus  d’archivage. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 5-

Présentation du Recovery Manager  1. Introduction  RMAN est un outil ligne de commande qui permet de réaliser des sauvegardes et des récupérations d’une  base  de  données appelée base de données cible (target database).  RMAN utilise un référentiel (repository) pour stocker des informations sur sa configuration, les sauvegardes réalisées,  la structure de la base cible, les fichiers de journalisation archivés, etc.  Ce  référentiel  est  toujours  stocké  dans  le  fichier  de  contrôle  de  la  base  cible.  La  durée  de  conservation  des  informations  dans  le  fichier  de  contrôle  est  déterminée  par  le  paramètre  d’initialisation  CONTROL_FILE_RECORD_KEEP_TIME (7 jours par défaut).  Le référentiel peut aussi être stocké dans un catalogue de récupération (recovery catalog) qui se matérialise par un  schéma  dans  une  autre  base  de  données.  Un  seul  catalogue  de  récupération  peut  être  utilisé  pour  centraliser  les  référentiels  RMAN  de  plusieurs  bases  de  données  cibles.  Employer  un  catalogue  de  récupération  séparé  est  intéressant car les informations de sauvegarde sont préservées si tous les fichiers de contrôle de la base cible sont  perdus.  Les  fichiers  de  contrôle  sont  donc  encore  plus  importants  lorsque  vous  utilisez  RMAN  sans  catalogue  de  récupération. Si vous perdez tous les fichiers de contrôle de la base cible, RMAN n’a plus d’informations sur  les  sauvegardes  disponibles.  Si  vous  repartez  d’une  sauvegarde  de  fichier  de  contrôle,  RMAN  n’aura  pas  d’informations sur les sauvegardes réalisées après la sauvegarde du fichier de contrôle. Si vous n’utilisez pas de  catalogue  de  récupération,  vous  avez  également  intérêt  à  augmenter  la  valeur  du  paramètre  CONTROL_FILE_RECORD_KEEP_TIME (au moins 10 à 15 jours).  Si  vous  définissez  une  zone  de  récupération  rapide  (flash  recovery  area),  à  l’aide  des  paramètres  DB_RECOVERY_FILE_DEST et DB_RECOVERY_FILE_DEST_SIZE, vous pouvez bénéficier des fonctionnalités de sauvegarde et  de restauration automatiques sur disque proposées par RMAN. En complément, vous pouvez définir une politique de  conservation  (retention  policy)  indiquant  combien  de  temps  une  sauvegarde  doit  être  conservée.  RMAN  se  charge  alors de gérer l’espace de la zone de récupération rapide en supprimant, si nécessaire, les sauvegardes obsolètes ou  les sauvegardes recopiées sur bande.  Pour  chaque  opération  de  sauvegarde,  copie,  restauration,  RMAN  utilise  un  canal  (channel).  Un  canal  est  une  connexion  entre  le  client  RMAN  et  un  processus  serveur  de  la  base  de  données  cible  qui  accède  à  un  périphérique  (disque ou bande).  Une  sauvegarde  RMAN  peut  se  faire  sous  la  forme  d’une  copie  image  (image  copy)  ou  d’un  jeu  de  sauvegarde  (backup  set).  Une  copie  image  est  une  copie  à  l’identique  du  fichier  (analogue  à  une  copie  par  une  commande  du  système d’exploitation). Un jeu de sauvegarde contient un ou plusieurs fichiers sauvegardés. Un jeu de sauvegarde  comprend  un  ou  plusieurs  fichiers ; chaque  fichier  d’un  jeu  est  appelé  élément  de  sauvegarde  (backup  piece).  Par  défaut, un jeu de sauvegarde comprend un seul élément de sauvegarde, mais il est possible de limiter la taille de ces  éléments ; dans ce cas, un jeu de sauvegarde peut contenir plusieurs éléments de sauvegarde si la taille totale de la  sauvegarde est supérieure à la limite. Le jeu de sauvegarde a un format propriétaire RMAN.  Pour réaliser des sauvegardes sur bande, RMAN s’interface avec un logiciel de gestion de média fourni par le vendeur  du système de sauvegarde.  RMAN offre un très grand nombre de fonctionnalités et d’options et peut être utilisé de différentes manières. Dans cet  ouvrage,  nous  présenterons  les  fonctionnalités  de  base  de  RMAN,  nécessaires  et  suffisantes  pour  mettre  en  place  des  stratégies  de  sauvegarde/récupération  simples,  adaptées  à  un  grand  nombre  de  cas.  Nous  supposerons  notamment  qu’une  zone  de  récupération  rapide  a  été  définie,  ce  qui  permet  de  simplifier  un  grand  nombre  d’opérations, et qu’aucun catalogue de récupération séparé n’a été mis en place.  Les fonctionnalités de base de RMAN sont décrites dans la documentation  Oracle® Database Backup and Recovery  User’s Guide. 

2. Lancer RMAN  Pour lancer RMAN, il suffit d’exécuter la commande rman à l’invite du système d’exploitation.  Syntaxe  rman [liste_options] Les options suivantes peuvent être utilisées :    © ENI Editions - All rights reserved - Algeria Educ

- 1-

TARGET [=] connexion  Chaîne de connexion à la base de données cible.  CATALOG [=] connexion  Chaîne de connexion à la base de données du catalogue de récupération.  CMDFILE [=] fichier  Chemin vers un fichier contenant des commandes RMAN à exécuter.  LOG [=] fichier  Chemin vers un fichier journal de l’activité RMAN.  APPEND  Indique que le fichier journal doit être ouvert en mode ajout.  USING valeur [...]  Définit  une  ou  plusieurs  valeurs  pour  des  variables  de  substitution  qui  peuvent  être  utilisées  dans  un  fichier  de  commandes RMAN. Dans le fichier de commande RMAN, les variables de substitution sont définies par la syntaxe &n  (éventuellement suivi d’un point), n étant un entier. 

Les  principes  de  connexion  à  la  base  cible  sont  les  mêmes  qu’avec  SQL*Plus : utilisation  par  défaut  des  variables  d’environnement  (ORACLE_SID,  LOCAL,  TWO_TASK),  utilisation  d’un  nom  de  service  réseau,  etc.  Les  variables d’environnement  comme NLS_DATE_FORMATetNLS_LANG  influent  aussi  sur  le  format  des  dates  et  la  langue  des messages affichés par RMAN. Par ailleurs, la connexion à la base cible s’effectue implicitement AS SYSDBA.  Exemple :  ●

Lancer RMAN sans se connecter 

> rman Recovery Manager: Release 11.1.0.6.0 - Production on Lun. Août 4 07:37:14 2008 Copyright (c) 1982, 2007, Oracle. All rights reserved. RMAN> ●

Lancer  RMAN  en  se  connectant  à  la  base  cible  (utilisation  des  variables  d’environnement  et  authentification  SYSDBA par le système d’exploitation) 

> rman target / Recovery Manager: Release 11.1.0.6.0 - Production on Lun. Août 4 07:48:22 2008 Copyright (c) 1982, 2007, Oracle. All rights reserved. connecté à la base de données cible : H E R M E S ( D B I D = 3 5 3 5 8 9 2 6 4 7 ) ●

Lancer  RMAN  en  se  connectant  à  la  base  cible  (utilisation  d’un  nom  de  service  réseau  et  authentification  SYSDBA par un fichier de mot de passe) 

> rman target sys/wX#12@hermes ... ●

Lancer RMAN et exécuter un fichier de commande (qui effectue la connexion) 

> rman cmdfile=backup.rcv log=backup.log append ... Si vous n’utilisez  pas  l’option CMDFILE, RMAN est lancé en mode interactif ; il affiche une invite et vous pouvez saisir 

- 2-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

des commandes. Avec l’option CMDFILE, RMAN est lancé en mode batch ; il exécute les commandes contenues dans le  fichier de commande puis quitte.  Chaque base de données possède un identifiant unique appelé DBID. Le DBID de la base cible est affiché par  RMAN  lorsque  vous  vous  connectez.  Vous  avez  intérêt  à  noter  ce  DBID  quelque  part,  il  peut  en  effet  se  révéler utile pour certaines opérations. 

3. Quelques commandes utiles  Certaines  commandes  RMAN  doivent  se  terminer  par  un  point­virgule,  d’autres  non  (point­virgule  optionnel).  Les  commandes  RMAN  nécessitant  un  point­virgule  peuvent  être  saisies  sur  plusieurs  lignes,  les  autres  non.  Les  commandes RMAN sont saisies indifféremment en majuscules ou en minuscules.  Les commandes suivantes peuvent être utilisées dans RMAN :  @fichier  Exécute un fichier de commande.  @@fichier  Exécute un fichier de commande dans le même répertoire que le fichier de commande actuel.  SET ECHO ON | OFF  Active ou désactive l’écho des commandes.  SPOOL LOG TO fichier [APPEND]  Écrit la sortie RMAN dans un fichier.  SPOOL LOG OFF  Arrête l’écriture de la sortie RMAN dans un fichier.  STARTUP [option]  Démarre la base de données ; les options sont les mêmes que dans SQL*Plus.  SHUTDOWN [option]  Arrête la base de données ; les options sont les mêmes que dans SQL*Plus.  ALTER DATABASE MOUNT | OPEN ;  Monte ou ouvre une base de données.  CONNECT CATALOG connexion  Établit une connexion à la base de données du catalogue.  CONNECT TARGET connexion  Établit une connexion à la base de données cible.  HOST [’commande’] ; HOST ["commande"] ;  Exécute  une  commande  du  système  d’exploitation  ou  ouvre  une  session  du  système  d’exploitation  (si  aucune  commande n’est spécifiée).  SQL ’requête’ ; SQL "requête" ; 

© ENI Editions - All rights reserved - Algeria Educ

- 3-

Exécute une requête SQL sur la base de données cible. La requête ne doit pas se terminer par un point­virgule ; si  elle contient des apostrophes, elles doivent être doublées.  EXIT ou QUIT  Quitte RMAN.  Exemple de script RMAN:  # ceci est un commentaire SPOOL LOG TO d:\rman.log SET ECHO ON CONNECT TARGET / SHUTDOW MOUNT SQL "ALTER DATABASE ARCHIVELOG"; ALTER DATABASE OPEN; SPOOL LOG OFF SET ECHO OFF Si  vous  souhaitez  placer  un  commentaire  en  fin  de  ligne,  vous  devez  terminer  la  commande  par  un  point­virgule  (même si le point­virgule est optionnel pour la commande).  Par ailleurs, il est possible de grouper des commandes RMAN dans un bloc délimité par des accolades et d’exécuter ce  bloc avec la commande RUN :  RUN { ... } Certaines  commandes  (ALLOCATE CHANNEL, SET)  exécutées  à  l’intérieur d’un  bloc  ont  une  portée  limitée  au  bloc.  Par  ailleurs, si une commande du bloc échoue, l’exécution du bloc s’arrête.  Certaines commandes RMAN doivent être exécutées à l’intérieur d’un bloc (ALLOCATE CHANNEL par exemple) ; d’autres  ne peuvent pas être exécutées dans un bloc (SPOOL par exemple). 

4. Configurer RMAN  RMAN dispose de plusieurs réglages persistants utilisés par défaut lors des différentes opérations.  La configuration actuelle peut être visualisée en exécutant la commande SHOW ALL.  Exemple :  RMAN> SHOW ALL ; utilisation du fichier de contrôle de la base de données cible au lieu du catalogue de récupération les paramètres de configuration RMAN de la base de données ayant le db_unique_name HERMES sont les suivants : CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ’%F’; # default CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM ’AES128’; # default CONFIGURE COMPRESSION ALGORITHM ’BZIP2’; # default CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO ’D:\APP\ORACLE\PRODUCT\11.1.0\DB_1\ DATABASE\SNCFHERMES.ORA’; # default Le commentaire # default indique que le paramètre est égal à sa valeur par défaut. 

- 4-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

La commande  CONFIGURE  permet  de  modifier  les  réglages  persistants ; la  commande  SHOW ALL  montre  la  valeur  des  réglages en utilisant la syntaxe de la commande CONFIGURE.  Les principaux réglages sont les suivants :  Configurer les canaux et les périphériques Par  défaut,  le  périphérique  utilisé  est  le  disque  (paramètre  DEFAULT DEVICE TYPE),  la  destination  par  défaut  des  sauvegardes étant la zone de récupération rapide. Si cette dernière n’est pas définie, RMAN utilise une destination  par défaut qui dépend de la plate­forme.  Si vous souhaitez configurer la destination de sauvegarde, vous pouvez utiliser la commande suivante :  CONFIGURE CHANNEL DEVICE TYPE DISK options ; La clause options peut prendre une ou plusieurs valeurs dont :  FORMAT ’format’ Chemin et format de nom de fichier pour la sauvegarde.  MAXPIECESIZE taille [K|M|G] Taille maximale des éléments de sauvegarde. Aucune limite par défaut.  Exemple :  CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ’h:\backup\%U’ MAXPIECESIZE 2G ; Dans cet exemple, la taille des éléments de sauvegarde est limitée à 2 Go. Si la taille de la sauvegarde est supérieure  à 2 Go, le jeu de sauvegarde contiendra plusieurs éléments de sauvegarde.  L’option format comprend un chemin et un format de fichier. Le format de fichier utilise généralement une ou plusieurs  des variables suivantes :  %U  Nom de fichier unique dont la composition dépend de la nature de la sauvegarde :  ­ %u_%p_%c pour un élément de sauvegarde ;  ­ data-D-%d_id-%I_TS-%N_FNO-%f_%u pour une copie image d’un fichier de données ;  ­ arch-D_%d-id-%I_S-%e_T-%h_A-%a_%u pour une copie image d’un fichier de journalisation archivé ;  ­ cf-D_%d-id-%I_%u pour une copie image du fichier de contrôle.  %d  Nom de la base de données.  %I  Identifiant de la base de données (DBID).  %h  Numéro d’activation de la base de données.  %N  Nom du tablespace.  %f  Numéro de fichier de données.    © ENI Editions - All rights reserved - Algeria Educ

- 5-

%e  Numéro de séquence du fichier de journalisation archivé.  %h  Numéro d’instance (thread) du fichier de journalisation archivé.  %s  Numéro du jeu de sauvegarde (backup set).  %p  Numéro de l’élément de sauvegarde (backup piece) à l’intérieur d’un jeu de sauvegarde.  %c  Numéro  de  copie  de  l’élément  de  sauvegarde  (cas  d’une  sauvegarde  multiplexée).  1  si  la  sauvegarde  n’est  pas  multiplexée.  %u  Chaîne unique de 8 caractères basée sur le numéro du jeu de sauvegarde ou de la copie image et de la date/heure  de la sauvegarde/copie. 

Si vous utilisez des formats personnalisés, assurez­vous que le nom de fichier généré est unique, sous peine  d’écraser d’autres sauvegardes.  Dans  la  commande  CONFIGURE CHANNEL DEVICE TYPE DISK,  une  option  non  spécifiée  est  remise  à  sa  valeur  par  défaut ; la valeur précédente n’est pas conservée.  Pour modifier la taille maximale des éléments de sauvegarde, en remettant le format par défaut, vous pouvez utiliser  la commande suivante :  CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 4G ; Pour revenir à la configuration par défaut, vous pouvez employer la commande suivante :  CONFIGURE CHANNEL DEVICE TYPE DISK CLEAR ; Configurer la politique de conservation La politique de conservation peut être définie en termes de fenêtre de restauration ou de redondance.  Une  fenêtre  de  restauration  indique  jusqu’à  combien  de  jours  dans  le  passé  vous  souhaitez  pouvoir  revenir.  Une  redondance indique combien de sauvegardes de chaque fichier doivent être conservées ; c’est la politique par défaut  (avec une redondance de 1).  Pour définir la politique de conservation, utilisez une des commandes suivantes :  ●

Fenêtre de restauration 

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF n DAYS ; ●

Redondance 

CONFIGURE RETENTION POLICY TO REDUNDANCY n ; Lorsque la zone de récupération rapide est utilisée, RMAN supprime automatiquement les sauvegardes obsolètes (s’il  a  besoin  de  place),  en  s’appuyant  sur  la  politique  de  conservation  par  défaut  et  sur  la  taille  allouée  à  la  zone  de  récupération rapide (paramètre DB_RECOVERY_FILE_DEST_SIZE).  Pour revenir à la configuration par défaut, vous pouvez utiliser la commande suivante : 

- 6-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

CONFIGURE RETENTION POLICY CLEAR ; Configurer la sauvegarde automatique du fichier de contrôle La sauvegarde automatique du fichier de contrôle peut être activée grâce à la commande suivante :  CONFIGURE CONTROLFILE AUTOBACKUP ON ; Lorsque  la  sauvegarde  automatique  du  fichier  de  contrôle  est  activée,  le  fichier  de  contrôle  est,  par  défaut,  sauvegardé dans la zone de récupération rapide.  Si  vous  souhaitez  définir  une  destination  de  sauvegarde  par  défaut  spécifique,  vous  pouvez  utiliser  la  commande  suivante :  CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ’format’ ; L’option format ne peut et ne doit inclure que la variable %F (nom unique basé sur l’identifiant de la base de données,  la date et un numéro de séquence hexadécimal). Remplacez TO ’format’ par CLEAR pour revenir au format par défaut.  Activer  la  sauvegarde  automatique  du  fichier  de  contrôle  active  aussi  la  sauvegarde  automatique  du  fichier  de  paramètres  serveur.  Lorsque  la  sauvegarde  automatique  est  activée,  ces  deux  fichiers  sont  automatiquement  sauvegardés  à  chaque  fois  qu’une  modification  de  structure  de  la  base  de  données  ou  une  sauvegarde  RMAN  est  enregistrée dans le fichier de contrôle.  Activer la sauvegarde automatique du fichier de contrôle est vivement conseillé, surtout si vous n’utilisez pas  de  catalogue  de  récupération  séparé  pour  RMAN.  En  cas  de  perte  de  tous  les  fichiers  de  contrôle,  RMAN  pourra restaurer ces derniers à partir d’une sauvegarde automatique. 

5. Utilisation de la zone de récupération rapide  Oracle  conseille  vivement  d’utiliser  une  zone  de  récupération  rapide  pour  bénéficier  d’un  certain  nombre  de  fonctionnalités automatiques relatives aux opérations de sauvegarde et de récupération.  Si une zone de récupération rapide est configurée, elle est utilisée comme destination par défaut des sauvegardes et  de  plusieurs  autres  fichiers  (par  exemple,  les  fichiers  de  journalisation  archivés  si  aucune  destination  d’archivage  n’est définie).  Le  quota  d’espace  alloué  à  la  zone  de  récupération  rapide  (paramètre  DB_RECOVERY_ FILE_DEST_SIZE)  doit  être  spécifié  avec  soin,  en  tenant  compte  de  la  taille  des  fichiers  qui  y  sont  stockés  (sauvegardes  notamment)  et  de  la  politique de conservation des sauvegardes.  Du  point  de  vue  de  la  sécurité,  il  est  vivement  conseillé  d’utiliser  un  disque  séparé  pour  la  zone  de  récupération rapide.  Les  fichiers  générés  par  Orale  dans  la  zone  de  récupération  rapide  sont  stockés  dans  différents  sous­répertoires,  avec des formats de nom de fichiers spécifiques. Ce sont des fichiers "gérés par Oracle" (Oracle­Managed Files).  Les différents répertoires sont définis sous la forme suivante :  ●

/[/] (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).    Sous­répertoire  correspondant  au  type  de  fichier : archivelog  (fichier  de  journalisation  archivé),  autobackup  (sauvegarde automatique du fichier de contrôle et du fichier de paramètres serveur), backupset (jeu de sauvegarde), 

© ENI Editions - All rights reserved - Algeria Educ

- 7-

controlfile (copie image de fichier de contrôle), datafile (copie image de fichier de données).    Identique à  mais en majuscules.    Sous­répertoire  correspondant  à  la  date  (au  format  AAAA_MM_JJ).  N’existe  pas  pour  les  répertoires  controlfile  et  datafile.  Les règles de nommage des fichiers gérés par Oracle sont les suivantes :  Type de fichier 

Format 

Fichier de journalisation archivé 

o1_mf__<s>__.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 ;  <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 ci­après).  La  commande  BACKUP VALIDATE DATABASE  peut  être  utilisée  pour  vérifier  que  la  base  de  données  est  en  "bon  état" (aucun fichier inaccessible, aucun fichier corrompu).  © ENI Editions - All rights reserved - Algeria Educ

- 3-

3. Sauvegarde de tablespaces ou de fichiers de données individuels  Pour  sauvegarder  individuellement  quelques  tablespaces  ou  quelques  fichiers  de  données,  vous  pouvez  utiliser  les  options TABLESPACE et/ou DATAFILE dans la commande BACKUP.  Exemple :  BACKUP TABLESPACE data,indx ; BACKUP DATAFILE 1,2,’E:\ORADATA\HERMES\DEFTBS01.DBF’ ; BACKUP TABLESPACE system DATAFILE 5 ; Les options  TABLESPACE et  DATAFILE peuvent être utilisées simultanément dans la même commande. Un tablespace  est  désigné  par  son  nom  et  un  fichier  de  données  par  son  numéro  ou  par  son  nom.  Lors  de  la  sauvegarde  d’un  tablespace,  RMAN  utilise  les  informations  du  fichier  de  contrôle  de  la  base  cible  pour  définir  la  liste  des  fichiers  de  données du tablespace et les sauvegarder. 

4. Sauvegarde du fichier de contrôle et du fichier de paramètres serveur  Le fichier de contrôle et le fichier de paramètres serveur sont sauvegardés automatiquement dans deux cas :  ●

Lorsque la sauvegarde automatique du fichier de contrôle a été activée. 

●

Lorsque le fichier de données numéro 1 (le premier fichier de données du tablespace SYSTEM) est sauvegardé. 

Dans  les  autres  cas,  le  fichier  de  contrôle  peut  être  explicitement  sauvegardé  en  utilisant  les  options  CURRENT CONTROLFILE ou INCLUDE CURRENT CONTROLFILE dans la commande BACKUP. De même, le fichier de paramètres serveur  peut être explicitement sauvegardé en utilisant l’option SPFILE.  Exemple :  BACKUP TABLESPACE data,indx INCLUDE CURRENT CONTROLFILE ; BACKUP CURRENT CONTROLFILE ; BACKUP AS COPY CURRENT CONTROLFILE ;BACKUP SPFILE ; Si la sauvegarde automatique du fichier de contrôle a été activée, le fichier de contrôle ou le fichier de paramètres  serveur sont sauvegardés en double lorsqu’ils sont explicitement sauvegardés.  Le fichier de contrôle et le fichier de paramètres serveur sont sauvegardés dans un jeu de sauvegarde séparé.  La  sauvegarde  automatique  du  fichier  de  contrôle  est  plus  intéressante  qu’une  sauvegarde  manuelle,  notamment  car  RMAN  peut  la  restaurer  automatiquement  en  cas  de  besoin  (ce  n’est  pas  le  cas  avec  une  sauvegarde  manuelle).  De  plus,  dans  cette  configuration,  le  fichier  de  contrôle  est  automatiquement  sauvegardé  lorsque la configuration des fichiers de la base de données change. 

5. Sauvegarde des fichiers de journalisation archivés  Si  les  fichiers  de  journalisation  ne  sont  pas  archivés  en  double  sur  des  disques  séparés,  ou  ne  sont  pas  archivés  dans la zone de récupération rapide (qui doit normalement être un disque séparé), il est vivement conseillé de les  sauvegarder ; ce sont eux en effet qui permettent de garantir une restauration complète.  Les  fichiers  de  journalisation  archivés  peuvent  être  sauvegardés  en  utilisant  les  options  ARCHIVELOG  ou  PLUS ARCHIVELOG dans la commande BACKUP.  Exemple :  BACKUP ARCHIVELOG ALL ; BACKUP ARCHIVELOG FROM TIME ’SYSDATE-1’ DELETE ALL INPUT ; BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG FROM TIME ’SYSDATE-7’ NOT BACKED UP 2 TIMES ; BACKUP DATABASE PLUS ARCHIVELOG ; BACKUP DATABASE PLUS ARCHIVELOG DELETE ALL INPUT ;

- 4-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

Dans  les  deux  cas,  si  les  fichiers  de  journalisation  sont  archivés  vers  plusieurs  destinations,  une  seule  copie  est  sauvegardée pour chaque numéro de séquence de journalisation.  La commande BACKUP ARCHIVELOG cible permet de sauvegarder les fichiers de journalisation désignés par la clause  cible. La clause cible offre différentes possibilités parmi lesquelles :  ALL  Tous les fichiers de journalisation archivés. Ne peut pas être combinée avec d’autres options.  FROM TIME ’date’  Tous les fichiers de journalisation archivés depuis une certaine date.  UNTIL TIME ’date’  Tous les fichiers de journalisation archivés avant une certaine date.  TIME BETWEEN ’date1’ AND ’date2’  Tous les fichiers de journalisation archivés entre deux dates.  Si la commande inclut le fichier de journalisation le plus récent (option ALL ou absence d’option UNTIL) et que la base  de donnée est ouverte, RMAN commence par archiver tous les fichiers de journalisation en ligne qui n’ont pas encore  été  archivés  (et  donc  notamment  le  courant).  De  cette  manière,  toute  l’activité  de  journalisation  générée  avant  le  début de la commande est sauvegardée.  La  commande  BACKUP ... PLUS ARCHIVELOG  permet  de  sauvegarder  les  fichiers  de  journalisation  en  plus  d’autres  éléments (mais dans un jeu de sauvegarde séparé). Cette commande effectue les opérations suivantes :  ●

●

archivage du fichier de journalisation courant ;  sauvegarde  de  tous  les  fichiers  de  journalisation  archivés  (équivalent  à  la  commande  BACKUP ARCHIVELOG ALL) ; 

●

sauvegarde des autres éléments ; 

●

de nouveau, archivage du fichier de journalisation courant ; 

●

sauvegarde des fichiers de journalisation archivés générés depuis le début de la sauvegarde. 

De  cette  manière,  toutes  les  sauvegardes  de  fichiers  de  données  effectuées  pendant  l’opération  (dans  un  état  incohérent) sont exploitables car tous les fichiers de journalisation nécessaires ont été sauvegardés.  Utilisation de l’option NOT BACKED UP L’option NOT BACKED UP peut être utilisée en plus, pour ne sauvegarder que les fichiers de journalisation archivés qui  n’ont pas déjà été sauvegardés un certain nombre de fois ou depuis un certain temps.  Utilisation de l’option DELETE [ALL] INPUT L’option  DELETE [ALL] INPUT  peut  être  utilisée  pour  supprimer  les  fichiers  de  journalisation  archivés  qui  viennent  d’être sauvegardés.  Si  les  fichiers  de  journalisation  sont  archivés  dans  une  seule  destination,  il  n’y  a  pas  de  différence  entre  l’option  DELETE INPUT et l’option DELETE ALL INPUT.  Si les fichiers de journalisation sont archivés vers plusieurs destinations, il y a une différence entre les deux options :  ●

DELETE INPUT supprime uniquement la copie du fichier de journalisation qui a été utilisé pour la sauvegarde. 

●

DELETE ALL INPUT supprime toutes les copies du fichier de journalisation sauvegardé. 

© ENI Editions - All rights reserved - Algeria Educ

- 5-

6. Sauvegarde incrémentale  Avec  RMAN,  il  est  possible  de  réaliser  des  sauvegardes  incrémentales,  de  la  totalité  de  la  base  de  données,  de  tablespaces individuels ou de fichiers de données individuels. L’objectif est de ne sauvegarder que les blocs qui ont  été  modifiés  depuis  la  dernière  sauvegarde.  Les  sauvegardes  incrémentales  présentent  comme  principal  intérêt  de  réduire la taille des sauvegardes, notamment lorsque l’activité de mise à jour est relativement faible sur la base de  données.  Pour  réaliser  une  sauvegarde  incrémentale,  il  suffit  d’inclure  l’option  INCREMENTAL LEVEL n [CUMULATIVE]  dans  la  commande BACKUP.  Exemple :  BACKUP INCREMENTAL LEVEL 0 DATABASE TAG=’dbinc0’ ; BACKUP INCREMENTAL LEVEL 1 DATABASE TAG=’dbinc1’ ; Une sauvegarde incrémentale peut être de niveau 0 ou de niveau 1, différentielle ou cumulative :  ●

●

Une  sauvegarde  incrémentale  de  niveau  0  sauvegarde  toujours,  tous  les  blocs  utilisés  des  fichiers  de  données.  Elle  est  équivalente  à  une  sauvegarde  complète  (mais  une  sauvegarde  complète  n’est  pas  considérée par RMAN comme une sauvegarde incrémentale de niveau 0).  Une  sauvegarde  incrémentale  différentielle  de  niveau  1  sauvegarde  tous  les  blocs  modifiés  depuis  la  dernière sauvegarde incrémentale de niveau 0 ou 1. C’est le comportement par défaut. 

 

●

Une sauvegarde incrémentale cumulative de niveau 1 sauvegarde tous les blocs modifiés depuis la dernière  sauvegarde incrémentale de niveau 0. 

  Les  sauvegardes  incrémentales  cumulatives  sont  plus  intéressantes  pour  la  rapidité  de  récupération  (moins  de  sauvegardes intermédiaires à appliquer), mais nécessitent plus d’espace disque.  Lors d’une sauvegarde incrémentale de niveau 1, RMAN est obligé de lire tous les blocs utilisés pour trouver ceux qui  ont  été  modifiés  et  doivent  donc  être  sauvegardés.  En  conséquence,  la  durée  de  la  sauvegarde  n’est  pas  sensiblement réduite par rapport à une sauvegarde de niveau 0 (pas de gain sur la lecture, simple gain sur l’écriture).  Si vous souhaitez réduire la durée de la sauvegarde, vous pouvez activer la fonctionnalité de trace des blocs modifiés  (block  change  tracking). Lorsque cette fonctionnalité est activée, Oracle garde une trace des blocs modifiés dans un  fichier. Lors d’une sauvegarde incrémentale de niveau 1, RMAN n’a plus besoin de parcourir tous les blocs utilisés ; il  emploie le fichier de trace des blocs modifiés pour identifier les blocs à sauvegarder.  Pour activer la fonctionnalité de trace des blocs modifiés, vous pouvez utiliser l’ordre SQL suivant (ce n’est pas une  commande RMAN) :  ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE ’fichier’; fichier donne le chemin complet et le nom du fichier de trace. 

- 6-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

Exemple d’activation à partir de RMAN en utilisant la commande SQL :  RMAN> SQL "ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE ’ ’F:\oradata\HERMES\block_change_tracking.trc’’"; Il  n’y  a  pas  de  recommandation  particulière  concernant  l’emplacement  du  fichier ; vous  pouvez  le  placer  dans  l’environnement de la base de données ou dans la zone de récupération rapide.  Le fichier de trace des blocs modifiés n’est pas spécialement volumineux ; Oracle annonce une taille de 1/30 000 de la  taille de tous les blocs à tracer, indépendante de la fréquence de mise à jour. Le fichier a une taille minimum de 10 Mo  et grossit par pas de 10 Mo.  La vue V$BLOCK_CHANGE_TRACKING <donne des informations sur la trace des blocs modifiés :  SQL> SELECT * FROM v$block_change_tracking; STATUS FILENAME BYTES ---------- ------------------------------------------- --------ENABLED F:\ORADATA\HERMES\BLOCK_CHANGE_TRACKING.TRC 11599872 Si le fichier de trace est perdu ou endommagé, la base de données ne pourra pas être ouverte (elle restera en état  MOUNT).  Pour  ouvrir  la  base,  il  faut  désactiver  la  trace,  et  éventuellement  la  réactiver  si  vous  souhaitez  continuer  à  utiliser la fonctionnalité. Il n’existe pas de possibilité de sauvegarde et de restauration du fichier de trace.  Pour déplacer le fichier de trace, vous pouvez utiliser l’ordre SQL ALTER DATABASE RENAME FILE, base montée.  Pour désactiver la fonctionnalité de trace des blocs modifiés, vous pouvez utiliser l’ordre SQL suivant :  ALTER DATABASE DISABLE BLOCK CHANGE TRACKING; Après activation de la trace, la première sauvegarde incrémentale de niveau 0 devra parcourir tous les blocs utilisés  car le fichier de trace ne reflète pas encore le statut des blocs. Il en est de même après une recréation du fichier de  trace.  Employer  ou  non  un  fichier  de  trace  des  blocs  modifiés  ne  change  rien  aux  commandes  à  utiliser  pour  réaliser  des  sauvegardes incrémentales. Si la fonctionnalité est active, RMAN l’exploite ; sinon il s’en passe.  Il  existe  une  autre  fonctionnalité  intéressante  concernant  les  sauvegardes  incrémentales : la  possibilité  de  réaliser  une  sauvegarde  sous  forme  de  copie  image  et  de  mettre  cette  copie  image  à  jour  par  application  régulière  de  sauvegardes incrémentales (Incrementally Updated Backup). Pour en savoir plus, consultez la documentation Oracle®  Database Backup and Recovery User’s Guide. 

7. Exemples de scénario  a. Préambule  Les scénarios présentés ici s’appuient sur deux hypothèses :  ●

Une zone de récupération rapide est utilisée. 

●

La sauvegarde automatique des fichiers de contrôle a été activée. 

b. Sauvegarde complète base fermée (cohérente)  Les commandes suivantes permettent de réaliser une sauvegarde complète base fermée (donc cohérente) :  SHUTDOWN IMMEDIATE ; STARTUP MOUNT ; BACKUP DATABASE ; SQL "ALTER DATABASE OPEN" ;

# # # #

arrêter la base monter la base sauvegarder la base ouvrir la base

Cette sauvegarde est un exemple typique de ce qui est fait lorsque la base fonctionne en mode NOARCHIVELOG. 

c. Sauvegarde complète base ouverte (incohérente) 

© ENI Editions - All rights reserved - Algeria Educ

- 7-

La  commande  suivante  permet  de  réaliser  une  sauvegarde  complète  base  ouverte  (donc  incohérente),  avec  sauvegarde  des  fichiers  de  journalisation  archivés,  et  suppression  des  fichiers  de  journalisation  archivés  sauvegardés :  BACKUP DATABASE PLUS ARCHIVELOG DELETE ALL INPUT; Cette sauvegarde ne peut être effectuée que lorsque la base fonctionne en mode ARCHIVELOG. 

d. Sauvegarde partielle base ouverte  Dans ce scénario, la totalité de la base est sauvegardée en trois fois sur trois jours :  ●

Sauvegarde 1 : fichiers de données 1 et 2 

BACKUP DATAFILE 1,2 PLUS ARCHIVELOG DELETE ALL INPUT; ●

Sauvegarde 2 : fichiers de données 3 et 4 

BACKUP DATAFILE 3,4 PLUS ARCHIVELOG DELETE ALL INPUT; ●

Sauvegarde 3 : le reste 

BACKUP DATABASE NOT BACKED UP SINCE TIME=’SYSDATE-3’ PLUS ARCHIVELOG DELETE ALL INPUT; Sur  le  principe,  c’est  une  variante  du  scénario  précédent.  La  commande  pour  la  troisième  sauvegarde  permet  de  sauvegarder tout ce qui n’a pas été sauvegardé depuis trois jours, y compris tout nouveau fichier de données.  Il est techniquement possible de réaliser des sauvegardes partielles, base fermée, mais ces sauvegardes ne sont  exploitables que si la base de données fonctionne en mode ARCHIVELOG. Donc, autant les réaliser base ouverte. 

e. Sauvegarde incrémentale  Dans ce scénario, des sauvegardes incrémentales cumulatives sont réalisées sur un cycle d’une semaine :  ●

Dimanche : sauvegarde incrémentale de niveau 0 

BACKUP INCREMENTAL LEVEL 0 DATABASE ; ●

Lundi au samedi : sauvegarde incrémentale cumulative de niveau 1 

BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE ; Dans cet exemple, nous supposons que la base de données fonctionne en mode ARCHIVELOG, ce qui nous permet de  réaliser  la  sauvegarde  base  ouverte ; pour  être  tout  à  fait  rigoureux,  il  faudrait  en  plus  s’occuper  des  fichiers  de  journalisation archivés (ajouter une clause PLUS ARCHIVELOG par exemple).  Ce  type  de  sauvegarde  peut  aussi  être  réalisé  si  la  base  de  données  fonctionne  en  mode  NOARCHIVELOG,  en  ajoutant les commandes suivantes :  SHUTDOWN IMMEDIATE ; STARTUP MOUNT ; BACKUP INCREMENTAL... ; SQL "ALTER DATABASE OPEN" ;

- 8-

openmirrors.com

# # # #

arrêter la base monter la base sauvegarder la base ici ouvrir la base

© ENI Editions - All rights reserved - Algeria Educ

Le référentiel RMAN  1. Trouver des informations sur les sauvegardes  a. La commande LIST  La commande LIST permet d’interroger le référentiel RMAN pour afficher des informations sur les sauvegardes et les  fichiers de journalisation archivés.  Syntaxe 1  LIST cible [ BY FILE | SUMMARY ] [ filtre_sauvegarde ]; - cible { BACKUP | COPY } [ OF objets ] BACKUPSET - objets DATABASE DATAFILE liste_numéros_ou_noms TABLESPACE liste_noms CONTROLFILE SPFILE ARCHIVELOG { ALL | filtre_archive } - filtre_archive FROM TIME ’date’ UNTIL TIME ’date’ TIME BETWEEN ’date1’ AND ’date2’ - filtre_sauvegarde TAG [=] ’nom’ COMPLETED { AFTER ’date1’ | BEFORE ’date2’ | BETWEEN ’date1’ AND ’date2’ } Syntaxe 2  LIST { BACKUPSET | BACKUPPIECE } { liste_clés | TAG [=] ’nom’ }; Syntaxe 3  LIST ARCHIVELOG { ALL | filtre_archive } [info_sauvegarde]; - info_sauvegarde BACKED UP n TIMES TO DEVICE TYPE [DISK | ’media’]   Toutes les options possibles ne sont pas présentées ici.

Première syntaxe La première syntaxe permet d’afficher des informations sur les sauvegardes enregistrées dans le référentiel RMAN.  Par défaut, les commandes LIST BACKUP, LIST COPY et LIST BACKUPSET listent tous les éléments enregistrés dans le  référentiel RMAN.  Dans  le  cas  des  commandes  LIST BACKUP  et  LIST COPY,  il  est  possible  de  spécifier  un  ou  plusieurs  objets  pour  n’afficher que les sauvegardes des objets en question.  Exemple :  LIST 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 ci­après est de montrer que tout n’est pas forcément perdu. En cas de  problème en mode NOARCHIVELOG, il ne faut pas hésiter à appeler le support Oracle pour tenter avec eux de  réaliser  la  récupération  la  plus  complète  possible.  Par  contre,  pour  être  certain  de  garantir  une  récupération  complète dans toutes les situations (et simplifier le processus de récupération), il faut faire fonctionner la base en  mode ARCHIVELOG.  Les situations sont les suivantes :  ●

●

●

Un cycle complet de basculement des fichiers de journalisation n’a pas eu lieu depuis la sauvegarde.  Le  fichier  de  données  perdu  n’est  pas  critique  pour  la  base  de  données  (n’appartient  pas  au  tablespace  SYSTEM, ni à au tablespace d’annulation  actif),  ni  pour  l’application  (ce  n’est pas le tablespace principal de  l’application).  Tous les fichiers de contrôle sont perdus mais les autres fichiers (données et journalisation) sont intacts. 

Si  les  fichiers  de  journalisation  n’ont  pas  subi  un  cycle  complet  de  basculements  depuis  la  sauvegarde  utilisée,  toutes les mises à jour effectuées depuis la sauvegarde en question sont encore "disponibles" dans les fichiers de  journalisation. Dans ce cas, il faut réaliser une récupération comme si la base de données était en mode ARCHIVELOG  (voir les scénarios correspondants).  Si le fichier de données perdu n’est pas critique pour la base de données ni pour l’application, et que le problème  soit survenu alors que la base de données était arrêtée, la situation est plutôt favorable car les fichiers qui restent  sont cohérents entre eux : si ce problème de fichier n’existait pas, le prochain démarrage ne nécessiterait pas de  récupération de l’instance.  Dans ce cas, il est possible :  ●

De démarrer la base de données en état MOUNT 

SQL> CONNECT / AS SYSDBA SQL> STARTUP MOUNT ●

De mettre les fichiers de donnés concernés OFFLINE avec l’option DROP 

SQL> ALTER DATABASE DATAFILE 2 ’e:\oradata\HERMES\indx01.dbf’ OFFLINE DROP; ●

D’ouvrir la base de données 

SQL> ALTER DATABASE OPEN;

- 2-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

●

De supprimer le tablespace 

SQL> DROP TABLESPACE indx; ●

Puis de recréer le tablespace (et éventuellement son contenu) 

SQL> CREATE TABLESPACE indx ... ; SQL> CREATE INDEX ... ; À l’arrivée, le tablespace est supprimé : cette technique n’est donc pas applicable si le fichier de données perdu est  critique  pour  la  base  de  données  ou  pour  l’application.  Elle  est,  par  contre,  envisageable  pour  des  tablespaces  contenant uniquement des index (les données, elles, ne sont pas perdues).  Si  le  problème  est  survenu  alors  que  la  base  était  en  fonctionnement,  la  situation  est  plus  problématique  car  les  fichiers de données restants ne sont peut­être pas cohérents et il n’existe pas vraiment de moyens de le savoir.  S’ils  ne  sont  pas  cohérents,  Oracle  aura  besoin  des  fichiers  de  journalisation  en  ligne  pour  les  rendre  cohérents  (c’est la récupération de l’instance "classique"). Si les fichiers de journalisation sont présents, ou si seuls les fichiers  de journalisation  INACTIVE  sont  perdus,  la  technique  présentée  précédemment  pourra  être  utilisée ; si  les  fichiers  de  journalisation CURRENT  ou ACTIVE  sont  perdus,  la  technique  ne  pourra  pas  être  employée  (il  faut  repartir  de  la  dernière sauvegarde).  Tous les fichiers de contrôle sont perdus. Dans cette situation critique et délicate, pour laquelle il existe différentes  possibilités de récupération, la documentation Oracle recommande de contacter le support Oracle. 

b. En mode ARCHIVELOG  En mode ARCHIVELOG, le mode opératoire de base pour une perte de fichier(s) de données est le suivant :  ●

restaurer la dernière sauvegarde de chaque fichier perdu ; 

●

appliquer les fichiers de journalisation (archives puis ceux en ligne) ; 

●

redémarrer la base (si la récupération n’a pas été faite base ouverte). 

Toutes  les  modifications  apportées  depuis  les  sauvegardes  utilisées  sont  récupérées.  La  récupération  est  dite  complète.  Ce  type  de  récupération  est  simple  et  ne  pose  pas  de  problème  s’il  reste  au  moins  un  fichier  de  contrôle,  un  membre  par  groupe  de  fichier  de  journalisation  et  que  toutes  les  archives  de  fichiers  de  journalisation  sont  disponibles.  Sur la base de ce scénario, différentes situations peuvent conduire à une récupération incomplète :  ●

●

volontairement, pour s’arrêter avant un ordre SQL malencontreux ;  involontairement, si des fichiers de journalisation sont perdus (une archive ou tout un groupe de fichiers de  journalisation en ligne). 

Dans la terminologie Oracle, une récupération incomplète est appelée point­in­time recovery.  Si tous les fichiers de contrôle sont perdus, si tout un groupe de fichiers de journalisation est perdu, ou s’il manque  une archive de fichiers de journalisation, la récupération complète sera plus délicate et dans certains cas impossible  (par  exemple,  s’il  manque  une  archive  de  fichier  de  journalisation) ; une  récupération  incomplète  reste  alors  possible et la base n’est pas ramenée à l’état où elle se trouvait juste avant l’incident mais à un état antérieur.  Dans certaines situations (suppression de table malencontreuse par exemple), la récupération incomplète peut être  volontaire ; là encore, la base de données n’est pas ramenée à l’état où elle se trouvait juste avant l’incident mais à  un état antérieur.  Quelle que soit l’origine de la récupération incomplète, tout ce qui a été fait, après le moment qui correspond à l’état  de récupération de la base, est perdu et doit être repris à la main : dans une séquence d’application des fichiers de  journalisation, Oracle ne peut pas "sauter" quelques ordres puis continuer.  Lors de la restauration des sauvegardes, si les sauvegardes sont partielles, il faut prendre la sauvegarde la plus  récente de chaque fichier endommagé. 

© ENI Editions - All rights reserved - Algeria Educ

- 3-

3. Les incidents sur les fichiers de contrôle et de journalisation  Les  incidents  sur  les  fichiers  de  contrôle  et  les  fichiers  de  journalisation  peuvent  être  classés  en  deux  catégories : "peu graves" et "très graves".  Incidents peu graves :  ●

perte d’un ou plusieurs fichiers de contrôle, du moment qu’il en reste au moins un ; 

●

perte d’un ou plusieurs fichiers de journalisation, du moment qu’il en reste au moins un par groupe. 

Incidents plus graves et plus complexes à traiter :  ●

●

perte de tous les fichiers de contrôle : moyennement grave si les autres fichiers sont intacts ;  perte de tous les membres d’un groupe de fichiers de journalisation : la gravité dépend du statut du groupe  perdu (CURRENT, ACTIVE, INACTIVE). 

Ces situations sont évitées si l’on multiplexe correctement les fichiers de contrôle et les fichiers de journalisation. La  perte  de  tous  les  fichiers  de  contrôle  n’est  pas  la  situation  la  plus  complexe  à  traiter,  s’il  existe  des  sauvegardes  récentes  du  fichier  de  contrôle  et  si  les  autres  fichiers  (particulièrement,  les  fichiers  de  journalisation)  sont  intacts ; dans ce cas, une récupération complète est possible.  La perte de tous les membres d’un groupe de fichiers de journalisation est bien plus complexe à traiter ; la situation  de départ doit être analysée avec soin (statut du groupe perdu, état des autres fichiers, etc.), afin de choisir le bon  mode opératoire. Pour les situations complexes, il est vivement conseillé de se faire aider par le support Oracle. 

4. Identifier la nature du problème  a. Message d’erreur concernant les fichiers de contrôle  Les messages d’erreurs les plus fréquents sur les fichiers de contrôle sont les suivants :  ORA-00204: erreur lors du fichier de contrôle ORA-00205: erreur lors de contrôle; consultez ORA-00206: erreur lors du fichier de contrôle

de la lecture (bloc, nbre blocs) de l’identification du fichier le journal des alertes de l’écriture (bloc, nbre blocs)

Ces messages indiquent qu’au moins un fichier de contrôle est endommagé ou perdu ; il faut consulter le fichier des  alertes  de  l’instance  pour  en  savoir  plus,  notamment  pour  déterminer  les  fichiers  endommagés  et  en  déduire  les  fichiers  intacts,  s’il  en  reste.  En  cas  de  problème  sur  un  fichier  de  contrôle,  l’instance  s’arrête.  Au  redémarrage,  l’instance reste en état NOMOUNT. 

b. Message d’erreur concernant les fichiers de journalisation  Les messages d’erreur les plus fréquents sur les fichiers de journalisation sont les suivants :  ORA-00313: échec d’ouverture des membres du groupe de journaux n, thread p ORA-00315: journal n, thread p, numéro de thread x incorrect dans en-tête ORA-00316: le journal n dans le thread p, type x dans l’en-tête, n’est pas un fichier journal ORA-00317: le type de fichier x dans l’en-tête n’est pas un fichier journal ORA-00318: journal n, thread p, taille x de fich. attendue ne correspond pas à y ORA-00319: journal n du thread p a un état de réinitialisation incorrect ORA-00320: impossible lire en-tête de fichier du journal n thread p ORA-00321: fichier n, thread p, impossible de mettre à jour l’en-tête du fichier journal

- 4-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

Ces messages s’accompagnent d’un ou plusieurs messages ORA-00312 donnant le nom du fichier :  ORA-00312: journal en ligne n thread p : fichier En cas de problème sur tout un groupe de fichiers de journalisation, l’instance s’arrête. Au redémarrage, l’instance  reste en état MOUNT.  En cas de problème, il faut consulter le fichier d’alerte de l’instance et le fichier de trace du processus LGWR. 

c. Message d’erreur concernant les fichiers de données  Il y a de nombreux messages d’erreur possibles concernant les fichiers de données, par exemple :  ORA-01157: impossible d’identifier ou de verrouiller le fichier de données n - voir le fichier de trace DBWR Ces messages s’accompagnent d’un ou plusieurs messages ORA-01110 donnant le nom du fichier :  ORA-01110: fichier de données n : fichier En mode NOARCHIVELOG, si la base de données est ouverte et qu’un problème se produise sur un fichier de données,  l’instance s’arrête. En mode ARCHIVELOG, il en est de même mais uniquement si le fichier de données incriminé est un  fichier du tablespace SYSTEM ou un fichier de données du tablespace d’annulation actif.  Au démarrage, l’instance reste en état MOUNT.  En  cas  de  problème,  il  faut  consulter  le  fichier  d’alerte  de  l’instance  et  le  fichier  de  trace  du  processus  DBWR.  D’autres fichiers, eux aussi endommagés, peuvent être cités.  Lorsque la base de données est montée ou ouverte, vous pouvez interroger la vue V$RECOVER_FILE pour déterminer  la liste des fichiers de données sur lesquels il existe un problème.  Les colonnes intéressantes de la vue V$RECOVER_FILE sont les suivantes :  FILE#  Identifiant du fichier (jointure sur V$DATAFILE.FILE# pour récupérer des informations complémentaires sur le fichier).  ONLINE_STATUS  Statut du fichier (ONLINE ou OFFLINE).  ERROR  Nature de l’erreur. Vide si l’erreur est inconnue et OFFLINE NORMAL si le fichier est hors ligne sans erreur (pas besoin  de restauration dans ce cas).  Exemple  SQL> SELECT file#,error,online_status FROM v$recover_file; FILE# ERROR ONLINE_ ---------- ------------------------------ ------5 FILE NOT FOUND ONLINE Sur cet exemple, le fichier de données 5 doit être restauré.  La  commande  VALIDATE endommagés. 

DATABASE  peut  aussi  être  utilisée  pour  identifer  les  fichiers  de  données  perdus  ou 

5. Les commandes RMAN  a. Introduction  Dans RMAN, les opérations de restauration et de récupération vont s’effectuer respectivement avec les commandes  RESTORE et RECOVER. 

© ENI Editions - All rights reserved - Algeria Educ

- 5-

La commande RESTORE permet de restaurer les fichiers à partir des sauvegardes. La commande RECOVER permet de  procéder à une récupération complète ou incomplète.  La syntaxe générale de ces deux commandes est du type :  { RESTORE | RECOVER } cible [options] ; Votre principale responsabilité, lorsque vous utilisez ces commandes, est de bien choisir la cible en fonction de la  nature  du  problème.  Ensuite,  RMAN  se  charge  normalement  de  tout : identifier  les  sauvegardes  à  utiliser,  et  en  extraire  les  fichiers  requis ; identifier  les  fichiers  de  journalisation  archivés  nécessaires  et  les  extraire  d’une  sauvegarde s’ils ont été sauvegardés puis supprimés.  Les options de ces deux commandes ne seront nécessaires que pour traiter des cas particuliers : sauvegarde non  disponible,  volonté  de  revenir  à  un  instant  dans  le  passé  (récupération  incomplète),  etc.  Dans  la  grande  majorité  des cas, vous ne devriez pas en avoir besoin.  Les  principes  de  fonctionnement  généraux  de  ces  commandes  vont  d’abord  être  présentés,  puis  nous  verrons  comment les utiliser dans différents scénarios de restauration.  Les  commandes  RESTORE  et  RECOVER  proposent  un  très  grand  nombre  d’options.  Dans  cet  ouvrage,  nous  présenterons uniquement les options les plus couramment utilisées. 

b. La commande RESTORE  La syntaxe simplifiée de la commande RESTORE est la suivante :  RESTORE cibles [options] - cibles DATABASE DATAFILE liste_numéros_ou_noms TABLESPACE liste_noms CONTROLFILE [TO ’destination’] [FROM AUTOBACKUP | ’sauvegarde’] SPFILE [TO ’destination’] [FROM AUTOBACKUP | ’sauvegarde’] ARCHIVELOG { ALL | filtre_archive } - filtre_archive FROM TIME ’date’ UNTIL TIME ’date’ TIME BETWEEN ’date1’ AND ’date2’ - options PREVIEW [SUMMARY] VALIDATE L’option cibles permet d’indiquer ce qu’il convient de restaurer. L’option DATABASE permet de restaurer la totalité de  la base de données ; elle ne doit être utilisée que si vous souhaitez ou devez effectivement restaurer la totalité de  la base de données. En mode ARCHIVELOG, si un fichier de données est endommagé, vous ne devrez restaurer que  le fichier en question, en utilisant les options DATAFILE ou TABLESPACE.  L’option  PREVIEW  est  intéressante  pour  lister  les  sauvegardes  dont  RMAN  a  besoin  pour  réaliser  l’opération  de  restauration  correspondante.  L’option  SUMMARY  permet  d’obtenir  un  affichage  résumé.  L’affichage  est  le  même  qu’avec la commande LIST.  L’option  VALIDATE  permet  de  tester  si  la  restauration  correspondante  peut  être  réalisée.  RMAN  accède  aux  sauvegardes  et  vérifie  qu’il  peut  en  extraire  les  fichiers  nécessaires.  Il  existe  aussi  une  commande  VALIDATE BACKUPSET qui permet de tester des jeux de sauvegarde spécifiques (voir la documentation Oracle). 

c. La commande RECOVER  La syntaxe simplifiée de la commande RECOVER est la suivante :  RECOVER cible [options] - cible DATABASE DATAFILE liste_numéros_ou_noms TABLESPACE liste_noms - options DELETE ARCHIVELOG [MAXSIZE taille [K|M|G]]

- 6-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

L’option  cible  permet  d’indiquer  ce  qu’il  convient  de  récupérer : la  base  de  données  dans  sa  totalité,  ou  des  tablespaces ou fichiers de données spécifiques.  Lors  de  l’opération  de  récupération,  RMAN  recherche  les  fichiers  de  journalisation  archivés  dont  il  a  besoin,  en  premier  lieu  sur  le  disque.  Les  fichiers  de  journalisation  archivés  manquants  sont  automatiquement  restaurés  à  partir de sauvegardes, vers le répertoire d’archivage défini par le paramètre LOG_ARCHIVE_DEST_1 (où vers une autre  destination ­ voir la commande SET ARCHIVELOG DESTINATION dans la documentation).  À  la  fin  de  l’opération,  les  fichiers  de  journalisation  archivés  restaurés  ailleurs  que  dans  la  zone  de  récupération  rapide,  ne  sont  pas  supprimés  par  défaut.  L’option  DELETE ARCHIVELOG  permet  de  supprimer  les  fichiers  de  journalisation  archivés  restaurés  qui  ne  sont  plus  nécessaires,  au  fur  et  à  mesure  de  leur  application.  L’option  MAXSIZE permet au besoin, de limiter l’espace utilisé par RMAN pour les fichiers de journalisation archivés restaurés.  Si cette option est spécifiée, RMAN procédera à la restauration des fichiers de journalisation archivés en plusieurs  étapes, pour ne pas dépasser la taille indiquée. Assurez­vous que la taille indiquée est supérieure à la taille des  fichiers de journalisation archivés, sinon vous obtiendriez une erreur.  La récupération peut utiliser des sauvegardes incrémentales ou des fichiers de journalisation archivés. Si RMAN a le  choix, il utilise en priorité les sauvegardes incrémentales. 

6. Scénarios de récupération  a. Présentation  Dans cet ouvrage, nous allons présenter les scénarios de récupération de base suivants :  ●

récupération du fichier de paramètres serveur ; 

●

récupération d’un fichier de contrôle ; 

●

récupération d’un fichier de journalisation ; 

●

récupération complète de la totalité de la base de données en mode ARCHIVELOG ; 

●

récupération complète d’une partie de la base de données en mode ARCHIVELOG ; 

●

récupération de tous les fichiers de contrôle en mode ARCHIVELOG ; 

●

récupération incomplète en mode ARCHIVELOG ; 

●

récupération en mode NOARCHIVELOG. 

En complément, nous évoquerons deux cas particuliers :  ●

récupération à un emplacement différent ; 

●

tablespace temporaire géré localement. 

Dans un cas de récupération réel, vous serez peut­être amenés à combiner plusieurs de ces scénarios de base. Par  exemple,  si  vous  avez  perdu  un  fichier  de  contrôle  et  un  tablespace,  et  si  vous  êtes  en  mode  ARCHIVELOG,  vous  appliquerez les scénarios suivants, dans l’ordre :  ●

récupération d’un fichier de contrôle ; 

●

récupération complète d’une partie de la base de données en mode ARCHIVELOG. 

En  règle  générale,  si  vous  avez  perdu  le  fichier  de  paramètres  serveur,  un  fichier  de  contrôle  et/ou  un  fichier  de  journalisation, vous devez d’abord résoudre ces problèmes avant de traiter le cas des fichiers de données.  Tous ces scénarios sont basés sur les hypothèses suivantes : 

© ENI Editions - All rights reserved - Algeria Educ

- 7-

●

Vous avez activé la sauvegarde automatique du fichier de contrôle et du fichier de paramètres serveur. 

●

Vous utilisez une zone de récupération rapide. 

●

Vous n’utilisez pas de base de données annexe pour stocker le catalogue RMAN. 

Quel que soit le scénario, si le fichier est en fait simplement temporairement inaccessible (contrôleur disque  en panne par exemple), une restauration n’est pas nécessaire ; il suffit de corriger le problème pour rendre  le fichier de nouveau disponible et de redémarrer la base. Une restauration est néanmoins envisageable s’il n’est  pas possible d’attendre que le problème soit corrigé. 

b. Récupération du fichier de paramètres serveur  En cas de perte du fichier de paramètres serveur, vous avez deux possibilités :  ●

Le recréer à partir d’un fichier de paramètres texte (voir le chapitre 7). 

●

Le récupérer à partir d’une sauvegarde RMAN. 

Pour le récupérer à partir d’une sauvegarde automatique RMAN située dans la zone de récupération rapide, le mode  opératoire est le suivant :  ●

Démarrer l’instance sans monter la base de données (notez que RMAN va utiliser un fichier de paramètres  "temporaire" pour démarrer l’instance) 

RMAN> STARTUP NOMOUNT échec du démarrage : ORA-01078: failure in processing system parameters LRM-00109: impossible d’ouvrir le fichier de paramètres ’D:\APP\ORACLE\PRODUCT\11.1.0\DB_1\DATABASE\INITHERMES.ORA’ démarrage de l’instance Oracle sans fichier de paramètres pour extraction de SPFILE instance Oracle démarrée Total System Global Area (SGA) 159019008 octets Fixed Size 1331852 octets Variable Size 67112308 octets Database Buffers 88080384 octets Redo Buffers 2494464 octets ●

Restaurer  le  fichier  de  paramètres  serveur  à  partir  d’une  sauvegarde  automatique  en  spécifiant  l’emplacement de la zone de récupération rapide et le nom (ou le nom unique) de la base de données 

RMAN> RESTORE SPFILE FROM AUTOBACKUP 2> DB_RECOVERY_FILE_DEST ’H:\oradata\flash_recovery_area’ 3> DB_NAME ’HERMES’; Démarrage de restore dans 05/08/08 utilisation du canal ORA_DISK_1 destination de la zone de récupération : H:\oradata\flash_recovery_area nom de base de données (ou nom unique de base de données) utilisé pour la recherche : HERMES canal ORA_DISK_1 : AUTOBACKUP H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\ AUTOBACKUP\2008_08_05\O1_MF_S_661968988_49JR5XWS_.BKP trouvé dans la zone de récupération canal ORA_DISK_1 : recherche de AUTOBACKUP effectuée le : 20080805 canal ORA_DISK_1 : restauration du fichier SPFILE à partir de AUTOBACKUP H:\ORADATA\FLASH_RECOVERY_AREA\HERMES\AUTOBACKUP\ 2008_08_05\ O1_MF_S_661968988_49JR5XWS_.BKP canal ORA_DISK_1 : restauration de SPFILE depuis AUTOBACKUP terminée Fin de restore dans 05/08/08 ●

- 8-

openmirrors.com

Redémarrer l’instance et ouvrir la base de données 

© ENI Editions - All rights reserved - Algeria Educ

RMAN> SHUTDOWN ... RMAN> STARTUP ... Si  la  sauvegarde  automatique  n’est  pas  stockée  dans  la  zone  de  récupération  rapide,  le  mode  opératoire  est  différent.  Il  faut  positionner  le  DBID  correspondant  à  la  base  de  données  (SET DBID …),  spécifier  le  format  utilisé  pour les sauvegardes automatiques (SET CONTROLFILE AUTOBACKUP FORMAT …) avant de restaurer la sauvegarde par  un RESTORE SPFILE FROM AUTOBACKUP (sans autre option).  Il  est  aussi  possible  de  restaurer  le  fichier  de  paramètre  serveur  en  spécifiant  la  sauvegarde  à  utiliser : RESTORE SPFILE FROM ’sauvegarde’. 

c. Récupération d’un fichier de contrôle  Dans le cas où vous avez perdu un ou plusieurs fichiers de contrôle, mais qu’il vous en reste encore au moins un,  vous ne devez pas repartir d’une sauvegarde de fichier de contrôle. Vous allez simplement dupliquer un des fichiers  de contrôle restants pour remplacer les fichiers perdus.  Nous supposons que l’instance est arrêtée.  Le mode opératoire est le suivant :  ●

●

●

utiliser le fichier d’alerte  de  l’instance pour identifier les fichiers de contrôle endommagés ou perdus et en  déduire qu’il reste bien au moins un fichier de contrôle valide ;  dupliquer une version valide du fichier de contrôle pour la mettre à la place du (des) fichier(s) de contrôle  endommagé(s) ;  redémarrer la base de données (STARTUP). 

Si  un  fichier  de  contrôle  est  dupliqué  à  un  autre  emplacement  que  l’emplacement  d’origine,  il  faut  modifier  le  paramètre  CONTROL_FILES  dans  le  fichier  de  paramètres  serveur.  Au  lieu  de  redémarrer  directement  la  base  de  données, il faudra procéder de la manière suivante :  ●

Démarrer l’instance, sans monter la base de données 

SQL> STARTUP NOMOUNT ●

Modifier le paramètre CONTROL_FILES dans le fichier de paramètres serveur : 

SQL> ALTER SYSTEM SET CONTROL_FILES= 2 ’f:\oradata\HERMES\control01.ctl’, 3 ’h:\oradata\HERMES\control02.ctl’ -- changement 4 SCOPE=SPFILE; ●

Redémarrer l’instance 

SQL> SHUTDOWN IMMEDIATE SQL> STARTUP La duplication d’une version valide du fichier de contrôle peut s’effectuer dans RMAN, à l’aide d’une variante de la  commande RESTORE CONTROLFILE. Exemple :  RMAN> RESTORE CONTROLFILE FROM ’F:\oradata\HERMES\control01.ctl’ ; La commande traite d’un seul coup tous les fichiers de contrôle manquants en se basant sur la valeur du paramètre  CONTROL_FILES.  Il est également possible de démarrer temporairement avec moins de fichiers de contrôle ; dans ce cas, il sera aussi  nécessaire de modifier la paramètre CONTROL_FILES dans le fichier de paramètres serveur. 

d. Récupération d’un fichier de journalisation 

© ENI Editions - All rights reserved - Algeria Educ

- 9-

Si vous avez perdu un ou plusieurs fichiers de journalisation, mais qu’il vous en reste au moins un par groupe, vous  n’avez  pas  besoin  de  réaliser  de  restauration  ou  de  récupération  de  la  base  de  données.  Vous  allez  simplement  recréer les fichiers de journalisation perdus.  Le mode opératoire est le suivant :  ●

●

Identifier  le  (les)  fichier(s)  de  journalisation  endommagé(s)  dans  le  fichier  d’alerte  de  l’instance,  dans  le  fichier de trace de LGWR ou dans la vue V$LOGFILE.  Supprimer le membre endommagé 

SQL> ALTER DATABASE DROP LOGFILE MEMBER ’nom_fichier’; ●

Ajouter un nouveau membre au groupe concerné 

SQL> ALTER DATABASE ADD LOGFILE MEMBER ’nom_fichier’ 2 TO GROUP numéro; ●

Réitérer les deux opérations précédentes avec tous les membres endommagés. 

Les fichiers de journalisation endommagés ont une colonne STATUS à INVALID dans la vue V$LOGFILE.  Le fichier de journalisation ajouté peut être mis à un autre emplacement ; s’il est remis au même emplacement que  le  précédent,  il  faudra  peut­être  au  préalable  supprimer  physiquement  l’ancien  fichier  (s’il  est  présent,  le  mettre  simplement de côté au cas où) ou utiliser la clause REUSE dans l’ordre SQL.  Vous ne pourrez pas supprimer le membre s’il appartient au groupe courant. Dans ce cas, il faut changer de groupe  courant en exécutant l’ordre SQL ALTER SYSTEM SWITCH LOGFILE. Cet ordre SQL ne peut être exécuté que si la base  de  données  est  ouverte.  Si  la  base  de  données  est  fermée,  et  qu’elle  ne  puisse  pas  être  ouverte  tout  de  suite,  vous pouvez reporter la correction du problème à plus tard ou vous contenter de recréer le membre ; la suppression  pourra avoir lieu plus tard, une fois la base de données ouverte.  Il peut être possible aussi de fonctionner temporairement avec moins de membres dans un groupe de fichiers de  journalisation. 

e. Récupération complète de la totalité de la base de donnéesc en mode ARCHIVELOG  Ce scénario émet l’hypothèse que vous avez perdu tous les fichiers de données. L’instance est arrêtée.  Le mode opératoire est le suivant :  ●

Monter la base de données 

RMAN> STARTUP MOUNT ●

Restaurer la base de données 

RMAN> RESTORE DATABASE ; Démarrage de restore dans 05/08/08 ... Fin de restore dans 05/08/08 ●

Récupérer la base de données 

RMAN> RECOVER DATABASE ; Démarrage de recover dans 05/08/08 ... Fin de recover dans 05/08/08 ●

Ouvrir la base de données 

RMAN> ALTER DATABASE OPEN ; Si  vous  n’utilisez  pas  la  zone  de  récupération  rapide  pour  l’archivage,  vous  pouvez  spécifier  l’option  DELETE ARCHIVELOG  dans  la  commande  RECOVE  pour  supprimer  les  fichiers  de  journalisation  archivés  restaurés  au  fur  et  à  - 10 -

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

mesure de leur application et éventuellement limiter l’espace utilisé par ces fichiers. 

f. Récupération complète d’une partie de la base de données en mode ARCHIVELOG  Ce scénario émet l’hypothèse que vous avez perdu un ou plusieurs fichiers de données (mais pas tous).  Cette opération peut être réalisée base fermée ou base ouverte, selon la nature du problème.  ●

●

Si  un  fichier  de  données  du  tablespace  SYSTEM,  ou  un  fichier  du  tablespace  d’annulation  actif  est  perdu,  l’instance  s’est  arrêtée  et  vous  ne  pourrez  pas  ouvrir  la  base  de  données  sans  récupérer  les  fichiers  en  question.  S’il  s’agit d’un  autre  fichier  de  données,  la  base  de  données  peut  rester  ouverte.  Par  contre,  si  elle  était  fermée, elle ne peut pas être ouverte. 

Récupération base de données fermée Dans cet exemple, le fichier de données du tablespace SYSTEM est perdu ; l’instance est arrêtée.  Le mode opératoire est le suivant :  ●

Monter la base de données : 

RMAN> STARTUP MOUNT instance Oracle démarrée ... ●

Restaurer les fichiers de données souhaités soit par un RESTORE TABLESPACE, soit par un RESTORE DATAFILE 

RMAN> RESTORE TABLESPACE system ; ●

Récupérer les fichiers de données soit par un RECOVER TABLESPACE, soit par un RECOVER DATAFILE 

RMAN> RECOVER TABLESPACE system ; ●

Ouvrir la base de données 

RMAN> ALTER DATABASE OPEN ; Récupération base de données ouverte Dans cet exemple, le fichier de données du tablespace INDX est perdu (fichier de données numéro 6).  Si  la  base  de  données  est  fermée,  mais  que  vous  souhaitiez  réaliser  la  récupération  base  ouverte  (pour  que  les  utilisateurs puissent recommencer à travailler), commencez par la première partie du mode opératoire. Si la base de  données est déjà ouverte, passez directement à la deuxième partie du mode opératoire.  La première partie du mode opératoire est la suivante :  ●

Monter la base de données 

RMAN> STARTUP MOUNT ●

Mettre OFFLINE les fichiers de données perdus 

RMAN> SQL "ALTER DATABASE DATAFILE 6 OFFLINE"; ●

Ouvrir la base de données 

RMAN> ALTER DATABASE OPEN; La deuxième partie du mode opératoire est la suivante : 

© ENI Editions - All rights reserved - Algeria Educ

- 11 -

●

Passer OFFLINE les tablespaces concernés ; vous devez utiliser l’option IMMEDIATE, car un fichier de données  n’est pas accessible 

RMAN> SQL "ALTER TABLESPACE indx OFFLINE IMMEDIATE"; ●

Restaurer les fichiers de données souhaités soit par un RESTORE TABLESPACE, soit par un RESTORE DATAFILE 

RMAN> RESTORE DATAFILE 6 ; ●

Récupérer les fichiers de données soit par un RECOVER TABLESPACE, soit par un RECOVER DATAFILE 

RMAN> RECOVER DATAFILE 6 ; ●

Passer ONLINE les tablespaces concernés 

RMAN> SQL "ALTER TABLESPACE indx ONLINE";

g. Récupération de tous les fichiers de contrôle en mode ARCHIVELOG  Dans  ce  scénario,  nous  supposons  que  nous  avons  perdu  tous  les  fichiers  de  contrôle  ainsi  qu’un  fichier  de  données. Il ne s’agit pas d’une catastrophe car nous disposons de sauvegardes automatiques du fichier de contrôle  (dans  la  zone  de  récupération  rapide)  et  les  fichiers  de  journalisation  en  ligne  sont  disponibles.  L’instance  est  arrêtée.  Le mode opératoire est le suivant :  ●

Démarrer l’instance sans monter la base de données 

RMAN> STARTUP NOMOUNT ●

Restaurer  les  fichiers  de  contrôle  à  partir  d’une  sauvegarde  automatique  (dans  la  zone  de  récupération  rapide). 

RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP; ●

Monter la base de données 

RMAN> ALTER DATABASE MOUNT ; ■

Restaurer les fichiers de données perdus (déjà vu) 

RMAN> RESTORE DATAFILE 5 ; ●

Récupérer  la  base  de  données  (pas  uniquement  les  fichiers  de  données  car  nous  repartons  d’une  sauvegarde de fichiers de contrôle) 

RMAN> RECOVER DATABASE ; ●

Ouvrir la base de données avec l’option RESETLOGS (obligatoire) 

RMAN> ALTER DATABASE OPEN RESETLOGS ; ●

Vous obtenez une nouvelle "incarnation" de la base de données 

RMAN> LIST INCARNATION OF DATABASE ; Liste des incarnations de base de données DB Key Inc Key DB Name DB ID ------- ------- -------- ---------------1 1 HERMES 3535892647 2 2 HERMES 3535892647

- 12 -

openmirrors.com

STATUS ------PARENT CURRENT

Reset SCN ---------1 460308

© ENI Editions - All rights reserved - Algeria Educ

Reset Time ---------16/07/08 05/08/08

Dans  la  commande  RESTORE CONTROLFILE FROM AUTOBACKUP,  vous  pouvez  spécifier  les  options  DB_RECOVERY_FILE_DEST et DB_NAME (ou DB_UNIQUE_NAME) si les valeurs actuelles ne sont pas correctes. Par contre, si  la sauvegarde automatique du fichier de contrôle n’est pas stockée dans la zone de récupération rapide, le mode  opératoire est différent. Il faut positionner le DBID correspondant à la base de données (SET DBID …), spécifier le  format  utilisé  pour  les  sauvegardes  automatiques  (SET CONTROLFILE AUTOBACKUP FORMAT …)  avant  de  restaurer  la  sauvegarde par un RESTORE CONTROLFILE FROM AUTOBACKUP.  Lorsque vous repartez d’une sauvegarde de fichier de contrôle, RMAN effectue automatiquement un CROSSCHECK et  un  CATALOG RECOVERY AREA  pour  mettre  à  jour  le  référentiel  dans  les  fichiers  de  contrôle  (qui  ne  sont  pas  à  jour  puisqu’ils proviennent d’une sauvegarde), en fonction de la réalité physique des fichiers.  Par ailleurs, vous devez ouvrir la base de donénes avec l’option RESETLOGS. Même si la récupération est complète,  Oracle  considère  que  c’est  une  nouvelle  vie  de  la  base  de  données,  une  nouvelle  « incarnation »  de  la  base  de  données. Les numéros de séquence des fichiers de journalisation vont repartir de zéro.  Dans  les  versions  précédentes  d’Oracle,  toutes  les  sauvegardes  et  tous  les  fichiers  de  journalisation  archivés  antérieurs à l’ouverture en mode RESETLOGS étaient pratiquement inexploitables.  Depuis  la  version  10,  ce  n’est  plus  le  cas.  Lors  d’une  ouverture  en  mode  RESETLOGS,  Oracle  associe  un  numéro  d’activation  à  la  "nouvelle"  base  de  données.  Ce  numéro  d’activation  est  utilisé  par  Oracle  à  différents  endroits,  dont  le  nom  des  fichiers  de  journalisation  archivés  (variable  %r  dans  le  paramètre  LOG_ARCHIVE_FORMAT).  De  cette  manière, Oracle est capable d’associer n’importe quel fichier à une incarnation de la base de données.  Le numéro d’activation courant peut être consulté dans la colonne INCARNATION# de la vueV$DATABASE. L’historique  des  incarnations  d’une  base  de  données  peut  être  consulté  dans  la  vue  V$DATABASE_INCARNATION.  Dans  RMAN,  la  commande LIST INCARNATION donne la liste des incarnations de la base de données.  Dans le fichier des alertes de l’instance, vous trouverez aussi des messages du type :  RESETLOGS after complete recovery through change 460307 Resetting resetlogs activation ID 3535886503 (0xd2c158a7) Tue Aug 05 18:09:16 2008 Setting recovery target incarnation to 2   La notion d’incarnation de base de données est l’un des sujets les plus complexes d’Oracle.

h. Récupération incomplète en mode ARCHIVELOG  Ce scénario va illustrer la technique de récupération incomplète, en partant d’une situation catastrophe : tout est  perdu (fichier de paramètres serveur, fichiers de contrôle, fichiers de données et fichiers de journalisation en ligne).  L’instance est arrêtée.  Une récupération incomplète est nécessaire dans plusieurs cas :  ●

perte de tous les fichiers de journalisation en ligne (c’est le cas dans ce scénario) ; 

●

perte d’un fichier de journalisation archivé, nécessaire à une récupération ; 

●

retour avant un ordre SQL malencontreux (DROP TABLE, DROP TABLESPACE, DROP USER, etc.). 

Dans tous les cas, il faudra identifier le point de retour souhaité par une date/heure, un numéro SCN ou un numéro  de séquence de fichier de journalisation.  À  la  fin  de  la  récupération,  il  faudra,  là  encore,  ouvrir  la  base  de  données  avec  l’option  RESETLOGS : c’est  une  nouvelle incarnation de la base de données.  Ce scénario est une combinaison de scénarios déjà étudiés.  Le mode opératoire est le suivant :  ●

Démarrer l’instance sans monter la base de données (RMAN utilise un fichier de paramètres "temporaire" car  le fichier de paramètres serveur est perdu) : 

RMAN> STARTUP NOMOUNT échec du démarrage : ... démarrage de l’instance Oracle sans fichier de paramètres ... instance Oracle démarrée

© ENI Editions - All rights reserved - Algeria Educ

- 13 -

... ●

Restaurer le fichier de paramètres serveur à partir d’une sauvegarde automatique (stockée dans la zone de  récupération rapide pour cet exemple) : 

RMAN> RESTORE SPFILE FROM AUTOBACKUP 2> DB_RECOVERY_FILE_DEST ’H:\oradata\flash_recovery_area’ 3> DB_NAME ’HERMES’; ●

Redémarrer l’instance  sans  monter  la  base  de  données  (démarrage  avec  le  fichier  de  paramètres  serveur  restauré) : 

RMAN> STARTUP NOMOUNT FORCE ●

Restaurer  les  fichiers  de  contrôle  à  partir  d’une  sauvegarde  automatique  (stockée  dans  la  zone  de  récupération rapide pour cet exemple) : 

RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP ; ●

Monter la base de données : 

RMAN> ALTER DATABASE MOUNT ; ●

Restaurer et récupérer la base de données : 

RMAN> RESTORE DATABASE ; ... RMAN> RECOVER DATABASE ; Démarrage de recover dans 06/08/08 ... RMAN-03002: échec de la commande recover à 08/06/2008 07:37:00 RMAN-06054: la récupération après défaillance matérielle requiert un journal inconnu : thread 1, séquence 7 et SCN de début 475124 ●

Ouvrir la base de données avec l’option RESETLOGS : 

RMAN> ALTER DATABASE OPEN RESETLOGS ; Dans ce scénario, avec le mode opératoire utilisé ici, il est normal que la commande  RECOVER se termine avec une  erreur puisqu’il manque un fichier de journalisation. Au préalable, la commande RESTORE a effectué automatiquement  un  CROSSCHECK  et  un  CATALOG RECOVERY AREA  pour  mettre  à  jour  le  référentiel  (notamment  les  fichiers  de  journalisation archivés disponibles) dans les fichiers de contrôle ; la commande RECOVER est donc, allée le plus loin  possible  avec  les  éléments  à  sa  disposition.  Avant  d’ouvrir  la  base  dans  le  mode RESETLOGS,  assurez­vous  que  le  numéro de séquence du dernier fichier de journalisation appliqué est conforme à vos attentes.  Dans le cas où nous souhaitons préciser explicitement le point de retour, il est possible d’utiliser une clause UNTIL  dans les commandes RESTORE et RECOVER ; cette clause offre plusieurs options :  UNTIL SCN [=] n  Jusqu’à un numéro SCN (non compris).  UNTIL SEQUENCE[=] n  Jusqu’à un numéro de séquence d’un fichier de journalisation (non compris).  UNTIL TIME [=]’date’  Jusqu’à  une  date/heure  (non  comprise).  Peut  être  spécifié  sous  la  forme  d’une  constante  (au  format  de  date  courant) ou une expression du type ’SYSDATE-1’ ou "TO_DATE(…)".  Dans un bloc RUN, il est aussi possible d’utiliser la commande SET UNTIL avant d’exécuter les commandes RESTORE et  RECOVER : 

- 14 -

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

RUN { SET UNTIL ... ; RESTORE DATABASE ; RECOVER DATABASE ;}

i. Récupération en mode NOARCHIVELOG  Dans  ce  scénario,  nous  supposons  que  nous  avons  perdu  tout  ou  partie  de  la  base  de  données  et  que  cette  dernière fonctionne en mode NOARCHIVELOG.  Dans ce cas, normalement, la seule solution de récupération consiste à ramener la base de données à l’état où elle  se  trouvait  lors  de  la  dernière  sauvegarde  complète  base  fermée,  cette  dernière  pouvant  être  une  sauvegarde  incrémentale.  Néanmoins, comme nous l’avions indiqué précédemment, il est peut être envisageable de réaliser une récupération  complète si les fichiers de journalisation sont disponibles et qu’il n’y ait pas eu un cycle complet de basculement des  fichiers  de  journalisation  depuis  la  dernière  sauvegarde.  Vous  pouvez  alors  tenter  une  restauration  de  type  ARCHIVELOG (points e. ou f.) :  ●

restauration des fichiers de données endommagés ; 

●

récupération des fichiers de données endommagés. 

Si  la  récupération  ne  signale  pas  d’erreur, c’est  gagné.  Par  contre,  si  la  récupération  signale  une  erreur  du  type  suivant, la situation est a priori désespérée :  journal d’archivage introuvable journal d’archivage, thread=1, séquence=7 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: échec de la commande recover à 08/06/2008 07:37:00 RMAN-06054: la récupération après défaillance matérielle requiert un journal inconnu : thread 1, séquence 7 et SCN de début 475124 Dans  ce  cas,  il  ne  reste  plus  qu’à  réaliser  une  récupération  en  mode  NOARCHIVELOG,  à  l’aide  du  mode  opératoire  suivant :  ●

Démarrer l’instance sans monter la base de données 

RMAN> STARTUP NOMOUNT ●

Restaurer  les  fichiers  de  contrôle  à  partir  d’une  sauvegarde  automatique  (stockée  dans  la  zone  de  récupération rapide pour cet exemple) 

RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP; ●

Monter la base de données 

RMAN> ALTER DATABASE MOUNT ; ●

Restaurer la base de données 

RMAN> RESTORE DATABASE; ●

Si  vous  utilisez  des  sauvegardes  incrémentales  cohérentes  (base  fermée)  de  la  totalité  de  la  base  de  données, la commande RESTORE précédente aura ramené la dernière sauvegarde de niveau 0. Vous pouvez  alors  réaliser  une  récupération  (RECOVER)  avec  l’option  NOREDO,  pour  que  RMAN  applique  les  sauvegardes  incrémentales  de  niveau  1  postérieur  à  la  sauvegarde  de  niveau  0,  sans  appliquer  les  fichiers  de  journalisation. 

RMAN> RECOVER DATABASE NOREDO;

© ENI Editions - All rights reserved - Algeria Educ

- 15 -

●

Ouvrir la base de données avec l’option RESETLOGS (obligatoire) 

RMAN> ALTER DATABASE OPEN RESETLOGS ; Là encore, vous obtenez une nouvelle incarnation de la base de données ; c’est normal puisque vous être revenu à  un instant donné du passé. 

j. Récupération à un emplacement différent  Dans  certains  cas,  il  peut  être  impossible  de  restaurer  les  fichiers  de  données  dans  l’arborescence  d’origine.  Il  faudra alors utiliser deux commandes supplémentaires dans le processus de restauration :  ●

Avant  la  restauration  (RESTORE) : SET NEWNAME FOR DATAFILE  pour  indiquer  à  RMAN  le  nouvel  emplacement  d’un fichier de données 

SET NEWNAME FOR DATAFILE ’ancien_chemin’ | numéro_fichier TO ’nouveau_chemin’ ; ●

Après la restauration (RESTORE) et avant la récupération (RECOVER) : SWITCH DATAFILE pour mettre à jour le  fichier de contrôle (équivalent à l’ordre SQL ALTER DATABASE RENAME FILE) 

SWITCH DATAFILE ALL ; Ces deux commandes doivent être exécutées dans un bloc RUN.  Exemple pour restaurer un fichier de données à un autre emplacement  RUN { # si l’instance est arrêtée, la démarrer # et monter la base de données STARTUP MOUNT # # si la base de données est ouverte, # mettre le tablespace OFFLINE # SQL "ALTER TABLESPACE data OFFLINE IMMEDIATE" ; # SET NEWNAME FOR DATAFILE ’e:\oradata\HERMES\data01.dbf’ TO ’f:\oradata\HERMES\data01.dbf’ ; RESTORE TABLESPACE data ; SWITCH DATAFILE ALL ; RECOVER TABLESPACE data ; # si la base de données est montée, l’ouvrir ALTER DATABASE OPEN ; # # si la base de données est ouverte, # mettre le tablespace ONLINE # SQL "ALTER TABLESPACE data ONLINE" ; }

k. Cas particulier du tablespace temporaire géré localement  Les fichiers de données des tablespaces temporaires gérés localement ne sont jamais sauvegardés par RMAN et ne  peuvent donc pas être restaurés.  Si vous perdez un fichier de données d’un tablespace temporaire géré localement, vous n’avez normalement rien de  particulier à faire car Oracle le recrée, si besoin, automatiquement lors de l’ouverture de la base de données. Dans  le fichier d’alerte de l’instance, vous trouverez alors des messages du type suivant :  2008-08-07 06:58:51.171000 +02:00 Re-creating tempfile E:\ORADATA\HERMES\TEMP01.DBF Pour  vérifier  que  les  fichiers  de  données  des  tablespaces  temporaire  gérés  localement  sont  bien  présents,  vous  pouvez interroger la vue V$TEMPFILE ou exécuter la commande RMAN REPORT SCHEMA. 

- 16 -

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

En  cas  de  besoin,  vous  pouvez  explicitement  recréer  les  fichiers  de  données  des  tablespaces  gérés  localement.  Exemple :  SQL> ALTER TABLESPACE temp 2 ADD TEMPFILE ’e:\oradata\HERMES\temp01.dbf’ SIZE 100M 3 AUTOEXTEND ON NEXT 100M MAXSIZE 1G;

7. Data Recovery Advisor  a. Vue d’ensemble  Le  Data  Recovery  Advisor  est  un  outil  qui  permet  de  simplifier  et  d’automatiser  le  diagnostic  et  la  résolution  des  problèmes (perte ou corruption) sur les fichiers de la base données. Cet outil est apparu en version 11.  Le conseiller peut être utilisé en ligne de commande dans RMAN ou avec une interface graphique dans le Database  Control (cf. Utiliser le Database Control).  Dans la terminologie du conseiller, un échec (failure en anglais) sur un fichier est identifié par un numéro unique et  est caractérisé par un statut (OPEN ou CLOSED) et une priorité (LOW, HIGH ou CRITICAL).  Le statut est OPEN tant que le problème n’a pas été résolu ; il passe à CLOSED ensuite.  La  priorité  est CRITICAL  lorsque  la  base  de  données  est  totalement  indisponible  et  HIGH  si  elle  est  partiellement  indisponible ; dans les deux cas, il convient de résoudre le problème rapidement. La priorité LOW n’est pas attribuée  par le conseiller. Par contre, si vous jugez qu’une priorité HIGH a peu d’impact sur le fonctionnement de la base de  données et ne nécessite pas de traitement immédiat, vous pouvez descendre manuellement la priorité à LOW.  Les informations relatives aux échecs sont stockées dans le référentiel de diagnostic automatique. Pour fonctionner,  le Data Recovery Advisor nécessite que l’instance soit démarrée (mais la base de donnée peut ne pas être montée  ce qui permet de diagnostiquer et résoudre les incidents sur les fichiers de contrôle). 

b. Utilisation  Dans RMAN, les étapes pour diagnostiquer et résoudre les problèmes à l’aide du conseiller sont les suivantes :  ●

Afficher les échecs actuels (statut OPEN) : LIST FAILURE. 

●

Déterminer les actions à effectuer pour résoudre le(s) problème(s) : ADVISE FAILURE. 

●

Résoudre le(s) problème(s) : REPAIR FAILURE. 

●

Retourner  à  l’étape  1  pour  confirmer  que  les  problèmes  ont  été  résolus  ou  voir  s’il  reste  encore  des  problèmes. 

Au  préalable,  il  est  possible  d’exécuter  la  commande  VALIDATE DATABASE  pour  vérifier  la  totalité  de  la  base  de  données (mais il faut que la base de données soit montée).  En complément des commandes LIST FAILURE, ADVISE FAILURE  et REPAIR FAILURE, il existe une commande CHANGE FAILURE qui permet de modifier le statut ou la priorité. Cette commande, moins utile, n’est pas présentée dans cet  ouvrage (voir la documentation "Oracle® Database Backup and Recovery Reference").  La première étape consiste donc à afficher les échecs actuels avec la commande LIST FAILURE.  Syntaxe simplifiée  LIST FAILURE [quoi] [DETAIL] ; La clause quoi peut prendre une ou plusieurs des valeurs suivantes : ALL, CRITICAL, HIGH, LOW, CLOSED ou un numéro  d’échec.  Par  défaut,  la  commande  LIST FAILURE  affiche  tous  les  échecs  de  statut  OPEN  et  de  priorité  CRITICAL  ou  HIGH.  L’option  CLOSED  permet  d’afficher  les  échecs  de  statut  CLOSED.  Les  options  CRITICAL,  HIGH, LOW  ou ALL  permettent  d’afficher les échecs ayant une priorité donnée (ALL = toutes les priorités).  Pour simplifier, les échecs de même nature sont regroupés dans un seul échec "parent" et seuls ces derniers sont  affichés  par  défaut  par  la  commande  LIST FAILURE.  Pour  afficher  tous  les  échecs  "enfants",  vous  pouvez  utiliser  © ENI Editions - All rights reserved - Algeria Educ

- 17 -

l’option DETAIL.  Exemple  RMAN> LIST FAILURE ; utilisation du fichier de contrôle de la base de données cible au lieu du catalogue de récupération Liste des échecs de base de données ========================= ID d’échec Priority Status Time Detected Summary ---------- -------- ------ ------------- ------565 HIGH OPEN 07/08/08 Un ou plusieurs fichiers de données non système sont absents RMAN> LIST FAILURE 565 DETAIL; utilisation du fichier de contrôle de la base de données cible au lieu du catalogue de récupération Liste des échecs de base de données ========================= ID d’échec Priority Status Time Detected Summary ---------- -------- ------ ------------- ------565 HIGH OPEN 07/08/08 Un ou plusieurs fichiers de données non système sont absents Impact : Voir l’impact des échecs des enfants Liste des échecs enfant de l’ID d’échec parent 565 ID d’échec Priority Status Time Detected Summary ---------- ------ ------ ------------- ------1859 HIGH OPEN 07/08/08 Le fichier de données 6: ’E:\ORADATA\HERMES\INDX01.DBF’ est absent Impact : Il se peut que certains objets dans le tablespace INDX soient indisponibles 1853 HIGH OPEN 07/08/08 Le fichier de données 5: ’E:\ORADATA\HERMES\DATA01.DBF’ est absent Impact : Il se peut que certains objets dans le tablespace DATA soient indisponibles Sur cet exemple, un problème a été détecté sur deux fichiers de données.  Pour  générer  et  afficher  les  actions  à  effectuer  pour  traiter  les  échecs,  vous  devez  utiliser  la  commande  ADVISE FAILURE.  Syntaxe simplifiée  ADVISE FAILURE [quoi] ; La  clause  quoi  peut  prendre  une  ou  plusieurs  des  valeurs  suivantes : ALL,  CRITICAL,  HIGH,  LOW  ou  un  numéro  d’échec.  La  commande  ADVISE FAILURE  sans  option  peut  être  utilisée  uniquement  si  une  commande  LIST FAILURE  a  été  exécutée au préalable dans la session RMAN. Dans ce cas, la commande ADVISE FAILURE affiche des informations de  résolution  pour  tous  les  échecs  de  statut  OPEN  et  de  priorité  CRITICAL  ou HIGH  enregistrés  dans  le  référentiel  de  diagnostic automatique.  Les  options  de  la  clause  quoi  permettent  d’afficher  les  informations  de  résolution  pour  un  sous­ensemble  d’échecs ; la signification des différentes options de cette clause est la même que pour la commande LIST FAILURE.  Exemple  RMAN> ADVISE FAILURE ; Liste des échecs de base de données ========================= ID d’échec Priority Status Time Detected Summary ---------- -------- ------ ------------- ------565 HIGH OPEN 07/08/08 Un ou plusieurs fichiers de données non système sont absents ... analyse des options de réparation automatique ; cette opération peut prendre un certain temps canal affecté : ORA_DISK_1 canal ORA_DISK_1 : SID=208 type d’unité=DISK analyse des options de réparation automatique terminée Actions manuelles obligatoires

- 18 -

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

======================== aucune action manuelle n’est disponible Actions manuelles facultatives ======================= 1. Si le fichier E:\ORADATA\HERMES\DATA01.DBF a été renommé ou déplacé involontairement, restaurez-le 2. Si le fichier E:\ORADATA\HERMES\INDX01.DBF a été renommé ou déplacé involontairement, restaurez-le Options de réparation automatique ======================== Option Repair Description ------ -----------------1 Restaurez et récupérez le fichier de données 5; Restaurez et récupérez le fichier de données 6 Stratégie : La réparation comprend une récupération après défaillance matérielle sans perte de données Script de réparation : d:\app\oracle\diag\rdbms\hermes\hermes\hm\ reco_499244267.hm Après avoir affiché des informations sur les échecs trouvés (résultat de la commande LIST FAILURE), la commande  ADVISE FAILURE affiche trois sections :  Actions  manuelles  obligatoires  :  cette  section  liste  les  opérations  qui  doivent  obligatoirement  être  faites  manuellement  pour  résoudre  le  problème.  Des  actions  manuelles  obligatoires  peuvent,  par  exemple,  être  nécessaires  si  une  sauvegarde  ou  un  fichier  de  journalisation  archivé  requis  par  la  réparation  automatique  sont  manquants.  Actions manuelles facultatives : cette section liste les opérations manuelles facultatives qui peuvent permettre de  résoudre  le  problème.  Par  exemple,  si  un  fichier  de  données  est  manquant,  le  conseiller  suggère  que  ce  fichier  a  peut­être  été  involontairement  renommé  ou  déplacé  et  qu’il  peut  donc  être  restauré  sans  devoir  repartir  d’une  sauvegarde.  Options  de  réparation  automatique  :  cette  section  liste  les  différentes  options  de  réparation  automatique.  Pour  chaque option, la commande affiche un numéro, une description, une stratégie (avec ou sans perte de données) et  le  chemin  du  script  qui  contient  les  commandes  de  réparation.  Les  options  correspondant  à  une  stratégie  sans  perte de données sont toujours proposées en premier.  Pour réparer automatiquement les échecs identifiés par le Data Recovery Advisor, vous pouvez utiliser la commande  REPAIR FAILURE.  Syntaxe  REPAIR FAILURE [USING ADVISE OPTION numéro] [PREVIEW] [NOPROMPT]; Par  défaut,  la  commande  REPAIR FAILURE  exécute  les  actions  de  la  première  option  de  réparation  automatique,  identifiée par la commande ADVISE FAILURE la plus récente exécutée dans la session RMAN ; si aucune commande  ADVISE FAILURE n’a été exécutée dans la session RMAN, une erreur est retournée.  L’option  USING ADVISE OPTION  permet  d’appliquer  une  option  de  réparation  automatique  spécifique,  identifiée  par  son numéro d’option.  L’option PREVIEW permet de ne pas exécuter les actions, mais simplement de les prévisualiser à l’écran.  L’option NOPROMPT permet de supprimer la demande de confirmation, lors de l’exécution effective de la commande.  Exemple  RMAN> REPAIR FAILURE PREVIEW ; Stratégie : La réparation comprend une récupération après défaillance matérielle sans perte de données Script de réparation : d:\app\oracle\diag\rdbms\hermes\hermes\hm\ reco_499244267.hm contenu du script de réparation : # restore and recover datafile restore datafile 5, 6; recover datafile 5, 6; RMAN> REPAIR FAILURE NOPROMPT ; Stratégie : La réparation comprend une récupération après défaillance matérielle sans perte de données Script de réparation : d:\app\oracle\diag\rdbms\hermes\hermes\hm\ reco_499244267.hm contenu du script de réparation :

© ENI Editions - All rights reserved - Algeria Educ

- 19 -

# restore and recover datafile restore datafile 5, 6; recover datafile 5, 6; exécution du script de réparation Démarrage de restore dans 07/08/08 ... Fin de restore dans 07/08/08 Démarrage de recover dans 07/08/08 ... Fin de recover dans 07/08/08 réparation de l’échec terminée base de données ouverte Lors  de  l’exécution  effective  des  actions  de  réparation,  RMAN  affiche  le  résultat  des  différentes  commandes  exécutées (RESTORE, RECOVER, etc.). 

c. Considérations  Le Data  Recovery  Advisor  est  un  outil  très  puissant  qui  permet  de  diagnostiquer  et  résoudre  un  grand  nombre  de  problèmes sur les fichiers de contrôle, les fichiers de journalisation ou les fichiers de données.  Le seul problème que le Data Recovery Advisor ne sait pas résoudre est la perte du fichier de paramètres serveur. Si  besoin, vous devrez restaurer manuellement le fichier de paramètre serveur (cf. Récupération)  Avant d’utiliser le conseiller, assurez­vous que l’instance a bien démarré avec un fichier de paramètres à jour. Si ce  n’est  pas  le  cas,  le  conseiller  risque  de  signaler  un  faux  problème  sur  les  fichiers  de  contrôle  si  la  valeur  du  paramètre CONTROL_FILES n’est pas correcte. Vous pouvez notamment rencontrer cette situation si RMAN a démarré  l’instance avec un fichier de paramètre "temporaire" (message démarrage de l’instance Oracle sans fichier de paramètres pour extraction de SPFILE).  Dans  le  cas  où  tous  les  fichiers  de  contrôle  sont  perdus,  le  Data  Recovery  Advisor  commencera  par  signaler  ce  problème  et  ne  sera  pas  forcément  en  mesure  d’identifier  tout  de  suite  d’autres  problèmes  (sur  les  fichiers  de  données par exemple). Vous devrez donc, d’abord traiter le problème sur les fichiers de contrôle (LIST FAILURE, puis  ADVISE FAILURE  puis  REPAIR FAILURE)  avant  de  faire  de  nouveau  appel  au  conseiller  pour  identifier  les  autres  problèmes éventuels (LIST FAILURE) et si besoin, les résoudre (ADVISE FAILURE puis REPAIR FAILURE).  Cette situation peut se produire dans le scénario catastrophe où vous avez perdu la totalité de la base de données  (tous les fichiers de contrôle, tous les fichiers de journalisation et tous les fichiers de données).  Là encore, utiliser une zone de récupération rapide, et faire des sauvegardes automatiques du fichier de contrôle  vers cette zone de récupération rapide, facilite la résolution des problèmes par le Data Recovery Advisor.  Si la situation l’exige (récupération incomplète ou récupération à partir d’une sauvegarde des fichiers de contrôle),  le Data Recovery Advisor ouvrira la base de données dans le mode RESETLOGS. 

- 20 -

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

Les techniques de flashback  1. Vue d’ensemble  Les techniques de flashback sont un ensemble de fonctionnalités proposées par Oracle qui permettent de voir l’état  passé des données, ou de ramener une table ou la totalité de la base de données dans le passé.  Les fonctionnalités proposées sont les suivantes :  ●

●

●

●

●

●

●

●

Flashback  Query:  permet  de  lire  les  données  telles  qu’elles  étaient  à  un  instant  dans  le  passé  (apparu  en  version 9).  Flashback  Version  Query : permet  de  voir  toutes  les  versions  d’une  ligne  sur  un  certain  intervalle  de  temps  (apparu en version 10).  Flashback Transaction Query : permet de voir les modifications réalisées par une ou plusieurs transactions sur  un certain intervalle de temps (apparu en version 10).  Flashback  Transaction:  permet  d’annuler  les  modifications  d’une  transaction,  et  de  ses  transactions  dépendantes (apparu en version 11).  Flashback  Data  Archive  (Oracle  Total  Recall) : permet  de  conserver  sur  le  long  terme,  toutes  les  modifications  apportées à une table (apparu en version 11).  Flashback Table : permet de ramener une table dans l’état où elle était, à un certain moment dans le passé  (apparu en version 10).  Flashback Drop: permet de ramener la table dans l’état où elle était, juste avant sa suppression (apparu en  version 10).  Flashback  Database : permet  de  ramener  la  totalité  de  la  base  de  données  dans  l’état  où  elle  était  à  un  certain moment dans le passé (apparu en version 11). 

Seule  la  fonctionnalité  Flashback  Query  est  disponible  dans  toutes  les  éditions  de  la  base  de  données  (et  donc  notamment en Standard Edition).  La fonctionnalité Flashback  Data  Archive (Oracle Total Recall) est une option de l’Enterprise Edition et nécessite donc,  une licence supplémentaire. Cette fonctionnalité n’est pas présentée dans cet ouvrage.  Les autres fonctionnalités de flashback nécessitent l’Enterprise Edition, mais sans option supplémentaire.  Ces fonctionnalités utilisent des techniques différentes mais pour répondre au même objectif : récupérer une erreur  d’utilisation.  Les fonctionnalités de flashback de requête (Flashback Query, Flashback Version Query et Flashback Transaction Query),  et la fonctionnalité de flashback de table, utilisent les informations d’annulation pour revenir en arrière. Le paramètre  UNDO_RETENTION  et  le  tablespace  d’annulation  doivent  donc  être  correctement  dimensionnés,  si  vous  souhaitez  pouvoir retourner loin dans le passé.  La  fonctionnalité  de flashback  de  transaction  (Flashback Transaction)  utilise  les  fichiers  de  journalisation  (en  ligne  et  archivés, donc la base de données doit fonctionner dans le mode ARCHIVELOG). Cette fonctionnalité, un peu avancée,  n’est pas présentée dans cet ouvrage.  La fonctionnalité de flashback de base de données (Flashback Database) utilise un fichier journal spécifique, différent  des fichiers de journalisation.  La fonctionnalité de flashback avant suppression d’une table (Flashback Drop) utilise le fait que le stockage d’une table  n’est pas physiquement supprimé lorsque la table est supprimée. 

2. Niveau ligne  Flashback Query

© ENI Editions - All rights reserved - Algeria Educ

- 1-

Pour lire les données telles qu’elles étaient à un instant donné du passé, vous pouvez utiliser l’option AS OF sur une  table présente dans la clause FROM d’une requête SELECT.  Syntaxe  nom_table AS OF { TIMESTAMP | SCN } expression L’option TIMESTAMP permet de retourner à un instant donné du passé en indiquant une date et une heure ; dans ce  cas,  l’expression  doit  être  de  type  TIMESTAMP.  L’option  SCN  permet  de  retourner  à  un  instant  donné  du  passé  en  indiquant un numéro SCN ; dans ce cas, l’expression doit être un nombre.  Exemple  -- situation de départ SQL> SELECT prenom FROM adherent WHERE numero = 1; PRENOM ---------------------------------------Sébastien SQL> SELECT TO_CHAR(SYSDATE,’DD/MM/YYYY HH24:MI:SS’) "SYSDATE", 2 dbms_flashback.get_system_change_number "SCN" 3 FROM dual; SYSDATE SCN -------------------- ---------08/08/2008 11:28:00 176032 SQL> -- un peu plus tard SQL> UPDATE adherent SET prenom = ’Olivier’ WHERE numero = 1; 1 ligne mise à jour. SQL> COMMIT; Validation effectuée. SQL> -- un peu plus tard SQL> SELECT TO_CHAR(SYSDATE,’DD/MM/YYYY HH24:MI:SS’) "SYSDATE", 2 dbms_flashback.get_system_change_number "SCN" 3 FROM dual; SYSDATE SCN -------------------- ---------08/08/2008 11:28:20 176123 SQL> SELECT prenom 2 FROM adherent AS OF TIMESTAMP SYSTIMESTAMP - INTERVAL ’30’ SECOND 3 WHERE numero = 1; PRENOM ---------------------------------------Sébastien SQL> SELECT prenom 2 FROM adherent AS OF SCN 176032 3 WHERE numero = 1; PRENOM ---------------------------------------Sébastien SQL> SELECT prenom FROM adherent WHERE numero = 1; PRENOM ---------------------------------------Olivier La fonction GET_SYSTEM_CHANGE_NUMBER du package DBMS_FLASHBACK retourne le numéro SCN courant. Il faut le  privilège EXECUTE sur le package pour l’utiliser.  La donnée lue dans le passé peut être utilisée pour réaliser une mise à jour dans le présent :  SQL> UPDATE adherent 2 SET nom = (SELECT prenom FROM adherent AS OF SCN 176032 3 WHERE numero = 1) 4 WHERE numero = 1; Flashback Version Query

- 2-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

Pour lire les différentes versions d’une ligne sur un certain intervalle de temps, vous pouvez utiliser l’option VERSIONS BETWWEN sur une table présente dans la clause FROM d’une requête SELECT.  Syntaxe  nom_table VERSIONS BETWEEN { TIMESTAMP | SCN } { expression1 | MINVALUE } AND { expression2 | MAXVALUE } La signification des options TIMESTAMP et SCN est la même que dans la clause AS OF. MINVALUE et MAXVALUE permettent  d’obtenir la plus ancienne ligne et la plus récente.En complément, vous pouvez utiliser plusieurs pseudo­colonnes qui  vous donneront des informations sur les différentes versions de la ligne :  VERSIONS_STARTTIME  Date/heure de début de validité de la version de la ligne.  VERSIONS_STARTSCN  Numéro SCN de début de validité de la version de la ligne.  VERSIONS_ENDTIME  Date/heure de fin de validité de la version de la ligne.  VERSIONS_ENDSCN  Numéro SCN de fin de validité de la version de la ligne.  VERSIONS_XID  Identifiant de la transaction à l’origine de la version de la ligne.  VERSIONS_OPERATION  Opération à l’origine de la version de la ligne : I pour INSERT, U pour UPDATE et D pour DELETE.  Exemple  SQL> BEGIN 2 INSERT INTO adherent(numero,prenom) VALUES(24,’Olivier’); 3 COMMIT; 4 UPDATE adherent SET prenom = ’David’ WHERE numero = 24; 5 COMMIT; 6 DELETE FROM adherent WHERE numero = 24; 7 COMMIT; 8 END; 9 / Procédure PL/SQL terminée avec succès. SQL> SELECT versions_startscn, versions_endscn, 2 versions_xid, versions_operation, 3 prenom 4 FROM adherent VERSIONS BETWEEN SCN MINVALUE AND MAXVALUE 5 WHERE numero = 24 6 ORDER BY versions_startscn; VERSIONS_STARTSCN VERSIONS_ENDSCN VERSIONS_XID V PRENOM ----------------- --------------- ---------------- - ---------177002 177003 030012000D010000 I Olivier 177003 177004 020019000E010000 U David 177004 01000D0008010000 D David   Une nouvelle version d’une ligne est créée lors d’un COMMIT.

Flashback Transaction Query © ENI Editions - All rights reserved - Algeria Educ

- 3-

Pour voir les modifications réalisées par une ou plusieurs transactions sur un certain intervalle de temps, vous pouvez  interroger la vue FLASHBACK_TRANSACTION_QUERY. Cette vue donne des informations sur toutes les transactions de la  base de données pouvant faire l’objet d’un flashback. Les principales colonnes de cette vue sont les suivantes :  XID  Identifiant de la transaction.  START_SCN  Numéro SCN de début de la transaction.  START_TIMESTAMP  Date/heure de début de la transaction.  COMMIT_SCN  Numéro SCN du COMMIT de la transaction (vide pour la transaction en cours).  COMMIT_TIMESTAMP  Date/heure du COMMIT de la transaction (vide pour la transaction en cours).  LOGON_USER  Compte utilisateur de la session.  OPERATION  Opération réalisée dans la transaction : INSERT, UPDATE, DELETE.  TABLE_NAME  Nom de la table concernée par l’opération.  TABLE_OWNER  Propriétaire de la table concernée par l’opération.  ROW_ID  ROWID de la ligne concernée par l’opération.  UNDO_SQL  Ordre SQL permettant d’annuler l’opération.  Vous pouvez interroger cette vue de différentes manières :  ●

par le nom d’une table sur laquelle vous avez noté un problème ; 

●

par le ROWID d’une ligne sur laquelle vous avez noté un problème ; 

●

par  un  identifiant  de  transaction  relevé  en  analysant  les  différents  versions  d’une  ligne  (pseudo­colonne  VERSIONS_XID). 

Exemple  SQL> SELECT xid, start_scn,commit_scn, logon_user, undo_sql 2 FROM flashback_transaction_query 3 WHERE table_name=’ADHERENT’ AND table_owner=’DIANE’ - 4-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

4 AND operation =’DELETE’ AND start_timestamp > SYSDATE-1; XID START_SCN COMMIT_SCN LOGON_USER ---------------- ---------- ---------- --------------UNDO_SQL ----------------------------------------------------------------... 030006000D010000 176702 176712 DIANE insert into "DIANE"."ADHERENT"("NUMERO","NOM","PRENOM","SEXE","DATE_ NAISSANCE","TELEPHONE","REF_CATEGORIE") values (’22’,NULL, ’Olivier’,NULL,NULL,NULL,NULL); 030006000D010000 176702 176712 DIANE insert into "DIANE"."ADHERENT"("NUMERO","NOM","PRENOM","SEXE","DATE_ NAISSANCE","TELEPHONE","REF_CATEGORIE") values (’21’,’HEURTEL’ ,NULL,NULL,NULL,NULL,NULL); ... Sur  cet  exemple,  nous  recherchons  toutes  les  transactions  qui  ont  fait  un  DELETE  sur  la  table  ADHERENT  du  schéma  DIANE,  la  dernière  journée.  Les  deux  lignes  affichées  appartiennent  à  la  même  transaction  (même XID).  La  colonne  UNDO_SQL donne l’ordre SQL qui peut être utilisé pour récréer la ligne. 

3. Niveau table  Flashback Table Pour ramener une table à l’état où elle était à un moment donné du passé, vous pouvez utiliser l’ordre SQL FLASHBACK TABLE.  Syntaxe  FLASHBACK nom_table [,…] TO instant [ENABLE TRIGGERS] ; instant { TIMESTAMP | SCN } expression | RESTORE POINT nom La signification des options TIMESTAMP et SCN est la même que dans la clause AS OF. L’option RESTORE POINT permet de  revenir  à  un  point  de  retour  créé  au  préalable  avec  l’ordre  SQL  CREATE RESTORE POINT ; les  points  de  retour  sont  visibles dans la vue V$RESTORE_POINT. L’option ENABLE TRIGGERS permet d’autoriser le déclenchement des triggers qui  existent et qui sont actuellement actifs ; par défaut, ils ne sont pas déclenchés.  Pour réaliser cette opération, il faut :  ●

●

●

avoir le privilège objet FLASHBACK sur la table ou le privilège système FLASHBACK ANY TABLE ;  détenir  les  privilèges  objet  SELECT,  INSERT,  et  ALTER  sur  la  table  (ou  les  privilèges  système  ANY  correspondants) ;  que le déplacement de lignes soit autorisé sur la table (ROW MOVEMENT). 

Exemple  -- je supprime toutes les lignes d’une table SQL> DELETE FROM diane.adherent; 20 lignes supprimées. SQL> COMMIT; Validation effectuée. SQL> SELECT COUNT(*) FROM diane.adherent; COUNT(*) ---------0 -- 5 minutes plus tard, je m’aperçoit de mon erreur ... SQL> FLASHBACK TABLE diane.adherent

© ENI Editions - All rights reserved - Algeria Educ

- 5-

2 TO TIMESTAMP SYSTIMESTAMP - INTERVAL ’5’ MINUTE; FLASHBACK TABLE diane.adherent TO TIMESTAMP SYSTIMESTAMP - INTERVAL ’5’ MINUTE * ERROR at line 1: ORA-08189: opération Flashback impossible sur la table : le mouvement de ligne n’est pas activé -- il faut autoriser le déplacement de lignes SQL> ALTER TABLE diane.adherent ENABLE ROW MOVEMENT; Table modifiée. SQL> FLASHBACK TABLE diane.adherent 2 TO TIMESTAMP SYSTIMESTAMP - INTERVAL ’5’ MINUTE; Flashback terrminé. SQL> SELECT COUNT(*) FROM diane.adherent; COUNT(*) ---------20 -- c’est cool ... Flashback Drop Depuis  la  version  10,  lorsqu’une  table  est  supprimée,  elle  ne  l’est  pas  complètement,  sauf  si  vous  utilisez  l’option  PURGE de l’ordre SQL DROP TABLE ; elle est placée dans une "corbeille". Dans les grandes lignes, une table supprimée  est en fait renommée par Oracle, et l’espace associé n’est pas récupéré immédiatement (bien qu’il apparaisse dans la  vue DBA_FREE_SPACE) ; Oracle fait la même chose avec les dépendances de l’objet, notamment les index. L’espace de  stockage  des  objets  se  trouvant  dans  la  corbeille  n’est  pas  réutilisé,  sauf  en  cas  de  manque  d’espace  dans  le  tablespace.  Si Oracle a besoin d’allouer une nouvelle extension dans un tablespace, et qu’il n’y ait plus suffisamment de place,  Oracle récupèrera l’espace correspondant aux objets de la corbeille, en commençant par les objets les plus anciens  (FIFO : First In First Out). Oracle réalise cette récupération avant de faire grandir le fichier de données du tablespace  si celui­ci a la propriété AUTOEXTEND.  La  "corbeille"  se  matérialise  tout  simplement  par  une  table  du  dictionnaire  de  données  qui  peut  être  interrogée  à  l’aide des vues USER_RECYCLEBIN et DBA_RECYCLEBIN, ou à l’aide de la commande SQL*Plus SHOW RECYCLEBIN (interroge  la vue USER_ RECYCLEBIN).  Les colonnes les plus intéressantes de la vue DBA_RECYCLEBIN sont les suivantes :  OWNER  Nom du propriétaire de l’objet.  OBJECT_NAME  Nom de l’objet dans la corbeille.  ORIGINAL_NAME  Nom d’origine de l’objet.  TYPE  Type de l’objet (TABLE, INDEX, TRIGGER, etc.).  TS_NAME  Nom du tablespace dans lequel l’objet est stocké.  CREATETIME  Date de création de l’objet.  DROPTIME 

- 6-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

Date de suppression de l’objet.  CAN_UNDROP  Indique si l’objet peut être sorti de la corbeille (YES ou NO).  CAN_PURGE  Indique si l’objet peut être définitivement supprimé (YES ou NO).  SPACE  Nombre de blocs utilisés par l’objet.  En complément, les vues DBA_INDEXES et DBA_TABLES contiennent une colonne DROPPED indiquant si la table ou l’index  est supprimé (YES ou NO).  Pour "annuler" la suppression d’une table, vous pouvez utiliser une variante de l’ordre SQL FLASHBACK TABLE.  Syntaxe  FLASHBACK TABLE nom_table TO BEFORE DROP [RENAME TO nouveau_nom] ; Dans  la  commande  FLASHBACK TABLE,  vous  pouvez  utiliser  le  nom  d’origine  de  l’objet  ou  le  nom  de  l’objet  dans  la  corbeille.  Si  plusieurs  tables  dans  la  corbeille  ont  le  même  nom  d’origine  (table  supprimée,  puis  recréée  puis  de  nouveau  supprimée), et que vous utilisiez le nom d’origine, Oracle ressortira de la corbeille la dernière table supprimée portant  ce nom (LIFO : Last In First Out). Pour ressortir spécifiquement une version plus ancienne, vous pouvez utiliser le nom  unique généré par Oracle pour placer la table dans la corbeille.  Lorsque vous sortez une table de la corbeille, vous pouvez lui attribuer un nouveau nom, ce qui est pratique si une  table portant le même nom existe dans le schéma. Les objets associés sont également ressortis de la corbeille, mais  ils gardent le nom qu’ils avaient dans la corbeille.  L’espace  utilisé  par  les  objets  stockés  dans  la  corbeille  peut  être  explicitement  et  définitivement  récupéré  grâce  à  l’ordre SQL PURGE.  Syntaxe  ●

Purger une table ou un index (avec le nom d’origine ou le nom dans la corbeille, et un principe FIFO si vous  utilisez le nom d’origine et que plusieurs objets portent ce nom) 

PURGE { INDEX | TABLE } nom ; ●

Purger les tables et les index d’un tablespace, en vous limitant éventuellement aux objets d’un schéma 

PURGE TABLESPACE nom_tablespace [USER nom_utilisateur] ; ●

Purger toutes les tables et les index de l’utilisateur courant 

PURGE RECYCLEBIN ; ●

Purger toutes les tables et les index 

PURGE DBA_RECYCLEBIN ; Vous pouvez noter les restrictions suivantes :  ●

Les tables supprimées par un DROP TABLESPACE ou un DROP USER ne sont pas placées dans la corbeille. 

●

Il n’y a pas de corbeille pour le tablespace SYSTEM. 

●

Il  n’y  a  pas  de  corbeille  pour  les  tablespaces  gérés  par  le  dictionnaire  (uniquement  pour  les  tablespaces  gérés localement). 

© ENI Editions - All rights reserved - Algeria Educ

- 7-

Exemple  -- je supprime la table SQL> DROP TABLE diane.adherent; Table supprimée. -- elle est dans la corbeille (avec ces dépendances) SQL> SELECT original_name,object_name,type, 2 ts_name,can_undrop,can_purge 3 FROM dba_recyclebin WHERE owner=’DIANE’; 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 (sous­répertoire nommé flashback).  La  durée  de  conservation  des  informations  dans  le  fichier  journal  flashback  est  définie  par  le  paramètre  d’initialisation  DB_FLASHBACK_RETENTION_TARGET  (en  minutes,  1 440  par  défaut,  soit  un  jour).  Comme  le  nom  du  paramètre l’indique, la durée de conservation indiquée est un objectif. S’il n’y a pas suffisamment de place dans la  zone de récupération, Oracle réduira la durée de conservation. Vous devez donc, là encore, dimensionner avec soin  la zone de récupération rapide.  Lors  d’une  opération  de  flashback  vers  un  instant  T  dans  le  passé,  les  blocs  seront  restaurés  à  partir  du  fichier  journal  flashback,  à  l’état  où  ils  étaient  à  cet  instant  ou  quelques  instants  avant ; ensuite,  les  fichiers  de  journalisation seront appliqués. Ceux­ci doivent donc être disponibles et la base de données fonctionner également  dans le mode ARCHIVELOG.    La fonctionnalité de Flashback Database est disponible uniquement en Enterprise Edition.

b. Activer le mode FLASHBACK  Pour  >mettre  la  base  de  données  dans  le  mode  FLASHBACK,  vous  devez  monter  la  base  de  données  et  exécuter  l’ordre SQL ALTER DATABASE FLASHBACK ON :  SQL> ... 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 ; celle­ci peut varier en fonction de la configuration  de  la  base  de  données.  La  stratégie  usuelle  proposée  par  Oracle  en  Enterprise  Edition  est  basée  sur  des  sauvegardes incrémentales :  ●

sauvegarde par copie image de la base de données la première fois ; 

●

sauvegarde incrémentale de niveau 1 ensuite ; 

●

application  régulière  des  sauvegardes  incrémentales  à  la  copie  image  pour  la  faire  progresser  dans  le  temps. 

  La page suivante permet de programmer la sauvegarde. 

- 6-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

  La  dernière  page  donne  un  récapitulatif  de  la  sauvegarde  et  montre  le  script  RMAN  correspondant.  Vous  pouvez  cliquer sur le bouton Soumettre le travail si la stratégie proposée par Oracle vous convient. 

c. Stratégie de sauvegarde personnalisée  Lorsque  vous  choisissez  l’option  Sauvegarde  personnalisée,  la  première  page  permet  de  sélectionner  le  type  d’objet  à  sauvegarder  (totalité  de  la  base,  tablespaces,  etc.)  et  de  saisir  les  informations  d’identification  et  de  connexion à l’hôte. 

  En  fonction  du  type  d’objet  sélectionné,  la  page  suivante  permet  de  préciser  la  sélection.  Si  vous  sélectionnez  l’intégralité de la base de données, vous arrivez directement sur la page de choix des options. 

© ENI Editions - All rights reserved - Algeria Educ

- 7-

  La page Options permet de préciser plusieurs options sur la sauvegarde :  ●

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 contre­vérifier) ; 

●

supprimer les sauvegardes obsolètes (bouton Supprimer tous les éléments obsolètes) ; 

●

- 10 -

cataloguer des fichiers non connus du référentiel RMAN (bouton Ecrire des fichiers supplémentaires dans  le catalogue) ; 

openmirrors.com

supprimer  tous  les  objets  ayant  le  statut  EXPIRED  (bouton  Supprimer  tous  les  éléments  arrivés  à  expiration). 

© ENI Editions - All rights reserved - Algeria Educ

4. Récupération  a. Démarrer une récupération  Si  la  base  de  données  n’est  pas  ouverte,  vous  accédez  à  l’assistant  récupération,  grâce  au  bouton  Effectuer  la  récupération qui est proposé sur la page donnant le statut de la base de données : 

  Après  saisie  des  informations  d’’identification  et  de  connexion  à  l’hôte  puis  à  la  base  de  données  (connexion  SYSDBA), vous accédez à la page de récupération (voir ci­dessous).  Si la base de données est ouverte, vous accédez à l’assistant récupération en cliquant sur le lien Disponibilité puis  sur le lien Effectuer la récupération.  Si un échec sur un fichier a été détecté, Oracle déclenche une alerte critique dans la catégorie "Echec de données".  Ces alertes peuvent être visualisées dans le cadre Alertes de la page d’accueil : 

 

b. L’assistant de récupération 

© ENI Editions - All rights reserved - Algeria Educ

- 11 -

  Les  informations  affichées  en  haut  de  la  page  dépendent  de  la  nature  du  problème.  Sur  l’exemple  ci­dessus,  un  échec  a  été  détecté  mais  la  base  de  données  est  ouverte.  Si  la  base  de  données  est  fermée,  l’affichage  le  mentionne. Exemple : 

  Si vous ouvrez cette page alors qu’il n’y a aucun problème, aucune information n’est affichée en haut.  Normalement,  en  cas  de  problème,  des  informations  de  diagnostic  provenant  du  Data  Recovery  Advisor  sont  affichées  et  le  bouton  Conseiller  et  récupérer  est  actif ; vous  pouvez  cliquer  ce  bouton  pour  effectuer  la  récupération à l’aide du Data Recovery Advisor (cf. Exemple de récupération avec le Data Recovery Advisor). C’est la  méthode la plus simple pour effectuer la récupération.  Si le problème n’est pas considéré comme un échec par le Data Recovery Advisor, des informations de diagnostic sont  quand même affichées en haut de la page, mais le bouton Conseiller et récupérer est inactif : 

  Dans  ce  cas,  en  cliquant  dans  l’ordre  sur  les  liens  affichés,  le  Database  Control  vous  guide  pour  effectuer  la  récupération (cf. Exemple de récupération ordonnée par l’utilisateur).  Si vous souhaitez effectuer une récupération alors qu’aucun problème n’a été détecté par Oracle (par exemple pour  revenir  avant  un  ordre  SQL  malencontreux),  ou  si  vous  souhaitez  résoudre  un  problème  avec  votre  propre  stratégie, vous pouvez démarrer une récupération dite "ordonnée par l’utilisateur" : 

- 12 -

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

  Pour cela, vous devez sélectionner l’étendue  de  la  récupération  et  un  type  d’opération, puis cliquer sur le bouton  Récupérer (cf. Exemple de récupération ordonnée par l’utilisateur).  Avant  de  démarrer  la  récupération  avec  une  des  méthodes  présentées  ci­dessus,  vérifiez  que  des  informations d’identification et de connexion à l’hôte sont correctement saisies dans le bas de la page. 

c. Exemple de récupération avec le Data Recovery Advisor  Vous pouvez accéder à la page du Data Recovery Advisor de différentes manières :  ●

en cliquant sur le bouton Conseiller et récupérer de la page de récupération ; 

●

en cliquant sur le lien Data Recovery Advisor du centre de conseil ; 

●

en  cliquant  sur  le  bouton  Lancer  Recovery  Advisor  des  pages  de  résultat  de  l’exécution  des  outils  de  vérification (cf. Chapitre Les outils d’administration section Diagnostiquer les problèmes). 

  Cette page affiche les échecs détectés par le Data Recovery Advisor. Par défaut, seuls les échecs de statut OPEN et  de  priorité  CRITICAL  ou  HIGH  sont  affichés ; vous  pouvez  utiliser  le  petit  formulaire  de  recherche  pour  filtrer  les  échecs affichés.  Un clic sur le bouton Conseil permet d’afficher les conseils de résolution pour les échecs sélectionnés dans la liste. 

© ENI Editions - All rights reserved - Algeria Educ

- 13 -

Le conseiller commence par afficher les actions manuelles qui peuvent être réalisées pour effectuer la récupération : 

  Pour afficher les actions de récupération automatique identifiées par le Data  Recovery  Advisor, vous pouvez cliquer  sur le bouton Poursuivre avec les conseils. 

  Pour exécuter les actions de récupération automatique identifiées par le Data Recovery Advisor, vous pouvez cliquer  sur le bouton Continuer. 

  Cliquez sur le bouton Soumettre le travail de récupération pour lancer la récupération.  Si la base de données est ouverte, le Data Recovery Advisor lance le travail de récupération et vous rend la main : 

- 14 -

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

  Vous pouvez retrouver ce travail en cliquant sur le lien Travaux (cadre Liens associés situé dans le bas de la page  d’accueil de chaque onglet).  Si la base de données est fermée, le Data Recovery Advisor attend que le travail se termine puis affiche le résultat : 

  À ce stade, deux cas se présentent en général :  La base de données était montée (pas de problème avec les fichiers de contrôle) Si la récupération a réussi, un bouton Ouvrir la base de données est présent et il ne reste plus qu’à cliquer sur ce  bouton pour ouvrir la base de données.  La base de données n’était pas montée (problème avec les fichiers de contrôle) Si la récupération a réussi, la base de données est montée mais le Data Recovery Advisor ne sait pas encore si elle  peut être ouverte ; le bouton Ouvrir la base de données n’est pas présent.  Si vous cliquez sur le bouton  OK, vous revenez sur la page de statut de la base de données et vous pouvez de  nouveau cliquer sur le bouton Effectuer la récupération pour revenir sur la page de récupération.  S’il n’y a plus d’échec de fichier, la page se présente ainsi : 

  Pour ouvrir la base de données, cliquez sur le lien Instance de base de données pour revenir à la page de statut,  puis sur le bouton Démarrer (cf. section Démarrage du chapitre Démarrage et arrêt).  © ENI Editions - All rights reserved - Algeria Educ

- 15 -

S’il y a des échecs de fichier, la page se présente ainsi et une nouvelle opération de récupération est nécessaire : 

  Parfois les informations du Data Recovery Advisor ne s’affichent pas correctement ; cliquer sur le lien Statut  en  cours  résout,  généralement,  ce  problème.  Vous  pouvez  aussi  cliquer  sur  le  lien  Echecs  de  base  de  données pour afficher la page du Data Recovery Advisor. 

d. Exemple de récupération ordonnée par l’utilisateur  Pour  illustrer  le  fonctionnement  de  l’assistant,  nous  allons  prendre  le  cas  d’une  récupération  d’un  fichier  de  données : 

 

■

Cliquez sur le bouton Récupérer. 

  La  page  suivante  permet  de  sélectionner  les  fichiers  de  données  à  récupérer  (bouton  Ajouter) ; les  fichiers  endommagés détectés par Oracle sont proposés par défaut dans la liste. 

- 16 -

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

  La  page  suivante  permet  d’indiquer  s’il  faut  restaurer  les  fichiers  de  données  à  leur  emplacement  d’origine  ou  ailleurs. 

  La  dernière  page  donne  un  récapitulatif  de  la  récupération.  Vous  pouvez  cliquer  sur  le  bouton  Modifier  le  script  RMAN  pour  voir  le  script  RMAN  correspondant,  et  au  besoin  le  modifier.  Vous  pouvez  cliquer  sur  le  bouton  Soumettre pour lancer l’opération. L’opération n’est pas lancée sous la forme d’un travail détaché ; vous restez sur  la page tout le temps de l’opération, sans aucune information sur son degré d’avancement.  Lorsque l’opération est terminée, le rapport RMAN est affiché. 

e. Flashback  Base de données L’assistant vous permet de faire une récupération de toute la base de données jusqu’à l’heure en cours ou jusqu’à  un point antérieur dans le temps (base montée uniquement) : 

© ENI Editions - All rights reserved - Algeria Educ

- 17 -

  Dans  ce  cas,  si  la  journalisation  flashback  est  active  sur  votre  base  de  données,  Oracle  vous  indique  qu’il  peut  utiliser la fonctionnalité de flashback de la base de données, si l’heure de retour demandée est compatible avec les  journaux. Cliquez sur le bouton Récupérer et laissez­vous guider.  Table Parmi les types d’objets d’une récupération, vous pouvez choisir « Tables » : 

  Dans ce cas, Oracle vous propose de faire un flashback soit pour ramener la table dans un état antérieur, soit pour  annuler la suppression d’une table. Là encore, cliquez sur le bouton Récupérer et laissez­vous guider.  Ligne Les fonctionnalités de flashback de niveau ligne, mais aussi de niveau table, sont accessibles à partir de la page de  gestion des tables, via les menus Interrogation de versions Flashback et Table Flashback : 

 

- 18 -

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

Vue d’ensemble  Les  outils  Data  Pump,  Export,  Import  et  SQL*Loader  sont  des  outils  très  puissants  comportant  de  nombreuses  fonctionnalités ; un ouvrage entier pourrait leur être consacré.  L’objectif de ce chapitre est donc de présenter les principes de fonctionnement généraux de ces différents outils, de  donner quelques conseils sur leur utilisation, illustrés par quelques exemples classiques d’utilisation.Pour approfondir  le sujet, vous pouvez consulter la documentation Oracle® Database Utilities.  Oracle propose trois utilitaires permettant d’administrer les données dans une base :  ●

●

●

Data Pump Export : permet d’exporter dans un fichier binaire propriétaire Oracle tout ou une partie des objets  (structure et/ou données) d’une base de données ;  Data  Pump  Import : permet  d’importer  dans  une  base  de  données  tout  ou  une  partie  des  objets  (structure  et/ou données) préalablement exportés par l’outil Data Pump Export ;  SQL*Loader : permet  de  charger  dans  des  tables  d’une  base  de  données,  des  données  stockées  dans  des  fichiers ASCII. 

Les  outils  Data  Pump  sont  apparus  en  version  10.  Dans  les  versions  précédentes,  il  existait  deux  outils  équivalents  simplement appelés Export et Import. Ces outils existent toujours pour des raisons de compatibilité ascendantes, mais  les outils Data Pump offrent bien plus de fonctionnalités (voir les remarques ci­après).  Pour utiliser ces outils, la base de données doit être ouverte.  Tous ces outils peuvent être utilisés par l’intermédiaire du Database Control.  Les  outils  Data  Pump  (ou  les  anciens  outils  d’export  et  d’import)  servent  essentiellement  à  échanger  des  objets  (structure et/ou données) entre deux bases de données Oracle, qui peuvent être sur des plates­formes différentes, et  qui peuvent avoir des versions différentes. Les outils Data Pump présentent de nombreux avantages par rapport aux  anciens outils d’export et d’import :  ●

plus rapides ; 

●

possibilité d’arrêter un travail Data Pump, puis de redémarrer ; 

●

possibilité de détacher sa session d’un travail Data Pump, puis de la rattacher ultérieurement ; 

●

possibilité de faire des transferts directs, à travers le réseau, entre deux bases de données ; 

●

plus de finesse dans la sélection des objets à exporter ou importer ; 

●

possibilité d’avoir une estimation de l’espace nécessaire lors d’un export ; 

●

possibilité de paralléliser une opération (Enterprise Edition uniquement). 

Data  Pump  n’est  pas  compatible  avec  les  outils  d’export  et  d’import  des  versions  précédentes : un  fichier  exporté  à  l’aide  de  l’outil  d’export  d’une  version  précédente  ne  peut  pas  être  lu  avec  l’outil  d’import  Data  Pump  (et  réciproquement).  Pour  échanger  des  données  entre  une  base  Oracle  version  10  ou  11  et  une  base  d’une  version  précédente, il faut utiliser les outils d’export et d’import traditionnels.  Dans ce chapitre, nous ne présenterons pas les anciens outils d’export et d’import. Par contre, nous présenterons les  outils Data Pump.  L’outil SQL*Loader sert essentiellement à charger des données provenant d’une autre application non Oracle.  Parmi les fonctionnalités de SQL*Loader, les suivantes sont particulièrement intéressantes :  ●

Il y a peu de limitation sur le format des données du fichier externe (largeur fixe, avec séparateur, etc.) ; 

●

Plusieurs fichiers externes peuvent être chargés dans la même session ; 

●

Plusieurs tables peuvent être chargées dans la même session ; 

© ENI Editions - All rights reserved - Algeria Educ

- 1-

●

Des critères peuvent être définis pour éliminer certaines données du fichier externe ; 

●

Les données peuvent être transformées avec des fonctions SQL pendant le chargement ; 

●

Des numéros séquentiels uniques peuvent être générés pour certaines colonnes. 

Oracle ne propose pas réellement d’outil pour extraire des données dans un fichier ASCII. Il faut développer des scripts  SQL (avec des requêtes SELECT; et la commande SPOOL pour l’écriture dans un fichier) ou des programmes en PL/SQL.  Nous en donnerons des exemples en fin de chapitre.  Depuis la version 10, Oracle propose aussi le package DBMS_FILE_TRANSFER; qui permet d’effectuer des copies  de fichiers binaires, soit localement, soit entre bases de données. Ce package peut être intéressant pour des  procédures de transfert de données. Voir la documentation PL/SQL Packages and Types Reference. 

- 2-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

L’instance  1. La SGA  a. Vue d’ensemble  La SGA (System Global Area) est une zone de mémoire partagée par les différents processus de l’instance.  La SGA est allouée au démarrage de l’instance et libérée lors de l’arrêt  de  l’instance. Elle est dimensionnée par un  ensemble de paramètres définis dans le fichier de paramètres.  Depuis  la  version  9  d’Oracle,  la  SGA  est  redimensionnable  à  chaud.  Depuis  la  version  10  d’Oracle,  certaines  structures de la SGA peuvent être gérées automatiquement (cf. section La gestion de la mémoire dans ce chapitre).  La taille maximale de la SGA est limitée par le paramètre SGA_MAX_SIZE.  La SGA comporte les structures suivantes :  ●

Database Buffer Cache : cache de données ; 

●

Redo Log Buffer : mémoire tampon pour l’enregistrement des modifications apportées à la base de données ; 

●

Shared Pool : zone de partage des requêtes et du dictionnaire Oracle ; 

●

Java Pool : mémoire utilisée par la machine virtuelle Java intégrée ; 

●

●

●

Large  Pool  :  zone  de  mémoire  optionnelle  utilisée  par  différents  processus  dans  des  configurations  particulières ;  Streams  Pool :  zone  de  mémoire  utilisée  par  la  fonctionnalité  Streams  (fonctionnalité  qui  permet  de  faire  circuler des informations entre processus) ;  Result Cache (nouveau en version 11) : cache pour le résultat des requêtes SQL ou des fonctions PL/SQL. 

La SGA contient aussi une structure appelé "SGA fixe" qui contient des informations sur l’état de la base de données  et de l’instance, et sur les verrous. Cette SGA fixe n’est pas dimensionnée par le DBA ; sa taille est faible (quelques  centaines de Ko).  Dans Oracle Enterprise Manager, en français, Oracle utilise la terminologie suivante :  Database Buffer Cache : Cache de tampon  Shared Pool : Pool partagé  Java Pool : Pool java  Large Pool : Zone de mémoire LARGE POOL  Généralement, plus la SGA est grande, meilleures sont les performances... sous réserve que la SGA tienne  en mémoire physique ! 

b. La Shared Pool  La Shared Pool est composée principalement de deux structures :  ●

le Library Cache ; 

●

le Dictionary Cache. 

Le Library Cache contient des informations sur les ordres SQL et PL/SQL les plus récemment exécutés : 

© ENI Editions - All rights reserved - Algeria Educ

- 1-

●

le texte de l’ordre ; 

●

sa version analysée ; 

●

le plan d’exécution. 

Le Dictionary Cache contient les informations du dictionnaire de données Oracle les plus récemment utilisées :  ●

description des tables ; 

●

droits des utilisateurs ; 

●

etc. 

La Shared Pool est globalement dimensionnée par le paramètre d’initialisation SHARED_ POOL_SIZE. La répartition entre  le  Library  Cache  et  le  Dictionary  Cache  est  assurée  par  Oracle.  La  taille  de  Shared  Pool  est  typiquement  comprise  entre quelques dizaines de Mo et quelques centaines de Mo.  Le Library Cache Lorsqu’une  requête  doit  être  exécutée,  Oracle  doit  d’abord  l’analyser  (étape  de  parse)  pour  vérifier  qu’elle  est  syntaxiquement  correcte  (FROM  après  le  SELECT)  et  sémantiquement  correcte  (les  tables  et  colonnes  existent  et  l’utilisateur a le droit d’y accéder), puis déterminer le plan d’exécution de la requête (différentes étapes permettant  de traiter la requête).  Comme cette étape d’analyse prend un peu de temps et que le résultat consomme de la mémoire, Oracle cherche à  partager  les  requêtes  entre  les  utilisateurs  de  manière  à  gagner  du  temps  et  économiser  de  la  mémoire  si  un  utilisateur exécute une requête déjà exécutée au préalable (par lui ou par un autre utilisateur).  Lorsqu’une requête est exécutée pour la première fois, Oracle stocke le résultat de l’analyse dans le  Library Cache  puis exécute la requête. Lorsque la même requête est de nouveau exécutée plus tard, Oracle est en mesure de la  retrouver dans le Library Cache et de l’exécuter directement sans refaire l’analyse (ou tout du moins en faisant une  analyse plus légère). Dans la pratique, le Library Cache ayant une taille finie, Oracle utilise un algorithme LRU (Least  Recently  Used)  pour  gérer  le  cache  :  en  cas  de  manque  de  place, Oracle  supprime  du  cache  la  requête  utilisée  la  moins récemment.  Pour  Oracle,  deux  requêtes  sont  les  mêmes  si  elles  sont  identiques  au  caractère  près  (y  compris  majuscules/minuscules, espaces, etc.). Les requêtes suivantes sont toutes différentes les unes des autres :  select select SELECT SELECT

* * * *

from from FROM FROM

client client client client

where where WHERE WHERE

id id id id

= = = =

1; 1; 1; 2;

Lorsque les requêtes sont générées par un applicatif, il n’y a généralement pas de problème sur les majuscules et  les minuscules ou sur les espaces ; lorsqu’un utilisateur demande une fiche client dans l’application, la requête sous­ jacente est toujours écrite de la même manière... sauf peut­être pour des valeurs utilisées dans la clause WHERE (voir  les deux derniers exemples ci­dessus).  Dans  ce  cas,  l’identité  parfaite  peut  être  obtenue  en  utilisant  des  variables  bind  dans  le  texte  de  la  requête.  Exemple :  SELECT * FROM client WHERE id = :v; L’utilisation de variables bind dans le texte de la requête lors du développement permet d’améliorer le partage des  requêtes  et  peut  améliorer  de  manière  importante  les  performances  d’un  système  accédé  simultanément  par  un  grand nombre d’utilisateurs.  Les  principaux  middleware  utilisés  pour  interfacer  Oracle  et  les  outils  de  développement  permettent  d’utiliser  les  variables bind : OLE DB, Oracle Objects For OLE (OO4O), JDBC, Bibliothèque Oracle de PHP, etc.  Le  paramètre  d’initialisation  CURSOR_SHARING  permet  éventuellement  d’indiquer  à  Oracle  dans  quelles  conditions  deux  requêtes  peuvent  partager  le  même  curseur.  Voir  la  documentation  Oracle®  Database  Reference. 

Le Dictionary Cache

- 2-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

Comme nous le verrons au point Le dictionnaire de données tout Oracle... est dans Oracle, en l’occurrence dans le  dictionnaire de données.  Dans  le  dictionnaire  de  données,  Oracle  stocke  toutes  les  informations  relatives  à  la  base  de  données :  liste  des  tables et des colonnes, liste des utilisateurs et de leurs droits, informations sur le stockage, etc.  Lors  de  la  phase  d’analyse  d’une  requête,  Oracle  utilise  le  dictionnaire  de  données  pour  vérifier  que  les  objets  demandés existent, que l’utilisateur a le droit d’y accéder, pour déterminer où sont stockés les objets, etc.  Pour garantir un bon niveau de performance, Oracle cherche à maintenir tout ou partie du dictionnaire de données  en mémoire, dans le Dictionary Cache.    Le Dictionary Cache est aussi appelé Row Cache dans la documentation.

c. Le Database Buffer Cache  Le Database Buffer Cache contient les blocs de données les plus récemment utilisés :  ●

blocs de tables ; 

●

blocs d’index ; 

●

blocs de segments d’annulation, contenant la version précédente des données en cours de modification. 

Les  blocs  sont  lus  en  mémoire  par  les  processus  serveur  et  écrits  dans  les  fichiers  de  données  par  le  ou  les  processus d’arrière­plan DBWn.  Toute modification (INSERT, UPDATE, DELETE) d’un bloc s’effectue en mémoire et l’écriture sur disque est différée.  Le Database Buffer Cache est un cache de données qui joue le même rôle que la Shared Pool mais pour les données.  Les données de la base de données ne sont accessibles, en lecture ou en mise à jour, qu’après avoir été chargées  dans le Database Buffer Cache.  Dans la pratique, le Database Buffer Cache ayant une taille finie, Oracle utilise un algorithme LRU (Least Recently Used)  pour  gérer  le  cache  :  en  cas  de  manque  de  place,  Oracle  supprime  du  cache  les  données  utilisées  le  moins  récemment.  Le Database Buffer Cache est dimensionné par les paramètres suivants :  ■

DB_CACHE_SIZE : taille du cache pour la taille de bloc par défaut (poolDEFAULT) 

■

DB_nK_CACHE_SIZE : taille du cache pour les blocs de n Ko (n valant 2, 4, 8, 16 ou 32). 

Dans le cas où la base de données utilise des tablespaces ayant des tailles de blocs différentes de la taille de bloc  standard,  il  faut  dimensionner  d’autres  pools  dans  le  Database  Buffer  Cache,  pour  les  blocs  en  question  ;  cette  opération s’effectue grâce aux paramètres DB_nK_CACHE_SIZE.  Dans certaines configurations plus avancées, il est possible aussi de définir deux autres pools au sein du Database  Buffer Cache :  ■

■

Le pool KEEP destiné à stocker des données qui doivent rester le plus longtemps possible en mémoire. Ce pool est  dimensionné par le paramètre DB_KEEP_ CACHE_SIZE.  Le pool RECYCLE destiné à stocker des données qui n’ont pas vocation à rester longtemps en mémoire. Ce pool est  dimensionné par le paramètre DB_RECYCLE_ CACHE_SIZE. 

Avant  Oracle9i,  la  taille  du  Database  Buffer  Cache  était  définie  en  nombres  de  blocs  (d’une  taille  définie  par  DB_BLOCK_SIZE)  grâce  au  paramètre  DB_BLOCK_BUFFERS.  Ce  paramètre  existe  toujours  pour  des  raisons  de  compatibilité ascendante mais il est déprécié.    Généralement, augmenter la taille du Database Buffer Cache améliore les performances.

d. Le Redo Log Buffer 

© ENI Editions - All rights reserved - Algeria Educ

- 3-

Le Redo Log Buffer stocke les informations sur les modifications apportées à la base de données, avant leur écriture  dans un fichier de journalisation.  Ce buffer est utilisé de manière séquentielle (les modifications de plusieurs transactions se mélangent) et circulaire  (quand il est plein, il repart au début... après avoir été écrit sur disque dans un fichier de journalisation).  Pour chaque modification, une entrée redo (redo entry) est écrite dans le buffer.  Une  entrée  redo  est  composée  d’un  ensemble  de  vecteurs  (change  vector)  qui  décrivent  chacun  une  modification  atomique  d’un  bloc  (table,  index  ou  segment  d’annulation).  La  nouvelle  valeur,  mais  aussi  l’ancienne,  sont  ainsi  enregistrées dans le fichier de journalisation. Ainsi, les tables, les index, mais aussi les segments d’annulation, sont  "protégés"  par  les  fichiers  de  journalisation.  Lors  d’une  récupération,  les  fichiers  de  journalisation  contiennent  les  informations nécessaires pour refaire une transaction perdue (notion de roll forward) ou annuler une transaction en  cours au moment de l’incident (notion de roll back).  Le Redo Log Buffer est dimensionné par le paramètre LOG_BUFFER. 

e. Autres pools de la SGA  La Java Pool La Java Pool est dimensionnée par le paramètre JAVA_POOL_SIZE (24 Mo par défaut). Ce paramètre peut être mis à 0  si  la  machine  virtuelle  Java  intégrée  à  Oracle  n’est  pas  utilisée.  Vous  pouvez  consulter  la  documentation  Oracle®  Database  Java  Developer’s  Guide  pour  les  considérations  sur  la  mémoire  utilisée  par  la  machine  virtuelle  Java  intégrée.  La Large Pool La Large Pool est notamment utilisée dans la configuration serveur partagé (voir plus loin). Elle est dimensionnée par  le paramètre LARGE_POOL_SIZE. La valeur par défaut du paramètre est dérivée d’autres paramètres.  La Streams Pool La  Streams  Poolest  dimensionnée  par  le  paramètre  STREAMS_POOL_SIZE  (0  par  défaut).  Vous  pouvez  consulter  la  documentation  Oracle®  Streams  Concepts  and  Administration  pour  en  savoir  plus  sur  le  fonctionnement  de  la  fonctionnalité Streams.  Le Result Cache La  taille  maximum  du Result  Cache  est  dimensionnée  par  défaut  par  Oracle  en  fonction  de  la  quantité  de  mémoire  totale  disponible  pour  la  SGA  et  du  mode  de  gestion  de  la  mémoire  actuellement  utilisé  (voir  plus  loin).  En  cas  de  besoin,  cette  taille  maximum  peut  être  définie  par  le  paramètre  RESULT_CACHE_MAX_SIZE.  Vous  pouvez  consulter  la  documentation  Oracle®  Database  Performance  Tuning  Guide  pour  obtenir  plus  d’informations  sur  l’utilisation  du  Result Cache. 

f. La notion de granule  Un granule est une quantité de mémoire qui peut être allouée à une structure de la SGA. La taille du granule dépend  de la taille totale de la SGA :  ●

●

4 Mo si la taille totale de la SGA est inférieure ou égale à 1 Go ;  8  Mo  (plate­forme  Windows)  ou  16  Mo  (autres  plates­formes)  si  la  taille  totale  de  la  SGA  est  strictement  supérieure à 1 Go. 

L’allocation  de  mémoire  aux  structures  de  la  SGA  s’effectue  en  nombre  entier  de  granules  (avec  un  arrondi  automatique au granule supérieur si la valeur d’un paramètre n’est pas un multiple de la taille du granule). 

2. Les processus d’arrière­plan  a. Introduction  Les  processus  d’arrière­plan  ont  chacun  un  rôle  bien  précis  dans  le  fonctionnement  de  l’instance.  La  plupart  des  processus  d’arrière­plan  sont  lancés  au  démarrage  de  l’instance  et  arrêtés  lors  de  l’arrêt  de  l’instance.  Certains  processus peuvent être lancés et arrêtés au cours du fonctionnement de l’instance.  - 4-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

Il  existe,  en  tout,  une  trentaine  de  processus  d’arrière­plan  différents,  mais  certains  processus  d’arrière­plan  peuvent  être  lancés  en  plusieurs  exemplaires.  Chaque  processus  d’arrière­plan  a  un  nom  de  4  caractères,  éventuellement de la forme ABCn, n étant un numéro ou une lettre variable pour les processus multiples.  Les principaux processus d’arrière­plan pour une instance standard sont les suivants :  DBWn  LGWR  CKPT  SMON  ARCn  CJQn  PMON 

b. DBWn  Les  processus  d’arrière­plan  DBWn  (Database  Writer)  sont  chargés  d’écrire  les  blocs  modifiés  du  Database  Buffer  Cache dans les fichiers de données.  Généralement,  une  instance  a  un  seul  processus  Database  Writer  désigné  par  DBW0.  Sur  les  systèmes  multiprocesseurs et multidisques ayant une forte activité de mise à jour, il est possible, voire conseillé, de démarrer  plusieurs processus Database Writer (jusqu’à 20).  Les processus DBWn réalisent des écritures multiblocs, en différé par rapport aux modifications en mémoire.  L’écriture est déclenchée par un des événements suivants :  ●

●

Un processus serveur ne trouve pas de place dans le cache.  Périodiquement, pour faire avancer le point de reprise (position dans les fichiers de journalisation à partir de  laquelle la récupération de l’instance est susceptible de démarrer). 

Il est donc important de noter qu’il  n’y a pas de synchronisation entre la modification d’un bloc en mémoire, même  validée (COMMIT), et l’écriture sur disque des blocs en question.  À un instant donné, il est donc possible de se trouver dans la situation suivante :  ●

●

Un fichier de données peut ne pas contenir les données modifiées de transactions validées (COMMITées).  Inversement, si le  Database Buffer Cache est petit, si la validation tarde, si d’autres processus serveurs ont  besoin  de  place  dans  le  cache,  des  données  modifiées  de  transactions  non  validées  peuvent  être  écrites  dans les fichiers de données. 

Que  se  passe­t­il en cas de plantage de l’instance  à  cet  instant  précis  ?  Nous  verrons  dans  la  suite  que,  pour  les  deux  situations  précédentes,  les  informations  nécessaires  sont  présentes  dans  les  fichiers  de  journalisation  et  permettent à l’instance, lorsqu’elle redémarre, de remettre les fichiers de données en état (c’est la "récupération de  l’instance " déjà évoquée précédemment). 

c. LGWR  Le processus d’arrière­plan LGWR (Log Writer) est chargé d’écrire le Redo Log Buffer dans le fichier de journalisation  courant.  LGRW écrit séquentiellement dans les fichiers de journalisation.  L’écriture est déclenchée par un des événements suivants :  ●

Une transaction est validée (COMMIT). 

●

Le Redo Log Buffer est au tiers plein. 

●

Database  Writer  s’apprête  à  écrire  des  blocs  modifiés  de  transactions  non  validées  dans  les  fichiers  de  données. 

© ENI Editions - All rights reserved - Algeria Educ

- 5-

●

Un délai est dépassé (3 secondes). 

L’écriture dans les fichiers de journalisation du Redo Log Buffer est la seule chose qui se produit lors de la validation  (COMMIT) d’une transaction. Cette opération d’écriture étant normalement rapide, la validation est rapide (notion de  fast commit).  Inversement,  si  DBWn  écrit  dans  les  fichiers  de  données  des  blocs  modifiés  de  transactions  pas  encore  validées  (COMMITées), le Redo Log Buffer est écrit dans les fichiers de journalisation.  Nous  avons  vu  précédemment  que  le Redo  Log  Buffer  contient  les  anciennes  valeurs  des  données  modifiées  (dans  des blocs de segment d’annulation) et les nouvelles valeurs (dans des blocs de tables et d’index).  En cas d’arrêt anormal de l’instance, le fait qu’un fichier de données puisse ne pas contenir les données modifiées de  transactions validées ou contenir des données modifiées de transactions non validées, ne pose pas de problème :  grâce au processus d’écriture  décrit  ci­dessus,  les  fichiers  de  journalisation  contiennent  forcément  les  informations  nécessaires pour refaire les transactions validées (mettre dans les fichiers de données les données modifiées des  transactions validées) ou défaire les modifications non validées (remettre dans les fichiers de données les anciennes  données  pour  les  modifications  non  validées).  Cette  récupération  de  l’instance  après  un  arrêt  anormal  est  un  processus automatique qui ne requiert aucune intervention.  Lors de la validation d’une transaction, Oracle affecte un numéro SCN (System Change Number) à la transaction. Ce  numéro SCN est enregistré dans le fichier de journalisation et à d’autres endroits. Ce numéro est fondamental pour  la capacité du système à savoir où il en est. 

d. CKPT  Périodiquement, tous les blocs modifiés du Database  Buffer  Cache sont écrits dans les fichiers de données : c’est le  mécanisme  de  synchronisation  (checkpoint).  Par  ce  biais,  les  fichiers  de  données  et  les  fichiers  de  contrôle  sont  rendus cohérents (même numéro SCN). Cela permet de garantir que les blocs modifiés en mémoire sont bien écrits  dans les fichiers de données.  Ce mécanisme définit aussi un point de reprise dans les fichiers de journalisation (correspondant à un numéro SCN) :  cette position correspond à la modification de bloc la plus ancienne qui n’a pas encore été écrite dans un fichier de  données. En cas d’arrêt anormal de l’instance, ce point marque le début des données à utiliser pour la récupération  de l’instance.  Une synchronisation se déclenche notamment lors d’un basculement de fichier de journalisation. Cela provoque dans  ce  cas,  l’écriture  dans  les  fichiers  de  données  des  blocs  modifiés  (non  encore  écrits)  relatifs  aux  informations  présentes dans le fichier de journalisation.  Le  processus  d’arrière­plan  LGWR  s’interdit  de  commencer  à  écrire  dans  un  fichier  de  journalisation  dont  la  synchronisation  n’est  pas  terminée.  En  effet,  tant  que  cette  synchronisation  n’est  pas  terminée,  le  fichier  de  journalisation contient des informations qui seraient nécessaires pour une récupération de l’instance en cas d’arrêt  anormal.  Une  synchronisation  se  produit  aussi  lors  de  l’arrêt  de  la  base  de  données  et  lors  de  la  mise  hors  ligne  d’un  tablespace. Avant ces opérations de "fermeture", les blocs modifiés qui se trouvent encore en mémoire sont écrits  dans les fichiers de données.  Le processus d’arrière­plan CKPT (Checkpoint) a simplement pour rôle d’enregistrer le point de reprise dans l’en­tête  des fichiers de données et dans le fichier de contrôle. 

e. SMON  Le  processus  d’arrière­plan SMON (System Monitor) est principalement chargé de faire la récupération de l’instance  après un arrêt anormal.  Il est aussi chargé de libérer les segments temporaires inutilisés et de compacter l’espace contigu disponible dans  les  tablespaces  gérés  par  le  dictionnaire  (voir  le  chapitre  Gestion  des  tablespaces  et  des  fichiers  de  données).  Au  cours de la récupération de l’instance, SMON effectue deux opérations :  ●

●

Un  roll forward  pour  appliquer  aux  fichiers  de  données  les  modifications  non  enregistrées  des  transactions  validées.  Puis  un roll  back  pour  enlever  des  fichiers  de  données  les  modifications  enregistrées  des  transactions  non  validées. 

f. PMON 

- 6-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

Le  processus  d’arrière­plan  PMON  (Process  Monitor)  est  principalement  chargé  du  nettoyage  lors  du  plantage  d’un  processus utilisateur :  ●

Annulation (ROLLBACK) de la transaction. 

●

Libération des verrous et des ressources. 

PMON est capable de détecter les situations où un processus utilisateur qui a ouvert une session sur le serveur n’est  plus "présent" et n’a pas fermé la session. La cause de la non "présence" du processus utilisateur est variable : fin  anormale de l’application sur le poste de l’utilisateur, coupure réseau, etc.  Dans tous les cas, PMON se charge du nettoyage en effectuant une annulation (ROLLBACK) de la transaction, cette  annulation libérant notamment les verrous posés par la transaction. Du point de vue de l’intégrité des données dans  la base de données, la disparition du processus utilisateur ne pose pas de problème. 

g. CJQn   Les processus d’arrière­plan CJQn (Job Queue) sont chargés d’exécuter périodiquement les tâches programmées sur  le système.  Un processus coordinateur (CJQ0) surveille s’il y a des travaux à exécuter. Si c’est le cas, il démarre un processus  esclave (J000 à J999) qui va se charger d’exécuter le travail.  Des  travaux  (traitements  PL/SQL  par  exemple)  peuvent  être  programmés  à  l’aide  du  package  DBMS_SCHEDULER ou des fonctions de programmation d’Oracle Enterprise Manager. 

h. ARCn   Les processus d’arrière­plan ARCn (Archiver) sont chargés de l’archivage des fichiers de journalisation pleins.  Le fonctionnement de ces processus sera présenté plus en détail dans le chapitre Sauvegarde et récupération. 

3. Les processus serveurs  Les processus serveurs sont chargés de traiter les requêtes des utilisateurs, et notamment de charger les données  nécessaires dans le Database Buffer Cache.  Le processus serveur communique (localement ou à travers le réseau) avec un processus utilisateur correspondant à  l’application de l’utilisateur.  Dans  la  configuration  par  défaut,  Oracle  lance  un  processus  serveur  dédié  pour  chaque  utilisateur  (dedicated  server  configuration). Ce processus ne traite que les requêtes de l’utilisateur en question.  Si  besoin,  Oracle  peut  être  configuré  en  serveur  partagé  (shared  server  configuration)  de  manière  à  avoir  des  processus serveurs partagés par plusieurs processus utilisateurs.  Dans  une  configuration  serveur  partagé,  un  petit  nombre  de  processus  serveurs  sont  partagés  entre  les  différents  processus  utilisateurs  et  peuvent  traiter  indifféremment  les  requêtes  de  n’importe  quel  processus  utilisateur.  Cette  configuration permet de limiter le nombre de processus lancés sur le serveur et d’optimiser l’utilisation des ressources  systèmes.  Cette  configuration  est  une  configuration  avancée  qui  n’est  pas  couverte  dans  cet  ouvrage.  La  mise  en  œ uvre de cette configuration est présentée dans la documentation Oracle® Database Administrator’s Guide.  Dans les deux cas, la communication entre le processus utilisateur et le processus serveur est locale, si l’application  est lancée sur le serveur ou s’effectue à travers le réseau (grâce à la couche Oracle Net), si l’application est lancée sur  un poste du réseau. 

4. La PGA  La PGA (Program Global Area) est la mémoire privée des différents processus.  Pour un processus serveur, la PGA contient :  ●

une zone de travail SQL (SQL work area) allouée dynamiquement pour certaines opérations (tri par exemple) ; 

© ENI Editions - All rights reserved - Algeria Educ

- 7-

●

des informations sur la session ; 

●

des informations sur le traitement des requêtes de la session ; 

●

les variables de session. 

La PGA totale, allouée à tous les processus serveurs, est appelée PGA agrégée (aggregated PGA) ou PGA de l’instance  (instance PGA).  Dans une configuration serveur partagé, une partie de la PGA est en fait stockée dans la SGA, dans la Large Pool, ou, à  défaut, dans la Shared Pool.  Dans  une  configuration  serveur  partagé,  ce  n’est  pas  forcément  le  même  processus  serveur  qui  va  traiter  deux  requêtes  successives  du  même  processus  utilisateur.  Les  informations  relatives  à  cette  session  utilisateur  doivent  donc être accessibles à l’ensemble des processus serveurs ; c’est la raison pour laquelle, dans cette configuration, une  partie  de  la  PGA  des  processus  serveurs  est  en  fait  stockée  dans  la  SGA ;  lorsqu’un  processus  serveur  traite  la  requête  d’un  processus  utilisateur,  il  "recharge"  le  contexte  du  processus  utilisateur  à  partir  de  la  SGA.  En  configuration serveur partagé, il faut donc augmenter la taille de la SGA (de préférence en prévoyant une Large Pool),  mais les besoins globaux en mémoire sont à peu près identiques (puisque les processus serveurs utilisent en propre  moins de mémoire).  Historiquement, la taille de la zone de travail SQL est contrôlée par plusieurs paramètres : SORT_AREA_SIZE (pour les  tris),  HASH_AREA_SIZE  (jointure  par  hachage),  BITMAP_ MERGE_AREA_SIZE  (fusion  de  bitmap  d’index  bitmap)  et  CREATE_BITMAP_AREA_SIZE (création d’index bitmap). Ces différents paramètres sont complexes à régler car les besoins  peuvent varier d’une session à l’autre.  Depuis  la  version  9,  un  nouveau  mécanisme  permet  de  gérer  automatiquement  et  globalement  la  PGA  agrégée  des  processus serveurs. ll suffit de définir la quantité de mémoire totale qui peut être utilisée par la PGA agrégée et laisser  Oracle répartir cette mémoire entre les différents processus en fonction des besoins. Avec ce mode de fonctionnement,  tous les paramètres présentés ci­dessus sont ignorés.  La  taille  de  la  PGA  agrégée  des  processus  serveurs  est  définie  par  le  paramètre PGA_ AGGREGATE_TARGET  (voir  la  section Création de la base de données à la main dans le chapitre Création d’une nouvelle base de données).  En version 11, la PGA peut aussi être gérée automatiquement au sein de la mémoire totale de l’instance (cf. section La  gestion de la mémoire dans ce chapitre). 

5. La gestion de la mémoire  a. Vue d’ensemble  La gestion de la mémoire évolue à chaque version afin de proposer au DBA des possibilités de réglage automatique  de plus en plus poussées : 

Version Oracle9i 

Oracle10g 

SGA

PGA

SGA dynamique 

Gestion automatique de la PGA 

Le DBA doit dimensionner  individuellement les différentes  composantes de la SGA, mais  ces composantes sont  redimensionnables à chaud. 

Le DBA alloue une quantité de  mémoire totale pour la PGA  agrégée des processus serveurs  et Oracle répartit cette mémoire  automatiquement entre les  différents processus en fonction  des besoins. 

Gestion automatique de la  mémoire partagée  Le DBA alloue une quantité de  mémoire totale pour la SGA et  Oracle répartit cette mémoire  automatiquement entre les  différentes composantes de la  SGA en fonction des besoins. 

Oracle11g 

Gestion automatique de la  mémoire  Le DBA alloue une quantité de 

- 8-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

mémoire totale pour l’instance et  Oracle répartit cette mémoire  automatiquement entre la SGA  (et ces différentes composantes)  et la PGA en fonction des  besoins. 

Pour que la gestion automatique de la mémoire ou de la mémoire partagée soit opérationnelle, il faut que le  paramètreSTATISTICS_LEVEL soit à TYPICAL (sa valeur par défaut) ou ALL.  Les principes de la gestion automatique de la PGA ont été présentés dans la section La PGA dans ce chapitre. 

b. La gestion automatique de la mémoire partagée  Lorsque la gestion automatique de la mémoire partagée est activée (Automatic Shared Memory Management ­ ASMM),  les composantes suivantes de la SGA sont dimensionnées automatiquement par Oracle, en fonction de leurs besoins  respectifs, et adaptées dynamiquement en fonction de la charge du système :  ●

Database Buffer Cache (paramètre DB_CACHE_SIZE), 

●

Shared Pool (paramètre SHARED_POOL_SIZE), 

●

Large Pool (paramètre LARGE_POOL_SIZE), 

●

Java Pool (paramètre JAVA_POOL_SIZE), 

●

Streams Pool (paramètre STREAMS_POOL_SIZE), 

●

SGA fixe (pas de paramètre). 

Les autres composantes de la SGA ne sont pas prises en charge par la gestion automatique de la mémoire partagée  et il convient de les dimensionner à la main si besoin :  ●

●

Redo Log Buffer (paramètre LOG_BUFFER),  Autres  pools  du  Database  DB_RECYCLE_CACHE_SIZE). 

Buffer 

Cache 

(paramètres 

DB_nK_CACHE_SIZE,

DB_KEEP_CACHE_SIZE, 

Pour  activer  la  gestion  automatique  de  la  mémoire  partagée,  il  suffit  de  définir  le  paramètre  SGA_TARGET.  Ce  paramètre spécifie la quantité de mémoire totale allouée à la SGA, pas uniquement la quantité de mémoire allouée  aux  composantes  prises  en  charge  par  la  gestion  automatique ;  la  mémoire  allouée  manuellement  aux  autres  composantes  est  déduite  de SGA_TARGET.  Si  besoin,  la  taille  de  la  SGA  peut  être  modifiée  à  chaud,  en  modifiant  la  valeur du paramètre SGA_TARGET, dans la limite de SGA_MAX_SIZE.  Dans  cette  configuration,  si  les  paramètres DB_CACHE_SIZE,  SHARED_POOL_SIZE,  LARGE_POOL_SIZE,  JAVA_POOL_SIZE  et  STREAMS_POOL_SIZE ne sont pas spécifiés, ils sont mis à zéro par Oracle et la taille du composant correspondant est  automatiquement  et  dynamiquement  ajustée  en  interne  par  Oracle.  Si  ces  paramètres  sont  spécifiés,  ils  imposent  une taille minimum au composant.  Si  SGA_TARGET  est  égal  à  zéro  (réglage  automatique  désactivé),  les  paramètres  DB_CACHE_SIZE,  SHARED_POOL_SIZE,  JAVA_POOL_SIZE et STREAMS_POOL_SIZE doivent être définis manuellement ; s’ils ne le sont pas, une valeur par défaut  leur est affectée.N’oubliez pas non plus que la mémoire est allouée aux composantes de la SGA en nombre entier de  granules. La taille d’un granule est de 4 Mo si SGA_MAX_SIZE est inférieur ou égal à 1 Go et de 16 Mo (8 Mo sur plate­ forme Windows) si SGA_MAX_SIZE est supérieur à 1 Go. En cas de besoin, Oracle arrondit la valeur des paramètres au  granule supérieur.  L’instance utilise généralement un granule pour le Redo Log Buffer et la SGA fixe.  Exemple 1 :  SGA_MAX_SIZE = 900M SGA_TARGET = 800M LOG_BUFFER = 524288 DB_16K_CACHE_SIZE = 64M

© ENI Editions - All rights reserved - Algeria Educ

- 9-

DB_CACHE_SIZE = 256M Sur cet exemple, la gestion automatique de la mémoire partagée est activée. Un  pool de 64 Mo est alloué dans le  Database  BufferCache  pour  les  blocs  de  16  Ko  et  un  minimum  de  256  Mo  est  demandé  pour  le  pool  standard  du  Database Buffer Cache.  La taille de la SGA est 800 Mo (SGA_TARGET).  La mémoire disponible pour le réglage automatique est égal à SGA_TARGET ­ DB_16K_CACHE_SIZE ­ un granule (SGA fixe  et  Redo  Log  Buffer)  soit  800  ­  64  ­  4  =   732.  Cette  quantité  de  mémoire  est  répartie  automatiquement  et  dynamiquement  par  Oracle  entre  les  paramètres  DB_CACHE_SIZE,  SHARED_POOL_SIZE,  LARGE_POOL_ SIZE,  JAVA_POOL_SIZE et STREAMS_POOL_SIZE, en fonction des besoins, mais avec un minimum garanti de 256 Mo pour le pool  standard du Database Buffer Cache.  La mémoire libre est de 100 Mo (SGA_MAX_SIZE ­ SGA_TARGET) ; en cas de besoin SGA_TARGET peut être augmenté pour  tirer parti de cette mémoire disponible.  Exemple 2 :  SGA_MAX_SIZE = 900M SGA_TARGET = 0 LOG_BUFFER = 524288 DB_CACHE_SIZE = 512M SHARED_POOL_SIZE = 64M Sur  cet  exemple,  la  gestion  automatique  de  la  mémoire  partagée  n’est  pas  activée.  Le  Database  Buffer  Cache  est  dimensionné à 512 Mo et la Shared Pool à 64 Mo. La Java Pool et la Large Pool sont dimensionnées par défaut.  La  taille  de  la  SGA  est  égale  à  DB_CACHE_SIZE  +  SHARED_POOL_SIZE  +  JAVA_POOL_SIZE  (défaut)  +  LARGE_POOL_SIZE  (défaut) + un granule (SGA fixe et Redo Log Buffer) = 512 + 64 + 24 + 0 + 4 = 604 Mo  La  mémoire  libre  est  de  296  Mo  (SGA_MAX_SIZE  ­  taille  de  la  SGA) ;  en  cas  de  besoin  les  différents  paramètres  pourront être augmentés pour tirer parti de cette mémoire disponible. 

c. La gestion automatique de la mémoire de l’instance  En version 10, la SGA et la PGA peuvent être gérées automatiquement par Oracle, mais c’est de la responsabilité du  DBA  de  répartir  la  mémoire  disponible  pour  Oracle  entre  les  deux  structures  (SGA_TARGET  pour  la  SGA  et  PGA_AGGREGATE_TARGET pour la PGA).  La  version  11  d’Oracle  introduit  la  gestion  automatique  de  la  mémoire  (Automatic  Memory  Management  ­  AMM)  qui  étend la fonctionnalité de gestion automatique de la mémoire partagée apparue en version 10. Cette fonctionnalité  est supportée uniquement sur les plates­formes suivantes : Linux, Solaris, Windows, HP­UX et AIX. Si vous tentez  d’activer cette fonctionnalité sur une plate­forme non supportée, vous obtiendrez le message d’erreur suivant : ORA00845: MEMORY_TARGET non pris en charge sur ce système.  Lorsque  la  gestion  automatique  de  la  mémoire  est  activée,  la  mémoire  allouée  à  l’instance  est  répartie  automatiquement  par  Oracle  entre  la  SGA  (avec  ces  différentes  composantes)  et  la  PGA.  Cette  répartition  est  adaptée dynamiquement en fonction de la charge du système et des besoins des différentes structures.  Pour activer la gestion automatique de la mémoire, il suffit de définir le paramètre MEMORY_TARGET. Ce paramètre fixe  la taille de la mémoire allouée à l’instance. En complément, il est possible de définir la taille maximum de la mémoire  utilisable par l’instance avec le paramètre <MEMORY_MAX_TARGET.  Si besoin, la taille de la mémoire allouée à l’instance peut être modifiée à chaud, en modifiant la valeur du paramètre  MEMORY_TARGET, dans la limite de MEMORY_MAX_TARGET.  La SGA est gérée selon les mêmes principes qu’avec la gestion automatique de la mémoire partagée. Ainsi, comme  avec la gestion automatique de la mémoire partagée, le Redo Log Buffer et les autres pools du Database Buffer Cache  ne sont pas pris en charge par la gestion automatique et il convient de les dimensionner à la main si besoin.  Normalement, lorsque la gestion automatique de la mémoire est utilisée, tous les autres paramètres relatifs à une  composante de mémoire gérée automatiquement doivent être mis à zéro ou supprimés.  Néanmoins, si les paramètres SGA_TARGET  et/ou PGA_AGGREGATE_TARGET sont définis, ils imposent une taille minimum  respectivement pour la SGA et la PGA. De même, comme dans la gestion automatique de la mémoire partagée, si un  des  paramètres  DB_CACHE_SIZE,  SHARED_POOL_SIZE,  LARGE_POOL_SIZE,  JAVA_POOL_SIZE  ou  STREAMS_POOL_SIZE  est  spécifié, il impose une taille minimum au composant.  À l’inverse, si le paramètre SGA_MAX_SIZE est défini, il impose une taille maximum pour la SGA.  Exemple :  MEMORY_MAX_TARGET = 900M MEMORY_TARGET = 800M

- 10 -

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

SGA_MAX_SIZE = 500M SGA_TARGET = 300M DB_CACHE_SIZE = 128M DB_16K_CACHE_SIZE = 64M PGA_AGGREGATE_TARGET = 64M Sur cet exemple, la gestion automatique de la mémoire est activée.  La mémoire allouée à l’instance est de 800 Mo (MEMORY_TARGET).  La  mémoire  disponible  pour  le  réglage  automatique  est  égale  à  MEMORY_TARGET  ­  DB_16K_CACHE_SIZE  ­  un  granule  (SGA  fixe  et Redo  Log  Buffer)  soit  800 ­  64 ­  4  =   732.  Cette  quantité  de  mémoire  est  répartie  automatiquement  et  dynamiquement  par  Oracle  entre  la  PGA  et  les  composantes  de  la  SGA  gérées  automatiquement,  en  fonction  des  besoins, mais avec un minimum garanti de 128 Mo (DB_CACHE_SIZE) pour le pool standard du Database Buffer Cache,  64  Mo  (PGA_AGGREGATE_TARGET)  pour  la  PGA,  et  une  SGA  comprise  entre  300  Mo  (SGA_TARGET)  et  500  Mo  (SGA_MAX_SIZE).  La  mémoire  libre  est  de  100  Mo  (MEMORY_MAX_SIZE  ­  MEMORY_TARGET) ;  en  cas  de  besoin  MEMORY_TARGET  peut  être  augmenté pour tirer parti de cette mémoire disponible.  Cet exemple est donné dans un but pédagogique. Dans la pratique, si la gestion automatique de la mémoire  est  utilisée,  il  est  conseillé  de  ne  spécifier  aucun  paramètre  relatif  à  une  composante  de  mémoire  gérée  automatiquement autre que MEMORY_TARGET et MEMORY_MAX_TARGET. 

d. Gestion manuelle : conseil sur la répartition SGA/PGA  Si  vous  choisissez  de  gérer  manuellement  la  répartition  de  la  mémoire  entre  la  SGA  et  la  PGA,  Oracle  donne  les  indications suivantes :  ●

●

Pour les systèmes transactionnels (OLTP)  ●

SGA : environ 80% de la mémoire disponible pour l’instance 

●

PGA : environ 20% de la mémoire disponible pour l’instance 

Pour les systèmes décisionnels (DSS)  ●

SGA : entre 50% et 30% de la mémoire disponible pour l’instance 

●

PGA : entre 50% et 70% de la mémoire disponible pour l’instance 

Cette recommandation est un point de départ. Il est nécessaire de surveiller ensuite le fonctionnement de l’instance  pour affiner ces valeurs.  En règle générale, les requêtes exécutées par les systèmes transactionnels effectuent des petits tris ; les processus  serveurs n’ont donc pas besoin d’une grosse zone de travail. Privilégier la SGA est alors opportun.  À l’inverse, les requêtes des systèmes décisionnels effectuent de gros tris ; les processus serveurs ont donc besoin  d’une grosse zone de travail. Privilégier la PGA est alors opportun.  Ces directives peuvent être utilisées pour dimensionner la SGA et la PGA sur un système dont la mémoire physique  est imposée.  Supposons par exemple que le système dispose de 1 Go de mémoire physique. Nous pouvons faire le raisonnement  suivant pour un système transactionnel :  ●

●

●

●

Réserver 20% de la mémoire pour le système d’exploitation (plus si d’autres applications s’exécutent sur le  serveur), soit 204 Mo arrondis à 224 Mo (un peu de marge).  Il reste donc environ 800 Mo disponibles pour Oracle.  Attribuer 80% de cette mémoire à la SGA et 20% à la PGA, ce qui permet de spécifier SGA_MAX_SIZE = 640M et  PGA_AGGREGATE_TARGET = 160M.  Si  nous  décidons  d’utiliser  la  fonctionnalité  de  gestion  automatique  de  la  mémoire  partagée,  et  de  laisser 

© ENI Editions - All rights reserved - Algeria Educ

- 11 -

Oracle  faire  complètement,  nous  pouvons  aussi  spécifier  SGA_TARGET = 640M  (autant  utiliser  toute  la  mémoire).  ●

Si  nous  souhaitons  nous­même  régler  la  taille  des  différentes  structures  de  la  SGA,  nous  pouvons  par  exemple spécifier SHARED_POOL_SIZE = 128M, JAVA_POOL_SIZE = 0 (pas besoin de Java Pool), LARGE_POOL_SIZE = 0 (pas besoin de Large Pool), réserver un granule pour la SGA fixe et le Redo Log Buffer et allouer toute le  reste au Database Buffer Cache, soit DB_CACHE_SIZE = 508M. 

6. Le fichier de paramètres  Au  démarrage,  l’instance  lit  un  fichier  de  paramètres  qui  contient  des  paramètres  d’initialisation.  Les  paramètres  d’initialisation permettent notamment à l’instance d’allouer la mémoire souhaitée aux différentes structures de la SGA,  et de trouver le nom et l’emplacement des fichiers de contrôle de la base de données à ouvrir. Ce fichier est géré par  le DBA.  Lors  du  démarrage  de  l’instance,  le  fichier  de  paramètres  est  lu  ;  ce  fichier  contient  notamment  un  paramètre  qui  donne  l’emplacement  des  fichiers  de  contrôle  de  la  base  de  données  à  ouvrir,  ce  qui  permet  ensuite  à  l’instance  d’ouvrir les fichiers de contrôle en question et d’y trouver le nom et l’emplacement des autres fichiers de la base de  données.  Historiquement,  Oracle  utilise  un  fichier  de  paramètres  de  type  texte  pour  le  démarrage  de  l’instance  de  base  de  données. Ce fichier doit se trouver sur la(les) machine(s) qui démarre(nt) la base de données, ce qui peut poser des  problèmes pour le démarrage à partir du réseau, et engendrer des duplications du fichier sur plusieurs machines et  des problèmes de synchronisation en cas de mise à jour.  Depuis la version 9, il est possible d’utiliser un fichier de paramètres binaire stocké sur le serveur (server parameter file  =SPFILE). Ce fichier peut être considéré comme une sorte de référentiel centralisé des paramètres d’initialisation, qui  élimine la nécessité de dupliquer le fichier de paramètres sur plusieurs machines.  Les  modifications  de  paramètres  effectuées  dynamiquement  pendant  le  fonctionnement  de  l’instance  peuvent  aussi  persister dans ce fichier de paramètres serveur.  Le  fichier  de  paramètres  serveur  est  un  fichier  binaire  qui  ne  peut  pas  être  consulté  ou  modifié  avec  un  éditeur  de  texte ; d’autres moyens seront utilisés pour cela.  Il  ne  faut  jamais  modifier  un  fichier  de  paramètres  serveur  avec  un  éditeur  de  texte,  au  risque  de  le  corrompre, voire de provoquer un arrêt de l’instance.  Nous verrons que le fichier de paramètres serveur est créé à partir d’un fichier de paramètres texte.  Dans un fichier de paramètres texte, les paramètres sont spécifiés sous la forme nom_ paramètre = valeur. Tous les  paramètres sont optionnels et ont une valeur par défaut. Des commentaires peuvent être inclus et commencent par le  caractère #. La valeur peut être spécifiée entre des guillemets doubles si elle contient des caractères spéciaux (égal,  espace, etc.). Les valeurs multiples peuvent être spécifiées entre parenthèses, séparées par des virgules.  Exemple :  db_name = hermes # nom de la base de données # fichiers de contrôle de la base control_files = ("f:\oradata\HERMES\control01.ctl", "g:\oradata\HERMES\control02.ctl")

7. Infrastructure pour la gestion automatique  Depuis la version 10, Oracle comporte beaucoup de fonctionnalités qui facilitent l’administration de la base de données  et dans certains cas, l’automatise.  Ces nouvelles fonctionnalités reposent sur une infrastructure que nous allons décrire brièvement ici ; il n’est en effet  pas nécessaire de connaître cette infrastructure dans le détail pour pouvoir tirer parti des nouvelles fonctionnalités.  De nouveaux processus d’arrière­plan sont chargés de collecter en mémoire des statistiques sur le fonctionnement du  système.  Toutes  les  60  minutes  (valeur  modifiable),  ces  statistiques  sont  déversées  dans  le  référentiel  AWR  (Automatic Workload Repository), qui se matérialise par un ensemble de tables dans le tablespace SYSAUX. Par défaut,  ces statistiques sont conservées 8 jours.  À  chaque  fois  qu’une  collecte  est  déversée  dans  le  référentiel  AWR,  ADDM  (Automatic  Database  Diagnostic  Monitor)  effectue un diagnostic des performances du système, détecte les éventuels problèmes et propose des solutions. Le  résultat  de  l’analyse  ADDM  est  stocké  dans  le  référentiel  et  peut  être  consulté  dans  Enterprise  Manager  Database  Control. 

- 12 -

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

En complément, plusieurs conseillers sont disponibles pour avoir des recommandations sur l’optimisation des requêtes  SQL, l’indexation,  la  gestion  de  la  mémoire,  etc.  Ces  conseillers  exploitent,  eux  aussi,  les  données  stockées  dans  le  référentiel AWR. 

© ENI Editions - All rights reserved - Algeria Educ

- 13 -

Data Pump  1. Présentation  a. Architecture  Data  Pump  est  un  utilitaire  serveur  qui  peut  être  utilisé  pour  déplacer  des  données  et/ou  des  métadonnées  (définitions) entre des bases Oracle.  Data Pump comporte trois éléments :  ●

un package PL/SQL DBMS_DATAPUMP ; 

●

un package PL/SQL DBMS_METADATA ; 

●

deux outils clients ligne de commande expdp (export) et impdp (import). 

Les outils clients expdp et impdp servent d’interface avec le package DBMS_DATAPUMP, qui est, en quelque sorte, l’API  (Application Programming Interface) de Data Pump. Ce package est complètement documenté, ce qui permet d’utiliser  directement  les  fonctionnalités  Data  Pump  dans  un  programme.  Data  Pump  peut  aussi  être  utilisé  à  partir  du  Database Control.  Les opérations proprement dites d’export et d’import sont effectuées par le package DBMS_DATAPUMP et donc, sur le  serveur  Oracle.  Cela  inclut  notamment  la  lecture  et/ou  l’écriture  des  fichiers : les  fichiers  générés  lors  d’un export  sont écrits sur le serveur et les fichiers chargés lors d’un import sont lus sur le serveur. L’accès aux fichiers sur le  serveur  s’effectue  grâce  à  des  objets  DIRECTORY ; un objet  DIRECTORY  est  un  alias  vers  un  répertoire  du  système  d’exploitation. Ces objets DIRECTORY doivent être créés par le DBA (cf. L’objet DIRECTORY).  Lorsqu’un travail Data Pump est créé, Oracle crée différentes structures pour gérer l’opération, parmi lesquelles :  ●

●

une table dite "maître" dans le schéma de l’utilisateur qui crée le travail (cette table porte le même nom que  le travail) ;  un processus de contrôle maître (nommé DMnn) qui contrôle l’exécution du travail. 

La table "maître" contient différentes informations sur le travail, utilisées notamment pour redémarrer le travail. La  table "maître" est supprimée lorsque le travail se termine normalement, ou lorsque le travail est supprimé avec la  commande  KILL_JOB (voir  plus  loin) ; en  cas  de  besoin,  cette  table  peut  être  directement  supprimée  à  la  main,  à  l’aide d’un ordre SQL DROP TABLE 

b. Les modes d’export ou d’import  Data Pump propose cinq niveaux (modes) pour les opérations d’export et d’import :  ●

Complet : totalité de la base de données ; 

●

Schéma : un ou plusieurs schémas ; 

●

Table : une ou plusieurs tables ; 

●

Tablespace : toutes les tables stockées dans un ou plusieurs tablespaces ; 

●

Tablespace transportable : permet le transport de tablespaces entre deux bases de données. 

Par la suite, nous verrons que pour chaque mode, il est possible de préciser très finement le contenu de l’export ou  de l’import, en filtrant les objets et/ou les données. 

c. Les privilèges nécessaires 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 1-

Aucun privilège particulier n’est requis pour exporter des objets de son schéma, ou importer dans son schéma des  objets préalablement exportés de son schéma.  Par  contre,  pour  exporter  des  objets  d’un  autre  schéma,  il  faut  avoir  le  rôle EXP_FULL_DATABASE.  De  même,  pour  importer dans un autre schéma, ou pour importer dans son schéma des objets en provenance d’un autre schéma, il  faut avoir le rôle IMP_FULL_DATABASE. Ces rôles sont attribués au DBA. 

d. L’objet DIRECTORY  Un objet DIRECTORY est un alias vers un répertoire du système d’exploitation. Cet objet est utilisé par beaucoup de  fonctionnalités du serveur Oracle qui ont besoin d’accéder à des fichiers du système d’exploitation hôte.  Syntaxe pour la création/modification  CREATE[ OR REPLACE ] DIRECTORY nom_directory AS ’chemin’ ; Syntaxe pour la suppression  DROP DIRECTORY nom_directory ; Les privilèges systèmes CREATE ANY DIRECTORY et DROP ANY DIRECTORY sont requis pour créer et supprimer un objet  DIRECTORY  Syntaxe pour l’attribution de droits sur cet objet  GRANT privilège [,…] ON DIRECTORY nom_directory TO utilisateur [,…] ; Les privilèges objets possibles sont READ pour l’accès en lecture et WRITE pour l’accès en écriture.  La vue DBA_DIRECTORIES permet de lister tous les objets DIRECTORY qui existent dans la base de données. 

2. Utilisation des outils lignes de commande  Les outils lignes de commande expdp et impdp peuvent être utilisés de trois façons :  ●

en passant les paramètres du travail à réaliser sur la ligne de commande ; 

●

en utilisant un fichier de paramètres contenant les paramètres du travail a réaliser 

●

en interactif. 

Syntaxe :  expdp connexion paramè t res impdp connexion paramè t res connexion est une chaîne de connexion habituelle (nom, mot de passe, nom de service réseau).    Il est déconseillé d’utiliser une connexion AS SYSDBA

paramètres est une liste de paramètres. Les paramètres peuvent être regroupés dans un fichier de paramètres, dont  le nom est indiqué sur la ligne de commande grâce au paramètre PARFILE Les paramètres sont présentés plus loin.  Exemples  expdp expdp expdp expdp

system/az#78@hermes DIRECTORY=dir_exp FULL=y DUMPFILE=exp.dmp system/az#78@hermes PARFILE=exp_param.txt JOB_NAME=exp_full system/az#78@hermes ATTACH=exp_job HELP=y

L’utilisation en interactif peut être activée de deux manières : 

- 2-

© ENI Editions - All rights reserved - Algeria Educ

●

●

en  tapant  les  touches  [Ctrl]  C  pendant  le  déroulement  d’une  opération  lancée  à  partir  de  la  ligne  de  commande ou à l’aide d’un fichier de paramètres ;  en attachant sa session à un travail en cours d’exécution ou arrêté (paramètre ATTACH). 

Lorsque vous entrez dans le mode interactif et qu’un travail est cours, l’affichage à l’écran de l’avancement s’arrête  (mais le travail continue en arrière­plan).  En mode interactif, vous disposez de plusieurs commandes qui permettent d’arrêter le travail, de le redémarrer, de le  supprimer, etc. :  CONTINUE_CLIENT  Redémarre l’affichage de l’avancement sur le terminal.  EXIT_CLIENT  Quitte l’outil (mais le travail continu, s’il n’a pas été arrêté).  KILL_JOB  Supprime le travail.  START_JOB  Redémarre le travail.  STOP_JOB[=IMMEDIATE]  Arrête le travail mais ne le supprime pas (il peut être relancé par la commande START_JOB). Sans option, la tâche en  cours se termine ; l’option IMMEDIATE permet d’arrêter le travail immédiatement.    Il existe d’autres commandes. Voir la documentation "Oracle® Database Utilities". La vue DBA_DATAPUMP_JOBS permet de superviser les travaux Data Pump en cours dans la base de données. 

3. Paramètres de l’export et de l’import  Data Pump propose un grand nombre de paramètres. Dans ce chapitre, nous ne présentons que les paramètres les  plus souvent utilisés pour les opérations usuelles d’export  et  d’import. Reportez­vous à la documentation "Oracle®  Database Utilities" pour avoir la liste de tous les paramètres. 

a. Paramètres communs à l’export et à l’import  ATTACH[=[schéma.]nom_travail]  Ce  paramètre  permet  d’attacher  sa  session  à  un  travail  existant.  Les  rôles  EXP_FULL_DATABASE  ou  IMP_FULL_DATABASE sont nécessaires pour s’attacher à un travail d’un autre schéma. Si aucun nom n’est spécifié, la  session s’attache au travail en cours du schéma de l’utilisateur, s’il n’y en a qu’un. Lorsque ce paramètre est utilisé,  aucun autre paramètre ne peut être spécifié.  CONTENT=ALL | DATA_ONLY | METADATA_ONLY}  Ce paramètre permet de définir le contenu de l’export ou de l’import (voir ci­après).  DIRECTORY=objet_directory  Ce paramètre permet de définir le nom de l’objet DIRECTORY, correspondant au répertoire par défaut dans lequel les  fichiers  vont  être  écrits  ou  lus  (DATA_PUMP_DIR  par  défaut).  Cet  objet  DIRECTORY  est  créé  lors  de  la  création  de  la  base de données et il peut être utilisé par le DBA. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 3-

DUMPFILE=nom_fichier  Ce paramètre permet de définir le nom du fichier utilisé pour l’export ou l’import. Lors de l’export, si le fichier existe  déjà,  une  erreur  est  retournée.  Il  existe  une  syntaxe  évoluée  qui  permet  de  spécifier  plusieurs  fichiers,  pour  paralléliser l’export sur plusieurs processus et/ou répartir l’export sur plusieurs fichiers dont la taille est limitée.  EXCLUDE=type_objet[:filtre] [, ...]  Ce paramètre permet d’exclure des objets de l’export ou de l’import (voir plus loin).  FULL={y | n  Si ce paramètre est égal à y, un export ou un import de niveau complet est réalisé.  INCLUDE=object_type[:name_clause] [, ...]  Ce paramètre permet d’inclure des objets dans l’export ou l’export (voir plus loin).  JOB_NAME=nom_travail  Ce paramètre permet de donner un nom au travail. En cas d’absence, un nom est généré par le système (du type  SYS__<mode>_).  LOGFILE=nom_fichier  Ce  paramètre  permet  de  définir  le  nom  du  fichier  journal.  Un  fichier  journal  est  toujours  généré  (export.log  ou  import.log, par défaut) sauf si le paramètre NOLOGFILE=y est spécifié.  NETWORK_LINK=nom_database_link  Ce  paramètre  permet  de  spécifier  le  nom  d’un  lien  de  base  de  données  (database link)  à  utiliser  pour  l’opération.  Dans  le  cas  d’un  export,  les  données  sont  extraites  de  la  base  de  données  distante,  et  un  fichier  d’export  est  généré sur le système local. Dans le cas d’un import, les données sont extraites de la base de données distante et  importées directement dans la base de données "locale" (celle à laquelle l’outil impdp est connecté).  NOLOGFILE={y | n  Si ce paramètre est égal à y, le fichier journal n’est pas généré.  PARFILE=chemin_fichier  Ce paramètre permet de définir l’emplacement du fichier de paramètres à utiliser pour l’opération. À la différence du  fichier d’export, du fichier d’import, ou du fichier journal, le fichier de paramètres doit être présent sur la machine qui  exécute le programme expdp ou impdp  QUERY=[schéma.][nom_table:]clause_WHERE  Ce paramètre permet de filtrer les données exportées ou importées (voir ci­après).  SCHEMAS=schéma [, ...]  Ce paramètre permet de faire un export ou un import de niveau schéma et de définir le ou les schémas à exporter  ou importer. C’est le mode d’export par défaut (sur le schéma de l’utilisateur).  TABLES=[schéma.]nom_table[:partition] [, ...]   Ce  paramètre  permet  de  faire  un  export  ou  un  import  de  niveau  table  et  de  définir  une  ou  plusieurs  tables  à  exporter ou importer.  TABLESPACES=nom_tablespace [, ...]   Ce  paramètre  permet  de  faire  un  export  ou  un  import  de  niveau  tablespace  et  de  définir  un  ou  plusieurs  tablespaces à exporter ou importer. 

- 4-

© ENI Editions - All rights reserved - Algeria Educ

TRANSPORT_FULL_CHECK={y | n  Si  ce  paramètre  est  égal  à  y,  Data  Pump  vérifie  les  dépendances  entre  les  objets  stockés  à  l’intérieur  des  tablespaces transportés.  TRANSPORT_TABLESPACES=nom_tablespace [, ...]  Ce  paramètre  permet  de  faire  un  export  ou  un  import  de  niveau  transport  de  tablespace  et  de  définir  un  ou  plusieurs tablespaces à transporter. 

b. Paramètres spécifiques à l’export  COMPRESSION={ALL | DATA_ONLY | METADATA_ONLY| NONE}  Permet d’activer la compression des métadonnées et/ou des données.  ESTIMATE_ONLY={y | n  Si ce paramètre est égal à y, l’export effectue simplement une estimation de l’espace nécessaire pour l’export, mais  sans faire l’export. 

c. Paramètres spécifiques à l’import  REMAP_DATAFILE=fichier_source:fichier_cible  Ce paramètre permet de changer les chemins des fichiers de données lors de l’import (par exemple, lorsque l’import  crée  un  tablespace).  Plusieurs  paramètres  peuvent  être  spécifiés  pour  effectuer  plusieurs  changements  (avec  un  fichier source différent à chaque fois).  REMAP_SCHEMA=schéma_source:schéma_cible  Ce  paramètre  permet  de  charger  les  objets  d’un  schéma  d’origine  dans  un  autre  schéma.  Plusieurs  paramètres  peuvent être spécifiés pour effectuer plusieurs changements (avec un schéma source différent à chaque fois). Si le  schéma cible n’existe pas, il peut être créé lors de l’import s’il y a les informations suffisantes dans le fichier importé.  REMAP_TABLESPACE=tablespace_source:tablespace_cible  Ce  paramètre  permet  de  changer  les  objets  de  tablespace  lors  de  l’import.  Plusieurs  paramètres  peuvent  être  spécifiés pour effectuer plusieurs changements (avec un tablespace source différent à chaque fois).  SQLFILE=nom_fichier  Ce  paramètre  permet  de  générer  un  fichier  SQL  contenant  tous  les  ordres  DDL  qui  seraient  exécutés,  si  l’import  était réalisé (mais l’import n’est pas réalisé). Si le fichier existe déjà, il est remplacé.  TABLE_EXISTS_ACTION={SKIP | APPEND | TRUNCATE | REPLACE}  Ce paramètre permet de spécifier ce que l’outil d’import doit faire si, une table qu’il doit créer existe déjà :  SKIP : ne fait rien et passe à l’objet suivant (non autorisé, si CONTENT=DATA_ONLY, valeur par défaut sinon).  APPEND : ajoute les données à la table (valeur par défaut, si CONTENT=DATA_ONLY).  TRUNCATE : tronque la table avant de charger les données.  REPLACE : supprime la table et la recrée, puis charge les données (interdit, si CONTENT=DATA_ONLY).  TRANSPORT_DATAFILES=fichiers  Ce paramètre permet de spécifier l’emplacement des fichiers de données des tablespaces transportés (les fichiers  doivent avoir été copiés au préalable). 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 5-

d. Contenu d’un export ou d’un import  Par  défaut,  Data  Pump  exporte  ou  importe  les  données  et  les  métadonnées  des  tables,  avec  toutes  les  dépendances (index, triggers, droits, contraintes, etc.).  Cependant, Data Pump permet de filtrer précisément ce qui doit être exporté ou importé :  ●

données et/ou métadonnées ; 

●

filtre sur les données ; 

●

filtre sur les objets.   

Ne s’applique pas au transport de tablespace.

Données et/ou métadonnées Le paramètre CONTENT permet de préciser globalement ce qui doit être exporté ou importé :  ●

ALL : les données et les métadonnées ; 

●

DATA_ONLY : les données uniquement ; 

●

METADATA_ONLY : les métadonnées uniquement. 

Filtre sur les données Lorsque les données sont exportées ou importées, il est possible de les filtrer grâce au paramètre QUERY :  QUERY = [schéma.][nom_table:]clause_WHERE Exemple  QUERY = diane.adherent:"WHERE sexe = ’F’" Le paramètre QUERY peut être spécifié plusieurs fois pour définir des filtres sur plusieurs tables.  Filtre sur les objets Les paramètres INCLUDE et EXCLUDE peuvent être utilisés pour inclure ou exclure des objets d’une opération d’import  ou d’export :  INCLUDE = type_objet[:"filtre"] EXCLUDE = type_objet[:"filtre"] type_objet est le type d’objet à inclure ou à exclure  Exemple  EXCLUDE=trigger INCLUDE=view:"LIKE ’ADH%’" Plusieurs  filtres  peuvent  être  spécifiés  lors  d’une  opération,  un  type  d’objet  pouvant  même  apparaître  dans  plusieurs filtres. Bien noter que dans ce cas, les différents filtres sont combinés par un « et » logique : pour qu’un  objet soit exporté, il doit passer tous les filtres définis sur l’opération.  Par  contre,  les  paramètres  EXCLUDE  et  INCLUDE  sont  mutuellement  exclusifs : soit  vous  travaillez  par  inclusion  (et  tout  ce  qui  n’est  pas  explicitement  inclus  est  exclus),  soit  vous  travaillez  par  exclusion  (et  tout  ce  qui  n’est  pas  explicitement exclus est inclus). Spécifier simultanément les paramètres EXCLUDE et INCLUDE génère une erreur.  À  moins  d’être  explicitement  exclues  (par  un  EXCLUDE),  les  dépendances  d’une  table  (contraintes,  triggers,  index)  sont  toujours  exportées,  même  si  elles  ne  sont  pas  implicitement  incluses  (par  un  INCLUDE).  Si  vous  avez  mis  INCLUDE=table et que vous souhaitez exclure une dépendance, il faut l’inclure avec un filtre qui n’est jamais vrai, par  exemple INCLUDE=trigger:"IS NULL" (il n’y a pas de trigger dont le nom est NULL).  - 6-

© ENI Editions - All rights reserved - Algeria Educ

Les vues DATABASE_EXPORT_OBJECTS, SCHEMA_EXPORT_OBJECTS et TABLE_ EXPORT_OBJECTS donnent la liste de tous les  types d’objets  qui  peuvent  être  spécifiés  dans  les  paramètres EXCLUDE et  INCLUDE, selon le niveau de l’opération.  Exemples :  CONSTRAINT 

PACKAGE_SPEC 

SYNONYM 

DIRECTORY 

PROCEDURE 

SYSTEM_GRANT 

FUNCTION 

REF_CONSTRAINT 

TABLE 

GRANT 

ROLE 

TABLESPACE 

INDEX 

ROLE_GRANT 

TRIGGER 

OBJECT_GRANT 

SCHEMA 

USER 

PACKAGE 

SEQUENCE 

VIEW 

PACKAGE_BODY 

STATISTICS 

4. Exemples  a. Préambule  Pour  les  différents  exemples,  nous  supposons  qu’il  existe  un  objet  DIRECTORY  nommé  DIR_PUMP,  créé  avec  l’ordre  SQL suivant :  CREATE OR REPLACE DIRECTORY dir_pump AS ’h:\oradata\pump’; Dans  tous  les  exemples,  un  fichier  de  paramètres  nommé  pump_param.txt  est  utilisé,  et  les  outils  expdp et  impdp sont appelés de la manière suivante :  expdp system/az#78 PARFILE=pump_param.txt impdp system/az#78 PARFILE=pump_param.txt La connexion s’effectue implicitement à l’instance définie par la variable d’environnement ORACLE_SID, ou LOCAL, ou  TWO_TASK 

b. Export complet  Dans cet exemple, nous allons faire un export complet.  Dans  un  premier  temps,  nous  allons  faire  une  simple  estimation  de  l’espace  à  l’aide  du  fichier  de  paramètres  suivant :  FULL=y ESTIMATE_ONLY=y NOLOGFILE=y Résultat  Export: Release 11.1.0.6.0 - Production on Dimanche, 10 Août, 2008 15:50:12 ... Estimation en cours à l’aide de la méthode BLOCKS ... Traitement du type d’objet DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA ... . estimation de "DIANE"."ADHERENT" 64 KB . estimation de "DIANE"."CATEGORIE" 64 KB ... Estimation totale à l’aide le la méthode BLOCKS : 44,39 MB Tâche "SYSTEM"."SYS_EXPORT_FULL_01" exécutée avec succès à 15:52:07 Nous pouvons ensuite procéder à l’export à l’aide du fichier de paramètres suivants :  JOB_NAME=exp_full

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 7-

FULL=y DIRECTORY=dir_pump DUMPFILE=exp-full.dmp LOGFILE=exp-full.log Extraits du fichier journal  Export: Release 11.1.0.6.0 - Production on Dimanche, 10 Août, 2008 15:59:10 ... Démarrage de "SYSTEM"."EXP_FULL" : system/******** parfile=pump_param.txt Estimation en cours à l’aide de la méthode BLOCKS ... Traitement du type d’objet DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA Estimation totale à l’aide le la méthode BLOCKS : 44,39 MB Traitement du type d’objet DATABASE_EXPORT/TABLESPACE … . . export : "SYSMAN"."MGMT_METRICS_RAW" 2.564 MB 45088 lignes . . export : "SYSMAN"."MGMT_MESSAGES" 3.406 MB 19070 lignes ... ************************************************************************* L’ensemble de fichiers de vidage de SYSTEM.EXP_FULL est : h:\oradata\pump\exp-full.dmp Tâche "SYSTEM"."EXP_FULL" exécutée avec succès à 16:06:20

c. Export sélectif  Dans cet exemple, un export sélectif du schéma DIANE est réalisé à l’aide du fichier de paramètres suivant :  JOB_NAME=exp_diane SCHEMAS=diane INCLUDE=table:"< > ’CATEGORIE’" INCLUDE=view INCLUDE=procedure INCLUDE=trigger:"IS NULL" QUERY=diane.adherent:"WHERE sexe = ’F’" DIRECTORY=dir_pump DUMPFILE=exp-diane.dmp LOGFILE=exp-diane.log Seules  les  tables  (sauf  la  table  CATEGORIE),  les  vues  et  les  procédures  sont  explicitement  exportées.  Comme  les  tables sont exportées, par défaut, les contraintes, les index et les triggers le sont aussi ; pour ne pas exporter les  triggers, le paramètre INCLUDE=trigger:"IS NULL" est utilisé (inclusion avec une condition fausse). Les données de  la table ADHERENT sont filtrées.  Résultat  Export: Release 11.1.0.6.0 - Production on Dimanche, 10 Août, 2008 16:19:01 ... Démarrage de "SYSTEM"."EXP_DIANE" : system/******** parfile=pump_param.txt Estimation en cours à l’aide de la méthode BLOCKS ... Traitement du type d’objet SCHEMA_EXPORT/TABLE/TABLE_DATA Estimation totale à l’aide le la methode BLOCKS : 64 KB Traitement du type d’objet SCHEMA_EXPORT/TABLE/TABLE Traitement du type d’objet SCHEMA_EXPORT/TABLE/INDEX/INDEX Traitement du type d’objet SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT Traitement du type d’objet SCHEMA_EXPORT/PROCEDURE/PROCEDURE Traitement du type d’objet SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE Traitement du type d’objet SCHEMA_EXPORT/VIEW/VIEW Traitement du type d’objet SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT. . export : "DIANE"."ADHERENT" 7.976 KB 10 lignes ORA-39168: Le chemin d’objet TRIGGER est introuvable. Table maître "SYSTEM"."EXP_DIANE" chargée/déchargée avec succès *************************************************************************** Le fichier de vidage défini pour SYSTEM.EXP_DIANE est : h:\oradata\pump\exp-diane.dmp Tâche "SYSTEM"."EXP_DIANE" exécutée avec 1 erreur(s) à 16:19:19 Sur  le  résultat,  nous  voyons  que  les  contraintes  et  les  index  ont  été  exportés ; l’erreur  signale  que  rien  n’a  été  trouvé pour les triggers.  - 8-

© ENI Editions - All rights reserved - Algeria Educ

d. Import sélectif  À  partir  de  l’export  réalisé  dans  l’exemple  précédent,  nous  allons  faire  un  import  sélectif,  en  effectuant  quelques  transformations :  ●

Les contraintes d’intégrités référentielles ne seront pas importées ; 

●

Les objets vont être chargés dans le schéma MERCURE ; 

●

Tout ce qui était stocké dans le tablespace DATA va aller dans le table DEFTBS ; 

●

Les données de la table ADHERENT sont de nouveau filtrées. 

Le fichier de paramètre est le suivant :  JOB_NAME=imp_diane SCHEMAS=diane REMAP_SCHEMA=diane:mercure REMAP_TABLESPACE=data:deftbs EXCLUDE=ref_constraint QUERY=mercure.adherent:"WHERE EXTRACT(YEAR FROM date_naissance) >= 1970" DIRECTORY=dir_pump DUMPFILE=exp-diane.dmp LOGFILE=imp-diane.log Notez que le filtre QUERY porte sur la table dans le schéma cible.  Résultat  Import: Release 11.1.0.6.0 - Production on Dimanche, 10 Août, 2008 16:27:07 ... Table maître "SYSTEM"."IMP_DIANE" chargée/déchargée avec succès Démarrage de "SYSTEM"."IMP_DIANE" : system/******** parfile=param.txt Traitement du type d’objet SCHEMA_EXPORT/TABLE/TABLE Traitement du type d’objet SCHEMA_EXPORT/TABLE/TABLE_DATA ... import de "MERCURE"."ADHERENT" 7.976 KB 4 sur 10 lignes Traitement du type d’objet SCHEMA_EXPORT/TABLE/INDEX/INDEX Traitement du type d’objet SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT Traitement du type d’objet SCHEMA_EXPORT/PROCEDURE/PROCEDURE Traitement du type d’objet SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE Traitement du type d’objet SCHEMA_EXPORT/VIEW/VIEW Tâche "SYSTEM"."IMP_DIANE" exécutée avec succès à 16:27:17 Nous voyons que les données ont bien été de nouveau filtrées. 

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

- 9-

SQL*Loader  1. Vue d’ensemble  a. Présentation  SQL*Loader est un outil très puissant qui permet de charger des données :  ●

à partir d’un ou plusieurs fichiers externes ; 

●

avec des enregistrements de longueur fixe ou de longueur variable (avec délimiteurs) ; 

●

dans une ou plusieurs tables ; 

●

en appliquant des traitements, des contrôles ou des filtres sur les données. 

b. Fonctionnement général 

  En entrée, SQL*Loader prend un fichier de contrôle (rien à voir avec le fichier de contrôle d’une base de données)  qui pilote le chargement, et un ou plusieurs fichiers de données ASCII (pas des fichiers de données d’une base de  données Oracle).  En sortie, SQL*Loader alimente la base de données Oracle et génère un fichier journal (log), un fichier des rejets  (bad ­ données erronées) et un fichier des refus (discard ­ données écartées).  Pour des petits volumes, les données peuvent être directement incluses dans le fichier de contrôle.  Le fichier discard contient des enregistrements qui ont été refusés (écartés) par SQL*Loader car ils ne respectaient  pas des conditions spécifiées dans le fichier de contrôle.  Le fichier bad contient des enregistrements qui ont été rejetés soit par SQL*Loader (format de l’enregistrement non  valide par rapport à la description du fichier de contrôle), soit par Oracle (violation d’une contrainte d’intégrité, type  de données non valide, etc.). 

© ENI Editions - All rights reserved - Algeria Educ

- 1-

Les enregistrements rejetés ou refusés sont écrits tels quels dans les fichiers bad et discard qui ont donc, la même  structure  que  les  fichiers  de  données  utilisés  en  entrée ; après  correction  éventuelle  des  enregistrements,  les  fichiers bad et discard peuvent être utilisés comme fichiers d’entrée.  Le fichier journal donne énormément d’informations sur le résultat du chargement :  ●

date ; 

●

nom des fichiers utilisés ; 

●

paramètres utilisés ; 

●

tables cibles et mode d’alimentation ; 

●

conditions éventuelles sur les enregistrements ; 

●

nombre d’enregistrements chargés ; 

●

nombre d’enregistrements écartés ; 

●

nombre d’enregistrements rejetés ; 

●

messages d’erreurs relatifs aux rejets. 

c. Les chemins du chargement  SQL*Loader peut effectuer le chargement selon deux "chemins" :  ●

●

Chemin conventionnel : les données sont chargées en mémoire et insérées dans les tables par des ordres  SQL INSERT classiques ;  Chemin  direct : les  données  sont  chargées  en  mémoire,  formatées  dans  des  blocs  qui  sont  écrits  directement dans la base de données. 

Avec le chemin conventionnel, tous les mécanismes classiques sont appliqués (contraintes, triggers, …).  Le chemin direct est plus performant mais a les conséquences suivantes :  ●

Seules les contraintes NOT NULL, PRIMARY KEY et UNIQUE sont appliquées ; 

●

Les triggers INSERT ne sont pas exécutés ; 

●

D’autres utilisateurs ne peuvent pas apporter de modifications aux tables pendant le chargement. 

Sur  un  chargement  important,  si  les  caractéristiques  évoquées  ci­dessus  sont  acceptables,  il  faut  choisir  un  chargement par chemin direct.  Lors d’un chargement en chemin direct, il existe d’autres options qui permettent de faire le chargement en  mode NOLOGGING Dans ce cas, les performances sont encore améliorées. 

2. Mise en œuvre  SQL*Loader  s’utilise  uniquement  en  mode  ligne  de  commande  (pas  de  mode  interactif).  Vous  pouvez  mettre  les  paramètres sur la ligne de commande, ou les regrouper dans un fichier de paramètres dont le nom seul est passé sur  la ligne de commande :  > sqlldr USERID=system/az#78 CONTROL=balance.ctl LOG=balance.log

- 2-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

> sqlldr PARFILE=balance.par Il y deux catégories de paramètres à ne pas confondre :  ●

●

les paramètres du fichier de contrôle ;  les paramètres de la ligne de commande qui peuvent être listés dans un fichier de paramètres (paramètre de  ligne de commande PARFILE). 

Certains paramètres de la ligne de commande peuvent être inclus dans le fichier de contrôle (paramètre de  fichier de contrôle OPTIONS) ou sont redondants avec des paramètres du fichier de contrôle.  Comme  pour  les  outils  d’export  et  d’import,  le  plus  simple  est  d’utiliser  un  fichier  de  paramètres  dont  le  nom  est  spécifié sur la ligne de commande.  Les  paramètres  du  fichier  de  contrôle  sont  essentiellement  destinés  à  décrire  la  structure  des  enregistrements  en  entrée, les tables cibles et la nature des contrôles/traitements à réaliser sur les enregistrements.  Les paramètres de la ligne de commande, ou du fichier de paramètres indiqué sur la ligne de commande, contrôlent le  fonctionnement général de l’outil.  Les principaux paramètres de la ligne de commande sont les suivants :  BAD  Nom du fichier bad (avec éventuellement un chemin complet).Par défaut, égal au nom du fichier de contrôle, mais avec  l’extension .bad  CONTROL  Nom du fichier de contrôle (avec éventuellement un chemin complet).  DATA  Nom du fichier de données à traiter (généralement plutôt indiqué dans le fichier de contrôle). Par défaut, égal au nom  du fichier de contrôle, mais avec l’extension .dat  DIRECT  TRUE : chemin direct. FALSE : chemin conventionnel (défaut).  DISCARDFILE  Nom du fichier discard (avec éventuellement un chemin complet). Par défaut, égal au nom du fichier de contrôle, mais  avec l’extension .dsc  DISCARDMAX  Nombre maximum de rejets autorisés avant l’arrêt du chargement (1 = arrêt au premier). Par défaut, pas d’arrêt.  ERRORS  Nombre d’erreurs d’insertion autorisées avant l’arrêt du chargement (50, par défaut ; 0 = aucune erreur autorisée ;  mettre un très grand nombre pour ne pas s’arrêter en cas d’erreur). Les enregistrements incriminés sont écrits dans  le fichier bad.  LOAD  Nombre maximum d’enregistrements à charger (après SKIP).  LOG  Nom du fichier journal (avec éventuellement un chemin complet). Par défaut, égal au nom du fichier de contrôle, mais  avec l’extension .log 

© ENI Editions - All rights reserved - Algeria Educ

- 3-

PARFILE  Nom du fichier de paramètres (avec éventuellement, un chemin complet).  SKIP  Nombre d’enregistrements à éliminer avant de commencer le chargement (aucun, par défaut).  USERID  Paramètres d’ouverture de la session sous la forme : utilisateur[/mot_de_passe][@nom_service]   Une invite s’affiche pour saisir le mot de passe s’il est non spécifié. 

Dans  le  fichier  de  contrôle,  certaines  directives  (voir  ci­dessous)  permettent  de  spécifier  des  paramètres  redondants avec les paramètres de la ligne de commande. En cas de conflit, c’est le paramètre de la ligne de  commande qui l’emporte.  Exemples de fichiers de paramètres  ●

Cas où toutes les informations sont dans le fichier de contrôle : 

userid=system/az#78 control=balance.ctl ●

Cas où le fichier de contrôle peut s’appliquer sur des fichiers de données de diverses origines (d’où un seul  fichier de contrôle et plusieurs fichiers de paramètres) : 

userid=system/az#78 control=balance.ctl data=balance_lyon.dat log=balance_lyon.log bad=balance_lyon.bad discardfile=balance_lyon.dsc Un fichier de contrôle type a la structure suivante :  [ OPTIONS(liste d’options) ] LOAD DATA [ INFILE fichier | * [ BADFILE fichier ] [ DISCARDFILE fichier ] [ DISCARDMAX valeur ] ] [ INSERT | APPEND | REPLACE | TRUNCATE ] INTO TABLE nom [ INSERT | APPEND | REPLACE | TRUNCATE ] [ WHEN condition ] [ FIELDS TERMINATED BY ’x’ [ OPTIONALLY ENCLOSED BY ’y’ ] ] [ TRAILING NULLCOLS ] ( colonne [ POSITION(x:y) ] [ type ] [ clause_SQL ], … ) [ BEGINDATA données ] La syntaxe n’est pas complète, mais les clauses les plus usuelles sont présentées.  Les clauses doivent apparaître dans l’ordre indiqué.  Les lignes de commentaire doivent commencer par deux signes moins (­­).  OPTIONS  La clause OPTIONS permet de spécifier, dans le fichier de contrôle, les options de ligne commande suivantes :  ●

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 point­virgule, etc.).  OPTIONALLY ENCLOSED BY ’y’ : caractère  optionnel  pouvant  entourer  les  enregistrements  (typiquement,  des  apostrophes, des guillemets, etc.).  TRAILING NULLCOLS  Les  colonnes  non  présentes  à  la  fin  de  l’enregistrement  sont  mises  à  NULL  (si  l’option  est  absente  et  que  des  colonnes vides existent à la fin, l’enregistrement est rejeté).  colonne [ POSITION(x:y) ] [ type ] [ clause_SQL ]  Liste des colonnes à alimenter dans la table :  colonne : le nom de la colonne cible.  POSITION(x:y) ; position  du  champ  correspondant  dans  l’enregistrement  source  (cas  d’un  enregistrement  de  longueur  fixe).  Pour  des  enregistrements  avec  séparateur,  la  correspondance  colonne/enregistrement  est  positionnelle (1ère colonne de la liste = 1er enregistrement, …)  type : type de données (en cas d’ambiguïté).  clause_SQL : clause  SQL  à  appliquer.  Pour  référencer  une  colonne  X  dans  la  clause  SQL,  utiliser  la  syntaxe  :X  (caractère deux­points devant le nom de la colonne).Il existe d’autres options sur la spécification des colonnes.  BEGINDATA  La clause BEGINDATA marque le début des données si celles­ci sont incluses dans le fichier de contrôle (INFILE *). 

3. Exemples  a. Préambule  Les différents exemples sont présentés avec des données incluses (INFILE * + BEGINDATA) pour mieux visualiser la  correspondance entre les données et les paramètres du fichier de contrôle.  Ces exemples sont très simples à adapter au chargement d’un fichier externe :  ●

copier les données, sans le BEGINDATA, dans un fichier ; 

●

mettre le nom du fichier dans la clause INFILE (à la place du caractère *) ; 

●

supprimer la clause BEGINDATA 

Sur chaque exemple, un chargement par ajout à la table existante est utilisé (APPEND).  Par ailleurs, nous supposons l’existence des tables suivantes :  ●

tables des adhérents 

SQL> DESC adherent Name Null? Type ----------------------------------------- -------- -------------NUMERO NUMBER(6) - 6-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

NOM PRENOM SEXE DATE_NAISSANCE ●

VARCHAR2(40) VARCHAR2(40) CHAR(1) DATE

tables des adhérents masculins (pas de colonne SEXE) 

SQL> DESC adherent_m Name Null? ----------------------------------------- -------NUMERO NOM PRENOM DATE_NAISSANCE ●

Type -------------NUMBER(6) VARCHAR2(40) VARCHAR2(40) DATE

tables des adhérentes féminines (pas de colonne SEXE, ni de colonne DATE_NAISSANCE) 

SQL> DESC adherent_f Name Null? ----------------------------------------- -------NUMERO NOM PRENOM

Type -------------NUMBER(6) VARCHAR2(40) VARCHAR2(40)

Enfin, une séquence S_ADHERENT permet d’alimenter les numéros d’adhérent. 

b. Longueur variable  LOAD DATA INFILE * INTO TABLE adherent APPEND FIELDS TERMINATED BY ’,’ OPTIONALLY ENCLOSED BY ’"’ TRAILING NULLCOLS ( prenom, nom, sexe, date_naissance "TO_DATE(:date_naissance,’YYYYMMDD’)", numero "s_adherent.NEXTVAL" ) BEGINDATA Olivier,HEURTEL,M,19660826 Valérie,MARTIN,F Jean,"PEYRAC (de)",M,19631204 Pour cet exemple, les enregistrements ont une longueur variable, avec séparateur.  Spécifications des données en entrée :  ●

●

●

●

●

Les champs sont délimités par une virgule : clause TERMINATED BY ’,’ ;  Ils  peuvent  éventuellement  entre  être  entourés  de  guillemets  (c’est  le  cas  du  nom  dans  la  troisième  ligne) : clause OPTIONALLY ENCLOSED BY ’"’;  Ils peuvent être manquants en fin de ligne (pas de date de naissance sur la deuxième ligne) ; dans ce cas  mettre un NULL : clause TRAILING NULLCOLS ;  La date de naissance est fournie sous forme de chaîne au format YYYYMMDD mais doit être stockée dans une  colonne de type DATE :  clause SQL "TO_DATE(:date_ naissance,’YYYYMMDD’)" ;  Le  numéro  d’adhérent  n’est  pas  fourni ; il  doit  être  calculé  à  l’aide  d’une  séquence :  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_OPER|DBA spécifiques à certaines instances (<SID> désignant le nom de l’instance).  Sur plate­forme Windows, pour que ce mode d’authentification soit autorisé, il faut qu’il y ait la ligne suivante dans  le  fichier  sqlnet.ora(répertoire  %ORACLE_HOME%\network\ admin ­ voir  le  Chapitre  Oracle  Net  pour  la  configuration  Oracle Net) :  SQLNET.AUTHENTICATION_SERVICES= (NTS) Les outils d’administration seront présentés plus en détail dans le chapitre Les outils d’administration. 

b. Par un fichier de mot de passe  Pour  utiliser  l’authentification  par  un  fichier  de  mot  de  passe,  vous  devez  mettre  le  paramètre  d’initialisation  REMOTE_LOGIN_PASSWORDFILE  à  EXCLUSIVE  (défaut)  ou  SHARED  et  créer  un  fichier  de  mot  de  passe  à  l’aide  de  l’utilitaireorapwd fourni par Oracle.  Exemple :  C:\ > orapwd file=D:\Oracle\Product\10.1.0\Db_1\database\pwdHERMES.ora password=dur_a_trouver entries=4 Ensuite,  vous  pouvez  vous  connecter  au  système  d’exploitation  avec  n’importe  quel  utilisateur,  lancer  l’outil  d’administration et vous connecter, en tant que SYS, à l’aide du mot de passe défini précédemment, avec le privilège  SYSDBA (ou SYSOPER).  Syntaxe (dans SQL*Plus)  CONNECT sys/mot_de_passe AS { SYSDBA | SYSOPER } Exemple :  CONNECT sys/dur_a_trouver AS SYSDBA Avec un fichier de mot de passe, par défaut, seul le compte SYS a le droit de se connecter avec le privilège SYSDBA ou  SYSOPER.  Si  le  paramètre  REMOTE_LOGIN_PASSWORDFILE  est  égal  à  EXCLUSIVE,  il  est  possible  de  donner  le  privilège  SYSDBA ou SYSOPER à d’autres utilisateurs (voir le chapitre Gestion des utilisateurs et de leurs droits). Si le paramètre  REMOTE_LOGIN_PASSWORD FILE est égal à SHARED, seul le compte SYS peut utiliser les privilèges SYSDBA ou SYSOPER.    Ce mécanisme est présenté plus en détail dans le chapitre Création d’une nouvelle base de données.

c. Remarques  Le privilège SYSDBA permet toutes les opérations "lourdes" d’administration, notamment, la création d’une base de  données, les arrêts et les démarrages, la création d’un fichier de paramètre serveur, les récupérations, etc. Il donne  un accès à toutes les données de la base de données. La connexion s’effectue implicitement dans le schéma de SYS.  Le privilège SYSOPER donne à peu près les mêmes droits que SYSDBA, à l’exception notable de la création de la base  de  données.  Par  contre,  l’accès  est  restreint  aux  seules  données  du  dictionnaire  de  données.  La  connexion  s’effectue implicitement dans le schéma PUBLIC.  Avec une authentification par le système d’exploitation, il est possible de se connecter en tapant une commande du  type CONNECT nimportequoi/nimportequoi AS SYSDBA, car le nom et le mot de passe ne sont en fait pas utilisés.  Ce  fonctionnement  est  un  peu  troublant,  notamment  si  un  vrai  compte  Oracle  est  utilisé,  d’autant  plus  que  la  session est ouverte dans le schéma SYS :  Exemple :  SQL> CONNECT nimportequoi/nimportequoi AS SYSDBA Connecté. - 2-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

SQL> SHOW USER USER est "SYS" SQL> CONNECT scott/tiger AS SYSDBA Connecté. SQL> SHOW USER USER est "SYS" SQL> CONNECT nimportequoi/nimportequoi ERREUR : ORA-01017: nom d’utilisateur/mot de passe non valide; connexion refusée Attention : vous n’êtes plus connecté à ORACLE. SQL> CONNECT scott/tiger Connecté. SQL> SHOW USER USER est "SCOTT" Depuis la version 9, la connexion sous le compte SYS sans le privilège SYSDBA n’est plus possible.  Dans  le  cas  de  l’utilisation d’un  fichier  de  mot  de  passe,  si  vous  modifiez  le  mot  de  passe  de  SYS  par  un  ordre SQL (voir le Chapitre Gestion des utilisateurs et de leurs droits), la modification est répercutée dans  le fichier de mot de passe.  L’administration  courante  ne  nécessite  pas  le  privilège  SYSDBA  ou  SYSOPER  ;  elle  s’effectue  généralement  avec  le  compte SYSTEM :  ●

gestion des structures de stockage ; 

●

gestion des utilisateurs ; 

●

gestion des schémas. 

Le privilège SYSDBA est, par contre, nécessaire pour :  ●

l’arrêt et le démarrage de la base de données ; 

●

la création d’une base de données ; 

●

les opérations de récupération d’une base de données. 

Dans  les  anciennes  versions  d’Oracle,  il  était  possible  d’utiliser  un  CONNECT INTERNAL  pour  obtenir  ces  privilèges  particuliers.  Cette  connexion  n’est  plus  supportée  depuis  la  version 9.  À  la  place,  il  faut  utiliser  une  connexion  AS SYSDBA (équivalente en terme de droits).  L’authentification SYSDBA ou SYSOPER par le système d’exploitation n’est pas autorisée pour les connexions à travers  le réseau (sauf utilisation d’un réseau sécurisé) ; dans ce cas, il faut utiliser une authentification par un fichier de  mot de passe.  Pour  l’administration  locale  de  la  base  de  données  (directement  sur  la  console  du  serveur  ou  en  émulation  de  terminal),  vous  pouvez  indifféremment  utiliser  une  authentification  par  le  système  d’exploitation  ou  par  fichier  de  mot  de  passe.  Dans  le  premier  cas,  vous  devez  vous  assurer  que  les  groupes  et  comptes  correspondants  du  système d’exploitation sont bien protégés. Dans le deuxième cas, vous devez vous assurer que le fichier de mot de  passe et l’utilitaire orapwd sont bien protégés. 

4. Autres comptes Oracle  Lors  de  la  création  d’une  base  de  données,  d’autres  comptes  Oracle  peuvent  être  créés,  notamment  SYSMAN  et  DBSNMP.  SYSMAN (mot de passe par défaut CHANGE_ON_INSTALL) est un compte qui peut être utilisé pour effectuer des tâches  d’administration dans Oracle Enterprise Manager. SYSMAN est un compte DBA.  DBSNMP (mot de passe par défaut DBSNMP) est un compte utilisé par l’agent d’Oracle Enterprise Manager pour superviser  et gérer une base de données.  De  nombreux  autres  comptes  "administratifs"  peuvent  être  créés  selon  les  options  installées  dans  la  base  de 

© ENI Editions - All rights reserved - Algeria Educ

- 3-

données. 

- 4-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

Le dictionnaire de données  1. Présentation  Le dictionnaire de données est un ensemble de tables et de vues qui donnent des informations sur le contenu d’une  base de données :  ●

les structures de stockage ; 

●

les utilisateurs et les droits ; 

●

les objets (tables, vues, index, procédures, fonctions, etc.). 

●

etc. 

Le dictionnaire de données appartient à SYS et est stocké dans le tablespace SYSTEM. Il est créé lors de la création de  la base de données et mis à jour automatiquement par Oracle lorsque des ordres SQL DDL (Data Definition Language)  sont exécutés (CREATE, ALTER, DROP).  Pour  l’utiliser,  il  suffit  de  l’interroger  grâce  à  des  requêtes  SELECT.  Sauf  exception,  toutes  les  informations  sont  stockées en majuscules dans le dictionnaire de données ; tenez en compte dans l’écriture de vos clauses WHERE !  Le dictionnaire de données est chargé en mémoire dans la partie Dictionary Cache de la Shared Pool et est utilisé en  interne par Oracle pour traiter les requêtes.  Le dictionnaire de données est créé lors de la création de la base. D’un point de vue pratique, les tables proprement  dites du dictionnaire de données ne sont pas documentées par Oracle et donc difficiles à utiliser. Par contre, grâce à  des  scripts  fournis  par  Oracle,  il  est  possible  de  créer  des  vues  (et  des  synonymes  publics)  qui,  elles,  sont  documentées  et  permettent  effectivement  d’exploiter  le  dictionnaire  de  données  ;  cette  étape  de  la  création  d’une  base sera présentée dans le chapitre Création d’une nouvelle base de données.  Il y a deux grands groupes de tables/vues dans le dictionnaire de données :  ●

les tables et vues statiques ; 

●

les tables et vues dynamiques de performance. 

Les  tables  et  vues  statiques  sont  basées  sur  de  vraies  tables  stockées  dans  le  tablespace  SYSTEM.  Elles  sont  accessibles uniquement quand la base de données est ouverte "complètement". Les tables et vues dynamiques de  performance ne sont en fait pas basées sur de vraies tables mais sur des informations en mémoire ou extraites du  fichier  de  contrôle.  Elles  s’interrogent  néanmoins  comme  de  vraies  tables/vues  et  donnent  des  informations  sur  le  fonctionnement  de  la  base  de  données,  notamment  sur  les  performances.  Pour  la  plupart,  elles  sont  accessibles  même lorsque la base de données n’est pas complètement ouverte.  La  notion  de  "niveau  d’ouverture"  d’une  base  de  données  sera  présentée  dans  le  chapitre  Démarrage  et  arrêt. 

2. Les vues statiques  Il y a trois grandes catégories de vues statiques caractérisées par leur préfixe :  ●

●

●

USER_% : informations sur les objets qui appartiennent à l’utilisateur ;  ALL_% : informations sur les objets auxquels l’utilisateur a accès (les siens et ceux sur lesquels il a reçu des  droits) ;  DBA_% :informations sur tous les objets de la base de données. 

Derrière le préfixe, le reste du nom de la vue est représentatif de l’information accessible. 

© ENI Editions - All rights reserved - Algeria Educ

- 1-

Ces trois catégories de vues permettent de filtrer les informations du dictionnaire de données par rapport aux droits  des  utilisateurs.  Les  informations  accessibles  dans  les  vues  USER_  forment  un  sous­ensemble  des  informations  accessibles  dans  les  vues  ALL_  qui  elles­mêmes  forment  un  sous­ensemble  des  informations  accessibles  dans  les  vues DBA_.  Un utilisateur "lambda" a le droit d’interroger les vues USER_ et ALL_ et il n’y voit que les informations auxquelles il a  droit.  Certaines vues de la catégorie DBA_ peuvent ne pas avoir d’équivalent dans les catégories USER_ ou ALL_. Exemple :  DBA_DATA_FILES.  Dans les vues ALL_ et DBA_ concernant les objets des schémas, la colonne OWNER permet de connaître le propriétaire  de l’objet.  Les vues suivantes sont particulièrement utiles pour la description d’un schéma :  %_OBJECTS  %_CONSTRAINTS  %_TABLES  %_CONS_COLUMNS  %_TAB_COLUMNS  %_VIEWS  %_INDEXES  %_SYNONYMS  %_IND_COLUMNS  %_SEQUENCES  %_TRIGGERS  %_SOURCE  Dans  les  différents  chapitres,  les  principales  vues  du  dictionnaire  de  données  relatives  au  sujet  traité  seront  présentées.  Oracle propose des synonymes sur certaines vues : 

Synonyme

Vue correspondante

COLS 

USER_TAB_COLUMNS 

DICT 

DICTIONARY 

IND 

USER_INDEXES 

OBJ 

USER_OBJECTS 

SEQ 

USER_SEQUENCES 

SYN 

USER_SYNONYMS 

TABS 

USER_TABLES 

Par ailleurs, les vues DICTIONARY et DICT_COLUMNS donnent la description de toutes les tables et vues du dictionnaire  de données.  La vue DICTIONARY est très pratique pour retrouver le nom des vues qui traitent d’un sujet donné. En effet, le nom de  la vue contient une chaîne de caractères représentative de l’information présentée par la vue (TAB ou TABLE pour les  tables,  IND ou  INDEX  pour  les  index,  COL ou  COLUMN  pour  les  colonnes,  etc.) ;  il  suffit  donc  de  faire  une  recherche  à  l’aide de l’opérateur LIKE.  Exemple  SQL> SELECT * FROM dictionary WHERE table_name LIKE ’USER%SEQ%’;

- 2-

openmirrors.com

© ENI Editions - All rights reserved - Algeria Educ

TABLE_NAME COMMENTS --------------- -------------------------------------------------USER_SEQUENCES Description of the user’s own SEQUENCEs SQL> SELECT column_name,comments FROM dict_columns 2 WHERE table_name = ’USER_SEQUENCES’; COLUMN_NAME COMMENTS -------------------- --------------------------------------------SEQUENCE_NAME SEQUENCE name MIN_VALUE Minimum value of the sequence MAX_VALUE Maximum value of the sequence INCREMENT_BY Value by which sequence is incremented CYCLE_FLAG Does sequence wrap around on reaching limit? ORDER_FLAG Are sequence numbers generated in order? CACHE_SIZE Number of sequence numbers to cache LAST_NUMBER Last sequence number written to disk

3. Les vues dynamiques de performance (v$)  Les  vues  dynamiques  de  performance  sont  préfixées  par  V$.  Derrière  le  préfixe,  le  reste  du  nom  de  la  vue  est  représentatif de l’information accessible.  Sauf exception, ces vues ne sont accessibles qu’aux DBA.  Les vues relatives aux sujets abordés dans ce chapitre sont les suivantes :  V$I[]NSTANCE   Informations sur l’instance  V$DATABASE   Informations sur la base de données  V$S[]GA et V$S[]GAINFO  Informations sur la SGA  V$PARAMETER  Informations sur les paramètres. 

La  vue  V$PARAMETER  est  une  des  rares  vues  du  dictionnaire  de  données  qui  stocke  des  informations  en  minuscules.  Les vues dynamiques de performance sont aussi décrites dans les vues DICTIONARY et DICT_COLUMNS. En complément,  les  vues  V$FIXED_TABLEet  V$FIXED_VIEW_DEFINITION  donnent  des  informations  sur  la  définition  interne  des  vues  dynamiques.  Exemple  SQL> SELECT name,value FROM v$parameter WHERE name LIKE ’%block%’; NAME VALUE ------------------------------ -------------------db_block_buffers 0 db_block_checksum TYPICAL db_block_size 8192 db_file_multiblock_read_count 95 db_block_checking FALSE Dans les différents chapitres, les principales vues dynamiques relatives au sujet traité seront présentées. 

© ENI Editions - All rights reserved - Algeria Educ

- 3-