Le système de gestion de base de données Oracle

Résumé du document

Dans le but de comprendre le fonctionnement interne du système de gestion de base de données Oracle, il nous a été demandé de mener diverses expérimentations à travers des jeux de tests et d'étudier le comportement de celui-ci.
Ce dossier se décompose en deux grandes sous-parties étant d'un côté le compte rendu des expérimentations menées au travers des travaux pratiques, et de l'autre un mini projet consistant à implémenter un algorithme de jointure en utilisant le langage java.

Extraits

[...] Voici un tableau récapitulatif des tests eectués sur celui-ci : Interprétation : Concernant la taille de notre index secondaire et de notre index primaire, on constate que ceux-ci sont identiques à ceux de l'organisation avec index primaire seul et respectivement ceux d'organisation avec index secondaire seul. On en conclu que le fait d'avoir en même temps un index primaire et un index secondaire sur une même table n'aue pas la taille des indexes ni leurs nombres de blocs. A travers nos diérents critères de sélection on constate que parfois l'index primaire est utilisé, et parfois non. L'index primaire est utilisé, lorsqu'on a un critère de sélection portant directement sur l'attribut indexé. [...]

[...] Reste à vérier l'ecacité de cet algorithme par rapport à une jointure réalisée par oracle. Pour cela nous allons nous intéresser aux plans d'exécutions de chacune des requêtes : 6.3 Jointure Par ORACLE SELECT FROM R JOIN S ON R. a = S . b ; La jointure par Oracle se fera par la requête : Elle aura donc pour plan d'exécution : Nous pouvons constater que le coût est loin d'être optimal, car malgré la présence d'index secondaires, la jointure réalise des TABLES ACCESS FULL, ce qui veut dire qu'elle va parcourir de façon séquentielle tout les tuples sans utiliser les indexes Création du graphe La requête est la même que celle citée un peu plus haut. [...]

[...] Cela est du à plusieurs choses : Le nombre de tuples renvoyé. On remarque clairement que lorsqu'une requête renvoie un nombre de tuples importants, ici 27104, Oracle choisit de ne pas utiliser notre index et préfère eectuer un balayage séquentiel. Lorsque le critère de sélection ne porte pas directement sur l'attribut référencé par l'index primaire. Dans notre cas le critère de sélection porte sur l'attribut VILLE. En utilisant les fonctions, dans certains cas Oracle choisira de pas utiliser l'index. [...]

[...] Nous avons remplis ces tables de manières similaire à la table Personne utilisées en TP, avec 3 villes communes et 3 villes diérentes dans chaque table. Chaque table est remplie avec 1000 tuples pour avoir des résultats visibles. Une fois nos critères de jointures choisis, la première étape consistait donc a créer le graphe des liaisons entre les blocs des tables R et S contenant au moins un tuple vériant R.a=S.b. La requête nous permettant de réaliser cela est : SELECT DISTINCT DBMS_ROWID.ROWID_BLOCK_NUMBER(R. rowid ) , DBMS_ROWID.ROWID_BLOCKS_NUMBER . [...]

[...] Il en est de même pour l'index secondaire. Cependant dans certaine situations, on constate qu'aucun index n'est utilisé. Plusieurs raisons expliquent cela : Lorsque le résultat de la requête retourne trop de lignes, le SGBD ne choisit pas d'utiliser le second index car le critère de sélection ne porte pas sur celui-ci. En utilisant les fonctions, dans certains cas Oracle choisira de n'utiliser aucun index On constate que l'association des 2 index (PRIMAIRE et SECONDAIRE) ne règle pas les problèmes de non utilisation de ceux-ci. [...]