Instance Oracle

La Shared Pool ou zone de mémoire partagée est utilisée pour partager les informations sur les objets de la base de données ainsi que sur les droits et privilèges accordés aux utilisateurs.

Cette zone mémoire se découpe en deux blocs :

• La Library Cache
• Le Dictionnary Cache

On dimensionnera la taille de la Shared Pool avec le paramètre SHARED_POOL_SIZE dans le fichier init.ora.

III-A-1. La zone mémoire : Library Cache▲

III-A-2. La zone mémoire : Dictionnary Cache▲

Cette zone mémoire sert à stocker les blocs de données utilisés récemment. Ce qui signifie que lorsque vous allez lancer une première fois la requête Oracle, cette dernière va se charger de rapatrier les données à partir du disque dur. Mais lors des exécutions suivantes les blocs de données seront récupérés à partir de cette zone mémoire, entrainant ainsi un gain de temps.

Cette zone fonctionne selon le principe dit du bloc ancien. C'est à dire que l'on peut représenter cette zone mémoire comme étant un tableau dont l'entrée serait en haut à gauche et la sortie en bas à droite. Quand un bloc est appelé pour la première fois, il se situe donc en haut à gauche. S'il n'est pas rappelé ou réutilisé il est alors déplacé lentement vers la sortie. Cependant s'il est à nouveau utilisé il sera automatiquement ramené vers l'entrée de la zone mémoire.

Cette zone mémoire est définie par 2 paramètres du fichier init.ora

• DB_BLOCK_SIZE : Ce paramètre, défini lors de la création de la base de données, représente la taille d'un bloc de données Oracle. Celui-ci est défini de manière définitive et ne pourra plus être modifié.
• DB_BLOCK_BUFFERS : Ce paramètre défini le nombre de blocs Oracle qui pourront être contenus dans le Database Buffer Cache.

Ainsi pour obtenir la taille du Database Buffer Cache on effectuera l'opération DB_BLOCK_SIZE*DB_BLOCK_BUFFERS qui nous retournera une taille en Kbytes.

Cette zone mémoire sert exclusivement à enregistrer toutes les modifications apportées sur les données de la base.

Cet une zone mémoire de type circulaire, et dont on pourra changer la taille avec le paramètre LOG_BUFFER (en Bytes).

Le fait que cette zone mémoire soit de type circulaire et séquentielle, signifie que les informations des toutes les transactions sont enregistrées en même temps. Le fait que ce buffer soit circulaire signifie qu'Oracle ne pourra écraser les données contenues dans ce buffer que si elles ont été écrites dans les fichiers REDOLOG FILE.

Le processus SMON (ou System Monitor) est un processus qui va servir à corriger les plantages de l'instance et à vérifier la synchronisation des données. Si l'instance plante, c'est SMON qui va se charger de rejouer le contenu des REDO LOG FILE afin de pouvoir rejouer les transactions et de resynchroniser les données dans les fichiers de données.

Voici les étapes de cette récupération :

• Étape 1 : SMON va automatiquement rejouer les transactions qui ont été enregistrées dans les fichiers REDO LOG FILE mais pas sur le disque dur. Le fait de rejouer les transactions contenues dans les fichiers REDO LOG FILE va permettre de valider les transactions qui avaient été validées mais qui n'avaient pas pu être enregistrée sur le disque.
• Étape 2 : SMON va ouvrir la base de données pour les utilisateurs. Toutes les informations qui ne sont pas utilisées dans l'étape 1 et qui ont été validées sont alors disponibles immédiatement. Les autres restent verrouillées pour l'étape 3.
• Étape 3 : SMON se charge alors d'annuler toutes les transactions qui n'avaient pas été validés. Ce qui permettra d'avoir un état valide de la base de données.

SMON sert aussi à nettoyer les segments temporaires après leur utilisation. Il sert aussi à défragmenter les fichiers de données, tablespaces et autres.

En 9i SMON utilisera la même méthode que précédemment mais avec une évolution significative lors de l'étape 1.

En Oracle 8i, SMON afin de rejouer les transactions lisait de manière séquentielle les fichiers REDO LOG FILE et rejouait toutes les transactions. Cette méthode était fortement pénalisante lors du redémarrage après le crash.

En Oracle 9i, SMON va effectuer deux lectures successives des fichiers REDO LOG FILE. La première lecture va servir à identifier les blocs qui vont nécessiter une restauration. La deuxième lecture servira à ne rejouer que les blocs identifiés. Cette méthode est évidement moins coûteuse car le temps de lecture des fichiers REDO LOG FILE est négligeable comparée à la répétition de toutes les transactions.

Le processus PMON (ou Process Monitor) va être surtout dédié aux processus des utilisateurs. Il va servir à annuler les transactions d'une session (lors d'un plantage de la session par exemple), mais aussi servir à relâcher tous les verrous posés par la session, et à relâcher toutes les ressources détenues par la session.

Le processus DBWn (ou Database Writer) va être dédié à l'écriture du Database Buffer Cache dans les fichiers de données de la base de données.

Ce processus est aussi là pour vérifier en permanence le nombre de blocs libres dans le Database Buffer Cache afin de laisser assez de place de disponible pour l'écriture des données dans le buffer.

DBWn se déclenchera lors des événements suivants :

• Lorsque le nombre de bloc dirty atteint une certaine limite
• Lorsqu'un processus sera à la recherche de blocs libres dans le Database Buffer Cache, et qu'il ne sera pas en mesure d'en trouver.
• Lors de timeouts (environ toutes les 3 secondes par défaut)
• Lors d'un checkpoint

V-C-1. GWR▲

Ce processus va servir à mettre à jour les en-têtes des fichiers de données, et mettre à jour les fichiers CONTROL FILE afin de spécifier que l'action de CHECKPOINT s'est bien déroulée (par exemple lors d'un changement de groupe de REDO LOG FILES).

Le CHECKPOINT est un évènement qui se déclencher lors :

• D'un changement de groupe de REDO LOG FILE.
• D'un arrêt normal de la base de données (c'est à dire sans l'option ABORT)
• D'une demande explicite de l'administrateur
• D'une limite définie par les paramètres d'initialisation LOG_CHECKPOINT_INTERVAL, LOG_CHECKPOINT_TIMEOUT, et FAST_START_IO_TARGET

L'évènement CHECKPOINT va ensuite déclencher l'écriture d'un certain nombre de blocs du Database Buffer Cache dans les fichiers de données par DBWn après que LGWR ait fini de vider le REDO LOG Buffer. Le nombre de blocs écris par DBWn est défini avec le paramètre FAST_START_IO_TARGET si celui-ci a été défini.

Voici une description des différents paramètres d'initialisation liés au CHECKPOINT

Ce paramètre va avoir pour seule fonction de copier un fichier REDO LOG FILE à un autre emplacement. Cette copie se déclenchera automatiquement en mode ARCHIVELOG (en mode NOARCHIVELOG le processus n'existe pas) lors du changement de groupe de REDO LOG FILE.

Dans cette explication on supposera que la base vient d'être démarrée et que aucune connexion n'a encore eu lieu. Une requête SQL va être exécutée en plusieurs étapes. Tout d'abord l'utilisateur se connecte au serveur, ce qui génère la création d'un processus serveur.

L'utilisateur va donc ensuite demander l'exécution de la requête suivante :

    SELECT *
FROM emp;

Vous remarquerez la richesse de mon exemple :). Cette requête va donc être passée au processus serveur qui va ensuite la traiter en plusieurs étapes :

• Étape 1 : Le parsage
• Étape 2 : L'exécution
• Étape 3 : Le fetch

VI-A-1. Le parsage▲

SELECT *
FROM emp;
-- et
select *
from emp

VI-A-2. L'exécution▲

VI-A-3. Le fetch▲

L'exécution d'un ordre DML (Update, Insert, Delete) va seulement se décomposer en 2 phases :

• Étape 1 : Le parsage
• Étape 2 : L'exécution

VI-B-1. Le parsage▲

VI-B-2. L'exécution▲

Le COMMIT va permettre de terminer une transaction en validant les données qui ont été modifiées. Afin de valider de manière sure les données, Oracle utilise un processus appelé FAST COMMIT. En effet la première chose que va faire Oracle en recevant une commande COMMIT, va être d'enregistrer cette commande directement dans le REDO LOG BUFFER afin d'enregistrer le fait que la transaction a été validée au moyen de LOGWR afin que celui-ci écrive la fin de cette transaction dans les REDO LOG FILE. A ce moment précis l'utilisateur n'a toujours pas reçu le message de confirmation.

Le temps utilisé pour ces actions peut être considéré comme négligeable car il est pratiquement impossible que la base de données plante durant ces actions. Cela signifie que si la base plante après ces actions, nous serons alors en mesure de restaurer de manière totalement transparente les données non écrites sur le disque grâce à SMON.

Une fois la transaction enregistrée dans les REDO LOG BUFFER, l'utilisateur est alors informé que l'ordre a bien été effectué. Puis le processus serveur se chargera de relâcher tous les verrous posés pendant la transaction.

Avant de pouvoir créer notre première instance il est indispensable de créer le fichier init.ora. En effet c'est ce fichier qui va contenir les paramètres d'initialisation qui vont nous être nécessaires pour démarrer l'instance.

En 9i les paramètres d'initialisation peuvent aussi être stockés dans le fichier SPFILE de la base, permettant dans certain cas de les modifier en ligne et en connexion client/serveur.

Le fichier init.ora sera un fichier texte comprenant les paramètres d'initialisation, alors que le SPFILE sera un fichier binaire.

VII-B-1. Sous Windows▲

c:\> oradim -new -sid ORCL -intpwd oracle -startmode auto -pfile c:\oracle\ora92\admin\orcl\pfile\init.ora

VII-B-2. Sous Unix/Linux▲

Que ce soit sous Windows ou Linux/Unix la méthode est identique. La première étape sera de définir la variable d'environnement ORACLE_SID.

Ensuite il va falloir se connecter à sqlplus en mode SYSDBA afin d'être en mesure de lancer et démarrer l'instance.

sqlplus /nolog
connect / AS sysdba

Une fois connecté il ne restera plus qu'à démarrer l'instance avec la commande startup.

Le démarrage d'une base de données complète se déroulera en plusieurs étapes telles que NOMOUNT, MOUNT, OPEN.

Ces trois étapes sont obligatoires et devront être exécutées dans cet ordre. Cependant la commande STARTUP permettra d'effectuer automatiquement ces 3 actions.

• NOUMOUNT : Cette étape va consister à lire le fichier init.ora, à démarrer l'instance, allouer la mémoire, et démarrer les processus d'arrière plan.
• MOUNT : Cette étape va consister à ouvrir le ou les fichiers CONTROLEFILE afin de mettre en mémoire les informations contenues par les fichiers CONTROLEFILE. Durant cette étape les fichiers de données ne sont pas accessibles car ils n'ont pas encore été ouverts.
• STARTUP : Cette étape va consister à ouvrir tous les fichiers de données enregistrés dans les fichiers CONTROLEFILE. Puis une fois tous les fichiers ouverts et disponible, à ouvrir complètement la base de données aux utilisateurs.

Voici des exemples d'utilisation :

-- Démarrage de l'instance
STARTUP NOMOUNT PFILE="<emplacement du init.ora>"
-- Lecture des controles files
ALTER DATABASE MOUNT;
-- Ouverture de la base de données
ALTER DATABASE OPEN;

-- --

-- NOMOUNT et MOUNT automatique
ALTER DATABASE MOUNT PFILE="<emplacement du init.ora>"
-- Ouverture de la base de données
ALTER DATABASE OPEN;

-- --

-- Ouverture directe de la base de données sans spécifier les 3 étapes

STARTUP PFILE="<emplacement du init.ora>"