[9i Tuning] Statspack

**MAGNUM_HEAD** · 13/03/2006, 16h31

Bonjour,

Oracle 9i sous Win2k,

Je viens de réaliser un rapport statspack entre deux snap et je suis un peu perdu... Existe-il une documentation détaillé parcourant un rapport statspack X et expliquant chaque point s? Donnant les conseils d'optimisation dans tel ou tel cas ?

Merci pour vos lumières,

**orafrance** · 13/03/2006, 16h55

essaye ceci : http://www.oraperf.com

**MAGNUM_HEAD** · 14/03/2006, 08h27

Merci Fred_d,

Cela semble intéressant.

Qu’elles sont vos règles pour fixer les paramètres du fichier d'initialialisation (ora).

Exe : db_cache_size = 2% de la taille de la base donnée ....

Existe-il des liens avec ses informations ?

Merci,

**orafrance** · 14/03/2006, 10h00

http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96533/build_db.htm#12646

Size of the buffer cache in the SGA. There are no good and simple rules to set a value, which is very application dependent, but typical values are in the range of twenty to fifty for each user session. More often, this value is set too high than too low.

Donc la réponse est : il faut fixer la valeur en fonction du contexte

**MAGNUM_HEAD** · 14/03/2006, 10h03

J'ai consulté le rapport de oraperf sur mon fichier de statistique et j'ai comparé ces deux fichiers.

Le rapport de oraperf présente les calculs et les conseils sur base de mon fichier stats, mais j'aimerais rester du côté du fichier stats afin de bien comprendre les différents éléments...

Dans sa mission de tuning le DBA se base uniquement sur ce fichier et conclut par lui-même sur les différents points à optimiser je pense.

J'aimerais comprendre se fichier statpack car sa lecture est assez compliquée...

**orafrance** · 14/03/2006, 11h11

la documentation dont j'ai donné le lien précédemment te sera précieuse. Tous les éléments y sont.

Par ailleurs, je ne peux que te conseiller la formation Tuning d'Oracle parce qu'en effet, ça ne s'invente pas

**MAGNUM_HEAD** · 15/03/2006, 14h10

Merci pour ton aide, j'avance tout doucement ;-)

Après plusieurs recherche il apparaît que la section Top 5 Timed Events est un indicateur de performance qui apporte énormément dans le rapport statspack. L'intervale entre les 2 snap est de 2 heures, le premier snap a été réalisé lorsque la base était calme et le deuxième lorsque la base était en plein traitement. Le serveur possède un seule processeur.

Code :

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

1
2
3
4
5
6
7
8
9
Top 5 Timed Events
 
Event                        		   Waits    Time(s)	% TotalEla Time
------------------------------ 	      -------	 ---- 	         --------
CPU time                                              297	   54.47
log file sync                  		 63,843	   167	         30.62
db file sequential read             12,166    33	     6.01
SQL*Net break/reset to client   4	     27	           4.90
log file parallel write                104,056  15	      2.80

Par exemple si j'ai bien compris, il s'agit des 5 evenements consommant trop temps.

log file sync : signifie que le process LGWR met trop de temps à écrire dans les données du log_buffer dans les fichiers redo log sur le disque.

Comment optimiser l'écriture ? Faire des redos de plus petites tailles ? Mettre les membres de chaque groupe dans deux partitions différentes....

Pourriez-vous me corriger et m'éclairer sur les autres points ? Quels sont les pistes à favoriser lorsque nous avons de forte consommation sur ces events ?

Merci d'avance,

**MAGNUM_HEAD** · 15/03/2006, 14h45

Concernant log file sync et log file parallel write j'ai trouvé mon bonheur dans :
http://mbouayoun.developpez.com/reglredo/#LIII

Ce que j'ai déjà conclus c'est qu'il y a trop de commit dans le code.
En effet nous insérons par exemple un fichier de 1000 lignes avec une procédure stockés ligne par ligne. Dans la procédure stocké, il y a un commit, donc 1000 commit... C'est probablement une des cause du log file sync.

**MAGNUM_HEAD** · 16/03/2006, 12h26

Envoyé par MAGNUM_HEAD

Comment optimiser l'écriture ? Faire des redos de plus petites tailles ? Mettre les membres de chaque groupe dans deux partitions différentes....

Pourriez-vous me corriger et m'éclairer sur les autres points ? Quels sont les pistes à favoriser lorsque nous avons de forte consommation sur ces events ?

Merci d'avance,

Pourriez-vous m'éclairer ?

**bouyao** · 16/03/2006, 12h40

Bonjour,

En lisant le lien que tu a donné, tu trouvera ton bonheur.

j'ai expliqué comment choisir la taille des fichier redo :

La réponse dépend de la taille du fichier redo en cours, du taux actuel de switch log et de l'objectif fixé en nombre de log switch par heure pendant les traitements. Pour trouver la fréquence des log switch en utilise la requête données dans la section log buffer space. Si notre objectif est de 4 fichiers redo par heure au lieu de 60 et que la taille du fichier redo en cours est de 20M, alors le nouveau fichier redo devrait avoir une taille de 300M (60*20M/4).

Malgré que ce tutoriel je ne l'ai pas encore terminé

**MAGNUM_HEAD** · 16/03/2006, 14h35

Bonjour,

je ne vois pas de reqûetes dans la section log buffer space.

J'ai une petite idée pour avoir la moyenne des switchs log sur une heure :

Code :

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

select sum(SWITCH)/count(HH) as SwitchParHeure from (select to_char(first_time,'HH24') as HH ,count(first_time) as SWITCH from v$log_history group by to_char(first_time,'HH24'));

Code :

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

1
2
3
SWITCHPARHEURE
--------------
    24,2857143

Mon objectif 4 fichiers redo/heure au lieu de 24
Taille du fichier en cours 50m

Nouveau fichier 300M (24*50m/4) ?

Est-ce correcte ?

Je crée donc 2 groupes avec 2 membres de 300m, total de 1.2 gb

:

D'avance merci

**bouyao** · 16/03/2006, 15h47

C'est correct

**MAGNUM_HEAD** · 17/03/2006, 09h54

Impeccable

Maintenant comment déterminer le meilleurs objectifs

:

Dans ton exemple tu précisais 4 redo/heure, comment choisir ce paramètre

:

Merci

**bouyao** · 17/03/2006, 10h17

Une chose que je n'ai pas indiqué dans l'article est le fameux paramètre :

Code :

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

ARCHIVE_LAG_TARGET

qui consite à switcher les logs même s'ils ne sont pas remplis.

Par exemple pour une valeur de 900 guarantié un switch log tous les 1/4 heurs.

Code :

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

alter system set ARCHIVE_LAG_TARGET=900 scope=both;

**MAGNUM_HEAD** · 17/03/2006, 11h03

8) Ok,

Pour revenir au log file sync et log file parallel write de mon top 5, j'ai vu sur ce site
http://www.dba-oracle.com/t_log_buffer.htm, qu'il était conseillé de maintenir une taille de log_buffer entre 5mb et 10mb.

En effet, notre log_buffer a la valeur par défaut 512k. Ce qui pourrait expliquer la quantité I/O... Mise à part le fait que nous avons beaucoup de commit. Car comme l'écriture du Log_buffer => redo file se fait aussi lorsqu'il est à 1/3 plein j'imagine que le notre doit être rapidement plein...

Quelle valeur avez-vous l'habitude de fixer

:

**Yorglaa** · 17/03/2006, 11h09

Personnellement j'ai eu de très mauvaises expériences avec un log_buffer trop gros (5MB).

Dans notre cas (machine assez ancienne) les disques ne sont pas très rapides, donc tant que les logs ne font que se remplir c'est OK, mais ensuite ils prennent un temps fou à se "décharger" sur les disques pour finaliser les écritures et le cycle complet des loggroups se terminaient avant que le prochain log du cycle n'ait fini de se vider du cycle précédent !

alors bonjour les temps d'attente pour les utilisateurs !

Alors tu as intérêt à avoir des disques très rapides et uniquement dédiés aux logs pour avoir des gros log_buffer.

**MAGNUM_HEAD** · 17/03/2006, 13h43

Oui effectivement, nous avons aussi des disques assez lent.
Il faudrait un bon compromis car 512K cela me semble limite quand même...

2 mb

:

**MAGNUM_HEAD** · 17/03/2006, 13h48

Tient je vais peut-être dire une bétise

Sous windows pour augmenter la vitesse des switch entre redo ne serait-il pas intelligent de prévoir une partition FAT32 qui est plus rapide que NTFS et qui acceuillerait que les redo logs ?

Bétise

:

**Yorglaa** · 17/03/2006, 13h57

ben pour le coup tes archives log serait formatés en Fat32, ce qui te laisse moins de latitude pour faire "en urgence" un recover sur une autre machine qui n'a pas forcément du Fat32 à dispo...

**Yorglaa** · 17/03/2006, 14h01

sinon pour la taille du log_buffer, je tourne aussi en 512k et tout va bien...

il ne faut pas confondre non plus, le buffer doit se vider DANS les logs. Donc rien à voir avec les logs switch.

je préfère avoir un peu plus fréquemment un "petit" buffer à écrire sur le(s) disque(s) que devoir attendre sur une grosse écriture sur des disques lents !

[9i Tuning] Statspack

Oracle

Vue hybride

Discussions similaires

Partager

Partager