The main problem as I see it is that you might be
lucky in getting IO balance with a
tables-here-indexes-there approach in rule based
databases, where pretty much the only thing Oracle can
do is table scan and single block index read.
But since 7.3, and even more so with the more recent
releases,
: Re: oraperf comment
Yechiel,
You had mentioned only one possible scenario
(i.e. "user A accesses table while user B simultaneously accesses index")
where there are several other possible, equally-likely scenarios (i.e. "user A
accesses table while user B simultan
: oraperf comment
Ray,
I don't know exactly what was intended with the
comment, but I agree with your interpretation.
---
As far as any other reasons for the
comment...
RANT
In terms ofmyths that have persisted with
Oracle over the years, the ideathat some performance
me as i'm looking for guidance.
=)
-Original Message-From: Yechiel Adar
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, October 22, 2002 5:44
AMTo: Multiple recipients of list ORACLE-LSubject: Re:
oraperf comment
Hello Tim
I beg to differ. Without raid it is better to put
i
...resending, as the original send encountered some
kind of "locking problem" at fatcity...
- Original Message -
From: Tim Gorman
To: [EMAIL PROTECTED]
Sent: Tuesday, October 22, 2002 6:35 AM
Subject: Re: oraperf comment
Why?What are the chances of
preciselythat scenari
Tim,
point well said. Thank you.
-Original Message-From: Tim Gorman
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, October 22, 2002 11:15
AMTo: Multiple recipients of list ORACLE-LSubject: Fw:
oraperf comment
...resending, as the original send encountered
some kind
To: Multiple recipients of list ORACLE-L
Sent: Tuesday, October 22, 2002 5:14
PM
Subject: Fw: oraperf comment
...resending, as the original send encountered
some kind of "locking problem" at fatcity...
- Original Message -
From: Tim Gorman
To: [EMAIL PROTECTE
:
Markham, Richard
To: Multiple recipients of list ORACLE-L
Sent: Tuesday, October 22, 2002 5:03
PM
Subject: RE: oraperf comment
I'm a little confused when one is talking about putting indexes and
tables into seperate TABLESPACES and the other is talking about seperate
DISKS
:
Sent by: Subject: RE: oraperf comment
[EMAIL PROTECTED
To: Multiple recipients of list ORACLE-L
Sent: Tuesday, October 22, 2002 3:43 AM
Subject: Re: oraperf comment
Hello Tim
I beg to differ. Without raid it is better to put indexes and tables on different
disks and controllers.
This way Oracle can do I/O to a table for user A while
whether they are tables or indexes, one can make better determinations on how to
distribute I/O across non-RAID devices.
Hope this helps...
-Tim
- Original Message -
From:
Yechiel
Adar
To: Multiple recipients of list ORACLE-L
Sent: Tuesday, October 22, 2002 10
Yechiel,
You had mentioned only one possible scenario (i.e. user A accesses table while user
B simultaneously
accesses index) where there are several other possible, equally-likely scenarios
(i.e. user A accesses
table while user B simultaneously accesses table, user A accesses index
An recent oraperf report included the comment: Never split index
and data files to different sets of disks. It goes on to state that
striping is better. If the system in question does not have
raid support, wouldn't it be better to split the index and data across
spindles? That would make the
e different blocksizes are possible for different
tablespaces
These last points are related to performance, but
not in the sense that the mythical"conventional wisdom"
dictates...
Hope this helps...
-Tim
- Original Message -
From: "Ray Stell" [EMAIL PROTECTED]
To: &q
PROTECTED]
cc:
Subject:oraperf comment
An recent oraperf report included the comment: Never split index
and data files to different sets of disks. It goes on to state that
striping is better. If the system in question does not have
raid support, wouldn't it be better
15 matches
Mail list logo
