Discussion :

[LeoAnderson]

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]

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]

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]

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]

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]

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