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.