Re: 10g Performance: its crawling
- From: MVR <yoursraju007@xxxxxxxxx>
- To: oracle-l <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 28 Dec 2006 15:22:18 -0500
Oops, I forgot dba_extents.BLOCK_ID column. Still not able to
understand why its waiting this long on this wait for reading a single
block..
Or may be my understanding is wrong :)
On 12/28/06, MVR <yoursraju007@xxxxxxxxx> wrote:
Hello,
After 10g upgrade, one job started performing very bad, real slow. It
used to complete in an hour and its taking around 4 hours now. I have
checked wait history from DBA_HIST_ACTIVE_SESS_HISTORY for last
night's run. Here is a top one event, ordered by TIME_WAITED Column.
~~~~~~~~~~~~~~~~~~~~~~~~~
Wait Event: db file sequential read,
Wait Class: User I/O
p1text : file# , p1: 328
p2text : block #, p2: 421640
p3text : blocks , p3: 1
TIME_WAITED: 1327817
~~~~~~~~~~~~~~~~~~~~~~~~~
Apparently it looks like its trying to read a single index block from
file 328(afaik). But this time_waited column is driving me crazy. I
thought If I assume that this is an I/O issue, it makes sense, but we
never had these issues in 9206... so this assumption may not be right.
How can we figure out Segment name with block# ? I know vetarans use
x$ tables to get this. Anyone any ideas please ?
Thanks
--
"Happy people plan actions, they don't plan results."
--
http://www.freelists.org/webpage/oracle-l
- References:
- 10g Performance: its crawling
- From: MVR
Other related posts:
- » 10g Performance: its crawling
- » Re: 10g Performance: its crawling
- » RE: 10g Performance: its crawling
- » Re: 10g Performance: its crawling
- » Re: 10g Performance: its crawling
- » RE: 10g Performance: its crawling
- » Re: 10g Performance: its crawling
- » Re: 10g Performance: its crawling
- » RE: 10g Performance: its crawling
- » Re: 10g Performance: its crawling
Hello, After 10g upgrade, one job started performing very bad, real slow. It used to complete in an hour and its taking around 4 hours now. I have checked wait history from DBA_HIST_ACTIVE_SESS_HISTORY for last night's run. Here is a top one event, ordered by TIME_WAITED Column. ~~~~~~~~~~~~~~~~~~~~~~~~~ Wait Event: db file sequential read, Wait Class: User I/O p1text : file# , p1: 328 p2text : block #, p2: 421640 p3text : blocks , p3: 1 TIME_WAITED: 1327817 ~~~~~~~~~~~~~~~~~~~~~~~~~ Apparently it looks like its trying to read a single index block from file 328(afaik). But this time_waited column is driving me crazy. I thought If I assume that this is an I/O issue, it makes sense, but we never had these issues in 9206... so this assumption may not be right. How can we figure out Segment name with block# ? I know vetarans use x$ tables to get this. Anyone any ideas please ? Thanks
- 10g Performance: its crawling
- From: MVR