Introduction à l Administration d Oracle

Transcription

1 Université de Manouba École Supérieure d Économie Numérique Département des Technologies des Systèmes d Information Introduction à l Administration d Oracle Document version 1.5 Dr. Mohamed Anis BACH TOBJI

2 Table des matières CHAPITRE 1 INTRODUCTION Oracle : Vue d ensemble Oracle Database Interaction avec Oracle Database... 8 CHAPITRE 2 ARCHITECTURE D ORACLE DATABASE La base de données Les fichiers de contrôle Les fichiers de données Les fichiers de journalisation Les archives des fichiers de journalisation Le fichier de paramètres Le fichier de mot de passe Autres fichiers L instance Les structures mémoires Les processus Le schéma Le dictionnaire de données Les vues statiques Les vues dynamiques de performance Fonctionnement d Oracle Pour exécuter une requête SELECT Pour exécuter une requête UPDATE Lors d un COMMIT Lors d un ROLLBACK CHAPITRE 3 DEMARRAGE/ARRET DE LA BASE DE DONNEES ET GESTION DE L INSTANCE Démarrage et Arrêt de la base de données Démarrage de la base de données Arrêt de la base de données Gestion de l instance... 31

3 3.2.1 Paramètres dynamiques et paramètres statiques Instancier les paramètres via SQL Exporter un fichier de paramètres CHAPITRE 4 GESTION DES TABLESPACES Tablespaces : types et conseils d utilisation Les tablespaces permanents Création des tablespaces permanents Extension des tablespaces permanents Basculer entre les modes OFFLINE/ONLINE Basculer entre les modes READ ONLY/READ WRITE Basculer entre les modes LOGGING/NOLOGGING Basculer entre les modes FORCE LOGGING/NO FORCE LOGGING Renommer un tablespace Renommer/déplacer un fichier de données Suppression d un tablespace Gestion de l espace à l intérieur des tablespaces Les tablespaces gérés par le dictionnaire de données Les tablespaces gérés localement Informations sur les tablespaces CHAPITRE 5 GESTION DES UTILISATEURS L objet USER La connexion Création d un utilisateur Modification d un utilisateur Suppression d un utilisateur Informations sur les utilisateurs L objet PROFILE Les privilèges Les privilèges système Les privilèges objet L objet ROLE Création et modification d un rôle Attribuer/retirer un privilège à un rôle Attribuer/retirer un rôle à un utilisateur Activer/désactiver un rôle CHAPITRE 6 CREATION D UNE NOUVELLE BASE DE DONNEES... 53

4 6.1 Créer les répertoires sur le disque : La norme OFA La création des répertoires Préparer un fichier de paramètres Créer le service associé à l instance Lancer SQL*PLUS Créer le fichier de paramètres serveur Démarrer l instance Créer la base de données Finalisation de la création du dictionnaire de données CHAPITRE 7 GESTION DES FICHIERS DE CONTROLE ET DE JOURNALISATION Gestion des fichiers de contrôle Création initiale des fichiers de contrôle Création de copies additionnelles, renommage, et déplacement des fichiers de contrôle S informer sur les fichiers de contrôle Gestion des fichiers de journalisation Informations sur les fichiers journaux Définir le nombre et les tailles des fichiers de journalisation Gestion des fichiers journaux CHAPITRE 8 GESTION DES INFORMATIONS D ANNULATION Segment d annulation : vue d ensemble Utilité des informations d annulation Gestion des informations d annulation Le segment d annulation SYSTEM Fonctionnement d un segment d annulation La durée de rétention des informations d annulation La gestion automatique des informations d annulation La mise en œuvre Fonctionnement d un tablespace d annulation Création d un tablespace d annulation Changement du tablespace d annulation actif Modification et suppression d un tablespace d annulation CHAPITRE 9 GESTION DES TABLES ET DES INDEX... 73

5 9.1 La gestion des tables Organisation du stockage dans les blocs Le ROWID Chainage et migration Spécifier le stockage d une table CHAPITRE 10 SAUVEGARDE ET RESTAURATION Archivage des fichiers de journalisation Les stratégies de sauvegarde Archivage des fichiers journaux... Erreur! Signet non défini. BIBLIOGRAPHIE... 86

6 Chapitre 1 Introduction Dans ce cours, nous essayerons d illustrer les notions de base de l administration d un serveur de base de données à travers la technologie Oracle. Le choix se porte sur Oracle parmi une variété d éditeurs (IBM, Microsoft etc.) pour diverses raisons : 1- Il s agit du leader du marché des SGBD. 2- La documentation est abondante sur le Web. 3- En Tunisie, il existe un représentant officiel de la firme (ORADIST), qui aide les académiques à travers la documentation et les formations des universitaires. Pour une maitrise parfaite de l administration d un serveur de bases de données, il faut passer par trois étapes, à savoir l assimilation de l architecture d un serveur BD, l administration du serveur, et finalement l optimisation du serveur. Seul le troisième volet ne sera pas évoqué dans ce cours. 1.1 Oracle : Vue d ensemble Oracle Corporation est sans conteste le leader du marché des Systèmes de Gestion de Base de Données Relationnelles, disposant de la plus grande part de marché (année 2013). Le produit fondamental commercialisé par Oracle est «Oracle Database», cela n empêche que la firme américaine commercialise d autres types de produits intégrés. La famille de produits Oracle est la suivante : - Oracle Database - Oracle Developer Suite - Oracle Application Server - Oracle Applications - Oracle Collaboration Suite - Oracle Services Brièvement, Oracle Database est le SGBD qui permet de stocker, gérer, administrer et manipuler des données d un grand volume tout en assurant performance, sécurité et accès concurrentiel. Les fonctions décrites ci-dessus ne sont naturellement pas exhaustives, mais plutôt basiques et Oracle ne cesse d innover en ce sens. La version Database la plus évoluée étant Oracle 12c (parue fin 2013). Oracle Developer Suite est un ensemble d outils de conception (Developer Designer), développement (Developer Forms, JDeveloper), édition d états (Developer Reports, Discoverer), implémentation de Data Warehouse (Warehouse Builder) et de déploiement d applications basés Web. Oracle Application Server est utilisé pour le déploiement d applications Web développés entre autres par Oracle Developer Suite. Ce produit assure la fiabilité et l efficacité d utilisation des applications pour des milliers d utilisateurs distants. Oracle

7 Introduction 7 Applications est un ensemble de modules standard prédéveloppés et paramétrables qui gèrent le personnel, la finance, la production, la vente, les achats, et autres fonctions d entreprises de différents secteurs. À noter que ces modules utilisent naturellement Oracle Database, Developer Suite et Application Server. Oracle Collaboration Suite est un système exhaustif qui intègre des outils puissants de collaboration et de communication allant de la messagerie électronique jusqu aux systèmes de conférences Web en passant par la télécopie, la messagerie instantanée, le calendrier partagé ainsi que la gestion de documents. Oracle Collaboration Suite utilise aussi Oracle Database, Oracle Developer Suite et Oracle Application Server. Oracle Services offre une plateforme complète de support technique aux utilisateurs pour qu ils puissent choisir, installer, et configurer leurs outils Oracle de la meilleure manière possible relativement à leurs besoins spécifiques. Cette vue d ensemble nous permet de mieux nous situer par rapport à l ensemble des produits d Oracle. En effet, nous essayerons à travers ce polycopié d introduire les bases de l administration d un SGBD Oracle, ce qui nous place sur le produit «Database» parmi la panoplie des produits listés ci-dessus. Architecture basique et minimale d Oracle Database, gestion de la mémoire, gestion du stockage physique et gestion de la sécurité seront donc les principaux axes de ce document. 1.2 Oracle Database C est le produit principal d Oracle, soit le Système de Gestion de Bases de Données Relationnelles qui est disponible sur plusieurs plateformes telles que Windows, Linux et Unix. Depuis 1977, année de création de la firme Oracle (jadis appelée SDL pour Software Development Laboratories), le produit Database est passé de la version 1 à la version 11g en 30 ans. Dans ce polycopié, nous nous basons sur des documents (voir bibliographie) qui traitent surtout les versions 10g et 9i. Il est à noter qu Oracle Database est disponible sous différentes éditions, les voici : - Enterprise Edition : inclut toutes les fonctionnalités d Oracle Database, en standard ou en option, et gère des données extrêmement volumineuses. - Standard Edition : inclut les fonctionnalités de base, mais ne permet pas d exploiter certaines options avancées. Cette édition est d ailleurs destinée pour des serveurs avec une capacité maximale de quatre processeurs. - Standard Edition One : pratiquement identique à l édition standard mais limité à des serveurs biprocesseurs. - Personal Edition : disponible uniquement sur Windows, destinée aux développeurs pour une utilisation mono-utilisateur. - Express Edition : complètement gratuite, destinée pour des machines monoprocesseurs et spécialement pour les petites entreprises, voire les institutions à but académique. - Lite Edition : inclut les fonctionnalités requises pour le développement et le déploiement

8 Introduction 8 d applications et de base de données mobiles. Cela étant dit, les notions de base étalées dans ce polycopié concernent toutes les éditions voire même les dernières versions. D ailleurs nous ne manquerons pas de vous signaler une nouveauté particulière qui correspond à la version 10g. 1.3 Interaction avec Oracle Database Le moyen le plus basique d interagir avec les objets d une base de données Oracle, tels que les tables, les séquences, les index, les utilisateurs, les vues etc., est le langage SQL servant à définir (LDD), manipuler (LMD) et contrôler (LCD) les données. Un utilisateur peut formuler des requêtes SQL via : - SQL*Plus qui est un éditeur permettant la saisie et l affichage des résultats de requêtes SQL. Naturellement, pour accéder aux objets de la base de données, il faut que l utilisateur ait un login et un mot de passe et qu il connaisse la chaîne de connexion (connection string) de la base de données si elle est distante, sachant que dans ce cas, l éditeur SQL*Plus est juste installé sur un poste client. - isqlplus est aussi un éditeur de saisie de requêtes SQL. A la différence de SQL*Plus, c est un éditeur Web et donc au poste client (celui de l utilisateur), il suffit d avoir un navigateur Web ainsi que l URL du serveur hébergeant la base de données, avec bien sur un login et un mot de passe, pour que la connexion soit réussie. Il existe d autres outils d administration et de développement. Oracle Discoverer par exemple est un outil graphique qui permet à l utilisateur de sélectionner les tables qu il veut interroger en cliquant dessus. Oracle Forms et Oracle Reports permettent respectivement de développer des applications Web et d éditer des états basés sur les données d Oracle Database. OEM (Oracle Enterprise Manager) quant à lui est une interface graphique qui permet l administration et la configuration d Oracle Database. Lorsque l utilisateur change la valeur d un paramètre dans l interface, une requête SQL est générée et est envoyée à la base de données. OEM est disponible en version Web et donc utilisable à partir de n importe quel poste client connecté au serveur base de données (à condition que le processus OEM soit lancé sur le serveur, ou en version client (EM Client) installable sur la machine client et offre les même possibilités que la version Web. Le langage 1 PL/SQL permet aussi l interaction avec Oracle Database. C est un langage procédural extension du langage SQL qui permet non seulement d utiliser des structures conditionnelles et itératives et de traiter les exceptions, mais aussi de créer des fonctions et procédures personnalisées et de développer des packages et des déclencheurs. 1 Il faut bien faire la différence entre langage (tel que SQL et PL/SQL) et outil tel qu un éditeur ou autre nous permettant soit de saisir du code, soit de manipuler directement et graphiquement les objets base de données (OEM, SQL*Plus, isqlplus etc.).

9 Chapitre 2 Architecture d Oracle Database Un serveur de base de données Oracle inclut deux composantes importantes, l instance et la base de données. La base de données est l ensemble de fichiers qui contiennent entre autres les données, les informations de la base ainsi que le journal de modification des données. L instance quant à elle est un ensemble de processus et d emplacements mémoire qui facilitent l accès et la manipulation de la base de données. 2.1 La base de données La base de données est constituée d un ensemble de fichiers physiques situés sur les disques durs du serveur hébergeant la base. La Figure 1 montre les différents types de ces fichiers, il est à noter que les archives des fichiers de journalisation, le fichier de paramètres ainsi que le fichier des mots de passe ne font pas partie prenante de la base de données, mais y sont étroitement reliés. Base de Données Fichiers de données Fichiers de contrôle Groupes des fichiers de journalisation Fichier de paramètres Archives des fichiers de journalisation Fichier de mot de passe Les fichiers de contrôle Figure 1 : Les fichiers physiques d'une base de données Ils contiennent des informations de contrôle sur la base de données tel que : - Le nom de la base de données. - Les noms, les chemins et les tailles des fichiers de données et de journalisation. - Les informations de restauration de la base de données en cas de panne. Le fichier de contrôle est primordial pour que l instance soit lancée correctement. En effet, cette dernière y lit les chemins de fichiers de données, ainsi que ceux des fichiers de journalisation (et d autres informations nécessaires au lancement). Si ce dernier est endommagé, la base de données ne peut pas être chargée même si les autres fichiers physiques sont intacts. C est pour

10 10 cela qu il est possible (et recommandé) de multiplexer le fichier de contrôle sur des endroits différents du disque dur. Il est à noter que les informations des fichiers de contrôle peuvent être examinées à partir de la vue V$CONTROLFILE Les fichiers de données Ce sont les fichiers physiques qui stockent les données de la base sous un format spécial Oracle. Les fichiers de données sont logiquement regroupés en structures logiques appelées tablespaces. Une base de données comporte au moins deux fichiers de données relatifs à deux tablespaces différents réservés par Oracle (SYSTEM et SYSAUX, ce dernier étant apparu en Oracle 10g). Ces deux tablespaces ne doivent logiquement contenir aucune donnée applicative. A titre indicatif, le tablespace SYSTEM inclut le dictionnaire de données ainsi que le code PL/SQL (fonctions, procédures etc.). En revanche, une organisation parmi tant d autres consiste à réunir les tables qui portent sur le même contexte (comptabilité, gestion de stock, gestion de personnel etc.) dans un même tablespace ; le résultat est d avoir des données regroupés par application/contexte. A noter que les vues DBA_TABLESPACES et DBA_DATA_FILES incluent toutes les informations respectivement relatives aux tablespaces et aux fichiers de données de la base. La requête suivante liste les fichiers de données utilisés dans la base triés par les tablespaces : REQ 1 SELECT tablespace_name, file_name FROM DBA_DATA_FILES ORDER BY tablespace_name; Un fichier de données est un ensemble de blocs d une taille donnée (4 Ko, 8Ko, 16 Ko etc.). Le bloc de données est la petite unité d E/S utilisée par Oracle et un fichier de données a forcément une taille qui est multiple de la taille du bloc. Logiquement, un tablespace (étalé sur un ou plusieurs fichiers de données), est un ensemble de segments. Un segment est l espace occupé par un objet base de données dans un tablespace, il y en a quatre types : - Segment de table : espace occupé par une table - Segment d index : espace occupé par un index - Segment d annulation : espace temporaire utilisé pour stocker les données nécessaires à l annulation d une transaction, ainsi qu à la lecture cohérente des données. - Segment temporaire : espace temporaire ou sont stockées des données temporaires utilisées lors d un tri, d une jointure, lors de la création d un index etc. En effet, les principaux types d objets appartenant à un utilisateur (constituant un schéma) sont les tables, les index, les vues, les synonymes, les séquences et les programmes PL/SQL.

11 11 Parmi ces différents types d objets, seuls les tables et les index 1 consomment de l espace disque en dehors du dictionnaire de données. Plus précisément, ils occupent de l espace mémoire sur les fichiers de données. Les autres types d objets n ont qu une définition stockée dans le dictionnaire de données. Un segment est à son tour composé de structures logiques appelées extensions. Une extension est un ensemble de blocs contigus dans un même fichier de données, tandis qu un segment peut être étalé sur plusieurs extensions chacun sur un fichier unique. Un bloc de données est la plus petite unité physique d E/S des données. Sa taille est définie via le paramètre DB_BLOCK_SIZE. Segment A (Extent 1) Segment A (Extent 2) Segment B (Extent 1) Segment B (Extent 2) Segment C (Extent 1) Data01.dbf Data02.dbf Figure 2 : Structure d'un tablespace incluant deux fichiers La Figure 2 présente un tablespace composé de deux fichiers de données. Le tablespace inclut trois segments A, B et C. Les segments A et B incluent chacun deux extensions chacune sur un fichier différent, pendant que le segment C inclut une seule extension. La Figure 3 représente la structure logique et physique d une base de données Oracle, remarquez que le sens des flèches entre les différentes structures indique une relation un à plusieurs Les fichiers de journalisation Tout d abord, faisons un petit rappel sur la notion de transaction ; une transaction est un ensemble d opérations (requêtes) de mises à jour (insert, update et delete) qui finit par un COMMIT (validation) ou un ROLLBACK (annulation). La validation/annulation concerne tout le bloc de mises à jour (l ensemble des opérations) depuis un COMMIT/ROLLBACK ultérieur ou depuis le début de la connexion. Une transaction finit donc par un COMMIT/ROLLBACK ou par une déconnexion de l utilisateur qui vaut un COMMIT si c est une déconnexion normale et un ROLLBACK si elle ne l est pas. 1 Il existe en effet d autres objets occupant de l espace disque, tel que les vues matérialisées, les tables organisées en index (IOT), les clusters etc.

12 12 Database Tablespace Fichier de données Segment Extension Bloc de donnée Bloc SE Structure Logique Structure Physique Figure 3 : Structure logique et physique d'une base de données Oracle Quant un utilisateur Oracle opère des mises à jour sur les données, celles-ci sont non seulement exécutées mais aussi sauvegardées dans les fichiers de journalisation. Cette mesure de sécurité primordiale permet en cas de crash du système de reconstituer les données perdues à partir des informations sauvegardées dans les fichiers de journalisation. C est d ailleurs la raison pour laquelle ces fichiers sont multiplexés et/ou copiés. En d autres termes, même si un fichier de journalisation est irrécupérable, Oracle peut compter sur sa (ou ses) copie(s). Un ensemble de fichiers journaux multiplexés constitue un groupe de fichiers de journalisation. Si par exemple un groupe inclut trois fichiers journaux, alors ces trois fichiers incluent exactement les mêmes informations, ils sont appelés membres d un groupe. Il existe au minimum deux groupes de fichiers journaux et ils sont écrits de manière cyclique, c.-à-d., que si les fichiers d un premier groupe sont pleins, Oracle passe au deuxième groupe et y écrit (dans chaque membre) les transactions nouvellement exécutées quitte à écraser les transactions existantes (voir la Figure 4). La vue V$LOGFILE contient toutes les informations qui concernent les fichiers journaux de la base de données.

13 13 Groupe 1 DELETE UPDATE INSERT INTO UPDATE UPDATE INSERT INTO DELETE UPDATE INSERT INTO UPDATE UPDATE INSERT INTO Membre 1 Membre 2 Groupe 2 INSERT INTO UPDATE DELETE... INSERT INTO UPDATE DELETE... Membre 1 Membre 2 Figure 4 : Ecriture cyclique et multiplexée des fichiers journaux Les archives des fichiers de journalisation Les fichiers de journalisation (présentés dans la section 2.1.3) sont écrits de manière cyclique. Il en découle que les données ne peuvent être récupérables qu à partir de la plus ancienne transaction non écrasée dans l un des groupes de fichiers de journalisation. Une solution de sécurité optimale, consiste à archiver les fichiers de journalisation avant de finir le cycle de sauvegarde des transactions et donc avant de les écraser. Il est à noter que les fichiers de journalisations sont archivés si la base de données fonctionne en mode ARCHIVELOG Le fichier de paramètres Il inclut l ensemble des paramètres de configuration qui conditionnent l initialisation de l instance, et ensuite son fonctionnement. Il est accédé lors du démarrage de l instance, il inclut entre autres le chemin du fichier de contrôle ainsi qu un ensemble de paramètres instanciés définissant la manière avec laquelle l instance va démarrer (notamment la taille des différentes structures mémoires de la SGA). Il existe deux types de fichiers paramètres, le classique PFILE (Parameter File) et le nouveau (depuis la version 9i) SPFILE (Server Parameter File). Une instance Oracle démarre sur un seul fichier paramètre, par défaut sur un SPFILE, mais peut aussi démarrer sur un PFILE si l administrateur le précise. Un PFILE est un fichier de paramètres de type texte qui devrait figurer sur toute machine susceptible de démarrer l instance. Pour éviter certains problèmes d utilisation en réseau (notamment la synchronisation lors de la mise à jour du fichier), Oracle 9i a introduit le SPFILE ; un fichier de paramètres binaire centralisé sur le serveur de la base de données. Le PFILE est généralement nommé init%.ora, il est modifié via n importe quel éditeur texte. Le SPFILE est nommé spfile%.ora, il est modifiable via SQL. Il est à noter qu on peut créer un fichier PFILE à partir d un fichier SPFILE et vice versa à l aide de la requête CREATE PFILE/SPFILE FROM SPFILE/PFILE. Finalement, les paramètres modifiés dans un fichier PFILE ne prennent effet que lors du prochain démarrage du système (modification sur fichier uniquement), pendant que les modifications de certains paramètres du SPFILE peuvent prendre

14 14 effet à chaud, c-à-d, sans redémarrer la base de données (modification directe en mémoire, sur fichier, ou les deux) Le fichier de mot de passe Lorsque l administrateur d une base de données tente de démarrer l instance, son identification se produit à partir de ce fichier qui inclut son mot de passe. En effet, la vérification du mot de passe ne peut pas se produire à partir du dictionnaire de données (comme pour les autres utilisateurs ordinaires) car l instance n est pas encore chargée en mémoire. La vérification se fait alors à partir d un fichier physique qui inclut l ensemble des administrateurs de la base de données avec leurs mots de passe ; il s agit du fichier du mot de passe. Ce fichier peut être quand même optionnel car l authentification à Oracle Database peut être reliée au système d exploitation qui l héberge. Cela veut dire qu une fois que l administrateur ouvre une session sur le système d exploitation (SE), il peut lancer automatiquement l instance Oracle sans aucune identification. Pour ce, il suffit de créer au niveau du SE un groupe d utilisateur, généralement appelée dba, d y ajouter les utilisateurs qu on veut administrateurs de la base, et de relier ce groupe à Oracle au moment de l installation d Oracle. Le paramètre REMOTE_LOGIN_PASSWORDFILE nous renseigne sur le type d identification pour accéder à l instance. Si sa valeur est mise à none, alors l identification se produit à travers le SE. Si la valeur est à exclusive, alors le fichier de mot de passe ne peut concerner qu une seule base de données. Dans ce cas, le fichier peut inclure les informations d identification de l utilisateur SYS, ainsi que d autres utilisateurs ayant reçu les privilèges d administration (plus précisément, les privilèges SYSDBA ou SYSOPER qui seront vus plus tard au Chapitre 5). Si la valeur dudit paramètre est mise à shared, alors le fichier de mot de passe peut être partagé par plusieurs bases de données. Dans ce cas, le fichier ne peut inclure que les informations d identification de l utilisateur SYS Autres fichiers Il existe d autres fichiers physiques nécessaires au bon fonctionnement d Oracle. Parmi ces fichiers, nous citerons brièvement les fichiers alertes, les fichiers traces et les fichiers de sauvegarde. Lorsqu une erreur interne est détectée par un processus d arrière plan ou serveur 1, ce dernier inscrit les détails de l erreur sur un fichier de trace. Certaines des informations écrites sur les fichiers de trace sont utiles à l administrateur soit pour débloquer le serveur, soit pour l optimiser. Les fichiers de trace écrits par les processus d arrière plan sont stockés dans le répertoire renseigné par le paramètre BACKGROUND_DUMP_DEST. Les fichiers de trace écrits par les processus 1 Les processus arrière plan et les processus serveur sont des programmes Oracle en exécution qui permettent à l instance de gérer les requêtes utilisateurs en assurant sécurité, intégrité et performance des données traitées. Ils seront détaillés à la section 2.2.2).

15 15 serveurs sont stockés dans USER_DUMP_DEST. Les fichiers de trace portent l extension.trc. Les fichiers d alertes stockent des informations relatives à des évènements et des messages importants qui correspondent à une base de données. Le chemin des fichiers d alerte se trouve au répertoire BACKGROUND_DUMP_DEST. Les fichiers d alerte portent l extension.log. Pour restaurer (reconstituer) un fichier endommagé (de données, de contrôle, de paramètres etc.), nous avons besoin d un fichier de sauvegarde. La sauvegarde est supposée déjà faite avant que le problème endommageant le fichier original ne se produise. 2.2 L instance L instance est l ensemble de structures mémoires et de processus qui assurent l accès et la gestion d une base de données. Le fichier de paramètres est utilisé pour configurer l instance lors de son démarrage. Celle-ci ne peut ouvrir qu une seule base de données à la fois Les structures mémoires Une instance emploie deux structures principales ; la SGA (System Global Area) et la PGA (Program Global Area). a. System Global Area (SGA) C est un espace de la mémoire centrale partagé par les différents processus de l instance. Elle est allouée au démarrage de la base de données et libéré lors de son arrêt. Elle est constituée de trois zones obligatoires et de trois zones optionnelles qui sont allouées au démarrage en fonction des valeurs des paramètres du fichier de paramètres. Depuis la version 9i d Oracle, sa taille n est plus obligatoirement fixe, et elle est devenue redimensionnable à chaud, c.-à-d., en cours d utilisation. Plus la taille de la SGA est grande, plus le nombre d E/S diminue et plus la performance de l instance est meilleure. Il est à noter que sa taille n excède pas la valeur du paramètre SGA_MAX_SIZE. La SGA inclut les structures suivantes : SGA Dictionary Cache Library Cache DB Buffer Cache Shared Pool Redo Log Buffer Java Pool Large Pool Streams Pool Figure 5 : Les composantes de la SGA

16 16 Le Pool Partagé (Shared Pool) C est une zone mémoire composée de deux structures ; le Library Cache et le Dictionary Cache. Le Library Cache contient les informations sur les requêtes SQL les plus récemment utilisées. Une requête SQL y est stockée sous trois formes ; le texte, sa version compilée, ainsi que son plan d exécution. Naturellement, le Library Cache a une taille limitée, c est pour cela qu il stocke uniquement les requêtes les plus récentes en utilisant l algorithme LRU (Least Recently Used). Il en découle qu une requête SQL exécutée pour la première fois est stockée dans le library cache avec son plan d exécution. Lorsque cette requête est exécutée de nouveau, Oracle ne perd de temps supplémentaire ni pour une deuxième analyse syntaxique et sémantique, ni pour trouver le plan d exécution optimal. En effet, il retrouve la requête sous ses trois formes (cités ci-dessus) et l exécute rapidement. La deuxième zone mémoire du pool partagé est le Dictionary Cache. En effet, lorsqu une requête est analysée, Oracle a besoin d accéder au dictionnaire de données pour voir si la table existe, si les colonnes sélectionnées ou conditionnées en font partie, si l utilisateur a le droit de manipuler cette table etc. Toutes ces informations nécessaires à l analyse de la requête SQL sont stockées dans le Dictionary Cache. Il est à noter que la taille du pool partagé est définie par le paramètre SHARED_POOL_SIZE. Le Database Buffer Cache Il stocke les blocs de données les plus récemment utilisées. Lorsqu Oracle est amené à exécuter une requête SQL et à ramener son résultat à l utilisateur, il vérifie si ses données (et donc blocs) existent dans le database buffer cache. Si ce n est pas le cas, Oracle lit les blocs de données qu il faut à partir des fichiers de données, les places dans le cache selon l algorithme LRU (en libérant de l espace s il le faut par élimination des blocs les moins récemment utilisées) et les renvoie à l utilisateur. Le paramètre DB_CACHE_SIZE désigne la taille du cache, il doit être naturellement un multiple de la taille d un bloc de données. À noter qu un bloc de données au DB Buffer cache (appelé aussi tampon) peut avoir un de ces quatre états : - Free bloc jamais utilisé, et donc disponible. Etat de tous les blocs juste après démarrage de l instance. - Dirty bloc modifié, mais non encore écrit sur le fichier de données. - Pinned bloc accédé couramment. - Clean bloc prêt à être libéré. Le Redo Log Buffer Ce buffer contient les mises à jour effectuées sur les données, et donc toutes les informations relatives à toute transaction réalisée par les utilisateurs. Il est écrit séquentiellement (ce qui provoque un mélange de transactions) et de manière cyclique ; taille limitée de la zone mémoire

17 17 oblige. Chaque modification correspond à une entrée redo écrite dans le buffer (redo entry). Une entrée redo est composée de plusieurs vecteurs de changement chacun correspondant à la modification d un bloc de données unique de manière à ce que la nouvelle valeur ainsi que l ancienne y soient enregistrées. Le contenu du buffer est écrit par Oracle dans les fichiers de journalisation (Redo Log Files) pour garantir la récupération des données en cas de crash du système. Il est à noter que la taille du buffer redo log est définie par le paramètre LOG_BUFFER. Java Pool Stocke les objets et applications Java les plus récemment utilisés lorsque la machine virtuelle Java JVM optionnelle est utilisée. Elle est dimensionnée par le paramètre JAVA_POOL_SIZE. Large Pool Stocke des données lors de l exécution d opérations volumineuses. Il est utilisé dans le cas d une configuration serveur partagé, elle est dimensionnée par le paramètre LARGE_POOL_SIZE. Streams Pool C est le cache des données relatives à la queue de messages utilisées par Oracle. Elle est dimensionnée par le paramètre STREAMS_POOL_SIZE. Notons la présence dans la SGA d une autre zone mémoire de petite taille (de l ordre de centaines de Ko) appelée SGA fixe ; elle inclut des informations sur l état de la base de données, sur l instance et sur les verrous. Le paramètre LOCK_SGA est un paramètre booléen (qui prend true ou false). Il permet à l administrateur d obliger (ou non) Oracle à allouer la zone SGA exclusivement en mémoire physique, sans ayant recours à la mémoire virtuelle. Les vues V$SGA et V$SGA_DYNAMIC_COMPONENTS permettent d afficher les tailles de zones mémoire composant la SGA, respectivement en résumé (SGA Fixe, SGA variable, Cache des données et celle des journaux) et en détail (chaque composant à part). REQ 2 SELECT * FROM V$SGA; REQ 3 SELECT component, current_size FROM V$SGA_DYNAMIC_COMPONENTS; La gestion automatique de la SGA (Automatic Shared Memory Management ASMM) La SGA peut être gérée automatiquement ou manuellement. Une gestion manuelle consiste tout simplement à instancier les tailles des zones mémoire une par une ; le choix de l administrateur s effectue selon les besoins de l application. Une gestion automatique est effectuée par l instance elle-même qui ajustera les tailles des composantes selon une quantité de mémoire précisée par l administrateur à travers le paramètre SGA_TARGET. La gestion automatique est donc activée si le paramètre SGA_TARGET (taille souhaitée de la SGA) est différent de zéro. Dans ce cas, le database buffer cache, le shared pool, le large pool et le java

18 18 pool sont dimensionnés automatiquement. À noter que la taille du log buffer n est pas prise en charge par la gestion automatique, sa taille est déduite du SGA_TARGET. Lorsque la gestion de la SGA est automatique (vs manuelle), l instance dispatche la quantité de mémoire renseignée par le paramètre SGA_TARGET au Shared Pool, DB Buffer Cache, Java Pool, Large Pool, Streams Pool. Oracle consulte des statistiques et des vues internes pour distribuer la quantité de mémoire globale aux zones mémoires de manière à maximiser la performance du serveur. Comme la charge de travail du serveur varie dynamiquement, Oracle se permet de changer dynamiquement le dispatching de la quantité totale de mémoire aux différentes zones mémoires de la SGA. Il est à noter que si la valeur de SGA_TARGET dépasse SGA_MAX_TARGET, alors Oracle met à jour le deuxième paramètre en l augmentant. b. Program Global Area (PGA) C est une zone mémoire privée (à la différence de la SGA) dédiée aux utilisateurs. Elle est créée pour chaque processus serveur quand il est initié. Elle stocke les informations spécifiques aux utilisateurs telles que les variables hôtes, les informations de session, l état des curseurs utilisés, les informations de tri etc. La PGA est exclusivement accédée par le processus serveur. La PGA totale allouée à tous les processus serveurs est appelée PGA agrégée. Depuis la version 9 d Oracle, un nouveau mécanisme permet de gérer globalement la PGA agrégée des processus serveurs. Sa taille est dimensionnée par le paramètre PGA_AGGREGATE_TARGET et c est Oracle qui se charge de répartir cette mémoire entre les différents processus serveurs Les processus Les processus Oracle permettent aux différentes composantes du serveur d interagir et d échanger entre elles ainsi qu avec l utilisateur. Il existe des processus utilisateurs du côté des clients, un ou plusieurs processus serveurs du côté du serveur assurant la communication avec le client et plusieurs processus d arrière plan qui assurent le bon fonctionnement de l instance. a. Les processus-utilisateur et le processus-serveur L interaction entre les clients et le serveur de base de données est assurée par le processus utilisateur du côté client et par le processus serveur du côté du serveur. En effet, lorsqu un utilisateur démarre une application (SQL*Plus, Oracle Enterprise Manager, une application Developer Forms etc.), Oracle démarre un processus utilisateur que ce soit sur sa machine distante s il s agit d une architecture client-serveur ou sur un serveur middle-tier sur une architecture multi-tier. Par la suite, une connexion entre le processus utilisateur et l instance est initiée et maintenue. Une fois la connexion établie, l utilisateur ouvre une session en s identifiant (saisie de son nom d utilisateur et de son mot de passe). Il est à noter que plusieurs sessions peuvent être ouvertes en même temps, ces sessions peuvent être ouvertes par le même utilisateur. Le paramètre qui détermine le nombre maximum de sessions ouvertes en même temps est le paramètre SESSIONS.

19 19 Après l ouverture d une session, Oracle démarre un processus serveur sur le serveur base de données, c est ce processus qui se chargera d exécuter les requêtes de l utilisateur et de maintenir une interaction entre le client et le serveur. Un serveur base de données est soit configuré en mode dédié, soit en mode partagé. Lorsque le serveur est configuré en mode dédié, Oracle crée sur le serveur pour chaque utilisateur (et donc pour chaque processus utilisateur) un processus serveur. En mode partagé, plusieurs processus utilisateurs peuvent partager un seul et unique processus serveur. Le mode par défaut est le mode dédié, pour activer le mode partagé, il suffit de modifier le paramètre SHARED_SERVERS dont la valeur par défaut est 0. La nouvelle valeur indiquerait le nombre de processus serveurs partagés démarrés lorsque l instance est lancée. Rappelons qu une zone de mémoire PGA est créée pour chaque processus serveur, elle inclut entre autres les variables hôtes et les variables de session utilisées dans les requêtes/programmes envoyés par l utilisateur (voir section b). b. Les processus d arrière plan Les processus d arrière plan sont utilisés par Oracle afin de maximiser la performance de l instance. La majorité des processus d arrière plan sont lancés lorsque l instance démarre, certains d entre eux pourraient être lancés après, lorsque l instance en aura besoin. Il est à noter que certains processus fonctionnent en plusieurs exemplaires, c est pour cela que leur nom finit par n qui signifie le numéro de l exemplaire du processus. - DBWn est le processus qui écrit le contenu du cache des données dans les fichiers de données (Database Writer). Le DBW écrit les tampons (buffers) modifiés, dits dirty, du cache de données dans les fichiers de données sur le disque. Un administrateur Oracle peut spécifier jusqu à 20 exemplaires de DBW, de DBW0 jusqu à DBW9 et de DBWa jusqu à DBWj si la base de données connait une forte charge transactionnelle. Il est à noter que les exemplaires des DBW sont inutiles dans le cadre de serveurs monoprocesseurs. Le paramètre d initialisation DB_WRITER_PROCESSES spécifie le nombre d exemplaires du DBW. Le maximum est de 20, si non spécifié, Oracle se charge d affecter le nombre d exemplaires qui convient selon le nombre de processeurs du serveur hébergeant la base. La tâche du DBW est de «nettoyer» le cache des données en écrivant les blocs dirty les moins récemment utilisés dans le fichier des données de manière à ce que le(s) processus serveur trouve(nt) aisément des tampons clean pour y charger les blocs de données qu il faut (à la suite d une interrogation utilisateur) à partir des fichiers de données. Il faut savoir que l écriture des blocs dirty par le DBW est différée, c-à-d, qu Oracle n écrit pas les blocs modifiés automatiquement après l exécution de la requête de mise à jour, et pas forcément après la confirmation (COMMIT) de la transaction en question. En d autres termes, ce n est pas l exécution de la transaction ni sa confirmation qui déclenchent le fonctionnement du DBW. Ce processus est plutôt déclenché par les événements suivants : o Un processus serveur ne trouve pas de tampons clean après qu il ait scanné un

20 20 nombre seuil de tampons. o Après une certaine période pour faire avancer le point de reprise. Le point de reprise est la position dans les fichiers journaux à partir de laquelle l instance est récupérable. Cette position est déterminée par le plus ancien tampon dirty dans le cache de données. - LGWR est le processus qui écrit le contenu (les entrées Redo) du redo log buffer sur les fichiers de journalisation de manière séquentielle. Une fois les entrées redo sont écrites sur le disque, le processus serveur peut utiliser cet espace (en écrasant les entrées déjà écrites) pour y stocker les informations des nouvelles mises à jour toujours sous la forme d entrées Redo. Le LGWR est déclenché par les événements suivants : o L utilisateur confirme une transaction par un COMMIT o Toutes les trois secondes. o Quand le buffer est plein au tiers. o Avant que le DBWn ne se mette à écrire les blocs modifiés non validés (non «committés») sur disque. En effet, lorsque le DBWn s apprête à écrire des blocs dirty non validés, il faut que toutes les entrées Redo en relation avec ses blocs soient écrites sur les Log Files. Cette situation ne peut se produire que si les modifications ne sont pas confirmées par un COMMIT (car sinon le LGWR aurait été déclenché et les entrés Redo en question auraient été déjà écrites). Si le DBWn sait qu il va écrire des blocs dirty non confirmés (dont les entrées Redo ne sont pas écrites sur disque), il le signale au LGWR et attend un message de ce dernier lui signalant la fin de sa tâche (écriture sur les Log Files des entrées redo en relation avec les blocs dirty) ; c est à ce moment là que le DBWn aura le feu vert pour écrire les blocs en question. Remarquez qu un COMMIT déclenche uniquement le LGWR. Après un COMMIT, les entrées Redo (du log buffer) en relation avec la transaction confirmée sont toutes écrites sur les fichiers journaux et un message de confirmation de la mise à jour est renvoyé à l utilisateur. Cette notion d écriture rapide du contenu du log buffer est dite fast commit. Lorsque le LGWR ne peut pas écrire sur un fichier du groupe courant (endommagement ou indisponibilité du fichier), il le fait sur les autres fichiers du même groupe et signale une erreur sur les fichiers de trace du système. Mais si tous les fichiers du groupe sont inaccessibles, LGWR n écrit nulle part et le signale aussi au système. Enfin, il est à noter qu Oracle affecte un code appelé SCN (System Change Number) à toute transaction validée (COMMIT). Ce code est inscrit par le LGWR sur les entrées Redo dans les fichiers de journalisation. Ce code est très important dans le mécanisme de récupération des données en cas de crash du système. - CKPT est un processus qui est lancé à la suite de l événement Checkpoint (point de

21 21 vérification). Lorsqu un checkpoint se produit, tous les blocs dirty doivent être écrits sur disque ; c est toujours le DBWn qui s en charge à la suite d un message du CKPT. Après écriture des blocs modifiés, le CKPT écrit le SCN de la dernière transaction confirmée sur les entêtes (headers) des fichiers de données ainsi que dans le fichier de contrôle ; ces deux derniers sont dits synchronisés. En cas de crash du système, le point de reprise est défini par ce SCN et Oracle récupère à partir des fichiers de journalisation toutes les transactions qui ont été confirmées après le SCN inscrit sur le fichier de contrôle/entêtes de fichiers de données. La synchronisation se produit lorsque le LGWR bascule d un fichier journal à un autre. Le LGWR ne se permet pas de basculer de fichier journal, et donc d écraser des entrés Redo, sans que le DBW n écrive les blocs dirty du DB buffer cache, le cas échéant, le LGWR pourrait écraser des entrés Redo relatives à des blocs modifiés non encore écrits sur disque. La synchronisation se produit aussi lors de la fermeture de la base de données ou lors de la mise hors ligne ou en READ ONLY d un tablespace. Le checkpoint peut être forcé à travers la requête : ALTER SYSTEM CHECKPOINT - SMON (System Monitor) est le processus qui récupère les données au démarrage de l instance si cette dernière s est arrêtée de manière anormale. Il est aussi chargé de libérer les segments temporaires inutilisés et de compacter les extensions libres et contiguës des tablespaces gérés par le dictionnaire de données. Si la récupération de certaines transactions échoue à cause de l indisponibilité d un tablespace ou d un fichier, SMON attend qu ils soient rétablis et récupèrent les transactions en question. Au cours d une récupération, SMON effectue un roll forward qui consiste à enregistrer sur les fichiers de données les modifications confirmées qui n ont pas été écrites par le DBWn, et un roll back pour annuler les modifications non confirmées écrites par le DBWn sur les fichiers de données. - PMON (Process Monitor) est le processus responsable de la récupération lors de l échec d un processus utilisateur. Lorsqu un un processus utilisateur plante, PMON annule la transaction de ce dernier et libère les verrous posés sur les données modifiées à cause de la transaction en cours. - ARCn est le processus qui écrit le contenu des fichiers journaux (redo log files) dans des fichiers archives lors de chaque basculement entre les groupes de fichiers journaux. Ce processus n est actif que si la base fonctionne en mode ARCHIVELOG. Une instance Oracle peut démarrer jusqu à 10 exemplaires d ARCs (d ARC0 jusqu à ARC9), c est le LGWR qui démarre un nouvel exemplaire d ARC à chaque fois que ceux qui fonctionnent déjà sont insuffisants pour écrire de manière efficiente. Cela étant dit,

22 22 l administrateur peut anticiper une charge importante d archivage et spécifier dès le départ le nombre d exemplaires qu il faut via le paramètre d initialisation LOG_ARCHIVE_MAX_PROCESSES. - CJQn est le processus coordinateur qui exécute les tâches planifiées par les utilisateurs. Ces tâches sont principalement des programmes PL/SQL planifiés entre autres grâce au package DBMS_SCHEDULER. Les informations concernant les tâches (jobs) planifiées d une base de données sont stockés dans la table DBA_SCHEDULER_JOBS du dictionnaire de données. Le processus CJQn peut exécuter un grand nombre de tâches grâces à ses processus esclaves (J000 J999). - MMAN (Memory Manager) est un processus introduit par Oracle 10g qui gère les tailles des composantes de la SGA lorsque l ASMM est activée. - MMON (Memory Monitor) est un processus introduit par Oracle 10g. Son objectif est de collecter des statistiques sur la SGA. MMON est déclenché toutes les 60 minutes pour collecter des statistiques à partir des vues dynamiques et statiques du dictionnaire de données et les stocker dans des tables de la base de données appelées Automatic Workload Repository (AWR). Le propriétaire de ces tables est SYSMAN et sont stockées dans le tablespace SYSAUX. Pour activer l AWR, il faut instancier le paramètre STATISTICS_LEVEL. La valeur assignée à ce paramètre détermine le niveau de statistiques que le MMON doit collecter ; BASIC veut dire que l AWR est désactivé (ce qui désactive plusieurs options de monitoring automatique) et que peu de statistiques sont collectées. TYPICAL est le niveau standard, il s agit de la valeur par défaut du paramètre. ALL permet la collecte des statistiques du niveau TYPICAL avec en plus les plans d exécution ainsi que d autres informations reliées au système d exploitation. Il faut savoir que le nombre maximum de processus exécutés en même temps dans l instance est contrôlé par le paramètre d initialisation PROCESSES. La vue V$PROCESS inclut les informations de tous les processus en court d exécution dans l instance. La Figure 6 présente toutes les composantes d un serveur base de données ; les fichiers physiques, les structures mémoire et les processus ainsi que l interaction entre ces différentes composantes que ce soit à l intérieur du serveur ou avec les clients et leurs processus utilisateurs. 2.3 Le schéma Un schéma est un ensemble d objets qui ont été créés par un certain utilisateur. Chaque utilisateur est le propriétaire d un unique schéma. Les principaux types d objets d un schéma sont les tables, les index, les vues, les synonymes, les séquences, les déclencheurs, les fonctions et procédures stockées et les packages PL/SQL. Il est à noter que les objets utilisateur, tablespace, profile, rôle et autres ne font pas partie des objets d un schéma. Il faut savoir aussi qu il n existe pas de relation directe entre un schéma et un tablespace. En effet, les objets d un schéma peuvent être stockés sur différents tablespaces tandis qu un unique tablespace peut inclure plusieurs schémas. L objet d un schéma n a pas forcément une

23 23 correspondance à un fichier physique de données. En réalité seuls les tables et les index sont stockés sous forme de segments, la plupart des autres objets correspondent tout simplement à des définitions dans le dictionnaire de données puisqu ils ne consomment pas d espace disque comparés aux tables et aux index. 2.4 Le dictionnaire de données Le dictionnaire de données est un ensemble de vues et de tables accédées en lecture seule, créées et maintenues par le système et contenant toutes les informations de toutes les composantes logiques et physiques du serveur de base de données. Le dictionnaire de données inclut en fait des données qui décrivent les données de la base de données ; c est ce qu on appelle les métadonnées. Il est créé dans le tablespace SYSTEM, et c est l utilisateur SYS qui en est le propriétaire. Cela étant dit, il n existe aucun utilisateur qui peut altérer la structure ou les données de ses tables, seul Oracle comme mentionné ci-dessus les crée et les maintient pour assurer l intégrité des données. Le dictionnaire de données est mis à jour entre autres lorsque les utilisateurs exécutent des requêtes LDD. Par exemple si un certain utilisateur JAMES crée une table FACTURE, Oracle insère certaines lignes dans plusieurs tables du dictionnaire de données qui décrivent la nouvelle table, ses colonnes, ses contraintes d intégrité, le segment utilisé, les extensions, les privilèges de JAMES sur cette table etc. Les tables du dictionnaire de données, telles que OBJ$ et FILE$, contiennent des données codifiées. Pour faciliter l accès à ces tables ainsi que leur utilisation par les utilisateurs, Oracle crée des vues qui y sont basées. Il existe deux types de vues du dictionnaire de données ; les vues statiques et les vues dynamiques de performance : Les vues statiques Ce sont des vues basées sur des tables créés réellement dans le dictionnaire de données. Elles ne sont accessibles que si la base de données est complètement ouverte. Elles commencent toutes soit par le préfixe DBA_%, soit ALL_%, soit USER_%. Les vues qui commencent par le préfixe USER_ concernent uniquement les objets possédés par l utilisateur qui les interroge (les objets de son schéma). Celles qui commencent par le préfixe ALL_ concernent les objets accessibles par l utilisateur (ses tables ainsi que celles dont il a eu certains privilèges). Finalement, celles qui commencent par le préfixe DBA_ concernent tous les objets de la base de données ; ces vues ne sont interrogeables que par un administrateur. La Table 1 inclut quelques vues statiques du dictionnaire de données. Nous remplacerons le préfixe par le caractère %, nous noterons directement le nom significatif des données générées par la vue. Par exemple, la vue %_TABLES est interrogeable soit sous forme de USER_TABLES, ALL_TABLES ou DBA_TABLES. Cela étant dit, certaines vues ne peuvent être consultées que par les administrateurs. C est pour cette raison que ces vues ne commencent que par le préfixe DBA_ tel que la vue