Re: 30 instances on one host

On Sun, 23 Jun 2002 19:44:02 +1000, Howard J. Rogers <dba_at_hjrdba.com> wrote:
>
>"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);
>> >
>> > 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.

He did say that, but that was part of a different rule of separating things with different fragmentation characteristics. Remember, this was a cookbook and would necessarily have some overgeneralizations. Overall, I found it the best book at the time for actually getting things done. Which book did you use at the time?

Sorry, I missed the stuff on this newsgroup about where Ault didn't know what he was talking about in the 7.0 timeframe.

And my experience at the time on the hardware available was that data and indexes would contend for disk resources, since you would often be using an index to determine what data to get, and if you put them on different disks you'd get better performance. You could hear it from the disks going clackity-clackity, not to mention timing.

>>
>> 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?

So you were talking to Cary about 7.0 performance issues? Cool! What did he have to say?

When I saw him he was only talking about new stuff. Of course, at that time everyone was saying how great 9R2 was going to be, fixing all those pesky bugs that just happened to be showing up in the first release, that nobody ever expected. Gee, quality at the top of the list! Who'da thunk?

jg

-- 
These opinions are my own. 
http://www.garry.to                                       Oracle and unix guy.
mailto:joel-garry_at_nospam.cox.net                       Remove nospam to reply.