Transcription

1 1

2 2

3 3

4 4

5 5

6 A propos des bases de données rela.onnelles Chaque organisa.on a des informa.ons à stocker et à gérer en fonc.on de ses besoins. Par exemple, une entreprise doit rassembler et maintenir des informa.ons de ressources humaines pour ses employés. Ces informa.ons doivent être disponibles à ceux qui les u.lisent. Un système d'informa.ons est un système formel permebant de stocker et traiter de l'informa.on. Un système d'informa.on peut être un ensemble de boîtes en carton contenant des dossiers avec des règles pour définir comment stocker et extraire les dossiers. La plupart des entreprises u.lisent une base de données pour automa.ser ses systèmes d'informa.ons. Une base de donnée est une collec.on d'informa.ons organisée traitée comme une unité. L'objec.f d'une base de données est de centraliser, stocker et extraire ses informa.ons pour l'u.lisa.on des applica.ons bases de données. Système de Ges.on Base de données ou Database Management System (DBMS) A système de ges.on de base de données ou database management system (DBMS) est un logiciel qui contrôle le stockage, l'organisa.on et l'extrac.on des données. Un DBMS est habituellement cons.tué des éléments suivants : Le code du noyau. Ce code gère la mémoire et le stockage pour le DBMS. Le référen.el de métadonnées. Ce référen.el est appelé un dic.onnaire de données. Le langage d'interroga.on. Ce langage permet aux applica.ons d'accéder aux données. Une applica.on Database est un programme logiciel qui intéragit avec une base de données pour accéder et manipuler les données. La première généra.on de systèmes de ges.on de base de données comprend les types suivants : Hiérarchique : Une base de données hiérarchique organise les données sous forme de structure d'arbre. Chaque enregistrement parent comprend un ou plusieurs enregistrements enfants, de manière similaire à la structure d'un système de fichiers. Réseau : Une base de données réseau est similaire à une base de données hiérarchique, exceptés que les enregistrements ont une rela.on plusieurs- vers- plusieurs plutôt que un- vers- plusieurs. Ce dernier système de ges.on de base de données stocke les données avec des rela.ons rigides prédéterminées. Comme aucun langage de défini.on de données n'existe, le changement de structure est difficile. De plus comme ces systèmes n'ont pas un langage de requête simple, cela entrave le développement d'applica.ons. 6

7 Le Modèle relationnel Dans son papier précurseur en 1970 intitulé "A Relational Model of Data for Large Shared Data Banks," E. F. Codd définit un modèle relationnel comme une théorie d'ensembles mathématiques. Aujourd'hui le modèle le plus largement accepté pour modéliser les bases de données relationnelles est le modèle relationnel. Base de donnée relationnelle Une base de données relationnelle est une base de données conforme au modèle relationnel. Le modèle relationnel se caractérise par les principaux aspects suivants : Structures : des objets bien définis pour stocker et accéder aux données d'une base de données. Opérations : des actions clairement définies permettant aux applications de manipuler les données et les structures d'une base de données. Règles d'intégrité : les règles gouvernent les opérations sur les données et les structures d'une base de données. Une base de données relationnelle stocke un ensemble de données dans un ensemble de relations simples. Une relation est un ensemble de tuples. Un tuple est un ensemble désordonné de valeurs d'attribut. Une table est une représentation à deux dimensions d'une relation sous la forme de lignes (tuples) et de colonnes (attributs). Chaque ligne d'une table a le même ensemble de colonnes. Une base de données relationnelle est une base de données qui stocke les données dans des relations (tables). Par exemple, une base de données relationnelle peut stocker des informations sur les employés dans une table employés, une table départements et une table salaires. Voir Aussi : pour un résumé et lien sur le papier de Codd 7

8 Système de Gestion de Base de données relationnelle Le modèle relationnel est la base pour un SGBD Oracle Database est un SGBD Relationnelle objet qui implémente des fonctionnalités orientées objet telles que les types définis par l'utilisateur, l'héritage et le polymorphisme Oracle Database a étendu le modèle relationnel à un modèle relationnel-objet, rendant possible le stockage de modèles business complexes dans une base de données relationnelle. 8

9 Voir Aussi : pour un article résumant l'évolution de Oracle Database Voir la vidéo 9

10 Une brève Histoire de Oracle Database Voir Aussi : pour un article résumant l'évolution de Oracle Database Voir la vidéo 10

11 Les Objets de Schema Dans une base de données Oracle, un schema est une collection de structures de données logiques, ou schema objects. Un schéma appartient à un utilisateur base de données et a le même nom que l'utilisateur. Les objets de schéma sont des structures créées par l'utilisateur qui se réfèrent directement aux données d'une base de données. La base de données supporte plusieurs types d'objets, les plus importants sont les tables et les index. Tables Une table décrit une entité comme les employés. Vous définissez une table avec un nom de table, et un ensemble de colonnes. En général, vous donnez un nom à chaque colonne ou column, un type de données ou data type, et une largeur quand vous créez une table. Une table est un ensemble de lignes. Une colonne identifie un attribut de l'entité décrite par la table. Une ligne ou row identifie une instance de l'entité. Par exemple, les attributs de l'entité employé correspondent aux colonnes pour employee ID et last name. Une ligne identifie un employé spécifique. Vous pouvez en option spécifier des règles pour chaque colonne d'une table. Ces règles sont appelées des contraintes d'intégrité. Par exemple, une contrainte d'intégrité NOT NULL. Cette contrainte force la colonne à contenir une valeur pour chaque ligne. Index Un index est une structure de données optionnelle que vous créez sur une ou plusieurs colonnes d'une table. Les index peuvent augmenter la performance pour l'extraction des données. Quand vous effectuez une requête, la base de données peut utiliser les index disponibles pour localiser les lignes plus efficacement. Les index sont utiles quand les applications interrogent souvent des données spécifiques. Les index sont logiquement et physiquement indépendants des données. Aussi vous pouvez supprimer et créer des index sans effet sur les tables ou autres index. Toutes les applications continuent à fonctionner après suppression d'un index. 11

12 L'accès aux Données Structured Query Language (SQL) SQL est un langage ensembliste qui fournit une interface à un RDBMS comme Oracle Database. En contraste aux langages procéduraux comme le C, qui décrit comment les choses doivent être faites, le SQL est non procédural et décrit ce qui pourrait être fait. Les utilisateurs spécifient le résultat qu'ils veulent obtenir (par exmeple le nom des employés) mais pas comment il le dérive. SQL est le langage standard ANSI pour les bases de données relationnelles. SQL unifie les tâches précédentes en un langage consistant. Oracle SQL est une implémentation du standard ANSI. Oracle SQL supporte plusieurs fonctionnalités qui étendent le standard SQL. PL/SQL et Java PL/SQL est une extension procédurale à Oracle SQL. PL/SQL est intégré avec Oracle Database, permettant d'utiliser toutes les commandes Oracle Database SQL, les fonctions et types de données. Vous pouvez utiliser PL/SQL pour contrôler les flux d'un programme SQL, utiliser des variables, et écrire des procédures de gestion d'erreur. Un avantage premier de PL/SQL est la capacité à stocker la logique applicative dans la base de données. Une procédure ou fonction PL/SQL est un objet de schéma qui consiste en un ensemble d'ordres SQL et autres constructions PL/SQL regroupés ensemble, stockés dans la base de données et exécutés comme une unité pour résoudre un problème spécifique ou effectuer un ensemble de tâches associées. L'avantage principal de la programmation côtéserveur et la fonctionnalité prédéfinie d'être déployée n'importe où. Oracle Database peut aussi stocker des unités de programme écrites en Java. Une procédure stockée Java est une méthode Java publiée et stockée dans la base pour une utilisation générale. Vous pouvez appeler des programmes PL/SQL depuis Java et des programmes Java depuis du PL/SQL. 12

13 La Gestion des Transactions La base de données doit s'assurer que plusieurs utilisateurs peuvent travailler en concurrence sans corruption des données d'un autre utilisateur. Transactions Une transaction est une unité logique, atomique de travail qui contient un ou plusieurs ordres SQL. Oracle Database garantie que les trois opérations s'exécute avec succès ou échec en tant qu'unité. Par exemple, en cas de panne si un ordre dans la transaction échoue alors les autres doivent être annulés. Concurrence des Données Une nécessité pour un RDBMS multi-utilisateur est le contrôle de concurrence, qui est un accès simultané des mêmes données par plusieurs utilisateurs. Sans contrôle de concurrence, les utilisateurs pourraient mal changer les données et compromettre l'intégrité des données. Par exemple, un utilisateur pourrait mettre à jour une ligne alors qu'un autre utilisateur la mettrait à jour simultanément. Oracle Database utilise les verrous pour contrôler l'accès concurrent aux données. Consistance des Données Dans Oracle Database, chaque utilisateur a une vue consistante des données, y compris des modifications visibles effectuées par ses propres transactions et celles validées par d'autres utilisateurs. Oracle Database renforce toujours au niveau ordre la consistance en lecture, qui garantit que les données retournées par une seule requête sont validées et consistantes par rapport à un point unique dans le temps. 13

14 L'Architecture Oracle Database Un serveur base de données Oracle comprend une base de données et au-moins une instance base de données. une base de données est constituée d'un ensemble de fichiers, localisés sur disque. Ces fichiers peuvent exister indépendamment d'une instance base de données. Database instance Une instance est un ensemble de structures mémoire qui gèrent les fichiers de la base de données. 14

15 Structures de L'Instance Database Une base de données Oracle utilise des structures mémoire et processus pour gérer et accéder à la base de données. Toutes les structures mémoire existent dans la mémoire principale des ordinateurs qui constituent le RDBMS. Quand les applications se connectent à une base de données Oracle, ils sont connectés à une instance database. L'instance sert les applications en allouant d'autres zones mémoire en plus du SGA, et démarre d'autres processus en plus des background processes. Les Background processes consolident les fonctions qui seraient gérées par plusieurs programmes Oracle Database pour chaque processus client. Les processus d'arrière-plan effectuent des I/O de manière asynchrone et gèrent d'autres processus Oracle Database pour fournir du parallélisme pour de meilleures performances. Structures Mémoire de l'instance Oracle Database crée et utilise des structures mémoire pour l'utilisation de la mémoire pour le code des programmes, les données partagées entre utilisateurs, les zones de données privées pour chaque utilisateur connecté. Les structures mémoire associées à l'instance sont : System Global Area (SGA) Le SGA est un groupe de structures mémoire partagées qui contient les données et informations de contrôle associées à une instance database. Des exemples de composants SGA sont les data blocks en cache et les zones partagées SQL. Program Global Areas (PGA) Un PGA est une région de mémoire qui contient les données et informations de contrôle pour un processus serveur ou d'arrière-plan L'accès au PGA est exclusif au processus. Chaque processus serveur et background process a sa propre PGA. 15

16 Architecture de l'application Dans une architecture client-serveur, l'application client initie une demande pour une opération à effectuer sur le serveur base de données. Le serveur exécute le logiciel Oracle Database et gère les fonctions nécessaires pour l'accès aux données partagées concurrentes. Le serveur reçoit et traite les demandes des clients. Dans une architecture multi-tiers traditionnelle, un ou plusieurs serveurs d'application effectuent une partie des opérations. Un serveur d'application ou application server contient une grande partie de la logique de l'application, fournit des accès aux données pour le client et effectue certains traitements d'interrogation, allégeant ainsi la charge de la base de données. Le serveur d'application peut servir d'interface entre les clients et plusieurs bases de données et fournir un niveau supplémentaire de sécurité. Service-oriented architecture (SOA) est une architecture multi-tiers dans laquelle la fonctionnalité de l'application est encapsulée dans des services. Les services SOA sont habituellement implémentés en Web services. Les Web services sont accessibles par HTTP et sont basés sur des standards XML comme Web Services Description Language (WSDL) et SOAP. Oracle Database peut agir en tant que provider Web service provider dans un environnement multi-tiers ou SOA. Architecture Réseau Oracle Net Services est l'interface entre la base de données et les protocoles de communication réseau qui facilitent le traitement distribué et les bases de données distribuées. Les protocoles de Communication définissent le moyen par lequel les données sont transmises et reçues sur un réseau. Oracle Net Services supporte les communications sur tous les protocoles réseaux majeurs comme TCP/ IP, HTTP, FTP, et WebDAV. Architecture Serveur dédié ou Dedicated server architecture 16

17 Architecture Multitenant Oracle Database 12c supporte l'architecture multitenant permet à une base de données Oracle d être un conteneur database (CDB). Un CDB est une base de données physique qui contient de zéro à plusieurs bases de donnée plugables (PDB) créées par l utilisateur. Une PDB est une collection portable de schémas objet et non schema. Lorsque vous démarrez avec Oracle Database 12c, vous devez créer une base de données soit de type CDB ou non-cdb. Vous pouvez plugger une non-cdb dans une une CDB en tant que PDB. Pour déplacer une PDB vers une non-cdb, vous devez utiliser Oracle Data Pump. En consolidant plusieurs bases de données physiques sur des machines séparées en une seule database sur une seule machine, l'architecture multitenant fournit les avantages suivants : réduction de coût pour le matériel mouvements de données et de code plus facile et plus rapide gestion et réglage plus facile de la base de données physique Séparation des données et du code Séparation de fonctions entre un administrateur PDB gère uniquement les PDB pour lesquelles il a des privilèges. L administrateur CDB gère le CDB entier. Physiquement, MYCDB est une base de données Oracle. MYCDB a une instance database (bien que plusieurs instances sont possibles avec Oracle Real Application Clusters) et un ensemble de fichiers database, comme une non-cdb. MYCDB contient deux PDBs: hrpdb et salespdb. ces PDBs apparaissent avec leurs applications respectives comme avant leur consolidation base de données. Pour administrer le CDB ou les PDB dedans, un administrateur CDB peut se connecter au conteneur root, qui est une collection de schémas, objets de schémas et objets de non schéma auxquelles les PDBs appartiennent. CDBs et non-cdbs ont des différences architecturales. 17

18 Documentation Oracle Database La documentation est divisée en trois niveaux ou groupes : basique, intermédiaire et avancé. Les utilisateurs peuvent commencer avec les manuels du groupe basique (Oracle Database 2 Day DBA, Oracle Database 2 Day Developer's Guide, ou ce manuel), passent ensuite aux manuels du groupe intermédiaires (2 Day + series), et terminent avec les manuels avancés qui comprennent le reste de la documentation. Groupe Basique Les utilisateurs techniques débutant sur Oracle Database commencent par lire un ou plusieurs manuels du groupe basique d'un bout à l'autre. Chaque manuel est conçu pour être lu en deux jours. Le groupe basique comprend : Oracle Database 2 Day DBA Ce manuel est un manuel basé sur des tâches de démarrage DBA qui enseigne comment effectuer les tâches d'administration database jour par jour. Il enseigne les tâches courantes d'administration nécessaires pour garder la base de données opérationnelle et effectuer des tâches basiques de dépannage et de réglage de performance. Oracle Database 2 Day Developer's Guide Ce manuel est un manuel basé sur des tâches de démarrage développeur base de données qui explique comment utiliser la base de données avec SQL et PL/SQL. Les manuels du groupe basique sont étroitement liés et comportent un certain nombre de références. Par exemple Oracle Database Concepts renvoie fréquemment les utilisateurs sur un manuel 2 Day manual pour apprendre à effectuer une tâche basée sur un concept. Les manuels 2 Day référencent fréquemment Oracle Database Concepts pour un concept sur une tâche. Groupe Intermédiaire Les manuels de ce groupe sont préfixés par le mot 2 Day + car il ajoute des informations contenues dans les manuels 2 Day. Ces manuels couvrent plus en profondeur ce qui est possible dans les manuels basiques ou couvrent des sujets d'intérêts spéciaux. Comme le montre le tableau ci-dessous, les manuels 2 Day + sont divisés en manuels pour les DBAs et développeurs. Groupe Avancé Ces manuels sont prévus pour des utilisateurs experts qui nécessitent plus d'informations détaillées sur un sujet particulier fourni par les manuels 2 Day +. Les manuels de référence Essentiel dans le groupe avancé comprennent : Oracle Database SQL Language Reference Ce manuel est la source d'information définitive pour Oracle SQL. Oracle Database Reference Ce manuel est la source définitive pour des informations sur les paramètres d'initialisation, les vues du dictionnaires de données et les vues dynamiques de performance. Les guides avancés sont trop nombreux pour être listés ici. Le tableau ci-dessous guide sur ceux utilisés en majorité par les experts DBA et développeurs. 18

19 19

20 20

21 21

22 22

23 Télécharger le logiciel Téléchargez le logiciel depuis Oracle Technology Network ou MyOracle Support suivant votre statut support. OTN: Oracle Database 12c Release 1 ( ) Software (64-bit) edelivery: Oracle Database 12c Release 1 ( ) Software (64-bit) 23

24 Décompresser les fichiers Dézippez les fichiers. unzip linuxamd64_12c_database_1of2.zip! unzip linuxamd64_12c_database_2of2.zip! Vous devez obtenir un répertoire appelé "database" contenant les fichiers d installation. 24

25 Le fichier hosts Le fichier "/etc/hosts" doit contenir le nom complet du serveur. <IP- address> <fully- qualified- machine- name> <machine- name> Par exemple localhost.localdomain localhost ol6-121.localdomain ol

26 Prérequis Installation Oracle Effectuez soit le Setup Automatique, soit le Setup Manuel pour compléter les prérequis de base. Le Setup supplémentaire est nécessaire pour toutes les installations. 1 Installation Automatique Si vous planifiez d utiliser le package "oracle-rdbms-server-12cr1-preinstall" pour effectuer tous vos setup prérequis, passez la commande suivante : # yum install oracle-rdbms-server-12cr1-preinstall -y Note. Les versions précédentes de Oracle Linux nécessitaient un setup manuel du référentiel Yum en suivant les instructions suivantes à l adresse : Il est probablement utile de faire une mise à jour complète, mais ce n est pas à proprement parlé nécessaire. # yum update 26

27 Installa.on manuelle Si vous n avez pas u.lisé le package "oracle- rdbms- server- 12cR1- preinstall" pour effectuer tous les prérequis, vous devez effectuer les tâches de setup suivantes : Ajoutez or modifiez les lignes suivantes dans le fichier "/etc/sysctl.conf". fs.file- max = kernel.sem = kernel.shmmni = 4096 kernel.shmall = kernel.shmmax = net.core.rmem_default = net.core.rmem_max = net.core.wmem_default = net.core.wmem_max = fs.aio- max- nr = net.ipv4.ip_local_port_range =

28 Installa.on manuelle Si vous n avez pas u.lisé le package "oracle- rdbms- server- 12cR1- preinstall" pour effectuer tous les prérequis, vous devez effectuer les tâches de setup suivantes : Exécutez la commande suivante pour changer les paramètres courants du noyau. /sbin/sysctl - p Ajoutez les lignes suivantes dans le fichier "/etc/security/limits.conf". oracle soi nofile 1024 oracle hard nofile oracle soi nproc oracle hard nproc oracle soi stack oracle hard stack

29 Installa.on manuelle Si vous n avez pas u.lisé le package "oracle- rdbms- server- 12cR1- preinstall" pour effectuer tous les prérequis, vous devez effectuer les tâches de setup suivantes : Installez les packages suivants s ils ne sont pas présents : # From Public Yum or ULN yum install binu.ls - y yum install compat- libcap1 - y yum install compat- libstdc y yum install compat- libstdc i686 - y yum install gcc - y yum install gcc- c++ - y yum install glibc - y yum install glibc.i686 - y yum install glibc- devel - y yum install glibc- devel.i686 - y yum install ksh - y yum install libgcc - y yum install libgcc.i686 - y yum install libstdc++ - y yum install libstdc++.i686 - y yum install libstdc++- devel - y yum install libstdc++- devel.i686 - y yum install libaio - y yum install libaio.i686 - y yum install libaio- devel - y yum install libaio- devel.i686 - y yum install libxext - y yum install libxext.i686 - y yum install libxtst - y yum install libxtst.i686 - y yum install libx11 - y yum install libx11.i686 - y yum install libxau - y yum install libxau.i686 - y yum install libxcb - y yum install libxcb.i686 - y yum install libxi - y yum install libxi.i686 - y yum install make - y yum install sysstat - y yum install unixodbc - y yum install unixodbc- devel - y 29

30 Installa.on manuelle Si vous n avez pas u.lisé le package "oracle- rdbms- server- 12cR1- preinstall" pour effectuer tous les prérequis, vous devez effectuer les tâches de setup suivantes : Installez les packages suivants s ils ne sont pas présents : Créez les nouveaux groupes et u.lisateur suivants : groupadd - g oinstall groupadd - g dba groupadd - g oper #groupadd - g backupdba #groupadd - g dgdba #groupadd - g kmdba #groupadd - g asmdba #groupadd - g asmoper #groupadd - g asmadmin useradd - u g oinstall - G dba,oper oracle Décommentez les autres groupes si nécessaire 30

31 Installa.on supplémentaire Les étapes suivantes doivent être effectuées en fonc.on de votre setup manuel ou automa.que. Définissez le mot de passe de l u.lisateur "oracle". passwd oracle Modifiez dans le fichier "/etc/security/limits.d/90- nproc.conf" comme décrit ci- dessous. Voir MOS Note [ID ] # Change this * soi nproc 1024 # To this * - nproc Définissez secure Linux à permissive en éditant le fichier "/etc/selinux/config", Vérifiez le flag SELINUX comme suit : SELINUX=permissive Une fois la modifica.on effectuée, redémarrez le serveur ou exécutez la commande suivante : # setenforce Permissive 31

32 Installa.on supplémentaire Si vous avez le firewall Linux ac.vé, vous devez le désac.ver ou le configurer, comme montré à cebe adresse : h"p:// base.com/ar2cles/linux/oracle- linux- 6- installa2on.php#firewall ou : h"p:// base.com/ar2cles/linux/linux- firewall.php#installa2on Pour le désac.ver : # service iptables stop # chkconfig iptables off 32

33 Installa.on supplémentaire Créez les répertoires dans lesquels le logiciel Oracle sera installé. mkdir - p /u01/app/oracle/product/12.1.0/db_1 chown - R oracle:oinstall /u01 chmod - R 775 /u01 Sauf si vous travaillez à par.r de la console ou u.lisez un tunnel SSH, connectez- vous en tant que root et exécutez la commande suivante : xhost +<machine- name> 33

34 Installa.on supplémentaire Ajoutez les lignes suivantes à la fin du fichier "/home/oracle/.bash_profile". # Oracle Sezngs export TMP=/tmp export TMPDIR=$TMP export ORACLE_HOSTNAME=ol6-121.localdomain export ORACLE_UNQNAME=cdb1 export ORACLE_BASE=/u01/app/oracle export ORACLE_HOME=$ORACLE_BASE/product/12.1.0/db_1 export ORACLE_SID=cdb1 export PATH=/usr/sbin:$PATH export PATH=$ORACLE_HOME/bin:$PATH export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib export CLASSPATH=$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib 34

35 Installa.on Connectez- vous avec l u.lisateur oracle. Si vous u.lisez une émula.on X, définissez la variable d environnement DISPLAY. DISPLAY=<machine- name>:0.0; export DISPLAY Démarrez Oracle Universal Installer (OUI) en passant la commande suivante sur le répertoire database../runinstaller Procédez à l installa.on de votre choix. Vous pouvez voir le type d installa.on effectué sur les captures d écran pour chaque étape ci- après. 35

36 Installa.on Configurer les mises à jour de sécurité. Mises à jour My Oracle Support Adresse My Oracle Support 36

37 Installa.on Sélec.onner le type d installa.on 37

38 Installa.on Classe système 38

39 Installa.on Configura.on Installa.on standard 39

40 Installa.on Récapitula.f d installa.on 40

41 Installa.on Installa.on du produit 41

42 Installa.on Exécu.on des scripts de configura.on 42

43 Installa.on Assistant de configura.on Database Note. L écran "Database Configura.on Assistant Complete" affiche Database Express 12c, sous la forme "hbps://ol6-121.localdomain:5500/em". 43

44 Installa.on Gestion des mots de passe 44

45 Installa.on Fin d installa.on 45

46 Installa.on Enterprise Manager Database Express 12c 46

47 Installa.on Enterprise Manager Database Express 12c 47

48 Post Installation Editez le fichier "/etc/oratab" en définissant le flag restart pour chaque instance à 'Y'. cdb1:/u01/app/oracle/product/12.1.0/db_1:y Si Database Express 12c ne fonctionne pas, vérifiez le port XMLDB HTTP. S il est à 0, définissez le port que vous souhaitez utiliser : SQL> SELECT dbms_xdb_config.gethttpsport FROM dual; GETHTTPSPORT SQL> EXEC dbms_xdb_config.sethttpsport(5500); PL/SQL procedure successfully completed. SQL> 48

49 Erreurs Courantes "error code 35" : Le nom de la machine dans le fichier "/etc/hosts" n est pas correct. Il faut une entrée pour le loopback adapter (localhost) et le nom de la machine. Si vous utilisez DNS pour la résolution de nom, vous devez référencer le loopback adapter dans ce fichier. "error code 37" : Le DNS ne fonctionne pas correctement. Vous pouvez avoir aussi cette erreur si le fichier "/etc/hosts" n est pas configuré correctement. "sqlplus: error while loading shared libraries: libclntsh.so.12.1" : les prérequis n ont pas été respectés. Relancez-les à nouveau. Plus précisément, vérifiez que le package "gcc" a été installé. Listener fails to start Typiquement due à une résolution de nom incorrecte. Vérifiez que "/ etc/hosts" et/ou DNS sont configurés correctement. Linking errors presque toujours due à des prérequis manquants. Examinez les sections d installation. 49

50 Pour plus d informa.on, voir : Oracle Database Installa2on Guide 12c Release 1 (12.1) for Linux h"p://docs.oracle.com/database/121/ladbi/toc.htm Automa2ng Database Startup and Shutdown on Linux h"p:// base.com/ar2cles/linux/automa2ng- database- startup- and- shutdown- on- linux.php Oracle Universal Installer (OUI) Silent Installa2ons h"p:// base.com/ar2cles/misc/oui- silent- installa2ons.php 50

51 51

52 52

53 Rôle du DBA Oracle Installer et gérer les mises à jour du logiciel Créer des bases de données Démarrer, arrêter l instance Database Configurer l environnement réseau Gérer les structures de stockage : tablespaces et Data files, online redo log files et control files Gérer l allocation mémoire Gérer les utilisateurs et leur assigner des privilèges et rôles Créer des objets de schéma : tables, vues, index et remplir les tables avec des données Créer une stratégie de sauvegarde et sauvegarder la base de données Activer l archivage des fichiers online redo log Gérer les performances de la base de données, diagnostiquer des problèmes de performance, et régler la base de données Communiquer avec le support Oracle 53

54 54

55 Outils d administration La liste ci-dessous vous donne un aperçu des produits, outils et utilitaires que vous pouvez utiliser pour atteindre les objectifs de l administrateur de base de données : Oracle Universal Installer Oracle Universal Installer (OUI) est l outil qui vous permet d installer le logiciel et ses options. Il peut appeler automatiquement Database Configuration Assistant lors de l installation du logiciel. Database Configuration Assistant Database Configuration Assistant (DBCA) est un utilitaire qui simplifie la création des bases de données via une interface graphique. Il vous permet de créer une base à partir d un modèle pré configuré. Database Upgrade Assistant L outil Database Upgrade Assistant vous guide dans les opérations de mise à niveau d une base de données après l installation d une nouvelle version du logiciel. Net Configuration Assistant Net Configuration Assistant (NETCA) est un utilitaire qui permet de configurer les «listeners» et les méthodes de résolution de noms qui sont les composants majeurs d Oracle Database network. Oracle Enterprise Manager Express Oracle Enterprise Manager Express permet d administrer votre base de données via une interface WEB. Après avoir installé le logiciel, créé ou mis à niveau la database et configuré le réseau, vous pouvez utiliser EM pour gérer votre base de données. EM fournis également une interface pour le réglage des performances via un ensemble d outil de conseil. Il permet aussi d exécuter différents utilitaires comme par exemple SQL*Loader ou Recovery Manager (RMAN). SQL*Plus SQL*Plus est l outil consacré pour administrer la base de données Oracle lorsque l on a pas la possibilité d utiliser une interface graphique. Cet outil envoie directement les ordres SQL au noyau Oracle en connexion locale ou distante via SQL*Net. SQL Developer est l outil graphique pour Développeurs et DBA. 55

56 56

57 57

58 Outils d administration avec le langage SQL La plupart des opérations qui sont exécutées avec «Oracle Enterprise Manager Database Control (Database Control)» utilisent le langage SQL («Structured Query Language»). Le SQL est le langage standard pour l interrogation des bases de données relationnelles. ci-dessous, vous avez un exemple de requête SQL qui ramène les informations code pays et nom de pays de la table des pays : SELECT COUNTRY_ID, COUNTRY_NAME FROM HR.COUNTRIES; Ci-dessous, vous avez un autre exemple d un ordre SQL concernant la création d un utilisateur dans le cadre de l administration de la base de données. : CREATE USER nick IDENTIFIED BY password; Quand vous effectuez ce genre d opération avec le Database Control, vous pouvez cliquer sur le bouton «Afficher le Code SQL» afin de contrôler l ordre qui sera envoyé à la Database. En supplément de l interface WEB du «Database Control» pour la gestion de la base de données, vous pouvez utiliser d autres outils tels que SQL Developer et SQL*Plus. Ces utilitaires envoient directement des ordres SQL ( select, insert, update, ou delete) vers la «database». Concernant «SQL Developer» «SQL Developer» est un outil avec une interface graphique pour accéder à «Oracle Database». C est l utilitaire privilégié pour les développements en langage SQL et PL/SQL. Il est disponible par défaut avec l installation du produit Oracle Database en version 11g. «SQL Developer» est un produit libre, vous pouvez le télécharger depuis le site 58

59 Administration en mode ligne de commande : SQL*Plus Pour effectuer des tâches d administration avec SQL*Plus il faut être connecté dans un mode particulier : «internal» dans les version 8i et précédentes, «AS SYSDBA» en 9i, 10g et 11g. Ce mode de connexion octroie tous les privilèges possibles, tant au niveau système d exploitation qu au sein de la base de données. Il est fortement recommandé de rester vigilant d un point de vue de la sécurité et de ne pas permettre à quiconque de se connecter dans ce mode privilégié. En local, c est l appartenance d un USER du système d exploitation à un groupe spécifique (DBA sous Unix/Linux, ORA_DBA sous windows), qui autorise la connexion en mode SYSDBA. Par exemple, lors de l installation du logiciel RDBMS (le noyau Oracle), un groupe d utilisateur doit être créé. L OUI demande le nom de ce groupe (dba en général) et configure le noyau Oracle en conséquence. Si l utilisateur système considéré appartient au groupe en question, il pourra alors se connecter en mode SYSDBA sans avoir a entrer de mot de passe. Dans l environnement Windows, le groupe ORA_DBA est créé automatiquement pendant l installation du logiciel. La connexion sous Unix s effectue de la manière suivante : 1. se connecter sous un utilisateur système appartenant au groupe DBA $ id (group 100 dba) 2. définir les variables d environnement d accès à la base ORACLE_HOME et ORACLE_SID. Cette dernière variable indique le nom de l instance à laquelle l on doit se connecter. $ ORACLE_SID=DB10G; export ORACLE_SID 3. Appeler SQL*Plus et se connecter en mode privilégié $ sqlplus "/ as sysdba" Ce mode de connexion est utilisé initialement si l on souhaite créer une base manuellement. En connexion distante via SQL*Net un fichier supplémentaire de mots de passe doit exister pour autoriser le mode SYSDBA. Ce fichier doit être créé au préalable via la commande orapwd. 59

60 Configurer l environnement réseau SQL*Net : Concepts Connexion client-serveur standard SQL*Net est la couche logiciel qui gère les communications entre les processus d Oracle. Il existe différent types de communication : Les communication Client/serveur. C est le mode le plus utilisé avec SQL*Net. Les connexions inter base Oracle. Elles sont établies via des liens inter base appelés plus communément DATABASE LINKS. Les connexions inter base hétérogènes. Ce type de connexion utilise également des DATABASE LINKS, le lien s appuie sur la couche logiciel «Oracle Transparent Gateway». Cette couche logiciel fait l objet d un produit à part et ne sera pas traitée dans ce chapitre. Les sessions SQL*Net sont établies avec l aide d un processus LISTENER qui est à l écoute des demandes de connexion sur le serveur. Lorsqu une demande de connexion arrive, le LISTENER active un processus serveur Oracle et le met en relation avec le processus client qui est actif sur la machine distante. Quand la connexion est établie, le processus LISTENER se remet à l écoute sur le réseau. 1. Le client émet une requête d ouverture de session avec un descripteur de connexion. 2. Le LISTENER établi la liaison entre un processus Serveur et le client. 3. Le dialogue s effectue entre le client et le serveur. 60

61 L utilisation de SQL*Net passe par un descripteur qui décrit le mode de connexion à la base de données distante. Cette chaîne de connexion est associée à un identificateur de connexion, appelé Chaîne Hôte, Alias SQL*Net ou Service de base de données réseau. L alias SQL*Net est évoqué directement derrière le soit lors de l ouverture de la session, soit au cours d une session. Le nom du service de base de données réseau peut être implicitement évoqué par l utilisation d un lien inter-base : DATA BASE LINK. 61

62 Fonctionnement des différentes méthodes de résolution d un identificateur de nom de connexion La diapositive ci-dessus montre trois méthodes de résolution : Fichier TNSNAMES.ORA Serveur d annuaire LDAP Serveur «Oracle Names» 1. Le client contacte une méthode de résolution de nom pour convertir l identificateur de connexion en descripteur de connexion. 2. Le serveur de résolution retourne un descripteur de connexion. 3. Le client appelle le LISTENER avec le descripteur de connexion. 62

63 Composants de l architecture de SQL*Net. SQL*Net supporte les protocoles de réseau suivant : TCP/IP TCP/IP avec SSL SPX Named Pipes LU6.2 Bequeath Les DRIVERS de protocole réseau sont intégrés avec les processus clients et serveur d Oracle. Pour les mettre en communication, l architecture SQL*Net fait appel à un processus LISTENER qui est à l écoute des demandes de connexion sur le réseau. Ce processus est indépendant de l instance de base de données et peut être arrêté et redémarré séparément. S il y a plusieurs versions Oracle installées sur la machine, il ne doit y avoir en général qu un seul LISTENER actif. C est celui de la version d Oracle la plus récente qui doit prendre en compte la gestion du serveur SQL*NET pour toutes les bases installées sur la machine. La configuration du LISTENER, des protocoles utilisés et des méthodes de résolution de noms sont définies dans différent fichiers qui sont implantés par défaut dans le répertoire ORACLE_BASE/ ORACLE_HOME/NETWORK/ADMIN. Vous pouvez définir une variable TNS_ADMIN, dans la base de registres ou dans l environnement du SHELL en mode ligne de commande, pour changer la destination du répertoire d implantation des fichiers de configuration de SQL*Net. Fichiers de configuration de SQL*Net. La configuration standard de SQL*Net, avec la méthode de résolution locale, fait appel à trois types de fichiers : LISTENER.ORA : C est le fichier qui contient les paramètres pour les processus LISTENER. Il est donc présent du coté du serveur de base de données. Il contient la configuration des adresses des différents protocoles de réseau à écouter et les informations qui concernent la destination des différents services de base de données. TNSNAMES.ORA : Ce fichier contient la définition des méthodes de résolution de noms locales. Il est présent du coté client. SQLNET.ORA : Il contient les informations qui définissent le profil de configuration SQL*Net. Notamment, les préférences de choix de la méthode de résolution de noms, le suffixe du domaine par défaut, les services d authentification. 63

64 Configuration du LISTENER SQL*Net Exemple de configuration avec le protocole de réseau TCP/IP LISTENER Nom d identification du LISTENER par défaut. Plusieurs configurations peuvent être définies. PROTOCOL Nom du protocole réseau utilisé. TCP et IPC dans le cas présent. KEY Clé d identification pour le protocole IPC. C est un protocole de communication inter-processus en local. HOST Nom réseau ou adresse IP de la machine. PORT Numéro de port TCP/IP. C est le port 1521 qui est utilisé par défaut, mais ce n est pas obligatoire. S il y a plusieurs LISTENER actifs sur la même machine, ils devront écouter sur des numéros de port différents. Le tableau suivant indique les numéros de port TCP/IP qui sont en général utilisés par SQL*Net Produit N port Fichier de configuration Listener 1521 LISTENER.ORA et TNSNAMES.ORA Oracle Names 1575 NAMES.ORA Oracle Connection 1630 CMAN.ORA Manager pour TCP/IP 1830 SID_LIST_LISTENER - Liste de noms d identification de la définition des services de base de données réseau relatifs au LISTENER par défaut (son nom est LISTENER). Si d autre LISTENER sont définis dans le fichier il doit y avoir également d autre SID_LIST_NOM_LISTENER de définition des services de base de données. GLOBAL_DBNAME C est le nom unique du service de la base de données sur le réseau. Ce nom dépend des paramètres SERVICE_NAMES ou INSTANCE_NAME du PFILE. Il est composé du nom de la base et du nom du domaine qui ont été choisis à la création. Remarque: plusieurs noms de service peuvent être définis pour une même base de données. SID_NAME Nom de l instance, doit correspondre au paramètre INSTANCE_NAME du PFILE (INIT.ORA). ORACLE_HOME - Répertoire d implantation du logiciel. 64

65 Pré-requis de mise en œuvre du LISTENER Vous ne pouvez pas gérer les bases Oracle10g avec un LISTENER provenant d une version inférieure comme celui de la 9i par exemple. Par contre vous pouvez gérer toutes les bases de toutes versions inférieures avec le LISTENER d Oracle10g. Si vous avez installé Oracle dans plusieurs «Oracle Homes» sur la même machine, vous devez normalement utiliser qu un seul LISTENER pour toutes les bases de données. Démarrage et arrêt du LISTENER. Normalement le service Windows NT/XP/2K/2003 du processus LISTENER (OracleOracleHomeTNSListener) doit être configuré en démarrage/arrêt automatique. Location par défaut du fichier LISTENER.ORA : Windows. ORACLE_BASE\ORACLE_HOME\NETWORK\ADMIN. Unix/Linux. Dépendante de la plate-forme en général c est $ORACLE_HOME/network/admin. L emplacement peut être redirigé avec la variable TNS_ADMIN. Vous pouvez administrer manuellement le LISTENER SQL*Net en mode ligne de commande dans une fenêtre MS-DOS (en mode commandes) sur Windows ou dans l environnement «shell» d Unix/Linux : Lancement manuel du LISTENER $ lsnrctl start nom_listener démarre le LISTENER dont le nom défini dans le fichier LISTENER.ORA est nom_listener. Si ce nom est LISTENER, vous pouvez omettre nom_listener : $ lsnrctl start C:\> lsnrctl (exemple sous Windows) Active le programme LSNRCTL (Listener Control) LSNRCTL> start nom_listener lancement du LISTENER nom_listener Arrêt manuel du LISTENER $ lsnrctl stop nom_listener Arrête le LISTENER dont le nom défini dans le fichier LISTENER.ORA est nom_listener. Si ce nom est LISTENER, vous pouvez omettre nom_listener : $ lsnrctl stop LSNRCTL> stop nom_listener arrêt du LISTENER nom_listener LSNRCTL> stat nom_listener affiche l état du LISTENER nom_listener 65

66 La méthode de résolution locale est définie dans le fichier TNSNAMES.ORA. Chaque nom de service y est ajouté et est associé à un descripteur de connexion. L exemple de la diapositive montre la syntaxe standard. Les deux noms LNX92 et VENTES sont associés chacun à un descripteur qui pointe vers la même base de données. LNX92, VENTES : Noms de l alias (identificateur de connexion). SERVICE_NAME: GLOBAL_NAME de la base de données sur le serveur. La méthode de résolution locale des noms de services peut être configurée pendant ou après l installation des bases de données avec les outils : Net Configuration Assistant Net Manager Location par défaut du fichier TNSNAMES.ORA : Windows NT/XP/2K/2003. ORACLE_BASE\ORACLE_HOME\NETWORK\ADMIN. Unix/Linux. Dépendante de la plate-forme en général c est $ORACLE_HOME/network/admin. L emplacement peut être redirigé avec la variable TNS_ADMIN. 66

67 Fichier profile SQL*Net : SQLNET.ORA Ce fichier contient les paramètres qui permettent de définir les propriétés du client SQL*Net et la stratégie employée. Par exemple : NAMES.DEFAULT_DOMAIN = fr.oracle.com Indique le domaine depuis lequel le client envoie les requêtes de résolutions de noms. Quand ce paramètre est défini, le nom du domaine est automatiquement ajouté à chaque nom de service non qualifié. Par exemple, si le domaine par défaut est fr.oracle.com, la chaîne de connexion CONNECT scott/tiger@ventes sera substituée par scott/[email protected] SQLNET.AUTHENTICATION_SERVICES= (NTS) Services d authentification du système d exploitation. NTS est le service natif d authentification de Windows NT. Plusieurs services peuvent être définis sur ce paramètre. NAMES.DIRECTORY_PATH= (TNSNAMES, ONAMES, HOSTNAME) Ordre de préférence des méthodes de résolution de noms TNSNAMES : Locale ONAMES : Oracle Names HOSTNAME : DNS TCP/IP Location par défaut du fichier SQLNET.ORA : Windows. ORACLE_BASE\ORACLE_HOME\NETWORK\ADMIN. Unix/Linux. Dépendante de la plate-forme en général c est $ORACLE_HOME/network/admin. L emplacement peut être redirigé avec la variable TNS_ADMIN. Variables d environnement SQL*Net Vous pouvez utiliser les variables suivantes : LOCAL (windows), TWO_TASK (Unix/Linux) TNS_ADMIN Sous Windows SQL*Net vérifie en premier si la variable est définie dans l environnement SHELL MS-DOS. Si ce n est pas le cas, la variable est recherchée dans la base de registres. LOCAL, TWO_TASK Cette variable permet d indiquer l alias de connexion SQL*Net sans avoir à l indiquer comme service sur la chaîne de connexion. Sa valeur est un nom de service défini dans le fichier TNSNAMES.ORA. TNS_ADMIN C est la variable qui permet de modifier l emplacement par défaut des fichiers de configuration de SQL*Net. Cela peut être utile lorsque vous avez plusieurs Oracle Home sur la machine et que vous voulez centraliser la configuration SQL*Net. 67

68 «Net Configuration Assistant» vous permet de configurer les éléments SQL*Net standard. L outil démarre automatiquement après l installation d Oracle. Il peut être utilisé soit sur une station cliente d Oracle soit sur un serveur de base de données. Il permet de configurer les méthodes de résolution de noms de services, le LISTENER, les noms des identificateurs de connexion dans le fichier TNSNAMES.ORA et l accès à un serveur d annuaire LDAP. Lancement de «Net configuration Assistant» Unix/Linux : $ netca Windows : Pour créer un autre module d écoute sur le protocole TCP/IP SSL : Unix/Linux : $ netca. Windows : Choisir Démarrer>Programmes->Oracle - Nom_Home->Configuration and Migration Tools->Net Configuration Assistant. La fenêtre de bienvenue de l utilitaire s affiche. 1. Sélectionner Configuration d un module d écoute et cliquer sur Suivant. 68

69 2. Sélectionner le radio bouton Ajouter. Vous avez également la possibilité de modifier, supprimer ou renommer un module d écoute déjà existant. Cliquer sur Suivant. 3. Indiquer un nom différent des LISTENERS déjà existants. Par exemple, LISTENER_SSL, cliquer Suivant. 4. Sélectionner un ou plusieurs protocoles pour le nouveau module d écoute dans le cadre de gauche et transférez les dans le cadre de droite en cliquant sur le bouton «>». Par exemple, supprimer le protocole TCP et sélectionner le protocole TCPS. Cliquez Suivant. 5. Indiquer le numéro de port pour le nouveau module d écoute. Vous ne pouvez pas choisir un numéro de port qui est déjà utilisé sur la machine. Pour le protocole TCP/IP SSL choisissez le numéro de port standard: Cliquez Suivant. 69

70 6. La configuration du LISTENER est terminée. A cette étape, Vous pouvez choisir de configurer un autre LISTENER. Sélectionnez Non et cliquez Suivant. 7. Sélectionner le nouveau module d écoute pour le démarrer, cliquez Suivant. 8. Terminer la session avec l Assistant de configuration. Le fichier LISTENER.ORA a été mis à jour. Une version de sauvegarde du fichier a été générée automatiquement avec la date de modification sur son nom. Entrée générée par «Net Configuration Assistant» pour le deuxième LISTENER # LISTENER.ORA Network Configuration File: C:\oracle\o10g\network\admin \listener.ora # Generated by Oracle configuration tools. LISTENER_SSL = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCPS)(HOST = )(PORT = 2484)) ) ) ) 70

71 Pour configurer les méthodes de résolution de noms avec «Net Configuration Assistant» : 1. Unix/Linux : $ netca. Windows : Choisir Démarrer->Programmes>Oracle - Nom_Home-> Configuration and Migration Tools ->Net Configuration Assistant La fenêtre de bienvenue de l utilitaire s affiche. Sélectionner Configuration des méthodes de résolution de noms et cliquer sur Suivant. 2. Vous pouvez ajouter de nouvelles méthodes de résolution en les sélectionnant dans le cadre de gauche pour les transférer à droite avec le bouton «>». L ordre de recherche se fera en premier sur la méthode en tête de liste dans le cadre de droite. Vous pouvez redéfinir cet ordre avec les boutons flèche haut et flèche bas situés à droite. 3. Cliquez sur Suivant et terminer la session. Comme pour les modules d écoute le fichier SQLNET.ORA a été mis à jour automatiquement. C est le paramètre NAMES.DIRECTORY_PATH qui a été modifié ou généré dans le fichier. # SQLNET.ORA Network Configuration File: C:\oracle\o10g\network\admin \sqlnet.ora # Generated by Oracle configuration tools. SQLNET.AUTHENTICATION_SERVICES= (NTS) NAMES.DIRECTORY_PATH= (TNSNAMES, HOSTNAME, ONAMES) 71

72 Pour configurer un nouvel alias SQL*Net avec Net Configuration Assistant : 1. Unix/Linux : $ netca. Windows : Choisir Démarrer>Programmes>Oracle - Nom_Home> Configuration and Migration Tools >Net Configuration Assistant La fenêtre de bienvenue de l utilitaire s affiche. Sélectionner Configuration d un nom de service réseau local et cliquer sur Suivant. 2. Cocher Ajouter et cliquez Suivant. 3. Sélectionner la version du noyau Oracle de la base de données concernée. La syntaxe des alias pour les anciennes version d Oracle est différente. Sélectionner Oracle8i ou ultérieur, cliquez Suivant. 4. Entrer le nom global de la base (nom d instance et nom de domaine réseau) ou d un service défini sur la base concernée s il s agit de la version Oracle8i ou supérieur. Cliquez sur Suivant. 5. Sélectionner le protocole de réseau par lequel la base sera accédée et cliquez sur Suivant. 6. Dans le cas du protocole TCP/IP indiquez le nom réseau de la machine qui héberge la base ainsi que le numéro de port TCP/IP sur lequel écoute le LISTENER SQL*Net du serveur. Cliquez Suivant. 7. Vous pouvez éventuellement effectuer un essai de connexion si le module d écoute est actif. Si le test réussi, cliquez Suivant, dans le cas contraire vous pouvez revenir en arrière pour modifier les paramètres. 8. Sur le dernier écran de configuration vous pouvez entrer le nom de l alias ou du service SQL*Net. Ce nom peut être différent du nom de l instance ou du nom global de la base. Le fichier TNSNAMES.ORA local est automatiquement modifié, une version de sauvegarde est générée. VENTES = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = )(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = lnx92.troiso.fr) ) ) 72

73 Gérer l Instance de base de données Il arrive souvent que l on emploie le terme «instance» pour désigner la base de données elle même. L origine de cette confusion est que la chaîne d identification de l instance définie par la variable d environnement ORACLE_SID correspond en général au nom de la base qui est défini par le paramètre DB_NAME. Il est recommandé d éviter de faire cet amalgame et notamment dans le contexte de l architecture «Real Application Cluster» (R.A.C) où plusieurs instances se partagent la même base simultanément. D une version à l autre les processus d arrière plan qui constituent l instance Oracle peuvent être différents. Cependant, il y a certaines fonctions qui sont toujours assurées par les mêmes processus détachés quelque soit la version du noyau Oracle. Les processus d arrière plan Les processus d arrière plan de l instance Oracle gèrent les structures en mémoire, exécutent les entrées/ sorties pour écrire les données dans les fichiers sur disque et effectuent les différentes tâches de maintenance. Les processus d arrière plan consolident les fonctions qui seraient autrement traitées par de multiples programmes fonctionnant pour le compte de chaque processus utilisateur. Les processus d arrière plan qui sont présents dépendent des dispositifs qui sont employés par la base de données. 73

74 Les principaux processus détachés (d arrière plan) qui sont toujours présents lorsqu une instance Oracle est démarrée sont : SMON "System Monitor" c est le processus superviseur de l instance PMON "Process Monitor" il gère les conflits entre les processus serveurs (dead locks) DBWn "Database Writer" synchronise les BUFFERS du CACHE dans la base. «n» représente un indice en fonction du nombre d occurrences du processus. DBW0, DBW1, etc. LGWR "Log Writer" écrit le contenu du LOG BUFFER dans le fichier REDOLOG actif D autres processus détachés peuvent être présents en fonction de la configuration de l instance : CKPT "Checkpoint" gère les points de synchronisation du CACHE (CHECKPOINT) avec DBWR ARCn "Archiver" archive les fichiers REDOLOGS lorsqu ils sont pleins en mode de fonctionnement ARCHIVELOG. «n» représente le numéro d occurrence du processus d archivage. La liste de processus d arrière plan ainsi que leur fonction est détaillée dans la documentation «Concepts». Les processus clients et serveurs En complément des processus d arrière plan, Oracle Database crée des processus serveurs qui sont chargés de prendre en compte et d exécuter les requêtes SQL des utilisateurs ou des programmes clients. Une connexion utilisateur est composée de deux parties distinctes : Un programme client agissant au nom de l'utilisateur, tel que «Oracle Enterprise Manager», SQL*Plus ou une application Un processus serveur qui gère la connexion à la base de données au nom du programme client et effectue une grande partie du travail pour celui-ci, tel que l interprétation et l exécution des ordres SQL ainsi que l interrogation et le rendu des résultats. Les processus serveurs peuvent être soit dédiés soit partagés par les sessions des utilisateurs. Pour les serveurs dédiés, Oracle Database est considéré comme s exécutant en mode «dedicated server». En serveur partagé, Oracle Database est considéré comme s exécutant en mode «shared server». En mode serveur dédié, chaque processus client est associé à son propre processus serveur. Bien que le mode serveur dédié soit une bonne solution pour des exécutions longues et les tâches d administration, un processus serveur à vide ou trop de processus serveur dédiés peut avoir comme conséquence une utilisation inefficace des ressources. 74

75 La structure mémoire de l instance Les tailles des structures mémoires de l instance influent sur les performances de la base Oracle. Elles sont contrôlées par des paramètres d initialisation. Lors de l installation, vous pouvez choisir de laisser la base de données contrôler la mémoire pour vous automatiquement ou vous pouvez configurer un certain degré de gestion manuellement. Dans le deuxième cas, «Oracle Database» peut vous aider à déterminer les valeurs appropriées pour les paramètres de la mémoire en utilisant les différents conseillés d «Oracle Enterprise Manager». Dans tous les cas, Oracle envoie également des alertes pour vous permettre d identifier les problèmes qui méritent une attention particulière. System Global Area Le System Global Area (SGA) est une zone de mémoire partagée qui contient les données ainsi que les informations de contrôle de l instance. Plusieurs utilisateurs peuvent se partager les données dans cet espace de mémoire et éviter ainsi les accès répétés et la perte de temps en entrées/sorties disque. La SGA est une zone de mémoire vive qui est partagée par les processus qui gèrent l instance. Dans l environnement Unix/Linux elle est implémentée par des segments de mémoire partagée et la concurrence d accès est gérée avec des sémaphores. Cette zone de mémoire contient les différents CACHES qui permettent de réduire la charge en entrées/sortie disque. La plupart de ces CACHES sont régis par un algorithme LRU (Least Recently Use) et peuvent être re-dimensionnés dynamiquement. La taille de chaque zone est définie par le paramètre décrit sur la diapositive ci-dessus. Les valeurs peuvent modifiées sans arrêter l instance dans la limite du paramètre SGA_MAX_SIZE qui lui n est modifiable que lorsque l instance est arrêtée. 75

76 Program Global Area L espace PGA est privé à chaque processus qui exécute une session SQL. Cet espace est utilisé pour stocker le contexte d exécution dynamique des ordres SQL dans une session. Il sert également de mémoire tampon lorsqu il y a nécessité de trier les informations avant de les renvoyer vers le processus utilisateur. La taille de la PGA peut être augmentée dynamiquement. La quantité de mémoire PGA utilisée ainsi que son contenu dépend du mode d exécution de l instance: serveur dédié ou serveur partagé. Le total de la somme de toutes les PGAs individuelles qui sont utilisées est désigné par la mémoire PGA de l instance ou simplement «instance PGA.» Avec Oracle Enterprise Manager Database Control, vous pouvez définir la taille de cette «instance PGA.» En mode de connexion classique, la PGA est un espace alloué dans la zone «heap space» de chaque processus serveur dédié. Pour une configuration en mode serveur partagé, l espace de la PGA est déporté dans une zone de la SGA. Cet espace se nomme UGA pour «User Global Area» et est associé à chaque session utilisateur active. Les processus utilisateur communiquent avec le noyau Oracle par l intermédiaire des processus «dispatchers». Les processus serveur partagés («shared server») exécutent les requêtes SQL qui sont candidates à l exécution dans une file d attente d entrée. Les résultats seront rangés ensuite dans une file d attente de sortie. Ce sont les processus dispatcher qui transferts ces résultats vers les processus client. 76

77 Démarrage et Arrêt de l instance Après l installation, L instance Oracle est démarrée et la base est ouverte aux utilisateurs. A tout moment, vous pouvez vouloir arrêter et redémarrer l instance. Cette section décrit comment démarrer et arrêter l instance de base de données Oracle. Administration des Privilèges pour le Démarrage et l Arrêt de la base Pour lancer ou arrêter l instance Oracle, vous devez vous connecter avec un privilège spécial. Il y a deux formes de ce privilège: SYSDBA pour avoir toutes les autorisations d un administrateur de base de données et SYSOPER pour gérer l instance sans avoir les droits d accès aux objets de la base de données. Quand vous créez une base Oracle, deux comptes administrateurs de base de données sont automatiquement créés: SYS et SYSTEM. Ces deux comptes ont tous les privilèges d administration dans la base de données, mais initialement, ils sont les seuls à pouvoir se connecter avec le privilège SYSOPER. Par conséquent, jusqu'à ce que vous accordiez le privilège SYSOPER à d'autres utilisateurs, vous devez vous connecter comme utilisateur SYS ou SYSTEME pour démarrer ou arrêter l instance. Si vous vous connectez (logging in) comme utilisateur SYS, vous devez toujours spécifier la clause AS SYSDBA (comme SYSDBA.) États d exécution Lorsque le moteur de gestion de base de données est démarré, l instance, c est à dire l ensemble des processus ainsi que la SGA, peut être dans l un des états suivants : NOMOUNT. Certains processus d arrière plan sont actifs et la SGA est allouée en mémoire vive. Seul le fichier de paramétrage (PFILE ou SPFILE) a été ouvert. C est dans cet état que la commande de création de la base de données est exécutée (CREATE DATABASE ) par exemple. MOUNT. Cet état est utilisé pour certaines opérations de maintenance liées au système d exploitation. Par exemple lorsque l on effectue une restauration ou un déplacement de fichier physique. Dans ce mode seuls les fichiers de paramétrage et le CONTROFILE ont été ouverts. Les ordres SQL SELECT sont utilisables pour consulter les structures internes de la SGA ( tables virtuelles V$). OPEN. C est l état normal de fonctionnement du moteur de gestion de base de données. La base est ouverte et toutes les opération SQL sont autorisées. Tous les fichiers qui participent au fonctionnement de la base de données ont été ouverts. 77

78 Activation de l instance Le démarrage de l instance s effectue via la commande STARTUP. Par défaut, l instance passe successivement par les états NOMOUNT, MOUNT et OPEN. Cela suppose que les fichiers de paramétrage sont dans le répertoire d implantation par défaut (recommandé par Oracle). Si ce n est pas le cas, il est possible d évoquer l endroit où se situe le fichier de paramètre avec l option «pfile» comme le montre la figure ci-dessus (le «?» indique le répertoire pointé par la variable ORACLE_HOME dans l environnement Unix/Linux). Vous pouvez également forcer un mode d activation spécifique de l instance : Mode «RESTRICT». Il est utilisé si l on désire effectuer des opérations d administration en interdisant l ouverture de session utilisateur qui n ont pas de privilège d administration (DBA). Commande STARTUP RESTRICT. En état NOMOUNT. C est ce que l on exécute lors d une restauration de fichier de contrôle ou d une restitution (RECOVER UNTIL) incomplète de base de donnée. Commande STARTUP NOMOUNT. En état MOUNT. Commande STARTUP MOUNT. 78

79 Lorsque vous cliquez sur le bouton «Démarrer / Arrêter» de la page d accueil (voir ci-dessous) vous pouvez être amené à entrer les informations de connexion au niveau système et base de données comme le montre la page sur la diapositive ci-dessus. Entrer les informations requises et cliquez sur le bouton OK pour exécuter l opération de démarrage ou d arrêt de l instance. 79

80 Sur la page de confirmation de démarrage de l instance de base de données vous pouvez sélectionner le mode en cliquant sur le bouton «Options avancées». Par défaut, c est l option «STARTUP NORMAL» qui sera prise en compte. Confirmez votre choix en cliquant sur le bouton «Oui». Attendez que la page de connexion à l instance s affiche. 80

81 Arrêt de l instance Il existe quatre modes d arrêt du moteur de gestion de base de données Oracle. Le mode STANDARD par défaut via la commande SHUTDOWN. L instance s arrêtra lorsque toutes les sessions actives seront déconnectées. Le mode TRANSACTIONAL provoque la déconnexion de session après la fermeture normale (COMMIT ou ROLLBACK) des transactions actives. Commande SHUTDOWN TRANSACTIONAL. Le mode IMMÉDIAT force l annulation (ROLLBACK) des transactions active et déconnecte toutes les sessions. Commande SHUTDOWN IMMEDIATE. Le mode ABORT provoque un arrêt brutal de l instance. La base peut être dans un état incohérent et l ouverture qui va suivre va effectuer un RECOVER automatique des dernières opération qui étaient en cours. Ce mode équivaut à un arrêt brutal du système et doit être utilisé à bon escient. Commande SHUTDOWN ABORT. 81

82 Sur la page de confirmation d arrêt de l instance de base de données vous pouvez sélectionner le mode en cliquant sur le bouton «Options avancées». Par défaut, c est l option «SHUTDOWN IMMEDIATE» qui sera prise en compte. Confirmez votre choix en cliquant sur le bouton «Oui». Cliquez sur le bouton «Régénérer» pour revenir sur la page de démarrage de l instance. 82

83 Paramétrage de l instance La configuration des paramètres de l instance influe sur son comportement basique. Ces paramètres d initialisation sont lus au démarrage. Pendant l installation,vous avez du choisir avec l outil DBCA, un type de base de données pré configurée avec des paramètres d initialisation définis en rapport de l environnement spécifié. Lorsque la charge de travail et le nombre d utilisateurs augmentent, vous devez ajuster certains de ces paramètres en conséquence. Vous pouvez exécuter ce genre d opération avec «Oracle Enterprise Manager Database Control (Database Control)» ou en utilisant les outils de conseil qui sont fournis avec «Oracle Database» tel que le «Memory Advisor». Après avoir été lus depuis le fichier, les paramètres d initialisation sont maintenus en mémoire et certaines valeurs peuvent être ajustées dynamiquement ensuite. Il existe deux types de fichiers de paramétrage : un fichier de type texte et un fichier serveur de paramètres de type binaire. Le type de fichier de paramétrage utilisé au démarrage de l instance détermine si les modifications dynamiques des valeurs des paramètres sont persistantes ou pas. Fichier serveur de paramètres (SPFILE) Le fichier serveur de paramètres doit être le mode à privilégier pour le paramétrage de l instance car il est maintenu automatiquement par le moteur Oracle. Il ne faut surtout pas l éditer manuellement. Il est implanté sur le serveur qui héberge la base de données. Les modifications sont effectives indépendamment des arrêts et des démarrages de l instance. Les modifications peuvent être effectuées avec le «Database Control» ou automatiquement par le moteur Oracle lui-même lorsque cela est nécessaire. Remarque : Lorsque vous faites une modification dans le fichier serveur de paramètres, vous pouvez également modifier la valeur active en mémoire afin qu elle soit prise en compte immédiatement. Dans le cas contraire, la nouvelle valeur ne sera effective qu après avoir relancé l instance. Fichier de paramétrage texte (PFILE) Ce type de fichier ne peut être modifié par l instance Oracle, il est seulement lu au démarrage. Les changements doivent être effectués avec un éditeur de texte et ne sont pris en compte qu après le redémarrage de l instance. Quand l instance a été démarrée avec ce type de fichier, seuls certains paramètres peuvent être ajustés en mémoire avec le Database Control mais il n y a pas de possibilité de propager ces modifications dans le fichier de paramétrage. Par conséquent, vous devez propager les modifications en éditant le fichier de paramètres car elles seront perdues dés que l instance sera arrêtée. 83

84 Le fichier INIT.ORA ( «parameter file» ) contient les paramètres de réglage de l instance Oracle. Les valeurs sont modifiées via un éditeur de texte. Le fichier SPFILE.ORA est la version binaire du fichier de paramètres et ne doit pas être modifié avec un éditeur de texte. Il faut utiliser la commande «ALTER SYSTEM SCOPE = SPFILE» pour changer dynamiquement les valeurs des paramètres de réglage de l instance. Les noms et les chemins d accès sont spécifiques pour chaque base installée sur la machine et sont différents en fonction de la plate-forme d installation : Unix/Linux : $ORACLE_HOME/dbs/init<SID>.ora, $ORACLE_HOME/dbs/spfile<SID>.ora Windows : %ORACLE_HOME%\Database\init<SID>.ora, %ORACLE_HOME%\Database\spfile<SID>.ora où <SID> (String IDentifier) représente le nom de l instance affecté à la variable ORACLE_SID. Tous les paramètres ne sont pas présent dans le INIT.ORA, seuls ceux qui ont une influence importante sur les réglages de l instance sont à définir. Les autres prendront la valeur par défaut définie dans le noyau Oracle pour une plate-forme donnée (les valeurs par défaut sur les systèmes Unix sont différentes de celles de Windows NT). Les paramètres qui influent sur la taille de la SGA et les performances de l instance sont : db_block_size détermine la taille du bloc Oracle db_cache_size Taille du Cache (nombre de blocs) alloués dans la SGA. Le produit de db_block_size par db_block_buffers donne la taille du BUFFER CACHE shared_pool_size taille de l espace shared_pool log_buffer taille du BUFFER REDOLOG archive_lag_target limite la quantité de données qui peuvent être perdues et augmente effectivement la disponibilité de la base de données de secours en forçant un SWITCH LOGFILE après expiration du délai. La liste exhaustive des paramètres d instance est documentée dans le manuel «Server Reference». Il est possible d imprimer la liste complète des paramètres avec les valeurs associées via la commande suivante sous SQL*Plus : SQL> show parameters Il est également possible de limiter la sortie en indiquant une chaîne de caractères de filtrage : SQL> show parameter size imprime tous les paramètres qui contiennent la chaîne «size» 84

85 A partir de la version 9i la majorité des paramètres de l instance sont modifiables dynamiquement. Il y a donc deux types de paramètres : ceux que l on peut modifier dynamiquement et ceux qui nécessitent un arrêt de l instance pour être ajustés. A partir des versions récentes 9i, 10g et 11g les paramètres sont modifiés via la commande ALERT SYSTEM SET comme le montre la diapositive ci-dessus. Dans les versions précédentes, le fichier PFILE était modifié via un éditeur de texte. Cela imposait un arrêt et redémarrage de l instance pour prendre en compte ces modifications. Cependant, certains paramètres pouvaient déjà être modifiés dynamiquement comme par exemple db_file_multi_block_read_count, mais ce n était pas couramment utilisé. 85

86 La diapositive montre un exemple de modification de la valeur du paramètre «db_cache_size» dans le fichier SPFILE. Si l on souhaite modifier également la valeur du paramètre en mémoire il faut indiquer SCOPE = BOTH. De même, si l on désire simplement modifier la valeur de l instance active il faut indiquer SCOPE = MEMORY. 86

87 La diapositive ci-dessus montre la même modification depuis la DB Console OEM 11g. Cette page est accessible depuis l onglet «Serveur» de la page principale, lien «Paramètres d initialisation». 87

88 Traces et diagnostics de fonctionnement Lorsque l instance de base de données est active, le noyau Oracle trace son activité dans différents fichiers qui sont répartis en trois catégories : La trace des processus utilisateur. C est à dire les processus qui exécutes les ordres SQL. Si vous activez la trace des ordres SQL via la commande ALTER SESSION SET SQL TRACE=TRUE, le fichier trace sera généré dans le répertoire qui est défini par le paramètre «user_dump_dest». La trace des dysfonctionnements. Ces fichiers peuvent être exploités pour le DEBUG d une anomalie par le support du logiciel. Le répertoire d implantation est défini par le paramètre «core_dump_dest». La trace des processus d arrière plan. Chaque processus «background» peut éventuellement produire un fichier trace dans le répertoire pointé par le paramètre «background_dump_dest» en cas d erreur de fonctionnement. C est également dans ce répertoire que le fichier des ALERTES est produit. Ce fichier est la trace de toutes les opérations de bas niveau qui sont exécutées par le moteur Oracle. Il est d usage de le consulter régulièrement afin de contrôler et de pouvoir diagnostiquer pour assurer un fonctionnement correct de l instance de base de données. Il est également nécessaire de purger de temps en temps le contenu de ce fichier. 88

89 Le contenu du fichier des Alertes est visualisable depuis la page «Erreurs du journal d Alertes» via le lien : «Journal d alertes». Cette page est accessible depuis la page d accueil comme le montre la flèche ci-dessous. 89

90 Consultation des structures internes et du dictionnaire de base de données. Oracle fournit un ensemble de vues (VIEWS) SQL pour interroger la structure interne de la base de données. Par exemple, un utilisateur pourra consulter la vue USER_TABLES pour lister l ensemble des tables présentes dans son schéma associé. Ces vues sont réparties en trois catégories. Chaque catégorie est identifiée par un préfixe sur le nom de la vue : Vues préfixées par DBA_. Elles ne sont accessible qu aux utilisateurs qui ont un privilège DBA et donne accès à tous les objets présents dans la base de données. Par exemple, la vue DBA_TABLES permet de lister l ensemble de toutes les tables de la base de données tous USER confondus. Vues préfixées par ALL_. Cette catégorie de vue permet de lister l ensemble des objets qui sont accessibles à l utilisateur connecté à la session courante. Par exemple, ALL_TABLES permet de lister toutes les tables qui peuvent être accédées par la session courante. C est un sous ensemble de DBA_TABLES. Vues préfixées par USER_. Cette catégorie permet de lister l ensemble des objets qui ont été créés par l utilisateur de la session courante. Par exemple, USER_TABLES est la liste des tables qui ont été créées par l utilisateur associé à la session courante. C est un sous ensemble de ALL_TABLES. Il faut consulter le manuel «Reference» pour obtenir la liste complète des vues disponibles pour interroger le dictionnaire de la base. 90

91 Audit de l Instance Les structures internes de la SGA et du CONTROLFILE sont accessibles en consultation via les vues (préfixe V$) qui sont basées sur des tables virtuelles (préfixe V_$). Ces vues sont accessibles dans les trois états que peut prendre l instance (NOMOUNT, MOUNT, OPEN). Ces structures contiennent les informations et les statistiques collectées (V$SYSSTAT) depuis le démarrage de l instance. Elles permettent d analyser le comportement du moteur Oracle et de détecter les problèmes de performances. Remarque : Le libellé des vues V$ est toujours au singulier à l inverse des vues sur le dictionnaires qui sont désignées avec le pluriel. Exemple V$DATAFILE et DBA_DATA_FILES. L ensemble de ces vues est documenté dans le manuel «Reference». 91

92 Administration de la mémoire Cette section montre comment gérer la mémoire de l instance Oracle et comment ajuster la taille des différents éléments de la SGA. Aperçu de la gestion mémoire La gestion de la mémoire concerne la maintenance optimale des tailles des structures mémoire de la «System Global Area» (SGA) et de l instance «Program Global Area» (PGA.) L instance PGA est l ensemble des PGA individuelles qui ont été allouées. Avec la version 11g, «Oracle Database» peut gérer la mémoire SGA et l instance PGA de manière complètement automatique. Vous devez seulement indiquer la taille totale de mémoire que vous désirez affecter à l instance et «Oracle Database» répartit dynamiquement l espace nécessaire entre la SGA et l instance PGA en fonction de la demande. Cette fonctionnalité est désignée comme «automatic memory management.» Dans ce mode de fonctionnement, la «database» effectue également les réglages dynamiques des composants de la SGA ainsi que les tailles des PGA individuelles. Si vous voulez exercer un contrôle plus précis sur les tailles de la SGA et de l instance PGA, vous pouvez vous servir des différents outils de conseil sur la page «Memory Advisors» du «Database Control» pour désactiver la gestion automatique de la mémoire et activer la gestion automatique de la mémoire partagée. Cette action active également de manière implicite la gestion automatique de la PGA. Avec la gestion automatique de la mémoire partagée, vous avez à définir la taille cible ainsi que la taille maximum de la SGA. Les réglages de taille des composants de la SGA sont alors automatiques. Avec la gestion automatique de la mémoire PGA, vous avez à définir la taille de l instance PGA. Les réglages des tailles des PGA individuelles sont alors automatiques. Si vous voulez exercer un contrôle total des tailles des composants de la SGA, vous pouvez utiliser la page «Memory Advisors» du «Database Control» pour désactiver la gestion automatique de la mémoire ainsi que la gestion automatique de la mémoire partagée. La gestion de la mémoire partagée est alors complètement manuelle. Avec ce mode de gestion, vous devez définir vous-même les tailles de chaque composant de la SGA et effectuer les réglages manuellement. Ce mode est laissé aux DBA expérimentés. Notez que la gestion automatique de la PGA reste active. 92

93 Si vous avez choisi l option basique à l installation, la gestion automatique de la mémoire est activée. Pour l installation avancée, DBCA vous permet de sélectionner un des trois modes de gestion de la mémoire. Cependant, Oracle recommande d activer la gestion automatique de la mémoire. Quel que soit le mode de gestion que vous avez choisi à l installation, il est toujours possible d ajuster la configuration en fonction des évolutions de la base de données ou de celles de la machine. Les différentes raisons pour lesquelles vous devrez ajuster la configuration de la mémoire sont les suivantes : Vous recevez de nombreux messages d alerte relatifs à la mémoire. L outil «Automatic Database Diagnostic Monitor (ADDM)» émet une recommandation. Vous désirez ajuster l espace mémoire alloué en fonction d une prévision de charge supplémentaire dans le futur. Vous pouvez utiliser l outil «memory advisor» pour vous aider à ajuster l allocation des espaces mémoire. Activation de la gestion automatique de la mémoire Si vous n avez pas activé la gestion automatique de la mémoire lors de l installation, Oracle vous recommande de le faire à moins que vous soyez un DBA expérimenté et que vous désiriez ajuster vousmême l allocation mémoire pour des raisons spécifiques. Avec la gestion automatique de la mémoire, Oracle effectue automatiquement tous les réglages et optimise les performances en fonction de l évolution de la charge applicative. Pour activer la gestion automatique de la mémoire : 1. Allez sur le lien «Fonctions de conseil sur la mémoire» depuis la page «serveur» en étant connecté en tant que SYS. 2. Cliquez sur un des boutons «Activer» ou «Désactiver» en fonction de ce que vous voulez faire. 3. Cliquer sur «Appliquer.» Une page de confirmation apparaît vous indiquant que vous devez redémarrer la «database» afin que les modifications soient prisent en compte dans le cas où vous auriez modifié le champ «Taille maximale de la mémoire». 93

94 Configuration de la gestion automatique de la mémoire La modification de la configuration de la gestion automatique de la mémoire implique d employer la page de l outil de conseil «Memory Advisors» afin de déterminer la taille totale de la mémoire qui sera utilisée. La procédure de configuration peut différer en fonction de la nouvelle valeur désirée si elle dépasse ou pas la taille maximum courante qui a été définie préalablement. Dans ce cas de figure, vous devez d abord augmenter la taille maximum de la mémoire. Pour modifier la taille totale de mémoire (la nouvelle valeur n excèdera pas la taille maximum de la mémoire) : 1. Allez sur le lien «Fonctions de conseil sur la mémoire» depuis la page «serveur» en étant connecté en tant que SYS. 2. Modifiez la valeur du champ «Taille totale de la mémoire» ou cliquez sur «Conseil» pour avoir une aide dans le choix de la nouvelle taille. La page «Conseils sur la taille de la mémoire» apparaît. Cliquez sur un point de la courbe pour changer la taille mémoire puis cliquez sur le bouton OK. 3. Cliquez sur «Appliquer.» Un message de confirmation apparaît. Pour modifier la taille totale de mémoire (la nouvelle valeur excèdera la taille maximum de la mémoire) 1. Allez sur le lien «Fonctions de conseil sur la mémoire» depuis la page «serveur» en étant connecté en tant que SYS. 2. Modifiez la valeur du champ «Taille Maximale de la mémoire», entrez une valeur supérieure ou égale à celle que vous allez affecter à la taille totale de la mémoire. 3. Cliquez sur «Appliquer.» Un message de confirmation apparaît vous indiquant qu il faut redémarrer la base. 4. Cliquez sur «Oui» et procédez au redémarrage de l instance. 5. Revenez sur la page «Fonctions de conseil sur la mémoire.» 6. Modifiez la valeur du champ «Taille totale de la mémoire» ou cliquez sur «Conseil» pour avoir une aide dans le choix de la nouvelle taille. La page «Conseils sur la taille de la mémoire» apparaît. Cliquez sur un point de la courbe pour changer la taille mémoire puis cliquez sur le bouton OK. Cliquez sur «Appliquer.» Un message de confirmation apparaît. 94

95 Configuration de la gestion automatique de la mémoire partagée La modification de la configuration de la gestion automatique de la mémoire partagée implique d employer la page de l outil de conseil «Memory Advisors» afin de déterminer la taille totale de la mémoire SGA. Cette section suppose que la gestion automatique de la mémoire est désactivée ainsi que la gestion automatique de la mémoire partagée est active et que la nouvelle valeur de la taille de mémoire partagée n excèdera pas celle de la taille maximale de la SGA. Pour modifier la taille totale de la SGA : 1. Allez sur le lien «Fonctions de conseil sur la mémoire» depuis la page «serveur» en étant connecté en tant que SYS. Rendez-vous sur l onglet SGA, comme le montre la figure ci-dessus 2. Modifiez la valeur du champ «Taille totale de mémoire SGA» ou cliquez sur «Conseil» pour avoir une aide dans le choix de la nouvelle taille. La page «Conseils sur la taille de la mémoire SGA» apparaît. Cliquez sur un point de la courbe pour changer la taille mémoire puis cliquez sur le bouton OK. Cliquez sur «Appliquer.» Un message de confirmation apparaît. 95

96 Configuration de la gestion automatique de la mémoire PGA La modification de la configuration de la gestion automatique de la mémoire PGA implique d employer la page de l outil de conseil «Memory Advisors» afin de déterminer la taille totale de l instance PGA. Cette section suppose que la gestion automatique de la mémoire est désactivée et que la gestion automatique de la mémoire PGA est active. Remarque: Quand vous désactivez la gestion automatique de la mémoire, la gestion automatique de la mémoire PGA est activée par défaut. Pour modifier la taille de l instance PGA: 1. Allez sur le lien «Fonctions de conseil sur la mémoire» depuis la page «serveur» en étant connecté en tant que SYS. Rendez-vous sur l onglet PGA, comme le montre la figure ci-dessus 2. Modifiez la valeur du champ «Cible d agrégation de la mémoire PGA» ou cliquez sur «Conseils» pour avoir une aide dans le choix de la nouvelle taille. La fenêtre «Conseils sur la cible d'agrégation de la mémoire PGA» apparaît. Cliquez sur un point de la courbe pour modifier la taille de l instance PGA puis cliquez sur le bouton OK. Cliquez sur «Appliquer.» Un message de confirmation apparaît. 96

97 Architecture physique de la base de données Les fichiers qui constituent la base de données proprement dite sont désignés par DATAFILE dans la documentation. Ils contiennent les informations qui sont stockées dans la base de données. Leur mode d installation dépend du système d exploitation qui héberge le logiciel Oracle. Les fichiers sont installés en général au dessus des systèmes de fichiers natifs de l OS tel que NTFS pour Windows, UFS pour Solaris ou EXT3 pour Linux par exemple. Oracle supporte l accès direct aux disques durs en mode «RAW DEVICE» et fourni également sa propre méthode d accès sur certaines plates-formes, c est la gestion ASM (Automatic Storage Management) qui s assimile à une gestion de volume logique classique. Les DATAFILES peuvent être créés à n importe quel endroit sur le système à la condition que celui-ci puisse garantir la propagation des entrées/sorties en temps réel lorsque le moteur Oracle le demande. Par exemple, les systèmes de fichiers réseau comme NFS 2 (Network File System) ne sont pas supportés par Oracle car les écritures à distance ne sont pas contrôlées par le mode de transport UDP sur lequel se base ce type de système de fichier. Les autres types de fichiers qui participent à la constitution de la base ne contiennent pas de données persistantes. Ils servent au fonctionnement du moteur de gestion de base de données et doivent être considérés en tant que tels. 97

98 TABLESPACES Les objets que l on stocke dans une base Oracle sont regroupés logiquement dans un SCHEMA. Chaque SCHEMA est associé à un utilisateur défini dans la base et porte le même nom. Par exemple, les objets créés par l utilisateur SCOTT sont regroupés sous le SCHEMA SCOTT. Les types d objets que l on peut trouver dans un SCHEMA sont : les tables, les index, les séquences, les procédures stockées, les déclencheurs, etc Les objets qui prennent de l espace dans la base de données sont stockés dans des SEGMENTS. Il existe plusieurs type de SEGMENTS qui sont : Les segments de données, ce sont les Tables Les segments d Index Les segments d annulation ou ROLLBACK SEGMENTS (stockés dans les UNDO TABLESPACES) Les segments temporaires ou TEMPORARY SEGMENTS (stockés dans les TEMPORARY TABLESPACES) Oracle stocke les SEGMENTS dans des entités logiques appelées TABLESPACES. Une base de données Oracle est composée d un ou plusieurs TABLESPACE. Le premier TABLESPACE qui est créé à la construction de la base est le TABLESPACE SYSTEM et est obligatoire. Il contient le dictionnaire de la base de données. Physiquement, un TABLESPACE est constitué d un ou plusieurs fichiers DATAFILE. Lorsqu ils ont été créés, les DATAFILES d un même TABLESPACE sont indissociables et il n est plus possible de les supprimer sans détruire tout le TABLESPACE. Cependant, il est possible de modifier la taille de chaque DATAFILE. Les vues dynamiques pour obtenir des informations sur les TABLESPACES et les fichiers DATAFILES sont : V$TABLESPACE V$DATAFILE DBA_TABLESPACES DBA_DATA_FILES Les commandes d administration des TABLESPACES sont documentées dans le manuel : "SQL Language Reference". 98

99 Création de TABLESPACE L outil «Database Configuration Assistant» (dbca) crée automatiquement les TABLESPACES obligatoires: SYSTEM, SYSAUX, UNDO et TEMP. Il crée également un modèle de TABLESPACES: INDEX, TOOLS et USERS. Ces dernier peuvent être supprimés ou remplacés par d autre TABLESPACES plus appropriés à l utilisation que l on veut en faire. La commande de suppression d un TABLESPACE est exécutable en mode ligne de commande sous SQL*Plus ou via un outil d administration tel que Oracle Enterprise Manager. En mode ligne la syntaxe est : SQL> DROP TABLESPACE <nom_tablespace>; La commande de création d un TABLESPACE doit inclure les caractéristiques (son nom et sa taille) d au moins un DATAFILE. Par exemple : SQL> CREATE TABLESPACE OUTILS DATAFILE /u01/oradata/outils_01.dbf SIZE 500M; La commande ci-dessus crée un TABLESPACE nommé OUTILS constitué d un fichier DATAFILE de 500 Mégas octets. 99

100 CONTROLFILE Le fichier de contrôle est l élément clé parmi les fichiers physiques de la base de données, il contient les informations de fonctionnement de l instance qui sont : Les références de la structure physique de la base, liste des TABLESPACE, nom et chemins d accès des fichiers DATAFILES et REDOLOGS. L'état de fonctionnement de l'instance (informations horodatées). Un référentiel («CATALOG") pour le fonctionnement de Recovery Manager Ce fichier est installé en miroir par défaut. En effet, la perte de celui-ci peut engendrer des problèmes importants pour relancer l instance et remettre en question l état consistant de la base de données. Les vues dynamiques pour obtenir des informations sur le fichier de contrôle sont : V$CONTROLFILE V$PARAMETER champ NAME = control_files V$CONTROLFILE_RECORD_SECTION ATTENTION: ne jamais écraser A PRIORI les fichiers "REDOLOGS" et "CONTROLFILE" lors d'une restauration. Mettre en place toutes les techniques disponibles pour conserver la version la plus récente de ces fichiers. 100

101 REDOLOGS Avec le fichier de contrôle, les fichiers REDOLOGS sont des éléments systèmes pour Oracle. Les fichiers REDOLOGS tracent l activité des transactions actives qui écrivent dans la base. Les blocs sont modifiés par les processus serveurs dans les BUFFERS du CACHE en mémoire et ne sont synchronisés dans les fichiers de la base que de temps en temps afin d optimiser les entrées/sorties. Pour ne pas perdre ces modifications si une panne électrique survient, toutes les opérations sur les blocs présents dans le CACHE sont écrites dans le fichier REDOLOG actif. Oracle pourra ainsi rejouer dans la base les opérations qu il n avait pas eu le temps d écrire dans les DATAFILES lorsque la base va redémarrer. Si, au moment de la panne, le REDOLOG actif est endommagé, Oracle ne pourra pas relancer l instance et l on sera contraint de restaurer la dernière sauvegarde complète valide. Cela qui peut être assez long si la taille de la base est importante. Afin d éviter d avoir à effectuer ce genre de restauration il est fortement recommandé d installer les REDOLOGS en miroir logique comme pour le fichier de contrôle. La figure ci-dessus illustre le principe de fonctionnement du miroir logique des fichiers REDOLOGS. Les REDOLOGS sont effectivement des groupes de fichiers identiques appelés membres de REDOLOG (REDOLOG MEMBER). Il faut au minimum deux groupes de un seul membre pour qu Oracle puisse fonctionner. Le groupe de REDOLOG actif est appelé le CURRENT REDOLOG et est identifié par un numéro chronologique : la LOG SEQUENCE. Chaque fois qu un groupe est plein, Oracle commute sur le groupe suivant et la LOG SEQUENCE est augmentée. Cette opération de commutation est appelée LOG SWITCH. Les commandes pour gérer les fichiers REDOLOGS sont préfixées par ALTER DATABASE (voir le manuel de référence SQL à ce sujet). Par exemple pour ajouter un membre au groupe de REDOLOG numéro 3 enter sous SQL*Plus : SQL> ALTER DATABASE ADD LOGFILE MEMBER /u01/oradata/miroir/redo_03.dbf TO GROUP 3; Les vues dynamiques pour obtenir des informations sur les fichiers et les groupes de REDOLOGS sont : V$LOG V$LOGFILE 101

102 Administration des TABLESPACES Le TABLESPACE est l entité de stockage des objets de la base de données. C est un espace de stockage logique qui est implanté physiquement sous la forme de fichiers du système d exploitation ou directement sur les partitions de disque dur (mini disque, raw device, disque ASM, etc.). A partir de la version 9i, les TABLESPACES peuvent être créés avec des tailles de bloc différentes. Un TABLESPACE peut être composé d un ou plusieurs fichiers. Cette faculté est intéressante si l on désire répartir les données sur différentes unités de disque dur lorsque l on a pas à disposition de mécanismes système pour assurer cette fonctionnalité (STRIPPING R.A.I.D 0). En pratique il est recommandé de distribuer au mieux les TABLESPACES sur le plus d axes de disque qu il est possible de faire. D autre part, il est également judicieux de séparer les types d objet (index, données, «rollback segment», etc..) et les différentes applications dans des jeux de TABLESPACES différents. Si la base contient des grandes tables organisées en partition, il est également intéressant d installer les partitions sur des TABLESPACES indépendant. Le TABLESPACE SYSTEM est créé automatique via la commande CREATE DATABASE. Les autres TABLESPACES sont créés et modifié après cette opération (voir l illustration ci-dessus). 102

103 Administration des TABLESPACES (suite) A partir de la version 9i, les espaces de stockage internes dans les TABLESPACES (EXTENTS) peuvent être gérés localement. C est à dire que l information sur l espace disponible dans le TABLESPACE se trouve dans l entête des fichiers DATAFILE. Ce mode de gestion est largement plus performant que dans les versions précédentes d Oracle (8i, 8.0, 7, etc.) où les espace de stockage étaient gérés dans le dictionnaire. Ce mode de gestion LOCALY MANAGED autorise également la fonction TRANSPORTABLE TABLESPACE. Cette fonction permet de décrocher un TABLESPACE d une base pour pouvoir l accrocher directement à une autre sans avoir à effectuer de déchargement et de rechargement des données. La diapositive ci-dessus montre les différentes commandes de création de TABLESPACE avec chacun des deux modes de gestion du stockage. Aujourd hui, il est recommandé d utiliser le mode de gestion local et de convertir les TABLESPACE qui sont encore dans l autre mode comme l illustre la diapositive ci-dessus. 103

104 Administration des TABLESPACES (suite) UNDO TABLESPACES Les informations qui sont modifiées au sein d une transaction SQL sont stockées temporairement dans des espaces de stockage spéciaux : les ROLLBACKS SEGMENTS. Jusqu en version 8i, les ROLLBACKS SEGMENTS étaient créés manuellement par l administrateur de base de données dans un TABLESPACE défini spécifiquement à cet usage. Aujourd hui, à partir de la version 9i les ROLLBACK SEGMENTS sont gérés automatiquement dans les TABLESPACES de type UNDO. L administration de ce type d objet est largement simplifiée. La syntaxe de création des TABLESPACES UNDO est illustrée ci-dessus. TEMPORARY TABLESPACES Ce type d espace disque logique est prévu pour stocker les résultats temporaires des opérations de tri avant de retourner le résultat définitif à l utilisateur. Ce sont les ordres SQL qui utilisent les options ORDER BY, GROUP BY ou bien qui effectue des jointures qui produisent en général des segments temporaires. Les utilisateurs déclarés dans la base sont associés à un TABLESPACE de type TEMPORARY. Plusieurs TABLESPACES de ce type peuvent être créés dans une même base, il convient alors de définir le TEMPORARY TABLESPACE par défaut comme le montre les commandes ci-dessus. La vue «database_properties» indique quel est le TABLESPACE temporaraire qui est définis par défaut. 104

105 Administration des TABLESPACES (suite) Il existe trois types de TABLESPACE : PERMANENT, UNDO et TEMPORARY. Le type standard est le PERMANENT. Ce type d espace disque logique peut être en mode lecture/écriture ou en lecture seulement. En mode lecture seule, aucun fichier qui constitue le TABLESPACE n est accédé en écriture à l ouverture et à la fermeture de l instance. Cela permet de déplacer les fichier de l espace disque logique sur des CDROM, DVD ou système de disque optique. La commande ALTER TABLESPACE permet de commuter le mode d utilisation du TABLESPACE. D autre part il est également possible de déconnecter un TABLESPACE avec la commande ALTER TABLESPACE nom OFFLINE (voir ci-dessus). Cette fonctionnalité peut être utile pour libérer temporairement de la place disque lors d opérations de maintenance. 105

106 Administration des TABLESPACES (suite) Les DATAFILES peuvent être configurés de telle sorte pour qu ils s agrandissent automatiquement lorsqu ils sont pleins. Ce paramétrage se défini au niveau de chaque fichier avec les commandes CREATE TABLESPACE ou ALTER DATABASE comme l illustre la diapositive ci-dessus. Les DATAFILES qui constituent un espace disque logique ne peuvent pas être supprimés tant que le TABLESPACE n a pas été supprimé avec la commande DROP TABLESPACE. Il arrive parfois que les fichiers DATAFILE aient mal été dimensionnés et qu il y a un gaspillage de place disque. Il est alors possible de réduire la taille de certains DATAFILE sans avoir à supprimer le TABLESPACE pour le recréer plus petit. La syntaxe est illustrée ci-dessus. 106

107 Administration des TABLESPACES (suite) Déplacement des fichiers Comme pour les fichiers REDOLOG, il est possible de déplacer les fichier DATAFILES via la commande ALTER TABLESPACE ou ALTER DATABASE. La procédure est illustrées ci-dessus. Suppression C est la commande DROP TABLESPACE nom INCLUDING CONTENT. Les DATAFILES associés au TABLESPACE peuvent être supprimé automatiquement en ajoutant la clause «including datafiles». Cette option existe à partir de la version 10g. Les noms de fichier DATAFILE peuvent être gérés automatiquement avec le module OMF (Oracle Management File). Le répertoire de destination des fichier doit être définis avec le paramètre : «db_create_file_dest». 107

108 Administration des TABLESPACES (suite) Vous pouvez gérer les TABLESPACES avec la console HTML OEM (voir la diapositive ci-dessus). La page «Espaces disques logiques» est accessible depuis la page principale onglet «Administration» (voir cidessous). 108

109 Administration des TABLESPACES (fin) Les vues V$TABLESPACE, V$DATAFILE et V$TEMPFILE sont également accessibles lorsque l instance est montée. Les vues DBA_TABLESPACES, DBA_DATA_FILES et DBA_TEMP_FILES ne peuvent être consultées que si l instance est ouverte. 109

110 Administration du CONTROLFILE Le fichier de contrôle consigne les informations de structure physique et d horodatage (time stamp) de la base de données. Chaque DATAFILE et fichier REDOLOG mobilise une entrée dans le CONTROLFILE. Le fichier de contrôle contient également un référentiel qui contient le journal des sauvegardes qui ont été exécutées par l outil «Recovery Manager». Ce fichier contient des informations codées en binaire et ne peut pas être édité avec un éditeur de texte classique. Sans le CONTROLFILE l instance ne peut pas démarrer, l information qu il contient est toujours plus à jour que celle qui est contenue dans l entête des DATAFILES et/ou des REDOLOG. Par conséquent, le fichier est installé en plusieurs exemplaires (miroir logique) qui doivent être implantés dans des répertoires différents de la machine qui héberge la base de données. C est le paramètre d instance «control_files» qui désigne le chemin d accès et le nom des différents exemplaires du fichier de contrôle. Ce fichier étant très important il est recommandé de le sauvegarder régulièrement avec la commande ALTER DATABASE BACKUP CONTROLFILE TO chemin_accès_nom_de_fichier. Les vues V$ relatives au CONTROLFILE sont : V$CONTROLFILE V$PARAMETER V$CONTROLFILE_RECORD_SECTION 110

111 Administration des fichiers REDOLOGS Les REDOLOGS sont des fichiers système qui concernent le fonctionnement du noyau Oracle. Il permettent de garantir que la base de données sera toujours cohérente même après des erreurs de fonctionnement du système d exploitation ou du moteur de gestion de base de données. Le noyau Oracle est conçu pour limiter le plus possible les entrées/sorties physiques dans les fichiers de la base de données. Les modifications des blocs de données sont exécutées dans le CACHE. Les blocs qui ont été marqués comme étant modifiés (dirty bloc) sont synchronisés dans la base périodiquement. L opération de synchronisation du ou d une partie du CACHE est désignée par CHECKPOINT. Les modifications des blocs entre deux CHECKPOINT sont sauvegardées automatiquement dans le REDOLOG actif. En cas d arrêt brutal de l instance, ces informations seront récupérées dans le dernier fichier REDOLOG actif (CURRENT REDOLOG). C est ce mécanisme qui permet de garantir que la base sera toujours cohérente. Cependant l écriture dans les groupes de REDOLOG est circulaire. C est à dire que le contenu du groupe de REDOLOG le plus ancien est écrasé par les informations REDO les plus récentes. Par conséquent, pour être sur de ne pas perdre les modifications qui ont effectuées sur les blocs de données dans le CACHE, le noyau Oracle déclenche un CHECKPOINT avant la commutation d un REDOLOG à l autre. Si le nombre de blocs «dirty» est important, le volume d entrées/sorties sera proportionnel à ce moment là et le système SGBD risque de ralentir. Pour éviter ce problème il faut régler la fréquence des CHECKPOINTS avec le paramètre LOG_CHECKPOINT_INTERVAL (8i et 9i). En 10g la fréquence des point de synchronisation est automatiquement ajustée en fonction de l activité de l instance et de la valeur du paramètre FAST_START_MTTR_TARGET. Ce paramètre le temps de RECOVER moyen souhaité. Il est exprimé en secondes. Plus ce temps est court, plus la fréquence des CHECKPOINTS sera importante. A l inverse, les performances seront meilleures. La commutation d un REDOLOG à l autre provoque donc un CHECKPOINT pour tous les BUFFERS DIRTY du CACHE. Le SWITCH de REDOLOG est automatique lorsque le groupe actif est plein. Par conséquent, la taille des fichiers REDOLOG conditionne la fréquence des CHECKPOINTS. Le SWITCH peut être déclenché manuellement avec les commandes décrites sur la diapositive. 111

112 Administration des REDOLOGS (suite) Il existe une relation entre la taille du CACHE et celle des fichiers REDOLOGS. Ces dimensions doivent être ajustées en proportion. Si l on désire augmenter considérablement le CACHE de la SGA, il peut être utile de redimensionner les REDOLOGS. Pour ce faire, il faut créer ne nouveaux groupes de REDOLOGS plus grand puis supprimer les anciens avec la commande ALTER DATABASE ADD LOGFILE comme l illustre la diapositive ci-dessus. En cas de dysfonctionnement qui provoque un arrêt brutal de l instance le contenu du CURRENT REDOLOG est automatiquement rejoué. Cela permet d annuler ou de valider les dernières opérations qui n ont pas été écrites dans la base avant la panne. Si le CURRENT REDOLOG est endommagé ou perdu, l instance ne pourra pas être relancée. Pour se sortir de cette situation critique, il est souvent nécessaire de restaurer une sauvegarde complète ce qui peut engendrer la perte des dernières opérations qui ont été effectuées après la dernière sauvegarde. Pour palier à la perte du CURRENT REDOLOG il est recommandé de configurer chaque groupe de REDOLOG avec plusieurs fichiers membre en miroir logique. La commande ALTER DATABASE ADD LOGFILE MEMBER permet d effectuer cette configuration comme le montre la diapositive ci-dessus. 112

113 Administration des REDOLOGS (suite) La gestion des nom de fichier membres des groupes de REDOLOGS peut être gérée automatiquement par Oracle. Si les fichiers sont implantés sur des systèmes de fichier, les paramètre «db_create_online_log_dest_n» (N peut prendre la valeur 1 à 5) doivent être définis avec le chemin d accès des répertoires destinés à accueillir les fichiers REDO. Pour afficher l état des groupes de REDOLOGS consulter la vue V$LOG. Pour afficher les chemins d accès et les noms des membres des groupes de REDO, utiliser la vue V$LOGFILE. 113

114 Administration des REDOLOGS (suite) Les commandes d administration des REDOLOG sont documentée dans le manuel «SQL Reference». C est un sous ensemble de la commande ALTER DATABASE. 114

115 Administration des REDOLOGS (fin) Vous pouvez gérer les groupes de REDOLOGS avec la console HTML OEM (voir la diapositive ci-dessus). La page «Groupe de fichiers de journalisation» est accessible depuis la page principale onglet «Administration» (voir ci-dessous). 115

116 Transactions et TABLESPACE UNDO Lorsqu un bloc de données est modifié par un ordre SQL DML (INSERT, UPDATE, DELETE), les informations qui vont changer sont sauvegardées dans un ROLLBACK SEGMENT. Cela permet de restaurer le bloc en cas d annulation de l opération (ROLLBACK). Tant que la transaction est active, le ROLLBACK SEGMENT conserve les données en cours de modification (image avant), et les informations de contrôle : l horodatage («timestamp»), l identification et l état (active, annulée, validée, ) de la transaction. Les informations de contrôle de la transaction sont stockées dans l entête du ROLLBACK SEGMENT. La transaction se termine lorsque la session envoie soit sur un ordre ROLLBACK, soit sur un ordre COMMIT. Dans le premier cas, l image avant est restituée dans les blocs de données concernés par la transaction. Dans le deuxième cas, l image avant est libérée dans le ROLLBACK SEGMENT et par conséquent, peut être écrasée par les données d une autre transaction future. Il est parfois nécessaire de conserver les données contenues dans les ROLLBACKS SEGMENTS plus longtemps pour garantir la lecture cohérente à certain traitements. Ce cas de figure est produit par les instructions SQL : «set transaction read only» et/ou «set transaction isolation level serializable». Dans ces circonstances les ROLLBACK SEGMENTS mobilisent plus d espace dans le TABLESPACE UNDO. Par défaut le niveau d isolation entre les transaction est «read committed» Dans les versions inférieures à la 9i, les problèmes d espace dans les TABLESPACES de ROLLBACK SEGMENTS se traduisent par l erreur ORA-1555 ou ORA A partir de la 9i, ce genre d erreur a tendance à disparaître avec l utilisation des TABLESPACES UNDO. 116

117 Transactions et TABLESPACE UNDO (suite) Les ROLLBACK SEGMENTS devaient être créé explicitement dans des TABLESPACES spécifiques pour les versions inférieures à la 9i. La diapositive ci-dessus montre un exemple de syntaxe de création selon l ancienne méthode. A partir de la 9i, il est recommandé d utiliser les TABLESPACES UNDO afin de simplifier l administration et d alléger la tâche du DBA. Les paramètres relatifs à la configuration du TABLESPACE UNDO doivent être défini comme le montre la diapositive ci-dessus. 117

118 Transactions et TABLESPACE UNDO (suite) La diapositive montre un exemple de création de TABLESPACE de type UNDO. Plusieurs TABLESPACES de ce type peuvent être créés mais un seul peut être utilisé à la fois. Le paramètre «undo_tablespace» désigne quel est ce TABLESPACE. 118

119 Transactions et TABLESPACE UNDO (suite) Vous pouvez définir la durée de conservation des informations qui sont stockées dans les ROLLBACK SEGMENTS du TABLESPACE UNDO avec le paramètre «undo_retention» qui est exprimé en seconde. La taille du TABLESPACE doit être proportionnelle à la durée de rétention souhaitée. Dans le cas où l on rencontre souvent l erreur ORA-1555, il convient d augmenter la valeur du paramètre et d agrandir la taille du TABLESPACE UNDO. 119

120 Transactions et TABLESPACE UNDO (fin) La diapositive ci-dessus montre la liste des principales vues du dictionnaire qui concernent les informations sur les transactions actives et les ROLLBACK SEGMENTS. 120

121 Gestion des ressources et des mots de passe des utilisateurs Un PROFILE est une collection de paramètres de ressources et de critères de gestion des mots de passe. Les profils sont attribués aux utilisateurs et permettent ainsi d affecter des règles d utilisation de la base de données. Les paramètres de ressource que l on peut définir dans un profil sont définis ci-dessus. 121

122 La diapositive ci-dessus décrit les critères qui concernent la gestion des mots de passe que l on peut définir dans les profils. 122

123 Par défaut le critère PASSWORD_VERIFY_FUNCTION n est pas actif. Un modèle de fonction PL/SQL pour la vérification des mots de passe est fournie avec le script $ORACLE_HOME/rdbms/admin/utlpwdmg.sql. Vous pouvez par exemple personnaliser cette fonction (effectuer une traduction par exemple) et charger le script dans la base de données sous le compte SYS afin de modifier le profil par défaut DEFAULT. 123

124 La diapositive ci-dessus donne un exemple de création de profil. Pour que la gestion des ressource et des critères de gestion des mots de passe soit effective il faut l activer en modifiant le paramètre d instance RESOURCE_LIMIT. Les vues du dictionnaire qui sont relatives à la gestion des ressources et des critères de gestion des mot de passe sont décrites ci-dessus. 124

125 Utilisateurs et Schémas L accès à la base de données s effectue via une procédure d identification sous le nom d un utilisateur qui a été déclaré dans la base par l administrateur. Les attributs associés à un utilisateur définissent un cadre d exécution sécurisé. Un schéma est un ensemble d objets regroupés pour le compte d un seul utilisateur de la base de données. La diapositive ci-dessus donne la liste des types d objets que peut posséder un utilisateur donné. Le schéma porte le même nom que l utilisateur avec lequel il est associé. Le schéma fait partie des propriétés attribuées à un utilisateur ainsi que le TABLESPACE par défaut dans lequel seront stockés implicitement les objets qui seront créés par l utilisateur, le TEMPORARY TABLESPACE pour les segments temporaires générés par les opérations de tri et enfin les privilèges (systèmes et objets) attribués pour la sécurité d exécution. En pratique, l utilisateur et le seul schéma qui lui est associé sont utilisés indifféremment, cela dépend du contexte d utilisation. 125

126 Création d un utilisateur de base de données La syntaxe de création d un utilisateur de base de données est décrite sur la diapositive ci-dessus. Il existe plusieurs méthodes d identification : Le mot de passe est stocké dans la base. C est la méthode standard, le mot de passe est défini lors de la création de l utilisateur (comme ci-dessus). Le mot de passe est géré sur le réseau local d entreprise dans un annuaire LDAP. Le directory peut être l OID (Oracle Internet Directory) d origine Oracle ou bien d une autre marque. Le mot de passe est géré par le système d exploitation. Dans ce cas de figure, l utilisateur de la base est créé en correspondance avec un utilisateur du système d exploitation avec la clause IDENTIFIED EXTERNALLY. Par défaut, le nom de l utilisateur dans la base a un préfixe (OPS$). Ce préfixe peut être modifié via le paramètre OS_AUTHENT_PREFIXE. Par exemple, si l utilisateur du système d exploitation se nomme FRED, le USER base correspondant avec le préfixe par défaut sera OPS$FRED. La procédure de connexion s effectuera comme suit depuis le USER FRED du système : $ whoami fred sqlplus / SQL> connecté Il est possible d autoriser la connexion d un utilisateur identifié sur une machine distante en définissant le paramètre REMOTE_OS_AUTHENT = TRUE. ATTENTION: ce mode de connexion peut générer des problèmes de sécurité. 126

127 Quotas En plus des ressource attribuées via les profils utilisateur, il est possible de définir des quotas d utilisation de l espace dans les TABLESPACES. La diapositive ci-dessus montre un exemple de syntaxe de définition d un quotas de 100 Méga octets sur le TABLESPACE USERS. Suppression d un utilisateur La commande DROP permet de supprimer un utilisateur ainsi que tous les objets contenus dans son schéma associé avec l option CASCADE. L exemple ci-dessus montre en exemple la suppression du USER SCOTT et de tous les objets qu il possède. Informations du dictionnaire Les vues montrées sur la diapositive ci-dessus ainsi que ALL_USERS, ALL_TS_QUOTAS, USER_USERS et USER_TS_QUOTAS permettent de consulter les informations relatives aux utilisateurs déclarés dans la base. 127

128 Gestion des privilèges Oracle permet de contrôler deux types de privilèges : Les privilèges système. Ce sont des autorisations d effectuer différentes opérations dans la base de données comme par exemple (respectivement pour les privilèges énoncés ci-dessus) : la création de d index, de tables, de modifier les caractéristiques de sa session, de supprimer n importe quelle table de la base, etc. Les privilèges sur les objets. Ce sont des autorisations d effectuer des opérations sur des objets spécifiques comme par exemple (respectivement pour les privilèges énoncés ci-dessus) : l interrogation sur une table, l insertion dans une table, le droit d exécution d une procédure stockée, la suppression dans une table, la modification des données d une table, etc. Les privilèges sont attribués avec la commande GRANT. La révocation est effectuée avec la commande REVOKE (voir les exemples ci-dessus). 128

129 Privilège SYSDBA et SYSOPER. Ce sont des collections de privilèges d administrateurs. Ces deux collections donnent des droits liés au système d exploitation et tous les droits liés à la base de données (privilège DBA). SYSOPER donne les droits notamment de démarrer et d arrêter les instances de base de données. SYSDBA inclus les droits de SYSOPER et autorise en supplément les opérations d administration les plus délicates et dangereuses pour la base (voir la diapositive ci-dessus). Ces collections de privilèges ne peuvent être acquises qu en local sur la machine qui héberge la base de données si l utilisateur du système d exploitation appartient à un groupe OS qui est en corrélation avec ces collections. Ce lien est établis lors de l installation du logiciel Oracle et est codé en dur dans l exécutable du moteur de gestion de base de données. A travers SQL*Net (en réseau), les USERS habilités SYSDBA ou SYSOPER doivent être déclarés dans le fichier de mot de passes qui est créé lors de l installation de la base sur le système. La commande orapwd (dont la syntaxe est commentée ci-dessus) permet de créer le fichier en question. Le nom du fichier est dépendant de la plate forme sur laquelle Oracle est installée : Sous Unix/Linux le nom avec le chemin d accès est $ORACLE_HOME/dbs/orapw<SID> (<SID> est le nom de l instance de base de données). Sous Windows le nom avec le chemin d accès est %ORACLE_HOME%\Database\PWD<SID>.ORA. Le mot de passe qui est passé sur la ligne de commande est celui de INTERNAL (8i est inférieure) ou de l utilisateur SYS (9i et 10g). Les entrées supplémentaires que l on déclare vont permettre de stocker le mot de passe des autres utilisateurs qui seront habilités à se connecter comme SYSDBA ou SYSOPER. C est la commande GRANT qui a pour effet de copier le mot de passe qui est stocké dans la base dans le fichier de mots de passe. Sur la diapositive ci-dessus la commande GRANT SYSDBA TO SYSTEM, attribue le droit SYSDBA au USER SYSTEM. Son mot de passe est par conséquent recopié dans le fichier de mots de passes. SYSTEM pourra ouvrir une session comme SYSDBA même lorsque l instance est arrêtée. 129

130 La diapositive ci-dessus montre deux exemple de connexion comme SYSDBA. Le premier passe par SQL*Net, le second est en local sur la machine qui héberge la base. Héritage de transmission de privilège dans la base En ce qui concerne les privilèges système, la clause WITH ADMIN OPTION permet au bénéficiaire de transmettre à son tour le privilège qui lui est transmis. Par exemple, ci-dessus le privilège CREATE SESSION est octroyé à l utilisateur FRED WITH ADMIN OPTION. Par conséquent, FRED pourra à son tour attribuer le privilège CREATE SESSION à un autre utilisateur. En ce qui concerne les privilèges sur les objets, la clause WITH GRANT OPTION permet au bénéficiaire de transmettre à son tour le privilège qui lui est transmis sur l objet en question. Cependant, en cas de révocation du privilège, celui-ci est également révoqué en cascade à tous les utilisateurs auxquels le bénéficiaire a attribué ce privilège. Par exemple, si l on attribue à FRED le droit d interroger la table SYSTEM.PRODUCT_USER_PROFILE WITH GRANT OPTION : SQL> grant select on system.product_user_profile to fred with grant option; FRED à son tour transmet le droit à SCOTT : SQL> grant select on system.product_user_profile to scott; Si maintenant le droit est révoqué pour FRED : SQL> revoke select on system.product_user_profile from fred; SCOTT n aura également plus de droit SELECT sur la table SYSTEM.PRODUCT_USER_PROFILE. 130

131 Privilèges PUBLIC L utilisateur PUBLIC est défini par défaut dans la base pour permettre de définir des droits pour tous les utilisateurs de la base de données. La diapositive ci-dessus donne comme exemple l attribution du privilège système d exécuter n importe quelle procédure stockée et du droit SELECT sur l objet OE.ORDERS pour tous les utilisateurs de la base. L interrogation du dictionnaire concernant les privilèges s effectue via les vues indiquées ci-dessus et également ALL_SYS_PRIVS, ALL_TAB_PRIVS, ALL_COL_PRIVS, USER_SYS_PRIVS, USER_TAB_PRIVS, USER_COL_PRIVS. 131

132 Rôles Les rôles sont des collections de privilèges. C est un moyen pratique de donner des autorisations en une seule commande plutôt que d attribuer chaque privilège indépendamment en plusieurs passes. Un rôle peut être également être attribué à un autre et plusieurs rôles peuvent être attribués simultanément à un utilisateur. La diapositive ci-dessus montre plusieurs exemples de création et d utilisation des rôles. Un mot de passe peut être définis sur un rôle. Ce mot de passe peut être stocké dans la base ou au niveau du système d exploitation. Pour acquérir les privilèges regroupés par un rôle protégé par un mot de passe, il faut utiliser la commande SET ROLE comme le montre la diapositive ci-dessus. 132

133 Rôles (fin) La commande DROP permet de supprimer un rôle de la base de données (voir la syntaxe ci-dessus). Cette commande ne peut être exécutée que si l on dispose du privilège DROP ANY ROLE. Il existe un certain nombre de rôles qui sont prédéfinis dans la base de données. La diapositive ci-dessus donne la liste des rôles prédéfinis les plus couramment utilisés. Les vues du dictionnaires concernant les rôle sont également indiquées ci-dessus. Il y a également ALL_ROLES, ALL_ROLE_PRIVS, ALL_SYS_PRIVS, USER_ROLES, USER_ROLE_PRIVS, USER_SYS_PRIVS. 133

134 Type de segments Une base de données Oracle permet de stocker différents types d objets que l on peut répartir en deux catégories : les objets qui contiennent de l information et ceux qui traitent l information. Ces derniers sont en général stockés dans le dictionnaire qui est stocké dans le TABLESPACE SYSTEM. Ce sont par exemple : les vues relationnelles, les procédures et fonctions stockées, les séquences, les packages, etc. Les objets de la première catégorie mobilisent de l espace dans la base de données et sont stockés sous forme de segments. On considère différents types de segments : Les Tables. Elles sont réparties en trois types : les tables classiques, les tables organisées en partitions et les tables organisées en index. Les premier type de table est stocké dans un seul TABLESPACE. Les tables en partition peuvent être stockées sur plusieurs TABLESPACE. Elles sont en général utilisées lorsque l on a affaire à des volumes très importants. Les IOT sont des structures de stockage très spécifiques où la table et l index sont une seule et même entité. Les Clusters. Ce sont des regroupements de tables selon un critère de jointure. Les données sont stockées physiquement de telle sorte que les blocs contiennent le résultat de la requête qui effectue l équi-jointure entre les tables qui participent au cluster. Il y a par conséquent une colonne commune qui peut être indexée soit avec un index classique (B-tree) pour le cas du cluster classique, soit avec un algorithme de «hash coding» pour le cas du «cluster HASH». Les Index. Il y a plusieurs types d index selon deux modes d organisation : L organisation B-tree (arbre équilibré) et l organisation Bit-map (carte de bit). Les type clé primaire, unique, non unique et partition sont en général organisés en B-tree. 134

135 Type de segments (fin) Les «Rollback segments». Ils interviennent pour les mécanismes des transactions SQL. Ils permettent de stocker temporairement l information qui est en cours de modification afin de pouvoir la restituer en cas d annulation : ROLLBACK. A partir de la version 9i les «rollback segments» sont automatiquement gérés dans les TABLESPACES de type UNDO. Les segments temporaires. Ils interviennent pour les mécanismes de gestion des tri de données. Ils permettent le stockage temporaire des paquets de données provisoirement triés avant leur fusion afin de retourner le résultat final. Ils sont stockés dans des TABLESPACES de type TEMPORARY. Les segments LOB. Ce type de segment est spécialisé pour le stockage de l information volumineuses (Large OBject) comme par exemple les segments de débordement que l on peut définir pour un IOT ou des colonnes de table de type LOB : CLOB, BLOB, NCLOB, etc. Les segments LOB peuvent être stockés dans des TABLESPACES spécifiques à part. Les «Nested Tables». Ce sont des tables qui sont imbriquées dans une autre par le biais d une colonne. Ce type de segment peut également être stocké dans un TABLESPACE indépendant. 135

136 Clauses de stockage EXTENT Un EXTENT est une unité de stockage qui correspond au regroupement d un ensemble de blocs contigus que l on réserve au sein d un TABLESPACE pour un segment donné. Quand un segment est créé, il y a au minimum un EXTENT qui est alloué dans un TABLESPACE. Lorsque ces EXTENT est plein, un EXTENT supplémentaire est à nouveau alloué. STORAGE C est la clause de stockage (STORAGE) qui définis la taille des EXTENTS qui vont être alloués. Par exemple pour une table classique : SQL> create table nom_table (. ) STORAGE (initial 128K next 128K pctincrease 0 maxextents 100) Les clauses de stockage explicitement définies sont gérées dans le dictionnaire de la base de données. A partir de la version 9i, il n est plus nécessaire de définir de clause de stockage pertinentes si les segments sont stockés dans des TABLESPACES avec le stockage géré localement (localy managed). Ce mode de gestion est beaucoup plus pratique et performant. Il peut être défini en allocation automatique ou en EXTENTS de taille uniforme (voir la syntaxe ci-dessus). Pour des TABLESPACES qui ne sont pas en mode LOCALY MANAGED, le mode de stockage est obligatoirement géré dans le dictionnaire. Si la clause de stockage n est pas indiquée explicitement à la création d un segment, c est la clause de stockage du TABLESPACE qui est appliquée. Par défaut, une définition arbitraire est utilisée si aucune clause de stockage n a été définie pour le TABLESPACE. 136

137 A partir de la version 9i il est recommandé d utiliser principalement des TABLESPACE avec la gestion des EXTENTS en local. 137

138 Ci-dessus, la figure montre en exemple les critères de création d un TABLESPACE depuis la console JAVA d OEM. 138

139 La figure ci-dessus montre en exemple l allocation automatique de EXTENTS d une table (SCOTT.ESSAI) dans un TABLESPACE en EXTENT MANAGEMENT LOCAL automatique avec l outil «Tablespace Manager» d OEM 9i. 139

140 Bloc de base de données La taille minimale d une entrée/sortie Oracle est définie par la taille d un bloc logique. Cette taille est définie à la création de la base et ne peut être modifiée ensuite. A partir de la version 9i, il y a la possibilité de créer de nouveaux TABLESPACES avec une taille de bloc différente de celle qui a été définie initialement. La taille par défaut est définie par le paramètre «db_block_size», elle doit être un multiple de 2048 (2K) et peut varier de 2k vers 32K. Le choix de la taille du bloc dépend du type d application qui utilisera la base Oracle. D une manière générale, les application de type OLTP (On Line Transaction Processing) utilisent des base ayant des blocs de petite taille (4K), à l inverse, les applications de type DSS (Decision Support System Data Warehouse) tire un meilleur parti de bases avec des bloc de grande taille. En pratique, on rencontre beaucoup de bases ayant des blocs de 8K, ce qui est un excellent compromis. 140

141 La diapositive ci-dessus montre la syntaxe de création d un TABLESPACE ayant des blocs de taille différente (16K) de celle qui a été choisie initialement. 141

142 La diapositive ci-dessus montre la liste des principales vues du dictionnaire qui concernent les informations de stockage des segments dans les TABLESPACES. 142

143 Segments de données Ce sont les tables répartie en trois catégories : les tables relationnelles standards, les tables en partitions et les tables organisées en index. Les types des colonnes que l on peut définir sont divisés en quatre classes : Les types scalaires prédéfinis. Voir la liste ci-dessus. les types ensembles : VARRAY (tableau) et NESTED TABLE (table imbriquée) Les types associations. Ce sont des références (REF) vers des objets. Ces types s utilisent avec la norme SQL3 l extension base de données objet relationnelle et les langages orientés objets. Les types spécifiquement définis. Comme précédemment cette catégorie est utilisée pour les langages orientés objets. 143

144 Segments de données (suite) Ci-dessus, l exemple montre la syntaxe complète de création d une table standard. On peut remarquer les options de stockage au niveau du bloc PCTFREE 5%, PCTUSED 90%, INITRANS 3 (dimensions tableau des transactions actives). Les FREELIST GROUPS permettent d éliminer les contentions dans le contexte des base de données en CLUSTER (R.A.C). 144

145 Segments de données (suite) Tables en partitions L organisation des tables en partitions a été conçue pour répartir physiquement les données lorsque l on a affaire à des volumes importants (plusieurs centaines de Gigas octets). Le principe est de découper la table en plusieurs tronçons afin de pouvoir traiter uniquement des parties concernées par les requêtes SQL. Il existe trois types de partition : Les partitions BY RANGE (par intervalle). Le critère de partition est en général un intervalle de temps. La clé de partition peut être une colonne de type numérique où plus couramment de type date. Par exemple, les partitions de la table des ventes concernent chaque mois de l année et les requêtes SQL peuvent interroger chaque partition séparément en filtrant la sélection avec un critère de date. Les partitions BY HASH. Le critère de partition est un algorithme de HASH CODING (basé sur le modulo reste de la division entière). La colonne clé de partition est en général de type numérique. Les partitions BY LIST. Le critère de partition est une liste exhaustive de valeurs. Chaque partition peut être installée sur un TABLESPACE spécifique. Elles peuvent être gérées indépendamment les unes des autres. Lorsque qu une table en partition est interrogée par une requête SELECT, le moteur SQL ne traite que les partitions qui sont concernées par le critère de filtrage si la clé de partition est spécifiée dans la clause WHERE («partition pruning»). La diapositive ci-dessus montre un exemple de création de table en partition par intervalle (RANGE PARTITIONING). La colonne qui est la clé de partition est de type date (DATE_TRANS). Les partitions sont stockée dans un TABLESPACE défini avec des blocs de 16K. 145

146 Table «Index Organized Table» Une table IOT est structurée physiquement comme un index B-tree. C est à dire que les enregistrements de la table sont triés et stockés directement dans l arbre d index. La clé d indexation est l enregistrement lui-même. Si la taille de chaque enregistrement est très grande ou contient des colonnes de type LOB, le volume en excès de celui-ci peut être stocké à part dans un segment de débordement (OVERFLOW). Ce segment peut être installé sur un autre TABLESPACE. Ce type de structure est particulièrement adapté pour des applications de gestion documentaire par exemple. Les tables organisées en index peuvent être créées en partition. La figure ci-dessus montre un exemple de syntaxe de création d une table IOT. 146

147 Opérations d administration des tables Critères de stockage dans les blocs En général les critères de stockage dans les blocs de données doivent être calibrés et définis correctement lors de la conception des applications. Ces critère permettent de limiter les phénomènes de fragmentation qui peuvent engendrer des problèmes de performance. L option PCTFREE doit être en général augmenté lorsque le taux de mise à jour (ordres UPDATE) est important pour une table donnée. PCTUSED prend son importance s il y a beaucoup de suppressions (ordre DELETE) dans la table. Ces critères sont modifiables (voir ci-dessus). Fragmentation Cependant, les phénomènes de fragmentation sont tout à fait normaux et ne génèrent pas systématiquement des perte de performance et de volumétrie. Il est préférable de surveiller les taux de fragmentation régulièrement et de réorganiser les objet seulement quand cela est nécessaire. La réorganisation d une table peut se faire de plusieurs manières, la méthode la plus pratique est d utiliser l instruction MOVE comme le montre la diapositive ci-dessus. Déplacer la table dans un autre TABLESPACE neuf permet de tasser les informations au début des fichiers DATAFILE et de pouvoir libérer les EXTENTS situés à la fin des fichiers du TABLESPACE original. Vidage d une table La commande TRUNCATE permet de vider rapidement une table. Cette instruction n utilise pas de ROLLBACK SEGMENT, il n y a donc pas de retour en arrière possible. Suppression de table La commande DROP TABLE permet d effectuer cette opération. Comme pour la commande TRUNCATE, il est recommandé de bien vérifier que l on est pas en train de supprimer des objets indispensables pour le fonctionnement correct des applications. En version 10g, il existe un garde fou : le RECYCLE BIN (corbeille). Ce dispositif permet de revenir en arrière de la commande DROP TABLE qui a seulement renommé la table dans la corbeille. La commande PURGE permet de vider le RECYCLE BIN (voir ci-dessus). 147

148 Technologie «Flashback» C est une nouvelle fonctionnalité de la version 10g. Cette technologie permet d interroger ou de restaurer des clichés d information du passé sur les segments de données. Son utilisation prend plusieurs formes : «Flashback query». Cette forme permet de consulter des clichés de données du passé qui ont été supprimées ou modifiées. La diapositive ci-dessus montre un exemple de requête qui consulte les informations dans une table par rapport à un point déterminé dans le temps (TIME STAMP). «Flashback table». Cette forme permet de restaurer une version des données du passé dans une table. La diapositive ci-dessus montre un exemple de restauration des données dans une table par rapport à un point déterminé dans le temps. Pour pouvoir effectuer ce genre d opération, l option «ROW MOVEMENT» doit être activée sur la table. 148

149 Technologie «Flashback» (fin) «Flashback drop». Cette forme permet de récupérer une table depuis le RECYCLE BIN (corbeille). Lorsqu une table est supprimée avec l instruction DROP TABLE, celle-ci est renommée mais n est pas détruite définitivement de la base de données. Le contenu du RECYCLE BIN peut être interrogé via les vues : USER_RECYCLEBIN et DBA_RECYCLEBIN. La commande FLASHBACK exécute la restauration de la table comme le montre la diapositive ci-dessus. 149

150 Segments de d index Il existe deux types d index dans Oracle : Les B-tree et les index BITMAPS. Les B-tree sont structurés physiquement en arbre équilibré (Balanced Tree). C est à dire que les clés sont triées et stockées dans les feuilles de l index, le parcours dans l arbre et à sens unique, des la racine vers les feuilles, il suit le principe de recherche dans un dictionnaire. Une grande majorité d applications utilisent ce type d index. Certains aménagement sont possibles comme la création en partitions ou le stockage des clés dans les feuilles en ordre inversé. Cette caractéristique permet de réduire les conflit d accès simultanés pour les base de données en CLUSTER (R.A.C). Les index BITMAP sont spécifiquement appropriés aux applications décisionnelles (Data Warehouse). Ce type d index est pertinent pour l indexation de colonnes de table à faible cardinalité (peut de valeurs distinctes). Son encombrement physique est réduit et ce type d index peut être parcouru dans n importe quel sens. Les index BITMAPS peuvent également être organisés en partition. 150

151 Options des index Un index peut être construit sur plusieurs colonnes de types hétérogènes d une même table. On parle alors d index concaténé. Un index peut être déclaré UNIQUE ou NON UNIQUE. Par définition, la contrainte de clé primaire s appuie automatiquement sur un index UNIQUE. Dans le cas de colonnes qui ne sont pas une clé primaire, ayant une contrainte d unicité (clé secondaire), cette dernière doit s appuyer sur un index UNIQUE créé explicitement. Critères de stockage Comme pour les tables, la fragmentation des index peut être contrôlée par des options de stockage : PCTFREE a pour objet de limiter les SPLITS (éclatements) des feuilles de l index lors de la réorganisation implicite sur l insertion de nouvelles clés. INITRANS, MAXTRANS permettent de dimensionner le tableau des transactions actives simultanément sur un même bloc d index. LOGGING, NOLOGGING active, désactive l écriture dans le REDOLOG pour certaines opérations sur les index (réorganisation, REBUILD, etc.). L audit des index peut s effectuer via les vues décrites ci-dessus et également avec ALL_INDEXES, ALL_IND_COLUMNS, USER_INDEXES, USER_IND_COLUMNS. 151

152 Syntaxe de création Ci-dessus, deux exemples de création d index. Le premier montre la création d un index unique concaténé sur les colonnes EMPNO et ENAME de la table SCOTT.EMP. Le deuxième exemple concerne la création d un index GLOBAL en partition par intervalle. Un index de type GLOBAL est un index organisé en partition où chacune d elle peut adresser n importe quelle clé de la table concernée. A l inverse un index est dit LOCAL lorsque chacune de ses partitions contient des clés qui adressent uniquement les clés contenues dans la partition correspondante de la table. Le critère de partition est identique pour l index et pour la table. Consulter à ce sujet le chapitre sur les partitions du manuel «Concepts» de la documentation. 152

153 Création d un index BITMAP La syntaxe est montrée sur l exemple ci-dessus. Pour obtenir quelque chose de performant, la colonne d index ne doit pas contenir beaucoup de valeurs distinctes. La clause PARALLEL permet l optimisation de parcours séquentiel de l index sur les machines multi-processeurs. Administration des index La commande ANALYZE de l exemple ci-dessus permet de contrôler s il est nécessaire de réorganiser l index en cas de corruption. Lors de la réorganisation avec l instruction REBUILD, il est possible de déplacer l index en indiquant le TABLESPACE de destination. 153

154 Types de contraintes d intégrité NULL, NOT NULL. Ces contraintes indique si la valeur d une colonne doit être obligatoirement renseignée ou pas lors de l insertion. Par défaut, les colonnes acceptent la valeur NULL. UNIQUE. La valeur renseignée sur la colonne ou un groupe de colonnes concaténées doit être unique pour toute la table. Cette contrainte doit est renforcée avec la présence d un index unique. PRIMARY KEY. La clé primaire est l identifiant unique pour chaque TUPLE (enregistrement) de la table. Lorsqu elle est créée, la contrainte est automatiquement renforcée par un index unique. La clé primaire peut être concaténée sur plusieurs colonnes et est de type NOT NULL. FOREIGN KEY. La clé étrangère est la ou les colonnes qui font référence à la clé primaire d une autre table. Cette contrainte doit être normalement renforcée par un index. CHECK. Cette contrainte est une condition qui doit être vérifiée pour chaque enregistrement inséré. Exemple : La contrainte VERIF_SAL contrôle que la valeur de la colonne SAL de la table est inférieure à

155 Une bonne stratégie de sauvegarde/restauration dépend souvent des choix et de l analyse des problèmes qui peuvent se poser sur un système d information. Dans bien des cas, la politique de sauvegarde peut s avérer inopérante car elle est bâtie sur des postulats qui sont faux. Une panne survient souvent là où on ne l attend pas et ne se manifeste pas dans les mêmes circonstances et sous la même forme que pendant les scénarios de simulation qui ont servis à élaborer la stratégie de sauvegarde/restauration. Les techniques de sauvegarde divergent en fonction des types de système d information à sauvegarder : «Operating system» copie de fichiers (cp, copy) duplication de disques (ufsdump, dd) copie de système de fichiers (tar, cpio, xcopy) Bases de données extractions logiques (export, sqlplus) duplication physique avec arrêt du SGBD (problèmes de disponibilité) copie physique des fichiers sans arrêt de l exploitation sauvegarde des blocs de la base contenant des informations Les bases de données ont d autres contraintes d exploitation : les problèmes de réorganisation engendrent des risques d indisponibilité les besoins de garantir la consistance des données Le modèle transactionnel part d un état consistant vers un autre état consistant, il n y pas d état intermédiaire. Il faut donc un système de sauvegarde de base de données différent des systèmes classiques et capable de répondre aux exigences d exploitation des SGBD. 155

156 Une base Oracle fonctionne par défaut en mode NOARCHIVELOG sauf si à sa création le mode ARCHIVELOG a été définis explicitement. En mode NOARCHIVELOG il n est pas recommandé et supporté par Oracle de prendre une sauvegarde des fichiers de la base si l instance est ouverte et ce même s il n y a aucune session active pendant la copie des fichiers. Oracle ne garanti pas le redémarrage d une base restaurée qui avait été sauvegardée à chaud en mode NOARCHIVELOG. En d autres termes, on peut dire qu Oracle ne propose pas de solution particulière en matière de sauvegarde/restauration si la base fonctionne en NOARCHIVELOG. La stratégie de sauvegarde de la base est laissée au niveau du système d exploitation. Dans ce mode, seules les dernières transactions actives en mémoire au moment d un crash de l instance seront récupérées automatiquement (instance recovery) au redémarrage de celle-ci. En cas de perte d un composant de la base (DATAFILE, REDOLOG, Controlfile), une sauvegarde complète doit être restaurée et toutes les transactions qui ont été passées audelà de cette sauvegarde seront perdues. 156 V1.0

157 Le mode ARCHIVELOG est la réelle solution d Oracle en matière de stratégie de sauvegarde/ restauration lorsque les enjeux du système d information sont importants. Pour commuter le mode de fonctionnement en ARCHIVELOG procéder comme suit : stopper l instance proprement : "shutdown" normal ou "immediate " (surtout pas ABORT) monter l instance : SQL> STARTUP MOUNT entrer la commande DDL : SQL> ALTER DATABASE ARCHIVELOG arrêter à nouveau l instance prendre une sauvegarde complète de tous les fichiers de la base : DATAFILES, REDOLOGS, CONTROLFILE modifier le INIT.ORA, valider les paramètres : log_archive_dest_1 répertoire de destination des fichiers Archivelogs log_archive_format format du nom de fichier des fichiers Archivelogs log_archive_start = true activation de l archivage automatique des REDOLOGS au démarrage de l instance L intégralité des données et des transactions actives seront récupérées dans la majorité des cas de figures de panne sur une base Oracle qui fonctionne en mode ARCHIVELOG. Ce mode de fonctionnement fourni d autre avantages : Sauvegarde de la base sans arrêter l exploitation Sauvegardes entrelacées avec l exploitation Restauration en ligne de la plupart de Tablespaces (sauf le Tablespace SYSTEM) Une stratégie de sauvegarde/restauration bien élaborée peut permettre des temps de restauration très courts gestion des cas limites (disaster recovery) 157

158 Le mode ARCHIVELOG assure la sauvegarde permanente des fichiers REDOLOGS qui tracent les transactions actives. Lorsque le système commute sur le fichier REDOLOG suivant, le fichier REDOLOG précédent est automatiquement copié dans le répertoire destiné aux fichiers ARCHIVELOGS. Oracle conserve ainsi la continuité des fichiers journaux des transactions et par conséquent est capable de refaire ou rejouer les opérations qui ont modifié les données de la base. Le mode ARCHIVELOG garanti qu un fichier REDOLOG ne sera pas écrasé tant qu il n aura pas été archivé par Oracle. Si l on oublie de purger le répertoire qui contient les fichiers des REDOLOGS archivés, le disque risque d être saturé et le mécanisme ARCHIVELOG sera bloqué. Pour débloquer cette situation il suffit de sauvegarder quelques fichiers «Archivelogs» et de les supprimer du répertoire. Cette fonction est automatiquement prise en charge avec l outil «Recovery Manager». 158

159 Lorsqu une corruption se produit sur un fichier de la base de données il est nécessaire de le restaurer. Le fichier de sauvegarde restauré est en retard avec l état consistant de la base. Si l on tente de remettre l élément restauré en ligne, Oracle indique par un message d erreur (ORA 1113) qu il faut exécuter un RECOVER du fichier («media recovery») pour le remettre en phase avec les autres. Cette opération consiste à appliquer les fichiers ARCHIVELOGS qui contiennent les données des transactions qui ont été produites après la sauvegarde du fichier restauré. Pour exécuter cette opération il faut entrer la commande DDL : «RECOVER», Oracle proposera automatiquement l emplacement et le nom des fichiers ARCHIVELOGS nécessaires pour effectuer le RECOVERY. Lorsque tous les fichiers d archives ont été appliqués, Oracle affiche le message : «media recovery complete». Il suffit alors de remettre l élément restauré en ligne. 159

160 «Recovery Manager» est la fonction de sauvegarde/restauration du noyau Oracle. Cet outil permet de gérer et d automatiser les procédures de sauvegarde et de restauration par un langage script qui lui est propre. Cela permet de réduire les risques d erreur comme, par exemple, la restauration de la mauvaise sauvegarde, l oubli de sauvegarder un TABLESPACE qui vient d être ajouter au système SGBD. «Recovery Manager» facilite la mise en œuvre du mode ARCHIVELOG, il peut être également utilisé avec des instances qui fonctionnent en mode NOARCHIVELOG. RMAN collabore avec la plupart des logiciels de sauvegarde du marché comme Netbackup par une API (Application Program Interface) fournie par l éditeur du logiciel de sauvegarde. La liste des éditeurs de logiciel de sauvegardes compatibles avec RMAN est fournie sur (voir «Oracle Backup Solutions Program»). Les caractéristiques de Recovery Manager sont : La compression des sauvegardes des DATAFILES, ne prend pas les blocs inutilisés L exécution des sauvegardes incrémentielles en mode différentiel et/ou cumulatif pour optimiser les volumes et les temps de sauvegarde. La génération de fichiers de sauvegarde des DATAFILES ou des ARCHIVELOGS sur bande magnétique : "Backup Sets" La copie (duplication) de DATAFILE sur d autres disques. La détection des corruptions dans la base pendant la sauvegarde L utilisation d un référentiel des sauvegardes dans une base Oracle appelé «Recovery Catalog» (RCVCAT) La conservation éventuelle des scripts les plus utilisés dans le «Recovery Catalog» La production de rapports, de diagnostics et de comptes rendus de sauvegarde La sauvegarde au niveau des blocs de la base offre les avantages suivants : Seul les blocs qui ont été utilisés (cf "incarnation number") sont sauvegardés ("Backup Set Compression") Permet les "backup" différentiels ou cumulatifs à un niveau très fin Un Mécanisme de détection dynamique des blocs incohérents ("split" ou "fractured blocks") permet de ne pas saturer les "REDOLOGS" pendant les «Backup ONLINE" car les ordres "BEGIN/END BACKUP" ne sont plus nécessaires. Les fichiers de sauvegarde «Backup set» ne sont donc pas des "DATAFILES" 160

161 A la différence des stratégies de sauvegardes que proposait Oracle dans les versions précédentes, ce sont des processus Oracle (serveurs oracle «shadow» sous Unix) qui exécutent les sessions de sauvegardes/ restaurations des fichiers DATAFILES et ARCHIVELOGS. Lorsque «Recovery Manager» est couplé avec un logiciel tiers de sauvegarde sur bande (comme Netbackup, Legato Networker, Omniback ) les processus Oracle des sessions de sauvegarde passent les blocs à sauvegarder directement aux processus du logiciel tiers par l intermédiaire d une couche logicielle : MML (Media Management Layer). La partie dans le cadre bleu de la figure ci-dessus ne peut être mise en œuvre qu avec un outil tiers. S il n y a pas de logiciel de sauvegarde, «Recovery Manager» est capable de produire les «Backupsets" sous forme de fichiers sur les disques. Le «recovery catalog» est facultatif, il doit être installé dans une base Oracle de version identique de préférence. C est le référentiel des opérations de sauvegardes des bases cibles («Target Database»), il est indispensable pour des environnements de production à haute disponibilité de type «business» ou «mission critical». La session «Recovery Manager» peut être opérée en mode ligne (prompt RMAN>), en mode batch sous Unix lancé par un logiciel tiers comme Netbackup ou dans l environnement graphique (GUI) d Oracle Enterprise Manager (OEM ->Backup Manager). 161

162 La gestion des opérations de sauvegarde et restauration s effectue avec un langage script de commandes propres à RMAN. Ces commandes sont interprétées et exécutées par les procédures des "packages" PL/SQL du moteur Oracle. Il y a plusieurs types de commandes RMAN : Les commandes autonomes (Stand-Alone) qui servent principalement à l administration du catalogue. catalog, create catalog, drop catalog, upgrade catalog : administration du référentiel create script, delete script, replace script : gestion des scripts dans le catalogue. change, crosscheck, delete expired backup : synchronisation du catalogue avec le référentiel des sauvegardes de l outil tiers ou avec le système d exploitation. list, report : liste des composants des bases cibles, états et diagnostics des sauvegardes/ restaurations à opérer. Les commandes de travail (Job) qui exécutent les tâches de sauvegarde et de restauration. La majorité des ces ordres seront exécutés dans un bloc run délimité par des accolades : run { }. allocate channel : ouverture d un canal de sauvegarde/restauration. C est cette commande qui provoque l activation d un processus serveur Oracle. switch : effectue la commutation d emplacement de fichiers DATAFILES. backup, copy, duplicate : commandes de sauvegarde proprement dites. La commande copy est obsolète en 10g. restore, recover : commandes de restauration et de restitution des transactions. Les exceptions sont des commandes qui peuvent être appelées à l intérieur ou à l extérieur d un : exécution de script RMAN sous forme de fichiers host, send : appel d une commande du système d exploitation, envoi de directives au logiciel tiers. startup, shutdown : lancement et arrêt de la base cible dans la session RMAN. sql : envoi d ordres SQL spécifiques au sein d une session RMAN. 162

163 La session Recovery Manager est activée par la commande système rman. Si l on utilise une base "catalog", il y aura deux connexions simultanées : celle vers la base cible et celle vers la base catalogue. L une des deux connexion peut être directe sans utiliser SQL*Net : $ rman target sys/secret rcvcat rman/rman@refoem Remarque : REFOEM est un alias SQL*Net (chaîne de connexion réseau) et non un ORACLE_SID dans ce contexte. La connexion peut également s effectuer dans la session RMAN : $ rman RMAN> connect target sys/secret ; RMAN> connect catalog rman/rman@refoem ; Lorsque Recovery Manager collabore avec un outil tiers de sauvegarde comme Netbackup ou Tivoli la session RMAN peut être activée en mode batch par un script shell avec l argument cmdfile : $ cat script_rman.ksh #!/bin/ksh rman cmdfile script_rman.rcv $ cat script_rman.rcv connect target sys/secret ; connect catalog rman/rman@refoem ; run { execute script sauvegarde_complete ; } 163

164 Recovery Manager produit trois types de fichiers de sauvegarde : "Backup Sets" de DATAFILES Ce sont des collections de blocs extraits des fichiers DATAFILES de la base cible. Ils peuvent contenir la sauvegarde complète du fichier de contrôle si la clause "include current controlfile" ou "current controlfile" de la commande "backup" a été ajoutée. La sauvegarde du fichier de contrôle se trouve alors au début du "Backup Set". La sauvegarde des blocs du Tablespace SYSTEM provoque automatiquement celle du fichier de contrôle dans le "Backup Set". Les "Backup Sets" de DATAFILES ne sont pas des fichiers de base directement utilisables par le moteur Oracle. Lorsqu ils sont restaurés, RMAN recrée le fichier DATAFILE vide puis y replace les blocs contenus dans le "Backup Set". "Backup Sets" d ARCHIVELOGS Ils regroupent un certain nombre de fichiers ARCHIVELOGS classés en ordre séquentiel croissant (les ARCHIVELOGS sont numérotés avec le numéro de séquence de REDOLOG). Les "Backup Sets" d ARCHIVELOGS ne peuvent pas contenir de blocs provenant de fichiers DATAFILES et vice versa. La restauration replace les fichiers ARCHIVELOG dans le répertoire pointé par le paramètre log_archive_dest. Les fichiers ARCHIVELOG peuvent être supprimés automatiquement de ce répertoire après la sauvegarde avec la clause "delete input" de l ordre "backup archivelog". "Images copies" Ce sont les copies intégrales des DATAFILES ou des ARCHIVELOGS sur d autres disques de la machine qui héberge la base cible. Les copies de fichiers DATAFILES sont très efficaces pour effectuer des restaurations rapides puisqu il n y a pas de fichier à restaurer depuis une bande magnétique. La commande " switch " de Recovery Manager permet de commuter instantanément sur la copie du fichier DATAFILE et il n y a plus que l opération de restitution (RECOVER) à réaliser pour pouvoir remettre le fichier en ligne. Cette opération sera d autant plus courte que la copie du fichier est récente. 164

165 Sauvegarde en ligne d un TABLESPACE Ce scénario suppose que le logiciel gestionnaire de bande magnétique fonctionne avec RMAN. La base fonctionne en mode ARCHIVELOG. Le script défini le type de périphérique par défaut qui sera utilisé pour les sauvegardes et passe les paramètres spécifiques au gestionnaire de média. Les périphériques de type disque sont également définis dans l exemple ci-dessous : configure default device type to sbt; configure channel device type sbt parms '<paramètres gestionnaire de média>'; # nombre de processus serveurs pour les canaux de type disque configure device type disk parallelism 2; configure channel device type disk format '/backup/ora_df%t_s%s_s%p'; configure controlfile autobackup format for device type disk to '/backup/%f'; La sauvegarde en ligne utilise le canal par défaut de type bande magnétique. run { backup tablespace tbs1; } 165

166 Sauvegarde en ligne incrémentielle niveau 0 C est le début du cycle de sauvegardes. La fenêtre de rétention est définie sur un mois (30 jours). Vous pouvez utiliser la commande DELETE OBSOLETE pour supprimer les sauvegardes qui ont été marquées comme obsolètes par les opérations de sauvegarde. Important : Vous devez noter l identifiant affiché par la sortie de RMAN si vous ne comptez pas utiliser de CATALOG de récupération. Cet identifiant est nécessaire pour les procédures de restauration du fichier de contrôle et les «disaster recovery». configure retention policy to recovery window of 30 days; # Activation de la sauvegarde automatique du CONTROLFILE. configure controlfile autobackup on; # Activation des sauveagrdes optimisées. configure backup optimization on; run { backup incremental level 0 database filesperset 4; backup archivelog all; delete archivelog until time 'sysdate-7'; } 166

167 Restauration en ligne d un TABLESPACE Ce type de restauration suppose que seuls les fichiers qui constituent le TABLESPACE sont endommagés. L opération s effectue base ouverte. La diapositive montre les instructions essentielles pour effectuer la restitution en ligne du TABLESPACE. Ci-dessous le script contient en commentaire des exemples de syntaxe ou la destination des fichiers restaurés est différente. run { sql 'alter tablespace tbs_1 offline'; } # si vous désirez restaurer les fichiers à un autre emplacement, # supprimez les caractères # de mise en commentaire. # set newname for datafile 5 to '/newdirectory/new_filename_for_5.f'; # set newname for datafile 6 to '/newdirectory/new_filename_for_6.f'; # set newname for datafile 7 to '/newdirectory/new_filename_for_7.f'; restore tablespace tbs_1; # switch datafile all; recover tablespace tbs_5; sql 'alter tablespace tbs_5 online'; 167

168 Restauration en ligne d un DATAFILE Ce scénario suppose que le DATAFILE numéro 5 est endommagé. Les autres fichiers sont intacts et l opération se déroule base ouverte. run { sql 'alter database datafile 5 offline'; } # si vous désirez restaurer le fichier à un autre emplacement, # supprimez les caractères # de mise en commentaire. # set newname for datafile 5 to '/newdirectory/new_filename.f'; restore datafile 5; # switch datafile all; recover datafile 5; sql 'alter database datafile 5 online'; 168

169 Restauration standard à froid Ce cas de figure suppose que ce sont les fichiers DATAFILE du TABLESPACE SYSTEM qui sont endommagés. Les autres fichiers sont intacts, la restauration se fait base fermée. $ rman target / catalog rman/rman@rcvcat RMAN> shutdown abort; RMAN> startup mount; run { restore database; recover database; alter database open; } 169

170 170