Version Description Date

(1)

Telephone : +243970808519, +243897779961 Site internet : www.dba-rdc.org

Numéro du document : 0.4 Auteur : Danny Nkutua Kalombo Date de publication : Septembre 2010 Dernière mise à jour : Avril 2012

Résumé des modifications :

Version Description Date

0.1 (Danny Nkutua) 0.2 (Danny Nkutua) 0.3 (Danny Nkutua)

Version initiale.

Clarification des textes et autres détails.

Ajout des captures d’écrans, détails sur les commandes SQL*PLUS et retouche sur la présentation dans son ensemble.

Septembre 2010 Novembre 2010 Décembre 2010

0.4 (Danny Nkutua) Mise à jour avec Oracle 11g, correction générale et ajout des détails dans les concepts théoriques.

Avril 2012

Droits d’auteurs :

Aucune partie de cet ouvrage ne peut être reproduit, transcrit, transmit ou traduit dans une autre langue dans n’importe quelle forme que ce soit électronique, magnétique, optique, manuelle sans la permission écrite de l’auteur sous peine des poursuites judiciaires conformément à la loi congolaise (RDC) des droits d’auteurs.

Pour tout contact avec l’auteur : +243970808519, +243897779961

Editeur : Stella Publising

(2)

À Berlishe, Nahomie et Benitan. Vos sourires m’ont permis de continuer…

-Danny

(3)

Remerciements

Nous ne saurions publier cet ouvrage sans pour autant remercier toute l’équipe NSAT Technologies pour son soutient lors de la première publication.

Nous tenons également à remercier tous ceux qui de près ou de loin ont contribué à cette version corrigée. Je citerais l’Assistant Selain KASEREKA avec qui nous avons initié ce projet de formation, Allain KATAKU pour la disponibilité de ses documentations, Chicco BADIBANGA pour son soutient pendant mes premiers pas avec Oracle, Daniel KALONJI pour ses lectures et corrections, Christian BOPE pour l’environnement de son entreprise lors de mes premiers pas.

A toi aussi…

Si vous avez une quelconque question ou commentaire à propos de cet ouvrage, n’hésitez pas à me contacter personnellement sur admin@dba-rdc.org ou dnkutua@gmail.com.

(4)

Pourquoi devenir DBA ?

Commençons par le commencement. Dans une entreprise, vous trouverez certainement toutes sortes d’informaticiens qui manipulent à la perfection les bases des données (les ingénieurs systèmes, les développeurs, les techniciens de supports aux applications, etc.).

Dans un tel environnement, on pourrait bien se demander à quoi bon vouloir se spécialiser dans le domaine des bases de données?

Réfléchissions encore. Tout le monde ne développe pas des applications Java, Python ou C# par exemple, ni ne configure des routeurs Cisco et encore moins n’élabore les plans des projets. Toutefois, presque tout le monde manipule les bases de données d’une manière ou d’une autre. La conclusion à notre réflexion semble d’une évidence certaine : un développeur, un administrateur réseau, un software security officer, un administrateur des projets, un technicien de support et même un encodeur possède une zone d’activité où il règne en maître, excepté l’administrateur de base de données (Data Base Administrator ).

Cette réflexion n’est pas fausse, quoiqu’elle mérite une certaine rectification.

Voyons pourquoi les DBA sont toujours là alors qu’ils semblent ne rien faire de spécial surtout que dans la plupart du temps, après quelques vérifications matinales, ils passent le reste de la journée à la lecture, correction des quelques scripts et ouf, facebook, twitter, google+ ou je ne sais quoi d’autres.

Bon, répondons à présent à la question fondamentale de savoir pourquoi devenir DBA ? à cela, nous allons y répondre par une métaphore. Actuellement les avions les plus sophistiqués sont de plus en plus facile à manipuler. Ceci grâce aux systèmes de pilotage automatique. De ce fait, vous pouvez piloter un avion après un après midi de formation. C’est simple du fait que la machine accomplit 95% du boulot tout seul. Pourtant, pourquoi faut-t-il des hautes études aéronautiques pour devenir pilote qualifié ? Quand tout va bien dans un avion, vous ne voyez certainement pas pourquoi applaudir à l’atterrissage pour des pilotes qui ont passé tout leur temps à bavarder bien au frais dans leurs cabines! Dans le cas contraire, quand les choses tournent mal, c’est la panique dans l’avion. Il y a alors une évidence : une mauvaise manipulation de la part du pilote peut coûter la vie à tous les passagers. Dans une telle situation, le choix entre un nouveau pilote et un pilote qualifié et expérimenté se fait ressentir. J’imagine la scène, tous les passagers prient pour que le pilote leur rassure

(5)

que le désagrément est mineur, qu’il a déjà connu ce genre de problème et qu’il sait comment s’y prendre.

C’est exactement la même chose avec le DBA, c’est quand les autres n’arrivent pas à avoir les réponses à leurs requêtes, quand le serveur arrête de fonctionner brusquement, quand les procédures ne tournent plus, quand des messages incompréhensible s’affichent à votre écran alors qu’aucune manipulation spéciale n’a été faite, quand vous n’arrivez pas à vous connecter avec votre mot de passe que vous avez utilisé il y a de cela 5 minutes, quand votre bouton à cliquer n’est plus cliquable, pfff, quand vous êtes vous ne savez prendre votre pieds avec la base de données…

C’est dans des telles situations que les développeurs, les administrateurs réseau et systèmes, les financiers, les comptables, les managers et tout autre agent se rendent compte qu’il faut appeler la personne qui d’apparence ne semble rien faire de spécial et pourtant sans qui rien ne peut se faire : moi, le DBA .

Ainsi, dans la suite de cet ouvrage, nous allons apprendre à devenir et à avoir les reflexes de ce pilote qui sait résoudre les problèmes sans que les passagers ne s’en rendent compte. Qu’ils continuent à croire que nous ne faisons rien, c’est le boulot d’un DBA que de veiller à ce que les autres ne se rendent même pas compte de tout ce qui arrive au système même en cas de problème. Un DBA d’avoir être proactifs. Le système doit rester accessible quelque soit les circonstances et ce, dans la plus grande ignorance des utilisateurs. C’est pour cette raison que j’ai lu des dizaines des livres manuscrits, des centaines des documentations électroniques, je me suis abonné à des dizaines des clubs des DBA Oracle, j’ai effectué des milliers des tests, assuré volontairement le support DBA dans des environnements réels de production, passé des milliers des heures devant des serveurs Oracle, animé des formations et séminaires parfois bénévolement,… Pour finalement devenir un DBA Oracle.

Connaissez-vous une entreprise sans DBA ?

Quelque soit votre expérience avec Oracle (Administrateur, développeur, utilisateur, etc.), il est important de vous mettre continuellement à jour avec les nouvelles versions qui apportent leurs lot de facilitation des tâches en modifiant quelque fois l’architecture même du serveur.

L’expérience étant la clé d’or des compétences d’un DBA, vous devez apprendre à surmonter les problèmes et vous affilié à des administrateurs expérimentés sans pour autant négliger les lectures et partage des connaissances.

(6)

Notons également que pour ceux qui désirent passer la certification (source de crédibilité et assurance d’un salaire au dessus d’une certaine limite), les désignations anglaises des composants sont obligatoires (ne vous conformez pas au français si vous désirez passer la certification, je sais de quoi je parle).

(7)

A qui s’adresse cet ouvrage ?

Tel que structuré et présenté, cet ouvrage s’adresse principalement aux administrateurs de bases de données qui veulent migrer vers une solution Oracle ou même ceux qui veulent prendre Oracle comme leur premier environnement d’administration des bases de données. En second lieu, il s’adresse aux développeurs, administrateurs systèmes, tout curieux de la science et particulièrement des bases de données. Toutefois, il est essentiellement axé vers une politique de migration vers le système de gestion de base de données Oracle (dans sa version 11g Release 1). Il est donc important que le lecteur ait au préalable certaines connaissances dans les bases de données, précisément sur le modèle relationnel et le langage SQL.

Néanmoins, en séance préparatoire de la formation, nous balayons les notions de conception et implémentation d’une base de données sous MERISE pour une bonne entrée dans la matière.

Comme tout domaine technique, la théorie est certes importante à la compréhension, mais seul la pratique et la détermination fera de vous un As des bases de données Oracle.

(8)

3

Il y a dans l'homme quelque chose de supérieur. C’est la volonté E. RENAN Copier sur un, c'est du plagiat. Copier sur deux, c'est de la recherche W. MIZNER

Rien ne peut arrêter un homme qui a de la volonté.

ARCHITECTURE ORACLE

Au cours de cette troisième partie, qui constitue le chapitre clé de notre formation, nous apprendrons essentiellement les points suivants. Nous vous recommandons vivement de prendre votre temps afin de très bien vous intégrer et comprendre l’architecture Oracle qui est le fondement de notre cours : III.1. Architecture

III.1.1. Le monobloc III.1.2. Le client/serveur III.2. Structure de la base Oracle

III.2.1. Base de données et instance III.2.2. Structure physique et logique III.3. Instances

III.3.1. Introduction

III.3.2. Les mémoires Oracle III.3.3. Les processus d’arrière plan

III.3.4. Processus de traitement d’une requête Oracle Tuning

III.4. Les droits et privilèges III.5. Le middleware Oracle Net

III.5.1. Rappel sur l’architecture Client/Serveur III.5.2. Le middleware ou médiateur

III.6. Le processus d’écoute ou Listener Oracle III.6.1. Introduction

III.6.2. Connexion utilisateur à la base de données

(9)

III. ARCHITECTURE ORACLE 10g

III.1. Architecture

Comme toute base de données professionnelle, Oracle peut fonctionner selon deux architectures principales : le monobloc et le client/serveur.

III.1.1. Le monobloc

Dans une telle architecture, toutes les ressources sont concentrées autour d’une machine qui héberge les applications ou ressources dont ont besoin les décideurs. Cependant, cette machine ne peut être accessible que par une connexion directe et on ne peut donc y avoir accès à distance.

Utilisateur travaillant Sur le serveur physique

Utilisateur distant

Figure : un système en monobloc avec accès distant inexistant.

III.1.2. Le client/serveur

Dans cette seconde architecture, nous distinguons deux variantes que nous allons explorer ci-dessous : le client/serveur simple et le multi tiers.

III.1.2.1. Le client/serveur simple

Pour illustrer ce type d’architecture, prenons exemple de ce que nous voyons dans les boîtes de nuit (pour ceux qui les fréquentent) et même dans nos terrasses publiques. Le serveur prend les commandes des clients et les sert si leurs demandes correspondent à ce que la maison offre sinon il demande aux clients de changer leurs commandes en leur proposant quelque chose de similaire à leurs demandes.

(10)

L’architecture clients/serveur Oracle fonctionne de la manière similaire. Les applications clientes envoient des requêtes SQL (PL/SQL) à un serveur qui analyse ces requêtes et retourne les réponses aux utilisateurs si les requêtes sont claires et ont un sens (analyse sémantique et syntaxique autrement dit le parsing) et dans le cas contraire un message d’erreur est envoyé à l’utilisateur qui pourra alors corriger sa requête et la relancer convenablement. La communication entre les clients et le serveur s’effectue en conséquence par un jeu des questions et réponses illustré comme suit :

Client

Serveur de base de données

Client

Requête

Requête Réponse

Réponse

Figure : le client/serveur échangeant questions et réponses.

Notons cependant qu’un serveur peut fonctionner soit en mode dédié, soit en mode partagé.

La distinction entre un serveur dédié et un serveur partagé sera abordée en détails dans la suite de ce chapitre. Cependant, notons que dans le cas d’un fonctionnement en mode dédié, chaque processus client est servi par un et un seul processus serveur pendant toute la durée de la communication alors dans un fonctionnement en mode partagé, un seul processus serveur s’occupe d’un certain nombre des processus clients.

Le mode partagé est très recommandés dans un environnement où l’on a un nombre important des clients très légers tel dans un environnement purement transactionnel alors que le mode dédié est recommandé dans un environnement où les clients sont lourds et à faible quantité comme c’est le cas dans les entrepôts des données (data warehouse).

(11)

Client

Serveur de base de données

Client Client

Processus serveur unique

Client

Figure : serveur en mode partagé où les clients se partagent les mêmes ressources serveurs.

Client

Serveur de base de données Client

Client

Processus serveur 1

Figure : serveur en mode dédié où chaque client à ses propres ressources au niveau du serveur.

III.1.2.2 Le Multitier

Toujours dans notre illustration des terrasses publiques, il arrive des cas où les clients deviennent tellement nombreux au point qu’il n’y a plus assez des serveurs pour que chacun d’eux s’occupe spécialement d’un client. Dans ce cas, le serveur reste dans le bar et un garçon de cours peut vite récupérer les commandes des clients, les amener aux serveurs et vas de nouveau récupérer les autres commandes et ainsi de suite. Une fois le serveur prêt, il lui remet les plats ou boissons commandé avec le numéro de la table. Le garçon ne sait pas où le serveur trouve ces plats et boissons et même comment il les prépare. Son boulot est simplement de récupérer les commandes des clients, les amener au serveur en indiquant le numéro de la table et une fois prêt le serveur lui dépose les plats et boissons pour aller servir les clients. Il allège donc les tâches du serveur.

(12)

Dans Oracle, les choses se passent également de la même façon, des serveurs d’applications allègent la charge du serveur de base de données en réalisant certains accès pour les clients comme le montre la figure suivante.

Cette architecture est dite multi tiers (dans le cas de la figure, c’est du 3 tiers) suite au fait qu’il y a plusieurs entités qui entrent en jeux (dans le cas de la figure, il y a trois entités : le client [les clients de la terrasse], le serveur d’application [le garçon qui aide le serveur] et le serveur de bases de donnés [le serveur/cuisinier de la terrasse]).

Serveur de base de données Client

Client

Serveur d’applications

Figure : le multitier (3 tiers).

III.2. Structure de la base Oracle III.2.1. Base de données et instance

Il nous convient de bien faire la distinction entre une base de données et une instance Oracle. Une base de données Oracle est composée d’un certaines nombre des fichiers comme nous le verrons tout de suite alors qu’une instance Oracle est composée de la base ainsi que des processus qui permettent de la modifier, le tout chargé en mémoire.

Vu l’importance de cette distinction, expliquons le par un exemple : Lorsque nous voulons modifier un document texte, que faisons nous ? Nous allons dans le fichier texte en question, puis nous l’ouvrons (c'est-à-dire que nous le chargeons en mémoire) et enfin nous le modifions. Le fichier physique sur le disque peut être considéré comme la base de données Oracle et le fichier ouvert ou chargé en mémoire peut être considéré comme l’instance Oracle. On ne peut donc parler d’instance que si les fichiers sont chargés en mémoire pour une manipulation quelconque. Comme on ne peut modifier le fichier physique qu’en l’ouvrant, on ne peut modifier une base Oracle qu’au travers de son instance.

L’instance Oracle est donc constituée des fichiers physiques, les différentes zones mémoires, ainsi que les processus qui permettent de travailler sur ces fichiers.

(13)

III.2.2. Structure physique et logique

Une base de données Oracle a une structure logique et une structure physique parfois totalement distinctes.

La structure physique d’une base Oracle concerne les différents fichiers physiques qui contiennent les données et informations de la base alors que la structure logique concerne le mode de stockage des données physique par Oracle.

III.2.2.1. Structure de stockage physique

Physiquement, une base de données Oracle est essentiellement composée de trois types de fichiers qui sont les suivants : les fichiers de contrôles (control files), les fichiers de données (data files) et les fichiers des journaux (redo log files).

Les fichiers de base de données sont des fichiers binaires et ne peuvent pas être lus ou modifiés sans passer par Oracle. Dans la figure suivante, les fichiers à l’intérieur du grand rectangle Base de données sont les fichiers essentiels qui constituent une base de données Oracle.

D’autres fichiers sont utiles au fonctionnement du serveur Oracle sans pour autant faire parti (techniquement) de la base de données, il s’agit par exemple de :

 Fichiers de mot de passe ;

 Fichier de paramètres d’initialisation .ora (pfile ou spfile) ;

 Fichier d’alerte ;

 Fichiers de sauvegarde (créés par RMAN ou manuellement par le DBA) ;

 Les fichiers de journalisation archivés (archivelog).

Base de données

Fichier de mot de passe

Fichier paramètre

Fichiers journaux archivés Fichier

De controle

Fichier

De données Fichier

journaux

Figure : les fichiers physiques de la base de données Oracle.

(14)

a. Les fichiers de données

Ces fichiers contiennent toutes les informations de votre base de données dans un format spécifique à Oracle. Le seul et unique moyen pour accéder et manipuler des données stockées dans Oracle est d’utiliser le langage SQL. Comme expliqué précédemment, on ne peut modifier les fichiers de données que via l’instance.

Les fichiers de données sont les plus volumineux de votre base ; leur dimension dépend de la quantité d’informations à stocker. Il est fréquent qu’un administrateur Oracle intervienne sur ces fichiers qui portent l’extension .dbf.

b. Les fichiers de contrôle

Ce sont des fichiers binaires contenant des informations sur tous les autres fichiers constitutifs d’Oracle ainsi que sur l’instance. Ils décrivent entre autre leur nom, leur emplacement, leur taille etc. Ils sont principalement utilisés au démarrage de la base de données, contiennent des informations sur l’état de la base et sur sa cohérence, ils indiquent si la base a été correctement fermée et si une restauration est nécessaire. Ils sont mis à jour automatiquement par Oracle.

Pour des raisons de sécurité, il est recommandé de créer plusieurs fichiers de contrôles (multiplexage) sur des disques différents, mais ceux-ci sont tous identiques.

Lorsqu’une instance est lancée pour ouvrir une base de données, le fichier de contrôle est le premier fichier ouvert. Il permet ensuite à l’instance de localiser et d’ouvrir les autres fichiers de la base de données. Si le fichier de contrôle ne peut être trouvé (ou endommagé), la base de données ne peut être ouverte, même si les autres fichiers sont présents. Dans ce cas, différents niveau de restauration sont possibles en fonction de la situation (voir le module de formation DBA Associate 2). Pour ces raisons, il est vivement conseillé de multiplexer le fichier de contrôle, les différentes copies seront gérées en miroir par Oracle. Le multiplexage des fichiers de contrôle peut être spécifiés lors de la création de la base ou ultérieurement comme nous le verrons dans nos séances pratiques.

c. Les fichiers journaux

Les fichiers journaux (redo-log) sont des fichiers qui conservent toutes les modifications successives de votre base de données. L’activité des sessions qui interagissent avec Oracle est consignée en détail dans les fichiers journaux.

Ils sont utiles lors d’une restauration à la suite d’un problème quelconque. Cette restauration consiste à reconstruire le contenu des fichiers de données à partir de l’information stockée dans les fichiers journaux.

(15)

Les fichiers de journalisation sont organisés en groupes (au minimum 2) composés d’un ou de plusieurs membres (minimum un) ; ils sont crées lors de la création de la base. A l’intérieur d’un groupe, les membres sont écrits simultanément en miroir par l’instance Oracle et contiennent la même information. Tous les membres d’un groupe ont la même taille définie lors de la création du groupe ; un fichier de journalisation contient donc une quantité maximale d’informations. De même, le nombre de groupes est déterminé à la création de la base et ne peut être modifié par la suite.

Lorsqu’un groupe est plein, l’instance Oracle passe au groupe suivant et ainsi de suite jusqu’au dernier ; lorsque le dernier groupe est plein, l’instance repasse au premier. Le passage d’un groupe à un autre est appelé basculement. Le cercle orienté de la figure suivante traduit l’écriture en cycle dans les fichiers de journalisation.

Groupe des fichiers de journalisation

Figure : l’écriture circulaire dans les fichiers de journalisation.

Outre ces trois types de fichiers obligatoires, Oracle dispose d’autres types des fichiers dont certains méritent qu’on s’y connaisse surtout en cas de problème.

d. Le fichier d’initialisation

Ce fichier est important car il permet le démarrage de l’instance. Au démarrage de l’instance, Oracle lit ses paramètres dans ce fichier dit fichier démarrage ou d’initialisation.

Les paramètres lus concernent entre autre la mémoire allouée aux différentes structures, le nom et l’emplacement des fichiers de contrôle de la base à ouvrir etc.

Historiquement, ce fichier était du type texte (init.ora), mais depuis la version 9, il est possible d’utiliser un fichier de paramètres binaire stocké sur le serveur (SPFILE = Server Parameter File).

Le fichier init.ora est un fichier éditable avec un éditeur simple de textes, les modifications y effectuées sont prise en compte lors du redémarrage de la base. Par contre les fichiers spfile sont modifiés avec la commande ALTER SYSTEM.

Comme nous le verrons dans nos ateliers pratique, on peut crée un spfile avec l’assistant de création de base de données (DBCA, Data Base Configuration Assistant) ou à

(16)

partir d’un fichier init.ora existant avec la commande CREATE SPFILE. Ces fichiers se trouvent dans %ORACLE_HOME%databasespfile%.

e. Fichier d’alerte et trace

Oracle dispose d’un fichier où il inscrit tout type d’erreurs et événements qui surviennent à la base de données (création de la base, démarrage et arrêt, modification de la structure, erreurs interne, problème lié à l’archivage des fichiers de journalisation, etc.). Ce fichier doit être fréquemment consulté par l’administrateur de base de données pour suivre l’évolution de la base. Le nom du fichier des alertes est de la forme alert_<SID>.log, le nom des fichiers de trace des processus d’arrière plan est de la forme

<sid>_<nom_processus>_<id_processus>.trc, et finalement, le nom des fichiers de trace des processus serveur est de la forme <sid>_ora_<id_processus>.trc. S’il faut faire la différence entre ces deux fichiers, disons que les fichiers trace enregistre toutes les activités des processus alors que le fichier alerte enregistre tous les erreurs survenues dans le fonctionnement du système, y compris ceux liées aux erreurs des processus.

Remarque

Il est sérieusement conseillé de purger régulièrement le fichier d’alerte pour éviter qu’il ne soit trop volumineux ; le mieux serait même de l’archiver à intervalle de temps réguliers pour garder l’historique de la vie de la base de données. Vous pouvez cependant supprimer ou renommer le fiche d’alerte sans crainte ; Oracle le recréer alors qu’il en aura besoin.

III.2.2.2. Structure de stockage logique

Comme dit plus haut, outre le stockage physique des données, Oracle dispose d’une structure logique pour le stockage des données. La structure logique spécifie la manière dont les données sont enregistrées dans la base.

Selon cette structure, en allant d’un ordre croissant de la plus petite unité vers la plus grande, nous avons les éléments suivants : bloc du système d’exploitation, bloc Oracle, Extents, Segments et Tablespace. La figure suivante illustre la relation qui existe entre ces différents éléments que nous expliquons dans les lignes qui suivent :

(17)

Base de données

Table, Index, Cluster,...

Bloc OS Fichier

Bloc Oracle

Schéma Tablespace

STRUCTURE LOGIQUE

STRUCTURE PHYSIQUE

Figure : Structure de stockage logique.

a. Blocks

La plus petite unité de stockage dans une base de données Oracle est appelée block (ou data block). La taille d’un bloc est généralement un multiple de la taille du bloc du système d’exploitation, cela pour faciliter les opérations d’entrée/sortie dans les disques et le chargement des données en mémoire. La taille par défaut des blocs est spécifiée par le paramètre DB_BLOCK_SIZE (généralement 8 Ko). Les différentes versions du software Oracle database sont dues entre autre aux différences des spécificités de chaque système d’exploitation.

b. Extents

L’extent est le second niveau de regroupement logique dans une base de données Oracle. Il est composé d’un ou de plusieurs blocks contigus permettant de stocker un certain type d’information. Les extents sont ajoutés automatiquement lorsque l’objet est créé ou lorsqu’un segment nécessite davantage d’espace. La taille minimum d’un extent est de cinq database blocks.

c. Segments

Le niveau suivant de regroupement logique dans Oracle est appelé segment. Un segment est un regroupement d’extents qui forment un objet de base de données qui est traité comme unité par Oracle (table ou index par exemple). Ainsi donc, c’est la plus petite unité de stockage qu’un utilisateur final d’Oracle peut manipuler.

(18)

Oracle dispose de quatre types de segments :

 Data segment (segment des données) ;

 Index segment (segments d’index) ;

 Temporary segment (segments temporaires) ;

 Undo segment ultérieurement appelée rollback segment (segments d’annulation).

c.1. Data segment

Ces segments stockent les données de la base de données.

c.2. Index segment

Ces segments stockent les données des index. Oracle crée le segment d’index pour chaque index ou partition d’index chaque fois que vous exécutez l’ordre CREATE INDEX.

c.3. Temporary segment

Lors de l’exécution des requêtes, Oracle exige souvent un espace temporaire de travail pour ses différentes étapes de traitement de la dite requête (le parsing et l’exécution).

Oracle alloue automatiquement cette espace disque qui est appelé segment temporaire.

Typiquement, Oracle exige un segment temporaire comme un espace de travail pour les tris. Il ne crée pas de segment si les opérations de tris peuvent être faites en mémoire ou si le moteur Oracle trouve d’autres moyens d’exécuter l’opération en utilisant les index.

Généralement, les opérations suivantes exigent la création des segments temporaires :

 CREATE INDEX;

 SELECT … ORDER BY;

 SELECT DISTINCT;

 SELECT … GROUP BY;

 SELECT … UNION;

 SELECT … INTERSECT;

 SELECT … MINUS;

Certaines jointures portant sur des tables non indexées ainsi que certaines sous requêtes peuvent exiger l’usage d’un segment temporaire. Par exemple si la requête contient une clause DISTINCT ou GROUP BY.

c.4. Undo segment

Ces segments stockent les données avant toute modification dans la base et sont vidés une fois que les modifications sont validées. Par contre en cas d’annulation des modifications, ce sont les données stockées dans les undo segments qui permettent un retour en arrière.

(19)

d. Tablespaces

Un tablespace est une unité logique de stockage pouvant stocker un ou plusieurs fichiers physiques. La quasi-totalité des opérations d’administration relatives au stockage s’effectue en travaillant sur le tablespace et non sur les fichiers de données.

Logiquement, un tablespace est composé d’un ou plusieurs segments. Physiquement, il correspond à un emplacement dans le disque du serveur pour le stockage des données.

Pour une installation d’Oracle, un minimum de deux tablespaces sont crées : la tablespace SYSTEM et SYSAUX. Une installation par défaut en crée six.

d.1. Le tablespace SYSTEM

Toutes les bases de données contiennent un tablespace nommé SYSTEM, qui est crée automatiquement à la création de la base. Le tablespace SYSTEM contient toujours les tables du dictionnaire des données de la base entière. Tous les programmes PL/SQL (procédures, fonctions, packages et triggers dont nous en parleront en détaille à la fin de notre formation), résident dans le tablespace SYSTEM. Les données utilisateurs ne doivent pas être stockées dans le tablespace SYSTEM.

d.2. Le tablespace SYSAUX

Le tablespace SYSAUX est crée auxiliairement au tablespace SYSTEM et ce, lors de la création de la base de données. Si le tablespace SYSAUX devient indisponible, la base de données restera néanmoins fonctionnelle.

L’administrateur de base de données peut créer d’autres tablespaces selon les besoins des applications:

1. Un tablespace d’annulation (UNDO TBS) utilisé pour stocker des informations d’annulation des transactions. Ils ne sont pas créer par l’administrateur, mais par l’instance ;

2. un tablespace par domaine d’activité (chaque sous système de gestion peut avoir ces propres tablespaces pour le stockage des données d’application) ;

3. un tablespace pour les index.

d.3. Le tablespace USERS

C’est le tablespace par défaut des utilisateurs.

d.4. Le tablespace UNDO

Ce tablespace récupère la version précédente des données en cours de modification par les transactions se déroulant sur la base.

(20)

d.5. Le tablespace Temporaire TEMP

Tablespace récupérant les segments temporaires utilisés par les requêtes SQL de la base de données.

La vue de dictionnaire DBA_ TABLESPACES fournit la liste de tous les tablespaces de la base de données.

La vue de dictionnaire DBA_DATA_FILES fournit les datafiles associés à chaque tablespace de la base de données.

Les tablespaces temporaires ne figurant pas dans DBA_TABLESPACES, sont listés dans DBA_TEMP_FILES.

Oracle vous permet également de créer un type spécial de tablespace appelé bigfile tablespace dont la taille peut aller jusqu’à 128 Téraoctets. En utilisant le bigfile, l’administration des tablespaces devient alors transparente pour le DBA. En effet, Oracle utiliser alors la technologie ASSM (Automatic Segment Space Management) pour une gestion automatique de l’espace dans les segments composant le bigfile. L’utilisation d’Oracle Managed Files (OMF) facilite également la gestion des tablespaces. Avec l’OMF, le DBA spécifie un ou plusieurs fichiers systèmes qui contiendront les fichiers de données, de control et les redo log (archive) et Oracle s’occupe du nommage et de la gestion de ces fichiers.

Remarques : Recommandation de stockage

Pour le stockage des fichiers de la base de données, il est conseillé de :

1. Utiliser plusieurs disques pour une meilleure répartition des entrées/sorties, ce qui contribue à l'amélioration des performances ;

2. Multiplexer les fichiers de contrôle et les fichiers de journalisation pour améliorer la sécurité de la base de données ;

3. Consulter régulièrement les fichiers des alertes et si nécessaires les supprimer (Oracle les recréera au besoin).

III.3. Instance III.3.1. Introduction

Pour ce qui est du bon fonctionnement de tout serveur professionnel, les éléments essentiels à prendre en compte portent généralement sur le processeur, l’espace disque et l’espace mémoire. Cependant, comme nous l’avons énoncé plus haut, il faut savoir que si la base de données Oracle se trouve dans le disque du serveur, l’instance par contre est volatile car elle est stockée dans la mémoire du serveur et que la taille de votre mémoire volatil est d’une importance capitale au bon fonctionnement de l’instance.

(21)

Une instance Oracle est composée d’une zone mémoire appelée System Global Area (SGA), associée à cela un certain nombre des processus qui interagissent entre le SGA et les fichiers de la base de données qui se trouvent sur disque. Elle est identifiée par un identifiant appelé SID. Généralement, le SID porte le même nom que la base et l’instance.

De la figure ci-dessous, nous pouvons voir les éléments essentiels d’une instance Oracle à savoir la mémoire partagée (SGA) et les processus (les petits cercles en bas).

Instance

ARC0 SMON

PMON

DBW0 LGWR

Serveur

Library cache Dictionary cache

System Global Area (SGA)

Redo log buffer

Database buffer cache Shared Pool

ORACLE_SID

Figure : Une instance Oracle et ses composants.

III.3.2. Les mémoires Oracle III.3.2.1. Le PGA

Afin d’optimiser ses performances, le serveur Oracle dispose de plusieurs zones mémoires différentes ayant chacune une tâche claire dans le fonctionnement du serveur.

Comme on a pu le voir précédemment, le processus utilisateur est un processus qui établie une connexion, ouvre une session avec une base de données Oracle. Par exemple, un utilisateur qui se connecte à l’instance de la base de données et ouvre ainsi une session pendant laquelle il pourra envoyer au moteur d’Oracle des commandes SQL. La session durera jusqu’à la fin de la connexion. Bref, La zone mémoire allouée pour le fonctionnement de chaque processus utilisateur au niveau du serveur s’appelle la zone mémoire du programme (PGA, Program Global Area).

(22)

Client

Processus utilisateur

INSTANCE ORACLE Processus serveur

PGA

Figure : Le PGA, la zone mémoire du programme.

Le PGA sert à stocker les informations privées liées à la session correspondante.

La PGA comprend essentiellement les zones mémoires suivantes :

 Une zone mémoire dans laquelle s’effectue le tri de vos requêtes ;

 Une zone mémoire où sont stockées des informations sur la session telles que les privilèges de l’utilisateur ;

 Une zone mémoire qui gère les informations sur la gestion des curseurs actuellement utilisés par la session ;

 Une zone mémoire où sont stockées les informations concernant les variables utilisées par la session.

III.3.2.2. Complément sur l’architecture des serveurs

Comme expliqué brièvement dans nos paragraphes précédents, il existe deux sortes des serveurs : les serveurs dédiés et les serveurs partagés.

a. Serveur dédiés (Oracle dedicated server)

Réfléchissons comme suit : si vous êtes un client VIP dans un restaurant, vous devez probablement avoir votre propre serveur. Ce dernier est là pour vous accueillir et vous escorter jusqu’à votre siège. Il prend votre commande et vous aide même à faire les bons choix et cela peu importe les nouveaux clients qui entrent dans le restaurant, votre serveur reste à vos côtés pour se rassurer que vous êtes à l’aise et vous rend le meilleur des services.

Un serveur dédié fonctionne de la même manière, chaque connexion cliente est associée à un processus serveur appelé shadow process. Peu importe les nouvelles connexions, le processus serveur reste au service des requêtes du même client. Aussi, vous remarquez que dans un tel environnement, il ne doit pas y avoir beaucoup des clients. C’est la

(23)

raison pour laquelle le mode dédié est utilisé dans un environnement des requêtes lourdes exécutées par très peu des clients (notamment dans les data warehouse).

Client 1

Serveur Shodow process 1

Client 4 Client 3

Client 2

Shodow process 4 Shodow process 3 Shodow process 2

Figure : Oracle Dedicated Server.

b. Serveur partagé (Oracle shared server)

Dans certains restaurants, un même serveur s’occupe des ordres des plusieurs clients et les donnent aux cuisiniers. Une fois les plats prêts vous êtes servis. Dans un tel environnement comme c’est le cas des cafés et terrasses, les plats sont assez abordables et tout le monde peu y prendre part. C’est donc un environnement où un même serveur peut s’occuper de plusieurs clients. De cette même façon fonctionne Oracle en mode shared server. Un processus dispatcher est responsable pour coordonner les requêtes des clients. Ce processus est capable de prendre en main les requêtes de plusieurs clients.

Quand un client lance une requête au serveur, c’est le dispatcher qui a la responsabilité d’enregistrer la requête et la placer dans le request queue qui est une structure contenue dans le SGA. Le processus serveur exécute la requête et place le résultat dans une zone de la SGA appelé response queue. Chaque dispatcher dispose de son propre response queue. Le dispatcher prend la réponse dans le response queue et le retourne au client. Ci- dessous les étapes dans la communication entre le client et le serveur. Le client passe sa requête à son dispatcher ;

1. Le dispatcher place la requête dans la request queue du SGA ;

2. Un des processus serveur exécute la requête placé dans le request queue ; 3. Le serveur place la réponse de la requête dans le response queue du dispatcher ; 4. Le dispatcher récupère la réponse dans le response queue ;

5. La réponse est retournée au client.

(24)

Client

Serveur Oracle SGA

Request queue Response queue

Shared Server pocess

Dispatcher pocess 1

6

5 2

3 4

Figure : Oracle shared server.

Pour ce qui est du PGA, suivant que le processus serveur est partagé par plusieurs processus utilisateurs ou dédié à un seul processus utilisateur, les informations relatives aux ordres de tris et à la session seront stockées dans le shared pool ou dans le PGA.

III.3.2.3. L’UGA

Les informations relatives aux ordres de tris et à la session forment une zone mémoire appelé UGA (User Global Area) ; cette zone mémoire est déplacée dans le pool partagé si vous utilisez l’option de serveur partagé. Sinon elle est placé dans le PGA.

III.3.2.4. Le SGA

Alors que le PGA est la zone de mémoire allouée à chaque processus utilisateur, un autre espace mémoire est alloué à tous les processus utilisateurs, c’est le SGA (System Global Area).

La mémoire SGA (System Global Area) est une mémoire partagée par tous les processus serveur et les processus en arrière-plan. Elle est allouée au démarrage de l'instance en mémoire principale. La SGA doit être la plus grosse possible car son but est d'économiser les entré/sorties.

Elle contient obligatoirement les composants suivants :

 Le cache de données (database buffer cache) ;

 Le cache de reprise (redo log buffer) pour les changements récents ;

 Le cache d'exécution partagée (shared pool) pour les requêtes SQL et PL/SQL. Contient le dictionnaire de données en cache.

(25)

a. Le database buffer cache

Il contient les blocs de données les plus récemment utilisés (blocs de tables, bloc d’index, bloc de segments d’annulation) avant de les inscrire dans la base de données. Ayant une taille finie, Oracle utilise un algorithme LRU (Least Recently Used) pour gérer ce cache. En cas de manque de place, Oracle supprime du cache les données utilisées le moins récemment.

Généralement, l’augmentation de sa taille améliore les performances du système. La taille du Database Buffer Cache est définie par la valeur du paramètre DB_BLOCK_BUFFERS.

b. Redo log Buffer

Il stocke les informations sur les modifications apportées à la base de données, avant leur écriture dans un fichier de journalisation. Il est utilisé de manière séquentielle et circulaire. Le redo log est dimensionné par le paramètre LOG_BUFFER.

c. La shared pool

La shared pool est composée principalement de deux structures :

 Le library cache ;

 Le dictionnary cache.

Le library cache contient des informations sur les ordres SQL et PL/SQL les plus récemment exécutés (notamment les plans d’execution).

Le Dictionnary cache contient les informations du dictionnaire de données Oracle les plus récemment utilisées (description des tables, droits des utilisateurs, les contraintes d’intégrités, la description des tables, les informations sur les index, et autres metadata).

Le shared pool est globalement dimensionné par le paramètre SHARED_POOL_SIZE. La répartition entre le library cache et le dictionnary cache est assurée par Oracle.

Le SGA contient secondairement les composants suivants :

 Java pool : mémoire utilisé par la machine virtuelle java, elle est dimensionné par le paramètre JAVA_POOL_SIZE (Oracle recommande une taille minimum de 50 MB) ;

 Large pool : zone de mémoire optionnelle utilisée par différents processus dans des configurations particulières comme par exemple la mise en œuvre de l’ASM ;

 Stream pool : zone de mémoire utilisée par la fonctionnalité Streams (méthode avancée de réplication), elle est dimensionné par le paramètre STREAMS_POOL_SIZE ;

 Reserved Area (depuis la version 11g) : zone mémoire utilisée par Oracle pour initialiser le paramètre MEMORY_TARGET. Par défaut ce paramètre est positionné à une valeur égale à 128K ;

 Flashback buffer : mémoire qui enregistre les images des blocks des données modifiés.

C’est-à-dire qu’à chaque fois qu’un bloc de données est modifié, l’image du bloc avant modification est inscrite dans le flashback buffer pour une utilisation future de

(26)

restauration ou interrogation de la base à un état du passée. La taille maximale de cette zone mémoire est de 16 MB.

Suivant que l’on travail avec un serveur en mode dédié ou partagé, la SGA se présente sommairement comme le montre la figure suivante :

Redo Log buffer Database

Buffer cache Dictionnary

cache Librairy cache

Shared Pool

SGA en mode dédié

Redo Log buffer Database

Buffer cache

Shared Pool UGA

UGA UGA

UGA

Request queue Dispatcher response queue Dispatcher response queue

Dictionnary cache Librairy cache

Shared Pool

SGA en mode partagé

Figure : SGA dans un serveur dédié versus SGA dans un serveur partagé.

Vous pouvez le constatez que lorsque Oracle est configuré pour fonctionner en mode serveur partagé, deux nouvelles structures sont crée au niveau de la SGA : le request queues et les response queues. Il n’y a qu’un seul request queue pour tous les dispatchers, mais chaque dispatcher a sa propre response queue. Comme expliqué plus haut, le PGA est une zone mémoire utilisé pour stocker les informations relatives à la session de l’utilisateur.

Cependant, dans un serveur en mode partagé, ces informations sont placées dans le UGA.

III.3.3. Les processus d’arrière plan

Oracle dispose de plusieurs processus d’arrière plan qui ont chacun un rôle bien précis dans le fonctionnement de l’instance. Chacun exécute un travail spécifique pour aider à gérer l'instance.

(27)

Cinq processus d'arrière-plan sont indispensable au bon fonctionnement du server Oracle, d’autres par contre sont facultatifs.

Un processus d'arrière-plan facultatif n’est utilisé que lorsque la fonction optionnelle d’Oracle correspondante est activée dans la base. Parmi les processus les plus importants, nous pouvons citer :

III.3.3.1. DBWn (Database Writer)

Les processus DBWn sont chargés d’écrire les blocs modifiés du database buffer cache dans les fichiers de donnes. Généralement, une instance a un seul processus Database Writer désigné par DBW0. Sur les systèmes multiprocesseurs et multidisque ayant une forte activité de mise à jour, il est possible voir conseillé de démarrer plusieurs processus DBW (jusqu’à 20 au maximum).

Ce processus copie des blocs modifiés des tables, les index, les undo segments et les segments temporaires à chaque occurrence des événements suivants :

 Toutes les trois secondes ;

 Dès que la longueur de la dirty List (liste des blocs modifiés) dépasse un seuil défini en interne ;

 Chaque fois qu’un autre processus consulte la liste des blocs récemment utilisés (LRU List) et ne peut trouver un emplacement libre après un nombre prédéterminé en interne de recherche de blocs ;

 Lors de chaque Checkpoint ;

 Chaque fois que la base de données est arrêtée normalement ;

 Chaque fois qu’une table est effacée ou tronquée ;

 Chaque fois qu’un tablespace est mise en mode hors ligne ou lecture seule ainsi que s’il fait partie d’une sauvegarde en ligne.

Les flèches dans la figure suivante illustre l’action du DBW dans l’instance Oracle.

(28)

Instance

ARC0 SMON

PMON

DBW0 LGWR

Serveur

Library cache Dictionary cache System Global Area (SGA)

Redo log buffer

ORACLE_SID

Fichier De controle

Fichier

journaux

Figure : DBWn

III.3.3.2. LGWR (Log Writer)

Les processus LGWR sont chargés de l’écriture par lots des entrées du tampon des journaux (buffer redo log) dans les fichiers journaux (fichier redo log).

Ce processus est le seul à écrire dans les fichiers journaux et à lire directement dans le tampon des journaux durant le fonctionnement normal de la base. Il écrit dans ces fichiers de façon séquentielle, par opposition aux accès relativement aléatoires du processus DBWn dans les fichiers de données. Les flèches dans la figure suivante illustre l’action du LGWR dans l’instance Oracle.

(29)

Instance

ARC0 SMON

PMON

DBW0 LGWR

Serveur

Redo log buffer

ORACLE_SID

Fichier

journaux

Figure : LGWR.

III.3.3.3. CKPT (checkpoints)

Les points de contrôle créent et enregistrent des points de synchronisation dans la base de données, de manière à faciliter sa récupération en cas de défaillance d’une instance ou d’un média.

Le processus CKPT exécute des points de contrôle, met à jour l’en-tête des fichiers de données ; lui-même n’écrit pas les données modifiées sur le disque, c’est le processus DBWn qui s’en charge.

Ce processus s’exécute naturellement à chaque basculement des fichiers journaux (fichiers redo-log) ou peut être exécuté manuellement par un DBA.

Les flèches dans la figure suivante illustre l’action du CKPT dans l’instance Oracle.

(30)

Instance

ARC0 SMON

CKPT

DBW0 LGWR

Serveur

Redo log buffer

ORACLE_SID

Fichier

journaux

Fichier De données

Figure : CKPT

III.3.3.4. ARCn (Archiver)

Le processus LGWR écrit dans chacun des fichiers journaux à tour de rôle. Lorsque le premier est plein, il écrit dans le second, et ainsi de suite. Une fois le dernier fichier rempli, il écrase le contenu du premier.

Lorsque la base opère dans le mode ARCHIVELOG, elle réalise une copie de chaque fichier journal et lorsqu’ils sont pleins ; ces fichiers archivés sont généralement enregistrés sur le disque.

La fonction d’archivage, c'est-à-dire la copie de chaque fichier journal plein, est assurée par le processus ARCn. Les flèches dans la figure suivante illustre l’action du processus ARC dans l’instance Oracle. Ce processus d'arrière-plan est facultatif mais essentiel à la récupération d'une base suite à une défaillance physique du disque.

(31)

Instance

ARC0 SMON

PMON

DBW0 LGWR

Serveur

Redo log buffer

ORACLE_SID

Fichier

journaux

Figure : ARCn

III.3.3.5. SMON (System MONitor)

C’est un processus obligatoire qui s’apparente à un observateur du système. Ce moniteur est essentiel au démarrage de l’instance et est impliqué dans tout rétablissement qui s’avère nécessaire. Il nettoie également les segments temporaires et inutilisés, efface les vieux processus, et fusionne l’espace libre dans de plus grands blocs contigus.

Récupération de l'instance : Dans le cas d’un arrêt anormal du serveur (coupure électrique par exemple) SMON récupère automatiquement l’instance de la manière suivante :

1. Réapplique les modifications des transactions validées (Roll forward) à partir des fichiers de journalisation en ligne. Une transaction validée implique une écriture des entrées de journalisation correspondantes sur disque et donc ne seront pas perdues en cas d’échec de l’instance ;

2. Ouvre la base de données pour permettre l'accès aux utilisateurs ;

3. Annule les modifications des transactions non validées (Roll back) lorsqu’un processus serveur accède à des données verrouillées par des transactions non validées.

Son fonctionnement est automatique, aucune action de l’administrateur de données n’étant requise. La flèche dans la figure suivante illustre l’action du SMON dans l’instance Oracle.

(32)

Instance

ARC0 SMON

PMON

DBW0 LGWR

Serveur

Redo log buffer

ORACLE_SID

Fichier

journaux

Figure : SMON

III.3.3.6. PMON (Process Monitor)

C’est un processus obligatoire qui est affecté à la récupération des processus utilisateur défaillants. Il libère le cache de blocs de données ainsi que les ressources qui étaient exploitées par l’utilisateur, telles que les verrous, afin de les mettre à disposition d’autres utilisateurs.

A l’instar du processus de surveillance SMON, le processus de surveillance PMON s’active régulièrement pour se rendre compte si on a besoin de ses services.

Le rôle de PMON est très important si vous utilisez un système comportant de nombreux utilisateurs ou encore si vous effectuez des requêtes lourdes. Chaque connexion à une base Oracle consomme quelques méga-octets de mémoire et du temps processeur. Si un utilisateur arrête brutalement sa machine ou si la connexion réseau est perdue au cours d’une longue requête SQL, un ensemble de ressources peut ainsi être bloqué inutilement si PMON ne détecte pas et ne nettoie pas les transactions anormalement interrompues. La flèche dans la figure suivante illustre l’action du DBW dans l’instance Oracle.

(33)

Instance

ARC0 SMON

PMON ^DBW0 ^LGWR CKPT

Redo log buffer

ORACLE_SID

Fichier

journaux

PGA Processus

serveur

Figure : PMON

III.3.3.6. Autres processus

A partir de la version 10g, d’autres processus ont été crée pour facilité le fonctionnement d’Oracle, nous pouvons citer entre autre :

 Job Queue Coordinator (CJQ) : utilisé par le Scheduler, il génère les processus pour exécuter les jobs planifiés qui se trouvent dans la file d’attente interne d’Oracle.

 Memory Manager (MMAN) : il agit comme un distributeur de mémoire et coordonne la taille allouée aux différents composants.

 Memory Monitor (MMON) : il programme et déclenche ADDM (L’Automatic Database Diagnostic Monitor) qui effectue des analyses pour déterminer des problèmes potentiels ;

 Recovery Write (RVWR) : il est responsable d’écrire le log du flash back dans le flash recovery area (nous allons en parler dans les procédures de sauvegarde et restauration) ;

 Recoverer (RECO) : il est utilisé dans une architecture distribuée pour résoudre tout types des problèmes lié à l’identification de la base cible.

(34)

Remarque : Audit des opérations de la base

L'audit Oracle est une des possibilités de surveillance de l'activité de la base de données pour :

 Contrôler les accès à la base, à des fins de sécurité ;

 Vérifier que tel ou tel objet est accédé en lecture ou en écriture (sécurité ou analyse de performance) ;

 Vérifier les tentatives d'accès infructueux à des objets ;

 Contrôler l'audit éventuellement des pirates.

Les résultats sont stockés dans une table du dictionnaire : SYS.AUD$ et préférablement accédés à travers des vues prédéfinies. Ceci permet de faire des requêtes SQL sur le résultat et éventuellement de produire des rapports sophistiqués.

La table SYS.AUD$ et les vues DBA_% ne sont bien sur accessibles qu'au DBA ou tout utilisateur ayant le privilège SYSDBA. Les vues d'audit sont normalement créées par CATALOG.SQL, et plus précisément par le script CATAUDIT.SQL, lors de la création de la base.

Vue d'audit Description

STMT_AUDIT_OPTION_MAP code des types d'option

AUDIT_ACTIONS codes des actions

ALL_DEF_AUDIT_OPTS option d'audit OBJET part défaut

DBA_STMT_AUDIT_OPTS options d'audit courantes

DBA_PRIV_AUDIT_OPTS options d'audit SYSTEME courantes

DBA_OBJ_AUDIT_OPTS, USER_OBJ_AUDIT_OPTS options d'audit sur tous les objets et sur ceux du USER DBA_AUDIT_TRAIL,

USER_AUDIT_TRAIL

toutes les entrées d'audit et celles concernant uniquement le USER

DBA_AUDIT_OBJECT, USER_AUDIT_OBJECT

toutes les entrées d'audit OBJET et celles concernant uniquement le USER

DBA_AUDIT_SESSION, USER_AUDIT_SESSION les entrées d'audit concernant toutes les (dé)connexions et celles concernant uniquement le USER

DBA_AUDIT_STATEMENT, USER_AUDIT_STATEMENT les entrées d'audit concernant GRANT, REVOKE, AUDIT, NOAUDIT, et ALTER SYSTEM de tous ou du user connecté

DBA_AUDIT_EXISTS les entrées d'audit concernant AUDIT EXISTS et AUDIT NOT EXISTS.

(35)

Pour activer les fonctions d’audit, il faut positionner le paramètre de démarrage AUDIT_TRAIL dans le fichier INIT.ORA de la base.

Trois valeurs sont possibles :

 NONE : invalide l'audit (valeur par default) ;

 DB : valide l'audit et stocke les résultats dans la table d'audit ;

 OS : valide l'audit et stocke les résultats dans un fichier externe (un autre paramètre : AUDIT_FILE_DEST précise le répertoire de destination...).

III.3.4. Processus de traitement d’une requête

Il est question dans ce paragraphe de comprendre le processus de traitement d’une requête avant son exécution et ce, afin de nous permettre de mieux comprendre la gestion des ressources mémoires intervenant ainsi que les techniques à mettre en œuvre afin d’optimiser les requêtes et avoir plus rapidement les résultats de vos requêtes.

Pour ce qui est des zone mémoire, le cache library conserve, à des fin de partage et de réutilisation, des informations sur les commandes SQL et le code PL/SQL les plus récemment utilisées qui ont été soumis par des utilisateurs de la base de données.

Dans le traitement d’une requête, le chargement d’une instruction SQL est très consommatrice en termes de ressources, raison pour laquelle le cache library partagé est utilisée pour optimiser et ne charger une instruction SQL qu’une et une seule fois pour de multiples exécutions.

En effet, c’est le processus serveur associé à la session utilisateur qui exécute l’ordre SQL transmis par le processus utilisateur. Pour le traitement de l’ordre SQL, un curseur (ou une zone mémoire) est crée et pointe vers une partie du PGA.

Figure : le processus de traitement d’une requête.

(36)

Cette mémoire privée contient les informations nécessaires pour le traitement du curseur (adresses des blocs contenant les lignes à extraire de la base de données, nombre de ligne renvoyé, ligne courante, état du curseur (ouvert ou fermé), …). Toutes ces informations ne sont utiles que pour la session utilisateur correspondante, c’est pourquoi elles sont placées dans la mémoire privée PGA et seront écrasées à la fermeture de la session.

Le traitement du code SQL se fait en trois phases :

 Analyse parse ;

 Execute ;

 Fetch.

III.3.4.1. Phase1 "Analyse parse"

Durant cette phase d’analyse, Oracle procède à :

1. une analyse syntaxique de l'ordre SQL (une instruction SQL doit respecter, en effet, des règles en termes d'orthographe et d'ordre des mots SQL réservés).

2. une analyse sémantique: Oracle vérifie l’existence dans le dictionnaire de données des objets référencés dans l'ordre SQL (tables, noms de colonnes …) et les droits de l'utilisateur sur les objets référencés.

3. Oracle détermine Le plan d'exécution (execution plan) permettant d’accéder de façon optimale aux données en s'appuyant sur des statistiques (sur les tables et les index) destinés à l'optimiseur. Ces statistiques permettent par exemple de juger qu'un FULL SCAN (parcours séquentiel) d'une table est parfois plus rentable en termes de coût qu'un accès via index lorsque le nombre de lignes est réduit. Seuls les index contribuant à un temps de réponse optimal seront utilisés.

4. Le plan d'exécution détermine les blocs Oracle contenant les données recherchées.

5. Oracle place, ensuite, la requête SQL dans le library cache

6. Oracle utilise un algorithme de hachage pour calculer une valeur qu'il compare aux valeurs calculées pour les autres ordres SQL disponibles dans le cache. Cette valeur détermine s'il est possible de réutiliser un code déjà mis en cache ou non.

Pour éviter autant que possible l'analyse parse qui consomme beaucoup de ressources, il est nécessaire d'optimiser le code SQL. Cette optimisation ne signifie pas forcément mettre les codes dans une procédure stockées. Ce qu’il faut, c’est limiter les entrées-sorties.

Idéalement, le code SQL doit être soumis à travers des procédures stockées. Une procédure stockée présente, en effet, l'avantage de stocker dans le dictionnaire de données (sur disque) le plan d’exécution correspondant.

L’utilisation de procédures applicatives garantit d’avoir le même texte de code SQL et donc la même valeur de hachage. Le code SQL est de ce fait facilement réutilisable. Un développeur doit organiser ses programmes en unités réutilisables et éviter autant que