Re: Question about Sun disk space configuration for large Oracle database

In the absence of any information about how the database is to be used, it is difficult to make any positive recommendations. However, as a simple rule of thumb, 36GB spindles are too big if you are packing them and accessing all the data - the number of controllers will not be the issue.

A few points on the Oracle strategy -

Generally - make sure that any heavy duty data activity is spread across a reasonable number of spindles.

If the database NEEDS a large space for TEMP then putting is all on just two spindles is a mistake.

If you are doing large exports, and it's a busy database then your shouldn't share export space with archived redo space - archiving is the biggest I/O choke to many Oracle databases.

You don't need to reserve 2 x 36GB of space and waste two spindles for the SYSTEM
tablespace.

(What do you mean by 'rollback for data 1' ? is this 'large rollback brought online for loading data 1' , or just a typo). Rollback is busy - in some systems is accounts for 30% of the
datafile I/O - putting it on two pairs of spindles is a threat.

Why do you wish to differentiate data1 from data2 - it is likely to be an artificial thing. You surely aren't planning to have a single 550GB tablespace for data1, so why make
it a single Raid set ? At 2TB aren't you likely to have some form of date-based partitioning, with entire tablespaces representing a time period - thus breaking the database into more manageable chunks ?

Alternative strategy:
If your SA is correct about 8 disks to an RAID, then go with it. Peel off a bit of space for your system and software, and put the rest into 8-disk RAID sets.

To appease your need for DATA 1, split
use a minimum of 4 RAID controllers and
assign one RAID set per controller as
'belonging to' Data1, and spread all data1 data across it.

Apart from that, let other of your high-level structures share RAID controllers, but don't let structures which could collide on I/O share the same controller. e.g. redo mirror 1 and redo mirror 2 on different controllers, archived redo on a third, and export targets on a fourth. e.g. have 4 rollback tablespaces one per raid controller. If necessary have multiple temp tablespaces, or multiple
tempfiles in one temp tablespace to get
TEMP spread across raid controllers.

Bottom line - think about when, where,
and how big, you I/O is, and don't do
anything that will let it end up on a
small number of discs.

--
Jonathan Lewis

Seminars on getting the best out of Oracle
Last few places available for Sept 10th/11th
See http://www.jlcomp.demon.co.uk/seminar.html




Richard Piasecki wrote in message <3b7084a6$0$249$45beb828_at_newscene.com>...


>Greetings.

>

>I am currently developing the physical disk space layout for a large Oracle

>database (over 2 terabytes of disks), and I wish to solicit some opinions

 as


>to how to make this work. My configuration calls for each Oracle tablespace

>to be placed on separate RAID 0+1 arrays. Each RAID array would be

>controlled

>by its own RAID controller. There are 13 such arrays and the largest of

>these

>arrays needs to be at least 550 Gigs. The system administrator with whom I

>am working on this project has reviewed Sun hardware specs and has come to

>the conclusion that 13 RAID controllers is not do-able. Instead, he

>recommends using fewer RAID controllers and allowing each one to control

>multiple arrays. I am primarily concerned with reducing I/O contention for

>the Oracle tablespace files and wonder if a single RAID controller can

>handle

>multiple requests for different arrays in parallel. There is another

 problem


>in that, according to his analysis, each RAID 0+1 array can accomodate, at

>most, 8 disks. Assuming 36 gig disks, this would mean that the largest size

>of a single RAID 0+1 array would be 144 gigs (4x36), significantly less

 than


>my 550 gig target. Below, you will see my proposed physical layout for each

>partition and its use. My questions for the Sun/Oracle experts are as

>follows...

>

>1) If I allow a single RAID controller to handle multiple arrays, how can

>   I minimize I/O contention to those arrays. Can a single RAID controller

>   handle multiple requests to different arrays in parallel?

>2) How do I set up a partition of 550 gigabytes? Can a single array be

>   composed of 32 disks (assuming RAID 0+1 with 36 gig disks)?

>3) Specifically for the Oracle DBAs, would you recommend any changes to

>   the proposed configuration to improve performance?

>4) If you were in my shoes, how would you do it? What specific Sun hardware

>   should be used?

>

>My company's upper management does not have the time right now (due to a

>very tight product development schedule) to bring in Sun reps to get

>answers to these questions, so I greatly appreciate whatever assistance

>the USENET community can provide.

>

>

>PROPOSED CONFIGURATION

>----------------------

>

>Dir    Size     Usage                       Recommendation

>----   -----    -------------------------   -----------------

>/      50 GB    All system software         Four(4) 36 GB dsks RAID 0+1

>/u01   2 GB     First Online Redo Logs      Part of root (/)

>/u02   2 GB     System tablespace           Two(2) 36 GB dsks RAID 0+1

>/u03   6 GB     Temporary tablespace        Two(2) 36 GB dsks RAID 0+1

>/u04   100 GB   Archived redo & exports     Six(6) 36 GB dsks RAID 0+1

>/u05   2 GB     Second Online Redo Logs     Two(2) 36 GB dsks RAID 0+1

>/u06   8 GB     Rollback for Data 1         Two(2) 36 GB dsks RAID 0+1

>/u07   8 GB     Rollback  segments          Two(2) 36 GB dsks RAID 0+1

>/u08   80 GB    Indexes for Data 1          Six(6) 36 GB dsks RAID 0+1

>/u09   550 GB   Data 1                      Thirty-two(32) 36 GB dsks RAID

>0+1

>/u10   12 GB    Indexes for Data 2          Two(2) 36 GB dsks RAID 0+1

>/u11   60 GB    Data 2                      Four(4) 36 GB dsks RAID 0+1

>/u12   4 GB     Indexes for Data 3          Two(2) 36 GB dsks RAID 0+1

>/u13   8 GB     Data 3                      Two(2) 36 GB dsks RAID 0+1

>

>

>