Re: Fast object checkpoint
- From: "Jonathan Lewis" <jonathan@xxxxxxxxxxxxxxxxxx>
- To: "oracle-l" <oracle-l@xxxxxxxxxxxxx>
- Date: Sat, 23 Sep 2006 19:21:21 +0100
----- Original Message -----
From: "Mladen Gogala" <mgogala@xxxxxxxxxxx>
To: "oracle-l" <oracle-l@xxxxxxxxxxxxx>
Cc: "oracle-l" <oracle-l@xxxxxxxxxxxxx>
Sent: Saturday, September 23, 2006 6:19 PM
Subject: Re: Fast object checkpoint
I found the description of this new feature in the following document:
www.oracle.com/technology/deploy/performance/pdf/twp_perf_database%20performance%20with%20oracle10gr2.pdf
"Prior to Oracle Database 10g administrators could specify the expected crash
recovery time (MTTR) by setting the value of a checkpoint-related initialization
parameter (FAST_START_MTTR_TARGET). They could do so by using the
MTTR advisory, which helps predict the number of physical writes that would
arise
with different MTTR target values. With Oracle Database 10g, the database can
self-tune checkpoints activity to achieve good recovery times with low impact on
normal throughput. With automatic checkpoint tuning, Oracle Database takes
advantage of periods of low I/O usage to write out data modified in memory to
the
data files without adverse impact on the throughput. Consequently, a reasonable
crash recovery time can be achieved even if the administrator does not set any
checkpoint-related parameter or if this parameter is set to a very large value.
Another enhancement done in the second release of Oracle Database 10g
dramatically improves the performance of object-checkpoint requests issued for
objects accessed through direct path reads, a situation that can occur with
parallel
query. Before an object can be accessed through direct path reads, dirty buffers
of
the object must be written to data files on disk via an object-checkpoint
request.
Prior to Oracle Database 10g Release 2, the checkpoint request is handled by
issuing a checkpoint for the tablespace the object belongs to, writing out all
the
dirty buffers for the entire tablespace. Since a large number of objects may
reside in
the same tablespace, this implementation may cause large number of unnecessary
disk writes. With the new release, a checkpoint request for a target object will
only
write out the dirty buffers of that object, without incurring any additional
writes for
the dirty buffers of other objects"
Of course, this is a very important new performance feature. Many people have
noticed and inquired about the "KO locks", queried v$lock_type and didn't
investigate
any further, but this dramatically changes the way the database functions. It
also
dramatically impacts performance consideration as a big buffer cache in which
large
parts of a big table can be cached can cause a serious I/O contention and a lock
contention.
I'm looking for a mechanism to turn off this new behavior, at least until the
next patch
version, if not until the next major version.
--
Mladen Gogala
http://www.mgogala.com
--
//www.freelists.org/webpage/oracle-l
I don't understand why you think that writing the
dirty blocks from one object is likely to cause
more problems than writing the dirty blocks from
every object in the tablespace that holds the one
object that needs to be written.
Regards
Jonathan Lewis
http://www.oracle.com/technology/community/oracle_ace/ace1.html#lewis
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
Cost Based Oracle: Fundamentals
http://www.jlcomp.demon.co.uk/cbo_book/ind_book.html
--
//www.freelists.org/webpage/oracle-l
Other related posts:
