fast_start_to_target is not in time, its measurement is in db_block_buffers. When this parameter is set, the DBWn writes dirty buffers out more aggressively to keep the number of blocks that must be processed during recovery below the value specified in the parameter.
value of fast_start_to_target cannot be greater than db_block_buffers.
For more details on how to set it RTM
Amar "There is a difference between knowing the path and walking the path."
FAST_START_IO_TARGET limits the number of blocks that needs instance recovery based on your system I/O. To set the recovery time to approximately 5 minutes, would require you to answer how much I/Os your system generates in around 5 minutes.
Best thing is that you test your recovery process each time by changing the value of this parameter. Smaller the value of FAST_START_IO_TARGET , Faster will be the recovery time. This feature is being depreciated in future versions in favour of FAST_START_MTTR_TARGET( from 9i onwards) which allows you to specify the recovery time in seconds as opposed to I/Os.
Is there any way I can test to get the time information by setting fast_start_to_target. Since my database is 8.1.7, I can't set parameter FAST_START_MTTR_TARGET. So I have to use parameter fast_start_to_target. I need to make sure database can be recovered in 5 min when instance is crushed.
LOG_CHECKPOINT_TIMEOUT: Assume this is set to 60. Oracle continually calculates the address of the redo record that was written 60 seconds ago. In order to satisfy this parameter, the checkpoint position must advance at least as far as this redo record. Should the checkpoint position point to a redo record older than this target position (written over 60 seconds ago), Oracle will write dirty buffers and advance the checkpoint until it points at a redo record written less than 60 seconds ago. Should the checkpoint position point to a redo record newer than this target position (written less than 60 seconds ago), Oracle will do nothing to satisfy this target for it is already satisfied