[10g] Job COMPUTE_ALL_STATISTCS

Bonjour,
En v10g
J'ai un job lancé par sysman COMPUTE_ALL_STATISTICS.
Savez-vous ce que ce job fait exactement, où je peux regarder ?
Merci

Citation:

---

Envoyé par laurentAM

J'ai un job lancé par sysman COMPUTE_ALL_STATISTICS.

---

CALCULE_TOUTES_LES_STATISTIQUES :ccool:

Bonjour,

la vue dba_jobs ne me montre pas de jobs de ce nom, or il
répondrait à une de mes questions .

quelle vue avez-vous interrogé pour le voir ?

Cdlt

Merci de vos réponses.

En effet il calcule bien toutes les statistiques mais il me faudrait savoir comment voir le détail de ce job, ci-après la ligne dans dba_jobs :

Code:

---

BEGIN MGMT_BSLN.COMPUTE_ALL_STATISTICS;/*DB*/END;

---

Et bien il se trouve dans dba_jobs seulement une petite remarque avec un outil comme toad avec une certaine release 9.n et évidemment ma petite tête ne se souvient plus du n :-( et bien tu ne vois pas tout car il y a un nouveau type de données en 10g à priori non géré par toad.
Ce qui est sûr c'est qu'une v10 de toad lit toute la vue !

Pour en revenir à mon problème c'est plus exactement que ce job ne calcule pas les histogrammes et qu'il me les faut, aussi je souhaite savoir comment le modifier ?

Merci beaucoup.

Bonjour,

le code source de ce package n'est pas tres clair ,
pour les histogrammes il faut peut-être utiliser le package
DBMS_STATS ?

cdlt

Merci,

D'accord avec toi, il n'est pas très clair !:cry:

Quelqu'un a déjà décodé cette procédure ?

Salutations

Je clos le post car trop peu d'intérêt.

Bonjour,

Base 10gr2 8Go de données dont 5Go de tables pour 3Go d'indexes.

J'ai deux paramètres dans un environnement OLTP où les requêtes répondent entre 3 secondes (70% de l'activité) et pour les plus grosses (30% de l'activité) 1 minute :

optimizer_index_caching à 0 et optimizer_index_cost_adj à 100.
Je veux les modifier afin d'inverser la sous utilisation des indexes à 80 pour le cache et 20 pour le coût.

1ère question : qu'est-ce que je risque ?

Ensuite la mémoire est gérée en auto par Oracle. 2 Go répartis comme suit :
- 880Mo en shared_pool
- 608Mo en dba_cache_size
- 250Mo en PGA

Les requêtes sont pour la plupart non bindés, le param cursor_sharing est à EXACT, il n'y a pas d'histogramme de calculé sur les indexes, les proc ne sont pas "pinées".

Je propose une action complète :
- pinned des procédures dans la limite de 50% de la shared_pool_reserved_size
- calcul des histogrammes pour les champs indéxés ou utilisés dans les clauses where
- cursor_sharing à SIMILAR
- gestion "manuelle" de la mémoire et du fait :
- baisse de la shared_pool à 400Mo
- augmentation du cache à 800Mo
- création d'un keep à 400Mo
- PGA à 300Mo

2è question : Ces conseils vous paraissent judicieux ou suis-je dans l'erreur la plus totale ?