Re: 30 instances on one host

"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);
>
> Well, as we've seen on this newsgroup, this doesn't stand up, and Ault
> doesn't/didn't know what he was talking about. If he'd said tables and
> rollback segments, fair enough.

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?

jg

--
@home is bogus