Architecture Ingres V4

INGRES

Architecture Technique INGRES

ARCHITECTURE INGRES

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 1 sur 41

INGRES

Architecture Technique 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 7. LES MÉCANISMES DE LA JOURNALISATION.............................................................................................................26 7.1.LES OBJECTIFS..........................................................................................................................................................................26 7.2.LES MOYENS............................................................................................................................................................................27 7.3.LE FICHIER LOG.....................................................................................................................................................................28 7.3.1.Topologie du fichier LOG.............................................................................................................................................28 7.3.2.La vie du fichier LOG...................................................................................................................................................28 7.3.3.Le contenu du fichier LOG...........................................................................................................................................31 7.4.LES LOG BUFFERS............................................................................................................................................................31 7.5.LE FICHIER LOG DUAL.........................................................................................................................................................31 7.6.LE PROCESS D’ARCHIVAGE.........................................................................................................................................................32 8. EN CAS DE PROBLÈME.......................................................................................................................................................33 8.1.PANNES DU SERVEUR DE DONNÉES : MÉCANISME DE RECOUVREMENT.................................................................................................33 8.2.PANNE DU DISQUE : SAUVEGARDE ET ARCHIVAGE...........................................................................................................................34 9. GESTION DES ACCÈS CONCURRENTS..........................................................................................................................36 9.1.POURQUOI ?............................................................................................................................................................................36 9.2.SANS VERROUS, QUE SE PASSERAIT-IL ?........................................................................................................................................36 DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 2 sur 41

INGRES

Architecture Technique INGRES

9.3.COMMENT ?............................................................................................................................................................................38 9.4.OÙ ?......................................................................................................................................................................................38 9.5.LE DEAD LOCK..................................................................................................................................................................39 10. EN GUISE DE CONCLUSION............................................................................................................................................41

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 3 sur 41

INGRES

Architecture Technique INGRES

1. Rappels sur les bases de données 1.1. Vocabulaire des bases de données relationnelles et autres Les définitions concernant les bases de données que vous avez pu rencontrer dans d’autres cours, voir d’autres lieux, ressemblent sans doute à ceci : 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. Un SGBD (système de gestion de base de données) est un ensemble de logiciels permettant la gestion et le contrôle des accès aux données de la base et aux programmes qui les manipulent. 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. On peut considérer que le problème se pose à plusieurs niveaux : Niveau conceptuel Niveau logique Niveau physique

  

règle de conduite, de circulation, de fonctionnement du taxi… formalisation du problème particulier (aller à…) utilisation de moyens pour résoudre le problème (passer par…)

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.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 4 sur 41

INGRES

Architecture Technique INGRES

1.2. Constitution d’un SGBD Un SGBD est présenté traditionnellement sous la forme d’un système en trois couches :  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.  La présentation des données aux programmes d'applications et aux usagers terminaux ayant exprimé leurs besoins à l'aide de langages plus ou moins élaborés, constitue la fonction essentielle de la troisième couche : c'est le SGBD EXTERNE qui assure d'une part, l'analyse et l'interprétation des requêtes des usagers et d'autre part, la mise en forme des données échangées avec le monde réel. 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.

1.3. Sécurité et intégrité 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.

1.4. Gestion des accès concurrents – Notion de transaction Un des objectifs, et non des moindres, d’un système d’information fondé sur les bases de données est de mettre à la disposition d’un grand nombre d’utilisateurs un ensemble cohérent de données. Ces données vont donc être manipulées simultanément par un grand nombre d’utilisateurs. 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

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 5 sur 41

INGRES

Architecture Technique INGRES

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 : La transaction T effectue un virement de 100 F du compte A vers le compte B. Les opérations nécessaires sont : 1) MODIFIER COMPTE A = COMPTE A – 100 2) MODIFIER COMPTE B = COMPTE B +100 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. 

Le prototype universitaire INGRES, développé à l'université de Berkeley à partir de 1973.

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.

2.2. Vue générale CA-OpenIngres est un progiciel modulaire dont le noyau est un SGBDR composé de divers process (au sens UNIX du terme), permettant une gestion efficace de la mémoire associée. Le processus serveur, au centre de l’architecture, agit comme un véritable système d’exploitation qui s’appuie fortement sur le système hôte en gérant le partage des tâches et en déléguant certaines fonctions à des processus

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 6 sur 41

INGRES

Architecture Technique INGRES

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 3.1. Premier aperçu

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. OUTILS DE DEVELOPPEMENT : Outils permettant le développement d'applications construites autour du SGBD. OUTILS UTILISATEURS : Outils destinés aux utilisateurs néophytes.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 7 sur 41

INGRES

Architecture Technique INGRES

UTILITAIRES : Ensembles de fonctions destinées aux administrateurs. OUTILS DE COMMUNICATION : Outils permettant l'utilisation de CA-OpenIngres en environnement réseau.

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.

3.2.1. Le serveur de données C'est lui qui assure les fonctions classiques d'un SGBD R :  Définition et manipulation de données au travers d’un langage propriétaire (QUEL) et d'un langage standard (SQL). 

Cohérence et intégrité des données

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 8 sur 41

INGRES

Architecture Technique INGRES



Confidentialité des données



Sauvegarde et restauration des données



Gestion des transactions et des accès concurrents

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.

3.2.2. Le gestionnaire de connaissances 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é). CONTROLE DES RESSOURCES : Un contrôle de la consommation excessive des ressources (processus, mémoire... ) pour chaque utilisateur permet de repérer les excès et de prévenir le blocage des applications en exploitation. 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... ).

3.2.3. Le gestionnaire d'objets 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).

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 9 sur 41

INGRES

Architecture Technique INGRES

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.

3.3. Outils de développement d'applications Autour d'une base de données, CA-OpenIngres permet le développement d'applications grâce à divers outils : 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'. CA-OPENROAD : Outils de développement de quatrième génération qui permet la génération d'applications dans un environnement graphique. 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. VISION : Générateur d'applications dans un environnement semi-graphique. Le développeur compose une hiérarchie de modules en désignant pour chaque module une vue externe de la base et un type d'action. L'application est automatiquement générée à partir de ces éléments. Le produit pouvant être finalisé grâce à un éditeur de masque d'écran et un L4G. Vision permet aussi d'intégrer des modules externes.

3.4. Outils utilisateur Les outils utilisateur permettent un accès simplifié aux données. 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. On peut accéder à l'ensemble de ces outils par l'utilitaire INGMENU

3.5. Utilitaires d'administration L'ensemble des outils d'administration apporte aux administrateurs de bases de données et à l'administrateur du SGBD un ensemble de fonctionnalités étendues. Citons-en quelques-uns : CBF (Configure By Form) : outils interactifs de configuration de l'installation du SGBD. IPM (Interactive Performance Monitor) : permet de visualiser différents aspects du fonctionnement de CA-OpenIngres (état des verrous, statistiques, état des connexions, transactions actives... ) DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 10 sur 41

INGRES

Architecture Technique INGRES

ACCESSDB : outils du DBA qui permet de gérer les utilisateurs, les accès aux bases et les espaces disques.

4. Différents types d'architecture 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 : ARCHITECTURE Centralisée Distribuée Répartie (avec ou sans duplication)

LOCALISATION DES DONNEES Ordinateur central Ordinateur central Ordinateurs distants

LOCALISATION DES TRAITEMENTS Ordinateur central Ordinateurs distants Ordinateurs distants

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.

4.2. Architecture centralisée Ce type d'architecture est la plus simple à mettre en place et correspond aux premières générations de SGBD qui étaient gérées par de gros systèmes (mainframe). A L'ESAT, CA-OpenIngres fonctionne ainsi. Les différentes applications (dont les outils CA-OpenIngres) sont installées sur le serveur.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 11 sur 41

INGRES

Architecture Technique INGRES

4.3. Architecture distribuée : CA-OpenIngres / NET Dans cette architecture, première génération du concept Client/Serveur, la gestion des données est assurée par un ordinateur central (le serveur) tandis que les applications utilisant ces données sont situées sur des machines distantes (les clients). Ici, ce sont les traitements qui sont distribués entre ordinateurs différents. Les données sont toujours centralisées D’une manière générale, nous pouvons représenter l’architecture client/serveur comme sur la figure suivante.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 12 sur 41

INGRES

Architecture Technique INGRES

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.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 13 sur 41

INGRES

Architecture Technique 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).

4.4. Architecture répartie : CA-OpenIngres / STAR L’approche répartie des bases de données nécessite l’existence d’un référentiel commun décrivant l’ensemble de données constituant la base de données répartie. Ce référentiel est appelé aussi schéma conceptuel global. Au niveau physique, les données sont stockées dans des bases de données locales gérées par des SGBD identiques ou différents. Cette répartition est transparente pour les utilisateurs qui voient l’ensemble de données comme une seule et unique base de données. 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.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 14 sur 41

INGRES

Architecture Technique INGRES

Le module CA-OpenIngres/STAR est un serveur de données fédérateur d’un ensemble de bases de données locales. 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.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 15 sur 41

INGRES

Architecture Technique INGRES

4.5. Architecture répliquée : CA-OpenIngres / Replicator L'utilisation de la duplication de données (réplication) est rendue possible grâce à CAOpenlngres /Replicator. Les avantages majeurs de ce procédé sont une meilleure disponibilité des données et une diminution des coûts de télécommunication par rapport à l’architecture répartie. La réplication se fait par propagation des mises à jours effectuées sur une base source vers une ou plusieurs bases cibles. Elle est assurée de façon complètement transparente par rapport à l'applicatif.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 16 sur 41

INGRES

Architecture Technique INGRES

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).

5.1. L’accès aux données – utilisation du cache DMF. Contrairement à ce que l’on pourrait croire, les données ne sont pas manipulées directement dans la base, mais dans une zone mémoire particulière appelée cache base de donnée ou cache DMF. 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,

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 17 sur 41

INGRES

Architecture Technique INGRES

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 FASTCOMMIT) 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. Le schéma suivant nous montre la topologie du buffer DMF.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 18 sur 41

INGRES

Architecture Technique INGRES

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 (consistencypoint 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.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 19 sur 41

INGRES

Architecture Technique INGRES

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.

5.3. Gestionnaire des communications Le gestionnaire de communication (General Communication Facility ou GCF) est un ensemble de services et de protocoles assurant la gestion des communications entre les différents composants de CAOpenIngres. Il est composé de trois éléments : 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 COMMUNICATION (GCC) : ce serveur se présente comme un processus qui est responsable de la communication entre un processus client et un serveur de données à travers le réseau. Il est utilisé par INGRES/NET. Il peut y avoir plusieurs serveurs de communication (en cas de protocoles différents ou de fort débit par exemple). 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.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 20 sur 41

INGRES

Architecture Technique INGRES

Dans le cas d’une architecture centralisée

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].

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 21 sur 41

INGRES

Architecture Technique INGRES

Dans le cas d’une architecture client / serveur

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].

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 22 sur 41

INGRES

Architecture Technique INGRES

6. Au cœur du serveur de données Le grand maître de cérémonie du SGBD est le serveur de données. C’est lui qui en définitive traite la requête fournie par l’application. Un serveur de données est composé de modules dont chacun est spécialisé dans l’étape du traitement d'une requête. 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 client qui assure toutes les taches de présentation et de calcul.

 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.

Détaillons le rôle de chaque module : DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 23 sur 41

INGRES

Architecture Technique INGRES

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. Résumons le déroulement d'une requête: 

La requête arrive sur le coordinateur (SCF).



Le texte de la requête est stocké (QSF).

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 24 sur 41

INGRES

Architecture Technique INGRES  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). 

Cet arbre est stocké (QSF).

 L'arbre est traduit en plan d'exécution (OPF) après recherche dans les catalogues systèmes des statistiques (RDF via DMF). 

Ce plan d'exécution est stocké (QSF).



Gestion de l'exécution (QEF et éventuellement ADF) et recherche des données (DMF).



Les données sont renvoyées au coordinateur (SCF) qui transmet les résultats au client.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 25 sur 41

INGRES

Architecture Technique INGRES

7. Les mécanismes de la journalisation 7.1. Les objectifs Pour présenter très globalement le but du système de journalisation, on pourrait dire qu’il permet d’assurer la cohérence des bases de données. 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. Regardons le schéma suivant.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 26 sur 41

INGRES

Architecture Technique INGRES

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.

7.2. Les moyens Le système de journalisation comprend plusieurs éléments : 

Le fichier LOG (journal des transactions)



Un fichier LOG DUAL (réplication automatique et optionnelle du fichier LOG)



Les log buffers



Le serveur de recouvrement



Le process d’archivage

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 27 sur 41

INGRES

Architecture Technique INGRES

7.3. Le fichier LOG 7.3.1. Topologie du fichier LOG Le fichier LOG est un fichier circulaire de taille fixe ( par défaut 16 Mo, mais en général plus grand) dans lequel sont consignées les informations permettant de défaire les transactions (rollback) et de retrouver une base cohérente après un crash du système ou du serveur de données. 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é.

7.3.2. La vie du fichier LOG 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 DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 28 sur 41

INGRES

Architecture Technique INGRES

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.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 29 sur 41

INGRES

Architecture Technique INGRES

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.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 30 sur 41

INGRES

Architecture Technique INGRES

7.3.3. Le contenu du fichier LOG Le journal des transactions est composé d'articles qui indiquent les événements principaux qui affectent la base de données : 

Début d'une nouvelle transaction



Fin d'une transaction (avec la confirmation des mises à jour)



Annulation d'une transaction



Création des points de consistance

Avec pour chaque mise à jour (il peut y en avoir plusieurs par transaction) 

L'identifiant de la transaction



L'identifiant de l'occurrence modifiée



L'ancienne valeur (image avant) de la donnée modifiée



La nouvelle valeur (image après) de la donnée modifiée

7.4. Les LOG BUFFERS Nous avons vu qu’avec le FAST-COMMIT, le serveur peut valider une transaction (exécuter un COMMIT) sans que les pages de données soient écrites 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 le log file sans attendre. Ceci permettant de garantir que les écritures dans la base sont représentées par des enregistrements dans le fichier log et donc de permettre un fonctionnement totalement sécurisé du système. Autre différence notable, alors que la taille du buffer DMF se compte en dizaine de Mo (au minimum !), le LOG BUFFER se mesure en dizaine de ko.

7.5. Le fichier LOG DUAL Contrairement au fichier LOG, le fichier LOG DUAL est facultatif. Son rôle est de suppléer en ligne au LOG FILE si celui-ci vient à tomber en panne. Ces deux fichiers sont rigoureusement identiques et tout ce qui est écrit sur le LOG est écrit en parallèle sur le LOG DUAL. En cas de problème, le système bascule sur le LOG DUAL de manière transparente pour les utilisateurs qui peuvent donc continuer à travailler.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 31 sur 41

INGRES

Architecture Technique INGRES

7.6. Le process d’archivage Comme nous l’avions dit précédemment, le rôle du process d’archivage est de faire le ménage dans le LOG FILE. La question est : comment déterminer les informations à supprimer ? Regardons le schéma suivant :

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é.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 32 sur 41

INGRES

Architecture Technique INGRES

8. En cas de problème 8.1. Pannes du serveur de données : mécanisme de recouvrement Le premier type de problème qui peut se présenter est la panne du serveur de données, c’est à dire du logiciel qui traite les requêtes. Dans la même catégorie, nous pouvons également mettre le bug dans le programme d’application (celui qui émet la requête) ou la simple volonté d’un utilisateur d’annuler une transaction pour convenance personnelle. 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.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 33 sur 41

INGRES

Architecture Technique INGRES

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. Regardons nos cinq transactions : 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.

8.2. Panne du disque : sauvegarde et archivage 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 DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 34 sur 41

INGRES

Architecture Technique INGRES

à 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.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 35 sur 41

INGRES

Architecture Technique INGRES

9. Gestion des accès concurrents 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.

9.2. Sans verrous, que se passerait-il ? Dans les deux exemples suivants, on considère qu'il n'y a pas de mécanisme permettant de gérer les accès concurrents. Un premier exemple est celui de l'écriture perdue.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 36 sur 41

INGRES

Architecture Technique INGRES

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. Un deuxième exemple, le cas de la lecture incohérente.

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.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 37 sur 41

INGRES

Architecture Technique INGRES

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, personne ne doit pouvoir la modifier



Pendant que je modifie une information, personne ne doit pouvoir y accéder.



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 : LECTURE  Verrou partagé (SHARED LOCK) MISE A JOUR  Verrou exclusif (EXCLUSIVE LOCK)  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). 

Lorsque la transaction se termine, elle libère les verrous.

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). DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 38 sur 41

INGRES

Architecture Technique INGRES

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).

9.5. Le DEAD LOCK Une mauvaise utilisation des possibilités des SGBD (structures des bases ou conception des transactions) peut aboutir à ce que le système de verrous soit perturbé. Prenons un exemple.

Que se passe-t-il ? L'utilisateur 1 pose un verrou partagé sur la table employé (niveau table car non restrictive).

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 39 sur 41

INGRES

Architecture Technique INGRES

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. Prenons un autre exemple.

L'utilisateur 1 commence à accumuler les verrous exclusifs au niveau page sur la table employé.

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 40 sur 41

INGRES

Architecture Technique INGRES

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 1 attend la fin de la transaction de l'utilisateur 2 et le déblocage des verrous de celui-ci. L'utilisateur 2 a besoin d'accéder à des données contenues dans une page verrouillée par l'utilisateur 1. L'utilisateur 2 attend la fin de la transaction de l'utilisateur 1 et le déblocage des verrous de celui-ci.

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.

10.

En guise de conclusion Nous avons découvert au travers de CA-OpenIngres les grandes lignes de l’architecture des SGBD Relationnels. D’autres SGBD existent sur le marché, celui-ci n’était qu’un (bon) exemple. Même si certaines divergences peuvent apparaître d’un produit à l’autre, la philosophie et les concepts sont communs à tous les vrais SGBDR. 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. Mais ceci est une autre histoire…

DMSI/ANALYSE/MST du jj/10/OO

ATI V 4.0

Page 41 sur 41