Académique Documents
Professionnel Documents
Culture Documents
ARCHITECTURE INGRES
Sommaire
ARCHITECTURE INGRES......................................................................................................................................................1
SOMMAIRE.......................................................................................................................................................................................2
1. RAPPELS SUR LES BASES DE DONNÉES.........................................................................................................................4
1.1.VOCABULAIRE DES BASES DE DONNÉES RELATIONNELLES ET AUTRES...................................................................................................4
1.2.CONSTITUTION D’UN SGBD........................................................................................................................................................5
1.3.SÉCURITÉ ET INTÉGRITÉ...............................................................................................................................................................5
1.4.GESTION DES ACCÈS CONCURRENTS – NOTION DE TRANSACTION........................................................................................................5
2. PRÉSENTATION DE CA-OPENINGRES.............................................................................................................................6
2.1.HISTORIQUE...............................................................................................................................................................................6
2.2.VUE GÉNÉRALE..........................................................................................................................................................................6
3. ARCHITECTURE FONCTIONNELLE.................................................................................................................................7
3.1.PREMIER APERÇU........................................................................................................................................................................7
3.2.LE NOYAU.................................................................................................................................................................................8
3.2.1.Le serveur de données....................................................................................................................................................8
3.2.2.Le gestionnaire de connaissances..................................................................................................................................9
3.2.3.Le gestionnaire d'objets..................................................................................................................................................9
3.3.OUTILS DE DÉVELOPPEMENT D'APPLICATIONS.................................................................................................................................10
3.4.OUTILS UTILISATEUR.................................................................................................................................................................10
3.5.UTILITAIRES D'ADMINISTRATION..................................................................................................................................................10
4. DIFFÉRENTS TYPES D'ARCHITECTURE.......................................................................................................................11
4.1.INTRODUCTION.........................................................................................................................................................................11
4.2.ARCHITECTURE CENTRALISÉE......................................................................................................................................................11
4.3.ARCHITECTURE DISTRIBUÉE : CA-OPENINGRES / NET.................................................................................................................12
4.4.ARCHITECTURE RÉPARTIE : CA-OPENINGRES / STAR..................................................................................................................14
4.5.ARCHITECTURE RÉPLIQUÉE : CA-OPENINGRES / REPLICATOR.........................................................................................................16
5. ARCHITECTURE INTERNE................................................................................................................................................17
5.1.L’ACCÈS AUX DONNÉES – UTILISATION DU CACHE DMF................................................................................................................17
5.2.LA JOURNALISATION..................................................................................................................................................................20
5.3.GESTIONNAIRE DES COMMUNICATIONS..........................................................................................................................................20
6. AU CŒUR DU SERVEUR DE DONNÉES..........................................................................................................................23
9.3.COMMENT ?............................................................................................................................................................................38
9.4.OÙ ?......................................................................................................................................................................................38
9.5.LE DEAD LOCK..................................................................................................................................................................39
10. EN GUISE DE CONCLUSION............................................................................................................................................41
Une base de données est un ensemble structuré de données (on dit aussi intégré) modélisant un
univers réel. Ces données sont placées sur un support accessible par l'ordinateur et sont
partagées par plusieurs utilisateurs.
Au cours de l’histoire, plusieurs modèles de bases de données se sont succédés et on a tendance à dire
que chacun de ces modèles est une amélioration du précédent. C'est vrai en grande partie, mais avec une
petite réserve que nous évoquerons un peu plus loin.
Pour mieux appréhender les différences qui existent entre ces modèles, imaginons la situation suivante :
Un voyageur débarque à Roissy et désire se faire transporter par taxi rue de Courcelles dans le huitième
arrondissement.
Avec les Systèmes de Gestion de Fichiers (SGF) et le premier modèle de base de données (hiérarchique),
le chauffeur du taxi aurait pris l’itinéraire, toujours le même, fixé dans sa mémoire ou tracé sur son plan
pour se rendre à l’adresse demandée. C’est fiable à 100 % mais ne supporte aucune initiative ni aucun
« détournement ».
Avec le modèle suivant (réseau), le chauffeur aurait pu choisir entre plusieurs chemins prédéfinis. Liberté
apparente seulement puisqu’il n’a toujours pas la possibilité de faire varier son trajet une fois l’itinéraire
choisi.
En fait, jusque là, on ne pouvait résoudre un problème logique que par l’utilisation de moyens physiques
explicites.
Avec les travaux de CODD, et le modèle relationnel, le chauffeur de taxi devient intelligent ; il est capable
de définir un itinéraire tout seul en fonction, par exemple, des conditions de circulation du moment ou
d’éventuels desiderata « hors norme » du client (par exemple : en passant par un fleuriste et une
boulangerie).
Les trois niveaux précédemment cités devenant du coup autonomes, autonomie rendue possible grâce à la
programmation par les données. On s’intéresse au « quoi ? » plus au « comment ? »
Alors, quelle réserve pouvons-nous mettre à cette évolution qui semble pourtant bien pratique ?
En fait, si le modèle relationnel a mis tant de temps à percer, c’est tout simplement à cause de sa très
grande gourmandise en terme de taux d’occupation mémoire et de ressources puisqu’il faut calculer le
chemin d’accès aux données pratiquement à chaque fois. Nécessité qui n’existait pas avec le modèle
réseau qui rendait de très bons services dans une informatique de gestion moins exigeante que
maintenant.
La gestion des récipients de données sur les mémoires secondaires compose la première
couche : c'est le SYSTEME DE GESTION DE FICHIERS, entièrement lié au système
d’exploitation.
La gestion des données stockées dans les fichiers, le placement et l'assemblage de ces
données, la gestion des liens entre les données et des structures permettant de les retrouver
rapidement constitue la deuxième couche : c'est le système d'accès aux données ou SGBD
INTERNE.
Mais, ceci ne représente en fait que 50% du code des logiciels constituant un SGBD tel que INGRES. En
effet, le monde n’étant pas parfait, il a fallu prévoir de nombreuses procédures « au cas où… » pour
pouvoir assurer trois des objectifs des bases de données, la sécurité, l’intégrité et le partage des données.
Le but est d’assurer d’une part que seules les personnes autorisées pourront accéder et manipuler de
façon correcte les données de la base par :
Le contrôle des utilisateurs qui sont définis avec un ensemble de possibilités d’action (de
responsabilités) au niveau du SGBD et également un ensemble de droits d’utilisation des données
dans chacune des bases du système. Les utilisateurs devront alors s'identifier par un login et
s'authentifier par un mot de passe.
Le contrôle sur la validité des opérations effectuées par l'application de règles appelées
contraintes d'intégrité. Les plus connues étant les contraintes d'intégrité référentielle.
Et d’autre part que la base de données puisse être remise en état en cas de problème, remise en état
devant être réalisée sans redondance de travail pour les utilisateurs. Pour ce faire, il a été mis en place
des mécanismes permettant :
La protection contre les défaillances techniques, les pannes : le SGBD doit offrir des
procédures permettant la remise en état cohérent de la base en cas de problème. C'est le rôle des
mécanismes de la journalisation, de l’archivage et des sauvegardes.
Afin de garantir la cohérence des données, une attention particulière doit être portée lors des
manipulations effectuées par les différents utilisateurs. Cette cohérence est assurée au travers des
concepts de transactions et d’accès concurrents.
Une transaction est définie comme une unité logique de traitement qui, appliquée à un état cohérent des
données, restitue un nouvel état cohérent, modifié, de la base. Une transaction est dite atomique, c’est à
dire qu’elle doit être exécutée en entier ou pas du tout. Dans le cas d’une requête composée de plusieurs
opérations (transaction multi-requêtes), si une des opérations ne peut pas être effectuée, alors toute la
transaction doit être considérée comme n’ayant jamais existé.
Exemple :
Il paraît évident que pour éviter un dialogue difficile entre les deux clients A et B et le banquier, les deux
opérations doivent être indissociables et correctement effectuées ! ! Si un incident empêche la réalisation
de la deuxième opération, il faudra veiller à ce que la première soit annulée. On comprend bien dans cet
exemple ce qu’atomicité des transactions veut dire.
D’autre part, pour garantir un parallélisme d’exécution des transactions, une gestion fine des accès
concurrents est nécessaire. L’exécution simultanée de plusieurs transactions permet un haut débit
transactionnel. Cependant, il faut veiller à ce que l’exécution parallèle des transactions aboutisse au même
résultat que si elles étaient lancées séquentiellement. Pour ce faire, la solution classique consiste à gérer
un verrouillage des données. Procédé que nous étudierons au chapitre 9.
2. Présentation de CA-OpenIngres
2.1. Historique
C'est en 1970, lorsque M. CODD a proposé son fameux modèle relationnel, que plusieurs prototypes ont
été développés au sein des universités et des laboratoires de recherche.
Deux prototypes ont marqué l'histoire des bases de données relationnelles et font encore aujourd'hui
référence dans le domaine :
Le prototype SYSTEM-R développé par IBM entre 1974 et 1977, qui a donné naissance au
produit ORACLE.
Connaître l’architecture de ces deux produits permet d’appréhender sans difficultés tous les SGBD
relationnels professionnels du marché.
Il est vrai qu’aujourd’hui, grâce à sa force commerciale, ORACLE a su s’imposer majoritairement, mais il
serait fallacieux de voir là une nette supériorité technique d’un produit par rapport à l’autre.
Commercialisé depuis 1980, INGRES a été initialement développé par la société Relational Technology
fondée par les professeurs de Berkeley, Ingres a été tout d’abord racheté par ASK puis par Computer
Associates en 1994. Il est alors devenu CA-OpenIngres.
INGRES a constamment innové, offrant des fonctionnalités avancées sur le marché à ses clients et
capitalisant un savoir-faire important pour appréhender les projets stratégiques d’entreprise. Par exemple,
Ingres fut le premier système à offrir la gestion des bases de données réparties dès 1987, un L4G orienté
objet en 1990 et les objets spatiaux en 1994.
esclaves. Ce qui permet de gérer un grand nombre d’utilisateurs en acceptant une montée en charge sans
dégradation linéaire des performances.
3. Architecture fonctionnelle
L'offre produit de CA-OpenIngres est composée d'un noyau et d'un ensemble d'outils. La figure ci-dessus
illustre l'architecture fonctionnelle de CA-OpenIngres.
NOYAU : assure toutes les fonctions de base d'un SGBD, d'un dictionnaire de données et d'une couche de
langage de requêtes constituant le seul moyen d'accéder aux données.
3.2. Le noyau
Le noyau est la principale composante du SGBD. Il est composé du serveur de données et de deux
modules optionnels.
Il est basé sur une architecture multithread et multiserveur. L'architecture multithread permet de répondre à
un grand nombre d'utilisateurs simultanés sans consommation excessive de ressources. L'architecture
multiserveur permet de lancer plusieurs instances du serveur accédant simultanément à toutes les bases
de données de l'installation. Ces instances partagent un cache pour accéder aux données, aux objets, aux
requêtes compilées, aux procédures et aux contextes des transactions en cours. L'équilibre de charge
entre les différents serveurs est assuré par un serveur appelé serveur de nom. Cette possibilité ne trouvant
sa raison d’être que sur des machines multiprocesseurs.
CA-OpenIngres possède un optimiseur de requête qui détermine la stratégie optimale d'accès aux
données en se basant sur une utilisation intensive des statistiques. L'optimiseur traduit automatiquement
toute requête sous la forme d’un plan d’exécution de requête. Ce plan d’exécution représente la meilleure
façon de traiter la requête en terme de temps CPU et de nombre d’E/S.
Enfin, les procédures base de données sont des procédures écrites en L4G, compilées une seule fois et
stockées dans la base. Elles sont partagées entre tous les utilisateurs et permettent un gain de
performance, puisqu’elles s'exécutent à chaque appel d'une application sans qu’il soit nécessaire de la
recompiler, et restent valables pour tous les utilisateurs.
Module optionnel pouvant rapidement devenir indispensable, le gestionnaire de connaissance offre les
possibilités suivantes :
GESTION DES REGLES : Les règles (RULES) sont définies à partir des règles de gestion de l'entreprise
qui ne peuvent pas être traduites par des contraintes d'intégrité au niveau des tables et se présentent
comme des petites routines exécutées automatiquement à chaque mise à jour dans la base. Le
développement d'application, déchargé de ces traitements, y gagne en productivité. (Exemple : si une
requête doit créer une commande pour un client, une règle peut vérifier que le client a bien réglé toutes les
factures de plus d'un mois d'ancienneté).
GESTION DES AUTORISATIONS : Les notions de rôle et de groupe d'utilisateurs offrent une meilleure
gestion des autorisations d'accès aux données et aux applications en ajoutant une sur-couche aux
fonctionnalités déjà proposées par SQL.
GESTION DES EVENEMENTS : Les événements base de données permettent de synchroniser les
applicatifs. C'est un moyen centralisé de communiquer avec une tâche applicative en attente d'un
événement qui conditionne son comportement (insertion dans une table, atteinte d'une valeur pour un
attribut, avertissement de l'arrêt du SGBD... ).
Ce module permet de définir des données dont le type sort des sentiers battus que sont ‘integer’, ‘float’,
‘char’, ‘varchar’, ‘date’...
Des types de données complexes peuvent être définis par l'utilisateur (User-defined Data Type) ainsi que
des données de type géométrique (Spatial Data type).
Contrairement à certains SGBD qui se contentent de stocker les données de ce type sous forme binaire,
CA-OpenIngres permet leur manipulation directement sous SQL au travers de fonctions et opérateurs
associés.
MONITEUR SQL : Interface en mode ligne qui permet l'exécution interactive des commandes SQL depuis
le système d'exploitation ou l'exécution des commandes regroupées dans un fichier (script SQL).
MONITEUR ISQL : Interface interactive permettant l'édition et l'exécution des commandes SQL.
MONITEUR ESQL : Ensemble d'outils permettant l'utilisation du langage SQL dans des programmes écrits
en langage de troisième génération (C, Pascal, Cobol, Fortran...). Ces outils sont communément appelés
‘précompilateurs' ou 'interfaces programmatiques'.
ABF (Application By Forms) : Langage de quatrième génération qui permet des accès à la base de
données à travers des écrans de présentation créés avec VIFRED.
TABLES : Interface graphique permettant la manipulation des tables (définition des structures,
suppression, manipulation des données)
QBF (Query By Form) : permet de composer des requêtes à l'aide de menus, de tableaux et de touches
de fonction. Point n'est besoin de maîtriser SQL pour accéder aux données. Les requêtes construites sous
QBF peuvent être sauvegardées pour une utilisation ultérieure et intégrée dans des applications.
VIFRED (Vlsual Form EDitor) : permet la création de masque d'écran, à partir d'une proposition par
défaut de QBF personnalisable et pouvant intégrer des formules de calcul et des contrôles de saisie.
VIGRAPH (Visual GRAPHics ) : permet de présenter les résultats de requêtes SQL sous forme de
graphiques (courbes, histogrammes, diagrammes, etc... )
REPORT, RBF (Report By Form). REPORT WRITER : permettent de définir des états par défaut ou
personnalisés, simples ou paramétrés selon l'outil.
ACCESSDB : outils du DBA qui permet de gérer les utilisateurs, les accès aux bases et les espaces
disques.
4.1. Introduction
Les applications et les données d'un système d'information peuvent être localisées sur un même ordinateur
central ou sur des ordinateurs différents. On distingue trois types d'architecture :
Il y a souvent confusion entre distribuée et répartie. Une architecture répartie implique que les données de
la base sont localisées sur des ordinateurs différents.
La réplication de données permet de dupliquer une partie d'une base source vers une base cible. On parle
alors d'architecture répliquée, variante de l'architecture répartie.
D’une manière générale, nous pouvons représenter l’architecture client/serveur comme sur la figure
suivante.
CA-OpenIngres propose pour cette architecture le module INGRES/NET qui ajoute une sur-couche au
réseau et encapsule les données en provenance et à destination des modules de CA-OpenIngres.
Le schéma suivant nous présente l’architecture client/serveur mise en place chez Ingres.
Il faut alors gérer les informations nécessaires pour établir des connexions avec les machines distantes. A
chaque machine, on attribue un nom virtuel (vnode) et on définit les données permettant d’accéder à cette
machine (adresse réseau, protocole, adresse d’écoute). L’utilitaire NETUTIL permet de gérer ces
informations (dans les versions Openingres 1.x).
Chaque serveur de base de données locale est autonome par rapport aux autres serveurs et il est
administré séparément. Une panne locale ne rend pas ainsi indisponible l’ensemble des données. Les
autres bases locales restant disponibles.
La définition d’une base de données répartie à partir d’un ensemble de bases locales se fait par la
définition de liens logiques (link). Chaque lien correspondant à une table d’une base locale (dans le même
esprit qu’un nœud virtuel permet de définir logiquement un serveur de données physique dans le mode
client/serveur). Les utilisateurs consulteront alors les données de la base répartie en utilisant ces liens,
sans connaître l’emplacement physique de ces données.
5. Architecture interne
Le schéma ci-dessous nous montre l’architecture interne de CA-OpenIngres.
Autour du serveur de données, pièce centrale du système, s’articule un ensemble de processus, de zones
mémoires (buffer) et de fichiers. Les processus utilisateurs se connectent au serveur de données local (par
le serveur d’adresse) ou distant (par le serveur de communication).
Les données sont regroupées dans des pages de données, unité d’échange incontournable.
Jusqu'aux versions 1.n de CA-OpenIngres, la taille de la page est de 2048 octets (2k). Une page pouvant
contenir plusieurs occurrences d'une table, mais une occurrence ne pouvant pas être coupée entre deux
pages. Conséquence immédiate, la taille maximale d'une occurrence dans une table est de 2k caractères
(en fait, un peu moins, puisque le système se réserve 40 octets sur chaque page). A partir de la version 2,
on a la possibilité de paramétrer la taille des pages de 2k à 64k (en valeur des puissances de 2), la valeur
par défaut étant de 2k pour des raisons de compatibilité avec les versions antérieures.
A chaque fois qu’une requête arrive au serveur de données, celui-ci va voir si les pages de données
nécessaires sont présentes dans le cache. Si ce n’est pas le cas, il chargera ces pages. A chaque requête,
il est bien sûr préférable que la page de données nécessaire soit déjà en zone mémoire. Dans ce cas, le
jargon des administrateurs parle de ‘HIT’. Dans le cas contraire, lorsque la page doit être chargée, on parle
de ‘MISS’. Deux termes qui expriment bien les préoccupations en terme de performance d’accès. En fait,
un taux de 90% de ‘HIT’ est recherché. Ce taux nécessite une taille importante du cache DMF qu’il faudra
donc paramétrer en conséquence.
En ce qui concerne l’écriture des pages modifiées dans la base, deux options sont possibles. L’une qui
favorisera les performances en minimisant les accès aux disques (option avec FAST-COMMIT) et l’autre
dont l’emploi garantira un recouvrement beaucoup plus rapide en cas de panne (option sans FAST-
COMMIT) mais au détriment des performances. Dans la plupart des cas, la première option est la meilleure
(c’est en fait l’option par défaut). Toutefois, si le système est très instable et risque de tomber en panne
souvent, il sera préférable de choisir la deuxième option pour ne pas s’exposer à des recouvrements très
longs. La longueur du recouvrement s’explique par le fait qu’il est nécessaire de réexecuter les
transactions validées (commitées) et non écrites sur le disque. Pour de grosses bases de données, le
temps de recouvrement se compte en heures, ce qui aura pour conséquence de mettre les utilisateurs au
chômage technique pendant ce temps-là !
Dans le cas où le FAST-COMMIT n’est pas activé, les pages modifiées sont écrites dans la base
immédiatement au moment de la validation de la transaction. On risque bien sûr d’être amené à écrire
plusieurs fois la même page, d’où la perte de performance mentionnée plus haut. En revanche, on est sûr
que les données modifiées sont bien écrites physiquement sur les disques et qu’il n’y aura pas à revenir
dessus !
Pour profiter pleinement du FAST-COMMIT, l’écriture des pages du cache vers la base va être assurée par
des processus asynchrones (qui tournent en arrière plan), de manière totalement détachée des traitements
effectués sur les données. On ne sait jamais à quel moment la page modifiée par une transaction va être
écrite sur le disque.
En fonctionnement avec l’option FAST-COMMIT, les pages de données sont chargées au fur et à mesure
des besoins dans le cache jusqu’à ce que la limite wbstart soit atteinte. A ce moment, les processus
d’écriture asynchrone (wbthread) se déclenchent et se chargent de le vider jusqu’à la limite wbend qui
marque l’arrêt des processus esclaves. Nous constatons la persistance de page dans la zone basse du
cache. Ces pages seront vidées à des moments particuliers appelés points de consistance ou points de
synchronisation sur lesquels nous reviendrons. A ces moments-là, un processus particulier (consistency-
point thread) réalisera le vidage complet du cache, provoquant la synchronisation entre les valeurs
stockées en zone mémoire et l’état physique (sur les disques) de la base.
Le premier constat qui vient tout de suite à l’esprit est qu’il existe entre deux points de consistance une
divergence entre ce que les utilisateurs ont pu effectuer comme modification et ce qui est réellement écrit
dans la base. Divergence d’autant plus grande que le cache remplit bien son rôle (+ de 90% de HIT).
Conséquence directe : en cas de problème, toutes les données en mémoire risqueraient d’être perdues.
Heureusement, il existe un mécanisme, la journalisation, qui permet d’assurer la sécurité des données.
Le second point remarquable réside dans le fait que les divergences correspondent au contenu du cache
entre deux points de consistance. Donc, pour minimiser ces divergences, il sera judicieux d’en régler la
fréquence. Le recouvrement sera d’autant plus rapide que la période de temps entre deux points de
consistance sera courte.
5.2. La journalisation
Le principe de la journalisation est de consigner dans un fichier spécial toutes les modifications apportées
aux données de la base par chaque transaction. C’est une sorte de livre de bord du SGBD. Ce livre de
bord est appelé ‘journal des transactions’ ou ‘log file’. Le détail du contenu et du fonctionnement du LOG
FILE sera abordé au chapitre 7.
Nous avons vu qu’avec le FAST-COMMIT, le serveur peut valider une transaction (exécuter un COMMIT)
sans écrire immédiatement les pages de données physiquement dans la base. La journalisation impose
d’écrire avant toute chose dans le LOG FILE la description de la modification apportée. L’utilisation du LOG
buffer diffère du buffer DMF en ce que les informations qui y sont écrites vont être transférées dans LOG
FILE sans attendre. Ceci permettant de garantir que les écritures dans la base sont représentées par des
enregistrements dans le LOG et donc de permettre un fonctionnement totalement sécurisé du système.
GENERAL COMMUNICATION AREA (GCA) : cet élément est le plus bas niveau du GCF. C'est un
protocole utilisé pour les communications inter-processus assurant les échanges des requêtes et des
résultats sous formes de messages.
SERVEUR DE NOM (GCN) : appelé aussi name server ou serveur d’adresse, il gère la liste des serveurs
de données, des serveurs de données réparties (STAR) et des serveurs de communication disponibles
dans une installation. Il fournit aux processus utilisateurs les informations nécessaires pour se connecter à
l’un de ces types de serveur de données. Il y a un seul serveur de nom par installation.
Pour bien comprendre comment s’articulent ces différents éléments, regardons les schémas suivants.
L’application fait une demande de connexion au serveur de nom (name server ou gcn) [1]. Le gcn, véritable
annuaire des serveurs de données disponibles, renvoie à l’application l’adresse du processus serveur de
données qui convient (le choix est basé, en règle générale sur un équilibrage des charges de travail des
serveurs) [2]. L’application adresse sa requête au serveur de données désigné [3]. Le serveur de données
traite la requête [4] et retourne les résultats à l’application [5].
L’application qui se connecte [1] reçoit du gcn l’adresse du processus qui va se charger de mettre en
contact la machine client et la machine serveur : le GCC [2]. L’application transmet sa requête au gcc [3]
qui établit le dialogue (au sens réseau du terme) avec le gcc de la machine serveur [4] via le protocole
réseau (ici, en exemple, TCP/IP) et une couche d’interface propre à Ingres (Ingres/net). Ensuite, le gcc
demande au gcn de la machine serveur de lui communiquer l’adresse d’un processus serveur de données
[5] et [6]. Le gcc se comporte alors comme une application vis à vis du serveur de données qui va traiter la
requête et lui retourner le résultat [7]. Enfin, ce résultat est retransmis par le chemin inverse à l’application
sur la machine client [8] et [9].
Le SGBD CA-OpenIngres fonctionne en interne selon l'architecture client/serveur. Toute interaction avec la
base de données se fait à travers deux processus :
Un processus serveur qui reçoit toutes les demandes d'accès aux données, les analyse,
les optimise, les traite puis rend la main au processus utilisateur.
La figure suivante représente les différents modules qui constituent le serveur de données.
SYSTEME CONTROLE FACILITY (SCF) : C'est le G.O. du traitement des demandes des utilisateurs. Il
reçoit les requêtes et coordonne les actions des autres modules du serveur de données. Il assure la
maintenance des contextes d'exécution des différentes requêtes actives en architecture multithread. Il est
aussi responsable des accès aux ressources partagées telles que les sémaphores et la mémoire. Il est
également responsable de la gestion des opérations de lancement et de l'arrêt du serveur, et de
l’initialisation des sessions.
PARSER FACILITY (PSF) : Ce module assure la conversion des commandes soumises au serveur d'un
format texte en un format interne. Ce format interne est composé d'un ensemble d'opérations élémentaires
de l'algèbre relationnelle. Des informations supplémentaires extraites du dictionnaire de données, telles
que la structure des tables manipulées, les droits et les définitions des vues, sont rajoutées à la
commande. Ces informations additionnelles sont destinées à l'optimiseur pour générer un meilleur plan
d'exécution. Notons que c'est ce module qui vous informera si une erreur de syntaxe s'est
malencontreusement glissée dans la requête que vous voulez faire exécuter.
OPTIMIZER FACILITY (OPF) : C’est le module central, capital, du serveur qui élabore le plan d’exécution
optimal de la requête.
Comment ?
A partir d’un ensemble de stratégies d’accès au données, l’OPF choisit la meilleure en utilisant, pour ces
estimations, des indicateurs : TMP CPU et DISK I/O (converti en TMP CPU). Il calcule les temps CPU d’un
certain nombre de stratégies (hypothèses) à partir des informations reçues du PSF qui sont analysées et
transformées en QEP (Query Execution Plan) selon un algorithme interne mettant en jeu des données
statistiques dont la fraîcheur est primordiale ou, à défaut, en se basant sur des règles prédéterminées (ce
qui est nettement moins efficace). La meilleure de ces stratégies sera utilisée. Bien évidemment, le travail
de recherche de l’OPF n’est pas infini et s’arrête au bout d’un certain temps (TIME OUT).
Le QEP est mémorisé jusqu’à son utilisation dans le ‘QSF Pool’. Il peut également être mémorisé pour une
utilisation future dans le cas de commandes répétitives (REPEATED dans une syntaxe ESQL). Le plan
d'exécution d'une requête peut être visualisé à l'aide de la commande SET QEP.
QUERY STORAGE FACILITY (QSF) : Ce module gère la mémoire partagée nécessaire pour la
mémorisation des requêtes sous leurs différentes formes (format texte, interne et plan d'exécution). La
mémorisation temporaire ou permanente des plans d'exécution générés par le OPF permet de les ré-
exécuter.
QUERY EXECUTION FACILITY (QEF) : Ce module est en charge d'exécuter les plans d'exécution des
commandes générées par l'OPF.
RELATION DESCRIPTION FACILITY (RDF) : Ce module gère la mémorisation dans un cache des
informations relatives aux tables et aux colonnes utilisées par les commandes SQL courantes. Ces
informations sont utilisées par le parser (PSF), l'OPF et le serveur de données réparties (INGRES/STAR).
ABSTRACT DATA TYPE FACILITY (ADF) : Ce module gère toutes les actions relatives aux types de
données telles que les opérations de comparaison et de conversion. Il gère aussi tous les types de
données définis par les utilisateurs. Il effectue les opérations en virgule flottante.
DATA MANIPULATION FACILITY (DMF) : Ce module gère les opérations de chargement des données
des disques (fichiers de données) vers le cache DMF, le contrôle des transactions et les accès
concurrents, ainsi que les différents types de structures de stockage (heap, isam, hash, btree). Pour ce
faire, il utilise un système de journalisation et de verrouillage qui sera présenté plus loin.
La requête est traduite en arbre (PSF) après recherche dans le catalogue système des
intégrités, des droits et des vues (RDF via DMF).
L'arbre est traduit en plan d'exécution (OPF) après recherche dans les catalogues
systèmes des statistiques (RDF via DMF).
Les données sont renvoyées au coordinateur (SCF) qui transmet les résultats au client.
Nous avions déjà vu l’un des aspects de la journalisation qui est de garantir que les modifications
apportées aux données et non écrites physiquement sur le disque pour cause d’utilisation du fast-commit
et des écritures asynchrones ne seront pas perdues en cas de panne du serveur de données.
Un autre objectif est de permettre l’annulation d’une transaction (volontaire ou non) indépendamment des
autres.
Si on considère les traitements dans leur globalité, on ne pourra que rester en l’état 2, en conservant les
modifications de T1 et T2 ou revenir en l’état 1 (par une restore de la sauvegarde) et en annulant d’un bloc
les modifications apportées par T1 et T2. On ne pourra pas annuler une transaction sans annuler l’autre.
Par contre, si l’on écrit quelque part ce que fait la transaction T1 et ce que fait la transaction T2, il sera
possible d’utiliser ces informations pour annuler l’une des transactions sans toucher au travail de l’autre.
Le journal des transactions (log file) contient justement ces informations et le système de journalisation (ou
système de logging) fournit les outils nécessaires à son exploitation.
Le serveur de recouvrement
Le process d’archivage
Fichier unique pour chaque installation de INGRES, ce fichier est obligatoire pour que le SGBD puisse
fonctionner. Il devrait résider sur un disque rapide à faible contention d’accès, voir un disque dédié.
Le remplissage du LOG FILE se déroule de manière fort simple. Les pages de données en provenance
des LOG BUFFERS sont écrites dans le LOG par des processus spécialisés (les log-writers).
Régulièrement, un point de consistance est généré. A ce moment, rappelons que le contenu du CACHE
DMF est écrit sur les disques. A ce moment privilégié, le système écrit une information spéciale dans le
LOG FILE, qui permet de mémoriser, de photographier l’état des bases ouvertes et de noter les
transactions actives (en cours) à cet instant. La fréquence de ces points de consistance est paramétrable
(par exemple, tous les 10% de remplissage du LOG). Comme nous le verrons plus loin, le recouvrement
s’effectuant à partir du point de consistance le plus récent, il y a corrélation directe entre la fréquence de
ces points de consistance et la rapidité de recouvrement en cas de panne du serveur de données.
Le fonctionnement d’un fichier circulaire est tel que la fin de fichier se déplace dynamiquement au fur et à
mesure des écritures, ce qui posera problème lorsque la boucle sera bouclée et lorsque la fin de fichier
atteindra le début de fichier. Ce genre d’événement est tout à fait impensable pour un bon fonctionnement
du SGBD. Heureusement, tout est prévu. Notons en premier lieu que les informations utiles du log file
concernent exclusivement les transactions en cours. Les informations concernant les transactions
achevées pouvant être effacées. Il existe justement un processus qui a la charge de supprimer les
informations inutiles et de récupérer de la place dans le log file, c’est le process d’archivage.
La vie du log repose sur deux processus : celui qui écrit les informations dans le log file et celui dont la
tâche est de récupérer de la place.
Malheureusement, il peut arriver que le log file se remplisse trop vite et que le process d’archivage n’arrive
plus à suivre. Pour éviter que cette situation ne dégénère et pour protéger les informations du log file
contre un écrasement intempestif, deux indicateurs sont positionnés.
Ces deux indicateurs ou limites représentent des taux de remplissage du log file.
La première limite, appelée ‘FORCE ABORT LIMIT’, est située vers 80% de la taille du log file. Si cette
limite est atteinte, le système tente d’annuler la transaction bloquante (la plus ancienne) par un rollback
forcé, tout en laissant les autres transactions tourner. Pendant ce temps (le rollback n’est pas instantané !),
d’autres informations continuent à être inscrites sur le log file. Encore une fois, si les écritures sont
nombreuses, la deuxième limite peut être atteinte. Cette limite, appelée ‘LOG FULL LIMIT’ se positionne en
général à 95% de la taille du log file. A ce moment, le système bloque les utilisateurs et annule toutes les
transactions en cours. Il est évident qu’il est préjudiciable pour la rentabilité d’un système d‘information que
ce phénomène se produise souvent ! Si c’est le cas, l’administrateur du SGBD aura à résoudre le problème
en intervenant soit sur la taille, soit sur les paramètres du log file, soit sur le positionnement relatif des deux
limites.
Avec pour chaque mise à jour (il peut y en avoir plusieurs par transaction)
L'identifiant de la transaction
A chaque point de consistance, le process d’archivage est activé. Il regarde quelles sont les transactions
en cours et supprime du log file tous les segments qui ne contiennent pas d’informations concernant ces
transactions (un segment : espace entre deux points de consistance).
Dans notre exemple, les transactions T7 et T6 sont actives. Le process d’archivage conservera donc les
segments à partir de [PC2 – PC3]. Tout ce qui précède a été effacé, l’espace libéré est récupéré et le BOF
(Begin Of File) du log file est avancé.
8. En cas de problème
Dans ces cas, un module particulier du SGBD, le serveur de recouvrement, va œuvrer afin de rétablir dans
les meilleurs délais un état cohérent de la base. Pour se faire, la règle est simple : toute transaction
validée doit être écrite sur les disques et toutes celles qui ne le sont pas (transactions interrompues par la
panne) ne doivent pas l’être. Dans le cadre d’un système utilisant le FAST-COMMIT et les écritures
asynchrones, on va se retrouver avec des données en mémoire qui devraient être écrites et des données
sur le disque qui ne devraient pas y être. Pour s’en sortir, le serveur de recouvrement va utiliser un point de
repère fondamental : le dernier point de consistance. En effet, le système est sûr du contenu physique de
la base et des transactions qui tournaient à cet instant.
Que se soit pour une transaction (dans le cas d’un arrêt du programme d’application ou du choix de
l’utilisateur d’annuler sa transaction) ou pour l’ensemble des transactions (dans le cas d’un arrêt du serveur
de données), la technique est toujours la même. Nous allons étudier dans le schéma suivant les différents
cas possibles.
Le serveur de recouvrement va d'abord déterminer quelles sont les transactions qui ont été validées avant
la panne (dans le jargon, on parle de transactions gagnantes) et celles qui étaient actives au moment de la
panne (perdantes). Ce qu’il faut bien voir, c’est que l’utilisateur qui a reçu confirmation que sa transaction
s’est terminée correctement, n’a pas à subir de désagrément du au principe du FAST-COMMIT et des
écritures asynchrones.
Pour lui transaction validée = données écrites physiquement.
En parcourant le LOG vers l'avant à partir du dernier point de consistance, le serveur de recouvrement va
trouver les informations utiles pour remettre la base en état cohérent. Pour cela, il lui faudra finir le travail
des transactions gagnantes et annuler celui des transactions interrompues par la panne.
T1, gagnante : Validée avant le point de consistance, toutes les modifications ont été écrites dans la base.
Le serveur de recouvrement n'a rien à faire.
T2, gagnante : Au moment du point de consistance, la transaction T2 n'est pas terminée, mais les
informations contenues dans le journal indiquent qu'elle sera validée. Seule certitude, une valeur
intermédiaire a été écrite physiquement au moment du dernier point de consistance. Le serveur de
recouvrement va donc refaire les actions de T2 mémorisées dans le journal à partir du point de
consistance afin de pouvoir la valider.
T3, perdante : Au moment du point de consistance, la transaction T3 n'est pas terminée et les informations
contenues dans le journal indiquent qu'elle ne sera pas validée avant la panne. Il faut donc annuler la
transaction c'est-à-dire que toutes les modifications écrites au moment du dernier point de consistance par
T3 doivent être annulées. Cela nécessite un parcours à l'envers du journal : pour chaque modification faite,
il faut revenir à l'ancienne valeur en appliquant les ‘images avant’ et ceci jusqu'au début de la transaction
T3.
T4, gagnante : Pour l'utilisateur qui a lancé T4, sa transaction est validée. Malheureusement, les
informations n'ont pas encore été écrites dans la base. Le serveur de recouvrement va donc refaire le
travail de T4 en appliquant les ‘images après’ correspondantes du journal de transactions.
T5, perdante : Pour l'utilisateur qui a lancé T5, sa transaction s'est terminée anormalement, mais comme
aucune écriture n’a été réalisée dans la base, le serveur de recouvrement va tout simplement ignorer cette
transaction.
Quand toutes les transactions présentes entre le dernier point de consistance et le moment de la panne
ont été traitées, le serveur de recouvrement pose un point de consistance (il provoque ainsi l’écriture
physique de données qui sont toutes cohérentes !). Les transactions annulées font l'objet d'un message
d'erreur vers les utilisateurs ou applications concernées.
Notons que sans les points de consistance le serveur de recouvrement devrait traiter tout le fichier LOG, ce
qui serait bien évidemment plus long. Ce qui nous conforte dans l’idée que la fréquence des points de
consistance influe directement sur la rapidité du recouvrement dans ce type de panne.
Même si cela n’arrive pas souvent, une panne des disques sur lesquels sont stockées les bases (style
atterrissage de tête) peut survenir et les rendre inutilisables.
En matière de sécurité des données, nous avons tous la très bonne habitude d’effectuer régulièrement des
sauvegardes. Tout SGBD digne de ce nom propose un ensemble de mécanismes permettant la mise en
œuvre des sauvegardes. Charge à l’administrateur de définir sa stratégie qui découle directement de la
philosophie de l’entreprise.
Si le disque est détruit, les données sont perdues. Il faudra donc recharger une copie de la sauvegarde la
plus récente. Imaginons qu’une sauvegarde est réalisée tous les matins à 7h00 et que la panne survienne
à 16h00. En rechargeant la sauvegarde de 7h00 (que l’on appelle sauvegarde statique), tout le travail
effectué entre la sauvegarde et la panne est définitivement perdu. Dans le meilleur des cas, les utilisateurs
auraient à refaire par eux-mêmes le travail perdu. Dans le pire des cas, ce procédé ‘manuel’ n’est même
pas envisageable (trop long, trop cher, trop complexe…) et l’entreprise aura du mal à se relever de cet
accident. Parfois, dans le cas où les données évoluent vraiment très peu, la sauvegarde statique est
suffisante. Dans tous les autres cas (les plus courants) cette situation n’est pas viable.
Le SGBD CA-OpenIngres, comme d’autres, propose une solution technique remarquable : l’archivage du
log file.
Lorsque le process d’archivage supprime les informations inutiles du log file (c’est-à-dire, rappelons le,
celles qui concernent les transactions terminées), il les enregistre dans des fichiers spéciaux (les fichiers
d’archives). Entre deux sauvegardes statiques, le système crée un fichier d’archives. La combinaison de la
sauvegarde statique et du fichier d’archives permet non seulement de recharger la sauvegarde mais aussi
de refaire automatiquement le travail perdu. Pendant le temps que dure la remise en état de la base, les
utilisateurs ne seront pas autorisés à se connecter, mais c’est un moindre mal, puisqu’ils auront la certitude
de récupérer les données dans l’état le plus récent possible. Seules les transactions en cours au moment
de la panne seront perdues.
9.1. Pourquoi ?
Dans un système d'information fondé sur les bases de données, plusieurs usagers vont se partager la
même base. Partager, c'est-à-dire vouloir accéder à la même donnée au même moment. A titre d'exemple,
citons le système de réservation de billet de train. Il s'agit de gérer des dizaines de millions d'octets
d'information et des centaines de transactions par seconde. On comprend facilement qu'il faut éviter de
réserver deux (ou plusieurs) fois la même place. La nécessité de mettre en place un système pour gérer
les conflits que pourrait engendrer la concurrence d'accès apparaît évidente.
Ici, l'écriture effectuée par la transaction 2 écrase celle faite par la transaction 1. En effet, la valeur finale
après une exécution correcte des transactions aurait dû être A = A - n + m. Or, elle sera dans notre
exemple de A = A + m puisque la transaction 2 utilise la valeur initiale de A, avant que la modification
apportée par la transaction 1 ait été enregistrée.
A l'inverse du cas précédent, la transaction 2 utilise bien la valeur modifiée par la transaction T1 pour
effectuer sa mise à jour. Tout serait pour le mieux (on aurait bien A = A - n + m) mais, par malchance, la
transaction 1 est annulée. C'est-à-dire que l'opération A = A - n est invalidée et de ce fait, la transaction 2
utilise une valeur incohérente de A.
En fait, pour le bonheur de tout le monde, il aurait fallu que tout se passe comme si les transactions 1 et 2
s'exécutaient de manière séquentielle. On appelle cela la sérialisation des transactions. Les SGBD dignes
de ce nom doivent garantir cette fonction.
CA-OpenIngres met en œuvre un principe de verrouillage pour résoudre ce problème. Cette méthode est
basée sur les règles suivantes :
Pendant que je lis une information, d'autres peuvent la lire en même temps.
9.3. Comment ?
Le SGBD, responsable de la gestion des accès concurrents, va devoir se débrouiller pour que tout se
passe bien. Il va donc appliquer une politique de verrouillage très simple :
Lorsqu'une transaction veut mettre à jour une donnée, elle doit d'abord poser un verrou
exclusif (exclusive lock)
Lorsqu'une transaction veut lire une donnée, elle doit d'abord poser un verrou partagé
(shared lock)
On ne peut pas poser de verrou exclusif sur une donnée déjà verrouillée On ne peut
pas modifier une donnée qui est lue par un autre utilisateur
On ne peut pas poser de verrou partagé sur une donnée verrouillée exclusivement On
ne peut pas lire une donnée qui est mise à jour par un autre utilisateur.
On peut poser un verrou partagé sur une donnée ayant déjà un verrou partagé Plusieurs
utilisateurs peuvent lirent simultanément la donnée.
Si une transaction doit poser un verrou et qu'elle ne peut pas, elle attend (par défaut
indéfiniment, mais ce temps d'attente est, heureusement, paramétrable).
9.4. Où ?
Dans un souci de performances, il faut cibler au plus juste la quantité d'informations verrouillée. Pour cela,
le système offre la possibilité de placer des verrous à plusieurs niveaux :
Au niveau de la base, ce qui est impensable en mode de production puisque cela va induire de très fortes
pertes de performances dans le cas de mises à jour faites par de nombreux utilisateurs. Toutefois, ce
niveau de verrouillage peut être utilisé par l'administrateur pour certaines opérations particulières.
Au niveau de la table, ce qui implique que toute une table sera verrouillée pour un seul utilisateur quel
que soit le nombre d'occurrences qu'il utilise.
Au niveau de la page de donnée, c'est le niveau de verrouillage le plus fin chez CA-OpenIngres. Seule
une partie des données de la table, celles contenues dans la même page que l'occurrence utilisée, sera
verrouillée.
Au niveau de l’occurrence, pour les dernières versions des SGBDR. Cette technique est très gourmande
en ressource et nécessite de grosses puissances de calcul.
Toutefois, en fixant à 1 le nombre d’occurrences par page, il est possible de simuler un verrouillage au
niveau occurrence à moindre coût (il faudra toutefois prévoir un espace disque beaucoup plus grand).
Le système de verrouillage de CA-OpenIngres pose par défaut les verrous au niveau page. Toutefois, s'il
estime avant son exécution qu'une requête va verrouiller un nombre important de pages ou si en cours
d'utilisation le nombre de pages verrouillées augmente, il peut faire évoluer le verrouillage au niveau table.
C'est ce qu'on appelle l'escalade du verrouillage. Le nombre de pages maximum autorisé avant l'escalade
est contenu dans la variable maxlocks qui vaut 10 par défaut et peut être modifié.
L'escalade au niveau table pourra se faire, par exemple, lorsque la requête n'est pas assez restrictive (pas
de clause where dans la commande SQL).
Prenons un exemple.
Que se passe-t-il ?
L'utilisateur 1 pose un verrou partagé sur la table employé (niveau table car non restrictive).
L'utilisateur 2 pose un verrou partagé sur la table département (niveau table car non restrictive).
L'utilisateur 1 a besoin d'un verrou exclusif au niveau page sur la table département. Il doit attendre car la
table est verrouillée.
L'utilisateur 2 a besoin d'un verrou exclusif au niveau page sur la table employé. Il doit attendre car la table
est verrouillée.
L'utilisateur 1 attend donc que l'utilisateur 2 libère ses verrous, ce qu'il ne pourra faire que lorsqu'il aura
terminé son travail, ce qu'il ne peut pas faire, puisqu'il attend la table bloquée par l'utilisateur 1 qui attend
que l'utilisateur 2 … BLOQUAGE !
La cause principale est un mauvais découpage des transactions. Les verrous partagés posés pour les
select auraient du être libérés avant l'exécution des requêtes de mises à jour.
L'utilisateur 1 commence à accumuler les verrous exclusifs au niveau page sur la table employé.
L'utilisateur 2 commence à accumuler les verrous exclusifs au niveau page sur la table employé.
L'utilisateur 1 a besoin d'accéder à des données contenues dans une page verrouillée par l'utilisateur 2.
L'utilisateur 2 a besoin d'accéder à des données contenues dans une page verrouillée par l'utilisateur 1.
BLOCAGE ! Une solution consisterait ici à forcer un verrouillage au niveau table dès le début de la
transaction, ou de découper physiquement la table en domaine si cela correspond à une règle de travail de
l’entreprise.
Dans ces cas de deadlock, l'attente pourrait être infinie. Mais le système au bout d'un certain temps va
décider d'annuler une des deux transactions. L'utilisateur lésé sera averti.
Enfin, si tous ces produits proposent de nombreux outils et répondent aux attentes des entreprises en
matière de système d’information, n’oublions pas le rôle capital du personnage clé qu’est l’administrateur
du SGBD qui devra surveiller, régler et optimiser le fonctionnement de l’ensemble.