Automatic checkpoint tuning on RAC
Date: Wed, 1 Jul 2009 18:55:41 +0000 (UTC)
Message-ID: <h2gbfd$3q8$1_at_solani.org>
I recently talked about the automatic checkpoint tuning with a colleague of mine and we considered setting fast_start_mttr_target to a decent nonzero value like 300 on a RAC database. I am aware of the recommendation not to set it and the argument for that recommendation is the fact that another RAC instance will do a recovery, if an instance fails.
However, automatic checkpoint tuning has a some other effects besides guaranteeing the medium time to recover. It also tunes what used to be known as "db block write batch" and it tunes how many concurrent I/O requests will be spawned. It initiates incremental checkpoints, thus keeping the buffer cache clean and log switches cheap. It also has a nice "wizard" which tells me the optimal redo log size in megabytes and many other things. One among the columns in GV$INSTANCE_RECOVERY tells me how long would it take for the other instances to re-master block owned by my instance, should the instance fail, which means that the "checkpoint wizard" is RAC aware.
Now, I do have a development RAC which I used for setting the parameter. There is nothing wrong with it, but it's not very heavily used. My question is if there is anyone aware of global cache problems with the automatic checkpoint tuning? Any global cache deadlocks or hangs because of the coordination problems? Is anybody using the automatic checkpoint tuning on a RAC database? Should I expect problems if I set it on a heavily used production RAC database?
-- http://mgogala.freehostia.comReceived on Wed Jul 01 2009 - 13:55:41 CDT