Re: Automatic checkpoint tuning on RAC

From: Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk>
Date: Wed, 1 Jul 2009 21:22:56 +0100
Message-ID: <y-CdnZ7O3IoDWNbXnZ2dnUVZ8qGdnZ2d_at_bt.com>



"joel garry" <joel-garry_at_home.com> wrote in message news:6dec4e02-846d-4fe0-bfbc-654a8b7ad504_at_24g2000yqm.googlegroups.com... On Jul 1, 12:19 pm, "Jonathan Lewis" <jonat..._at_jlcomp.demon.co.uk> wrote:
>
> Have you got a reference for the recommendation to not set it ?

See "Best Practices for Optimizing Availability During Unplanned Outages Using Oracle Clusterware and Oracle Real Application Clusters" section "Understand the Instance Recovery Target and Optimize if Required" which is referred to in
http://download.oracle.com/docs/cd/B28359_01/server.111/b28282/configbp004.htm

"In a RAC 10g Release 2 Patchset 2 environment (10.2.0.3), the best practice is to use the _FAST_START_INSTANCE_RECOVERY_TARGET parameter instead of the FAST_START_MTTR_TARGET parameter. The _FAST_START_INSTANCE_RECOVERY_TARGET parameter represents the number of seconds that it will take a surviving instance to recover the redo thread of a failed instance. This includes the first pass redo scan, recovery claiming, and the second pass redo application.

So, an important distinction is the fact that FAST_START_MTTR_TARGET bounds the total time for startup, mount, crash recovery, and open whereas
_FAST_START_INSTANCE_RECOVERY_TARGET bounds only instance recovery. Another important point is that _FAST_START_INSTANCE_RECOVERY_TARGET is based on the assumption that only one instance has failed. It is not correct to expect
_FAST_START_INSTANCE_RECOVERY_TARGET to properly bound instance recovery when multiple instances have failed"

jg

--


Joel,  thanks.for the reference.
Interesting suggestion - as you say.

-- 
Jonathan Lewis
http://jonathanlewis.wordpress.com

Author: Cost Based Oracle: Fundamentals
http://www.jlcomp.demon.co.uk/cbo_book/ind_book.html

The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
Received on Wed Jul 01 2009 - 15:22:56 CDT

Original text of this message