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.

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

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 ;)

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...

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.

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 ?

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 :mouarf:

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 :king: rien que ça me suffit à passer à DBMS_STATS :)

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 ! ;)

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 :?