Checkpoint not complete

Version imprimable

Bonjour,

J'ai un petit souci et quelques interrogations.

Je suis sur un moteur oracle 9.2.0.4.0.

J'ai beaucoup de checkpoint not complete. Je n'ai aucun visu niveau applicatif (les joies du DBA de production en infogérance).

Ci-dessous la taille de mes redos actuel :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
SQL> SELECT a.group#, a.member, b.bytes/1024/1024 FROM v$logfile a, v$log b WHERE a.group# = b.group#;
 
    GROUP#                  MEMBER                   B.BYTES/1024/1024
----------------------------------------------------------------------
         1   /appli/oraredolog01/VICTOR/VICTOR_redo1_1.rdo      200
         1   /appli/oraredolog02/VICTOR/VICTOR_redo1_2.rdo      200
         2   /appli/oraredolog01/VICTOR/VICTOR_redo2_1.rdo      200
         2   /appli/oraredolog02/VICTOR/VICTOR_redo2_2.rdo      200
         3   /appli/oraredolog01/VICTOR/VICTOR_redo3_1.rdo      200
         3   /appli/oraredolog02/VICTOR/VICTOR_redo3_2.rdo      200
 
 
6 rows selected.
 
SQL>

Voici un extrait des switchs de redo logs :

Code:

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
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
 
SQL> col nb_de_transac for 999999
SQL> select SEQUENCE#,TO_CHAR(FIRST_TIME, 'DD-MM-YY HH24:MI:SS') as date_switch,NEXT_CHANGE#-FIRST_CHANGE# as nb_de_transac from v$log_history;
 
 
 SEQUENCE# DATE_SWITCH       NB_DE_TRANSAC
---------- ----------------- -------------
 
[...]
    566745 27-11-09 07:01:23         49792
    566746 27-11-09 07:01:58         31875
    566747 27-11-09 07:02:31         30232
    566748 27-11-09 07:03:07         16083
    566749 27-11-09 07:04:09         18820
    566750 27-11-09 07:04:47         15231
    566751 27-11-09 07:05:23         17246
    566752 27-11-09 07:06:02         17429
    566753 27-11-09 07:06:36         20427
    566754 27-11-09 07:07:10         22819
    566755 27-11-09 07:07:48         29155
    566756 27-11-09 07:09:16         11781
    566757 27-11-09 07:09:50          9976
    566758 27-11-09 07:10:23         13775
    566759 27-11-09 07:11:00          7220
    566760 27-11-09 07:11:55         19832
    566761 27-11-09 07:12:37         32473
    566762 27-11-09 07:13:27         23843
    566763 27-11-09 07:14:14        111963
    566764 27-11-09 07:15:57         56226
    566765 27-11-09 07:19:24          8143
    566766 27-11-09 07:19:59         93486
    566767 27-11-09 07:21:59         35273
    566768 27-11-09 07:22:43        203934
    566769 27-11-09 07:46:36          7554
    566770 27-11-09 07:47:48        254461
    566771 27-11-09 08:12:58          7533
    566772 27-11-09 08:13:38          3826
    566773 27-11-09 08:14:59          2409
    566774 27-11-09 08:16:13          2445
    566775 27-11-09 08:16:51          2335
    566776 27-11-09 08:17:23          2351
    566777 27-11-09 08:17:49          2412
    566778 27-11-09 08:18:17          2515
    566779 27-11-09 08:18:41        196768
    566780 27-11-09 08:47:49          2116
    566781 27-11-09 08:48:26       #######
    566782 27-11-09 19:00:23         11192
    566783 27-11-09 19:03:36         15023
    566784 27-11-09 19:32:04          1605
    566785 27-11-09 19:32:37          1826
    566786 27-11-09 19:33:22          1849
    566787 27-11-09 19:34:03          1721
    566788 27-11-09 19:34:39          1882
    566789 27-11-09 19:35:20          1686
    566790 27-11-09 19:35:57          1742
    566791 27-11-09 19:36:38          2035
    566792 27-11-09 19:37:18          1856
    566793 27-11-09 19:37:58          1861
    566794 27-11-09 19:38:43          1645
    566795 27-11-09 19:39:22          2094
    566796 27-11-09 19:40:10          3432
    566797 27-11-09 19:40:51          1950
    566798 27-11-09 19:41:32          1858
    566799 27-11-09 19:42:11          1943
    566800 27-11-09 19:42:51          1766
    566801 27-11-09 19:43:42          1835
    566802 27-11-09 19:44:34          1821
    566803 27-11-09 19:45:22          2140
    566804 27-11-09 19:46:48          1691
    566805 27-11-09 19:47:25          1888
    566806 27-11-09 19:48:02          1951
    566807 27-11-09 19:48:40          2399
    566808 27-11-09 19:49:21        434661
[...]

D'après Oracle pour optimizer les switch de redologs il faut tailler les redo log files de façon à ce que le switch se fasse toutes les 30 minutes.

Si je compte que j'ai un switch toues les 30 seconde pour des fichiers d'une taille de 200 Mo je devrais avoir des fichiers de 200 x 120 = 24Go le redo ...

Hors, si je fais comme ca la taille de mes redolog files deviendrait énorme ...

Quelle est votre avis sur la question ?

30/11/2009, 22h00
apersonnat
Bonjour,

Juste pour clarifier le nbre de groupe et de membres par redo, pourriez-vous svp faire un simple
Code:

1 2 3 select * from v$log; select * from v$logfile;
1 switch tte les 30mn, c'est la théorie ensuite il faut s'adapter à l'environnement.

Je pense qu'en augmentant le nombre de groupe et la taille des redo vous ne devriez plus avoir de 'checkpoint not complete'.

Bonne soirée,
Alain

J'ai 3 groupe de 2 membres chacun :

Code:

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
 
 
SQL> select GROUP#,STATUS from v$log;
 
    GROUP# STATUS
---------- ----------------
         1 INACTIVE
         2 INACTIVE
         3 CURRENT
 
 
SQL> SELECT a.GROUP#, a.member, b.bytes/1024/1024 FROM v$logfile a, v$log b WHERE a.group# = b.group#;
 
    GROUP#                  MEMBER                   B.BYTES/1024/1024
----------------------------------------------------------------------
         1   /appli/oraredolog01/VICTOR/VICTOR_redo1_1.rdo      200
         1   /appli/oraredolog02/VICTOR/VICTOR_redo1_2.rdo      200
         2   /appli/oraredolog01/VICTOR/VICTOR_redo2_1.rdo      200
         2   /appli/oraredolog02/VICTOR/VICTOR_redo2_2.rdo      200
         3   /appli/oraredolog01/VICTOR/VICTOR_redo3_1.rdo      200
         3   /appli/oraredolog02/VICTOR/VICTOR_redo3_2.rdo      200
 
 
6 rows selected.
 
SQL>

En quoi augmenter le nombre de groupe ferait que je n'ai plus de checkpoint not complete ? Oracle ne fait-il pas un checkpoint à chaque switch de redolog ?

01/12/2009, 08h56
apersonnat

Bien souvent cette attente résulte du fait qu'Oracle ne peut écrire dans le groupe suivant car il est tj actif (en train d'être archivé).

Comment est fait le découpage de l'architecture ? Est ce que les redo sont sur des disques à part ? et les archlogs ?

Cdt,
Alain
01/12/2009, 09h46
pachot

Bonjour,

Ces 'checkpoint not complete', est-ce qu'ils arrivent tout le temps, ou seulement à certaines periodes (genre lors de gros batch de chargement par exemple) ?

Ensuite, celà ne veut pas dire qu'il y a un problème de performance.
Est-ce des sessions sont en attentes sur 'log file sync' durant ces moments ?
Sinon, celà veut dire que le switch de log est effectivement en attente de la fin d'un checkpoint, mais que celà n'a pas d'impact sur les temps de réponse utilisateur.

Cordialement,
Franck.

Au niveau de l'architecture physique, il n'y a rien de particulier. (les redo et les archivelogs ne sont pas sur des disques a part, ni en direct I/O) Je ne suis pas maitre, malheureusement de l'architecture.

Pour ce qui est des erreur de checkpoint not complete, leur récurrence est variable. Mais les intervalles de switch sont tous les jours, tous le matin de moins d'une minute. Donc les checkpoint not complete dépendent de la charge disque.

Voici les events wait des log file (de 7h00 à 8h00 le matin) :
Code:

1 2 3 4 5 6 Avg Total Wait wait Waits Event Waits Timeouts Time (s) (ms) /txn ---------------------------- ------------ ---------- ---------- ------ log file sync 268,446 148 1,335 5 1.0

04/12/2009, 13h16
Boudine

Pas d'avis sur la situation ... ?
04/12/2009, 13h29
pachot

Citation:

Envoyé par Boudine

Pas d'avis sur la situation ... ?

Donc dbwriter a du mal à écrire sur disque toutes les modifications, aux moments où les switch de logs sont très importants.

Les 'log file sync', quel pourcentage du db time (ou total wait time) représentent-ils ?

Les solutions, ce serait soit de tuner les i/o (pour que dbwriter puisse écrire plus vite), soit générer moins de log (commits trop frequents peut-être)

A la limite, le rapport statspack ou AWR prise entre 7h et 8h, tu peux l'attacher à ta réponse, histoire d'y jetter un coup d'oeuil.

Franck.
04/12/2009, 13h33
pifor

Comme déjà dit, pour éliminer les "checkpoint non complete" il faut soit agrandir les online redo logs soit augmenter leur nombre.

Je ne suis pas entièrement d'accord avec Franck lorsqu'il dit qu'il n'y a pas de problème de performance: je crois que durant un checkpoint non complete et jusqu'à la fin du checkpoint, les transactions qui font COMMIT sont bloquées.

C'est ce que je comprends de cette discussion sur AskTom:
http://asktom.oracle.com/pls/asktom/...93900346690427 pour Oracle 10.2.0.4

Citation:

1) when we switch a logfile - we initiate a checkpoint of the blocks protected by that log file. But so many things initiate a checkpoint (your MTTR settings specifically) that a checkpoint was probably already happening. It kicks archiver off to archive the file as well. The switch itself won't 'degrade' performance. However, if we have failed to complete the checkpoint OR archive that log file before you return to it - that will affect performance as the database will PAUSE until the checkpoint completes or the archiver finishes.
04/12/2009, 13h51
pachot

Citation:

Envoyé par pifor

Je ne suis pas entièrement d'accord avec Franck lorsqu'il dit qu'il n'y a pas de problème de performance: je crois que durant un checkpoint non complete et jusqu'à la fin du checkpoint, les transactions qui font COMMIT sont bloquées.

Oui, exact. Je voulais seulement dire qu'il n'est peut être pas nécessaire de faire du tuning lorsque personne ne se plaint des performances. Le temps moyen du 'log file sync' wait est de 5 millisecondes. Ce n'est peut-être pas un problème 5 millisecondes de plus par commit (sauf si les commits sont trop frequents).

Sinon, effectiviement, l'idée c'est d'avoir assez de redo log (plus nombreux ou plus grands) pour pouvoir absorber cette periode de pic, en en ajoutant petit à petit.

Cordialement,
Franck.
04/12/2009, 13h56
jkofr

Citation:

Envoyé par pifor

Je ne suis pas entièrement d'accord avec Franck lorsqu'il dit qu'il n'y a pas de problème de performance: je crois que durant un checkpoint non complete et jusqu'à la fin du checkpoint, les transactions qui font COMMIT sont bloquées.

Oui c'est vrai:ccool:

Regarde la valeur de ton parametre log_checkpoint_interval
Tu peux le mettre a zéro si ce n'est pas le cas.
Regarde aussi la fréquence des switch. En gros on peut dire que un switch toutes les (entre 30 ou 60 minutes) est normal.
A toi d'augmenter la taille de tes redo pour te trouver dans cette fenêtre.

Ceci est bien sur valable pour un fonctionnement normal de ton application.
Il est utopique de vouloir illiminer les "checkpoint non complete " lors de traitements de masse.

Citation:

Envoyé par pachot

Les solutions, ce serait soit de tuner les i/o (pour que dbwriter puisse écrire plus vite), soit générer moins de log (commits trop frequents peut-être)

C'est le log writer qui écrit les redo logs.
Cependant ta remarque sur les contentions I/O est bonne. Dans ce cas il faudrait aller voir le compteur "Taille courante de la file d'attente' de perfmon (si sous windows) pour confirmer ca. Une valeur continuellement > a 0 est pas bon signe.

Jko
04/12/2009, 14h16
pachot

Citation:

Envoyé par jkofr

C'est le log writer qui écrit les redo logs.

Oui mais c'est dbwriter qui écrit les blocs lors du checkpoint, et c'est ça qui traine ici. A la limite, log writer il est trop rapide...