Oracle 10G Statistiques SYSTEM

Bonjour tout le monde,

en général, je ne lance pas de statistiques sur les schémas SYSTEM et SYS.
Un editeur me demande de les passer pour optimiser de maniere
automatique le paramètre db_file_multiblock_read_count .

Comment vérifier que les stats sont bien executées sur ces schémas ?
est-ce bien judicieux ?

Cordialement

Le job GATHER_STATS_JOB activé par défaut en 10g calcule par défaut les statistiques sur les objets SYS et SYSTEM. Vous pouvez vérifier par exemple avec:

Code:

---

1 2 3 4

select table_name, last_analyzed from dba_tables where owner in ('SYSTEM', 'SYS');

---

Votre éditeur confond 2 choses:
- les statistiques sur les objets des comptes SYS et SYSTEM
- les statistiques système qui consistent à prendre en compte la rapidité du processeur et du stockage:
http://download.oracle.com/docs/cd/B...ats.htm#i41496

Bonjour,

Ce n'est pas l'éditeur qui a confondu , c'est moi !!!
Il a bien demandé à executer la procédure :

Citation:

---

DBMS_STATS.GATHER_SYSTEM_STATS

---

ce qui d'apres la doc est utile depuis oracle10 .

Je ne connaissais pas et pensais que cette proc lançait les stats
sur les schémas SYSTEM et SYS.

Les stats sur les schémas SYSTEM et SYS comme je j'ai déjà constaté
ne datent pas des mêmes jours, ce que je ne comprends toujours pas

en tout cas merci pour la réponse, je vais executer cette procédure
sur mes bases en oracle10 et 11.
cordialement

Citation:

---

Envoyé par ducho

Les stats sur les schémas SYSTEM et SYS comme je j'ai déjà constaté
ne datent pas des mêmes jours, ce que je ne comprends toujours pas

---

Par défaut Oracle 10 ne recalcule les statistiques sur un objet que si l'objet a eu plus de 10% de modifications.

Je crois qu'il y a mauvaise compréhension.

DBMS_STATS.GATHER_SYSTEM_STATS n'est pas conçu pour jouer les statistiques des tables des schémas SYS et SYSTEM mais pour renseigner l'optimiseur sur les performances réelles de votre système.

Par défaut, Oracle relève des métriques pour son optimiseur basé sur les coûts CPU au démarrage de l'instance, donc sans charge (noworkload).

Cela se fait, pour une collecte de 20 minutes à jouer en pleine charge, via l'ordre

Code:

---

exec dbms_stats.gather_system_stats(gathering_mode => 'interval', interval => 30)

---

Avant d’exécuter cela, il convient de relever les valeurs actuelles via

Code:

---

1 2 3

select pname param, pval1 valeur from sys.aux_stats$ where sname='SYSSTATS_MAIN' ;

---

Sur une base où il n'y a que les valeurs en mode noworkload, l'affichage ressemble à cela

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

PARAM VALEUR ------------------------------ ---------- CPUSPEEDNW 1273.890005 IOSEEKTIM 10 IOTFRSPEED 4096 SREADTIM MREADTIM CPUSPEED MBRC MAXTHR SLAVETHR   9 lignes sélectionnées

---

Notez le CPUSPEEDNW (NW pour no workload), et le CPUSEED à NULL.

Il convient donc de jouer la transaction DBMS_STATS.GATHER_SYSTEM_STATS en mode pleine charge afin qu'il obtienne de meilleures informations.
Et il convient de le rejouer à chaque fois que les ressources de la machine contenant la base changent... vous aurez bien compris qu'en environnement virtuel où les ressources sont modifiées à la volée, cette paramétrisation revêt une importance toute particulière !

... et là, ô miracle, les valeurs réelles apparaissent... et elles peuvent sensiblement différer des valeurs NW.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

PARAM VALEUR ------------------------------ ---------- CPUSPEED 1350 -- en millions, nombre d'opérations par seconde que le CPU est en mesure d'effectuer en pleine charge CPUSPEEDNW 1606.268 -- en millions, nombre d'opérations par seconde que le CPU est en mesure d'effectuer sans charge (qui correspond généralement à la cadence CPU) IOSEEKTIM 5.927 -- temps de recherche E/S en ms IOTFRSPEED 36432.71 -- temps de transfert E/S en ms MAXTHR 450000 -- débit maximum des E/S MBRC 10 -- nombre moyen de blocs lus lors d'une lecture multiblocs MREADTIM 3 -- vitesse en ms de lecture d'un multibloc SLAVETHR SREADTIM 4 -- vitesse en ms de lecture d'un seul bloc

---

Charger ces données n'est pas anodin ! Cela va fortement influencer le comportement de votre optimiseur... et, partant, un certain nombre de plans d'exécution... pour le meilleur et pour le pire :mouarf: