ANALYZE vs DBMS_STATS.GATHER

LeoAnderson · 07/11/2007, 16h01

Bonjour,

Ce n'est pas la première fois que le "problème" se soulève mais j'avoue n'avoir jamais pu trancher et savoir quelle était la méthode préférable |b]par défaut[/b] et laquelle devrait-on utiliser quand celle par défaut n'est pas satisfaisante ?
(je sais qu'il n'y aura pas de méthode magique, fantastique et qui marche à tous les coups)

Je me souviens par exemple qu'un analyze (même compute statistics, pas validate) permettait de détecter des corruptions logiques, qui passaient à la trappe avec le dbms_stats.

Alors, il vaut mieux commencer par tester quoi ? DBMS_STATS ou ANALYZE ?

Leo.

orafrance · 07/11/2007, 16h11

Si je ne m'abuse DBMS_STATS collecte d'avantage de statistiques (les histogrammes notamment)... et à le gros avantage d'être récursif aussi

Par ailleurs, dans le cas de tables partitionnées, c'est beaucoup plus

pour info : DBMS_STATS versus ANALYZE

En plus, on pourrait parler des export/import de stats, du calcul des stats systèmes, etc... qui ne permet pas ANALYZE

Par contre, ANALYZE reste utile, tu parles de VALIDATE mais il y a aussi les chained rows

dgi77 · 07/11/2007, 16h31

Je ne suis pas encore convaincu par la manipulation du DBMS_STATS, buggé sur certaines releases de la 9i, et un peu lourd à prendre en main.

Par contre, il a l'avantage d'être intégré au PL/SQL, et paraît-il plus performant que l'ANALYZE comme évoqué ci-dessus, et j'ai entendu dire que le ANALYZE va prochainement disparaître, si ce n'est déjà fait en version 11. Donc autant s'habituer au DBMS_STATS...

jf4db · 07/11/2007, 17h55

Citation:

Envoyé par dgi77

Je ne suis pas encore convaincu par la manipulation du DBMS_STATS, buggé sur certaines releases de la 9i, et un peu lourd à prendre en main.

Par contre, il a l'avantage d'être intégré au PL/SQL, et paraît-il plus performant que l'ANALYZE comme évoqué ci-dessus, et j'ai entendu dire que le ANALYZE va prochainement disparaître, si ce n'est déjà fait en version 11. Donc autant s'habituer au DBMS_STATS...

De plus il est simple de collecter les stats par DBMS_sTATS en utilisant les jobs oracle.

LeoAnderson · 07/11/2007, 20h52

Citation:

Envoyé par jf4db

De plus il est simple de collecter les stats par DBMS_sTATS en utilisant les jobs oracle.

Le plus simple, c'est pas le plus important
ce qui compte, c'est le plus efficace

Toutes les données ne sont pas exportées, et même, lors d'import, on peut tolérer un recalcul des stats... donc les "avantages" avancés de DBMS_STATS ne me semblent pas intérêssant au vu de ceux de analyze

Donc, je reste sur une préférence à analyze ?
ou je me fourvoie ?

ou est-ce que l'erreur consiste simplement à vouloir les comparer puisqu'ils n'ont pas du tout la même vocation ?

orafrance · 07/11/2007, 21h11

Citation:

Envoyé par LeoAnderson

ou est-ce que l'erreur consiste simplement à vouloir les comparer puisqu'ils n'ont pas du tout la même vocation ?

C'est un peu excessif

Je dirais que le ANALYZE dans le cas de modéle de données simple avec des volumétries raisonnables est tout à fait envisageable. Ca l'est moins quand les stats prennent des heures à être calculées, qu'on utilise des objets partitionner ou qu'on prévoit de migrer un jour vers une version qui ne supporte plus le ANALYZE

Comme d'habitude, c'est pas parce qu'Oracle promet l'obsolescence d'une commande que ça devient crétin de l'utiliser... tout dépend du besoin. N'empêche que l'export/import des stats c'est bien pratique quand tu fais des tests de tuning

rien que ça me suffit à passer à DBMS_STATS

LeoAnderson · 07/11/2007, 21h17

Certes c'est bien pratique pour tester.
mais en exploitation, la problématique est différente...

est-ce que je dois calculer les stats sur ma base de prod avec dbms_stats parce que c'est mieux pour tester ? je suis pas sûr !

orafrance · 07/11/2007, 21h25

ha si justement

Tu as ta prod qui a brusquement changé de comportement, certaines requêtes ont changé. Dans ce cas tu copies les stats dans une base de test et hop, tu peux optimiser les requêtes sans perturber la production. Tes plans d'exécutions seront les mêmes qu'en prod

Et pour les tables volumineuses c'est quand même pratique de calculer les stats en mode PARALLEL

Et je répéte quand même que le CBO peut être perturbé à cause du ANALYZE qui est moins exhaustif

07/11/2007, 16h01	#1
LeoAnderson Expert Confirmé Inscription : septembre 2004 Messages : 2 942 Détails du profil Informations forums : Inscription : septembre 2004 Messages : 2 942 Points : 2 972 Points : 2 972	ANALYZE vs DBMS_STATS.GATHER Bonjour, Ce n'est pas la première fois que le "problème" se soulève mais j'avoue n'avoir jamais pu trancher et savoir quelle était la méthode préférable \|b]par défaut[/b] et laquelle devrait-on utiliser quand celle par défaut n'est pas satisfaisante ? (je sais qu'il n'y aura pas de méthode magique, fantastique et qui marche à tous les coups) Je me souviens par exemple qu'un analyze (même compute statistics, pas validate) permettait de détecter des corruptions logiques, qui passaient à la trappe avec le dbms_stats. Alors, il vaut mieux commencer par tester quoi ? DBMS_STATS ou ANALYZE ? Leo.
	00

07/11/2007, 16h11	#2
orafrance Rédacteur/Modérateur Inscription : janvier 2004 Messages : 15 861 Détails du profil Informations personnelles : Âge : 35 Informations forums : Inscription : janvier 2004 Messages : 15 861 Points : 16 212 Points : 16 212	Si je ne m'abuse DBMS_STATS collecte d'avantage de statistiques (les histogrammes notamment)... et à le gros avantage d'être récursif aussi Par ailleurs, dans le cas de tables partitionnées, c'est beaucoup plus pour info : DBMS_STATS versus ANALYZE En plus, on pourrait parler des export/import de stats, du calcul des stats systèmes, etc... qui ne permet pas ANALYZE Par contre, ANALYZE reste utile, tu parles de VALIDATE mais il y a aussi les chained rows __________________ Règles et liens du forum Oracle Guide Oracle Pense-bête du DBA Oracle : Exemple
	00

07/11/2007, 16h31	#3
dgi77 Membre expérimenté Inscription : juillet 2007 Messages : 495 Détails du profil Informations personnelles : Localisation : France, Paris (Île de France) Informations forums : Inscription : juillet 2007 Messages : 495 Points : 585 Points : 585	Je ne suis pas encore convaincu par la manipulation du DBMS_STATS, buggé sur certaines releases de la 9i, et un peu lourd à prendre en main. Par contre, il a l'avantage d'être intégré au PL/SQL, et paraît-il plus performant que l'ANALYZE comme évoqué ci-dessus, et j'ai entendu dire que le ANALYZE va prochainement disparaître, si ce n'est déjà fait en version 11. Donc autant s'habituer au DBMS_STATS... __________________ Des chercheurs qui cherchent, on en trouve, mais des chercheurs qui trouvent, on en cherche !
	00

07/11/2007, 21h25	#8
orafrance Rédacteur/Modérateur Inscription : janvier 2004 Messages : 15 861 Détails du profil Informations personnelles : Âge : 35 Informations forums : Inscription : janvier 2004 Messages : 15 861 Points : 16 212 Points : 16 212	ha si justement Tu as ta prod qui a brusquement changé de comportement, certaines requêtes ont changé. Dans ce cas tu copies les stats dans une base de test et hop, tu peux optimiser les requêtes sans perturber la production. Tes plans d'exécutions seront les mêmes qu'en prod Et pour les tables volumineuses c'est quand même pratique de calculer les stats en mode PARALLEL Et je répéte quand même que le CBO peut être perturbé à cause du ANALYZE qui est moins exhaustif __________________ Règles et liens du forum Oracle Guide Oracle Pense-bête du DBA Oracle : Exemple
	00

07/11/2007, 21h17	#7
LeoAnderson Expert Confirmé Inscription : septembre 2004 Messages : 2 942 Détails du profil Informations forums : Inscription : septembre 2004 Messages : 2 942 Points : 2 972 Points : 2 972	Certes c'est bien pratique pour tester. mais en exploitation, la problématique est différente... est-ce que je dois calculer les stats sur ma base de prod avec dbms_stats parce que c'est mieux pour tester ? je suis pas sûr !
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email