Not completely true.
If the dbwr is going to write a buffer, it will set a bit that the buffer is
being written. In the good old days, this meant that the buffer could be
changed until the block was written ('write complete waits'). However in 8.1,
cloning of buffers was introduced. So now
]
hia.net cc:
Sent by: Subject: Re: buffer busy waits and
v$filestat
[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
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)
Hello Raj.
BBW with a p3=0 are a consecuence of the I/O subsystem
not being able to provide enough throughput to the
database, as Mladen has said.
But there are also many others causes for BBW. Check
p3.
Also if the session A is waiting for a buffer in the
buffer cache (that's a BBW), the
That's On 2003.07.29 19:59, Diego Cutrone wrote:
Another thing I think (I'm sorry to disagree with
Mladen on this) is that when DBWR hasn't finished
writing a buffer to the disk, and a session wants that
buffer in exclusive mode, there's a wait and that wait
is computed as a write complete wait
Gogala,
quote
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.
/quote
I have read that RMAN has the advantage of not
On 2003.07.29 21:36, Prem Khanna J wrote:
Gogala,
quote
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.
/quote
I
Thanks a lot for your explanation Gogala.
Eagerly waiting for Steve's revised edition of Oracle Internals.
Regards,
Jp.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Prem Khanna J
INET: [EMAIL PROTECTED]
Fat City Network Services-- 858-538-5051
