From: "Jonathan Lewis" Newsgroups: comp.sys.sun.hardware,comp.databases.oracle.server Subject: Re: Question about Sun disk space configuration for large Oracle database Date: Wed, 8 Aug 2001 18:19:14 +0100 Message-ID: <997290987.4320.0.nnrp-01.9e984b29@news.demon.co.uk> References: <3b7084a6$0$249$45beb828@newscene.com> NNTP-Posting-Host: jlcomp.demon.co.uk X-NNTP-Posting-Host: jlcomp.demon.co.uk:158.152.75.41 X-Trace: news.demon.co.uk 997290987 nnrp-01:4320 NO-IDENT jlcomp.demon.co.uk:158.152.75.41 X-Complaints-To: abuse@demon.net X-Newsreader: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Lines: 154 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@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 > > >