Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Sizing - RAC, storage subsystem EMC

RE: Sizing - RAC, storage subsystem EMC

From: Cary Millsap <cary.millsap_at_hotsos.com>
Date: Thu, 22 May 2003 08:56:44 -0800
Message-ID: <F001.005A01A0.20030522085644@fatcity.com>


> I've yet to see anyone give a benchmark result which
> showed that table and index separation gave any
> noticeable benefit (san, cache, or otherwise).

I totally agree. However, from an historical perspective, by accident some of my work may be the reason people think they have to put their indexes and data on different devices. In the OFA Standard document I wrote in the early 1990s, I wrote that there are three requirements that drive how one should separate one's segments into different tablespaces (OFA Standard, pp13-14):

  1. fragmentation character
  2. I/O distribution
  3. administrative needs

I recommended separating data and indexes into separate *tablespaces* (which is not to say different devices). Index segments should be put into separate tablespaces from data segments predominantly for reasons 1 and 3. Reason 2 ranks a distant third (indexes are dropped and rebuilt much more often than tables, and indexes should probably have different storage parameters and backup schedules than tables). The tablespace separation recommendation allows you to distribute table vs. index I/O, but I/O distribution was *not* the prime reason that I recommended separating indexes and data into different tablespaces.

I'd encourage you guys to believe Connor, for sure, but don't mistake his point to mean that it's a good idea all of a sudden to start mixing index segments and data segments in the same tablespace.

Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com

Upcoming events:
- Hotsos Clinic 101 in Reykjavik, Ottawa, Dallas, Washington, Denver, Sydney - Visit www.hotsos.com for schedule details...

-----Original Message-----
McDonald
Sent: Wednesday, May 21, 2003 11:12 AM
To: Multiple recipients of list ORACLE-L

I've yet to see anyone give a benchmark result which showed that table and index separation gave any noticeable benefit (san, cache, or otherwise).

Conversely, I have seen systems where judicious separation of certain segments helped enormously, probably the most common in my (limited) experience being partitions setup in different stripes to maximise large scale parallel scan performance. (The improvement was in comparison to SAME btw)

Sensible I/O separation to maximise throughput is a good thing to have - if that ends up being data and indexes separate then so be it, but I would contend its probably very unlikely to be the norm.

Similarly, having a big cache will help with some things, but not all...eg if you're backing a database disk-to-disk, then when it comes down the crunch, it pure disk performance thats going to matter.

Going back to the original post on raid 0+1 versus raid 5, its not raid-5 during normal operation that bothers me (cache and other smarts can hide the overhead quite well)...Its what happen when you lose a disk...Just when you're most vulnerable, your I/O performance takes a bullet to the head.

hth
connor


Connor McDonald
web: http://www.oracledba.co.uk
web: http://www.oaktable.net
email: connor_mcdonald_at_yahoo.com

"GIVE a man a fish and he will eat for a day. But TEACH him how to fish, and...he will sit in a boat and drink beer all day"



It's Samaritans' Week. Help Samaritans help others. Call 08709 000032 to give or donate online now at http://www.samaritans.org/support/donations.shtm
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: =?iso-8859-1?q?Connor=20McDonald?=
  INET: hamcdc_at_yahoo.co.uk

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Cary Millsap
  INET: cary.millsap_at_hotsos.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Thu May 22 2003 - 11:56:44 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US