Re: Oracle RAID

kmchugh_at_ix.netcom.com (Kevin McHugh) wrote:

>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

We're getting ready to implement an HP/RAID Oracle application and all this thread has been usefull. If we were to go with Level 5 what would be a good size for the striping unit. 2K ... 4K ... or 8K??? Received on Thu Sep 14 1995 - 00:00:00 CEST