Re: Physical Layout of disk to use Oracle

Thanks Howard again!

Here is my final draft...after brain stromming for 6 hrs......

Basically, I am first MIRRORING (Hardware RAID 1) and then stripping (RAID 0) thereby implementing RAID 1+0.

hdisk0 + hdisk 1 --> aix --> RAID 1 and then RAID 0 --> AIX OS + Oracle SW

hdisk2 + hdisk 3 --> datadict -->RAID 1 and then RAID 0 --> SYSTEM Tablespace
If one of this disk crashes I have another mirrored redundant disk !

hdisk4 + hdisk 5 --> redo1 --> RAID 1 and then RAID 0 --> REDO LOGS GROUP 1 + ARCHIEVE Destination.

hdisk6 + hdisk 7 --> redo2 --> RAID 1 and then RAID 0 --> REDO LOGS GROUP 2 + ARCHIEVE Destination.

In this I am using MULTIPLEXING and MIRRORING. MIRRORING is achieved with disk 4&5 and with disk 5&6 and Multiplexing is achieved with redo1 and redo2.

hdisk8 + hdisk 9 + hdisk10 + hdisk11+ hdisk12 + hdisk 13 --> data --> RAID 1 and then RAID 0 --> DATA Files

NOTE: aix,datadict,redo1,redo2,data are the names to my RAID Arrays respectively.......

Also, hdisk0 and hdisk1 each are 18 GB and others are 36GB each.

Can I have REDO Logs and ARCHIEVE at same place...?

Any comments/issues on above plan...?

THANKS! "Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message news:<3f6a1422$0$26941$afc38c87_at_news.optusnet.com.au>...
> Hari Om wrote:
>
> > Thanks Howard.....HATS OFF to you.....that was really a good
> > advice....
> > (BTW, I also got the difference betwee members and groups...)
> >
> > Here is my advancement:
> >
> > disk0 --> AIX + SYSTEM TBLSP + Control File1
> > disk1 --> AIX + SYSTEM TBLSP + Control File1
> > disk2 --> REDO Log Files 1a,1b,1c + Control File2
> > disk3 --> REDO Log Files 2a,2b,2c + Control File3
> > disk4 --> ARCHIEVE + TEMP + Oracle SW
> > RAID 5 (disk5+disk6+disk7) --> DATA + UNDO
> >
> > what do you think...is it better approach then my previous
> > version....?
>
>
> I think it is better... but I still don't quite get why you are separating
> the SYSTEM tablespace out from everything else. I mean, if it's just that
> you are trying to use up the space, fair enough I suppose. But keeping it
> separated out seems to me to be a waste of time. Likewise, TEMP separated
> out is pointless... and sticking it on just one disk is really not good
> practice. TEMP is I/O intensive (usually) and striping it across a lot of
> spindles has got to be a good thing.
>
> But at least the logs are on their own-ish. And that's good.
>
> (Convention normally states that numbers are groups and letters are members,
> so it would be better if you named then Red Logs 1a,2a,3a and 1b, 2b and
> 3b. But that's just a mere detail).
>
> >
> > Note: Disk2 + Disk3 are each 36GB ...so do you think I am
> > UNDERUTILIZING those disk.....?
>
> Yup. Underutilization is something you sometimes have to live with. I recall
> lots of posts about the problem here when disk sizes first started creeping
> up from 8/12GB to 20GB to 40GB to 80GB.
>
> But the usual mantra is 'disk space is cheap and performance is at a
> premium'.
>
> If memory serves, Loney's Gold-Plated disk layout requires a separate disk
> for each Control File (though he quickly acknowledges that 30+GB for a 10MB
> file is just silly!!).
>
> Anyway: that's why I'd bite the bullet, and put as many disks as you can
> into the RAID array, and have done with it.
>
> >
> > Also, I have pushed SYSTEM TBLSPC to my MIRRORED disk0/disk1
> > combination....would there be any issues in that.....? Do I need to
> > MIRROR SYSTEM TBLSPC also.....? In your last reply you mentioned
> > SYSTEM to be in RAID 5 along with DATA....is that OK...? I read
> > somewhere that SYSTEM "should be" separate from DATA.....correct me if
> > I am wrong.
>
> See: you're still caught between two hard places in your mindset. On the one
> hand, you have the Loney approach, which is to separate SYSTEM from DATA,
> those two from INDEXES and everything from UNDO. That's generally sort-of
> good advice, but Loney is working with individual disks, where he is in
> control over what gets co-located with what.
>
> On the other hand, you have the SAME brigade, you say 'bung it all into a
> RAID'. If that's what you do, you lose all control of what gets physically
> co-located with anything else, because it's the RAID's job to sort that out
> for you. You end up with a stripe of SYSTEM data physically next to a
> stripe of DATA data, but that's OK because the whole lot is striped over
> multiple spindles, and thus the I/O is evened out across all disks.
>
> What you seem to be doing is clinging on to some of the Loney approach
> whilst wanting to adopt most of the SAME approach. And that's why I would
> not keep SYSTEM or TEMP out of the RAID... you've abandoned physical
> location control over most of the database, you might as well do it for all
> of it.
>
> Archives deserve a disk on their own, in my view, because they are not
> subject to continual I/O, but are bulk-written at a log switch, and then
> just forgotten about (they are not, in fact, technically part of the
> database at all). But you'll probably batch them up onto tape at some
> point: that maintenance I/O should be kept away from the database files. A
> separate disk/controller would let you do that.
>
> Anyway: strikes me you're getting close.
>
> Regards
> HJR
Received on Fri Sep 19 2003 - 17:10:14 CDT