Hello Howard,
> Hans Forbrich wrote:
>
>> Igor wrote:
>>
>>> Thanks for your comments.
>>>
>>>> If your environment is that susceptible to the disk performance, you
>>>> might also get some benefit from the old (myth-age) style of separating
>>>> tablespaces to separate disk drives & controllers, etc. However, other
>>>> than for keeping someone busy, I would not recommend resurrecting those
>>>> techniques!
>>>
>>> We did so when there was something to separate on, when we had disks,
>>> which where seen/addressable individually. As we passed from single disk
>>> handling (IBM SSA 7133) to Raid5 (IBM FAStT SAN), there of course is not
>>> really much one can address individually. But in fact, we separated rbs
>>> from tmp, data from indexes and so on.
>>
>> From a performance perspective, according to the SAME (stripe and mirror
>> everywhere) supporters there is little, or even negative, benefit to
>> separating indexes from tables, etc.
>
> I can't help it!
>
> That there is no performance difference in separating or not separating
> indexes from tables has got nothing to do with whether you are using SAME
> or not.
>
> Even if Oracle is implemented on JBOD (just a bunch of disks), with
> traditional file systems, and not a whiff of RAID in sight, there is still
> no intrinsic performance degradation from combining indexes and tables in
> one tablespace.
>
> The lack of a performance hit arises from the way tables and indexes
> actually work, not the way they happen to be physically stored.
>
> Of course, SAME adds yet another argument to the 'don't bother for
> performance reasons' school of thought's armoury. But it's not the sole or
> even main reason.
>
> Regards
> HJR
I can't speak about experience from comparison between JBOD vs SAME vs
RAID, it's just -to stick to the "official statement" issues- that Oracle
partner suggested to do so. And when we started there was not much of this
available; of course, as time passed by, things changed and we went
from JBOD to LVM-Mirroring to Raid5 to SAN/Raid5.
But on the issue "the way
tables and indexes actually work" I might give you this comment: We
struggled with manufacturer of the billing software, as they pointed out
poor performance of machine and db. IBM was called for performance test
and tuning, Oracle was called for performance test and tuning. Several
times. Different persons. All of them told us: You can achive 10, 20,
maybe even 30% of performance gain on machine, disk or db tuning issues.
You may gain several tens of % of performance gain when you tune the
application (like selects). One consultant in particular told me to have
worked on a project, where a select lasted about 17 hours, gave good
results, but just after 17 hours. They checked the code and rewrote the
select and went down to ... 1 hour (one). I guess we are all aware, that
application tuning is what makes things go faster. But, unfortunately or
not, it is not my task to check application (or better, someone told
me/senior dba not to do so).
That's about politics.
Have a nice day.
Best regards, Igor
Received on Thu Sep 16 2004 - 07:07:32 CDT
