Re: Redo logs - need a guru

Hello Steve.

To add my own 2 cents worth to Frank's comments:

>A redo log should last at least 30 minutes. If you are filling
>up your REDO in less that 30 minutes - on average - then it is
>too small.
>Step 1. Make redos bigger

...And more of them. I've seem the same kind of problem you discribe with redo logs filling up and not draining before Oracle wraps around and waits on a busy log. Then it seems to wait until ALL logs are drained before continuing on its merry way.

One approach I took was the brute-force method. On a benchmark system (an HP T520 with 12 CPU's, 2GB RAM, and 120GB disk), I simply created 32 redo logs of 32MB each (a total of 1GB disk space just for redo logs!). That way no benchmark test came close to filling up all the redo logs before any one finished its drain.

>Step 2. Move Redos to their own disk - and - insure that it is
>setup for large writes - and - if archiving reads.

If you can, set up your redo logs in raw logical volumes. This will improve I/O and allow you to take advantage of async I/O, which on HP is only available in raw. I have found having at least the redo logs in raw space really helps. But first, you will need to implement async I/O.

In SAM (assuming HPUX 10.X), you will need to change the kernel device driver "asyncdsk" status from "out" to "in", then allow SAM to re-gen the kernel and reboot. Next, create a pseudo character device driver for Oracle.

    # mknod /dev/async c 101 0
    # chown oracle:dba /dev/async
    # chmod 660 /dev/async

Now you can create your raw logical volumes for redo logs. This example assumes 12 redo logs 16MB in size in a volume group "vgredo". I also add the ORACLE_SID as part of the logical device name, in this case "demo".

    # lvcreate -L 16 -n redo01_demo vgredo

           ...etc.

You now have device names /dev/vgredo/redoNN_demo, where NN is 01 through 12. For your next trick, change ownership of the character device names to oracle.

    # find /dev -type c -name "*_demo" -exec chown oracle:dba {} \;

Finally, the proper sizing in Oracle will be 1 system block (not 1 db block) less than the size of the raw device. (Note this only applies to redo logs in raw. Datafiles in raw must be at least 1 db block less.) So in your "create database" or "alter database add logfile", reference these redo logfiles as:
'/dev/vgredo/rredo01_demo' size 16383k reuse, ....

That extra 'r' in front of 'redo01' is not a stutter. That's the character device name for the raw logical volume.

My own personal preference when dealing with raw volumes is to not be OFA compliant, but to directly use the device name so that it's immediately obvious one is not dealing with filesystem datafiles. Also, I prefer to work through LVM for its flexibility, such as being able to stripe a logical volume across disks and controllers. If a system isn't running LVM, then I stay away from raw.

You can avoid some latching contention with parameters such as:

log_simultaneous_copies = 10	# 5 cpu's * 2
spin_count                       = 2000

Plus, many more. I should warn you that everything I've written here is from memory, so do check your own documentation.

I hope you find this useful.

                --Bolen Coogler Received on Sun Jul 28 1996 - 00:00:00 CEST