RE: Reality check for filesystem/disk layout

[Matthew Zito]

Title: Message

 

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: [EMAIL PROTECTED]
Cell: 646-220-3551
Phone: 212-358-8211 x 359
http://www.gridapp.com

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of April Wells
Sent: Friday, September 26, 2003 5:30 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: Reality check for filesystem/disk layout

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-----
From: Paul Baumgartel [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 26, 2003 4:20 PM
To: Multiple recipients of list ORACLE-L
Subject: Re: Reality check for filesystem/disk layout

Jay,

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

--- [EMAIL PROTECTED] 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: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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.