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
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
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 :
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.
Code : Sélectionner tout - Visualiser dans une fenêtre à part BEGIN MGMT_BSLN.COMPUTE_ALL_STATISTICS;/*DB*/END;
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 !
Quelqu'un a déjà décodé cette procédure ?
Salutations
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 ?
Partager