Re: How To Distribute I/O over a limited # of disks.

From: Willem Dekker <willem_at_serc.nl>
Date: Mon, 11 May 1998 14:56:27 +0200
Message-ID: <3556F57B.1AF11E5B@serc.nl>

S Green wrote:
>
> I am configuring an OLTP application, using Oracle 7.3.2 on a Sun with
> Solaris 2.6. We only have 8 disks. In 3 months we will be buying another
> disk tray and several more disks. For now, I want the best compromise
> configuration. The application is very transactional, so RAID 5 not
> appropriate. We have an unattended 7x24 application. I really want to be
> able to ride through a disk failure automatically, so Raid 1 or RAID 0/1
> seems best.
>
> I want to mirror the system disk using RAID 1. That leave 6 disks for the
> data base. The redo logs, being sequential and requiring redundancy, would
> work well with RAID 1. That leaves 4 disks for everything else. Any
> suggestions. Yes, I know that 7 disks is suggested as a minimal
> configuration.
>
> Here is my highly compromised solution:
> disk0, mirrored (highly loaded, but it has a separate internal controller!)
> UNIX
> oracle product
> INDEXES
> control file 1
>
> disk1, mirrored
> SYSTEM
> REDO LOGS 1,2, 3….
> control file 2
>
> disk 2, mirrored
> RBS, RBS_2
> ARCHIVE LOG FILES (assuming we run in archive mode).
> control file 3
>
> disk 3, mirrored
> DATA
> TEMP
> control file 4
>
> Please offer suggestions, except the obvious- buying more disks :).
I have seen a simualar situation, where we didn't need need the 24x7 and unattended option,
and we decide to mirror (RAID 1) 3 disks. Thus :

DISK 1 (mirrored) : system disk (mirrored) + control file
DISK 2 (copy of disk 1)
DISK 3 (mirrored) : redo log + control file + system tablespace + INDEX

tablespace.
DISK 4 (copy of disk 3)
DISK 5 Archive log
DISK 6 TEMP + Rollback
DISK 7 DATA tablespace disk
DISK 8 (copy of disk 7)

But it depends on the data, index volumes projected and the TEMP + ROLLBACK space needed.
It does mean that DBA intervention is needed when disks 5 or 6 break. If it does, they will
stop the operation of the database, but don't need large recovery, so the database can be up in a short notice. Since the system is highly transactional I suspect the redo log disks get a big hit, by
separating it from the archive log disk, you can prevent some performance degradation,
during log switching. I know it's not optimal, but better than combining the redo log
with the archive log. Further the archive log is not essential for the database operation,
only for database recovery.
I would seperate the system disk from any database disks. You can seperate measurements much
easier, easy upgrades/disk moves. If you put all the 6 disks of the database in a
other enclosure, you can switch machines while keeping the data in case of a hardware failure.
The only way to make more optimal allocation is a more detailed study of the application
requirements. Then writing down all possible scenarios, and rank each on the performance and system management properties : each.

Like :             Update perf  Select perf  RecoveryWork Recovery Time
Greens's Config  : -            +            +            +
Dekker's Config : +            +            -            +

(many more possibilities)

Willem Dekker Received on Mon May 11 1998 - 07:56:27 CDT