Re: Oracle with VMS shadowing and stripping

In article <22jha0$nec_at_ef2007.efhd.ford.com>, theobald_at_iao.ford.com (Mark Theobald) writes:
>
> We are planning on stripping and shadowing our disks that Oracle
> data files reside on under VMS version 5.5-2. I am looking for someone
> to share any experiences (bad or good?) related to this configuration
> using version 6.0.35 or later.

I am a DBA (not Systems) person managing several V6.0.34 and V6.0.36 databases which are gradually being migrated to V7.0.12/13.

VMS SHADOW'ing and STRIPE'ing are OS level thingys and Oracle works transparently with either and both at the same time.

We are currently STRIPE'ing 3 databases successfully. So far we haven't had any problems (knock wood).

STRIPE'ing gives you:

1. STRIPE'ing 2 or more disks together reduces the reliability of the disk set. If one disk gets hard errors then the contents of the entire stripe set is useless. ARCHIVE your data.
2. The stripe set gives you roughly 'n' times the performance at getting your data on/off the stripe set (where 'n' = number of disks in stripe set) and thus helps reduce I/O queues to the disk as well. Obviously, 'n' times is not correct. Perhaps one of the people 'in the know' could give you the correct formula. But it does help throughput, a lot.
3. You can only pull data from your stripe set as fast as the load on your HSC will transfer data. There are limits that you will need to look at and balance.
4. You get a larger single disk equal in size to the total disks in the stripe set. Oracle will let you do this (well sort of) by building a tablespace across several (independent) disks but it's not as effective as a real stripe set and you have to do the work of building the tablespaces that way.

We don't shadow our databases. We did try it once and it works fine. We rely on Oracle's ARCHIVE'ing facility for roll forward recovery. The users are able to accept downtime of up to a day for recovery purposes so this was an acceptable tradeoff. We do shadow our Oracle software and application software disks.  

SHADOW'ing gives you:

1. REDUNDANCY! In an 'n' member stripe set you can afford to have hard errors on 'n-1' disks before looking for a new job. This redundancy can be good or bad depending upon who wants the data 'safe' and who has to pay for the disks.
2. Minimal downtime during offline BACKUPs. Simply shutdown database, correctly remove one shadow set disk member, restart database, BACKUP disk, and put disk back in shadow set. Since Oracle now allows online BACKUPs without database shutdown this is not such a big advantage now.
3. Additional READ speed! A READ request can be satisfied from whichever disk in the shadow set can get to the data first thus reducing 'rotational' latency overhead in the I/O formula. Each additional disk in the shadow set DOES NOT give a straight line improvement in READs. It tapers off in usefulness quite quickly.
4. WORST CASE WRITE senario. Your WRITE to the shadow set does not finish until ALL disks in the set have been updated. Don't shadow for READ speed if more than 20% of the activity on the disk are WRITEs.

What if you STRIPE AND SHADOW your database?

Oracle works fine (we tried this too) and you get all the good things listed above and most of the bad things are significantly reduced in impact. The cost of redundancy (striping) is still high though.

First look at which database objects are your 'hot' ones and move them to low activity disks ie spread your I/O load across as many disks as possible without resorting to stripe or shadow.

If you've got the memory (RAM), then increase your SGA. Make it as big as possible and this will reduce READ I/O to the disk and may remove the need for shadowing for read speed. The increased SGA size will also help with WRITE I/Os by allowing Oracle to 'group' them and apply them more effeciently to the disk but you can't get away from having to DO the writes.

If increasing your SGA size isn't viable or doesn't increase speed enough then STRIPE disks for ALL I/O activity (no wasted space) or SHADOW disks for READ activity (100%+ wasted space)..

If you're going through this whole exercise to guarantee data survivability then SHADOW and activate Oracle ARCHIVE'ing.

Whew! i think I've rambled on a bit too much.

Hope you find some of it usefull.

Call me if you have any specific questions.

> --
> ----------------------------------------------------------------
> Mark A. Theobald | theobald_at_asc019.ets.ford.com
> Ford Motor Company Safety Labs | Phone: (313) 390-8094
> "What do you mean God requires a spaceship? " Capt. Kirk
> ----------------------------------------------------------------

Bruce... pihlab_at_cbr.hhcs.gov.au Received on Fri Jul 23 1993 - 01:22:24 CEST