Re: Physical Layout of disk to use Oracle

Hari Om wrote:

> I am using Oracle 9.2.0.1 on IBM AIX 5.1L box.
> My box has 8 different hard disk hdisk0-hdisk7.
>
> hdisk0 + hdisk1 are mirrored and house System ROOT BOS.
> That leaves me to 6 hard disk hdisk2-hdisk7.
> hdisk0 and hdisk1 both are 18GB each
> hdisk2-hdisk7 are each 36GB
>
> I was wondering what would be the best way to utilize these disk taking
> into consideration following points:
> 1) Contention Problems i.e.: 2 different process using the same disk and
> one
> has to wait.
> 2) Speed - without having any process having to wait a longer.
>
> I have read Kevin Loneys' ORACLE DBA Handbook and read a chapter on
> Physical Database Layouts. Here is what I get....correct me if I am wrong.
>
> hdisk2 --> Oracle Appplication Software
> hdisk3 --> SYSTEM Tablespaces(for all instances) + Control File 1
> hdisk4 --> ROLLBACK Tablespace + Redo Log files + Control File 2
> hdisk5 --> DATA Tablespace + Control File 3
> hdisk6 --> INDEX Tablespace + TEMP Tablespace
> hdisk7 --> ARCHIVE Redo Log destination disk.
>
> Can anyone point out if there would be any issues in the above Layout.
> Please feel free to be as critical as possible....after all I learn
> from my mistakes only.
>
>
> THANKS!
No real advice this time... except that you're going to get a lot of people telling you to "Stripe and Mirror Everything" (SAME), and before you take that advice (which is certainly an easy approach), you might care to check out www.ixora.com.au, and see what Steve Adams has to say on the subject.

Oh alright then, I'll give you a precis:

I/O response time consist of waiting and service time. SAME probably eliminates waiting time, but randomizes all I/O and thus makes service times uniform... and that service time is probably higher than it might have been, because with all your I/O being randomised everywhere, you have no localisation of data... so your seek time creeps up. To hide that, you employ lots of caching and asynchronous prefetching.

You can read the details at Steve's site.

He makes the point that SAME is advocated not for any intrinsic technical merit, but because it's blindingly simple to implement and requires very little DBA skill. It also has a big downside: if your storage needs grow, how do you anticipate adding the extra disks into the stripeset? Without a large re-organisation, it's going to be tricky... and hence SAME can be inflexible.

Still, if simple is what you want, and there are no DBA skills you want to acquire, go for it.

Regards
HJR Received on Mon Sep 15 2003 - 15:12:17 CDT