Every DBA knows that the size of their redo logs is very important.  Too small, and the frequent log switches tie-up the LGWR, ARCH and DBWR background processes.  Too large and you risk losing data during an instance crash.

As a general rule of thumb, Oracle recommends that you size your online redo logs not to switch more then 5 times per hour during peak DML times.  Also see my notes on fixing frequent log switches and these notes on tuning_online_redo_logs for RAC.

Here is a script that measures redo log sizing and log switches:

col day format a15;
col hour format a4;
col total format 999;

select
to_char(first_time,"yyyy-mm-dd") day,
to_char(first_time,"hh24′) hour,
count(*) total
from
See code depot for full script
v$log_history
group by
to_char(first_time,"yyyy-mm-dd"),to_char(first_time,"hh24")
order by
to_char(first_time,"yyyy-mm-dd"),to_char(first_time,"hh24")
asc;

Using the redo log sizing advisor

The following SQL will give advice on the optimal size of the redo logs, but manual inspection of redo log switch frequency is always the best approach:

Oracle 10g introduced an advisory utility that allows you to specify your optimal mean time to recovery (MTTR) recovery interval and uses this to suggest the optimal redo log size.  In Oracle 10g the fast_start_mttr_target parameter is used.

Oracle recommends using the fast_start_mttr_target initialization parameter to control the duration of startup after instance failure. With 10g, the Oracle database can now self-tune check-pointing to achieve good recovery times with low impact on normal throughput. You no longer have to set any checkpoint-related parameters.

This method reduces the time required for crash recovery and makes the recovery bounded and predictable by limiting the number of dirty buffers and the number of redo records generated between the most recent redo record and the last checkpoint. Administrators specify a target (bounded) time to complete the cache recovery phase of recovery with the fast_start_mttr_target initialization parameter, and Oracle automatically varies the incremental checkpoint writes to meet that target.

The target_mttr field of v$instance_recovery contains the MTTR target in effect. The estimated_mttr field of v$instance_recovery contains the estimated MTTR should a crash happen right away.

 For example,

SELECT
   TARGET_MTTR,
   ESTIMATED_MTTR,
   CKPT_BLOCK_WRITES
FROM
   V$INSTANCE_RECOVERY;

TARGET_MTTR ESTIMATED_MTTR CKPT_BLOCK_WRITES

----------- -------------- -----------------

         37             22            209187

Whenever you set fast_start_mttr_target to a nonzero value, and while MTTR advisory is ON, Oracle Corporation recommends that you disable (set to 0) the following parameters: