Re: Oracle RAID

In <41l3vg$g2r_at_kocrsv08.delcoelect.com> awdorrin_at_kocrsv01.delcoelect.com (Albert W. Dorrington) writes:
>
>
>In article <41e1gu$t03_at_news.ios.com>, nocera_at_haven.ios.com (Nocera)
 writes:
>|> michael.pawle_at_ncom_main.ccmail.ncom.nt.gov.au wrote:
>|>
>|> >How is ORACLE (v7.1.6) best configured on RAID5?
>|> >What is ORACLE performance like on RAID5 compared to a
 conventional
>|> >implementation over multiple disks?
>|> >Should ORACLE's online redo log files and control files be
 mirrored
>|> >on RAID5?
>|> >Should ORACLE's archivelog mode be switched on at all (as RAID5
 protects
>|> > data from loss)?
>|> >Would it be best to have a mix of RAID5 and non RAID disks so that
 log
>|> > and control files can physically exist in 2 places?
>|> >Where should Oracle Finacials out and log files be placed given a
 mix of
>|> > RAID5 and non-RAID disks?
>|>
>|> Under no condition would I run a high performance database at RAID
 5,
>|> especially if you have a lot of INSERT activity. You are much
 better
>|> off using mirroring (RAID 1).
>
> I'm not sure if i'd agree with this statement. It really depends
>a lot on what you would condsider 'a lot' of insert activity, also, it
>will depend on the size of the data transfers. RAID 1 can be a rather
>expensive alternative, since you need 2 times the disk space for what
>is required.
> In RAID 5 reads and writes to the disk drives can occur either
>in parallel or independently - depending on the size of the data
 transfer
>and the block depth used by the RAID controller. Quoting from an HP
 booklet
>on RAID that I have ("Disk Arrays", 1991 HP):
> Concurrent reads and writes can occur for short transfers, but
>lengthy transfers still require all drives. They go on to say:
>Level 5 may in some cases decrease performance for writes, depending
 on
>the system application. For a small write, a 'Read-Modify-Write'
 proceedure
>is used - which adds some extra overhead for small writes, when
 compared to
>RAID level 3. However, for small reads involving just a few drives,
 much
>better read concurrence occurs - since the array can process multiple
>operations.
>
>|> If you MUST use RAID 5 for some
>|> tables, use it only for tables that receive very little update
>|> activity. Remember a RAID 5 update will write both the update and the
>|> parity information. This is two I/Os and although interleaved, less
>|> than desirable.
>
> This is not really two I/Os, since the 'parity' information is written
>at the same time that the data is written. Of course with the RAID 1
 strategy
>you are recommending, you will the same type of activity, since the
 controller
>will still need to write to two separate drives.
>
>|>
>|> Secondly, redo log activity should be isolated from your data and
>|> index files. Never use redo logs and data or index files on the same
>|> devices. This is because redo logs write synchronously ( O_SYNC)
>|> while other Oracle writes to the database via DBWR use ether async IO
>|> or list IO.
>
> I'd agree that you have to look ahead when deciding which disks to
>place what tables, indicies, or logs. In fact, you may find that a mixture of
>several RAID types will result in better performance than one type.
>
>|> These are lessons we learned the hard way, I hope it helps.
>|>
>|> We have been using redo logs on internal disks and oracle to mirror
>|> them (groups) and putting data files on their own RAID 1 devices and
>|> isolating index files on different RAID 1 devices with great success.
>
> In our current configuration we are using both RAID 1 and RAID 5.
>Our RAID 5 portion consists of two RAID controllers, both configured with
>10 GB of usable disk space. On one of the subsystems we have placed the
>data tables, and on the second we have placed the index tables.
> We then have two 2 GB drives mirrored (RAID 1) for the log files
>which are generated.
> The system behaves very well, for our needs, and is much more
 efficient
>than the older system we were using. The data transfers into the system
 consists of
>4 - 6 insertions per minute, with sizes ranging from 10 kbytes to 5 Mbytes
 (an average
>size of about 500kbytes).
>
> What you need to remember, is that any type of RAID configuration
 will tend
>to degrade I/O performance - but performance needs to be tempered with
 security.
> You could have the fastest system around using no protection at all
 (RAID 0)
>but if you lose a disk, you might be looking for a new job.
> In my experience a combination of RAID 5 and RAID 1 offers a good
 balance
>between speed and security of data. However, your own situation might
 vary.
>
>-Al
>
>
>--
>Al Dorrington
>awdorrin_at_ictest.delcoelect.com Database Admin
>Delco Electronics - IC CIM Unix Sysadmin
>Kokomo, Indiana, USA Phone: 317.451.9655

I just recently left a site where I inheritted an HP T500 system configured with all Raid-5 disks for a data warehouse. In looking at the disk efficiency (ms/I/O) on the disks it quickly became apparent that the Raid-5 Disks were well matched to tablespaces containing data and index tablespaces because the performance of the reads is excellent (multiple concurrent reads to mutiple disks) and the writes were done asynchronously to by the DBWR processes (4). The problem is with files that the database writes synchronously. HP has an internal document that shows the degradation in preformance in this area. As more disks were required we began putting files with high synchonous I/O requirements on either Raid-1 or Raid 1/0. The initial files were the obvious redo logs, but the not so obvious files were the temporary and rollback tablespaces. Writes to these tablespace even though performed by the DBWR are required to be synchonous for the statement to complete. The difference between Raid-1 (a single mirrored disk) and Raid 1/0 (mutiple stripped disks mirrored) was about a factor of 3 better than the Raid-5 (Index creation on a Very Large Index went from 6 to 2 hours ).

Using the following lessons when It came time to build a system for Oracle Financials we used no Raid-5 disks but contructed the system from Raid 1 and Raid 1/0.

Regardless of the Raid level chosen we were still using archive logging which gave us continous point in time recovery capability. This is different than the instantaneous recovery ability of Raid. This is important when the ability to recover to a prior point in time is required and for on-line backups.

(for those interested the hardware for the Raid 1 and Raid 1/0 was the Hp Nike array which provides a flexible system where disks can be incorporated in a variety of Raid configurations all with hot swapped capability).

Lastly, the price premium of a Raid 1 system over a Raid 5 system is about 50% but (IMHO) given the price per megabyte ($0.5-$5) these days it is not worth quibbling over especially for systems of less than 20 gigabytes.

Kevin McHugh
DBA
The Triad Group Received on Wed Aug 30 1995 - 00:00:00 CEST