Re: 30 instances on one host

"Joel Garry" <joel-garry_at_home.com> wrote in message news:91884734.0206222315.17c129a3_at_posting.google.com... > "Howard J. Rogers" <dba_at_hjrdba.com> wrote in message news:<aes178$t8s$1_at_lust.ihug.co.nz>...
> > "Joel Garry" <joel-garry_at_nospam.cox.net> wrote in message
> > news:slrnah2ro0.ho.joel-garry_at_zr1.vista1.sdca.cox.net...
> > > On Tue, 18 Jun 2002 04:01:17 GMT, Sean M <smckeown_at_earthlink.net>
wrote:
> > > >Alan wrote:
> > > >>
> > > >> For example, OFA asks the DBA to place software on a mount point
> > > >> separate from the data mount points. The faulty logic behind this
is
> > > >> that it will separate I/O and thus boost performance. The truth is
> > > >> that the software mount point will generate relatively little I/O;
the
> > > >> software mount point would be quiet and the data mount points would
be
> > > >> busy. So, a DBA following this advice would not optimize the I/O
> > > >> potential of the host.
> > > >>
> > > >> The OFA advice on mount points also holds little water when viewed
> > > >> from the perspective that on most decent sized UNIX boxes, I/O
> > > >> spreading is now done inside the storage array. The days of having
a
> > > >> mount point logically connected to a disk partition's address are
> > > >> gone. OFA was written for systems built before the proliferation
of
> > > >> disk volume management software like Veritas.
> > > >
> > > >This is not accurate. OFA is designed to address managability of
Oracle
> > > >isntallations by providing guidelines for naming conventions and the
> > > >like. It is not designed to address performance. The reason to
> > > >separate Oracle software is not for performance, but for
managability.
> > >
> > > It was indeed explicitly about performance, when the idea was to split
> > > I/O among physical disk devices. Eventually the reasons were watered
down
> > > as it became cookbooked to /u001.../unnn, and completely stupid as
modern
> > > storage hardware became prevalent. I just grabbed the old 7.0 Ault
book
> > p. 12,
> > > summarizing 2 of the 3 rules of the OFA process have performance
> > implications;
> > > includes separating groups of segments that will contend for disk
> > resources
> > > (e. g. data and indexes);

> >

>
> How about reading the first sentence of this Abstract:
> http://www.orapub.com/cgi/genesis.cgi?p1=sub&p2=abs106
>
> Now, what part of "faster" do you not understand?
>

Well, having spoken to Cary not so very long ago, what part of 'you don't separate tables from indexes for performance reasons' don't *you* understand?

HJR

> jg
> --
> @home is bogus