Bases de données réparties sous Oracle

PARTIE I. BASES DE DONNEES REPARTIES

I. PROBLEMATIQUE ET AVANTAGES

I.1. PROBLEMATIQUE

Comme nous l'avons mentionné à l'introduction, les BDR (Bases de données réparties) sont d'abords des bases de données normales. En fait, elles sont issues de l'évolution de ces dernières.

En effet, la gestion de bases de données avec le temps, s'est confrontée à divers problèmes qui sont :

> L'augmentation du volume de données

> l'augmentation du volume de traitements

> l'augmentation du volume de transactions

> etc.

Cela a entraîné la lenteur des applications, car les périphériques de stockage submergés, ne répondant pas assez vite. Aussi, il a été noté que les débits des liaisons réseaux évoluaient beaucoup plus vite que les capacités des périphériques de stockage.

Ainsi, l'idée est venue de multiplier les sources de données et les faire communiquer par réseau, afin de bénéficier de traitements parallèles, minimisant ainsi les temps de réponses. Aujourd'hui, les BDRs sont de plus en plus répandus, et comblent largement les lacunes des bases de données classiques.

I.2. AVANTAGES

Les avantages d'une base de données sont nombreux. On peut citer comme principaux :

> Le gain en performances : les traitements se font en parallèles

> La fiabilité : Si un site a une panne, un autre peut le remplacer valablement.

> La transparence des données : les développeurs et les utilisateurs n'ont pas à se préoccuper de la localisation des données qu'ils utilisent.

II. LES DIFFERENTES ARCHITECTURES

Dans un environnement de bases de données réparties, il existe 2 principaux types d'architectures :

II.1. L'ARCHITECTURE CLIENT-SERVEUR

Figure 1: Architecture Client-Serveur

Dans cette architecture, l'application client se connecte au serveur de base de données (ici Oracle). Ce dernier à son tour, leur renvoie des réponses en fonction de leurs requêtes.

II.2. L'ARCHITECTURE SERVEUR-SERVEUR

Dans un système de bases de données réparties, il existe en général plusieurs serveurs de données qui fonctionnent selon l'architecture suivante :

Figure 2 :Architecture serveur-serveur

Chaque serveur gère sa base de données et échange les informations avec les autres. Le tout est vu comme une seule base de données logique.

De façon globale voici comment fonctionne un système de base de données réparties :

Figure 3 Architecture générale

Les clients se connectent à leurs serveurs respectifs, et ces derniers s'échangent les informations si nécessaires.

III. CONCEPTION D'UNE BASE DE DONNEES REPARTIES

Comme dans tous les mécanismes, la phase de conception est la plus importante et déterminante dans la mise en place d'une base de données reparties. Le rôle du concepteur est de définir les différents fragments de la base et, leurs localisations ; d'évaluer les différents coûts de stockage et de transfert, et les priorités à respecter. On distingue deux principaux types de conception : la conception ascendante et la conception descendante.

III.1. LA CONCEPTION ASCENDANTE OU BOTTUM UP DESIGN

Dans ce cas de figure, il existe plusieurs bases de données disjointes qu'il faut réunir en une seule base de données reparties et cohérente avec un schéma de conception global.

III.2. LA CONCEPTION DESCENDANTE OU TOP DOWN DESIGN

Ici, on a au départ une seule base de données qu'il faut fragmenter et allouer les fragments aux différents sites. On va donc d'un schéma global de conception a des sous schémas locaux.

III.3. LA FRAGMENTATION

La fragmentation désigne le découpage de la base globale en sous bases selon les critères d'analyse. Le concepteur choisi entre un découpage horizontal, vertical ou mixte.

III.3.A. LA FRAGMENTATION HORIZONTALE

Cette fragmentation consiste à faire une séparation selon les enregistrements. On définit le critère de sélection suivant les valeurs d'un ou plusieurs champs et la division est faite. Par exemple dans le cas d'une gestion de contrats, on peut séparer les contrats signés à Rabat de ceux signés à Casablanca.

III.3.B. LA FRAGMENTATION VERTICALE

Ici, la division est faite non au niveau des données, mais de la structure même de la base. Certains champs sont envoyés dans un fragments et d'autres ailleurs. En continuant avec l'exemple des contrats, on peut avoir d'une part le numéro du client , son nom et prénom, et d'autre part le numéro du client, le lieu d'habitation, et lieu du contrat.

La fragmentation mixte consiste à utiliser conjointement les deux méthodes citées ci-dessus.

III.3.C. LES TROIS REGLES DE LA FRAGMENTATION

La fragmentation doit respecter trois principales règles.

· Pour toute donnée de la relation originale R il doit avoir une sous relation Ri la contenant.

· Pour toute fragmentation de la relation R en plusieurs sous relations Ri il doit avoir un procédé inverse de reconstitution de la relation principale R.

· Aucune donnée ne doit se trouver dans plus d'un fragment sauf dans le cas d'une fragmentation verticale ou la clé primaire doit être présente partout.

III.4. L'ALLOCATION

Lorsque le concepteur a fini de fragmenter sa base, il lui faut ensuite allouer chaque fragment sur son site correspondant. Cette phase est appelée Allocation. L'allocation peut être faite de plusieurs façons :

> La réplication totale des données

Pour des raisons de fiabilité on peut décider de répliquer toutes les données sur tous les sites. Ainsi, si un site est temporairement ou définitivement défaillant, on utilise simplement un autre. Mais cette méthode n'est pas très efficace lorsque les données sont régulièrement mises à jour car il se pose le problème de cohérence de données

Rapport de fin de cycle Ingénierie Informatique

> L'absence de réplication

On peut aussi choisir de ne rien répliquer afin d'assurer une meilleur cohérence de données. Ici, chaque donnée est mise à jour sur un seul site. Cette méthode est plus efficace quand les données sont beaucoup plus modifiées que lues.

> La méthode hybride

Afin de bénéficier des deux méthodes citées à la fois, celle hybride peut être utilisé. Ainsi les données en Read Only peuvent être répliquées et les données en Read Write pas du tout.

IV. LES TRANSACTIONS REPARTIES

IV.1. DEFINITIONS

Une transaction désigne un ensemble d'opérations effectuées de manière indivisible sur une base de données.

Elle est soit validée par un Commit, soit annulé par un rollback soit interrompue par un abort. Afin de garantir la stabilité du système, une transaction doit validée quatre propriétés indispensables :

> L'Atomicité

Cette propriété signifie que toutes les opérations d'une transaction sont menées de façon indivisible ; toutes le opérations doivent être validées, si non tout est annulé.

> La cohérence

La transaction doit amener le système d'un état cohérent vers un état cohérent, telles que toutes les contraintes d'intégrités soient respectées.

> L'isolation

Une transaction en cours ne peut révéler ses résultats à d'autres transactions si toutes ces opérations n'ont pas été validées.

> La durabilité

Tout résultat produit par une transaction doit être permanent et ne doit souffrir d'aucune altération, quelques soient les pannes du système.

IV.2. CONTROLE DE CONCURRENCE

Afin d'améliorer les performances dans les traitements de bases de données, il est utile de mener en parallèles plusieurs transactions. Dans ce cas, des mécanismes sont mis en place pour gérer leurs accès concurrents aux données.

IV.3. MECANISMES UTILISES

IV.3 .A. VERROUILLAGE

La méthode la plus utilisée pour gérer des accès concurrents est bien sûr celle des verrouillages. Elle consiste pour chaque transaction avant de débuter de s'assurer de la disponibilité des données requises en y plaçant des verrous : c'est la phase de croissance. Si un objet est déjà verrouillé, la transaction ne peut débuter. Dans la phase de diminution, les verrous sont enlevés. Cette méthode est appelée verrouillage à 2 phases.

IV.3 .B. ESTAMPILLES

L'autre méthode de contrôle de concurrence est la méthode des estampilles. Ici, à chaque transaction est attribuée un numéro par un compteur. Les transactions s'exécutent par ordre croissant. Dans le cas de systèmes distribués, l'ordre global est partiel, mais total sur chaque site. En effet chaque site a son compteur. L'ordre global peut devenir total si à chaque site est attribué aussi un numéro.

IV.4. INTERBLOCAGES

Lorsqu'on applique un système de verrouillage, on doit toujours penser au problème d'interblocage. En effet supposons qu'une transaction a mi un verrou sur un objet A et attend un objet B verrouillé par un autre qui a son tour

attends de verrouiller l'objet A. Dans ce cas de figure, il est clair que les deux transactions vont s'attendrent indéfiniment : c'est l'interblocage.

Afin de gérer les interblocages trois principales actions peuvent être effectuées :

· Détecter les interblocages et les résoudre

· Prévenir les interblocages avant qu'ils n'apparaissent !

· Eviter les interblocages, par la façon d'allouer les ressources.

La méthode la plus utilisée est la première, qui consiste à attendre que les interblocages arrivent, les détecter, et décanter la situation. Pour cela, il est utilisé un graphe qui représente l'état d'attente des transactions : c'est le WFG (Wait For Graph) (voir fig 4). Chaque noeud représente une transaction en cours. Et les arcs entre les noeuds sont les attentes d'une transaction par rapport à l'autre. Lorsque un cycle est détecté, on a un interblocage. La solution consiste à retirer (abort) une transaction, afin de libérer ses ressources. Encore faudrait-il faire le meilleur choix, qui génère moins de coûts.

Figure 4 : Graphe d'attentes

IV.5. TRANSACTIONS REPARTIES

Dans le cadre de systèmes répartis, les algorithmes cités ci-dessus sont aussi valables. La différence est qu'ici, une transaction peut être en attente pas seulement para rapport à une transaction locale, mais située sur autre site. La gestion en est donc un peu plus compliquée. Aussi, on peut avoir le cas de

transaction répartie ; c'est-à-dire une transaction constituée de plusieurs transactions locales. Dans ce cas, on utilise un protocole de validation à 2 phases. Dans la première phase dite phase de préparation, le site coordonnateur demande aux sites participants de se préparer à la validation. Lorsqu'il reçoit les notifications positives il lance alors la phase de validation en donnant l'ordre correspondant aux sites. Dans le cas contraire il donne l'ordre d'interrompre les transactions.

Figure 5 : Validation à deux phases

V. LA REPLICATION

La réplication désigne la reproduction identique de données d'un site à un autre. Elle a pour but d'assurer la fiabilité du système et diminuer les trafics réseaux, dans le cadre de systèmes distribués. Ainsi, si un site est momentanément inaccessible, un autre peut valablement le remplacer sans que les utilisateurs ne s'en aperçoivent. Aussi, au lieu de faire des requêtes réparties, qui occupent la bande passante, les requêtes se font au niveau local.

Le mode le plus courant de la réplication dans les bases de données est la notion de clichés en anglais snapshots.

Un cliché est une photo de la base de données partiellement ou totalement à un instant donné. Afin de garder une certaine cohérence de la base, les clichés

doivent régulièrement êtres mis à jour. Ainsi, plus le cliché est récent, plus il est fiable.

VI. LES REQUETES REPARTIES

VI.1. DEFINITION

Une requête répartie est une requête s'effectuant sur une base de données répartie. Comme une requête normale, elle se base sur les relations de la base et leurs champs, en utilisant l'algèbre relationnel. Mais elle doit tenir compte en plus de certains paramètres essentiels de fragmentation, de localisation afin d'optimiser le temps de réponse global de la requête.

Dans le cadre d'une base de données locale, 2 principaux paramètres sont considérés pour l'optimisation des résultats à savoir : les coûts d'accès aux entrées sorties et les capacités de traitement du CPU. Pour une base de donnée distribuée, en plus de ces indices, il faut aussi tenir compte des coûts de communication réseaux.

VI.2. OPTIMISATION

Optimisation consiste à choisir parmi de nombreuses possibles, une stratégie d'exécution de requête tant efficace que efficiente. En effet, lorsque l'utilisateur soumet une requête au SGBD, le composant appelé le Query Processor entre en action pour récrire la requête sous une forme plus simple, et optimale.

L'optimisation d'une requête intervient à deux principaux niveaux :

VI.2.A. DECOMPOSITION DE LA REQUETE

VI.2.A.a. Normalisation

La normalisation consiste à écrire la partie critère (contenu dans la clause WHERE) sous forme d'une conjonction de coordination ou disjonction de conjonction de prédicats.

WHERE (a et b) ou (c et d).

Ceci afin de simplifier la clause et faciliter ainsi l'analyse et l'optimisation.

VI.2.A.b. Analyse

Après la normalisation, il est question d'analyser la requête afin de détecter et éliminer les erreurs. Parmi elles on peut citer, la présence de champs ou relations inexistants, l'incohérence des valeurs données avec les types réels des champs, etc.

VI.2.A.c. Elimination des redondances

Ensuite, la requête est simplifiée en éliminant les redondances. En effet dans certains cas, plusieurs formules identiques peuvent se retrouver au sein de la même requête.

Exemple : NON (NON A) == A

A ET A == A

A OU A ==A

Ainsi lorsque de tels cas sont détectés, le Query processor les simplifie et obtient une formule finale plus claire.

VI.2.A.d. Réécriture

La dernière phase de cette première partie consiste à réécrire la requête en une forme qui améliore ou optimise le temps de traitement global. En effet, les opérations de l'algèbre relationnel à savoir : l'Union, la Sélection, la Projection, la Différence, la jointure, le Produit cartésien n'ont pas les mêmes complexités (voir tableau1). Alors il est plus avantageux d'exécuter de les exécuter dans l'ordre de complexités croissantes.

Opérations	Complexité en nombre de données
Sélection Projection (sans élimination des doublons)	O (n)
Opérations	Complexité en nombre de données
Projection (avec élimination des doublons) Union Jointure Semi-j ointure Quotient Opérations de mises à jour	O (n*log n)
Produit Cartésien	O (n2)

Tableau 1 :Tableau des complexités des opérations

Ainsi, le Query Processor reformule la requête dans ce sens, en appliquant les règles logiques de commutativité, associativités, distributions, idem potence, etc ...

VI.2.B. REPARTITION DE LA REQUETE

Après la première partie citée ci-dessus, il faut tenir compte de la répartition des données : c'est-à-dire de la fragmentation et de la localisation. En effet, il faut décomposer la requête globale en requêtes sur les fragments. Ainsi des reconstructions sont encore faites afin d'annuler les formules dont les conditions ne respectent pas les restrictions des fragments aux quelles elles font référence. Dans certains cas aussi, on peut remplacer certaines opérations par d'autres, comme la jointure par la sémi - jointure car moins coûteuse.

Selon la localisation de chaque fragment et l'existence ou non de relations répliquées, une stratégie d'exécution est mise en place afin de minimiser au maximum les trafics réseaux et bénéficier de rapides accès aux données et traitements du CPU. Ainsi, en fonction de la topologie du réseau et de son

architecture il peut être plus avantageux d'exécuter tel fragment de requête sur tel site et pas sur un autre. Par exemple dans le cas d'une architecture client Serveur, il faut choisir quels fragments s'exécutera sur le client et quel autres sur le serveur. Aussi les coûts de communication n'étant pas les mêmes sur un LAN que sur un WAN, les stratégies utilisées dans ces cas peuvent être différentes.

VI.2.C. SCHEMA GENERAL DE L'OPTIMISATION

Maintenant, nous allons récapituler tout ce qui a été dit pus haut dans un schéma général d'optimisation. Tout d'abord, il est important de mentionner que dans un système distribué, l'optimisation peut se faire de trois manières principales :

· Une optimisation centralisée où un site central détermine la stratégie d'exécution sur tous les autres sites. Dans ce cas, l'optimisation est plus facile mais souvent peu efficace car il faudrait connaître exactement les indices de chaque site, ce qui n'est pas évident.

· Une optimisation distribuée où chaque site a sa propre stratégie d'optimisation

· Enfin on peut joindre les deux première méthodes pour en faire une hybride. Ainsi, dans un premier temps, un site décide de l'optimisation globale et ensuite chaque site optimise à son tour, à son niveau. C'est cette dernière possibilité que nous illustrons dans le schéma suivant.

Figure 6 : Schéma général de l`optimisation

VII. LES OBJECTIFS D'UNE BASE DE DONNEES REPARTIE

En conclusion de cette première partie sur la notion de base de donnée répartie, nous allons donner les principaux objectifs à respecter par un système réparti, suivant les 12 points définis par C.J Date.

VII.1. L'AUTONOMIE LOCALE

L'autonomie locale implique que chaque site doit fonctionner indépendamment des autres, même si ces derniers venaient à avoir des pannes.

Aussi, chaque site est responsable de l'intégrité, la sécurité et la gestion de sa base de données.

VII.2. NE PAS SE REPOSER SUR UN SITE UNIQUE

Cet objectif vise à éviter des arrêts de production lorsqu'un site tombe en panne. Pour cela on peut soit penser à ce que Oracle appelle la réplication avancée ou les données sont entièrement répliquées d'un site à l'autre.

On peut aussi utiliser Oracle Parallele Server qui est une architecture composée de plusieurs SGBD utilisant une même base de données. Ainsi, si le SGBD d'un site tombe en panne, celui de l'autre prend la relève.

VII.3. OPERATION EN CONTINU

Ici, il est question d'assurer le fonctionnement continu du système réparti par des mises à jour et maintenances effectuées.

VII.4. TRANSPARENCE VIS A VIS DE LA LOCALISATION

Cet objectif a pour but de rendre l'accès aux données transparentes sur tout le réseau. En effet, ni les applications, ni les utilisateurs ne doivent savoir la localisation des informations qu'ils utilisent. Pour cela on peut utiliser les liens de base de données et les synonymes dont nous parlerons plus amplement dans la deuxième partie.

VII.5. INDEPENDANCE VIS A VIS DE LA FRAGMENTATION

La fragmentation doit être réelle et respectée sur chaque site, indépendamment.

VII.6. INDEPENDANCE VIS A VIS DE LA REPLICATION

De même chaque site doit bien gérer ses réplications.

VII.7. TRAITEMENT DES REQUETES DISTRIBUEES Chaque site doit avoir des outils et stratégies d'optimisation.

VII.8. GESTION REPARTIE DES TRANSACTIONS

Généralement les SGBD utilisent des protocoles de validation à 2 phases.

VII.9. UNE INDEPENDANCE VIS A VIS DU MATERIEL

Le SGBD ne doit dépendre du matériel

VII.10. UNE INDEPENDANCE VIS A VIS DU SYSTEME D'EXPLOITATION

Il est important que les SGBD utilisés soient utilisables sur plusieurs systèmes d'Exploitation.

VII. 11. UNE INDEPENDANCE VIS A VIS DU RES EAU

L'idéal serait que chaque SGBD réparti est son propre protocole réseau comme Oracle, pour faire communiquer les différentes instances.

VII.12. UNE INDEPENDANCE VIS A VIS DU TYPE DE LA BASE DE DONNEES RELATIONNELLE

De plus en plus, il est possible d'interconnecter des SGBD de types différents, au moyen des standards tels que ODBC, JDBC et des middlewares fournis par les constructeurs eux-mêmes.

Ainsi se termine cette première partie basée sur la présentation générale de la notion de base de données répartie et ses principales caractéristiques. Dans la suite, nous parlerons du cas particulier de Oracle qui est le SGBD le plus utilisé au monde dans la répartition et de loin le plus efficace.