Wait Class
Hi,
As per documents In general, the addition of wait classes helps direct the DBA more quickly toward the root cause of performance problems.
How could i trace the root cause of performence problems if it is related to wait class?
Thanks,
userpat wrote:
Hi,
As per documents In general, the addition of wait classes helps direct the DBA more quickly toward the root cause of performance problems.
How could i trace the root cause of performence problems if it is related to wait class?
Thanks,I am not completely sure that I understand your question. The wait class gives you an approximate idea of where the performance problem will be found. You must then further investigate the wait events in that wait class. There are of course potential problems with starting at the wait class (some wait classes have 2 wait events, while others have many - that could throw off the search for the problem that is impacting performance the most), but at least it provides a starting point. To give you an idea of the wait events in each wait class, here is a SQL statement that was executed on Oracle Database 11.1.0.7:
SQL> DESC V$EVENT_NAME
Name Null? Type
EVENT# NUMBER
EVENT_ID NUMBER
NAME VARCHAR2(64)
PARAMETER1 VARCHAR2(64)
PARAMETER2 VARCHAR2(64)
PARAMETER3 VARCHAR2(64)
WAIT_CLASS_ID NUMBER
WAIT_CLASS# NUMBER
WAIT_CLASS VARCHAR2(64)
SELECT
SUBSTR(NAME,1,30) EVEMT_NAME,
SUBSTR(WAIT_CLASS,1,20) WAIT_CLASS
FROM
V$EVENT_NAME
ORDER BY
SUBSTR(WAIT_CLASS,1,20),
SUBSTR(NAME,1,30);
EVEMT_NAME WAIT_CLASS
ASM COD rollback operation com Administrative
ASM mount : wait for heartbeat Administrative
Backup: sbtbackup Administrative
Backup: sbtbufinfo Administrative
Backup: sbtclose Administrative
Backup: sbtclose2 Administrative
OLAP DML Sleep Application
SQL*Net break/reset to client Application
SQL*Net break/reset to dblink Application
Streams capture: filter callba Application
Streams: apply reader waiting Application
WCR: replay lock order Application
Wait for Table Lock Application
enq: KO - fast object checkpoi Application
enq: PW - flush prewarm buffer Application
enq: RC - Result Cache: Conten Application
enq: RO - contention Application
enq: RO - fast object reuse Application
enq: TM - contention Application
enq: TX - row lock contention Application
enq: UL - contention Application
ASM PST query : wait for [PM][ Cluster
gc assume Cluster
gc block recovery request Cluster
enq: BB - 2PC across RAC insta Commit
log file sync Commit
Shared IO Pool Memory Concurrency
Streams apply: waiting for dep Concurrency
buffer busy waits Concurrency
cursor: mutex S Concurrency
cursor: mutex X Concurrency
cursor: pin S wait on X Concurrency
Global transaction acquire ins Configuration
Streams apply: waiting to comm Configuration
checkpoint completed Configuration
enq: HW - contention Configuration
enq: SQ - contention Configuration
enq: SS - contention Configuration
enq: ST - contention Configuration
enq: TX - allocate ITL entry Configuration
free buffer waits Configuration
ASM background timer Idle
DIAG idle wait Idle
EMON slave idle wait Idle
HS message to agent Idle
IORM Scheduler Slave Idle Wait Idle
JOX Jit Process Sleep Idle
ARCH wait for flow-control Network
ARCH wait for net re-connect Network
ARCH wait for netserver detach Network
ARCH wait for netserver init 1 Network
ARCH wait for netserver init 2 Network
ARCH wait for netserver start Network
ARCH wait on ATTACH Network
ARCH wait on DETACH Network
ARCH wait on SENDREQ Network
LGWR wait on ATTACH Network
LGWR wait on DETACH Network
LGWR wait on LNS Network
LGWR wait on SENDREQ Network
LNS wait on ATTACH Network
LNS wait on DETACH Network
LNS wait on LGWR Network
LNS wait on SENDREQ Network
SQL*Net message from dblink Network
SQL*Net message to client Network
SQL*Net message to dblink Network
SQL*Net more data from client Network
SQL*Net more data from dblink Network
AQ propagation connection Other
ARCH wait for archivelog lock Other
ARCH wait for process death 1 Other
ARCH wait for process death 2 Other
ARCH wait for process death 3 Other
ARCH wait for process death 4 Other
ARCH wait for process death 5 Other
ARCH wait for process start 1 Other
Streams AQ: enqueue blocked du Queueing
Streams AQ: enqueue blocked on Queueing
Streams capture: waiting for s Queueing
Streams: flow control Queueing
Streams: resolve low memory co Queueing
resmgr:I/O prioritization Scheduler
resmgr:become active Scheduler
resmgr:cpu quantum Scheduler
ARCH random i/o System I/O
ARCH sequential i/o System I/O
Archiver slave I/O System I/O
DBWR slave I/O System I/O
LGWR random i/o System I/O
BFILE read User I/O
DG Broker configuration file I User I/O
Data file init write User I/O
Datapump dump file I/O User I/O
Log file init write User I/O
Shared IO Pool IO Completion User I/O
buffer read retry User I/O
cell multiblock physical read User I/O
cell single block physical rea User I/O
cell smart file creation User I/O
cell smart index scan User I/O
cell smart table scan User I/O
cell statistics gather User I/O
db file parallel read User I/O
db file scattered read User I/O
db file sequential read User I/O
db file single write User I/O
...So, if the User I/O wait class floats to the top of the wait classes between a known start time and end time, and the Commit wait class is at the bottom of the wait classes when comparing accumulated time, it probably would not make much sense to spend time investigating the wait events in the Commit class... until you realize that there is a single event in the Commit wait class that typically contributes wait time, while there are many in the User I/O wait class.
Charles Hooper
Co-author of "Expert Oracle Practices: Oracle Database Administration from the Oak Table"
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.
Similar Messages
-
Wait event "virtual circuit wait" in wait class "Network" was consuming sig
Hello,
We are facing this problem when there are 2 queries try to run at the same time.
The first query takes longer to finish so 2nd has to wait for 1st to be finished and then only 2nd starts. It seems the jam is at netowork instead of server.
I want to make sure before I start testing on network.
I get following :
Wait event "virtual circuit wait" in wait class "Network" was consuming significant database time. 98.4
Wait class "Network" was consuming significant database time.
and recommendations is stated as :
Investigate the cause for high "virtual circuit wait" waits with P1 ("circuit#") value "21" and P2 ("type") value "2".
I am checking OEM.
Thanks,
Shashi.Hello Sybrand,
Can you suggest some changes to be done to test ?
Here is my shared server config :
SQL> show parameter SHARED
NAME TYPE VALUE
hi_shared_memory_address integer 0
max_shared_servers integer
shared_memory_address integer 0
shared_pool_reserved_size big integer 135895449
shared_pool_size big integer 0
shared_server_sessions integer
shared_servers integer 1
Thanks,
Shashi. -
User I/O Wait class in Top 5 Timed Foreground Events
Hi Mates
In my awr report in Top 5 Timed Foreground Events, i get the below event list
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
DB CPU 25,721 58.29
db file sequential read 67,491,952 7,710 0 17.47 User I/O
db file scattered read 7,147,112 2,560 0 5.8 User I/O
log file sync 2,926,748 1,526 1 3.46 Commit
direct path read 342,745 834 2 1.89 User I/O
So does it means that there is a issue with disk I/O on my box. since the wait class is showing as User I/O.
I am running the single instance database with oracle version 11.2 on IBM AIX server.huzaifa wrote:
Hi Mates
In my awr report in Top 5 Timed Foreground Events, i get the below event list
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
DB CPU 25,721 58.29
db file sequential read 67,491,952 7,710 0 17.47 User I/O
db file scattered read 7,147,112 2,560 0 5.8 User I/O
log file sync 2,926,748 1,526 1 3.46 Commit
direct path read 342,745 834 2 1.89 User I/OSo does it means that there is a issue with disk I/O on my box. since the wait class is showing as User I/O.
I am running the single instance database with oracle version 11.2 on IBM AIX server.Is this a standard one hour report on a machine with at least 8 CPUs available ?
If so then take a look at Dom Brooks comment - your average read times are in the range of 0.1 to 0.3 milliseconds - they're mostly coming out of filesystem cache (but maybe you have some very good database flashcache installed).
Your first move should probably be to take some of the memory from your file system cache and increase your buffer cache - this will probably decrease the number of reads reported and the amount of CPU used. I'd also look for statements that seem to be doing an unreasonable amount of I/O to get their end results, and check the "Segments by ... " section of the report to see which objects are seeing most I/O.
Before you mess about with ASM, you should simply check for easy ways to do less work.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author: <b><em>Oracle Core</em></b> -
Wait class 'commit' consuming significant database time.
Hi
My awr report was showing that the log file sync as the top wait event.I can also see additional message saying that wait class 'commit' consuming significant database time.Can any one suggest me what are the tuning things i need to consider for this wait class 'LOG FILE SYNC'
ThanksBe very careful about this.
Follow this only if you can afford to lose some data in case of instance failure
(eg death of the instance from a bug, server panic/reboot, power failure etc).
Oracle's normal behaviour is to guarantee that every committed transaction
IS available by ensuring that it is in the redologs and reapplying it if necessary
in case of an instance failure and recovery or media recovery.
A Commit NOWAIT means that there is a possibility, however slight, that
the last few transaction(s) might not have gotten into the redo logs at the time
of instance failure.
Your application / analysts must be able to identify transactions that are 'lost'
and reapply them after you restart a crashed instance. -
Don't understand why OEM is reporting that Database Time Spent Waiting (%): Wait Class Other is nearly 100% all the time. Database 10.1.0.4 just installed on Linux(RHEL4AS) and nobody use it for now except OEM and me for admin purpose.
Any clue for that problem ?
Regards
NicolasSeems like you are not the first to see this kind of behaviour.
I've found another similar thread on metalink. I can't say the answer is terribly helpful, but thought you might be interested anyway:
From: Jose Ramón Tourón 14-Sep-07 08:34
Subject: Database Time Spent Waiting (%) at 100 in event class Commit
RDBMS Version: Oracle 10g r2
Operating System and Version: Suse Enterprise Linux 10
Error Number (if applicable):
Product (i.e. SQL*Loader, Import, etc.): database core
Product Version: 10gR2
Database Time Spent Waiting (%) at 100 in event class Commit
Hi everyone, yesterday we create a new database instance with dbca, the creation process was ok, and the two instances are running ok, database stops and starts without any problem, and listeners are ok. In the enterprise manager of this new instance we found this message:
Database Time Spent Waiting (%) at 100 in event class Commit, this event happend every 1 or 2 minutes sometimes at 100, the next 40%, the next 98, ... and so on.
Do you know what's happend in this instance?
Thanks in advance to everyone
Santiago Pérez
From: Oracle, Helmut Pfau 14-Sep-07 12:52
Subject: Re : Database Time Spent Waiting (%) at 100 in event class Commit
From Oracle Database Reference Manual:
Commit
This wait class only comprises one wait event - wait for redo log write confirmation after a commit (that is, 'log file sync')
So you can't write fast enough into your log files.
Did you check the frequency of log switches?
From: Metalink TCS User Group TCS Uruguay 14-Sep-07 15:52
Subject: Re : Database Time Spent Waiting (%) at 100 in event class Commit
Hi José! Please don't get anxious because of this: Wait time must be SOMEWHERE, there's a saying "An OLTP DB is only as fast as its redo logs", but if you are not having any performance problem you don't need to do anything special.
You say you've just created the DB. Now make it DO something: put it to the test by simulating production conditions as closely as you can, and after some hours ask the users whether there is some problem. If there is, take a look at the wait statistics... you'll probably see many other top events before this one!
Bruno abate_at_adinet.com.uy -
can anyone tell me what are the wait events in wait class 'OTHER';
Dear dbaforu,
Short but indeed useful information here;
http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/instance_tune.htm#PFGRF94504
+"+
+10.3.7 events in wait class other+
+This event belong to Other wait class and typically should not occur on a system. This event is an aggregate of all other events in the Other wait class, such as latch free, and is used in the V$SESSION_EVENT and V$SERVICE_EVENT views only. In these views, the events in the Other wait class will not be maintained individually in every session. Instead, these events will be rolled up into this single event to reduce the memory used for maintaining statistics on events in the Other wait class.+
+"+
Regards.
Ogan -
what is Wait class Application?
give guide meHi,
Application is one of a classification of Wait class events along with network,commit,idle,user i/o.
Application: locks waits caused by row level locking or explicit lock commands
Have a look into this link.
http://youngcow.net/doc/oracle10g/server.102/b14211/autostat.htm
Regards
Jafar -
Hi guys
I'm getting this warning every 20 minutes from Enterprise Manager 10g: Metrics "Database Time Spent Waiting (%)" is at 67.62891 for event class "Commit". My database is an Oracle 10g 10.2.0.4 (Linux x84_64) with dataguard, one physical and one standby networked at 100Mbit. I have 3 groups of 50M redo log with a low volume of transaction for now. Here are some metrics numbers:
SQL> select sum(seconds_in_wait),event from v$session_wait group by event;
SUM(SECONDS_IN_WAIT) EVENT
121210 SQL*Net message from client
0 Streams AQ: waiting for messages in the queue
18 wait for unread message on broadcast channel
6 LNS ASYNC end of log
30 jobq slave wait
37571 rdbms ipc message
384 smon timer
35090 pmon timer
I tune the my listerners for Dataguard using the documentation. I don't know what to tune anymore, is someone has a clue.
Thanks,
Chriscprieur wrote:
Metrics "Database Time Spent Waiting (%)" is at 67.62891 for event class "Commit"
I'am also getting this message at a regular time:
Metrics "Database Time Spent Waiting (%)" is at 64.09801 for event class "Network"
The report, I was sent only to indicate the time spent on: SQL*Net message from client
I believe that these metrics are explained here (near the bottom of the page):
http://download.oracle.com/docs/cd/B19306_01/em.102/b25986/oracle_database.htm
There are only two wait events in the Commit class (on 11.1.0.7):
log file sync
enq: BB - 2PC across RAC instances
log file sync waits happen when sessions issue a COMMIT or ROLLBACK. Sessions will wait on this event until LGWR completes its writes to the redo logs (LGWR will likely wait on the event log file parallel wriite while waiting for the write to complete). I believe that your DataGuard configuration may contribute to the long waits experienced by LGWR, and it may be made worse by the network connection.
http://download.oracle.com/docs/cd/B28359_01/server.111/b28294.pdf
"Maximum availability - This protection mode provides the highest level of data protection that is possible without compromising the availability of a primary database. Transactions do not commit until all redo data needed to recover those transactions has been written to the online redo log and to at least one standby database."
So, if Maximum availability is configured, the sessions will have to wait for the redo to be applied to the remote database.
At the system-wide level you will almost always be able to ignore the SQL*Net message from client wait events. At the session level this wait event has a more significant meaning - the client computer is not actively waiting on a response from the database instance - the client is either sitting idle, or performing client-side processing.
Sybrand, if he joins this thread, will likely be able to provide a more complete answer regarding DataGuard's contribution to the Commit wait class.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
Hi,
Can any one help me on this warning, i got this warning on ORACLE ENTERPRISE MANAGER
Waits by Wait Class
Database Time Spent Waiting (%)
Metrics "Database Time Spent Waiting (%)" is at 69.64818 for event class "Commit"
Below are our environment details:
RDBMS: 10.2.0.4
Oracle E-Business suite: 12.0.6
OS: Oracle Sun 10
Please suggest.
Thank you.Please see the following docs.
How to Disable Alerts for The Database Time Spent Waiting (%) Metric? (Doc ID 1500074.1)
"Database Time Spent Waiting (%)" at 100 for Event Class "Other" when Database is not Under Load (Doc ID 1526552.1)
Thanks,
Hussein -
High library cache load lock waits in AWR
Hi All,
Today i faced a significant performance problem related to shared pool. I made some observations, thought it would be a nice idea to share them with Oracle experts. Please feel free to add your observations/recommendations and correct me where i am wrong.
Here are the excerpts from AWR report created for the problem timing. Database server is on 10.2.0.3 and running with 2*16 configuration. DB cache size is 4,000M and shared pool size is of 3008M.
Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 9994 29-Jun-09 10:00:07 672 66.3
End Snap: 10001 29-Jun-09 17:00:49 651 64.4
Elapsed: 420.70 (mins)
DB Time: 4,045.34 (mins) -- Very poor response time visible from difference between DB time and elapsed time.
Load Profile
Per Second Per Transaction
Redo size: 248,954.70 23,511.82
Logical reads: 116,107.04 10,965.40
Block changes: 1,357.13 128.17
Physical reads: 125.49 11.85
Physical writes: 51.49 4.86
User calls: 224.69 21.22
Parses: 235.22 22.21
Hard parses: 4.83 0.46
Sorts: 102.94 9.72
Logons: 1.12 0.11
Executes: 821.11 77.55
Transactions: 10.59 -- User calls and Parse count are almost same, means most of the calls are for parse. Most of the parses are soft. Per transaction 22 parses are very high figure.
-- Not much disk I/O activity. Most of the reads are being satisfy from memory.
Instance Efficiency
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 99.92 In-memory Sort %: 100.00
Library Hit %: 98.92 Soft Parse %: 97.95
Execute to Parse %: 71.35 Latch Hit %: 99.98
Parse CPU to Parse Elapsd %: 16.82 % Non-Parse CPU: 91.41 -- Low execute to parse ratio denotes CPU is significantly busy in parsing. Soft Parse% showing, most of the parse are soft parses. It means we should concentrate on soft parsing activity.
-- Parse CPU to Parse Elapsed % is quite low, means some bottleneck is there related to parsing. It could be a side-effect of huge parsing pressure. Like CPU cycles are not available.
Shared Pool Statistics
Begin End
Memory Usage %: 81.01 81.92
% SQL with executions>1: 88.51 86.93
% Memory for SQL w/exec>1: 86.16 86.76 -- Shared Pool memory seems ok (in 80% range)
-- 88% of the SQLs are repeating ones. It's a good sign.
Top 5 Timed Events
Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
library cache load lock 24,243 64,286 2,652 26.5 Concurrency
db file sequential read 1,580,769 42,267 27 17.4 User I/O
CPU time 33,039 13.6
latch: library cache 53,013 29,194 551 12.0 Concurrency
db file scattered read 151,669 13,550 89 5.6 User I/O Problem-1: Contention on Library cache: May be due to under-sized shared pool, incorrect parameters, poor application design, But since we already observed that most of the parses are soft parses and shared pool usgae in 80%, seems problem related to holding cursors. open_cursors/session_cached_cursors are red flags.
Problem-2: User I/O, may be due to poor SQLs, I/O sub-system, or poor physical design (wrong indexes are being used as DB file seq reads)
Wait Class
Wait Class Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn
Concurrency 170,577 44.58 109,020 639 0.64
User I/O 2,001,978 0.00 59,662 30 7.49
System I/O 564,771 0.00 8,069 14 2.11
Application 145,106 1.25 6,352 44 0.54
Commit 176,671 0.37 4,528 26 0.66
Other 27,557 6.31 2,532 92 0.10
Network 6,862,704 0.00 696 0 25.68
Configuration 3,858 3.71 141 37 0.01
Wait Events
Event Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn
library cache load lock 24,243 83.95 64,286 2652 0.09
db file sequential read 1,580,769 0.00 42,267 27 5.91
latch: library cache 53,013 0.00 29,194 551 0.20
db file scattered read 151,669 0.00 13,550 89 0.57
latch: shared pool 25,403 0.00 12,969 511 0.10
log file sync 176,671 0.37 4,528 26 0.66
enq: TM - contention 1,455 90.93 3,975 2732 0.01 Instance Activity Stats
opened cursors cumulative 5,290,760 209.60 19.80
parse count (failures) 6,181 0.24 0.02
parse count (hard) 121,841 4.83 0.46
parse count (total) 5,937,336 235.22 22.21
parse time cpu 283,787 11.24 1.06
parse time elapsed 1,687,096 66.84 6.31 Latch Activity
library cache 85,042,375 0.15 0.43 29194 304,831 7.16
library cache load lock 257,089 0.00 1.20 0 69,065 0.00
library cache lock 41,467,300 0.02 0.07 6 2,714 0.07
library cache lock allocation 730,422 0.00 0.44 0 0
library cache pin 28,453,986 0.01 0.16 8 167 0.00
library cache pin allocation 509,000 0.00 0.38 0 0 Init.ora parameters
cursor_sharing= EXACT
open_cursors= 3000
session_cached_cursors= 0
-- open_cursors value is too high. I have checked that maximum usage by a single session is 12%.
-- session_cached_cursors are 0 causing soft parsing. 500/600 is good number to start with.
cursor_sharing exact may cause hard parses. But here, hard parsing is comparatively small, we can ignore this.
From v$librarycache
NAMESPACE GETS GETHITS GETHITRATIO PINS PINHITRATIO RELOADS INVALIDATIONS
SQL AREA 162827 25127 .154317159 748901435 .999153087 107941 81886-- high invalidation count due to DDL like activities.
-- high reloads due to small library cache.
-- hit ratio too small.
-- Need to pin frequently executed objects into library cache.
P.S. Same question asked on Oracle_L, but due to formatting reasons, pasing duplicate contents here.
Regards,
Neeraj Bhatia
Edited by: Neeraj.Bhatia2 on Jul 13, 2009 6:51 AMThanks Charles. I really appreciate your efforts to diagnose the issue.
I agree with you performance issue is caused by soft parsing, which can be solved by holding cursors (session_cached_cursors). It may be due to oversized shared pool, which is causing delay in searching child cursors.
My second thought is, there is large number of reloads, which can be due to under-sized shared pool, if invalidation activities are not going (CBO statistics collection, DDL etc), cursors are being flushed frequently.
CPU utilization is continuously high (above 90%). Pasting additional information from same AWR report.
Namespace Get Requests Pct Miss Pin Requests Pct Miss Reloads Invalidations
BODY 225,345 0.76 4,965,541 0.15 5,533 0
CLUSTER 1,278 1.41 2,542 1.73 26 0
INDEX 5,982 9.31 13,922 7.35 258 0
SQL AREA 141,465 54.10 27,831,235 1.21 69,863 19,085 Latch Miss Sources
Latch Name Where NoWait Misses Sleeps Waiter Sleeps
library cache lock kgllkdl: child: no lock handle 0 8,250 5,792 Time Model Statistics
Statistic Name Time (s) % of DB Time
sql execute elapsed time 206,979.31 85.27
PL/SQL execution elapsed time 94,651.78 39.00
DB CPU 33,039.29 13.61
parse time elapsed 22,635.47 9.33
inbound PL/SQL rpc elapsed time 14,763.48 6.08
hard parse elapsed time 14,136.77 5.82
connection management call elapsed time 1,625.07 0.67
PL/SQL compilation elapsed time 760.76 0.31
repeated bind elapsed time 664.81 0.27
hard parse (sharing criteria) elapsed time 500.11 0.21
Java execution elapsed time 252.95 0.10
failed parse elapsed time 167.23 0.07
hard parse (bind mismatch) elapsed time 124.11 0.05
sequence load elapsed time 23.34 0.01
DB time 242,720.12
background elapsed time 11,645.52
background cpu time 247.25 According to this DB CPU is 65% utilization (DB CPU + Background CPU / Total Available CPU seconds). While at the same time DB host was 95% utilized (confirmed from DBA_HIST_SYSMETRIC_SUMMARY).
Operating System Statistics
Statistic Total
BUSY_TIME 3,586,030
IDLE_TIME 1,545,064
IOWAIT_TIME 22,237
NICE_TIME 0
SYS_TIME 197,661
USER_TIME 3,319,452
LOAD 11
RSRC_MGR_CPU_WAIT_TIME 0
PHYSICAL_MEMORY_BYTES 867,180
NUM_CPUS 2 -
Hi
I am getting huge buffer busy waits events on my database and its increasing
following is the result of query on my database(9.2.0.8.0)
SQL> select event,total_waits from v$system_event where event in ('free buffer waits','buffer busy waits')
2 ;
EVENT TOTAL_WAITS
free buffer waits 118
buffer busy waits 12827
Also my "segment space management" is on "auto" on the tablespaces
please someone let me know even when "segment space management" is on "auto" , why buffer busy waits is so huge
And how to reduce this event
RegardsHi,
Try to post the out put for system wide if possible
SELECT time, count, class
FROM V$WAITSTAT
ORDER BY time,count
First of all check how many session till now impacted with this event. execute the below query and check
SELECT count(*), event
FROM v$session_wait
WHERE wait_time = 0
AND event NOT IN ('smon timer','pmon timer','rdbms ipc message',
'SQL*Net message from client')
GROUP BY event
ORDER BY 1 DESC;
try to check p1, p2 and p3 value of below query, from there we can find the cause
SELECT count(*) n_w , p1 FILE#, p2 BLK#, p3 CLASS
FROM v$session_wait
WHERE event = 'buffer busy waits'
GROUP BY p1, p2, p3
from the above query you will get the AFN and Block and wait class, use those inputs and check the actual segment cause, then we can seee what we need to do
SELECT owner,segment_name,segment_type
FROM dba_extents
WHERE file_id=&file
AND &blockid BETWEEN block_id AND block_id + blocks
- Pavan Kumar N
- Pavan Kumar N
Updated with queries -
Buffer busy waits after cnanging lob storage to oracle securefiles
Hi Everyone
I need help resolving a problem with buffer busy waits in for a lob segment using securefiles for storage.
During the load the application inserts a record into a table with the lob segment and update the record after, populating lob data. The block size on the table space holding the lob is 8 kb and the chunk size on the lob segment is set to 8kb. The average size of the lob record is 6 kb and the minimum size is 4.03 KB. The problem occurs only when running a job with a big number of relatively small inserts (4.03 Kb) in to the lob column . The table definition allow in-row storage and the ptcfree set to 10%. The same jobs runs without problem when using basicfiles storage for the lob column.
According to [oracle white paper |http://www.oracle.com/technetwork/database/options/compression/overview/securefiles-131281.pdf] securefiles have a number of performance enhancements. I was particular interested to test Write Gather Cache as our application does a lot of relatively small inserts into a lob segment.
Below is a fragment from the AWR report. It looks like all buffer busy waits belong to a free list class. The lob segment is located in an ASSM tablespace and I cannot increase freelists.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning option
Host Name Platform CPUs Cores Sockets Memory(GB)
DB5 Microsoft Windows x86 64-bit 8 2 31.99
Snap Id Snap Time Sessions Curs/Sess
Begin Snap: 1259 01-Apr-11 14:40:45 135 5.5
End Snap: 1260 01-Apr-11 15:08:59 155 12.0
Elapsed: 28.25 (mins)
DB Time: 281.55 (mins)
Cache Sizes Begin End
~~~~~~~~~~~ ---------- ----------
Buffer Cache: 2,496M 2,832M Std Block Size: 8K
Shared Pool Size: 1,488M 1,488M Log Buffer: 11,888K
Load Profile Per Second Per Transaction Per Exec Per Call
~~~~~~~~~~~~ --------------- --------------- ---------- ----------
DB Time(s): 10.0 0.1 0.01 0.00
DB CPU(s): 2.8 0.0 0.00 0.00
Redo size: 1,429,862.3 9,390.5
Logical reads: 472,459.0 3,102.8
Block changes: 9,849.7 64.7
Physical reads: 61.1 0.4
Physical writes: 98.6 0.7
User calls: 2,718.8 17.9
Parses: 669.8 4.4
Hard parses: 2.2 0.0
W/A MB processed: 1.1 0.0
Logons: 0.1 0.0
Executes: 1,461.0 9.6
Rollbacks: 0.0 0.0
Transactions: 152.3
Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Avg
wait % DB
Event Waits Time(s) (ms) time Wait Class
buffer busy waits 1,002,549 8,951 9 53.0 Concurrenc
DB CPU 4,724 28.0
latch: cache buffers chains 11,927,297 1,396 0 8.3 Concurrenc
direct path read 121,767 863 7 5.1 User I/O
enq: DW - contention 209,278 627 3 3.7 Other
?Host CPU (CPUs: 8 Cores: 2 Sockets: )
~~~~~~~~ Load Average
Begin End %User %System %WIO %Idle
38.7 3.5 57.9
Instance CPU
~~~~~~~~~~~~
% of total CPU for Instance: 40.1
% of busy CPU for Instance: 95.2
%DB time waiting for CPU - Resource Mgr: 0.0
Memory Statistics
~~~~~~~~~~~~~~~~~ Begin End
Host Mem (MB): 32,762.6 32,762.6
SGA use (MB): 4,656.0 4,992.0
PGA use (MB): 318.4 413.5
% Host Mem used for SGA+PGA: 15.18 16.50
Avg
%Time Total Wait wait Waits % DB
Event Waits -outs Time (s) (ms) /txn time
buffer busy waits 1,002,549 0 8,951 9 3.9 53.0
latch: cache buffers chain 11,927,297 0 1,396 0 46.2 8.3
direct path read 121,767 0 863 7 0.5 5.1
enq: DW - contention 209,278 0 627 3 0.8 3.7
log file sync 288,785 0 118 0 1.1 .7
SQL*Net more data from cli 1,176,770 0 103 0 4.6 .6
Buffer Wait Statistics DB/Inst: ORA11G/ora11g Snaps: 1259-1260
-> ordered by wait time desc, waits desc
Class Waits Total Wait Time (s) Avg Time (ms)
free list 818,606 8,780 11
undo header 512,358 141 0
2nd level bmb 105,816 29 0
-> Total Logical Reads: 800,688,490
-> Captured Segments account for 19.8% of Total
Tablespace Subobject Obj. Logical
Owner Name Object Name Name Type Reads %Total
EAG50NSJ EAG50NSJ SYS_LOB0000082335C00 LOB 127,182,208 15.88
SYS SYSTEM TS$ TABLE 7,641,808 .95
Segments by Physical Reads DB/Inst: ORA11G/ora11g Snaps: 1259-1260
-> Total Physical Reads: 103,481
-> Captured Segments account for 224.4% of Total
Tablespace Subobject Obj. Physical
Owner Name Object Name Name Type Reads %Total
EAG50NSJ EAG50NSJ SYS_LOB0000082335C00 LOB 218,858 211.50
....Best regards
Yuri KogunHi Jonathan,
I was puzzled by the number of logical reads as well. This hasn't happened when the lob was stored as a basic fille and I assumed that the database is able to store the records in-row when we switched to securefiles. With regards to ASSM, according to the documentation this is the only option when using securefiles.
We did have high number of HW-enqueue waits in the database when running the test with basic files and had to set 44951 event
alter system set EVENTS '44951 TRACE NAME CONTEXT FOREVER, LEVEL 1024' There are 2 application servers running 16 jobs each, so we should not have more than 32 sessions inserting the data in the same time but I need to check wheter jobs can be brocken to smaller peaces. I that case the number of concurrent session may be bigger. Each session is configured with bundle size of 30 and it will issue commit every 30 inserts.
I am not sure how exactly the code does insert, as I've been told it should be straight insert and update I will be able to check this on Monday.
Below is the extract from the AWR reports with top SQL, I could not find any SQL related to the $TS table in the report. The query to the V$SEGMENT_STATISTICS was executed by me during the job run.
?SQL ordered by Elapsed Time DB/Inst: ORA11G/ora11g Snaps: 1259-1260
-> Resources reported for PL/SQL code includes the resources used by all SQL
statements called by the code.
-> % Total DB Time is the Elapsed Time of the SQL statement divided
into the Total Database Time multiplied by 100
-> %Total - Elapsed Time as a percentage of Total DB time
-> %CPU - CPU Time as a percentage of Elapsed Time
-> %IO - User I/O Time as a percentage of Elapsed Time
-> Captured SQL account for 91.3% of Total DB Time (s): 16,893
-> Captured PL/SQL account for 0.1% of Total DB Time (s): 16,893
Elapsed Elapsed Time
Time (s) Executions per Exec (s) %Total %CPU %IO SQL Id
7,837.5 119,351 0.07 46.4 28.3 .7 2zrh6mw372asz
Module: JDBC Thin Client
update JS_CHANNELDESTS set CHANNELID=:1, DESTID=:2, CHANNELDESTSTATUSDATE=:3, ST
ATUS=:4, BINOFFSET=:5, BINNAME=:6, PAGECOUNT=:7, DATA=:8, SORTORDER=:9, PRINTFOR
MAT=:10, ENVELOPEID=:11, DOCID=:12, CEENVELOPEID=:13, CHANNELTYPE=:14 where ID=:
15
7,119.0 115,997 0.06 42.1 23.1 .2 3vjx93vur4dw1
Module: JDBC Thin Client
insert into JS_CHANNELDESTS (CHANNELID, DESTID, CHANNELDESTSTATUSDATE, STATUS, B
INOFFSET, BINNAME, PAGECOUNT, DATA, SORTORDER, PRINTFORMAT, ENVELOPEID, DOCID, C
EENVELOPEID, CHANNELTYPE, ID) values (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :
11, :12, :13, :14, :15)
85.6 2 42.80 .5 98.3 .0 cc19qha9pxsa4
Module: SQL Developer
select object_name, statistic_name, value from V$SEGMENT_STATISTICS
where object_name = 'SYS_LOB0000082335C00011$$'
35.0 111,900 0.00 .2 74.3 7.6 c5q15mpnbc43w
Module: JDBC Thin Client
insert into JS_ENVELOPES (BATCHID, TRANSACTIONNO, SPOOLID, JOBSETUPID, JOBSETUPN
AME, SPOOLNAME, STEPNO, MASTERCHANNELJOBID, SORTKEY1, SORTKEY2, SORTKEY3, ID) va
lues (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12)
34.9 111,902 0.00 .2 63.0 2.6 a0hmmbjwgwh1k
Module: JDBC Thin Client
insert into JS_CHANNELJOBPROPERTIES (NAME, VALUE, CHANNELJOBID, ID) values (:1,
:2, :3, :4)
29.2 950 0.03 .2 95.9 .1 du0hgjbn9vw0v
Module: JDBC Thin Client
SELECT * FROM JS_BATCHOVERVIEW WHERE BATCHID = :1
?SQL ordered by Executions DB/Inst: ORA11G/ora11g Snaps: 1259-1260
-> %CPU - CPU Time as a percentage of Elapsed Time
-> %IO - User I/O Time as a percentage of Elapsed Time
-> Total Executions: 2,476,038
-> Captured SQL account for 96.0% of Total
Elapsed
Executions Rows Processed Rows per Exec Time (s) %CPU %IO SQL Id
223,581 223,540 1.0 22.4 63.7 .0 gz7n75pf57c
Module: JDBC Thin Client
SELECT SQ_CHANNELJOBPROPERTIES.NEXTVAL FROM DUAL
120,624 120,616 1.0 8.1 99.0 .0 6y3ayqzubcb
Module: JDBC Thin Client
select batch0_.BATCHID as BATCHID0_0_, batch0_.BATCHNAME as BATCHNAME0_0_, batch
0_.STARTDATE as STARTDATE0_0_, batch0_.PARFINDATE as PARFINDATE0_0_, batch0_.PRO
CCOMPDATE as PROCCOMP5_0_0_, batch0_.BATCHSTATUS as BATCHSTA6_0_0_, batch0_.DATA
FILE as DATAFILE0_0_, batch0_.BATCHCFG as BATCHCFG0_0_, batch0_.FINDATE as FINDA
119,351 227,878 1.9 7,837.5 28.3 .7 2zrh6mw372a
Module: JDBC Thin Client
update JS_CHANNELDESTS set CHANNELID=:1, DESTID=:2, CHANNELDESTSTATUSDATE=:3, ST
ATUS=:4, BINOFFSET=:5, BINNAME=:6, PAGECOUNT=:7, DATA=:8, SORTORDER=:9, PRINTFOR
MAT=:10, ENVELOPEID=:11, DOCID=:12, CEENVELOPEID=:13, CHANNELTYPE=:14 where ID=:
15
116,033 223,892 1.9 8.0 92.2 .0 406wh6gd9nk
Module: JDBC Thin Client
select m_jobprope0_.CHANNELJOBID as CHANNELJ4_1_, m_jobprope0_.ID as ID1_, m_job
prope0_.NAME as formula0_1_, m_jobprope0_.ID as ID4_0_, m_jobprope0_.NAME as NAM
E4_0_, m_jobprope0_.VALUE as VALUE4_0_, m_jobprope0_.CHANNELJOBID as CHANNELJ4_4
_0_ from JS_CHANNELJOBPROPERTIES m_jobprope0_ where m_jobprope0_.CHANNELJOBID=:1
115,997 115,996 1.0 7,119.0 23.1 .2 3vjx93vur4d
Module: JDBC Thin Client
insert into JS_CHANNELDESTS (CHANNELID, DESTID, CHANNELDESTSTATUSDATE, STATUS, B
INOFFSET, BINNAME, PAGECOUNT, DATA, SORTORDER, PRINTFORMAT, ENVELOPEID, DOCID, C
EENVELOPEID, CHANNELTYPE, ID) values (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :
11, :12, :13, :14, :15)
115,996 115,996 1.0 15.9 75.0 4.5 3h58syyk145
Module: JDBC Thin Client
insert into JS_DOCJOBS (CREATEDATE, EFFDATE, JURIST, LANG, IDIOM, DD, DDVID, USE
RKEY1, USERKEY2, USERKEY3, USERKEY4, USERKEY5, USERKEY6, USERKEY7, USERKEY8, USE
RKEY9, USERKEY10, USERKEY11, USERKEY12, USERKEY13, USERKEY14, USERKEY15, USERKEY
16, USERKEY17, USERKEY18, USERKEY19, USERKEY20, REVIEWCASEID, ID) values (:1, :2
115,440 115,422 1.0 11.5 63.3 .0 2vn581q83s6
Module: JDBC Thin Client
SELECT SQ_CHANNELDESTS.NEXTVAL FROM DUAL
...The tablespace holding the lob segment has system extent allocation and the number of blocks for the lob segments roughly the same as the number of blocks in allocated extents.
select segment_name, blocks, count (*)
from dba_extents where segment_name = 'SYS_LOB0000082335C00011$$'
group by segment_name, blocks
order by blocks
SEGMENT_NAME BLOCKS COUNT(*)
SYS_LOB0000082335C00011$$ 8 1
SYS_LOB0000082335C00011$$ 16 1
SYS_LOB0000082335C00011$$ 128 158
SYS_LOB0000082335C00011$$ 256 1
SYS_LOB0000082335C00011$$ 1024 120
SYS_LOB0000082335C00011$$ 2688 1
SYS_LOB0000082335C00011$$ 8192 117
SELECT
sum(ceil(dbms_lob.getlength(data)/8000))
from EAG50NSJ.JS_CHANNELDESTS
SUM(CEIL(DBMS_LOB.GETLENGTH(DATA)/8000))
993216
select sum (blocks) from dba_extents where segment_name = 'SYS_LOB0000082335C00011$$'
SUM(BLOCKS)
1104536 Below is the instance activity stats related to securefiles from the AWR report
Statistic Total per Second per Trans
securefile allocation bytes 3,719,995,392 2,195,042.4 14,415.7
securefile allocation chunks 380,299 224.4 1.5
securefile bytes non-transformed 2,270,735,265 1,339,883.4 8,799.6
securefile direct read bytes 1,274,585,088 752,089.2 4,939.3
securefile direct read ops 119,725 70.7 0.5
securefile direct write bytes 3,719,995,392 2,195,042.4 14,415.7
securefile direct write ops 380,269 224.4 1.5
securefile number of non-transfo 343,918 202.9 1.3Best regards
Yuri
Edited by: ykogun on 02-Apr-2011 13:33 -
my database suddently very slow in a few seconds.After a while, all become normal.
In awr report,I find no special sql.
I paste two trouble time awr report here.
If you have any more information for troubleshooting ,I will paste if you require.
Thanks.
AWR report1:
WORKLOAD REPOSITORY report for
DB Name DB Id Instance Inst Num Release RAC Host
DB 3594421410 db2 2 10.2.0.4.0 YES db2
Snap Id Snap Time Sessions Curs/Sess
Begin Snap: 2342 17-Mar-09 21:30:23 521 1.1
End Snap: 2344 17-Mar-09 22:30:25 498 1.0
Elapsed: 60.03 (mins)
DB Time: 750.95 (mins)
Cache Sizes
~~~~~~~~~~~ Begin End
Buffer Cache: 3,504M 3,504M Std Block Size: 8K
Shared Pool Size: 1,200M 1,200M Log Buffer: 14,340K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
Redo size: 18,182.64 2,754.51
Logical reads: 326.19 49.41
Block changes: 123.54 18.72
Physical reads: 21.33 3.23
Physical writes: 7.29 1.10
User calls: 178.46 27.03
Parses: 62.04 9.40
Hard parses: 0.09 0.01
Sorts: 2.00 0.30
Logons: 0.20 0.03
Executes: 63.12 9.56
Transactions: 6.60
% Blocks changed per Read: 37.87 Recursive Call %: 17.93
Rollback per transaction %: 14.26 Rows per Sort: 44.63
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.99 Redo NoWait %: 99.95
Buffer Hit %: 93.46 In-memory Sort %: 100.00
Library Hit %: 99.52 Soft Parse %: 99.86
Execute to Parse %: 1.70 Latch Hit %: 99.97
Parse CPU to Parse Elapsd %: 0.82 % Non-Parse CPU: 98.60
Shared Pool Statistics Begin End
Memory Usage %: 78.60 78.77
% SQL with executions>1: 99.38 99.27
% Memory for SQL w/exec>1: 99.00 98.78
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
latch: library cache 736 47,078 63965 104.5 Concurrenc
CPU time 236 0.5
rdbms ipc reply 360 219 608 0.5 Other
log file sync 20,469 137 7 0.3 Commit
gc cr block 2-way 35,641 102 3 0.2 Cluster
AWR report 2:
DB Name DB Id Instance Inst Num Release RAC Host
db 3594421410 db2 2 10.2.0.4.0 YES yt-db2
Snap Id Snap Time Sessions Curs/Sess
Begin Snap: 2364 18-Mar-09 08:30:29 497 1.1
End Snap: 2365 18-Mar-09 08:42:28 511 1.0
Elapsed: 11.99 (mins)
DB Time: 277.14 (mins)
Cache Sizes
~~~~~~~~~~~ Begin End
Buffer Cache: 3,504M 3,504M Std Block Size: 8K
Shared Pool Size: 1,200M 1,200M Log Buffer: 14,340K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
Redo size: 23,306.73 2,556.74
Logical reads: 337.31 37.00
Block changes: 159.74 17.52
Physical reads: 0.72 0.08
Physical writes: 9.74 1.07
User calls: 274.07 30.06
Parses: 95.29 10.45
Hard parses: 0.04 0.00
Sorts: 2.52 0.28
Logons: 0.19 0.02
Executes: 95.71 10.50
Transactions: 9.12
% Blocks changed per Read: 47.36 Recursive Call %: 9.14
Rollback per transaction %: 11.13 Rows per Sort: 32.48
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 98.81 Redo NoWait %: 100.00
Buffer Hit %: 99.79 In-memory Sort %: 100.00
Library Hit %: 99.86 Soft Parse %: 99.95
Execute to Parse %: 0.44 Latch Hit %: 99.94
Parse CPU to Parse Elapsd %: 40.91 % Non-Parse CPU: 81.90
Shared Pool Statistics Begin End
Memory Usage %: 79.91 80.01
% SQL with executions>1: 99.52 99.52
% Memory for SQL w/exec>1: 98.83 98.77
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
latch free 176 4,391 24950 26.4 Other
gc buffer busy 3,726 3,335 895 20.1 Cluster
gc cr multi block request 4,165 2,204 529 13.3 Cluster
gc current grant busy 3,938 1,798 457 10.8 Cluster
latch: cache buffers chains 124 1,548 12487 9.3 Concurrenc
^LRAC Statistics DB/Inst: db/db2 Snaps: 2364-2365
Begin End
Number of Instances: 2 2
Global Cache Load Profile
~~~~~~~~~~~~~~~~~~~~~~~~~ Per Second Per Transaction
Global Cache blocks received: 19.36 2.12
Global Cache blocks served: 19.39 2.13
GCS/GES messages received: 63.76 6.99
GCS/GES messages sent: 63.64 6.98
DBWR Fusion writes: 2.58 0.28
Estd Interconnect traffic (KB) 334.84
Edited by: gaoyafang on 2009-3-18 上午12:46my database suddently very slow in a few seconds.After a while, all become normal.
In awr report,I find no special sql.
I paste two trouble time awr report here.
If you have any more information for troubleshooting ,I will paste if you require.
Thanks.
AWR report1:
WORKLOAD REPOSITORY report for
DB Name DB Id Instance Inst Num Release RAC Host
DB 3594421410 db2 2 10.2.0.4.0 YES db2
Snap Id Snap Time Sessions Curs/Sess
Begin Snap: 2342 17-Mar-09 21:30:23 521 1.1
End Snap: 2344 17-Mar-09 22:30:25 498 1.0
Elapsed: 60.03 (mins)
DB Time: 750.95 (mins)
Cache Sizes
~~~~~~~~~~~ Begin End
Buffer Cache: 3,504M 3,504M Std Block Size: 8K
Shared Pool Size: 1,200M 1,200M Log Buffer: 14,340K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
Redo size: 18,182.64 2,754.51
Logical reads: 326.19 49.41
Block changes: 123.54 18.72
Physical reads: 21.33 3.23
Physical writes: 7.29 1.10
User calls: 178.46 27.03
Parses: 62.04 9.40
Hard parses: 0.09 0.01
Sorts: 2.00 0.30
Logons: 0.20 0.03
Executes: 63.12 9.56
Transactions: 6.60
% Blocks changed per Read: 37.87 Recursive Call %: 17.93
Rollback per transaction %: 14.26 Rows per Sort: 44.63
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.99 Redo NoWait %: 99.95
Buffer Hit %: 93.46 In-memory Sort %: 100.00
Library Hit %: 99.52 Soft Parse %: 99.86
Execute to Parse %: 1.70 Latch Hit %: 99.97
Parse CPU to Parse Elapsd %: 0.82 % Non-Parse CPU: 98.60
Shared Pool Statistics Begin End
Memory Usage %: 78.60 78.77
% SQL with executions>1: 99.38 99.27
% Memory for SQL w/exec>1: 99.00 98.78
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
latch: library cache 736 47,078 63965 104.5 Concurrenc
CPU time 236 0.5
rdbms ipc reply 360 219 608 0.5 Other
log file sync 20,469 137 7 0.3 Commit
gc cr block 2-way 35,641 102 3 0.2 Cluster
AWR report 2:
DB Name DB Id Instance Inst Num Release RAC Host
db 3594421410 db2 2 10.2.0.4.0 YES yt-db2
Snap Id Snap Time Sessions Curs/Sess
Begin Snap: 2364 18-Mar-09 08:30:29 497 1.1
End Snap: 2365 18-Mar-09 08:42:28 511 1.0
Elapsed: 11.99 (mins)
DB Time: 277.14 (mins)
Cache Sizes
~~~~~~~~~~~ Begin End
Buffer Cache: 3,504M 3,504M Std Block Size: 8K
Shared Pool Size: 1,200M 1,200M Log Buffer: 14,340K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
Redo size: 23,306.73 2,556.74
Logical reads: 337.31 37.00
Block changes: 159.74 17.52
Physical reads: 0.72 0.08
Physical writes: 9.74 1.07
User calls: 274.07 30.06
Parses: 95.29 10.45
Hard parses: 0.04 0.00
Sorts: 2.52 0.28
Logons: 0.19 0.02
Executes: 95.71 10.50
Transactions: 9.12
% Blocks changed per Read: 47.36 Recursive Call %: 9.14
Rollback per transaction %: 11.13 Rows per Sort: 32.48
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 98.81 Redo NoWait %: 100.00
Buffer Hit %: 99.79 In-memory Sort %: 100.00
Library Hit %: 99.86 Soft Parse %: 99.95
Execute to Parse %: 0.44 Latch Hit %: 99.94
Parse CPU to Parse Elapsd %: 40.91 % Non-Parse CPU: 81.90
Shared Pool Statistics Begin End
Memory Usage %: 79.91 80.01
% SQL with executions>1: 99.52 99.52
% Memory for SQL w/exec>1: 98.83 98.77
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
latch free 176 4,391 24950 26.4 Other
gc buffer busy 3,726 3,335 895 20.1 Cluster
gc cr multi block request 4,165 2,204 529 13.3 Cluster
gc current grant busy 3,938 1,798 457 10.8 Cluster
latch: cache buffers chains 124 1,548 12487 9.3 Concurrenc
^LRAC Statistics DB/Inst: db/db2 Snaps: 2364-2365
Begin End
Number of Instances: 2 2
Global Cache Load Profile
~~~~~~~~~~~~~~~~~~~~~~~~~ Per Second Per Transaction
Global Cache blocks received: 19.36 2.12
Global Cache blocks served: 19.39 2.13
GCS/GES messages received: 63.76 6.99
GCS/GES messages sent: 63.64 6.98
DBWR Fusion writes: 2.58 0.28
Estd Interconnect traffic (KB) 334.84
Edited by: gaoyafang on 2009-3-18 上午12:46 -
Too much time on network wait!
At peak time my apex pages are very very slow. I open Home>Utilities>Database Monitor>Sessions>Waits, and see all wait classes are network. I have already changed shared_servers to 100. But all waiting sessions are still waiting for network. How to improve it? Thank you!
John,
it was in the context of a cross-platform 9.2 to 11.1 migration that
we decided to opt for EPG using the APEX bundle integral to the db
packages (thus, we are still running 3.0.1). I think some documents
mentioned certain advantages of this architecture, but meanwhile I
have my doubts ...
To install APEX, we simply followed Note:457621.1 (How to Configure
Oracle Application Express (APEX) & the Embedded PL/SQL Gateway (EPG)
in an 11G DB).
We currently have a SR open for weeks, were it is tried to track down
the reason for those numerous virtual circuit waits, and found that
all sessions emenate from APEX sessions (with various users and
various apps). Thus, it is quite difficult to track down the reason
for those waits.
Is there an easy procedure to switch to Apache instead of EPG?
Regards, Thomas -
Query on dba_free_space ends in wait by event db file sequential read
Hello All,
Env: 10gR2 on WinNT
I gave the query
select tablespace_name,sum(bytes)/1024/1024 from dba_free_space group by tablespace_name and its waiting for ever.
I checked the wait event from v$session and its "db file sequential read".
I put a trace on the session before the running the above query:
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 1 0.06 0.06 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.06 0.06 0 0 0 0
Misses in library cache during parse: 1
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
db file sequential read 13677 0.16 151.34
SQL*Net message to client 1 0.00 0.00
db file scattered read 281 0.01 0.53
latch: cache buffers lru chain 2 0.00 0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 13703 0.31 0.32 0 0 0 0
Execute 14009 0.75 0.83 0 0 0 0
Fetch 14139 0.48 0.74 26 56091 0 15496
total 41851 1.54 1.89 26 56091 0 15496
Misses in library cache during parse: 16
Misses in library cache during execute: 16
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
db file sequential read 26 0.00 0.12
1 user SQL statements in session.
14010 internal SQL statements in session.
14011 SQL statements in session.I took the AWR Report (for 1 hr time period) and the top 5 events came out as,
Event Waits Time (s) (ms) Time Wait Class
db file sequential read 1,134,643 7,580 7 56.8 User I/O
db file scattered read 940,880 5,025 5 37.7 User I/O
CPU time 967 7.2
control file sequential read 4,987 3 1 0.0 System I/O
control file parallel write 2,408 1 1 0.0 System I/O The PHYRDS(from dba_hist_filestatxs) on my system01.dbf is 161,028,980 for the latest snap.
Could someone throw some light into what is happening here ?
TIA,
JJUnder some circumstances querying the dictionary can be slow, usually because of problems with bad execution plans related to bad statistics, try to gather statistics using dbms_stats.gather_fixed_objects_stats(); it has worked for me before.
You can also read Note 414256.1 Poor Performance For Tablespace Page Display In Grid Control Console which in addition points to a possible problem with the recycle bin.
HTH
Enrique
Maybe you are looking for
-
I've been using a USB mouse since I've had my laptop, and it's always worked fine until a week or so ago. When I turn my computer on the mouse will work just fine, but after a while it starts jumping around the screen whenever I move the mouse. I'm u
-
TDS certificate numbers according to Business Place for one key
Dear all, I am trying to generated TDS certificates through J1INCERT. I am able to generated certificate numbers also. But I want to generate the certificate numbers according to my business place. EX: I assigned number range as 200001 to 299999.
-
Yesterday I bought a brand new Zen V. I connected it via USB, until it had its battery loaded 00%, then installed the CD and managed to upload 00~ songs until it froze. Then had to reset the player and the songs are still there and play ok. The thing
-
How do I make After Effects CS5.5 preview in full FPS?
I have After Effects CS5.5 and whenever I put a clip into it and try to play the clip in a preview I get a message in the player that says its playing at a certain frame rate out of the frame rate it should be and then in parentheses (not realtime).
-
Problems with receiving emails
I just got this phone for Christmas and set up both email accounts on my phone. Up until now, I've been receiving my emails just fine on my phone and they've always loaded right, notified me, etc. Yesterday, I got an email in both inboxes (on my ph