|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Membre régulier
![]() Inscription : avril 2003 Messages : 131 ![]() |
Bonjour,
Je suis en train de me documenter les le calcul des statistique. Je suis sous Oracle 10g 64Bits (Solaris 10). J'ai des tables relativement importantes, beaucoup font plusieurs centaines de Go. Elles bougent quotidiennement (plusieurs millions d'enregistrement). Mes plus grosses tables sont toutes partionnées. Passons le fait que calculer des stats sur des tables qui ne bougent pas represente sans doute un réel interet, en esperant pas me tromper. Est ce qu'il est interessant de recalculer les stats sur ces tables ? Le temps et les ressources que cela va prendre ne serat-il pas pénalisant ? Est ce que je le calcul des stats pourrait avoir un impact important sur les performances (cad, je calcul les stats, mes requetes s'executent alors beaucoup plus vite) ? Petit question subsidiaire, je n'ai pas trouvé comment, sous Oracle 9i, voir quels sont les tables qui ont des statistiques ? |
|
|
00
|
|
|
#2 |
|
Expert Confirmé
![]() Inscription : septembre 2004 Messages : 2 942 ![]() |
En 10g, il y a par défaut un job qui les calcule.
Ce job ne vous convient pas ? ou est-ce la fenêtre de calcul qui ne convient pas (messages dans l'alert.log ?) |
|
|
00
|
|
|
#3 | |
|
Membre régulier
![]() Inscription : avril 2003 Messages : 131 ![]() |
J'avais effectivement vu dans la doc qu'un Job s'executé automatiquement tous les jours, vers 6h00 il me semble.
Je viens de trouver via Oracle Enterprise Manager (le truc via HTTP) les rapports des executions de ce jobs. Citation:
Vue la durée, je ne perds pas grand chose à supprimer ce jobs, non ? Mais est ce que les tables systèmes ne vont pas en souffrir ? |
|
|
|
00
|
|
|
#4 | ||
|
Expert Confirmé
![]() Inscription : septembre 2004 Messages : 2 942 ![]() |
ce job est optimisé pour ne calculer les stats que sur les objets qui en ont besoin. Vous ne ferez pas beaucoup mieux
par ailleurs, la fenêtre d'exécution par défaut n'est pas aussi longue que 33h. (6h de 0h à 6h de mémoire me semble-t-il) l'avez-vous modifié ? de quel "truc http" parlez-vous donc ? la DB Console ? la grid Console ? iSQL*Plus ? ... EDIT : collez plutôt le résultat de cette requête : Code :
|
||
|
|
00
|
|
|
#5 |
|
Membre actif
![]() |
Bonjour,
Les vues du dictionnaire de données (user_tables & co.) sont justement mises à jour par ce job. En revanche, tu as la possibilité de générer toi-même tes stats. Dans Enterprise Manager, dans la partie Maintenance, tu as un lien Gather Statistics qui te permet de sélectionner les objets ou les schémas dont les stats seront mises à jour. Cet assistent va en fait te générer les blocs PL de mise à jour des stats. ++
__________________
Diction de DBA : "Tant va la cruche à l'eau qu'à la fin, ça me les brise" ![]() ------------------------------------- Working on Oracle Database 10g / 11g ------------------------------------- Article d'installation d'Oracle 10g AS Portal by Maxime GONTCHAROV labo-oracle.com |
|
|
00
|
|
|
#6 | ||
|
Membre régulier
![]() Inscription : avril 2003 Messages : 131 ![]() |
Voici le résultat de la requete:
Code :
![]() A moins que je sois mal reveillé (ce qui est fort possible), 2032 minutes, ça fait bien ~33h ^^ Je rajoute un élément important. Je suis en train de copier la base vers la 10g, donc forcement, la base se prend une claque de 2To de données d'un seul coup (enfin, en quelques heures). Je pense que ca explique les 'STOPPED'. Une fois qu'elle sera en prod, est ce que je retrouverais des temps "normaux" pour le calcul des stats ? Est ce que, comme j'ai pu le lire, activer le monitoring des tables me permettra d'accelerer ce processus ? Ou encore, est ce que de modifier la facon dont sont calculés les stats, avec des options comme Estimate_Percent, COMPUTE (ref) via le job permettra d'améliorer tout ça ? La base source, sous 9i, n'avait pas de stats sauf pour des tables qui ne bougeaient jamais. J'aimerais avoir les stats sur la 10g afin d'améliorer les performances générales. Les stats permettent au plan d'execution d'être plus efficace, est ce que c'est le cas aussi lors des insert/update ? Enfin, comme j'ai pu le voir en conseil sur le forum, calculer les stats sur de gros volumes une seule fois par semaine, par exemple le dimanche, ne serait-il pas une bonne alternative si ma base évolue trop vite chaque jour ? |
||
|
|
00
|
|
|
#7 |
|
Membre régulier
![]() Inscription : avril 2003 Messages : 131 ![]() |
Merci pour l'info, je n'avais pas encore eu l'occasion de voir cette partie, c'est ultra pratique.
|
|
|
00
|
|
|
#8 |
|
Expert Confirmé
![]() Inscription : septembre 2004 Messages : 2 942 ![]() |
le job 192 a bien duré 33 heures, ou 1 jour et 9h.... +001 09:52:08
les stopped, c'est quand la fenêtre de maintenance se ferme avec un job en cours. et le week-end, la fenêtre par défaut ne se ferme pas. voilà pourquoi ce week-end ça a pris 33 heures en 10, le monitoring est activé par défaut et ce job s'appuie dessus. vous n'avez donc rien à faire Laissez la volumétrie se stabiliser et laisser faire le job par défaut avant de vouloir tout changer... la gestion du job avec les fenêtres de maintenant est pas mal : Tous les jours il essaye de calculer les stats, mais que sur les objets qui ont beaucoup changé. En semaine, il empêche le job de déborder sur la plage de fonctionnement et a tout le temps nécessaire en week-end. S'il doit s'arrêter, ce n'est pas très grave, le travail fait n'est pas perdu. ne cherchez pas à réinventer la roue. Utilisez les outils existants. |
|
|
00
|
|
|
#9 |
|
Membre régulier
![]() Inscription : avril 2003 Messages : 131 ![]() |
Merci pour tes réponses (tu m'en veux pas si je te tutois
Tu confirmes ce que j'ai vu voir à droite et a gauche. Je vais laisser tourner et voir ce que ca donne. Par contre, la base étant stoppée la nuit pour la sauvegarde (me demandez pas pourquoi, c'est pas moi qui gère ça ^^), il faudra peut être que je revois les heures d'execution. Je crois même que la base est stoppée le WE ... Je vais voir ce que ca donne après une journée de batch, toutes les tables ne changent pas et je pense que ça ne devrait pas prendre trop de temps. |
|
|
00
|
|
|
#10 |
|
Expert Confirmé
![]() Inscription : septembre 2004 Messages : 2 942 ![]() |
la fenêtre de maintenance doit être ajustée en fonction de vos contraintes, c'est tout
|
|
|
00
|
Copyright © 2000-2012 - www.developpez.com