Bonjour,
qq'un connaiterait-il un site qui expliquerait comment interpéter un rapport statspack?
merci d'avance
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Interprétation du rapport Statspack
Bonjour,
qq'un connaiterait-il un site qui expliquerait comment interpéter un rapport statspack?
merci d'avance
Peut-être le site référencé par Burleson Consulting et ex Oraperf (non testés).
Il y également des notes intéressantes sur le blog de Jonathan Lewis.
Idéalement il faudrait comparer les rapports avec un état du sytème "normal" et un état du système "lent".
Vous pouvez aussi poster votre rapport ici avec les bonnes balises de formatage.
en fait j'essai d'optimiser un traitement batch qui dure un peu moins de 30h.
j'ai lancé un cliché statspack avant le traitement et un autre à un peu plus de la moitié (le traitement est tjr en cours).
J'ai édité le rapport statspack mais j'ai du mal à interpréter les résultats.
qq'un peut-il m'aider? comment puis-je mettre à disposition du forum mon rapport?
Si le traitement est en cours, inutile de regarder le statspack. Toutes les infos sont dispo en live dans v$session_wait, v$system_event et autres tables du dictionnaire.
Statspack c'est plutôt pour trouver les maladies de la base, quand t'as un problème sur un traitement particulier une trace est plus utile
je sais mais j'ai pas encore préparé mes scripts pour requêter les vues dynamiques, j'aimerais juste interpréter dans un 1er temps mon rapport statspack pour voir pourquoi mon traitement batch est si long: est ce un pb de buffer cache?de tri?
Donnez-nous:
- la version d'Oracle
- la durée exacte du rapport Statspack
- le nombre de processeurs de la machine
- le rapport Statspack complet ou au moins les sections Cache Sizes, Load Profile, Instance Efficiency Percentages, Top 5 Timed Events, Events,
Instance Activity Stats, Tablespace IO Stats for DB, Buffer Pool Statistics for DB, Buffer Pool Advisory for DB, SGA Memory Summary for DB.
La bonne durée d'un rapport Statspack est 15 à 30 minutes.
le problème étant que si le rapport a été lancé durant une longue requête, on ne la verra pas
Enfin, au moins le top des events et waits pourraient être intéressant
la machine a 4 processeurs, c'est un solaris 10 64 bits avec 16Go de RAM
la base est une base 9.2.0.8
voici un extrait de mon rapport:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
et voici la suite:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
voici la partie advice:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
voici la fin:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
quelle est la taille des REDO et la fréquence de switch ? As-tu bien mis les redos et leur mirroir sur des disques différents ? Cette instance est-elle répliquée via Dataguard par exemple ?
le rapport porte sur des snapshots trop éloignés aussi... faudrait en refaire 2 avec seulement 30 minutes d'intervalle.
Tiens, regarde ce tuto : http://mbouayoun.developpez.com/reglredo
Je pense qu'il pourrait t'aider
enfin avec un CPU Time de 60% on aura du mal à voir quelque chose de probantFaudrait vraiment un rapport sur une période plus courte.
les redo font 100 Mo
la fréquence de switch varie entre 3 et 6 minutes et sont tous sur le même disk.
Il n'y a pas de Dataguard.
je sais que le switch devrait se faire toutes les 20/30 minutes.
Comment as-tu su à partir du rapport statspack qu'il y'avait un souci au niveau des redo? Pourquoi un intervalle de 30 minutes pour le rapport statspack?
20 minutes c'est trop long... 3/6 minutes c'est très bien
j'ai suspecté les redos en regardant les événements d'attente :
CPU Time n'est pas significatif, db file sequential READ c'est de l'accès par index, et en continuant je trouve 2 événements liés aux logs.Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time 14,604 60.42
db file sequential READ 998,164 2,685 11.11
log file parallel WRITE 167,783 1,459 6.04
log file sequential READ 32,754 1,459 6.04
SQL*Net more DATA TO client 2,135,088 1,191 4.93
Mais au regard de ta réponse j'vois pas où il pourrait y avoir souci... encore une fois, la période est trop longue pour se faire une idée
c bizarre que tu me dises ça.3/6 minutes c'est très bien
j'étais en formation TUNING chez Oracle fin Janvier et le formateur m'a dit que c'était trop court et qu'il fallait compter environ 20 à 30 minutes entre chaque switch.
Autre question: le tutoriel sur le réglage des redo tu l'as trouvé où? parceque dans la page des tutoriels Oracle il n'y figure pas.
je suis en train de générer un rapport entre 2 snapshot de 30 minutes.
Voici un rapport statspack avec un interval de 30 minutes:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
Non car:Envoyé par farenheiit
Vous avez 3316 * 60 * 1072 = 213 285 120 requêtes exécutées pendant la durée analysée: c'est énorme !Buffer Hit %: 99.86 In-memory Sort %: 100.00
Vous avez environ 7 millions d'échanges entre l'instance et ses clients:
Comme le temps d'attente de 507 784 secondes est supérieure à la durée d'analyse, cela veut dire que le batch semble tourner en paralllèle avec des sessions d'utilisateurs qui utilisent l'application. Est-ce le cas ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Il faudrait mettre le traitement batch du début à la fin en mode trace avec les temps d'attente pour avoir les détails au niveau du batch en lui-même avec:
Si le batch contribute pour une partie importante sur les 507 000 secondes d'attente, cela peut signifier que les programmes batch client travaillent plus que l'instance Oracle. Il est aussi possible ques les programmes batch exécutent trop de requêtes SQL qui à chaque fois retourne quelques lignes de données.
Code : Sélectionner tout - Visualiser dans une fenêtre à part ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 12'
C'est sans doute un problème mineur mais vous avez aussi des temps d'E/S qui sont parfois trop longs (70/80 voir 100 ms) sur certains tablespaces.
est-ce que ça veut dire qu'entre les 2 snapshots tous mes tris se font en mémoire et que 99.86% des fois que le process cherche une donnée il la trouve dans le buffer cache? Si oui pourquoi les vues dynamique V$DB_CACHE_ADVICE et V$PGA_TARGET_ADVICE me recommandent-elles de doubler le db_cache_size et le pga_aggregate_target????Buffer Hit %: 99.86 In-memory Sort %: 100.00
comment obtenez-vous ce chiffre?Vous avez 3316 * 60 * 1072 = 213 285 120 requêtes exécutées pendant la durée analysée: c'est énorme !
j'ai bcp de requêtes car mon traitement batch fais des boucles sur des tables et insère dans d'autres tables après avoir appliquer pas mal de règles de gestion.
oui c'est le cas. mon traitement batch s'execute sous le user DBO_TUNING, mais il y'a une IHM disponible aux utilisateurs qui effectuent certaines requetes sur d'autres shémas (mais rien de bien méchant). il y'a aussi un moteur de calcul JAVA qui se connecte et se deconnecte sans cesse de la base pour voir s'il y'a des traitements le concernant.Comme le temps d'attente de 507 784 secondes est supérieure à la durée d'analyse, cela veut dire que le batch semble tourner en paralllèle avec des sessions d'utilisateurs qui utilisent l'application. Est-ce le cas ?
où voyez-vous ça?vous avez aussi des temps d'E/S qui sont parfois trop longs (70/80 voir 100 ms) sur certains tablespaces
Dois je relancer mon traitement batch avec ce mode? et après? je récupère des snapshots et j'execute un rapport statspack ou bien ça n'a rien à voir?Il faudrait mettre le traitement batch du début à la fin en mode trace avec les temps d'attente pour avoir les détails au niveau du batch
Hello,
Tous ça me parle pas trop à part 2 ou 3 paramêtres à toucher, peut on voir dans ce même statpack les ordres sql ?
Merci
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager