RE: db file scattered reads
- From: <Ogun.Heper@xxxxxxxxxxxxxxx>
- To: <sjaffarhussain@xxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 27 Jun 2006 12:06:42 +0300
Hi,
First of all, the p3 parameter doesn't have to be equal to
DB_FILE_MULTIBLOCK_READ_COUNT. The only explanation about this value in the
documentation is;
P3 - The number of blocks (should be greater than 1)
Furthermore, documentation states that;
13.5.1.2.3 Small Table
If a table contains less than DB_FILE_MULTIBLOCK_READ_COUNT blocks under the
high water mark, which can be read in a single I/O call, then a full table scan
might be cheaper than an index range scan, regardless of the fraction of tables
being accessed or indexes present.
So this can be your situation, if these are small lookup tables, then Oracle
can decide to do a full table scan and wait on the db file scattered read event
consequently, with a p3 value less than DB_FILE_MULTIBLOCK_READ_COUNT. For
example in my test case this occurs for a small table which has got only two
blocks.
PARSING IN CURSOR #2 len=25 dep=0 uid=46 oct=3 lid=46 tim=32288060382808
hv=468215388 ad='3382740c'
select count(*) from t
END OF STMT
PARSE #2:c=0,e=132,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=32288060382801
BINDS #2:
EXEC #2:c=0,e=78,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=32288060383009
WAIT #2: nam='SQL*Net message to client' ela= 2 p1=1413697536 p2=1 p3=0
WAIT #2: nam='SQL*Net message from client' ela= 1479 p1=1413697536 p2=1 p3=0
WAIT #2: nam='db file sequential read' ela= 34 p1=25 p2=16009 p3=1
WAIT #2: nam='db file scattered read' ela= 60 p1=25 p2=16010 p3=2
WAIT #2: nam='SQL*Net message to client' ela= 2 p1=1413697536 p2=1 p3=0
FETCH #2:c=0,e=511,p=3,cr=4,cu=0,mis=0,r=1,dep=0,og=4,tim=32288060385189
WAIT #2: nam='SQL*Net message from client' ela= 13590 p1=1413697536 p2=1 p3=0
Actually, you need to investigate this further in order to fully understand the
issue.
1. For which segments this is occuring? Are they small?
2. If there are a small number of segments hitting this event, why they are
being aged out from the buffer cache so often? Can CACHE or BUFFER_POOL KEEP be
an option?
3. If these segments are not too small, why are they being full scanned?
Best regards.
OgÃn Heper
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Syed Jaffar Hussain
Sent: Monday, June 26, 2006 6:21 PM
To: _oracle_L_list
Subject: db file scattered reads
Hi,
On one of our very busy OLTP Oracle 9i Rel. (9205) database on AIX 5.3
OS, 'db file scattered reads' wait event, most of the time, it shows
2, 1, 3 as p3 value.
What surprised me is that the value for db_file_multiblock_read_coutn
is set to 8, but, db file scattered reads never oftenly shows 8 as p3
values while looking in v$session_wait view.
There is another doubt about, 'buffer busy waits, reason code 130.
On dizwell site,from the below link, the author explains about buffer
busy waits explanation for reason code 130. When I look into metalink
note for buffer busy waits reference note, the explanation is totally
confused me and look totally different.
In metalink note, it says that the reason code 130 is like 'Block is
being read by another session and no other suitable block image was
found.. Whereas on dizwell has little bit, differenet explanation.
Can anyone explain about this?
http://dizwell.com/main/index.php?option=com_jd-wiki&Itemid=112&id=bufferbusywaits
--
Best Regards,
Syed Jaffar Hussain
8i,9i & 10g OCP DBA
Banque Saudi Fransi,
Saudi Arabia
I blog at :http://jaffardba.blogspot.com/
http://www.oracle.com/technology/community/oracle_ace/ace1.html#hussain
----------------------------------------------------------------------------------
"Winners don't do different things. They do things differently."
--
//www.freelists.org/webpage/oracle-l
************************************************************************
Bu elektronik posta ve onunla iletilen bÃtÃn dosyalar sadece gÃndericisi
tarafindan almasi amaclanan yetkili gercek ya da tÃzel kisinin kullanimi
icindir. Eger sÃz konusu yetkili alici degilseniz bu elektronik postanin
icerigini aciklamaniz, kopyalamaniz, yÃnlendirmeniz ve kullanmaniz kesinlikle
yasaktir ve bu elektronik postayi derhal silmeniz gerekmektedir.
TURKCELL bu mesajin icerdigi bilgilerin doÄruluÄu veya eksiksiz oldugu
konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne
sekilde olursa olsun iceriginden, iletilmesinden, alinmasindan ve
saklanmasindan sorumlu degildir. Bu mesajdaki gÃrÃsler yalnizca gÃnderen
kisiye aittir ve TURKCELLin gÃrÃslerini yansitmayabilir
Bu e-posta bilinen bÃtÃn bilgisayar virÃslerine karsi taranmistir.
************************************************************************
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you are not the intended recipient you are hereby notified that any
dissemination, forwarding, copying or use of any of the information is strictly
prohibited, and the e-mail should immediately be deleted.
TURKCELL makes no warranty as to the accuracy or completeness of any
information contained in this message and hereby excludes any liability of any
kind for the information contained therein or for the information transmission,
reception, storage or use of such in any way whatsoever. The opinions
expressed in this message belong to sender alone and may not necessarily
reflect the opinions of TURKCELL.
This e-mail has been scanned for all known computer viruses.
************************************************************************
--
//www.freelists.org/webpage/oracle-l
Other related posts:
