RE: Reality check for filesystem/disk layout

On hardware arrays, its basically impossible for anything more complex than straight mirroring. Since you can usually only lay out raid groups by individual disks, the "disk" you get back from a 0+1 set is a blend of disks, and its hard to say where the actual "outside" and "inside" of a disk are. With an LVM, you create subdisks based on where you define the outside, inside, and middle of your RAID-1 volumes, and then create plexes that stripe across just the outside, just the inside, etc.  

Matt

--
Matthew Zito
GridApp Systems
Email: mzito_at_gridapp.com
Cell: 646-220-3551
Phone: 212-358-8211 x 359
http://www.gridapp.com <http://www.gridapp.com/>  

-----Original Message-----
April Wells
Sent: Friday, September 26, 2003 5:30 PM
To: Multiple recipients of list ORACLE-L



I would like to know what you are striping this on, too.  Sounds solid, but
how can I gain that much control of where things end up physically (center,
outside...) on Shark?  I envy you being able to convince everyone that Raid
5 isn't the be all and end all solution... but we HAVE to raid 5 it... with
hot swap disks in ever rank.

April Wells 
Oracle DBA/Oracle Apps DBA 
Corporate Systems 
Amarillo Texas 
  /\ 
 /   \ 
/     \ 
\     / 
  \/ 


  >\< 

     \ 
     >\< 
         \ 
Few people really enjoy the simple pleasure of flying a kite 
Adam Wells age 11 



-----Original Message----- 
Sent: Friday, September 26, 2003 4:20 PM 
To: Multiple recipients of list ORACLE-L 


Jay, 

I'd like to see (for my enlightenment) a brief rationale for your 
decisions, if you have time.  Thanks! 

--- JayMiller_at_tdwaterhouse.com wrote: 
> We have the luxury of moving a 300G database to a new box that's 
> being built 
> and choosing the specifications, disk layout, striping, etc.  After 
> spending 
> the morning poring over Cary Millsap's wonderful VLDB  paper this is 
> what 
> we're thinking of but I'd appreciate any comments. 
>  
> One of my main goals going in was separating redo logs into 2 sets of 
> disks 
> and archive logs on a third. 
>  
> We have 16 disks to play with and seem to be winning the 1+0 battle 
> against 
> some SAs who don't understand why we wouldn't want to use RAID5. 
>  
> The database has minimal write activity during the day (other than 
> sorts to 
> the temp tablespace) but huge batch write activity at night and 
> especially 
> at the end of the month (the data load time is enough of a problem 
> that the 
> few partitioned tables we can easily reload are doing unrecoverable 
> loads). 
> There is a lot of read activity during the day, both single row 
> queries from 
> front ends that are rolled out to several thousand people and reports 
> that 
> can do some large sort/merge joins. 
>  
> Here's what we were thinking: 
>  
> 1st Disk Set - 4 72M disks RAID 1+0 
>  
> 1st and 3rd redo log on outside 
> Misc. Datafiles in middle 
> Misc scripts and files used by other departments in center 
>  
> 2nd Disk Set - 6 72M disks RAID 1+0 
> Archive logs on outside 
> Temp tablespace and misc. datafiles in middle 
> Text files used for loading in center 
>  
> 3rd Disk Set - 6 72M disks RAID 1+0 
> 2nd and 4th redo logs on outside 
> Rollback tablespace and misc datafiles in middle 
> /oracle (executables and some scripts) in center 
>  
>  
> I was debating if there was any advantage in varying stripe sizes 
> across the 
> different disk sets (since I know Cary says redo logs like fine 
> grained 
> stripe sizes) but given the mix of uses for each that doesn't seem 
> viable. 
>  
>  
> Comments, suggestions or even productive questioning of my sanity 
> would be 
> appreciated. 
>  
>  
> Thanks, 
> Jay Miller 
>  
> 


===== 
Paul Baumgartel 
Transcentive, Inc. 
www.transcentive.com 

__________________________________ 
Do you Yahoo!? 
The New Yahoo! Shopping - with improved product search 
http://shopping.yahoo.com 
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net 
-- 
Author: Paul Baumgartel 
  INET: treegarden_at_yahoo.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). 


The information contained in this communication, including attachments, is
strictly 

confidential and for the intended use of the addressee only; it may also
contain 

proprietary, price sensitive, or legally privileged information. Notice is
hereby given that 

any disclosure, distribution, dissemination, use, or copying of the
information by anyone 

other than the intended recipient is strictly prohibited and may be illegal.
If you have 

received this communication in error, please notify the sender immediately
by reply e-mail, 

delete this communication, and destroy all copies.

 



Corporate Systems, Inc. has taken reasonable precautions to ensure that any
attachment to 

this e-mail has been swept for viruses. We specifically disclaim all
liability and will 

accept no responsibility for any damage sustained as a result of software
viruses and advise 

you to carry out your own virus checks before opening any attachment.





-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Matthew Zito
  INET: mzito_at_gridapp.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).