Discussion :

[laurentAM]

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

[Invité]

J'ai un job lancé par sysman COMPUTE_ALL_STATISTICS.

CALCULE_TOUTES_LES_STATISTIQUES

[ducho]

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

[laurentAM]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[ducho]

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

[laurentAM]

Merci,

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

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

Salutations

[laurentAM]

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 ?