To Tune or not to Tune?To Tune or not to Tune?A Lightweight Physical Design
Alerter
Costa Jean-DenisCosta Jean-DenisLe Yaouanc AurélieLe Yaouanc Aurélie
Mécanismes de SGBD
2007
PlanProblèmes exposésPrésentation d’une solutionPrincipeFonctionnement de l’optimiseurCalcul de la borne inférieureCalcul de la borne supérieureExpérimentationConclusion
Problèmes exposés:Le Tuning des conceptions physiques :
• Les données et les charges de travail sont souvent modifiées :
• Existence d’outils 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 d’amélioration possible :
• L’Alerter
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 l’alerter.
Calcul de la borne inférieure pour l’amé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 d’alerte).
Principe
Fonctionnement de l’optimiseur Sélection des chemins d’accès:
Access Path Generation Module
Available indexes
Logical sub-plan Physical plans
Project(Filter(…))πc,d (σ a=10 (T))
1- Lorsque le module de génération des chemins d’accès reçoit une requête, il analyse les index disponibles et renvoie un ou plusieurs plans d’exécution candidats.
Fonctionnement de l’optimiseur
Tag logical subplan with index request
Instrumentation Original optimizer
{(a, 0.85)}, Ø, {c,d}
Access Path Generation Module
Available indexes
Logical sub-plan Physical plans
Project(Filter(…))πc,d (σ a=10 (T))
2- Il intercepte les requêtes et stocke le tuple (S,O,A,N).
-> Permet de conserver les propriétés de stratégie d’index afin d’éviter le relancement de l’Alerter en cas de modification de conception.
Fonctionnement de l’optimiseur L’interception des requêtes d’index :
T1.x=T2.y
T1.w=T3.z
ρ1, 0.08 secs
ρ2, 0.23 secs(left=0.08 secs)
ρ3, 0.45 secs(left=0.23 secs)
ρ5, 0.05 secs
Hash Join
Hash Join
Filter(T1.a=5) Filter(T3.b=8)
Scan(T1) Scan(T3)Scan(T2)
SELECT T.bFROM T1, T2, T3WHERE T1.x=T2.y AND T1.w=T3.z AND T1.a=5 AND T3.b=8
ρ1 =( {(T1.a, 2500)}, Ø, {T1.a,T1.x,T1.w}, 1 )
ρ2 =({(T2.y, 0.2)}, Ø, {T2.y}, 2500)
ρ3 =({(T3.z, 1)}, Ø, {T3.z,T3.b}, 500)
ρ4 =({(T3.z, 0.2)}, Ø, {T3.z,T3.b}, 2500)
ρ5 =( {(T3.b, 5000)}, Ø, {T3.b,T3.z}, 1 )
Fonctionnement de l’optimiseur Algorithme de génération de l’arbre « AND/OR »:
T1.x=T2.y
T1.w=T3.z
ρ1, 0.08 secs
ρ2, 0.23 secs(left=0.08 secs)
ρ3, 0.45 secs(left=0.23 secs)
ρ5, 0.05 secs
Hash Join
Hash Join
Filter(T1.a=5) Filter(T3.b=8)
Scan(T1) Scan(T3)Scan(T2)
BuildAndOrTree(T:Execution Plan) =IF (T.isLeaf) // Case 1
RETURN T.requestELSE IF (T.request is null) // Case 2
RETURN AND( BuildAndOrTree(T.child1),...,BuildAndOrTree (T. childn) )
ELSE IF (T.isJoin) // Case 3RETURN AND( BuildAndOrTree (T.leftChild),
OR( T.request, BuildAndOrTree(T.rightChild)))ELSE // Case 4
RETURN OR( T.request,BuildAndOrTree (T.child))
Ø
OR
ρ1 Ø
OR
ρ2
AND
Ø
OR
ρ5
OR
ρ3
ANDAND
ρ1
ρ5ρ3
ρ2OR
Arbre normalisé
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 l’amélioration = une borne supérieure sur le coût estimé
On va se servir de l’arbre AND/OR généré lors de l’optimisation sans appeler à noueau l’optimiseur
Calcul de la borne inférieure On dispose:
Du chemin d’accès choisi par l’optimiseur Du coût de chaque branche du plan d’exécution généré De l’espace 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
Calcul de la borne inférieure On ne regarde pas:
Les index multiples pour une seule table
Les variation d’arbre d’exé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
Calcul de la borne supérieurerapide
Principe Pour chaque feuille de
l’arbre (chaque table), on cherche le meilleur index possible
On renvoi les choix d’index 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 s’occupe pas des contraintes d’espace (index gros)
ρ1 =( {(T1.a, 2500)}, Ø, {T1.a,T1.x,T1.w}, 1 )
ρ2 =({(T2.y, 0.2)}, Ø, {T2.y}, 2500)
ρ3 =({(T3.z, 1)}, Ø, {T3.z,T3.b}, 500)
ρ4 =({(T3.z, 0.2)}, Ø, {T3.z,T3.b}, 2500)
ρ5 =( {(T3.b, 5000)}, Ø, {T3.b,T3.z}, 1 )
Calcul de la borne supérieurePrécise
Principe Se fait en même temps que l’optimisation A chaque requête d’index, on regarde quel serait le meilleur On simule sa présence On continue l’optimisation On regarde les résultats de l’optimiseur
Problème On utilise des index qui n’existent pas vraiment Le plan d’exécution généré n’est pas « faisable »
Calcul de la borne supérieurePrécise (suite)
Solution Lancer deux fois l’optimiseur (une fois en supposant et une
fois normalement) Lourd (le but est de rester transparent)
Optimisation On mélange le calcul des deux plans d’exécution On calcule le meilleur sous plan faisable Puis on simule l’index 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
ExtensionsGestion des Update
On coupe les updates en deux:UPDATE T SET a=b+1, c=c*2 WHERE a<10 AND d<20Devient:(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 l’update 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
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 d’autres conceptions
physiques comme le partitionnement
ExpérimentationLa partie client de l’Alerter est implémentée
en C++ avec une base Microsoft SQL Server 2005.
L’outil de Tuning est Microsoft SQL Server Database Tuning Advisor.
Bases de données utilisées:
Résultats:Pour requêtes simples :
Variation des charges de travail
La configuration de W1 est déjà optimale -> l’Alerter n’envoie pas d’alarme.
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).
Variation des charges de travail
• Alerter tout seul très rapide (moins de 1 seconde en moyenne)• Les requêtes sont différentes, l’exécution de requêtes identiques augmente les pondérateur de l’arbre AND/OR, mais ne modifient pas l’arbre lui-même, donc n’augmentent pas le temps d’exécution
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 l’essentiel est la borne inférieure (nécessité de lancer un outil de tuning)
Conclusion
L’alerter complète les fonctions d’un outil de Tuning.
Il demande peu de ressources et tourne régulièrement pendant une opération.
Alerte le DBA si une conception n’est 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.