Re: Physical Layout of disk to use Oracle

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 Thu Sep 18 2003 - 15:19:17 CDT