Hallo:
wir haben eine ORACLE-DB in der Version 10.2.0.1 unter Solaris 5.8
laufen. Die Datenbank wird für ein Projekt mit SIEBEL(7.8) benutzt.
Da wir Laufzeit-Probleme haben, bin ich am Auswerten des Statpacks
(generiert über awrrpt.sql). Allerdings ist mir nicht ganz klar, was einige Werte zu bedeuten haben.
Hier ein Auszug aus dem Statpack:
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 99.93 In-memory Sort %: 100.00
Library Hit %: 96.65 Soft Parse %: 95.03
Execute to Parse %: 37.52 Latch Hit %: 99.39
Parse CPU to Parse Elapsd %: 10.66 % Non-Parse CPU: 97.96
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
-------------------- ------------ ----------- ------ ------ ----------
CPU time 685 73.2
library cache pin 125 244 1955 26.1 Concurrenc
control file parallel write 1,200 8 6 0.8 System I/O
log file sync 1,343 7 5 0.7 Commit
log file parallel write 1,765 5 3 0.6 System I/O
-------------------------------------------------------------
Wait Class
Avg
%Time Total Wait wait Waits
Wait Class Waits -outs Time (s) (ms) /txn
----------------------------- ------ ---------------- ------- ---------
Concurrency 160 45.6 245 1534 0.0
System I/O 5,802 .0 16 3 1.3
Commit 1,343 .0 7 5 0.3
User I/O 229 .0 2 8 0.1
Network 31,676 .0 1 0 7.0
Other 24 16.7 0 18 0.0
Application 6 .0 0 3 0.0
Configuration 1 .0 0 0 0.0
-------------------------------------------------------------
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
---------------------- -------------- ------ ----------- --------------
library cache pin 125 58.4 244 1955 0.0
control file parallel write 1,200 .0 8 6 0.3
log file sync 1,343 .0 7 5 0.3
log file parallel write 1,765 .0 5 3 0.4
db file parallel write 953 .0 3 3 0.2
db file sequential read 218 .0 2 8 0.0
os thread startup 4 .0 1 248 0.0
SQL\*Net more data to client 4,133 .0 1 0 0.9
control file sequential read 1,884 .0 0 0 0.4
SQL\*Net more data from clien 1,507 .0 0 0 0.3
kksfbc child completion 4 100.0 0 55 0.0
latch free 1 .0 0 210 0.0
SQL\*Net message to client 26,036 .0 0 0 5.8
db file scattered read 1 .0 0 34 0.0
SQL\*Net break/reset to clien 6 .0 0 3 0.0
library cache load lock 2 .0 0 8 0.0
row cache lock 15 .0 0 1 0.0
latch: shared pool 2 .0 0 5 0.0
read by other session 1 .0 0 6 0.0
buffer busy waits 10 .0 0 0 0.0
LGWR wait for redo copy 19 .0 0 0 0.0
enq: SQ - contention 1 .0 0 0 0.0
latch: In memory undo latch 1 .0 0 0 0.0
direct path write 9 .0 0 0 0.0
cursor: mutex X 1 .0 0 0 0.0
SQL\*Net message from client 26,036 .0 102,624 3942 5.8
virtual circuit status 121 100.0 3,540 29260 0.0
Streams AQ: qmn slave idle w 129 .0 3,540 27443 0.0
Streams AQ: qmn coordinator 264 51.1 3,540 13410 0.1
Streams AQ: waiting for mess 721 100.0 3,520 4882 0.2
Streams AQ: waiting for time 3 100.0 307 102326 0.0
jobq slave wait 40 100.0 118 2939 0.0
class slave wait 2 100.0 10 4889 0.0
SGA: MMAN sleep for componen 41 .0 0 2 0.0
-------------------------------------------------------------
=> was können die vielen Waits bei wait-class „Network“ bedeuten?
Wenn ich v$session_wait abfrage, bekomme ich diese Waits angezeigt :
SQL\> select sid,event,wait\_class, seconds\_in\_wait from v$session\_wait
2 where sid in (select sid
3 from v$session s, v$sqlarea sa
4 where
5 username='LDAPUSER'
6 and s.sql\_id =sa.sql\_id (+)
7 );
SID EVENT WAIT\_CLASS SECONDS\_IN\_WAIT
---------- ---------------------------- ---------------------------
1538 SQL\*Net message from client Idle 0
1540 SQL\*Net message from client Idle 31
1546 SQL\*Net message from client Idle 0
1556 SQL\*Net message from client Idle 41
1559 SQL\*Net message from client Idle 0
1573 SQL\*Net message from client Idle 17
1599 SQL\*Net message from client Idle 51
1608 SQL\*Net message from client Idle 5635
1615 SQL\*Net more data from client Network 8
1642 SQL\*Net message from client Idle 217
=> Was bedeutet die lange Wartezeit bei „library cache pin“?
SGA_TARGET ist auf 1,5 GB gesetzt, was laut Advisor etwas zu niedrig dimensioniert ist .
SGA Target Advisory
SGA Target SGA Size Est DB Est Physical
Size (M) Factor Time (s) Reads
---------- ---------- ------------ ----------------
1,128 0.8 55,058 1,195,419
1,504 1.0 53,883 985,425
1,880 1.3 51,900 645,749
2,256 1.5 51,194 563,367
2,632 1.8 51,194 555,484
=> Ist die zu kleine SGA das einzige Problem?
Der ADDM weist folgende Probleme mit dem grössten „Impact“ auf:
-)Hard parsing of SQL statements was consuming significant database time.
-)SQL statements were not shared due to the usage of literals. This resulted in additional hard parses which were consuming significant database time.
-)SQL statements consuming significant database time were found.
Sagt mir das, dass keine Bind-Variablen enutzt werden?
Nur ist SIEBEL eine Standard-Software und man wird kaum was an der Software ändern können. cursor_sharing=force habe ich noch nicht ausprobiert, wollte ich aber auch nicht als Lösung suchen, da immer gesagt wird, dass die eine vorrübergehende Lösung sein kann, bis die Applikation abgeändert wurde.
Hat jemand eine Ahnung, wo genau das Problem liegt?
Was könnte ich noch überprüfen?
Vielen Dank
Regine
analysiert?