Calcul des stats

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 ?

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

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:

---

Durée de l'exécution (minutes) 2032.13

---

Voici un petit exemple ^^ ~ 33h ... ca fait beaucoup. La plupart des grosses tables bougent chaque jour, il me semble que je perds plus de temps à générer les stats qu'au gain que je gagne par la suite.

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 ?

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 ? :roll:
la DB Console ? la grid Console ? iSQL*Plus ? ...

EDIT :
collez plutôt le résultat de cette requête :

Code:

---

1 2	select Job_Name, Log_Date, Run_Duration, Status, CPU_UseD from dba_scheduler_job_run_details where job_Name = 'GATHER_STATS_JOB'

---

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.

++

Voici le résultat de la requete:

Code:

---

1 2 3 4 5 6 7 8

LOG_ID JOB_NAME LOG_DATE RUN_DURATION STATUS CPU_USED ---------- ----------------------------------------------------------------- --------------------------------------------------------------------------- --------------------------------------------------------------------------- ------------------------------ --------------------------------------------------------------------------- 794 GATHER_STATS_JOB 29-JAN-08 06.00.00.284172 AM +01:00 +000 07:59:59 STOPPED +000 01:46:23.09 1173 GATHER_STATS_JOB 30-JAN-08 06.00.00.392459 AM +01:00 +000 07:59:58 STOPPED +000 02:57:28.09 1320 GATHER_STATS_JOB 31-JAN-08 06.00.01.567297 AM +01:00 +000 07:59:58 STOPPED +000 05:01:49.73 1388 GATHER_STATS_JOB 01-FEB-08 12.22.54.292044 AM +01:00 +000 02:22:51 SUCCEEDED +000 00:43:17.55 41 GATHER_STATS_JOB 25-JAN-08 10.46.01.020788 PM +01:00 +000 00:45:58 SUCCEEDED +000 00:15:50.96 192 GATHER_STATS_JOB 27-JAN-08 03.52.15.134437 PM +01:00 +001 09:52:08 SUCCEEDED +000 04:22:47.61

---

Effectivement, je ne vois pas de 33h. J'ai trouvé ce chiffre dans les rapports de l'execution du job, via OEM Database Control (le truc via HTTP ^^). J'ai rajouté la colonne job_id pour voir le rapport entre les deux:

http://img528.imageshack.us/img528/334/cappy6.jpg

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 ?

Citation:

---

Envoyé par Scual

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

---

Merci pour l'info, je n'avais pas encore eu l'occasion de voir cette partie, c'est ultra pratique.

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

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.

la fenêtre de maintenance doit être ajustée en fonction de vos contraintes, c'est tout