Architecture de base Oracle
L'objectif de cette section est d'introduire et de critiquer l'architecture d'Oracle. Nous allons en parcourir les composants essentiels. Cette description est celle d'une architecture générique qui s'applique à toutes les plateformes sur lesquelles Oracle peut tourner. Des différences existent d'une plateforme à l'autre mais elles sont minimes.
Physiquement, Oracle est bien sûr un ensemble de fichiers. Mais Oracle est aussi un ensemble de vues logiques. Les utilisateurs de la base de données ne "voient" que le sous-ensemble de données qui leur est nécessaire. Ce sous-ensemble est une modélisation d'une partie du monde réel. Cette personnalisation des vues se fait par le biais de " user accounts ".
1. Fichiers d'Oracle
Les fichiers (tous binaires) utilisés par Oracle se subdivisent en 4 catégories : | fichiers de données
| fichiers de contrôle
| journaux
| autres fichiers (options) | |
1.1 Fichiers de données
Ces fichiers contiennent toutes les données de la base. Leur taille peut varier de quelques Méga Octets à quelques Giga Octets. Il en faut au moins un. Néanmoins, toutes les "vues" des utilisateurs ou toutes les tables peuvent tenir dans un seul fichier. En contrepartie de ce modèle trop simple, on perd en flexibilité. Les fichiers de données ont une taille fixe et ils ne dépassent jamais la taille à laquelle ils ont été créés.1.2 Fichiers de contrôle
Un fichier de ce type est indispensable. Plus il y en a, plus faible est le risque de panne au sens large. Le fichier de contrôle contient les informations suivantes : nom de la BD, date et heure de création, localisation des fichiers journaux (redo) et des informations de synchronisation. Ce fichier est constamment mis à jour, au gré de l'évolution de la BD.1.3 Journaux
Ce type de fichier enregistre tous les changements des états des objets de l'utilisateur et du système. Si un problème survient (perte d'un fichier de données par exemple), le système parcourt le journal et ramène la BD dans un état consistant sans perdre les transactions qui ont déjà été achevées par un commit . Pour les pannes (crash par exemple), le journal est aussi parcouru mais sans intervention de l'administrateur.Il y a en permanence 2 journaux " online ", exactement les mêmes, pour minimiser les risques de problèmes. (L'administrateur peut également créer 2 copies " offline " de ces fichiers.)
1.4 Autres fichiers
Un fichier texte de configuration du système, INIT.ORA pour les intimes, peut être personnalisé par l'administrateur.
2. Processus système et utilisateur
Dans l'environnemet d'Oracle, il faut considérer les processus système d'une part, et utilisateur, d'autre part.2.1 Processus système
Pour que le système Oracle fonctionne, il faut au moins que 4 processus s'exécutent en permanence en arrière-plan : | DataBase WRiter (DBWR)
| LoG Writer (LGWR)
| System MONitor (SMON)
| Process MONitor (PMON) | |
2.1.1 DataBase Writer
Son rôle est de mettre à jour les fichiers de données. Les " dirty blocks ", c'est-à-dire les blocs résidant dans la zone globale partagée (SGA pour " Shared Global Area ") qui ont été supprimés ou modifiés sont écrits dans la BD, suivant une stratégie LRU. Cette mise-à-jour se fait indépendamment des commit qui, eux, mettent à jour les journaux, pas les fichiers de données.2.1.2 Log Writer
Son rôle est simplement de mettre à jour les buffers des journaux online contenus dans la SGA et les journaux online eux-mêmes.2.1.3 System Monitor
Ce processus permet de déceler les deadlocks et de les casser en tuant un des processus qui en est à l'origine. Notons que cette méthode peut être coûteuse en calcul CPU.Une autre approche aurait été de concevoir le système de telle sorte qu'une situation de deadlock ne puisse jamais se produire, par exemple, en s'assurant qu'il n'y a pas de cycle dans le graphe des demandes des ressources. Cette dernière approche est néanmoins mal adaptée aux BD sujettes à de grandes variations. Chaque record peut en effet être considéré comme une ressource. Une BD est donc un système à nombre de ressources variable. En général, imposer la non existence de deadlocks implique une utilisation moins flexible et moins optimale des ressources.
Une dernière solution consiste à calculer la probabilité qu'une telle situation se produise. Si elle est très faible, on ne tente même pas de la déceler. Ce raisonnement n'est évidemment pas valable pour des applications critiques.
Rien n'est spécifié sur le traitement des livelocks .
Durant le reste du temps (presque 100 %, on espère...), le SMON fait des optimisations de toutes sortes (compactage, etc).
2.1.4 Process Monitor
Ce processus observe les processus utilisateur. Si l'un d'eux crashe au milieu d'une transaction, le PMON est chargé de ramener la BD dans un état stable. Il fait l'inverse du travail effectué par le processus utilisateur, en consultant les journaux.2.1.5 Processus optionnels
Les principaux processus optionnels permettent de diminuer les risques d'inconsistence : archivation, checkpoints, restauration, verrouillage, ...
Dans l'environnemet d'Oracle, il faut considérer les processus système d'une part, et utilisateur, d'autre part.
2.2 Processus utilisateur
On distingue 2 types de processus utilisateur : | Oracle Server Code
| Code spécifique de l'outil | |
La seconde catégorie implémente l'outil qui exécute réellement les commandes SQL.
3. Mémoire
Les performances du système sont directement proportionnelles à la quantité de mémoire disponible... ce qui est logique.3.1 Shared Global Area ( SGA )
Cette zone contient les structures de données qui peuvent être accédées par tous les processus en arrière-plan d'Oracle et par tous les processus utilisateur.Le contenu du SGA est subdivisé en 3 parties :
| Cache du buffer de la BD
| Zone partagée
| Cache du redo | |
3.1.1 cache du buffer
Comme toutes les caches, elle contient les blocs lus le plus récemment par les processus. Les blocs y sont ordonnés suivant une file d'arrivée. Si d'autres blocs arrivent dans la cache (pleine), les blocs les plus anciens sont jetés (et réécrits dans les fichiers de données par le BBWr s'ils ont été modifiés). La stratégie d'écriture des blocs n'est pas Write Thru.3.1.2 redo cache
La mise-à-jour des journaux ne se fait que quand la cache est pleine ou quand un commit est rencontré.L'avantage, c'est qu'on gagne en rapidité, car les accès disque sont optimisés (pas de Write Thru comme en DOS).
L'inconvénient, c'est qu'en cas de perte de données, un travail plus long devra être fourni par le système pour ramener la BD dans un état consistant. Le compromis résulte en une évaluation de probabilité de panne.
3.1.3 zone partagée
Elle comprend 2 sous-parties : | Zone SQL
| Cache du dictionnaire | |
Par contre, pour exploiter cet avantage, l'utilisateur doit être conscient qu'il vaut mieux, pour optimiser son programme, faire exactement les mêmes requêtes, même pour celles qui auraient pu êre optimisées plus efficacement individuellement. L'inconvénient résulte en la non transparence.
La seconde sous-zone est réservée par Oracle pour y stocker les tables système (informations diverses sur les objets, la sécurité, ...). Le seul but est de minimiser les accès disque en factorisant dans une cache les informations les plus souvent accédées.
3.2 Zone globale des processus
Cette zone (une par processus utilisateur ou système) contient les structures de données et de contrôle du processus qui l'accède. C'est la mémoire virtuelle adressable par le processus.3.3 Les programmes Oracle
Le code du serveur (bas niveau donc) est unique quel que soit l'outil de requête (SQL*Plus, Excel, ...). L'avantage est le gain mémoire grâce au partage du code.)Sources : itlibrary.com : le livre Oracle Unleashed 2nd edition (page 2).
NB : une nouvelle référence intéressante sur l'architecture est apparue après
le premier juillet : Oracle 8 server Unleashed (page 2).