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]

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]

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]

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