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'
Thanks

Be 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.

Similar Messages

Cluster multi-block requests were consuming significant database time

Hi,
DB : 10.2.0.4 RAC ASM
OS : AIX 5.2 64-bit
We are facing too much performance issues and CPU idle time becoming 20%.Based on the AWR report , the top 5 events are showing that problem is in cluster side.I placed 1st node AWR report here for your suggestions.
WORKLOAD REPOSITORY report for
DB Name DB Id Instance Inst Num Release RAC Host
PROD 1251728398 PROD1 1 10.2.0.4.0 YES msprod1
Snap Id Snap Time Sessions Curs/Sess
Begin Snap: 26177 26-Jul-11 14:29:02 142 37.7
End Snap: 26178 26-Jul-11 15:29:11 159 49.1
Elapsed: 60.15 (mins)
DB Time: 915.85 (mins)
Cache Sizes
~~~~~~~~~~~ Begin End
Buffer Cache: 23,504M 23,504M Std Block Size: 8K
Shared Pool Size: 27,584M 27,584M Log Buffer: 14,248K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
Redo size: 28,126.82 2,675.18
Logical reads: 526,807.26 50,105.44
Block changes: 3,080.07 292.95
Physical reads: 962.90 91.58
Physical writes: 157.66 15.00
User calls: 1,392.75 132.47
Parses: 246.05 23.40
Hard parses: 11.03 1.05
Sorts: 42.07 4.00
Logons: 0.68 0.07
Executes: 930.74 88.52
Transactions: 10.51
% Blocks changed per Read: 0.58 Recursive Call %: 32.31
Rollback per transaction %: 9.68 Rows per Sort: 4276.06
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.87 Redo NoWait %: 100.00
Buffer Hit %: 99.84 In-memory Sort %: 99.99
Library Hit %: 98.25 Soft Parse %: 95.52
Execute to Parse %: 73.56 Latch Hit %: 99.51
Parse CPU to Parse Elapsd %: 9.22 % Non-Parse CPU: 99.94
Shared Pool Statistics Begin End
Memory Usage %: 68.11 71.55
% SQL with executions>1: 94.54 92.31
% Memory for SQL w/exec>1: 98.79 98.74
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
CPU time 18,798 34.2
gc cr multi block request 46,184,663 18,075 0 32.9 Cluster
gc buffer busy 2,468,308 6,897 3 12.6 Cluster
gc current block 2-way 1,826,433 4,422 2 8.0 Cluster
db file sequential read 142,632 366 3 0.7 User I/O
RAC Statistics DB/Inst: PROD/PROD1 Snaps: 26177-26178
Begin End
Number of Instances: 2 2
Global Cache Load Profile
~~~~~~~~~~~~~~~~~~~~~~~~~ Per Second Per Transaction
Global Cache blocks received: 14,112.50 1,342.26
Global Cache blocks served: 619.72 58.94
GCS/GES messages received: 2,099.38 199.68
GCS/GES messages sent: 23,341.11 2,220.01
DBWR Fusion writes: 3.43 0.33
Estd Interconnect traffic (KB) 122,826.57
Global Cache Efficiency Percentages (Target local+remote 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer access - local cache %: 97.16
Buffer access - remote cache %: 2.68
Buffer access - disk %: 0.16
Global Cache and Enqueue Services - Workload Characteristics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Avg global enqueue get time (ms): 0.6
Avg global cache cr block receive time (ms): 2.8
Avg global cache current block receive time (ms): 3.0
Avg global cache cr block build time (ms): 0.0
Avg global cache cr block send time (ms): 0.0
Global cache log flushes for cr blocks served %: 11.3
Avg global cache cr block flush time (ms): 1.7
Avg global cache current block pin time (ms): 0.0
Avg global cache current block send time (ms): 0.0
Global cache log flushes for current blocks served %: 0.0
Avg global cache current block flush time (ms): 4.1
Global Cache and Enqueue Services - Messaging Statistics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Avg message sent queue time (ms): 0.1
Avg message sent queue time on ksxp (ms): 2.4
Avg message received queue time (ms): 0.0
Avg GCS message process time (ms): 0.0
Avg GES message process time (ms): 0.0
% of direct sent messages: 6.27
% of indirect sent messages: 93.48
% of flow controlled messages: 0.25
Time Model Statistics DB/Inst: PROD/PROD1 Snaps: 26177-26178
-> Total time in database user-calls (DB Time): 54951s
-> Statistics including the word "background" measure background process
time, and so do not contribute to the DB time statistic
-> Ordered by % or DB time desc, Statistic name
Statistic Name Time (s) % of DB Time
sql execute elapsed time 54,618.2 99.4
DB CPU 18,798.1 34.2
parse time elapsed 494.3 .9
hard parse elapsed time 397.4 .7
PL/SQL execution elapsed time 38.6 .1
hard parse (sharing criteria) elapsed time 27.3 .0
sequence load elapsed time 5.0 .0
failed parse elapsed time 3.3 .0
PL/SQL compilation elapsed time 2.1 .0
inbound PL/SQL rpc elapsed time 1.2 .0
repeated bind elapsed time 0.8 .0
connection management call elapsed time 0.6 .0
hard parse (bind mismatch) elapsed time 0.3 .0
DB time 54,951.0 N/A
background elapsed time 1,027.9 N/A
background cpu time 518.1 N/A
Wait Class DB/Inst: PROD/PROD1 Snaps: 26177-26178
-> 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
Avg
%Time Total Wait wait Waits
Wait Class Waits -outs Time (s) (ms) /txn
Cluster 50,666,311 .0 30,236 1 1,335.4
User I/O 419,542 .0 811 2 11.1
Network 4,824,383 .0 242 0 127.2
Other 797,753 88.5 208 0 21.0
Concurrency 212,350 .1 121 1 5.6
Commit 16,215 .0 53 3 0.4
System I/O 60,831 .0 29 0 1.6
Application 6,069 .0 6 1 0.2
Configuration 763 97.0 0 0 0.0
Second node top 5 events are as below,
Top 5 Timed Events
Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
CPU time 25,959 42.2
db file sequential read 2,288,168 5,587 2 9.1 User I/O
gc current block 2-way 822,985 2,232 3 3.6 Cluster
read by other session 345,338 1,166 3 1.9 User I/O
gc cr multi block request 991,270 831 1 1.4 Cluster
My RAM is 95GB each node and SGA is 51 GB and PGA is 14 GB.
Any inputs from your side are greatly helpful to me ,please.
Thanks,
Sunand

Hi Forstmann,
Thanks for your update.
Even i have collected ADDM report, extract of Node1 report as below
FINDING 1: 40% impact (22193 seconds)
Cluster multi-block requests were consuming significant database time.
RECOMMENDATION 1: SQL Tuning, 6% benefit (3313 seconds)
ACTION: Run SQL Tuning Advisor on the SQL statement with SQL_ID
"59qd3x0jg40h1". Look for an alternative plan that does not use
object scans.
SYMPTOMS THAT LED TO THE FINDING:
SYMPTOM: Inter-instance messaging was consuming significant database
time on this instance. (55% impact [30269 seconds])
SYMPTOM: Wait class "Cluster" was consuming significant database
time. (55% impact [30271 seconds])
FINDING 3: 13% impact (7008 seconds)
Read and write contention on database blocks was consuming significant
database time.
NO RECOMMENDATIONS AVAILABLE
SYMPTOMS THAT LED TO THE FINDING:
SYMPTOM: Inter-instance messaging was consuming significant database
time on this instance. (55% impact [30269 seconds])
SYMPTOM: Wait class "Cluster" was consuming significant database
time. (55% impact [30271 seconds])
Any help from your side , please?
Thanks,
Sunand

JAVA execution consumed significant database time

Dear all,
DB 11. on solaris..
I have a time consuming package.. this package unloads data in the current db and loads data from another remote db in the same network. below is the recommendation from Oracle ADDM report.
This session is a work flow session. What can I do for JAVA execution consumed significant database time.?
JAVA execution consumed significant database time.
   Recommendation 1: SQL Tuning
   Estimated benefit is .5 active sessions, 43.98% of total activity.
   Action
      Tune the PL/SQL block with SQL_ID "6bd4fvsx8n42v". Refer to the "Tuning
      PL/SQL Applications" chapter of Oracle's "PL/SQL User's Guide and
      Reference".
      Related Object
         SQL statement with SQL_ID 6bd4fvsx8n42v.
         DECLARE job BINARY_INTEGER := :job; next_date DATE := :mydate;
         broken BOOLEAN := FALSE; BEGIN OWF_USER.START_METS_REFRESH(SYSDATE );
         :mydate := next_date; IF broken THEN :b := 1; ELSE :b := 0; END IF;
         END;Please advise
Kai

Hi Forstmann,
Thanks for your update.
Even i have collected ADDM report, extract of Node1 report as below
FINDING 1: 40% impact (22193 seconds)
Cluster multi-block requests were consuming significant database time.
RECOMMENDATION 1: SQL Tuning, 6% benefit (3313 seconds)
ACTION: Run SQL Tuning Advisor on the SQL statement with SQL_ID
"59qd3x0jg40h1". Look for an alternative plan that does not use
object scans.
SYMPTOMS THAT LED TO THE FINDING:
SYMPTOM: Inter-instance messaging was consuming significant database
time on this instance. (55% impact [30269 seconds])
SYMPTOM: Wait class "Cluster" was consuming significant database
time. (55% impact [30271 seconds])
FINDING 3: 13% impact (7008 seconds)
Read and write contention on database blocks was consuming significant
database time.
NO RECOMMENDATIONS AVAILABLE
SYMPTOMS THAT LED TO THE FINDING:
SYMPTOM: Inter-instance messaging was consuming significant database
time on this instance. (55% impact [30269 seconds])
SYMPTOM: Wait class "Cluster" was consuming significant database
time. (55% impact [30271 seconds])
Any help from your side , please?
Thanks,
Sunand

Sql statement consuming significant database time

This sql statement consuming significant elapsed time(2,446 seconds). also also cause significant user i/0 , is this because of using temp TABLE IN THIS QUERY ,
or is there any alternative for this query ?
"WITH TEMP AS ( SELECT ROOT, CHILD, LEVEL LEV FROM catagory V START WITH CHILD=:B1 CONNECT BY PRIOR ROOT=CHILD ) SELECT CHILD FROM TEMP WHERE LEV=(SELECT MAX(LEV) FROM TEMP) "
Thanks
Renjith

Click on the FAQ stick posting (at the top of this forum). Find the "+when my query is slow+" question and read the FAQ response to it.

Contention on index block splits consuming significant database time

Hi Guys,
can anybody suggest on how to remove Contention on index block splits,this is giving so many issues on my production DB,the CPU usage shots up and application hangs for few minutes.
DB is 10.2.0.3 and OS is IBM AIX 5.3

I found this.. it might be useful
One possibility is that this is caused by shared CBC latching peculiarities:
1) during normal selects your index root block can be examined under a
shared cache buffers chains latch.
So as long as everybody is only reading the index root block, everybody can
do it concurrently (without pinning the block). The "current holder count"
in the CBC latch structure is just increased by one for every read only
latch get and decreased by one on every release. 0 value means that nobody
has this latch taken currently.
Nobody has to wait for others for reading index root block in all read only
case. That greatly helps to combat hot index root issues.
2) Now if a branch block split happens a level below the root block, the
root block has to be pinned in exclusive mode for reflecting this change in
it. In order to pin a block you need to get the corresponding CBC latch in
exclusive mode.
If there are already a bunch of readers on the latch, then the exclusive
latch getter will just flip a bit in the CBC latch structure - stating it's
interest for exclusive get.
Every read only latch get will check for this bit, if it's set, then the
getters will just spin instead, waiting this bit to be cleared (they may
yield or sleep immediately as well, I haven't checked). Now the exclusive
getter has to spin/wait until all the shared getters have released the latch
and the "current holder count" drops to zero. Once it's zero (and the getter
manager to get on to CPU) it can get the latch, do its work and release the
latch.
During all that time starting from when the "exclusive interest" bit was
set, nobody could access this indexes root block except the processes which
already had the latch in shared mode. Depending on latch spin/sleep strategy
for this particular case and OSD implementation, this could mean that all
those "4000 readers per second" start just spinning on that latch, causing
heavy spike in CPU usage and they all queue up.
How do diagnose that:
You could sample v$latch_misses to see whether the number of "kcbgtcr:
kslbegin shared" nowaitfails/sleeps counter takes an exceptional jump up
once you observe this hiccup.
How to fix that once diagnosed:
The usual stuff, like partitioning if possible or creating a single table
hash cluster instead.
If you see that the problem comes from excessive spinning, think about
reducing the spinning overhead (by reducing spincount for example). This
could affect your other database functions though..
If you can't do the above - then if you have off-peak time, then analyse
indexes (using treedump for start) and if you see a block split coming in a
branch below root block, then force the branch block to split during
off-peak time by inserting carefully picked values into the index tree,
which go exactly in the range which cause the proper block to split. Then
you can just roll back your transaction - the block splits are not rolled
back nor coalesced somehow, as this is done in a separate recursive
transaction.
And this
With indexes, the story is more complicated since you can't just insert a
row into any free block available like with tables. Multiple freelists with
tables help us to spread up inserts to different datablocks, since every
freelist has its distinct set of datablocks in it. With indexes, the
inserted key has to go exactly to the block where the structure of b?tree
index dictates, so multiple freelists can't help to spread contention here.
When any of the index blocks has to split, a new block has to be allocated
from the freelist (and possibly unlinked from previous location in index),
causing an update to freelist entry in segment header block. Now if you had
defined multiple freelists for your segment, they'd still remain in the
single segment header block and if you'd have several simultaneous block
splits, the segment header would become the bottleneck.
You could relieve this by having multiple freelist groups (spreading up
freelists into multiple blocks after segment header), but this approach has
it's problems as well - like a server process which maps to freelist group 1
doesn't see free blocks in freelist group 2, thus possibly wasting space in
some cases...
So, if you have huge contention on regular index blocks, then you should
rethink the design (avoid right hand indexes for example), or physical
design (partition the index), increasing freelists won't help here.
But if you have contention on index segment's header block because of block
splits/freelist operations, then either partition the index or have multiple
freelist groups, adding freelists again won't help here. Note that adding
freelist groups require segment rebuild.

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.

Contention for latches related to the shared pool was consuming significant

We are having performance issue on our database. When I look at the AWR, I see that there is a contention for latches. Below is the AWR Report.
ADDM Report for Task 'ADDM:1775307360_12808'
Analysis Period
AWR snapshot range from 12807 to 12808.
Time period starts at 10-MAY-11 01.00.15 PM
Time period ends at 10-MAY-11 02.00.23 PM
Analysis Target
Database 'ADVFDWP' with DB ID 1775307360.
Database version 11.1.0.7.0.
ADDM performed an analysis of all instances.
Activity During the Analysis Period
Total database time was 27827 seconds.
The average number of active sessions was 7.71.
Summary of Findings
Description Active Sessions Recommendations
Percent of Activity
1 Shared Pool Latches 6.43 | 83.42 0
2 Top SQL by DB Time 2.41 | 31.24 3
3 "Concurrency" Wait Class 2.18 | 28.22 0
4 PL/SQL Execution 1.53 | 19.86 1
5 "User I/O" wait Class 1.33 | 17.24 0
6 Hard Parse 1.24 | 16.14 0
7 Undersized Buffer Cache .83 | 10.73 0
8 CPU Usage .7 | 9.02 0
9 Top SQL By I/O .31 | 4.04 1
10 Top Segments by I/O .24 | 3.12 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Findings and Recommendations
Finding 1: Shared Pool Latches
Impact is 6.43 active sessions, 83.42% of total activity.
Contention for latches related to the shared pool was consuming significant
database time in some instances.
Instances that were significantly affected by this finding:
Number Name Percent Impact ADDM Task Name
1 ADVFDWP1 99.31 ADDM:1775307360_1_12808
Check the ADDM analysis of affected instances for recommendations.
Finding 2: Top SQL by DB Time
Impact is 2.41 active sessions, 31.24% of total activity.
SQL statements consuming significant database time were found.
Recommendation 1: SQL Tuning
Estimated benefit is 1.07 active sessions, 13.82% of total activity.
Action
Run SQL Tuning Advisor on the SQL statement with SQL_ID "fdk73nhpt93a5".
Related Object
SQL statement with SQL_ID fdk73nhpt93a5.
INSERT INTO SFCDM.F_LOAN_PTFL_MOL_SNPSHT SELECT * FROM
F_LOAN_PTFL_MOL_SNPSHT_STG
Recommendation 2: SQL Tuning
Estimated benefit is 1 active sessions, 12.96% of total activity.
Action
Tune the PL/SQL block with SQL_ID "7nvgzsgy9ydn9". Refer to the "Tuning
PL/SQL Applications" chapter of Oracle's "PL/SQL User's Guide and
Reference".
Related Object
SQL statement with SQL_ID 7nvgzsgy9ydn9.
begin
insert into SFCDM.F_LOAN_PTFL_MOL_SNPSHT select * from
F_LOAN_PTFL_MOL_SNPSHT_STG;
end;
Recommendation 3: SQL Tuning
Estimated benefit is .4 active sessions, 5.2% of total activity.
Action
Investigate the SQL statement with SQL_ID "fcvfq2gzmxu0t" for possible
performance improvements.
Related Object
SQL statement with SQL_ID fcvfq2gzmxu0t.
select
a11.DT_YR_MO DT_YR_MO,
a11.IND_SCRTZD IND_SCRTZD,
a13.CD_LNSTAT CD_LNSTAT_INTGRTD,
sum(a11.CNT_LOAN) WJXBFS1,
sum(a11.AMT_PART_EOP_UPB) WJXBFS2,
sum(a11.AMT_LST_VLD_PART_UPB) WJXBFS3
from
SFCDM.F_LOAN_PTFL_MOL_SNPSHT
a11
join
SFCDM.D_DETD_LNSTAT_CURR
a12
on
(a11.ID_CYCL_CLOS_DETD_LNSTAT_SRGT = a12.ID_DETD_LNSTAT_SRGT)
join
SFCDM.D_LNSTAT_CD
a13
on
(a12.ID_LNSTAT_CD_SRGT = a13.ID_LNSTAT_CD_SRGT)
join
SFCDM.D_LOAN_CHARTC_CURR_MINI
a14
on
(a11.ID_LOAN_CHARTC_SRGT = a14.ID_LOAN_CHARTC_SRGT)
where
(a11.DT_YR_MO in (201103)
and a14.CD_SFCRM_LOAN_BUS_LI not in ('L', 'T', 'W')
and a13.CD_LNSTAT in (14)
and not exists
(select * from SFCDM.F_LOAN_PTFL_MOL_SNPSHT s
where s.id_loan_syst_gend = a11.id_loan_syst_gend
and s.dt_yr_mo

It is worth checking the actual size of the shared pool e.g.
select pool,sum(bytes)/1024/1024/1024 from v$sgastat group by pool;
the parameters you ahve posted suggest you have set a minimum but no maximum, so it could very large.
Next up is looking for unhared SQL i.e.
select column1 from some_table where column2='A_VALUE';
select column1 from some_table where column2='Another_Value';
where the code should be using binds instead of literals for security and performance reasons, a simple way to find this is to look in v$sql for sql having the same plan_hash_value but different sql_Ids and compare the sql_fulltext of each statement.
Also a possibility is sql with many child cursors, this is trickier as the cause may vary and may not be easy to fix. check th econtents of v$sql for sql that have high values in the child_number column anmd investigate the contents of v$sql_shared_cursor for the reason there are multiple child cursors.
Chris

Metrics "Database Time Spent Waiting (%)" is at ... for event class "Commit

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,
Chris

cprieur 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.

Database Time Spent Waiting (%): Wait Class Other nearly 100% all the time

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
Nicolas

Seems 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

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.

Waiting (%) Metrics "Database Time Spent Waiting (%)" is at 69.64818 for event class "Commit"

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

Database Time Spent Waiting (%) for event Commit

I have a 10G R2 database that has started to report this alert every minute.
Metrics "Database Time Spent Waiting (%)" is at 61.25661 for event class "Commit"
I have not changed any metric configuration and the really weird thing to me is that the database is completely idle. I am having difficulty finding good documentation on the Metrics and alerts. I read something that seemed related and it said the commit class has only one alert and that is for redo log write confirmation. There are no users other than myself connected to this database and I am just monitoring with the EM. Any ideas?
-Tim

Update...
The IBM rep said he could send someone over for $1500 day. Right. So I read over the DS4300 manuals again but nothing really stood out. However I thought it would be worth noting that when the write cache was turned 'off' for the logical with the redo logs the 'log file sync' wait event would stay below the warning threshold (50%) and average about 18%. With the write cache 'on' the wait event would always be above the warning threshold. Performance of the database overall is still degraded with either setting. I am going into production with the redo on a local mirror. Additionally I tested segment sizes of 64 ,32, and 16kb. The 16kb did not effect the 'log file sync' waits but proves to be excellent for transaction performance overall.
-Tim

Metrics "Database Time Spent Waiting (%)" is at 23,02268 for event class "C

Hi,
on 10g,
I have this alerte in DB control home page :
Metrics "Database Time Spent Waiting (%)" is at 23,02268 for event class "Commit"
Should I do any action/correction ?
Thank you.

user522961 wrote:
Thank you.
Here is the result :
SQL> select sid, event, p1, p2, p3 from v$session_wait where event not in ('SQL*Net message from client', 'rdbms ipc message', 'pipe get', 'PL/SQL lock timer',
'pmon timer');
SID EVENT                                                                    P1         P2      P3
163 jobq slave wait                                                           0          0       0
165 Streams AQ: waiting for messages in the queue                          8808 875118900       5
166 SQL*Net message to client                                        1413697536          1       0
167 wait for unread message on broadcast channel                      865275080 865241852       0
169 Streams AQ: qmn slave idle wait                                           0          0       0
170 Streams AQ: waiting for time management or cleanup tasks                  0          0       0
179 Streams AQ: qmn coordinator idle wait                                     0          0       0
194 smon timer                                                              300          0       0
8 rows selected.Regards.As per above result, it seems there was no critical wait event or something occurs during frequent commits.
If you know which application or batch processing caused this, for the best result, you should rerun this query during that workload.

Metrics "Database Time Spent Waiting (%)" is at 83.25965 for event class

Hello,
when i log into em console, i have alert below,
"Metrics "Database Time Spent Waiting (%)" is at 83.25965 for event class "Commit"
so, what do i need to do? i have no idea about this,
is it a critical error? is there any solution?
thank you
Ugur

Ugur MIHCI wrote:
Hello,
when i log into em console, i have alert below,
"Metrics "Database Time Spent Waiting (%)" is at 83.25965 for event class "Commit"
so, what do i need to do? i have no idea about this,
is it a critical error? is there any solution?
thank you
UgurProbably what you would want to do in this case is to first determine which wait events are in that event class:
{code}
SELECT
NAME
FROM
V$EVENT_NAME
WHERE
WAIT_CLASS='Commit';
NAME
log file sync
enq: BB - 2PC across RAC instances
{code}
If you are not using RAC, the second of the above wait events probably does not apply. Next, you need to determine what the "log file sync" wait means, so you might do a Google search of the Oracle documentation. Assume that you are using Oracle Database 10.2.0.x - you would then search for:
{code}
site:download.oracle.com "log file sync" 102
{code}
In my search, the first link was a page from the Oracle Database Performance Tuning Guide:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/instance_tune.htm
That page contained the following quote:
"log file sync
General area: I/O, over- committing
Possible cause: Slow disks that store the online logs, Un-batched commits
Look for: Check the disks that house the online redo logs for resource contention. Check the number of transactions (commits + rollbacks) each second, from V$SYSSTAT."
Excessive waits for log file sync may also be caused by lack of available CPU time - an overloaded CPU.
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.

Metrics "Database Time Spent Waiting (%) is ar 100 for event class "Applica

Metrics "Database Time Spent Waiting (%) is ar 100 for event class "Application".
i get this error in database. help me regarding this error.

Streams AQ: qmn coordinator idle wait     31     16     42598     1374.12     425976281     989870553     2723168908     6     Idle
Streams AQ: qmn slave idle wait     15     0     41599     2773.27     415990747     1830121438     2723168908     6     Idle
Streams AQ: waiting for messages in the queue     83     83     41478     499.73     414776290     3955192389     2723168908     6     Idle
jobq slave wait     134     131     39906     297.8     399055017     782339817     2723168908     6     Idle
Streams AQ: waiting for time management or cleanup tasks     7     4     3778     539.71     37779540     3702640206     2723168908     6     Idle
class slave wait     3     3     1499     499.54     14986144     1055154682     2723168908     6     Idle
Streams AQ: qmn coordinator waiting for slave to start     2     1     500     249.95     4999066     1565566389     1893977003     0     Other
LGWR wait for redo copy     1     0     0     0     1     4266849434     1893977003     0     Other

Wait class 'commit' consuming significant database time.

Similar Messages

Maybe you are looking for