High virtual circuit wait event
Hi,
in my 11g Enterprise Edition Database I have a problem with some sessions that are almost always in virtual circuit wait event. What is this wait event and how can I troubleshoot it?
IMPORTANT: I'm not using XDB or APEX
Edited by: Insaponata on Jan 9, 2011 8:00 AM
From awr report based on the last our of work I see:
Top 5 Timed Foreground Events
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
virtual circuit wait 95,038 16,056 169 263.91 Network
DB CPU 305 5.02
SQL*Net message from dblink 42,432 48 1 0.79 Network
db file sequential read 21,990 48 2 0.78 User I/O
db file scattered read 26,021 36 1 0.59 User I/O
Do you think that this situation is normal? If no, how can I troubleshoot?
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. -
Hello,
I'm facing a problem, I can't get behind...
I've created a PL/SQL Package that generates a HTML page with the package procedure "HTP.PRN" in a Ora11gR2 DB.
Everything works fine. A client with IE or Firefox can access the HTML page without any problem by calling url
http://<db-servername>:8080/<DAD>/<Package_Name>.<Procedure_Name>
But when a second client tries to call the same page, it has to wait for approx a minute until the page will be shown in the browser.
During this time, I can see in dbconsole, that there is a massive peak for "virtual circuit wait" events. After loading the page in IE
"virtual circuit waits" run against zero again.
I've tested this now on ORA 11GR2 on a Windows and a Linux box. On both machines, there is the same behavior.
The listener.ora looks like this (on Windows box):
# listener.ora Network Configuration File: D:\oracle\product\11.2.0\JAAP\network\admin\listener.ora
# Generated by Oracle configuration tools.
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = CLRExtProc)
(ORACLE_HOME = D:\oracle\product\11.2.0\JAAP)
(PROGRAM = extproc)
(ENVS = "EXTPROC_DLLS=ONLY:D:\oracle\product\11.2.0\JAAP\bin\oraclr11.dll")
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rrottlaender02.seepex.local)(PORT = 1521))
ADR_BASE_LISTENER = D:\oracle
Any hint, showing me the rigth direction, would be great!
Thank you in advance...
Ciao,
RolandIncrease the amount of SHARED SERVERS via an ALTER SYSTEM statement
SQL> show user
SYS
SQL> alter system set shared_servers=5 scope=both; -
What does the event "virtual circuit wait" mean?
Hi all !
Can anyone tell me about this event? Yesterday I checked my ASH table and found that most of the time database spends on are 2 "non-idle" events: "db file sequential read" and "virtual circuit wait". I did not find any information about the second event on Metalink or in Documentation. Do i need to pay my attention to this event? DB is 11g on HP-UX.
Thanks in advance!The Oracle Reference has descriptions of wait events:
[Virtual Circuit Wait|http://download.oracle.com/docs/cd/E11882_01/server.112/e10820/waitevents003.htm#BABBCJEF]
The session waits for a virtual circuit operation to complete.Wait Time: 30 seconds
Parameter Description
circuit# Indicates the virtual circuit# being waited on
type Indicates the type of operation the session is waiting for -
Hii All..
I am seeing the following wait in the result of the query.Have you any idea what is the reason of the wait ?
SELECT event, total_waits, time_waited_micro
FROM v$system_event
WHERE wait_class <> 'Idle' order by 3 desc
result is
EVENT TOTAL_WAITS TIME_WAITED_MICRO
1 virtual circuit wait 588966 241791462220
2 SQL*Net more data from client 433132 78999049842
3 direct path read 7570504 22167783009
4 db file sequential read 10187059 18516379084
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production on AIX 5.3 ML 10Hii..
In the metalink note ID 6653834.8
This is a performance monitoring enhancement to split the
'virtual circuit status' wait event into two new
wait events:
"shared server idle wait" - for when the shared server is
idle waiting for something to do
"virtual circuit wait" - for when the shared server is
blocked waiting on a specific
circuit / message
The wait "virtual circuit status" no longer exist with this fix. -
Dear experts,
can you please help on the below query... we have to identify top 5 wait events which is make critical impact on the particular database. different wait events available in oracle, could please list out 4 or 5 wait events which we need to take high attention.A wait event tells you what the database is waiting on. No wait event is any better or worse than any other wait event-- there is no such thing as a critical wait event.
Take a process in the physical world, let's say getting to work. Worker A clocks 5 minutes of time walking to the bus stop, 30 minutes of time waiting for the bus, 45 minutes riding the bus, and 10 minutes walking from his stop to work. Worker B clocks 60 minutes of time driving from home.
Worker A's wait profile, then is
45 min - riding bus
30 min - waiting for bus
10 min - walking
Worker B's wait profile is
60 min - driving to work
For worker A, the commute is dominated by the "riding bus" and "waiting for bus" wait events. Potentially, A could optimize those wait events a bit by finding a faster bus or better coordinating his arrival at the bus stop with the bus schedule. But that may be the most efficient way for A to get to work.
For worker B, the commute is dominated by the "driving to work" wait event. Again, there may be opportunities to reduce that wait event but it may simply be that B lives an hour from work.
A monitoring report on A's commute would likely want to highlight changes from the normal wait events. If B suddenly starts spending 10 minutes walking, for example, with no decrease in the other wait events, you'd want to highlight that as abnormal while that same wait event would be perfectly normal for A. If A suddenly starts spending 45 minutes waiting for the bus, you'd want to highlight that as abnormal because the basline expectation is that A will wait for about 30 minutes a day.
Justin -
10.2.0.3 high concurrency wait event
I have a new 64bit windows 10g 10.2.0.3 VM server doing nothing but spinning its wheels. I intalled Oracle on it Friday and when I checked it tonight I see it is getting high concurrency wait events. Looks like every 10 minutes concurrency goes up to about 35.0 (?seconds) and then goes back to 0 - up and down every few minutes. Just enough to hit the warning threashold.
I need this machine for a peoplesoft install on Monday morning.
Anyone have any ideas what this could be? I kinda know what concurrency is but not sure if it could be from hardware or software.
Didn't see any patches/bugs but I will continue to look.
Help, KathieWhat are the wait events as described in v$system_wait and v$session_event?
-
DB CPU wait event is high in AWR
Hello Experts,
Could you please tell me what are the causes of increasing DB CPU wait event ? I mentioned below which i know. please guide me
1. When Buffer cache is more than required then DB CPU wait event occur.
Regards,
SachinSachin.Ichake wrote:
Currently in my database DB CPU has taken 90% DB time . in accordance to resolve it I will gonna follow steps
1. Tune the query which has taken more cpu
2. Decrease Buffer cache size by referring buffer cache advisory.Solve what? You must understand that DB CPU is not shown as a Wait Event but as a Timed Event and so are the other events that are shown in the Top 5 Timed Events category. This is an indication of how much you have used in the comparison of the total DB Time but not necessarily , it's an issue as to do anything in the system, you would need to burn the CPU only. You need to check that how much total CPU time you have with you and then compare it with your DB CPU seconds. In addition to this, you also need to check the CPU consumption from the o/s commands like Top etc. Combining all of such information only would be able to help to understand that whether any tuning needs to be done or not.
Post here the AWR/Statspack report. That would give more clear picture of the things.
Aman.... -
"EMPTY" Virtual Circuits causes the dispatcher proces D000 use 100% CPU
(29th April)
SQL*Plus: Release 10.2.0.1.0 - Production on Wed Apr 29 14:59:56 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Data Mining and Real Application Testing options
Could someone please indicates why the D000 process uses 100% cpu while no XDB action seems to be running? Whe are not using shared server (besides the XML DB usage) and the only value for the dispatcher parameter in the init<SID>.ora = (PROTOCOL=TCP) (SERVICE=<SID>XDB).
update (30th april)
When I lookup the virtual circuits I notice 2 VC without server and waiter address and without session info.
GERE@ARG_DV8>
# SELECT RAWTOHEX(C.CIRCUIT), RAWTOHEX(C.SERVER) SRV, RAWTOHEX(C.WAITER)WTR,
2 D.NAME,
3 S1.NAME,
4 S.SID,
5 S.SERIAL#,
6 C.STATUS,
7 C.QUEUE,
8 C.MESSAGES,
9 C.BYTES
10 FROM V$CIRCUIT C, V$DISPATCHER D, V$SHARED_SERVER S1, V$SESSION S
11 WHERE C.DISPATCHER = D.PADDR(+) AND C.SERVER = S1.PADDR(+) AND
12 C.SADDR = S.SADDR(+)
13 /
CIRCUIT SRV WTR NAME NAME SID SERIAL# STATUS QUEUE MESSAGES BYTES
C0000002398456C0 00 00 D000 NORMAL NONE 6 261
C000000239840DC0 00 00 D000 NORMAL NONE 7 280
2 rows selected.
The SADDR is empty also.
GERE@ARG_DV8>
# SELECT SADDR, CIRCUIT, DISPATCHER, SERVER, SUBSTR(QUEUE,1,8) "QUEUE", WAITER
2 FROM V$CIRCUIT;
SADDR CIRCUIT DISPATCHER SERVER QUEUE WAITER
00 C000000239840DC0 C000000214C05FB8 00 NONE 00
00 C0000002398456C0 C000000214C05FB8 00 NONE 00
2 rows selected.
A lsnrctl services shows 2 current
Service "ARG_DV8XDB" has 1 instance(s).
Instance "ARG_DV8", status READY, has 1 handler(s) for this service...
Handler(s):
"D000" established:58903 refused:0 current:2 max:2046 state:ready
DISPATCHER <machine: leo, pid: 5672>
(ADDRESS=(PROTOCOL=tcp)(HOST=leo.argenta.be)(PORT=53044))
Stop and start of the listener doesn't solve this problem but killing the unix process will do. When I killed the D000 proces a new dispatcher is started (does pmon do this?) and the current shows 0. This workaround is fine on the DVL machine but no sollution on a production DB :-)
Kind regards,
Rene
Edited by: Rene Geilings on Apr 30, 2009 2:28 AMBy the way... you just could be unlucky hitting a very rare situation that caused the phenomenon decribed by you. Deamon processes also could arise due too standard JDBC, ODBC or other connection methods. As long as you don't provide Oracle Support with a SR, you will not know if it is actually XDB related or not.
If I would implement XDB functionality in a production system than at least I would:
a) disable automatic memory management by setting SGA parameters manually
b) set the large_pool_size to a appropriate value to support the shared server processes
c) tweak dispatcher and shared server processes to match at least values that represent
the minimum++ needed processes (= a higher value then needed maximum)
d) set java_pool size to a decent size (250 Mb or higher)
e) set an appropriate PGA setting to support XML fragment handling
f) DISABLE autoregistering database functionality with the listener
(see amongs others "Registering non-default XMLDB HTTP/WebDAV and FTP ports
on a non-default Oracle Listener port" - http://www.liberidu.com/blog/?p=116)
g) alter the xdbconfig.xml file with more appropiate timeouts, locking and cache handling.
h) dedicate a specific listener (aka a a listener not called "LISTENER") for shared server
connection handling (this for management reasons and specific debugging).
i) use version 10.2.0.4.0 or 11.1.0.7.0 for production environments (I know that this
matches your environment)
j) always enforce that client software matches the database version
(as in your case 10.2.0.4.0)
k) keep NLS settings on client and database equal and support a AL32UTF characterset
(IMHO a minimum requirement on the database side) -
Problem identifying db object for "buffer busy waits" event.
10.2.0.3
AIX 64
SELECT username, a.p1text, a.p1, a.p2text, a.p2, a.p3text, a.p3, event FROM v$session a WHERE
a.status='ACTIVE'
AND a.event = 'buffer busy waits'
Query reports about 40 active sessions with this information:
file# 3746
block# 2
class# 13
select
owner,
segment_name,
segment_type
from
dba_extents
where
file_id = 3746
and
2 between block_id and block_id + blocks -1;
no rows returned
SELECT MAX(a.file#) FROM sys.file$ a
3535
This was only a temporary situation when after couple of minutes(7) wait event "buffer busy waits" dissapeared completely.
Any ideas?
Thank you,
Daniel.http://perfvision.com/papers/06_buffer_cache.ppt
Slide 80-81 points at increasing the size of the initial and next extent for File Header Block buffer busy waits
Side 85 points at high extent allocation for File Header Block buffer busy waits
http://perfvision.com/ftp/hotsos/aas.ppt
Side 55 points at extent allocation too small/too many extents being allocated for File Header Block buffer busy waits
A couple hints from the documentation:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/instance_tune.htm
"To determine the possible causes [of buffer busy waits], first query V$SESSION to identify the value of ROW_WAIT_OBJ# when the session waits for buffer busy waits."
"To identify the object and object type contended for, query DBA_OBJECTS using the value for ROW_WAIT_OBJ# that is returned from V$SESSION."
"V$SEGMENT_STATISTICS - This is a user-friendly view of statistic values. In addition to all the columns of V$SEGSTAT, it has information about such things as the segment owner and table space name. It makes the statistics easy to understand, but it is more costly."
You may want to query DBA_TEMP_FILES for the specific FILE_ID identified by the V$SESSION. Taking a look at V$SEGMENT_STATISTICS might also be helpful.
Are you using dictionary managed tablespaces, locally managed tablespaces with manual extent size management, ASSM with manual extent size management, or ASSM with automatic extent size management?
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
Hi frnds,
As, I'm beginner to performance tuning I dont know
What action do i need to take?
I mean how to read the output which I given below.
this is the output suffering buffer busy waits.
Could anyone please tell me
CLASS TOTAL_WAITS TOTAL_TIME
data block 93303 58711
unused 0 0
system undo header 12 232
undo header 7847 6636
3rd level bmb 0 0
save undo header 0 0
bitmap index block 0 0
file header block 0 0
free list 0 0
undo block 68 207
segment header 422 399
extent map 0 0
2nd level bmb 0 0
system undo block 0 0
sort block 0 0
save undo block 0 0
1st level bmb 1 17
bitmap block 0 0
Thanks, Muhammed Thameem. SHello,
"Buffer busy waits" is contention for a buffer (representing a specific
version of a database block) within the Buffer Cache. So, in essence
it is block contention and thus it is most likely something to do with
the design of the tables and indexes supporting the application. A
built-in bottleneck. On indexes, it could be the age-old problem of
insertions into an index on a column with a monotonically-ascending
data value (i.e. timestamps or sequence numbers) which tends to cause
contention on the highest leaf node of the index. On tables, it might
have to do with many concurrent insertions into a table in a
freelist-managed tablespace where the table has only one freelist. It
could also be due to a home-grown implementation of sequence-number
generators (i.e. small table with one row, one column in which contains
the "last value" of a sequence, etc) which lots of people use to avoid
not being "portable across databases" which they think means not using
Oracle sequences (yadda yadda yadda).
I'd look for any SQL statement in the "SQL sorted by Elapsed Time"
section of the AWR report which exhibits high elapsed time but
relatively low CPU time, indicating a lot of wait time. Of course,
there are something like 800 possible wait events in current releases
of Oracle, of which "buffer busy waits" is only one, so this is just
inference and not a direct causal connection to your problem. But,
once I find such statements I'd check to see if they are
accessing/manipulating tables within the CUBS_DATA tablespace, and then
use "select * from table(dbms_xplan.display_awr('sql-id'))" to
get the execution plan(s), and then look for something ineffective
within the execution plan. You might find the script "sqlhistory.sql" helpful
here as well, to get a "historical perspective" on the execution of the
SQL statements over time, in case the buffer busy waits peaked at some
point in the past
Please refer to:
http://www.pubbs.net/201003/oracle/51925-understanding-awr-buffer-waits.html
Also
http://www.remote-dba.net/oracle_10g_tuning/t_buffer_busy_waits.htm
kind regards
Mohamed -
High Buffer Busy Wait due to Concurrent INSERTS
Hi All,
One of my OLTP database is running on 11.1.0.7 (11.1.0.7.0 - 64bit Production) with RHEL 5.4.
On frequent basis, i am observing 'BUFFER BUSY WAITS' and last time i tried to capture some dictionary information to dig the waits.
1. Session Watis :
Oracle Sec Hash
Sid,Serial User OS User Svr-Pgm Wait Event State-Seq Wt Module Cmnd Value P1 P2 P3
633,40830 OLTP_USE fateadm 21646-orac buffer busy wai Wtng-9999 1 ORDERS ISRT 3932487748 384 1863905 1
647, 1761 OLTP_USE fateadm 22715-orac buffer busy wai Wtng-3837 0 ORDERS ISRT 3932487748 384 1863905 1
872, 5001 OLTP_USE fateadm 21836-orac buffer busy wai Wtng-9999 1 ORDERS ISRT 3932487748 384 1863905 1
702, 1353 OLTP_USE fateadm 21984-orac buffer busy wai Wtng-9999 1 ORDERS ISRT 3932487748 384 1863905 1
337,10307 OLTP_USE fateadm 21173-orac buffer busy wai Wtng-9999 1 ORDERS ISRT 3932487748 384 1863905 1
751,43016 OLTP_USE fateadm 21619-orac buffer busy wai Wtng-9999 1 ORDERS ISRT 3932487748 384 1863905 1
820,17959 OLTP_USE fateadm 21648-orac buffer busy wai Wtng-9999 0 ORDERS ISRT 3932487748 384 1863905 1
287,63359 OLTP_USE fateadm 27053-orac buffer busy wai Wtng-9999 0 ORDERS ISRT 3932487748 384 1863905 1
629, 1653 OLTP_USE fateadm 22468-orac buffer busy wai Wtng-9999 1 ORDERS ISRT 3932487748 384 1863905 1
788,14160 OLTP_USE fateadm 22421-orac buffer busy wai Wtng-9999 0 ORDERS ISRT 3932487748 384 1863905 1
615, 4580 OLTP_USE fateadm 21185-orac buffer busy wai Wtng-9999 0 ORDERS ISRT 3932487748 384 1863905 1
525,46068 OLTP_USE fateadm 27043-orac buffer busy wai Wtng-9034 1 ORDERS ISRT 3932487748 384 1863905 1
919,23243 OLTP_USE fateadm 21428-orac buffer busy wai Wtng-6340 1 ORDERS ISRT 3932487748 384 1863906 1
610,34557 OLTP_USE fateadm 21679-orac buffer busy wai Wtng-6422 1 ORDERS ISRT 3932487748 384 1863906 1
803, 1583 OLTP_USE fateadm 21580-orac buffer busy wai Wtng-6656 1 ORDERS ISRT 3932487748 384 1863906 1
781, 1523 OLTP_USE fateadm 21781-orac buffer busy wai Wtng-9999 0 ORDERS ISRT 3932487748 384 1863906 1
369,11005 OLTP_USE fateadm 21718-orac buffer busy wai Wtng-9999 0 ORDERS ISRT 3932487748 384 1863906 1
823,35800 OLTP_USE fateadm 21148-orac buffer busy wai Wtng-9999 1 ORDERS ISRT 3932487748 384 1863906 1
817, 1537 OLTP_USE fateadm 22505-orac buffer busy wai Wtng-9999 1 ORDERS ISRT 3932487748 384 1863906 1
579,54959 OLTP_USE fateadm 22517-orac buffer busy wai Wtng-9999 0 ORDERS ISRT 3932487748 384 1863906 1
591,33597 OLTP_USE fateadm 27027-orac buffer busy wai Wtng-9999 1 ORDERS ISRT 3932487748 384 1863906 1
481, 3031 OLTP_USE fateadm 21191-orac buffer busy wai Wtng-3502 1 ORDERS ISRT 3932487748 384 1863906 1
473,24985 OLTP_USE fateadm 22629-orac buffer busy wai Wtng-9999 0 ORDERS ISRT 3932487748 384 1863906 1
868, 3984 OLTP_USE fateadm 27191-orac buffer busy wai Wtng-9999 0 ORDERS ISRT 3932487748 384 1863906 1
select owner,segment_name,segment_type from dba_extents where file_id = 384 and 1863905 between block_id and block_id + blocks -1;
OWNER SEGMENT_NAME SEGMENT_TYPE
ORDER ORDER_DETAILS TABLE
select TABLE_NAME,PARTITIONED,ini_trans ,degree,compression,FREELISTS from dba_TABLES WHERE TABLE_NAME='ORDER_DETAILS';
TABLE_NAME PAR INI_TRANS DEGREE COMPRESS FREELISTS
ORDER_DETAILS NO 1 1 ENABLED 1
Tablespace is not ASSM managed !
select
object_name,
statistic_name,
value
from
V$SEGMENT_STATISTICS
where
object_name = 'ORDER_DETAILS';
OBJECT_NAME STATISTIC_NAME VALUE
ORDER_DETAILS logical reads 487741104
ORDER_DETAILS buffer busy waits 4715174
ORDER_DETAILS db block changes 200858896
ORDER_DETAILS physical reads 143642724
ORDER_DETAILS physical writes 20581330
ORDER_DETAILS physical reads direct 55239903
ORDER_DETAILS physical writes direct 19500551
ORDER_DETAILS space allocated 1.6603E+11
ORDER_DETAILS segment scans 9727
ORDER_DETAILS table is ~ 153 GB non-partitioned table.
It seems its not a READ BY OTHER SESSIONS wait but BUFFER BUSY due to write-wirte contention inside same block. I have never observed Cache Buffer Chain/ ITL-Wait/ High wait time on dbfile sequential/scattered reads.Table contains one PK (composite index on 3 columns) which seems to be highly fragmented.This non partitioned global Index has 3182037735 rows and blevel is 4.
BHAVIK_DBA.FATE1NA>select index_name,status,num_rows,blevel,pct_free,ini_trans,clustering_factor from dba_indexes where index_name='IDX_ORDERS';
INDEX_NAME STATUS NUM_ROWS BLEVEL PCT_FREE INI_TRANS CLUSTERING_FACTOR
IDX_ORDERS VALID 3182037735 4 2 2 2529462377
1 row selected.
One of the index column value is being populated by sequence. (Monotonically increasing value)
SEGMENT_NAME MB
IDX_ORDERS 170590.438
Index size is greater than table size !Tuning goal here is to reduce buffer busy waits and thus commit latencies.
I think, i need to increase FREELISTS and PCT_FREE to address this issue, but not much confident whether it is going to solve the issue or not?
Can i ask for any help here ?Hi Johnathan;
Many thanks for your detailed write-up. I was expecting you !
Your post here gave lot of information and wisdom that made me think last couple of hrs that is the reason for the delay in reply.
I did visited your index explosion posts couple of times and that scenario only gave me insight that concurrent DML (INSERT) is cause of index fragmentation in my case.
Let me also pick the opportunity to ask you to shed more light on some of the information you have highlighted.
if you can work out the number of concurrent inserts that are really likely to happen at any one instant then a value of freelists that in the range of
concurrency/4 to concurrency/2 is probably appropriate.May i ask you how did you derive this formula ? I dont want to miss learning opportunity here !
Note - with multiple freelists, you may find that you now get buffer busy waits on the segment header block.I did not quite get this point ? Can you shed more light please? What piece in segment header block is going to result contention(BBW on SEGMENT HEADER) on all concurrent inserts ?
The solution to this is to increase the number of freelist groups (making sure that
freelists and freelist groups have no common factors).My prod db NON-RAC environment. Can i use FREELIST GROUPS here ? My little knowledge did not get, What "common factors" you are referring here ?
The reads could be related to leaf block splits, but there are several possible scenarios that could lead to that pattern of activity - so the next step is to find out which blocks are being
read. Capture a sample of the waits, then query dba_extents for the extent_id, file_id, and block_id (don't run that awful query with the "block_id + blocks" predicate) and cross-check the
list of blocks to see if they are typically the first couple of blocks of an extent or randomly scattered throughout extents. If the former the problem is probably related to ASSM, if the
latter it may be related to failed probes on index leaf block reuse (i.e. after large scale deletes).I have 10046 trace file with me (giving you some sample below) that can give some information. However, since the issue was critical, i killed the insert process and rebuilt both the indexes. Since, index is rebuilt, i am not able to find any information in dba_extents.
select SEGMENT_NAME,SEGMENT_TYPE,EXTENT_ID from dba_extents where file_id=42 and block_id=1109331;
no rows selected
select SEGMENT_NAME,SEGMENT_TYPE,EXTENT_ID from dba_extents where file_id=42 and block_id=1109395 ;
no rows selected
select SEGMENT_NAME,SEGMENT_TYPE,EXTENT_ID from dba_extents where file_id=42 and block_id=1109459;
no rows selected
select SEGMENT_NAME,SEGMENT_TYPE,EXTENT_ID from dba_extents where file_id=10 and block_id=1107475;
no rows selected
select SEGMENT_NAME,SEGMENT_TYPE,EXTENT_ID from dba_extents where file_id=10 and block_id=1107539;
no rows selected
select object_name,object_Type from dba_objects where object_id=17599;
no rows selected
WAIT #4: nam='db file sequential read' ela= 49 file#=42 block#=1109331 blocks=1 obj#=17599 tim=1245687162307379
WAIT #4: nam='db file sequential read' ela= 59 file#=42 block#=1109395 blocks=1 obj#=17599 tim=1245687162307462
WAIT #4: nam='db file sequential read' ela= 51 file#=42 block#=1109459 blocks=1 obj#=17599 tim=1245687162307538
WAIT #4: nam='db file sequential read' ela= 49 file#=10 block#=1107475 blocks=1 obj#=17599 tim=1245687162307612
WAIT #4: nam='db file sequential read' ela= 49 file#=10 block#=1107539 blocks=1 obj#=17599 tim=1245687162307684
WAIT #4: nam='db file sequential read' ela= 198 file#=10 block#=1107603 blocks=1 obj#=17599 tim=1245687162307905
WAIT #4: nam='db file sequential read' ela= 88 file#=10 block#=1107667 blocks=1 obj#=17599 tim=1245687162308016
WAIT #4: nam='db file sequential read' ela= 51 file#=10 block#=1107731 blocks=1 obj#=17599 tim=1245687162308092
WAIT #4: nam='db file sequential read' ela= 49 file#=10 block#=1107795 blocks=1 obj#=17599 tim=1245687162308166
WAIT #4: nam='db file sequential read' ela= 49 file#=10 block#=1107859 blocks=1 obj#=17599 tim=1245687162308240
WAIT #4: nam='db file sequential read' ela= 52 file#=10 block#=1107923 blocks=1 obj#=17599 tim=1245687162308314
WAIT #4: nam='db file sequential read' ela= 57 file#=42 block#=1109012 blocks=1 obj#=17599 tim=1245687162308395
WAIT #4: nam='db file sequential read' ela= 52 file#=42 block#=1109076 blocks=1 obj#=17599 tim=1245687162308470
WAIT #4: nam='db file sequential read' ela= 98 file#=42 block#=1109140 blocks=1 obj#=17599 tim=1245687162308594
WAIT #4: nam='db file sequential read' ela= 67 file#=42 block#=1109204 blocks=1 obj#=17599 tim=1245687162308686
WAIT #4: nam='db file sequential read' ela= 53 file#=42 block#=1109268 blocks=1 obj#=17599 tim=1245687162308762
WAIT #4: nam='db file sequential read' ela= 54 file#=42 block#=1109332 blocks=1 obj#=17599 tim=1245687162308841
WAIT #4: nam='db file sequential read' ela= 55 file#=42 block#=1109396 blocks=1 obj#=17599 tim=1245687162308920
WAIT #4: nam='db file sequential read' ela= 54 file#=42 block#=1109460 blocks=1 obj#=17599 tim=1245687162308999
WAIT #4: nam='db file sequential read' ela= 52 file#=10 block#=1107476 blocks=1 obj#=17599 tim=1245687162309074
WAIT #4: nam='db file sequential read' ela= 89 file#=10 block#=1107540 blocks=1 obj#=17599 tim=1245687162309187
WAIT #4: nam='db file sequential read' ela= 407 file#=10 block#=1107604 blocks=1 obj#=17599 tim=1245687162309618TKPROF for above trace
INSERT into
order_rev
(aggregated_revenue_id,
legal_entity_id,
gl_product_group,
revenue_category,
warehouse_id,
tax_region,
gl_product_subgroup,
total_shipments,
total_units_shipped,
aggregated_revenue_amount,
aggregated_tax_amount,
base_currency_code,
exchange_rate,
accounting_date,
inventory_owner_type_id,
fin_commission_structure_id,
seller_of_record_vendor_id,
organizational_unit_id,
merchant_id,
last_updated_date,
revenue_owner_type_id,
sales_channel,
location)
VALUES
(order_rev.nextval,:p1,:p2,:p3,:p4,:p5,:p6,:p7,:p8,:p9,:p10,:p11,:p12,to_date(:p13, 'dd-MON-yyyy'),:p14,:p15,:p16,:p17,:p18,sysdate,:p19,:p20,:p21)
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 613 5.50 40.32 96672 247585 306916 613
Fetch 0 0.00 0.00 0 0 0 0
total 613 5.50 40.32 96672 247585 306916 613
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 446
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 164224 0.04 62.33
SQL*Net message to client 613 0.00 0.00
SQL*Net message from client 613 0.03 0.90
latch: cache buffers chains 8 0.00 0.00
latch: object queue header operation 2 0.00 0.00Is there any other way to find out culprit amongst the two you have listed (ASSM / failed probes on index leaf block reuse ) ? -
Wait Events "log file parallel write" / "log file sync" during CREATE INDEX
Hello guys,
at my current project i am performing some performance tests for oracle data guard. The question is "How does a LGWR SYNC transfer influences the system performance?"
To get some performance values, that i can compare i just built up a normal oracle database in the first step.
Now i am performing different tests like creating "large" indexes, massive parallel inserts/commits, etc. to get the bench mark.
My database is an oracle 10.2.0.4 with multiplexed redo log files on AIX.
I am creating an index on a "normal" table .. i execute "dbms_workload_repository.create_snapshot()" before and after the CREATE INDEX to get an equivalent timeframe for the AWR report.
After the index is built up (round about 9 GB) i perform an awrrpt.sql to get the AWR report.
And now take a look at these values from the AWR
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
log file parallel write 10,019 .0 132 13 33.5
log file sync 293 .7 4 15 1.0
......How can this be possible?
Regarding to the documentation
-> log file sync: http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents003.htm#sthref3120
Wait Time: The wait time includes the writing of the log buffer and the post.-> log file parallel write: http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents003.htm#sthref3104
Wait Time: Time it takes for the I/Os to complete. Even though redo records are written in parallel, the parallel write is not complete until the last I/O is on disk.This was also my understanding .. the "log file sync" wait time should be higher than the "log file parallel write" wait time, because of it includes the I/O and the response time to the user session.
I could accept it, if the values are close to each other (maybe round about 1 second in total) .. but the different between 132 seconds and 4 seconds is too noticeable.
Is the behavior of the log file sync/write different when performing a DDL like CREATE INDEX (maybe async .. like you can influence it with the initialization parameter COMMIT_WRITE??)?
Do you have any idea how these values come about?
Any thoughts/ideas are welcome.
Thanks and RegardsSurachart Opun (HunterX) wrote:
Thank you for Nice Idea.
In this case, How can we reduce "log file parallel write" and "log file sync" waited time?
CREATE INDEX with NOLOGGINGA NOLOGGING can help, can't it?Yes - if you create index nologging then you wouldn't be generating that 10GB of redo log, so the waits would disappear.
Two points on nologging, though:
<ul>
it's "only" an index, so you could always rebuild it in the event of media corruption, but if you had lots of indexes created nologging this might cause an unreasonable delay before the system was usable again - so you should decide on a fallback option, such as taking a new backup of the tablespace as soon as all the nologging operatons had completed.
If the database, or that tablespace, is in +"force logging"+ mode, the nologging will not work.
</ul>
Don't get too alarmed by the waits, though. My guess is that the +"log file sync"+ waits are mostly from other sessions, and since there aren't many of them the other sessions are probably not seeing a performance issue. The +"log file parallel write"+ waits are caused by your create index, but they are happeninng to lgwr in the background which is running concurrently with your session - so your session is not (directly) affected by them, so may not be seeing a performance issue.
The other sessions are seeing relatively high sync times because their log file syncs have to wait for one of the large writes that you have triggered to complete, and then the logwriter includes their (little) writes with your next (large) write.
There may be a performance impact, though, from the pure volume of I/O. Apart from the I/O to write the index you have LGWR writting (N copies) of the redo for the index and ARCH is reading and writing the completed log files caused by the index build. So the 9GB of index could easily be responsible for vastly more I/O than the initial 9GB.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan -
High I/O wait observed in Linux based Oracle Database Server
Hi,
We have just migrated Oracle Database from Solaris Server to Linux VM [ESX] server.
We have observed that there is high I/O wait issues while database query is running on Linux VM, which was ideally zero in case of Solaris. The same Database was running with no i/o wait on solaris physical server.
In the same ref.I would like to below points.
- Recommendations for running Oracle on VM based Linux.
- Recommendations from ESX Host side
Please suggest.user558914 wrote:
We have just migrated Oracle Database from Solaris Server to Linux VM [ESX] server.
We have observed that there is high I/O wait issues while database query is running on Linux VM, which was ideally zero in case of Solaris. The same Database was running with no i/o wait on solaris physical server.What did you expect? A virtualised I/O subsystem to respond and perform like a real one?
That would a very unrealistic expectation. And as comparisons go, as sensible as comparing the taste of an apple with the odour of the colour blue.
Forget about comparisons. Only marketing, sales and the idiot believe the cr@p that introducing several s/w layers between the the target (e.g. sector on spinning rust) and the destination (e.g. Oracle) makea the path between target and destination, faster.
To optimise the virtualised target, you need to make the path as short as possible. If your virtual disk is for example a file on a cooked file system on the host, then you are introducing the host's complete I/O layer for accessing that virtual drive. If your virtual disk is an actual (raw) partition or drive on the host, then path is faster - passing through the host kernel as direct I/O and bypassing the host's cache and file system drivers.
I suggest that when you setup your virtualised environment, you do proper stress testing of the various configurations of a virtualised I/O subsystem, using something like fio. -
Hello SAP Community,
I start by mentioning a few details about the system I'll be talking about in this subject:
- SAP NetWeaver 7.0
- Oracle Database 10.2g
I was reading the following Note: "Note 618868 - FAQ: Oracle performance", in order to try to understand what's causing the oracle database to have slow performance.
While reading section 3 "How can I determine whether the general database performance can be optimized?" I found out that the ratio of "Busy wait time to CPU time" is away above the recommended 60:40 value. I'm getting a 94:6 ratio. This value was calculated using the query:
SELECT
ROUND((STM1.VALUE - STM2.VALUE) / 1000000) "BUSY WAIT TIME (S)",
ROUND(STM2.VALUE / 1000000) "CPU TIME (S)",
ROUND((STM1.VALUE - STM2.VALUE) / STM1.VALUE * 100) || ' : ' ||
ROUND(STM2.VALUE / STM1.VALUE * 100) RATIO
FROM V$SYS_TIME_MODEL STM1, V$SYS_TIME_MODEL STM2
WHERE STM1.STAT_NAME = 'DB time' AND STM2.STAT_NAME = 'DB CPU';
With such high values, SAP recommends to improve system performance doing some "wait event tuning".
Can someone give me some directions about this subject? Some guides specific to this subject would be nice. Any further information about my system you may require, please ask me.
Thanks in advance.
Best regards,
Daniel GarridoHello again,
Before I did any changes to the Oracle's parameters I checked the Note 619188 - FAQ: Oracle wait events, to understand what could be causing such high event wait time.
With the query:
SELECT EVENT, TOTAL_WAITS, TIME_WAITED, AVG_MS,
ROUND(RATIO_TO_REPORT(TIME_WAITED) OVER () * 100) PERCENT
FROM (SELECT SUBSTR(EVENT, 1, 30) EVENT, TOTAL_WAITS, TIME_WAITED,
ROUND(TIME_WAITED_MICRO / TOTAL_WAITS / 1000, 2) AVG_MS
FROM V$SYSTEM_EVENT
WHERE WAIT_CLASS NOT IN ('Idle', 'System I/O')
UNION
SELECT 'CPU' EVENT, NULL, VALUE, NULL
FROM V$SYSSTAT
WHERE STATISTIC# = 12
ORDER BY 3 DESC)
WHERE ROWNUM <=10;
I got the non-idle events that took more time in my system and the result was:
Result of the SELECT statement
EVENT
TOTAL_WAITS
TIME_WAITED
AVG_MS
PERCENT
log file switch (archiving nee
578.686
57.850.863
999.69
80
buffer busy waits
712.163
6.420.932
90.16
9
CPU
0
2.791.238
4
db file sequential read
4.005.546
1.746.442
4.36
2
log file sync
10.176.490
1.577.177
1.55
2
enq: TX - row lock contention
854.451
642.955
7.52
1
db file scattered read
1.055.533
621.332
5.89
1
enq: CF - contention
210.085
246.910
11.75
0
read by other session
561.558
119.910
2.14
0
log file switch completion
10.777
85.843
79.65
0
So most of the TIME_WAITED for wait events was because of the "log file switch (archiving needed)", after reading what could cause such wait event, I understood this was related with a problem I previously had in the server, where the archiving folder was with no space left. (Meanwhile the backup of the archives is being done and so the folder is being cleaned on a daily basis).
Thank you all for your help!
Maybe you are looking for
-
How to stop the Calendar from editing your input?
How to stop the Calendar from editing your input?
-
Message GU506 when branching to line item report
We have carried out a shortened fiscal year change and now when we use a existing report painter report to branch to the line item report, then the system generates Message GU506: "Posting period & is not defined for fiscal year variant &" I have fou
-
Want External Phone Number Mask to say "Unknown Caller" Is this Possible?
When a user dials an external # is it possible to have it show on Caller ID as "Unknown Caller"? I have deleted the # that is currently in the External Phone Number Mask, and left it blank, but the Coporate# now shows when he dials out. This is somet
-
Legal Consolidation: Entity structure question
Hi Experts, Just want to ask if technical Entities are required in order for Legal Consolidation to work in SAP BPC 7.5 NW SP6? I'm using both R-Type (Currencies) and G-Type dimension (Conso Groups). In my first structure, I only have the following s
-
Built in video player crashes?
After playing videos from iPhone and Canon point-and-shoot camera the player will stop playing and displays some message and I have to reboot the program. Any ideas why it does this? Thanks.