Redo Space wait

Question

oracle : 9i
os : linux
log : archive
dg : primary
Production : Yes
The instance is up. the performace is poor due to redospace wait.
I checked the following.
1. select (sw.value)*100/lw.valuefrom v$sysstat sw, v$sysstat lwwhere sw.name='redo log space requests' and lw.name='redo writes';
24.9544131
2. Parameters
log_checkpoint_interval integer 0
log_checkpoint_timeout integer 1800
log_checkpoints_to_alert boolean TRUE
log_buffer integer 524288
3. SELECT name, value
FROM SYS.v_$sysstat
WHERE NAME in ('redo buffer allocation retries',
'redo log space wait time');
redo buffer allocation retries 5216940
redo log space wait time 40519121
4. Select name, value from v$sysstat
Where name in ('redo log space requests', 'redo entries'); 2
redo entries 785620472
redo log space requests 1295431
Other than restarting the server, Any action can be taken ?

Answer 1

1. Make sure your archiving destination isn't getting
full. If ARCH can't archive, LGWR can't switch, the
log buffer fills up and users then have to wait until
it unclogs.
space is enough . File is getting generated and able to transport also.
2. Make sure you have sufficient ARCH processes. As a
rough rule of thumb, LGWR can fill a log about three
times faster than ARCH can copy it. Therefore, there
is always a risk of ARCH getting bogged down with a
backlog of unarchived logs. If that happens, LGWR
will eventually get to a point where it can't
switch... and the log buffer fills up etc etc. ARCH
is supposed to be self-tuning (that is, extra ARCH
processes are spawned automatically). But you may
want to set log_archive_max_processes to provide a
minimum number of processes to start with (yeah, the
name of the parameter and its job are very confusing!
MAX_PROCESSES actually specifies a minimum (and
initial) number of processes!)
log_archive_max_processes integer 2
need to increase further?
3. Make sure you have sufficient log groups.If you've
only the minimum two, for example, LGWR will likely
be unable to switch back to log 1 when it's finished
in log 2, because log 1 is still being archived and
checkpointed. If LGWR waits, the log buffer fills up,
users have to wait until space becomes free once
more... With lots of log groups, however, LGWR can
switch into group 3, group 4, group 5 and so on
before having to switch back to attempt to re-use
group 1. I'd generally recommend a minimum of 4
groups.
SQL> select group#, (bytes)/(1024* 1024) from v$log;
GROUP# (BYTES)/(1024*1024)
1 5
2 5
3 5
I wll add 1 more group as per your suggestion
4. Make sure your logs are sufficiently large. Small
logs switch quicker, and hence LGWR can catch up with
itself more readily. If the logs are big, the rate of
switching slows down, but incremental checkpointing
means you don't build up a huge backlog of checkpoint
work to perform when the switch finally happens. Few
switches that don't have to do much will help keep
LGWR able to work, and if LGWR can keep clearing the
log buffer, users won't experience redo space waits.
5. Put your redo logs on your best hardware. If
you've got a mix of very fast disks and very ordinary
disks, put your online logs on the good stuff. If
you've got RAID 5 for the data files, don't put your
redo logs on it. Use RAID1+0 ideally, or RAID0 with
multiplexing. Keep the redo subsystem fast, in other
words.
running on RAID0 and archive logs are on san device
6. Related: keep the IO done to redo logs away from
the IO done to data files and anything else. Anything
which disrupts LGWR's ability to clear the log buffer
efficiently will increase your risk of redo space
waits.