Stats des redologs

**rohrim** · 11/06/2007, 11h12

Bonjour
comment interpreter ces chiffres ?

Code :

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

1
2
3
4
5
6
7
8
 
SQL> select *  from V$SYSSTAT where NAMe like 'redo log%';
 
STATISTIC# NAME                             CLASS      VALUE
---------- -------------------------- ---------- ----------
       122 redo log space requests                2        190
       123 redo log space wait time               2       8678
       124 redo log switch interrupts             2          0

Mes fichiers redo sont multipléxés sur 2 disques et sont au nombre de 3

d'aprtes la requete suivante, il switchent super souvent.
normal ?

SELECT a.sequence# ,
to_char(a.first_time,'DD-MON-YYYY HH:MI:SS') "date début Log",
( b.first_time - a.first_time ) * 3600*24 "Secondes"
FROM v$loghist a, v$loghist b
WHERE b.sequence#= a.sequence# + 1 ;

SEQUENCE# date début Log Secondes
---------- -------------------- ----------
45366 22-MAY-2007 10:06:58 6785
45367 22-MAY-2007 12:00:03 7837
45368 22-MAY-2007 02:10:40 101
45369 22-MAY-2007 02:12:21 2458
45370 22-MAY-2007 02:53:19 11210
45371 22-MAY-2007 06:00:09 19797
45372 22-MAY-2007 11:30:06 5898
45373 23-MAY-2007 01:08:24 269
45374 23-MAY-2007 01:12:53 1238
45375 23-MAY-2007 01:33:31 2194
45376 23-MAY-2007 02:10:05 530
45377 23-MAY-2007 02:18:55 4917
45378 23-MAY-2007 03:40:52 10227
45379 23-MAY-2007 06:31:19 5761
45380 23-MAY-2007 08:07:20 341
45381 23-MAY-2007 08:13:01 332
45382 23-MAY-2007 08:18:33 344
45383 23-MAY-2007 08:24:17 361
45384 23-MAY-2007 08:30:18 403
45385 23-MAY-2007 08:37:01 371
45386 23-MAY-2007 08:43:12 360
45387 23-MAY-2007 08:49:12 315
45388 23-MAY-2007 08:54:27 325
45389 23-MAY-2007 08:59:52 345
45390 23-MAY-2007 09:05:37 360
45391 23-MAY-2007 09:11:37 345
45392 23-MAY-2007 09:17:22 1327

SEQUENCE# date début Log Secondes
---------- -------------------- ----------
45393 23-MAY-2007 09:39:29 1577
45394 23-MAY-2007 10:05:46 4392
45395 23-MAY-2007 11:18:58 10533
45396 23-MAY-2007 02:14:31 78
45397 23-MAY-2007 02:15:49 1567
45398 23-MAY-2007 02:41:56 9469
45399 23-MAY-2007 05:19:45 18759
45400 23-MAY-2007 10:32:24 5281
45401 24-MAY-2007 12:00:25 18
45402 24-MAY-2007 12:00:43 17
45403 24-MAY-2007 12:01:00 16
45404 24-MAY-2007 12:01:16 17
45405 24-MAY-2007 12:01:33 17
45406 24-MAY-2007 12:01:50 16
45407 24-MAY-2007 12:02:06 17
45408 24-MAY-2007 12:02:23 20
45409 24-MAY-2007 12:02:43 21
45410 24-MAY-2007 12:03:04 16
45411 24-MAY-2007 12:03:20 19
45412 24-MAY-2007 12:03:39 20
45413 24-MAY-2007 12:03:59 17
45414 24-MAY-2007 12:04:16 22
45415 24-MAY-2007 12:04:38 18
45416 24-MAY-2007 12:04:56 19
45417 24-MAY-2007 12:05:15 16
45418 24-MAY-2007 12:05:31 14
45419 24-MAY-2007 12:05:45 15

SEQUENCE# date début Log Secondes
---------- -------------------- ----------
45420 24-MAY-2007 12:06:00 13
45421 24-MAY-2007 12:06:13 19
45422 24-MAY-2007 12:06:32 20
45423 24-MAY-2007 12:06:52 19
45424 24-MAY-2007 12:07:11 18
45425 24-MAY-2007 12:07:29 20
45426 24-MAY-2007 12:07:49 16
45427 24-MAY-2007 12:08:05 21
45428 24-MAY-2007 12:08:26 17
45429 24-MAY-2007 12:08:43 21
45430 24-MAY-2007 12:09:04 21
45431 24-MAY-2007 12:09:25 14
45432 24-MAY-2007 12:09:39 22
45433 24-MAY-2007 12:10:01 17
45434 24-MAY-2007 12:10:18 24
45435 24-MAY-2007 12:10:42 18
45436 24-MAY-2007 12:11:00 19
45437 24-MAY-2007 12:11:19 18
45438 24-MAY-2007 12:11:37 19
45439 24-MAY-2007 12:11:56 18
45440 24-MAY-2007 12:12:14 19
45441 24-MAY-2007 12:12:33 18
45442 24-MAY-2007 12:12:51 21
45443 24-MAY-2007 12:13:12 723
45444 24-MAY-2007 12:25:15 259
45445 24-MAY-2007 12:29:34 93
45446 24-MAY-2007 12:31:07 84

SEQUENCE# date début Log Secondes
---------- -------------------- ----------
45447 24-MAY-2007 12:32:31 16
45448 24-MAY-2007 12:32:47 79
45449 24-MAY-2007 12:34:06 102
45450 24-MAY-2007 12:35:48 81
45451 24-MAY-2007 12:37:09 44
45452 24-MAY-2007 12:37:53 79
45453 24-MAY-2007 12:39:12 86
45454 24-MAY-2007 12:40:38 98
45455 24-MAY-2007 12:42:16 89
45456 24-MAY-2007 12:43:45 58
45457 24-MAY-2007 12:44:43 73
45458 24-MAY-2007 12:45:56 66
45459 24-MAY-2007 12:47:02 86
45460 24-MAY-2007 12:48:28 35
45461 24-MAY-2007 12:49:03 52
45462 24-MAY-2007 12:49:55 87
45463 24-MAY-2007 12:51:22 76
45464 24-MAY-2007 12:52:38 90
45465 24-MAY-2007 12:54:08 31
45466 24-MAY-2007 12:54:39 82
45467 24-MAY-2007 12:56:01 90
45468 24-MAY-2007 12:57:31 46
45469 24-MAY-2007 12:58:17 85
45470 24-MAY-2007 12:59:42 60
45471 24-MAY-2007 01:00:42 124
45472 24-MAY-2007 01:02:46 31
45473 24-MAY-2007 01:03:17 42

**LeoAnderson** · 11/06/2007, 13h27

Le volume de redo log dépend exclusivement de l'activité transactionnelle. On n'a aucun levier là-dessus.
par contre, il y a trop de switches : augmentez la taille et le nombre des groupes.

**rohrim** · 11/06/2007, 14h17

D'accord pour le nombre de redo
ils font déjà chacuns 100Mo et je n'ai que 2 disques disponibles

D'une config suivante :
groupe1
redo_1a , redo_1b -> 100 Mo
groupe2
redo_2a , redo_2b -> 100 Mo
groupe3
redo_3a , redo_3b -> 100 Mo

je passerai a une config

D'une config suivante :
groupe1
redo_1a , redo_1b -> 150 Mo
groupe2
redo_2a , redo_2b -> 150 Mo
groupe3
redo_3a , redo_3b -> 150 Mo
groupe4
redo_4a , redo_4b -> 150 Mo

C'est ca ?

**LeoAnderson** · 11/06/2007, 14h47

Non.
sachant que la cible est 3-4 switches par heure "normale" d'activité et que, le 24/05 entre 12 et 13h il y a une 30 de switches, il faudrait multiplier la taille par 10, si l'activité y est alors représentative de l'activité normale

**louping** · 11/06/2007, 15h10

Le max de 80 switchs par jour ou 6 par heure me parait bien.
Sous TOAD tu as un vue graphique de cette activité...
4 switchs par minutes, c'est trop, le process d'archivage n'a peut-être pas fini lorsque Oracle demande de nouveau ce redo. Il y a surement des waits...
A+

**rohrim** · 11/06/2007, 15h40

oui , vous avez raison , je susi entrain de décortiquer le resultat de statpack et voila :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
TOP 5 DES EVENEMENTS CONSOMMANT DE LA CPU
 
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                                     % Total
Event                                               Waits    Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
db file sequential read                        14,389,603     256,052    59.21
CPU time                                                      123,656    28.59
buffer busy waits                                 938,262      13,974     3.23
direct path write                                  24,250      12,014     2.78
async disk IO                                   1,005,764       7,942     1.84
          -------------------------------------------------------------
Wait Events for DB: TEST  Instance: TEST  Snaps: 51383 -51416
-> s  - second
-> cs - centisecond -     100th of a second
-> ms - millisecond -    1000th of a second
-> us - microsecond - 1000000th of a second
-> ordered by wait time desc, waits desc (idle events last)
 
                                                                   Avg
                                                     Total Wait   wait    Waits
Event                               Waits   Timeouts   Time (s)   (ms)     /txn
---------------------------- ------------ ---------- ---------- ------ --------
db file sequential read        14,389,603          0    256,052     18     79.1
buffer busy waits                 938,262         10     13,974     15      5.2
direct path write                  24,250          0     12,014    495      0.1
async disk IO                   1,005,764          0      7,942      8      5.5
log file sync                     199,194         45      5,340     27      1.1
db file scattered read            350,879          0      5,319     15      1.9
log file parallel write           205,177    205,118      3,919     19      1.1
control file parallel write        42,458          0      1,478     35      0.2
db file parallel write             28,839          0      1,185     41      0.2
latch free                        288,977     19,215        460      2      1.6
library cache pin                  14,834          0        454     31      0.1
control file sequential read      228,503          0        377      2      1.3
direct path read                    6,067          0        134     22      0.0
log file sequential read            1,166          0         74     63      0.0
enqueue                               135          2         21    153      0.0
SQL*Net more data to client       287,374          0         19      0      1.6
SQL*Net break/reset to clien       12,624          0         13      1      0.1
log file switch completion             34          2         10    282      0.0
local write wait                      116          0          4     38      0.0
process startup                       102          0          4     41      0.0
db file single write                  210          0          3     14      0.0
log file single write                  44          0          1     16      0.0
wait list latch free                    9          0          0     18      0.0
direct path read (lob)                  1          0          0     23      0.0
undo segment extension             23,319     23,319          0      0      0.1
direct path write (lob)                 1          0          0     12      0.0
LGWR wait for redo copy                68          0          0      0      0.0
row cache lock                          1          0          0      1      0.0
SQL*Net message from client    12,671,864          0  1,479,003    117     69.6
jobq slave wait                     2,214      2,130      6,576   2970      0.0
SQL*Net message to client      12,671,869          0         27      0     69.6
SQL*Net more data from clien       20,081          0          4      0      0.1

c'est la cata non ?

perso je pense que oui, mais je débute dans le tuning

**pifor** · 11/06/2007, 17h40

L'evénement db file sequential read n'a rien à voir avec les redo logs: Les redo logs ne sont en général pas lus lors du fonctionnement normal de l'instance, Oracle ne fait qu'écrire dedans.

Pour en savoir un peu plus sur l'importance des attentes, il faudrait savoir:
quel est la durée du snapshot ?
quel est le nombre de processeurs sur votre serveur ?

**LeoAnderson** · 11/06/2007, 21h08

Et surtout "est-ce l'activité normale ?"
si 15 utilisateurs faisaient des exports/imports volumineux par exemple, ça fausse tout !

mais si c'était une journée comme les autres, oui, y'a du boulot !

**rohrim** · 12/06/2007, 08h10

Bonne question.
il me semble que certaines nuits, ils font des rebuild d'index
sachant que cet iindex faite 33 GO sur une base totale de 50 et que cet index est de l'intermedia text.

un rebuild d'index pourrait faire switcher les redo aussi souvent ?

je vais vérifier les autre nuit et je reposterai dans la journée un echantillion.

**LeoAnderson** · 12/06/2007, 08h27

des rebuilds indexes nocturnes ? c'est donc du batch, et ce serait dangereux de tuner en se basant sur cette activité si le rôle de la base c'est du transactionnel.

**louping** · 12/06/2007, 11h19

Pour les rebuild d'index, ajoute NOLOGGING, cela ne trace pas dans les redos, donc pas de switchs (moins)

db file sequential read 59.21%
Il y a des lectures non sequentiel, fragmentation ?
CPU time 28.59%
Ce qui provoque une augmentation du CPU

Il faudrait que tu nous fasse passer le tableau "Instance Efficiency Percentages"
pour voir les "Redo NoWait" et aussi le "buffer Hit".

donne-nous le résultat de :
prompt
prompt PGA : 9i Only
prompt +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
SELECT 'PGA size: '||VALUE/1024/1024||'M' from v$parameter where NAME = 'pga_aggregate_target' ;
SELECT 'PGA cache percentage : '||VALUE||' %' FROM V$PGASTAT
where name='cache hit percentage' ;
SELECT 'PGA over allocation : '||VALUE FROM V$PGASTAT
where name='over allocation count' ;
prompt If cache hit percentage < 90% and over allocation count != 0 increase PGA_AGGREGATE_TARGET
set heading on
SELECT round(PGA_TARGET_FOR_ESTIMATE/1024/1024) "PGA Mb",
ESTD_PGA_CACHE_HIT_PERCENTAGE "Cache %",
ESTD_OVERALLOC_COUNT "Over alloc"
FROM v$pga_target_advice;

A+

**LeoAnderson** · 12/06/2007, 11h37

1. pour l'option nologging, je suis plus réservé. Cela aura forcément un impact lourd sur la capacité et le temps de restauration.... :-/

2. Sequential reads = accès par index
quelle est le type d'activité que l'on étudie ????

**louping** · 12/06/2007, 12h12

Envoyé par LeoAnderson

1. pour l'option nologging, je suis plus réservé. Cela aura forcément un impact lourd sur la capacité et le temps de restauration.... :-/

2. Sequential reads = accès par index
quelle est le type d'activité que l'on étudie ????

A mon avis, une instance pour la restauration (manger)
J'ai une instance comme cela, avec bcp d'activité entre 12h et 14h, et bcp d'index et c'est la PGA qui mer.. (sortie des tickets)
A+

**rohrim** · 12/06/2007, 12h54

voila le resultat de la requete :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
    PGA Mb    Cache % Over alloc
---------- ---------- ----------
       175         95          0
       350         96          0
       700         97          0
      1050         97          0
      1400         99          0
      1680         99          0
      1960        100          0
      2240        100          0
      2520        100          0
      2800        100          0
      4200        100          0
 
    PGA Mb    Cache % Over alloc
---------- ---------- ----------
      5600        100          0
      8400        100          0
     11200        100          0
 
14 rows selected.

c'est une base de données pour un site web de type amazon.fr mais largement moins connu (peut pas dire le nom mais c'est sur des bouquins)
avec beaucoup de lecture et de recherche multicritere
il y a un index multicolonne de plusieurs millions de lignes

concernant les switch des redos en journée standard, ca donne ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
 SEQUENCE# date début Log         Secondes
---------- -------------------- ----------
     46489 10-JUN-2007 12:37:26      19364
     46490 10-JUN-2007 06:00:10       6971
     46491 10-JUN-2007 07:56:21      19454
     46492 10-JUN-2007 01:20:35      16977
     46493 10-JUN-2007 06:03:32       7346
     46494 10-JUN-2007 08:05:58       7058
     46495 10-JUN-2007 10:03:36       5886
     46496 10-JUN-2007 11:41:42      13928
     46497 11-JUN-2007 03:33:50       2093
     46498 11-JUN-2007 04:08:43       6267
     46499 11-JUN-2007 05:53:10      14877
 
 SEQUENCE# date début Log         Secondes
---------- -------------------- ----------
     46500 11-JUN-2007 10:01:07       4274
     46501 11-JUN-2007 11:12:21       2864
     46502 11-JUN-2007 12:00:05       5363
     46503 11-JUN-2007 01:29:28       5655
     46504 11-JUN-2007 03:03:43         67
     46505 11-JUN-2007 03:04:50         48
     46506 11-JUN-2007 03:05:38       5099
     46507 11-JUN-2007 04:30:37      14455
     46508 11-JUN-2007 08:31:32      10715
     46509 11-JUN-2007 11:30:07       9047
     46510 12-JUN-2007 02:00:54      23673

**bouyao** · 12/06/2007, 13h46

Tu a quoi comme version Oracle ?

**rohrim** · 12/06/2007, 13h53

serveur sun fire 880 4 proc de 800 Mhz
4 disques en scsi pas de raid juste du local
8 Go de Ram et 6 pour la SGA
je suis sous Oracle 9ir2

j'ai un disque a 100% full I/O en permanence (celui ou se trouve les redo + index + control)

**bouyao** · 12/06/2007, 15h02

C'est mieu de positionner le paramètre ARCHIVE_LAG_TARGET à 30 ou 20 minutes et tu met la taille des archivelogs a 500 Mo par exemple.

**rohrim** · 12/06/2007, 15h13

OK, Merci

je vais demander à changer ca :
augmenter la taille des archivelog et ajouter ce parametre

merci beaucoup pour vos aides précieuses
Je vous tiens au courant pour la performance

Stats des redologs

Administration Oracle

Discussions similaires

Partager

Partager