Discussion :

[dnboa]

Bonjour,

J'aurais une question sur les stats.
Savez-vous si les stats doivent être mises sur toutes les tables ou que sur celles qui ne bouge pas énormément?
Si je mets les stats sur une table qui souffre souvent des modifications, est-ce que les performances sont affectées négatif?

Merci à vous,

[LeoAnderson]

toutes, mais la fréquence de calcul peut-être variable

en 8i/9i, le liste_stale est utile
En 10g, le job fait ça pas trop mal

[lallio]

Il n'y pas vraiment de formule magique. Mais cela dépend effectivement si les tables sont plutot hautement transactionnel ou plutot table fixe.
Par ailleurs, cela dépend de la volumétrie. Si cela prends 10 minutes d'analyzer les tables & index alors autant le faire quotidiennement.

Attention: Pour les stats, il faut penser à générer les histogrammes, cela peut améliorer les performances

[13thFloor]

Mais pourquoi donc recalculer systématiquement les statistiques ?
Si les plans d'exécution sont ok et les temps de réponse corrects, inutile de recalculer les stats au risque de fausser les plan d'exec.
Dés qu'une requête est tunée aux petits oignons, plus la peine de "dbms_stater".
Zêtes pas d'accord ?

[13thFloor]

Si je mets les stats sur une table qui souffre souvent des modifications, est-ce que les performances sont affectées négatif?

Dans ce cas, j'essaiera de déterminer les bonnes valeurs à fournir à l'optimiseur (au travers de plusieurs tests) pour, au final, ne pas calculer les stats sur cette table mais les mettre à jour avec dbms_stats.set_table_stats une fois quand la table est à volume de croisière, une autre fois quand il y a changement important de volumétrie (en terme de blocs).
Ex : utilisation courante, plan d'exec ok pour numblks=100 000, purge de 90% de la table, tu passes un set_table_stats avec numblks=10 pour forcer un full.
Il faut en fait trouver les bonnes valeurs qui garantissent de bons plans d'exécution en toute circonstance (si c'est possible of course).

[lallio]

Si on se positionne dans le tuning à un instant t, effectivement si le plan est ok et les temps de réponse ok alors pas besoin.
Mais en général dans la vraie vie, les données liées aux applications.
Dans les banques ou assurances ce sont plusieurs millions de transactions / jours. Donc mieux d'avoir des stats à jours.
Maintenant si il s'agit d'une table avec la liste des pays du monde, une fois que c'est fait, ca doit pas trop bouger (et ce même avec quelques déclaration d'indépendances.)

[Invité]

Mais pourquoi donc recalculer systématiquement les statistiques ?
Si les plans d'exécution sont ok et les temps de réponse corrects, inutile de recalculer les stats au risque de fausser les plan d'exec.
Dés qu'une requête est tunée aux petits oignons, plus la peine de "dbms_stater".
Zêtes pas d'accord ?

ben non, pas d'accord.
si tu as des tables qui bougent beaucoup, à coup de millions d'enregistrements par jours mettons, le plan d'exécution peut se trouver modifier à juste titre pour optimiser la requête.

[13thFloor]

ben non, pas d'accord.
si tu as des tables qui bougent beaucoup, à coup de millions d'enregistrements par jours mettons, le plan d'exécution peut se trouver modifier à juste titre pour optimiser la requête.

Si le plan d'exec se trouve amélioré rien qu'avec de nouvelles stats, c'est que le dba n'a pas fait du bon boulot. Faut pas attendre qu'un recalcul améliore les perfs (à mon avis).

Néanmoins ce que tu dis est vrai si le dba ne fait rien et qu'une requête se met à faire du hash join au lieu de nested loops dés que le volume est important.

Sur des tables SAP de plusieurs dizaines de millions de lignes, quelques millions de plus par jour ne change rien, les accès se font toujours par index (un peu forcé par le paramètrage je te l'accorde). Le plan est optimum quelque soit le volume supplémentaire car peu de données sont accédées.

[bruce_gray]

Si le plan d'exec se trouve amélioré rien qu'avec de nouvelles stats, c'est que le dba n'a pas fait du bon boulot. Faut pas attendre qu'un recalcul améliore les perfs (à mon avis).

Ha? Personnellement je trouve normal qu'un DBA recalcule regulierement les stats des objects de sa base. Si les recalculer ne sert a rien, il faut peut etre inform Oracle qu'ils stoppent le dev de ce feature.

Néanmoins ce que tu dis est vrai si le dba ne fait rien et qu'une requête se met à faire du hash join au lieu de nested loops dés que le volume est important.

Sur des tables SAP de plusieurs dizaines de millions de lignes, quelques millions de plus par jour ne change rien, les accès se font toujours par index (un peu forcé par le paramètrage je te l'accorde). Le plan est optimum quelque soit le volume supplémentaire car peu de données sont accédées.

Yes, mais tu dis just que 1Million/day est au pire 10% du total nombre de tes lignes dans tes tables et dans ce cas si tu fais un "estimate" sur 20% de ta table ca ne change rien bien sur!

Dans l'autre main, si ta table contient des millions de lignes et avec beaucoup de % de insertion/suppression (I mean there's a great difference between the lowest number of rows and the highest one), regenerer les stats me semble plutot un bonne idee

Bien sur, il n'existe pas de solution absolu, tout les base de donnees sont differentes et il depend de l'utilisation de la base. Le bon DBA est celui qui connait bien sa base et comment elle est utilise.
Il y a, pour sur, une phase d'experiment et il n'y a pas d'outil ou de solution a exclude, seul l'experience apres les phases d'observation peut dire quel est le meilleur moyen de garder des performance correct dans la majorite des cas.