To Tune or not to Tune? To Tune or not to Tune? A Lightweight Physical Design Alerter Costa Jean-Denis Le Yaouanc Aurélie Mécanismes de SGBD 2007.

Présentation au sujet: "To Tune or not to Tune? To Tune or not to Tune? A Lightweight Physical Design Alerter Costa Jean-Denis Le Yaouanc Aurélie Mécanismes de SGBD 2007."— Transcription de la présentation:

1 To Tune or not to Tune? To Tune or not to Tune? A Lightweight Physical Design Alerter Costa Jean-Denis Le Yaouanc Aurélie Mécanismes de SGBD 2007

2 Plan Problèmes exposés Présentation dune solution Principe Fonctionnement de loptimiseur Calcul de la borne inférieure Calcul de la borne supérieure Expérimentation Conclusion

3 Problèmes exposés: Le Tuning des conceptions physiques : Les données et les charges de travail sont souvent modifiées : Existence doutils de Tuning : - Efficaces - Chers - Consomment beaucoup de ressources. Le Tuning des conceptions physiques : Les données et les charges de travail sont souvent modifiées : Les installations sont souvent « sous optimisées ». « Gaspillage de ressources » Objectif des DBA : avoir des installations optimales: - Utilisation régulière des outils de Tuning. - Mais utilisation inutile si absence damélioration possible :

4 LAlerter Solution - Rôle : Analyse la charge de travail et détermine si une session de Tuning peut améliorer la configuration actuelle. - Caractéristiques: Analyse de faible coût : - Fonctionne seulement avec l'information recueillie quand la charge de travail était optimisée et non pas sur les différents appels de lalerter. Calcul de la borne inférieure pour lamélioration: - Pas de positif faux (fausse alerte) - Certain que l'amélioration réalisée par un outil de Tuning serait aussi importante. Calcul de la borne supérieure : - Réduit les faux négatifs (absence dalerte).

5 Principe

6 Fonctionnement de loptimiseur Sélection des chemins daccès: 1- Lorsque le module de génération des chemins daccès reçoit une requête, il analyse les index disponibles et renvoie un ou plusieurs plans dexécution candidats.

7 Fonctionnement de loptimiseur 2- Il intercepte les requêtes et stocke le tuple (S,O,A,N). -> Permet de conserver les propriétés de stratégie dindex afin déviter le relancement de lAlerter en cas de modification de conception.

8 Fonctionnement de loptimiseur Linterception des requêtes dindex : SELECT T.b FROM T1, T2, T3 WHERE T1.x=T2.y AND T1.w=T3.z AND T1.a=5 AND T3.b=8

9 Fonctionnement de loptimiseur Algorithme de génération de larbre « AND/OR »: BuildAndOrTree(T:Execution Plan) = IF (T.isLeaf) // Case 1 RETURN T.request ELSE IF (T.request is null) // Case 2 RETURN AND( BuildAndOrTree(T.child1),..., BuildAndOrTree (T. childn) ) ELSE IF (T.isJoin) // Case 3 RETURN AND( BuildAndOrTree (T.leftChild), OR( T.request, BuildAndOrTree(T.rightChild))) ELSE // Case 4 RETURN OR( T.request,BuildAndOrTree (T.child)) Arbre normalisé

10 Calcul de la borne inférieure Objectif: Obtenir efficacement la borne inférieure sur l'amélioration de la charge de travail. L'amélioration d'une configuration est définie par: 100%.(1 – coût après / coût courant ) où coût courant et coût après sont les coûts estimatifs de la charge de travail pour la configuration originale et la configuration recommandée. Une borne inférieure sur lamélioration = une borne supérieure sur le coût estimé On va se servir de larbre AND/OR généré lors de loptimisation sans appeler à noueau loptimiseur

11 Calcul de la borne inférieure On dispose: Du chemin daccès choisi par loptimiseur Du coût de chaque branche du plan dexécution généré De lespace maximum disponible pour de nouveaux index Principe: On peut remplacer chaque sous arbre par un sous arbre implémentant la même requête On va rechercher quels index seraient plus adaptés Le seek_index: Index préfixé par les membres de S ayant une égalité Suivi des membres ayant une inégalité par ordre descendant Le reste des colonnes Le sort_index: Index préfixé par les membres de S ayant une égalité Suivi des membres de O par ordre descendant On fait une estimation du coût de la requête avec chaque index

12 Calcul de la borne inférieure On ne regarde pas: Les index multiples pour une seule table Les variation darbre dexécution (ordre de jointure…) Relaxation: Si on a plusieurs index sur la même table on va les mélanger ou les supprimer I(a, b, c) + I(a, c, d) => I(a, b, c, d) Coût total: Somme des coûts de chaque sous arbre

13 Calcul de la borne supérieure rapide Principe Pour chaque feuille de larbre (chaque table), on cherche le meilleur index possible On renvoi les choix dindex et la somme des coûts de cette configuration Trop Optimiste On ne regarde que les feuilles, pas les jointures et agrégats On ne soccupe pas des contraintes despace (index gros)

14 Calcul de la borne supérieure Précise Principe Se fait en même temps que loptimisation A chaque requête dindex, on regarde quel serait le meilleur On simule sa présence On continue loptimisation On regarde les résultats de loptimiseur Problème On utilise des index qui nexistent pas vraiment Le plan dexécution généré nest pas « faisable »

15 Calcul de la borne supérieure Précise (suite) Solution Lancer deux fois loptimiseur (une fois en supposant et une fois normalement) Lourd (le but est de rester transparent) Optimisation On mélange le calcul des deux plans dexécution On calcule le meilleur sous plan faisable Puis on simule lindex localement optimal et on continue A chaque étape on choisit un index réel et un index hypothétique On obtient donc les deux plans simultanément en rajoutant peu de surcharge

16 Extensions Gestion des Update On coupe les updates en deux: UPDATE T SET a=b+1, c=c*2 WHERE a<10 AND d<20 Devient: (i) SELECT b+1, c*2 FROM T WHERE a<10 and d<20 (ii) UPDATE TOP(k) T SET a=a, c=c On cherche les meilleurs index possibles pour le select On nettoie normalement, mais en tenant compte du coût de modification de lupdate Les index non optimaux pour le select ne sont pas forcément rejetés Les index couvrant toutes la requête sont probablement rejetés car trop durs à maintenir

17 Extensions Gestion des vues matérialisées Pour chaque requête on simule des vues matérialisées On simule également des index sur ces vues Très cher et très lourd Beaucoup de recherche sur les vues et dautres conceptions physiques comme le partitionnement

18 Expérimentation La partie client de lAlerter est implémentée en C++ avec une base Microsoft SQL Server 2005. Loutil de Tuning est Microsoft SQL Server Database Tuning Advisor. Bases de données utilisées:

19 Résultats: Pour requêtes simples :

20 Variation des charges de travail La configuration de W1 est déjà optimale -> lAlerter nenvoie pas dalarme. Charges de travail pour la base TPC-H: W1 (les 11 premières requêtes) W2 (les 11 dernières requêtes) W3 (mélange).

21 Variation des charges de travail Alerter tout seul très rapide (moins de 1 seconde en moyenne) Les requêtes sont différentes, lexécution de requêtes identiques augmente les pondérateur de larbre AND/OR, mais ne modifient pas larbre lui-même, donc naugmentent pas le temps dexécution

22 Variation des charges de travail Peu de surcharge en mode rapide Environ 15% (jusquà 40%) de surcharge moyenne en mode précis Borne supérieure importante, mais lessentiel est la borne inférieure (nécessité de lancer un outil de tuning)

23 Conclusion Lalerter complète les fonctions dun outil de Tuning. Il demande peu de ressources et tourne régulièrement pendant une opération. Alerte le DBA si une conception nest pas optimale. Les bornes inférieures sont supportées par des configurations valides. Les bornes supérieures sont flexibles et donnent la possibilité au DBA de définir des règles de déclenchement de sessions de Tuning.