Discussion :

[glood1]

bonjour,


j'ai actuellement des problèmes sur une base ORACLE 9i pas tres bien architecturée
beaucoup IO

on me demande d otptimiser la base malgre un MCD mediocre

que puis je faire pour améliorer l'existant.

STATSPACK report for

DB Name DB Id Instance Inst Num Release Cluster Host
------------ ----------- ------------ -------- ----------- ------- ------------
INFO 728677380 INFO 1 9.2.0.5.0 NO ALPHA8

Snap Id Snap Time Sessions Curs/Sess Comment
------- ------------------ -------- --------- -------------------
Begin Snap: 4 28-Sep-09 16:36:52 12 5.6
End Snap: 6 28-Sep-09 16:57:43 12 5.5
Elapsed: 20.85 (mins)

Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 32M Std Block Size: 8K
Shared Pool Size: 112M Log Buffer: 512K

Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 1,698.40 1,062,348.00
Logical reads: 685.84 428,994.50
Block changes: 9.77 6,111.00
Physical reads: 653.58 408,813.50
Physical writes: 0.55 346.00
User calls: 0.58 363.50
Parses: 0.95 591.50
Hard parses: 0.01 4.00
Sorts: 0.63 391.00
Logons: 0.00 1.00
Executes: 1.83 1,145.50
Transactions: 0.00

% Blocks changed per Read: 1.42 Recursive Call %: 85.12
Rollback per transaction %: 0.00 Rows per Sort: 1268.70

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 4.71 In-memory Sort %: 100.00
Library Hit %: 99.67 Soft Parse %: 99.32
Execute to Parse %: 48.36 Latch Hit %: 99.98
Parse CPU to Parse Elapsd %: 84.62 % Non-Parse CPU: 99.72

Shared Pool Statistics Begin End
------ ------
Memory Usage %: 42.74 42.86
% SQL with executions>1: 59.14 66.60
% Memory for SQL w/exec>1: 50.18 60.29

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
db file sequential read 451,828 1,225 90.47
db file scattered read 22,901 86 6.37
CPU time 40 2.94
control file sequential read 294 1 .09
control file parallel write 407 1 .05
-------------------------------------------------------------
Wait Events for DB: INFO Instance: INFO Snaps: 4 -6
-> 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 451,828 0 1,225 3 ########
db file scattered read 22,901 0 86 4 ########
control file sequential read 294 0 1 4 147.0
control file parallel write 407 0 1 2 203.5
db file parallel read 14 0 1 43 7.0
log file parallel write 1,805 0 0 0 902.5
log file sync 3 0 0 3 1.5
SQL*Net more data to client 33 0 0 0 16.5
buffer busy waits 22 0 0 0 11.0
undo segment extension 208 207 0 0 104.0
latch free 16 15 0 0 8.0
direct path read 9 0 0 0 4.5
direct path write 9 0 0 0 4.5
LGWR wait for redo copy 4 0 0 0 2.0
SQL*Net message from client 554 0 2,905 5244 277.0
virtual circuit status 42 42 1,260 30000 21.0
wakeup time manager 40 40 1,185 29620 20.0
SQL*Net more data from clien 72 0 0 0 36.0
SQL*Net message to client 554 0 0 0 277.0
-------------------------------------------------------------
Background Wait Events for DB: INFO Instance: INFO Snaps: 4 -6
-> ordered by wait time desc, waits desc (idle events last)

Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
---------------------------- ------------ ---------- ---------- ------ --------
control file sequential read 164 0 1 6 82.0
control file parallel write 407 0 1 2 203.5
log file parallel write 1,805 0 0 0 902.5
db file sequential read 27 0 0 6 13.5
db file scattered read 9 0 0 6 4.5
rdbms ipc reply 115 0 0 0 57.5
buffer busy waits 7 0 0 0 3.5
LGWR wait for redo copy 4 0 0 0 2.0
latch free 3 3 0 0 1.5
rdbms ipc message 3,157 1,221 4,917 1558 1,578.5
pmon timer 419 419 1,251 2986 209.5
smon timer 5 3 1,204 ###### 2.5
-------------------------------------------------------------
SQL ordered by Gets for DB: INFO Instance: INFO Snaps: 4 -6
-> End Buffer Gets Threshold: 10000
-> Note that resources reported for PL/SQL includes the resources used by
all SQL statements called within the PL/SQL code. As individual SQL
statements are also reported, it is possible and valid for the summed
total % to exceed 100

CPU Elapsd
Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
365,400 1 365,400.0 42.6 34.31 119.36 767427966
Module: wiqt.exe
SELECT BO_FOURNISSEURS.LBFOU1, BO_ACHATS.NUSUC, BO_ACHA
TS.NUFOU, sum(decode(sign(8+(trunc((to_number(( '200907' ))-0
8)/100)*100) - to_number(substr(BO_ACHATS.DTREC,1,6))-1),-1, d
ecode( sign (to_number(substr(BO_ACHATS.DTREC,1,6))-1 - to_nu
mber(( '200907' ))),-1,BO_ACHATS.CAHRT))) FROM BO_FOURNISS

16,186 40 404.7 1.9 0.92 1.87 815501214
select t.schema, t.name, t.flags, q.name from system.aq$_queue_t
ables t, sys.aq$_queue_table_affinities aft, system.aq$_que
ues q where aft.table_objno = t.objno and aft.owner_instance = :
1 and q.table_objno = t.objno and q.usage = 0 and b
itand(t.flags, 4+16+32+64+128+256) = 0 for update of t.name, aft

14,753 2 7,376.5 1.7 1.19 2.34 2522684317
Module: SQL*Plus
BEGIN statspack.snap; END;

11,982 2 5,991.0 1.4 0.35 0.43 1116368370
Module: SQL*Plus
INSERT INTO STATS$SQLTEXT ( HASH_VALUE , TEXT_SUBSET , PIECE , S
QL_TEXT , ADDRESS , COMMAND_TYPE , LAST_SNAP_ID ) SELECT ST1.HAS
H_VALUE , SS.TEXT_SUBSET , ST1.PIECE , ST1.SQL_TEXT , ST1.ADDRES
S , ST1.COMMAND_TYPE , SS.SNAP_ID FROM V$SQLTEXT ST1 , STATS$SQL
_SUMMARY SS WHERE SS.SNAP_ID = :B3 AND SS.DBID = :B2 AND SS.INST

j'ai également un report sur ORAPERF

PRODUCING too many read consistency block
TOO may block cleanouts on commits
scanning too many buffers
large of frequent small rollbacks





merci de votre avis

[13thFloor]

Hello,

version 9.2.0.5 => il est temps de passer en 9.2.0.8 au moins

Buffer Hit %: 4.71 => j'ai rarement vu aussi faible. Une augmentation de db_cache_size et sga_max_size pourra être envisagée s'il y a suffisamment de RAM dispo sur le serveur 32Mo de cache data pour 112Mo de shared pool, c'est peu).

db file scattered read => vérifier les accès en full table scan -> rubrique physical reads. lance un ?/rdbms/admin/sprepsql avec les hash_value les plus consommatrices (en % de la période du snap). Essaies d'éliminer les FTS (par index, histogrammes, partitionnement...)

db file sequential read => index peu sélectif ?

Quelles sont les valeurs, dans le rapport, des temps d'accès aux datafiles,
des buffer busy waits et des itl waits (si le snapshot a été pris en lvl 7) ?

C'est visiblement la 1ère requête qui gloutonne la cpu : à optimiser en fonction de son plan d'exécution (voir le rapport sprepsql).

[farenheiit]

C'est une base de prod ça?
avec 32mo de cache t'iras pas bien loin, t'es condammné à faire des accès disk

[glood1]

Hello,

version 9.2.0.5 => il est temps de passer en 9.2.0.8 au moins

Buffer Hit %: 4.71 => j'ai rarement vu aussi faible. Une augmentation de db_cache_size et sga_max_size pourra être envisagée s'il y a suffisamment de RAM dispo sur le serveur 32Mo de cache data pour 112Mo de shared pool, c'est peu).

db file scattered read => vérifier les accès en full table scan -> rubrique physical reads. lance un ?/rdbms/admin/sprepsql avec les hash_value les plus consommatrices (en % de la période du snap). Essaies d'éliminer les FTS (par index, histogrammes, partitionnement...)

db file sequential read => index peu sélectif ?

Quelles sont les valeurs, dans le rapport, des temps d'accès aux datafiles,
des buffer busy waits et des itl waits (si le snapshot a été pris en lvl 7) ?

C'est visiblement la 1ère requête qui gloutonne la cpu : à optimiser en fonction de son plan d'exécution (voir le rapport sprepsql).

hello
merci pour votre peine

Petit precision c 'est un datawarhouse sous open vms donc peu de memoire et un lourd historique (pas mal d' index et de full table scan)

le sga free est jamais plein

j' ai fait des statspack periode de 1 heure et 30 minute pendant une semaine

je suis etonné du hit ratio ici a 4.71 dans un autre 51.36 et 73 de plus
qd je lance la requete pour les hit ratio


select
100*(1 - (v3.value / (v1.value + v2.value))) "Cache Hit Ratio [%]"
from
v$sysstat v1, v$sysstat v2, v$sysstat v3
where
v1.name = 'db block gets' and
v2.name = 'consistent gets' and
v3.name = 'physical reads'


82.1307991717226 %

pourquoi le ratio est il bon en temps reel est mauvais dans les statspack


essai d eliminer fts ? tu peux developper

je peux envoyer plusieurs spreport je suis entrain de les examiner pour voir si on est en corrélation
qui se propose (j en ai tant que je veux j ai un job qui tourne)


tu veux que je lance un script avec les requettes qui consomme le plus de ressources ? hadh value (cela veut dire quoi deja)
ok

[glood1]

deux autre version

B Name DB Id Instance Inst Num Release Cluster Host
------------ ----------- ------------ -------- ----------- ------- ------------
INFO 728677380 INFO 1 9.2.0.5.0 NO ALPHA8

Snap Id Snap Time Sessions Curs/Sess Comment
------- ------------------ -------- --------- -------------------
Begin Snap: 39 02-Oct-09 14:30:04 12 2.5
End Snap: 41 02-Oct-09 15:30:04 13 2.3
Elapsed: 60.00 (mins)

Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 32M Std Block Size: 8K
Shared Pool Size: 112M Log Buffer: 512K

Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 1,229.38 340,442.77
Logical reads: 858.23 237,664.46
Block changes: 8.80 2,436.92
Physical reads: 437.49 121,150.00
Physical writes: 17.33 4,799.08
User calls: 0.53 146.31
Parses: 0.88 242.92
Hard parses: 0.00 0.85
Sorts: 0.46 126.38
Logons: 0.01 3.15
Executes: 1.67 461.85
Transactions: 0.00

% Blocks changed per Read: 1.03 Recursive Call %: 86.25
Rollback per transaction %: 46.15 Rows per Sort: 6195.61

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 51.36 In-memory Sort %: 99.76
Library Hit %: 99.81 Soft Parse %: 99.65
Execute to Parse %: 47.40 Latch Hit %: 99.98
Parse CPU to Parse Elapsd %: 79.41 % Non-Parse CPU: 99.85

Shared Pool Statistics Begin End
------ ------
Memory Usage %: 79.71 80.11
% SQL with executions>1: 77.61 77.49
% Memory for SQL w/exec>1: 65.83 65.65

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
db file scattered read 93,590 508 56.72
CPU time 357 39.82
db file sequential read 14,073 26 2.93
control file sequential read 600 2 .22
log file parallel write 5,178 1 .13
-------------------------------------------------------------
Wait Events for DB: INFO Instance: INFO Snaps: 39 -41
-> 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 scattered read 93,590 0 508 5 7,199.2
db file sequential read 14,073 0 26 2 1,082.5
control file sequential read 600 0 2 3 46.2
log file parallel write 5,178 0 1 0 398.3
control file parallel write 1,171 0 1 1 90.1
SQL*Net more data to client 5,685 0 0 0 437.3
process startup 6 0 0 36 0.5
direct path read 12,093 0 0 0 930.2
direct path write 8,502 0 0 0 654.0
latch free 11 8 0 2 0.8
SQL*Net break/reset to clien 2 0 0 1 0.2
LGWR wait for redo copy 34 0 0 0 2.6
log file sync 1 0 0 0 0.1
SQL*Net message from client 1,782 0 7,508 4213 137.1
virtual circuit status 120 120 3,575 29790 9.2
wakeup time manager 118 118 3,476 29453 9.1
jobq slave wait 133 126 400 3005 10.2
SQL*Net message to client 1,783 0 0 0 137.2
SQL*Net more data from clien 126 0 0 0 9.7
-------------------------------------------------------------
Background Wait Events for DB: INFO Instance: INFO Snaps: 39 -41
-> ordered by wait time desc, waits desc (idle events last)

Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
---------------------------- ------------ ---------- ---------- ------ --------
control file sequential read 468 0 2 4 36.0
log file parallel write 5,178 0 1 0 398.3
control file parallel write 1,171 0 1 1 90.1
db file scattered read 51 0 0 5 3.9
db file sequential read 34 0 0 5 2.6
LGWR wait for redo copy 34 0 0 0 2.6
latch free 1 0 0 0 0.1
rdbms ipc message 8,550 3,519 13,650 1597 657.7
pmon timer 1,208 1,208 3,598 2979 92.9
smon timer 11 11 3,136 ###### 0.8
-------------------------------------------------------------
SQL ordered by Gets for DB: INFO Instance: INFO Snaps: 39 -41
-> End Buffer Gets Threshold: 10000
-> Note that resources reported for PL/SQL includes the resources used by
all SQL statements called within the PL/SQL code. As individual SQL
statements are also reported, it is possible and valid for the summed
total % to exceed 100

CPU Elapsd
Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
2,569,512 1 2,569,512.0 83.2 114.15 490.68 1766649387
Module: WIReportServer.exe
SELECT SCC_PS_PVT.NUSUC, BO_FOURNISSEURS.NUFOU, sum(ST1_S
TOCKS.STNA * ST1_STOCKS.PXSMP), ST1_STOCKS.DATE_INTEGRATION FR
OM SCC_PS_PVT, BO_FOURNISSEURS, ST1_STOCKS, ST1_ARTSUC W
HERE ( ST1_STOCKS.NUSUC=ST1_ARTSUC.NUSUC and ST1_STOCKS.NUART=
ST1_ARTSUC.NUART ) AND ( SCC_PS_PVT.NUSUC=ST1_STOCKS.NUSUC a

329,508 4 82,377.0 10.7 151.26 302.56 933122211
Module: wiqt.exe
SELECT INFOCLIENT.NUSUC, BO_PVT_AFFECTATION.NUSUC || BO_PV
T_AFFECTATION.NUPVT || ' ' || BO_PVT_AFFECTATION.LBSAT, BO_S
VT.NUSVT || ' ' || BO_SVT.LBVND2, sum(decode( INFOCLIENT.DTE
NR6, to_char(( '200909' )),(INFOCLIENT.CASTAT))), sum(decod
e(INFOCLIENT.DTENR6,to_char(( '200909' )),(INFOCLIENT.MTPBVT))),

47,343 118 401.2 1.5 2.46 2.87 815501214
select t.schema, t.name, t.flags, q.name from system.aq$_queue_t
ables t, sys.aq$_queue_table_affinities aft, system.aq$_que
ues q where aft.table_objno = t.objno and aft.owner_instance = :
1 and q.table_objno = t.objno and q.usage = 0 and b
itand(t.flags, 4+16+32+64+128+256) = 0 for update of t.name, aft

43,005 2 21,502.5 1.4 2.02 4.54 2390807850
DECLARE job BINARY_INTEGER := :job; next_date DATE := :mydate;
broken BOOLEAN := FALSE; BEGIN PERFSTAT.STATSPACK.SNAP; :mydate
:= next_date; IF broken THEN :b := 1; ELSE :b := 0; END IF; END;


41,042 2 20,521.0 1.3 0.90 1.11 1116368370
Module: SQL*Plus
INSERT INTO STATS$SQLTEXT ( HASH_VALUE , TEXT_SUBSET , PIECE , S
QL_TEXT , ADDRESS , COMMAND_TYPE , LAST_SNAP_ID ) SELECT ST1.HAS
H_VALUE , SS.TEXT_SUBSET , ST1.PIECE , ST1.SQL_TEXT , ST1.ADDRES
S , ST1.COMMAND_TYPE , SS.SNAP_ID FROM V$SQLTEXT ST1 , STATS$SQL
_SUMMARY SS WHERE SS.SNAP_ID = :B3 AND SS.DBID = :B2 AND SS.INST

38,460 2 19,230.0 1.2 56.28 88.48 3351753059
Module: wiqt.exe
SELECT BO_PVT_AFFECTATION.NUSUC || BO_PVT_AFFECTATION.NUPVT |
| ' ' || BO_PVT_AFFECTATION.LBSAT, BO_RAYON.LBRAY, BO_SUR
_FAMILLE.NUSURF||' '||BO_SUR_FAMILLE.LBSURF, BO_FAMILLE.NUFA
|| ' ' || BO_FAMILLE.LIBFA, BO_SOUS_FAMILLE.NUFA || BO_SOUS
_FAMILLE.NUSF || ' ' || BO_SOUS_FAMILLE.LIBSF, sum(decode(ST


STATSPACK report for

DB Name DB Id Instance Inst Num Release Cluster Host
------------ ----------- ------------ -------- ----------- ------- ------------
INFO 728677380 INFO 1 9.2.0.5.0 NO ALPHA8

Snap Id Snap Time Sessions Curs/Sess Comment
------- ------------------ -------- --------- -------------------
Begin Snap: 1 28-Sep-09 15:37:40 11 3.2
End Snap: 3 28-Sep-09 16:29:34 13 5.2
Elapsed: 51.90 (mins)

Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 32M Std Block Size: 8K
Shared Pool Size: 112M Log Buffer: 512K

Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 1,348.05 2,098,920.00
Logical reads: 4,502.69 7,010,683.50
Block changes: 9.06 14,113.50
Physical reads: 743.10 1,157,014.00
Physical writes: 73.33 114,176.00
User calls: 0.74 1,154.50
Parses: 1.31 2,046.50
Hard parses: 0.06 92.00
Sorts: 0.71 1,102.50
Logons: 0.01 11.00
Executes: 2.21 3,437.00
Transactions: 0.00

% Blocks changed per Read: 0.20 Recursive Call %: 91.18
Rollback per transaction %: 0.00 Rows per Sort: 245.08

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 83.91 In-memory Sort %: 99.91
Library Hit %: 97.10 Soft Parse %: 95.50
Execute to Parse %: 40.46 Latch Hit %: 99.99
Parse CPU to Parse Elapsd %: 70.21 % Non-Parse CPU: 97.29

Shared Pool Statistics Begin End
------ ------
Memory Usage %: 35.88 42.50
% SQL with executions>1: 60.79 58.97
% Memory for SQL w/exec>1: 52.52 49.92

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
db file sequential read 411,260 1,571 69.90
db file scattered read 116,645 599 26.64
CPU time 73 3.25
control file sequential read 601 2 .08
control file parallel write 1,013 1 .05
-------------------------------------------------------------
Wait Events for DB: INFO Instance: INFO Snaps: 1 -3
-> 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 411,260 0 1,571 4 ########
db file scattered read 116,645 0 599 5 ########
control file sequential read 601 0 2 3 300.5
control file parallel write 1,013 0 1 1 506.5
log file parallel write 4,473 0 1 0 2,236.5
SQL*Net more data to client 4,865 0 0 0 2,432.5
direct path write 32,203 0 0 0 ########
db file parallel read 7 0 0 12 3.5
direct path read 9,065 0 0 0 4,532.5
LGWR wait for redo copy 42 0 0 0 21.0
latch free 13 5 0 0 6.5
log file sync 2 0 0 1 1.0
SQL*Net break/reset to clien 20 0 0 0 10.0
buffer busy waits 1 0 0 0 0.5
SQL*Net message from client 1,900 0 7,432 3912 950.0
virtual circuit status 104 104 3,120 30000 52.0
wakeup time manager 101 101 2,992 29625 50.5
SQL*Net more data from clien 246 0 0 0 123.0
SQL*Net message to client 1,900 0 0 0 950.0
-------------------------------------------------------------
Background Wait Events for DB: INFO Instance: INFO Snaps: 1 -3
-> ordered by wait time desc, waits desc (idle events last)

Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
---------------------------- ------------ ---------- ---------- ------ --------
control file sequential read 404 0 2 4 202.0
control file parallel write 1,013 0 1 1 506.5
log file parallel write 4,474 0 1 0 2,237.0
db file scattered read 72 0 0 6 36.0
db file sequential read 96 0 0 3 48.0
rdbms ipc reply 65 0 0 0 32.5
LGWR wait for redo copy 42 0 0 0 21.0
latch free 3 1 0 0 1.5
rdbms ipc message 7,472 3,041 12,956 1734 3,736.0
smon timer 11 10 3,170 ###### 5.5
pmon timer 1,046 1,046 3,115 2978 523.0
-------------------------------------------------------------
SQL ordered by Gets for DB: INFO Instance: INFO Snaps: 1 -3
-> End Buffer Gets Threshold: 10000
-> Note that resources reported for PL/SQL includes the resources used by
all SQL statements called within the PL/SQL code. As individual SQL
statements are also reported, it is possible and valid for the summed
total % to exceed 100

CPU Elapsd
Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
303,615 1 303,615.0 2.2 30.14 1071.32 1487298357
Module: BUSOBJ.EXE
SELECT STATARTICLE.NUART, BO_ARTICLE.LBART, BO_ARTFOUR.
NUARFO, BO_ARTFOUR.NUFOU, BO_FOURNISSEURS.LBFOU1, BO_SU
R_FAMILLE.NUSURF||' '||BO_SUR_FAMILLE.LBSURF, BO_FAMILLE.NUF
A || ' ' || BO_FAMILLE.LIBFA, sum(decode( sign( (trunc
((to_number(( '200908' )))/100)*100) -to_number(STATARTICLE.D

115,571 1 115,571.0 0.8 12.74 447.19 2648353455
Module: BUSOBJ.EXE
SELECT STATARTICLE.NUART, BO_ARTICLE.LBART, BO_ARTFOUR.
NUFOU, BO_FOURNISSEURS.LBFOU1, BO_ARTFOUR.NUARFO, BO_SU
R_FAMILLE.NUSURF||' '||BO_SUR_FAMILLE.LBSURF, BO_FAMILLE.NUF
A || ' ' || BO_FAMILLE.LIBFA, sum(decode( sign( (trunc
((to_number(( '200908' )))/100)*100) -to_number(STATARTICLE.D

40,708 101 403.0 0.3 2.29 3.53 815501214
select t.schema, t.name, t.flags, q.name from system.aq$_queue_t
ables t, sys.aq$_queue_table_affinities aft, system.aq$_que
ues q where aft.table_objno = t.objno and aft.owner_instance = :
1 and q.table_objno = t.objno and q.usage = 0 and b
itand(t.flags, 4+16+32+64+128+256) = 0 for update of t.name, aft

21,918 2 10,959.0 0.2 0.40 1.99 1886383545
Module: TOAD 9.5.0.31
Select owner ,decode(partition_name, null, segment_name, s
egment_name || ':' || partition_name) objectname ,segment
_type objecttype ,nvl(bytes, 0) "SIZE" ,nvl(initia
l_extent, 0) INITIALEXT ,nvl(next_extent, 0) NEXTEXT
,nvl(extents, 0) NUMEXTENTS ,nvl(max_extents, 0) "MAXE

[glood1]

Hello,

version 9.2.0.5 => il est temps de passer en 9.2.0.8 au moins

Buffer Hit %: 4.71 => j'ai rarement vu aussi faible. Une augmentation de db_cache_size et sga_max_size pourra être envisagée s'il y a suffisamment de RAM dispo sur le serveur 32Mo de cache data pour 112Mo de shared pool, c'est peu).

db file scattered read => vérifier les accès en full table scan -> rubrique physical reads. lance un ?/rdbms/admin/sprepsql avec les hash_value les plus consommatrices (en % de la période du snap). Essaies d'éliminer les FTS (par index, histogrammes, partitionnement...)

db file sequential read => index peu sélectif ?

Quelles sont les valeurs, dans le rapport, des temps d'accès aux datafiles,
des buffer busy waits et des itl waits (si le snapshot a été pris en lvl 7) ?

C'est visiblement la 1ère requête qui gloutonne la cpu : à optimiser en fonction de son plan d'exécution (voir le rapport sprepsql).

il a y que de 2 GO de ram sur le serveur
on va tuner la fiat panda pour quelle roule a 200

je vais essayer de gratter 150 mo


j ai aussi enomement de db file sequentiel read sur une dizaine de statpack

[orafrance]

c'est normal, tu as des 'accès par les index c'est plutôt bon par contre tu as trop de db file scattered read = Full table scan

[pachot]

Bonjour,

Tu es sur un datawarehouse, avec peu d'utilisateurs en même temps (d'après tes statspack, il y a en moyenne une seule session active - calculé avec total wait time / elapsed time) donc je ne vois aucune raison pour regarder le cache hit ratio: ce sont à chaque fois des requêtes sur des données différentes, aucune raison pour les garder en cache.

Si tu trouves de la mémoire, c'est plutot pour la PGA qu'ils seront utiles. Peut-être que tes requêtes font des jointures nested loop à outrance (->db file sequential reads) alors qu'avec un peu plus de mémoire l'optimiseur choisirait un hash join (->beaucoup moins d'i/o). Donc une piste: regarder le paramétrage xxx_area_size ou pga_aggregate_target.

Tu peux prendre comme exemple les requêtes que tu as dans le statspack, ou d'autre qui durent très longtemps, et essayer de voir leur plan d'execution, combien de lignes elles ramènent, et si un hash join ne serait pas plus judicieux.

En soi, tes i/o sont corrects (5 milliseconde en moyenne), je ne pense pas que tu ait interêt à garder beaucoup de données en cache. Sauf s'il y a des données frequemment accédées, genre tables de dimensions, et dans ce cas peut être lse forcer à rester en cache. Parce qu'avec tous ces 'db file sequential read' dans une si petit buffer cache, les données référentielles sont peut être rapidement éjectées même si elles sont frequemment utilisées.

Mais la meilleur piste à mon sens, c'est voir plan d'execution de quelques requêtes lourdes, qui se retrouverait à faire des nested loop (donc aller faire un 'db file sequential read' pour chaque ligne) au lieu d'un hash join (donc quelques 'db file squattered read' qui ramènent des milliers d'enregistrements en un i/o).Dans ce cas:
-> essai avec hints pour forcer le hash join
-> voir les paramètres pga pour utiliser toute la mémoire physique utilisable (mais pas plus !)
Si les nested loop sont inévitables, alors il faudra voir les indexes les plus utilisés et voir le clustering factor correspondant.

Bon courage.
Franck.

[glood1]

Bonjour,

Tu es sur un datawarehouse, avec peu d'utilisateurs en même temps (d'après tes statspack, il y a en moyenne une seule session active - calculé avec total wait time / elapsed time) donc je ne vois aucune raison pour regarder le cache hit ratio: ce sont à chaque fois des requêtes sur des données différentes, aucune raison pour les garder en cache.

Si tu trouves de la mémoire, c'est plutot pour la PGA qu'ils seront utiles. Peut-être que tes requêtes font des jointures nested loop à outrance (->db file sequential reads) alors qu'avec un peu plus de mémoire l'optimiseur choisirait un hash join (->beaucoup moins d'i/o). Donc une piste: regarder le paramétrage xxx_area_size ou pga_aggregate_target.

Tu peux prendre comme exemple les requêtes que tu as dans le statspack, ou d'autre qui durent très longtemps, et essayer de voir leur plan d'execution, combien de lignes elles ramènent, et si un hash join ne serait pas plus judicieux.

En soi, tes i/o sont corrects (5 milliseconde en moyenne), je ne pense pas que tu ait interêt à garder beaucoup de données en cache. Sauf s'il y a des données frequemment accédées, genre tables de dimensions, et dans ce cas peut être lse forcer à rester en cache. Parce qu'avec tous ces 'db file sequential read' dans une si petit buffer cache, les données référentielles sont peut être rapidement éjectées même si elles sont frequemment utilisées.

Mais la meilleur piste à mon sens, c'est voir plan d'execution de quelques requêtes lourdes, qui se retrouverait à faire des nested loop (donc aller faire un 'db file sequential read' pour chaque ligne) au lieu d'un hash join (donc quelques 'db file squattered read' qui ramènent des milliers d'enregistrements en un i/o).Dans ce cas:
-> essai avec hints pour forcer le hash join
-> voir les paramètres pga pour utiliser toute la mémoire physique utilisable (mais pas plus !)
Si les nested loop sont inévitables, alors il faudra voir les indexes les plus utilisés et voir le clustering factor correspondant.

Bon courage.
Franck.

merci ouais en hit ratio les requetes sont rarement re-utilisé je vais mettre la fin des statpack pas mal intéréssant

je pense pas que cela sert en pga peut etre
ok je peux vous mettre les plans d exécutions mais d après ma memoire j' ai vu des requete lourdes venant de bo ou d un client similaire
il y avait pas mal de nested loop

peux tu developpez pour le hash join
les hints je vois ce que c 'est
j' ai monitoré les index mais il me semble qu' il me dis ceux non utilisés
comme voir les plus utilises et que faire avec clustering factor



le tablespace temp monte pas mal en io aussi mais si les requetes sont foireuses


merci pour votre aide en tout cas, puis je vous envoyer les 3 ou 4 requetes les plus lourdes ou les plans d 'execution pour que vous me confimier ce que je trouve

[glood1]

sur oraperf le statpack donne cela
en advice :
1/ Reduce the number of buffer gets or executions
2/ Reduce the number of physical reads per execution



General Information


This report is generated by the new Report generator. It is still Beta. Please report problems to OraPerf.com Support

Timing Information

Begin Time End Time Seconds Elapsed
02-Oct-09 14:30:04 02-Oct-09 15:30:04 3600

Version Information

Host Name Version Information
xxxx 9.2.0.5.0

Breakdown of Response Time

Response Time Time Percentage Per Execute Per User Call Per Transaction
Response Time 446890 100.00% 74.43 234.96 74481.67
CPU Time 35690 7.99% 5.94 18.76 5948.33
Wait Time 411200 92.01% 68.49 216.19 68533.33

Breakdown of CPU Time

If the CPU time is the largest contributor to the total response time, it will need to be brokendown into different areas of CPU usage. In Oracle we can currently have three areas of CPU usage:

* Parse CPU Time
* Recursive CPU Time
* Other CPU Time

CPU Time Time Percentage Per Execute Per User Call Per Transaction
Total 35690 100.00% 5.94 18.76 5948.33
Parse CPU Time 54 0.15% 0.01 0.03 9.00
Recursive CPU Time 773 2.17% 0.13 0.41 128.83
Other CPU Time 34863 97.68% 5.81 18.33 5810.50
Analyzing Parse CPU Time

parse - execute ratio

3158 parses (11 hard parses), 6004 executions of SQL statements happened. Normally the number of parses should be low and executions should be high. Each cursor was parsed an average of 1.03 times. A value greater than 1, means that the same cursor is parsed more than once. A value lower than 1 means that not all opened cursors have been parsed yet. Parsing the same cursor again and again will consume CPU and other resources. There is no need to parse the same cursor again for each execute. The re-parsing normally happens becomes some applications have an build in cursor cache which is configured too small. Making the cursor cache in the application larger will reduce the reparsing. During this interval 41 sessions logged on and at the end of the timing interval 0 more sessions where active.

The init.ora parameter SESSION_CACHED_CURSORS has NOT been set. Setting this parameter (start with a value of 100), will reduce contention during parsing.

Here is a list that you can check in your application:

* Ensure that the application is using bind variables.
* When using PCC programs: make sure that the number of open cursors is high enough.
* When using PCC programs: use release_cursor = NO and hold_cursor = YES.
* SQL statements can be parsed once and executed many times with bind variables, so check the design of the application.
* When using XA programs make sure that the connect string contains a large enough setting for the session cursor cache.

parse contention

During parsing 540 msec of CPU were used and 140 msec was spent waiting on resources. This will most likely will be latch contention on 'library cache' latch.
Analyzing Recursive CPU Time

Recursive CPU can be high for different reasons:

* Many data dictionary statements are parsed and executed over and over again.

Analyzing All Other CPU Time

A number of things can be consuming the remaining CPU:

* Inefficient SQL statements (too many block gets)
* Producing too many Read Consistency blocks
* Too many block cleanouts on commit
* Scanning too many buffers
* Large or frequent small rollbacks

Inefficient SQL statements

There are 3066731 block gets and 6004 statement executed (avg. 520.80 gets/execute).

Here are the top SQL statements ordered by buffer gets per execute:



During this interval 118 CR blocks were created (or 0.03 per second).

Consistent Read Operations Type Total Per Execute
CR Block gets 3066731 510.78
CR - no work 1541640 256.77
CR - cleanouts 12 0.00
CR - cleanouts and rollbacks 0 0.00
CR - rollbacks 590 0.10
Block Cleanout
Block Cleanouts on Commit Type Total Per Commit
Total cleanouts 7694 1099.14
Successfull cleanouts 7694 1099.14
Cleanout failures 0 0.00

Other Block Cleanout failures Type Total Per Commit
Write Disabled 0 0.00
Buffer being written or block lost 0 0.00
Hot Backup in Progress 0 0.00
Callback failure or can't pin the buffer 0 0.00
Buffer Scanning

On average 1.00 buffers needed to bescanned to find a free buffer. On average 0.00 dirty buffers were found that were moved to the write queue.

Rollbacks

There were 6 rollbacks and 0 undo records were rollbacked in the timing period.

Breakdown of Wait Time

The wait for the foreground sessions can be broken down in the following wait events (in order of wait time):
Wait Time Event Time Percentage Avg. Wait Per Execute Per User Call Per Transaction
virtual circuit status 357500 86.94% 2979.17 59.54 187.96 59583.33
db file scattered read 50800 12.35% 0.54 8.46 26.71 8466.67
db file sequential read 2600 0.63% 0.18 0.43 1.37 433.33
control file sequential read 200 0.05% 0.33 0.03 0.11 33.33
control file parallel write 100 0.02% 0.09 0.02 0.05 16.67
log file sync 0 0.00% 0.00 0.00 0.00 0.00
process startup 0 0.00% 0.00 0.00 0.00 0.00
SQL*Net message to client 0 0.00% 0.00 0.00 0.00 0.00
SQL*Net break/reset to clien 0 0.00% 0.00 0.00 0.00 0.00
SQL*Net more data from clien 0 0.00% 0.00 0.00 0.00 0.00
direct path read 0 0.00% 0.00 0.00 0.00 0.00
SQL*Net more data to client 0 0.00% 0.00 0.00 0.00 0.00
direct path write 0 0.00% 0.00 0.00 0.00 0.00
latch free 0 0.00% 0.00 0.00 0.00 0.00
Idle Time Wait Events

The following events can be ignored as they indicate idle time in the foreground process. They could be relevant if another process (like an application client) is waiting on the foreground process.

Wait Time Event Time Per Wait Per Execute Per User Call Per Transaction
SQL*Net message from client 7508 4.21 1.25 3.95 1251.33
wakeup time manager 3476 29.46 0.58 1.83 579.33
jobq slave wait 400 3.01 0.07 0.21 66.67
log file parallel write 1 0.00 0.00 0.00 0.17
LGWR wait for redo copy 0 0.00 0.00 0.00 0.00
virtual circuit status

This event is used to indicate waiting on the server and and waiting on the client. In this report we are assuming that 100 percent is used for waiting on the client.
db file scattered read

File IO is probably one of the most important areas where you can tune. There are basically two areas:

* The amount of IO.
* The cost per IO.

The amount of I/O

There are a number of things that you can do to reduce the number of IOs:

* Increase buffer cache

Currently there are 0 database buffers configured.

* Check on disk sorts

There have been 4 sort(s) to disk. Sorts to disk could cause many dirty buffers to be flushed to disk and they may have to be read later again.



The cost of I/O

Sometimes by just reducing the amount of IO, each IO can become cheaper because less IO means less contention on IO resources. If for some reason you can't reduce the amount of IO you may look at making each IO cheaper. The way to do this would be to increase the number of spindles and/or controllers. Sometimes a diffent disk layout can also make a big difference. Never split index and data files to different sets of disks. It is generally better to stripe all files over all available disks.

Distribution of I/O Operations Operation Foreground Perc Background Perc Total Perc Total
Single block data file reads 14073 11.69% 34 6.15% 14107 11.09%
Multi block data file reads 93590 77.76% 51 9.22% 93641 73.58%
Control file reads 600 0.50% 468 84.63% 1068 0.84%
Data file writes 0 0.00% 0 0.00% 0 0.00%
Control file writes 1171 0.97% 1171 18.44% 2342 1.84%
Log file writes 5178 4.30% 5178 81.56% 10356 8.14%

The reads are 95% of all the I/O operations that happenend.
File I/O in msec File Name Reads Avg Read (ms) Avg Blocks/Rd Writes Buffer Waits Avg Buf Waits(ms)
ALPHA8:[ORACLE9I.ORADATA.INFO]STOCKS_13.DBF 15386 4.7 16.0 0 0
ALPHA8:[ORACLE9I.ORADATA.INFO]TEMP_07.DBF 6643 5.6 5.9 5632 0
ALPHA8:[ORACLE9I.ORADATA.INFO]STOCKS_14.DBF 5487 4.6 15.9 0



db file sequential read

Please check under db file scattered read for advise.
control file sequential read

A foreground process had to read some data from the control file. This shouldn't happen a lot.
control file parallel write

There are many reasons why the control would/could be updated, but the most likely reason is for a checkpoint. So when this event is high on the list, check the checkpoint activity. During this interval 0 checkpoints have started and 0 completed.
log file sync

The average wait time per Transaction is 0.00 msecs. The average number of redo blocks written per redo write is 1.97 block(s). The average number of redo blocks per commit is 1460.71 block(s). The average number of redo blocks per transaction is 1704.17 block(s). If the number of redo blocks written per write is large enough, consider striping the redo logfile over a number of disks with a small enough stripe width.

Another option is to decrease the init.ora parameter "processes". The LGWR needs to scan all processes to find each process that is waiting for the commit to be written. The current value for processes is 150. Try setting it close to the number of process that you really need.

process startup

Waiting for a background process (for Parallel Query to startup e.g.) to startup. Check to see if you need to increase min_servers.
SQL*Net message to client

The Oracle Server is experiencing some delays in sending data to the client side. This could happen if the network connection is slow or has some other performance problem. This send send should work without a delay.
SQL*Net break/reset to clien

The client is sending some bundled calls or doing an array operation that resulted in an error at the server side. The server can't receive the remaining data and notifies the client to reset the connection.
SQL*Net more data from clien

The client side is inserting large records and/or is using array insert. Basically the client side is sending more data than will fit in one SQL*Net package. Increasing the package size will help to reduce this event and will help to improve performance. One needs to be using Net 2.3 or higher to set the SDU and TDU sizes at client AND the server side.
direct path read

This event can happen during sorting, direct load or parallel query operations. If it is sorting, check the sort stats and consider using a larger sort_area_size. If it is because of any parallel operations, check the plan of the statement that is being executed.
SQL*Net more data to client

The client side is selecting large records and/or is using array fetch. Basically the Oracle Server is sending more data thand will fit in a SQL*Net package. Increasing the package size will help to reduce this event and will help to improve performance. One needs to be using Net 2.3 or higher to set the SDU and TDU sizes at client AND the server side.
direct path write

This event can happen during sorting, direct load or parallel query operations. If it is sorting, check the sort stats and consider using a larger sort_area_size. If it is because of any parallel operations, check the plan of the statement that is being executed.
latch free

Below follows a table with the overview of which latch is responsible for most waits.

Latch Sleep Statistics Per Latch Latch Name Gets Sleeps Percentage Cumulative
cache buffers lru chain 1506658 1 100.00% 100.00 %

* cache buffers lru chain

No advice available yet.

The following places in the Oracle kernel caused the latch free events to occur.

Latch Sleep Statistics Per Latch Function/Where Latch Name Sleeps Percentage Cumulative
kcbzib: multi-block read: cache buffers chains 3 27.27% 27.27 %
kcbrls: kslbegin cache buffers chains 2 18.18% 45.45 %
kcbzgb: scan from tail no cache buffers chains 2 18.18% 63.64 %
kcbgtcr: kslbegin excl cache buffers chains 1 9.09% 72.73 %
kcbzgb: wait cache buffers lru chain 1 9.09% 81.82 %
kcbzib: mbr get multiblock read objects 1 9.09% 90.91 %
kcrfwr redo allocation 1 9.09% 100.00 %

[farenheiit]

peux tu executer la requête suivante et nous envoyer les résultats:

Code :

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

select name,value from v$parameter where ISDEFAULT = 'FALSE';

[orafrance]

tes posts sont illisibles glood1

[glood1]

tes posts sont illisibles glood1

ok j ai enlevé des parties
vous les requetes qui consomment le plus

[glood1]

peux tu executer la requête suivante et nous envoyer les résultats:

Code :

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

select name,value from v$parameter where ISDEFAULT = 'FALSE';

processes 150

[orafrance]

ok j ai enlevé des parties
vous les requetes qui consomment le plus

Tu peux aussi ajouter les balises QUOTE pour améliorer la lisibilité

[glood1]

Bonjour,

Tu es sur un datawarehouse, avec peu d'utilisateurs en même temps (d'après tes statspack, il y a en moyenne une seule session active - calculé avec total wait time / elapsed time) donc je ne vois aucune raison pour regarder le cache hit ratio: ce sont à chaque fois des requêtes sur des données différentes, aucune raison pour les garder en cache.

Si tu trouves de la mémoire, c'est plutot pour la PGA qu'ils seront utiles. Peut-être que tes requêtes font des jointures nested loop à outrance (->db file sequential reads) alors qu'avec un peu plus de mémoire l'optimiseur choisirait un hash join (->beaucoup moins d'i/o). Donc une piste: regarder le paramétrage xxx_area_size ou pga_aggregate_target.

Tu peux prendre comme exemple les requêtes que tu as dans le statspack, ou d'autre qui durent très longtemps, et essayer de voir leur plan d'execution, combien de lignes elles ramènent, et si un hash join ne serait pas plus judicieux.

En soi, tes i/o sont corrects (5 milliseconde en moyenne), je ne pense pas que tu ait interêt à garder beaucoup de données en cache. Sauf s'il y a des données frequemment accédées, genre tables de dimensions, et dans ce cas peut être lse forcer à rester en cache. Parce qu'avec tous ces 'db file sequential read' dans une si petit buffer cache, les données référentielles sont peut être rapidement éjectées même si elles sont frequemment utilisées.

Mais la meilleur piste à mon sens, c'est voir plan d'execution de quelques requêtes lourdes, qui se retrouverait à faire des nested loop (donc aller faire un 'db file sequential read' pour chaque ligne) au lieu d'un hash join (donc quelques 'db file squattered read' qui ramènent des milliers d'enregistrements en un i/o).Dans ce cas:
-> essai avec hints pour forcer le hash join
-> voir les paramètres pga pour utiliser toute la mémoire physique utilisable (mais pas plus !)
Si les nested loop sont inévitables, alors il faudra voir les indexes les plus utilisés et voir le clustering factor correspondant.

Bon courage.
Franck.

avec hints pour forcer le hash join
il faut que j essaie sur les requetes les plus lourdes peut tu detailler un peu
merci

[glood1]

avec hints pour forcer le hash join
il faut que j essaie sur les requetes les plus lourdes peut tu detailler un peu
merci

une des requetes qui explose tout

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
SELECT   statarticle.nusuc, bo_succursale_livraison.lbsuc, statarticle.nupvtl,
         bo_pvt_livraison.lbsat, statarticle.nuart, bo_article.lbart,
         statarticle.cdtyar, SUM (statarticle.qtfacb),
         SUM (statarticle.castat), SUM (statarticle.nbsort), bo_famille.nufa,
         bo_famille.libfa, bo_sous_famille.nusf, bo_sous_famille.libsf
    FROM bo_famille,
         bo_succursale bo_succursale_livraison,
         bo_sous_famille,
         bo_pvt bo_pvt_livraison,
         bo_section,
         bo_article,
         statarticle
   WHERE (    statarticle.cdtyar = bo_article.cdtyar
          AND statarticle.nuart = bo_article.nuart
         )
     AND (bo_famille.nufa = bo_sous_famille.nufa)
     AND (    bo_sous_famille.nusf = bo_section.nusf
          AND bo_sous_famille.nufa = bo_section.nufa
         )
     AND (    bo_article.nusec = bo_section.nusec
          AND bo_article.nufa = bo_section.nufa
          AND bo_article.nusf = bo_section.nusf
         )
     AND (bo_pvt_livraison.nusuc = bo_succursale_livraison.nusuc)
     AND (    bo_pvt_livraison.nusuc = statarticle.nusuc
          AND statarticle.nupvtl = bo_pvt_livraison.nupvt
         )
     AND (    statarticle.dtenr6 BETWEEN '200810' AND '200909'
          AND statarticle.nusuc IN ('14', '27', '94', '50')
         )
GROUP BY statarticle.nusuc,
         bo_succursale_livraison.lbsuc,
         statarticle.nupvtl,
         bo_pvt_livraison.lbsat,
         statarticle.nuart,
         bo_article.lbart,
         statarticle.cdtyar,
         bo_famille.nufa,
         bo_famille.libfa,
         bo_sous_famille.nusf,
         bo_sous_famille.libsf;

[orafrance]

Et les balises bon sang !

Sans explain plan ça va pas beaucoup nous aider ta requête

[glood1]

Et les balises bon sang !



sorry pour les balises oublie de ma part


Sans explain plan ça va pas beaucoup nous aider ta requête

Plan
SELECT STATEMENT CHOOSECost: 175,576 Bytes: 3,902,860 Cardinality: 22,958
16 SORT GROUP BY Cost: 175,576 Bytes: 3,902,860 Cardinality: 22,958
15 HASH JOIN Cost: 174,468 Bytes: 3,902,860 Cardinality: 22,958
1 TABLE ACCESS FULL EXPL.BO_FAMILLE Cost: 2 Bytes: 690 Cardinality: 30
14 HASH JOIN Cost: 174,464 Bytes: 3,374,826 Cardinality: 22,958
2 TABLE ACCESS FULL EXPL.BO_SOUS_FAMILLE Cost: 2 Bytes: 9,594 Cardinality: 369
13 NESTED LOOPS Cost: 174,459 Bytes: 2,777,918 Cardinality: 22,958
11 HASH JOIN Cost: 174,459 Bytes: 2,640,170 Cardinality: 22,958
9 HASH JOIN Cost: 173,128 Bytes: 1,469,312 Cardinality: 22,958
7 HASH JOIN Cost: 7 Bytes: 380 Cardinality: 10
5 INLIST ITERATOR
4 TABLE ACCESS BY INDEX ROWID EXPL.BO_SUCCURSALE Cost: 2 Bytes: 96 Cardinality: 4
3 INDEX RANGE SCAN UNIQUE EXPL.PK_BO_SUCCURSALE Cost: 1 Cardinality: 4
6 TABLE ACCESS FULL EXPL.BO_PVT Cost: 4 Bytes: 1,064 Cardinality: 76
8 TABLE ACCESS FULL EXPL.STATARTICLE Cost: 173,099 Bytes: 35,813,830 Cardinality: 1,377,455
10 TABLE ACCESS FULL EXPL.BO_ARTICLE Cost: 347 Bytes: 18,255,297 Cardinality: 357,947
12 INDEX UNIQUE SCAN UNIQUE EXPL.PK_BO_SECTION Bytes: 6 Cardinality: 1

sur la table EXPL.STATARTICLE Cost: 173,099 Bytes: 35,813,830 Cardinality: 1,377,455 c 'est quoi cette cardinalite de ouf

en text c 'est pas tres parlant
je peux t envoyer le plan d execution sous forme grphique avec la requete et les graphiques de mes statpacks sur la journee si tu veux

[farenheiit]

Pour afficher ton plan d'execution
met toi sous sqlplus

Code :

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

1
2
3
4
5
6
7
 
set lines 200
set pages 100
explain plan for
Ta_requete
;
select * from table(dbms_xplan.display());