Separate database logs from the other database storage

For database logs, getting write complete confirmation from the disks as fast as possible is essential.

For the sapdatas, use a simple disk layout that is easy to understand and can be extended without big performance loss. Never fill the disks more than about 70% so there is room for extending space and time for ordering new disks/disk subsystems.

Place database logs on separate disks that contain no other data.

Make sure the remaining disk space of the disks containing the database logs will remain empty or contains disk space with little activity. The best way to achieve this is by placing (one or more) empty, read-only mounted file systems on those disks. Leaving those disks mainly unused is no waste of money - a slow R/3 system is much more expensive than buying some disks. Another way to avoid that database log disks are used for other purposes is to use solid state disk - they should be chosen to have about the same size as the database logs.

Place each log filesystem or raw device only in the outer areas of the disks. To do this, allocate space for the logs first. On empty disks the outer cylinders are used first.

Never place two consecutive logs (e.g. origlogA, origlogB or mirrlogD, mirrlogA) on the same disk(s) because during log switch time, the old logs are copied to the archive directory while the new logs are already used for the next transactions.

For large size R/3 installations, place database logs only on disk subsystems with write cache (e.g. A1xxx, A35xx, T3xx), or on solid state disks, or use the Fast Write Cache option. In these cases, striping is normally not necessary. However, note that there may be restrictions if the database server is part of a cluster. Place the disks containing the database logs in a separate access path (separate controller, at least separate loop). If there are only disk subsystems available without write cache, stripe the logs over 4 or better more disks. Make sure the disks containing the database logs will never be used for other data.

For medium size R/3 installations, placing database logs on separate write cached disk subsystems may not be necessary, depending on the I/O write load. As always, place the logs on separate disks and at least stripe the database logs (use RAID 0) if they have to be placed on disk subsystems without write cache.

For Oracle, use Oracle log mirroring as recommended by Oracle. You normally do not need Volume Manager mirroring for the Oracle logs