Raj - You might also consider monitoring the I/O from the system side, until
that you won't have the full picture. That is probably where the RMAN load
would show up, and your instance would be indirectly affected. 4 channels
sounds pretty heavy. Is this tuned for to keep a tape drive busy? We haven't
had any noticed any interference, but since we're backing up to disk, we
just use a single channel.
Dennis Williams
DBA, 80%OCP, 100% DBA
Lifetouch, Inc.
[EMAIL PROTECTED]
-----Original Message-----
Sent: Wednesday, July 30, 2003 10:49 AM
To: Multiple recipients of list ORACLE-L
Thanks, Mladen, for that helpful quick reply.
The reason I ask is, one of our clients claims that they see a intermittent
database performance degrade (queries get timed out), during times when the
RMAN backup runs. Using an OS monitoring tool, they see a spike in I/O.
The RMAN backups have 4 channels writing to disk, and as such, I/O is to
be expected. I generated statspack reports during the times the backup
runs, and the tablespace I/O summary does show high avg reads/ms. Also, I
see higher than normal "total waits" in the tablespace I/O summary. This, I
guess, should be the "buffer busy wait" events, though I dont see it
amongst the top 15 wait events. Also, the "data block" waits in v$waitstat
spikes during this backup. So, I was wondering if I these wait events are
the real cause of the I/O spike?
Thanks
Raj
Mladen Gogala
<[EMAIL PROTECTED] To: Multiple recipients of list
ORACLE-L <[EMAIL PROTECTED]>
hia.net> cc:
Sent by: Subject: Re: buffer busy waits
and v$filestat
[EMAIL PROTECTED]
ity.com
07/29/2003
05:49 PM
Please respond
to ORACLE-L
Buffer busy wait has a different correlation with v$filestat and I/O.
Buffer
busy wait simply means that the buffer you're waiting for is pinned by
somebody else.
There are 3 classic situations:
1) DBWR hasn't finished writing to the disk yet.
2) Block is locked by another node (OPS, RAC).
3) RMAN is writing the block. That's right, RMAN locks (pins) blocks in
memory, otherwise it couldn't ensure consistent backup. That is the
reason
why RMAN doesn't need "alter tablespace begin backup" command.
To make the long story short, there is a note on metalink (Note:155971.1)
with
an appropriate title: Resolving Intense and "Random" Buffer Busy Wait
Performance Problems. Buffer busy waits are usually a consequence of I/O
subsystem not being to provide enough throughput to the database. What can
you
do with v$filestat? You can find where are your hot spots and fix the
problem.
On 2003.07.29 17:24, [EMAIL PROTECTED] wrote:
> Folks,
>
> Say a session issues a read request, and finds another session already
> reading the block into the buffer cache. If this session waits N ms on a
> "buffer busy waits" event, does this N ms of wait get added to the read
> times in v$filestat? Or is the readtim in v$filestat purely physical
I/O?
>
> Thanks
> Raj
>
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: DENNIS WILLIAMS
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
