Gaja
Would you be able to send me your presented paper.
Thanks much
mcg
- Gaja Krishna Vaidyanatha <gajav_at_yahoo.com> wrote:
> Ganapathi,
>
> Yes, the number of spindles does matter even with a
> 2Gb cache.
> Actually a 2Gb cache may not that much depending on
> the volume
> of transactions in your environment. We have seen
> 16Gb caches in
> very heavy transactional environments getting
> saturated. So a
> cache can only take you so far. So for example,
> don't pick RAID5
> for write-intensive applications just because you
> have a 2Gb
> cache. The cache can vanish in a hurry and your
> system may
> experience significant I/O waits caused by the
> parity
> calculations.
>
> For the sake of our discussion, a spindle is a
> physical disk
> (just so that we are on the same page). Obviously,
> when you
> create any logical volumes and implement some level
> of RAID on
> it, we will treate the entire volume as 1 spindle,
> as it will be
> uniquely identified as i device (unless you start
> slicing and
> dicing at the logical volume level and then mount
> multiple file
> systems on the same set of drives...not a good way
> to design
> your I/O sub-system).
>
> You also need to look at your database layout from a
> size
> perspective, database partitioning requirements,
> parallelism
> requirements and availability requirements (do you
> need partial
> availability of data, if you did suffer from
> multiple media
> failures).
>
> Don't buy the story from anyone who says the
> following - 'create
> 1 huge volume, put everything on it, and we will
> take care it'
> (the concept of thin wide striping). Magic will not
> happen with
> disks regardless of the vendor and when your batch
> jobs kick in
> and perform range scans on your huge indexes, your
> system might
> experience significant I/O waits, if your DATA and
> INDX
> tablespaces are on the same set of physical drives.
> We have seen
> this happen with uncanny accuracy at many sites and
> doing
> something simple such as moving the INDX datafiles
> to a separate
> volume does wonders.
>
> Use the usual DBA101 placement rules - separate DATA
> and INDX,
> separate redo logs etc. You may want to download a
> paper I
> presented on 'Implementing RAID on Oracle Systems'
> at OOW 2000.
> This has more detail than what I can write here.
> Understand what
> each level of RAID offers and then choose the right
> level based
> on your applications's I/O patterns and the number
> of users. As
> you can see, the answers to your question are
> multi-faceted and
> complex. Enjoy the ride! May the force be with you!
>
> Cheers,
>
> Gaja
>
>
> --- Ganapathi Kesavelu <k7g_at_yahoo.com> wrote:
> >
> > We are looking for a storage option. Here are
> the
> > specs
> >
> > O/S Digital Unix 4.0D (upgraded to 4.0G)
> > Tru Cluster 1.5 (upgraded to 1.6)
> > Oracle 7.3.4 with OPS (upgraded to 8.1.7)
> > Database will be around 100G (24x7 system)
> >
> > The sales guys from EMC and Hitachi have met us.
> EMC
> > is proposing a 8430 . Hitachi is considering 7700E
> and
> > 9900.
> >
> > Does the number of spindles matter in case of
> disk
> > array (2GB of cache)
> >
> > I'll be grateful if you can give your experiences
> or
> > advices with these products
> > Thanks in Advance
> >
> > Thanking you
> > GK
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Calendar - Get organized for the holidays!
> > http://calendar.yahoo.com/
> > --
> > Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> > --
> > Author: Ganapathi Kesavelu
> > INET: k7g_at_yahoo.com
> >
> > Fat City Network Services -- (858) 538-5051
> FAX: (858)
> > 538-5051
> > San Diego, California -- Public Internet
> access /
> > Mailing Lists
> >
>
> > 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).
>
>
> =====
> Gaja Krishna Vaidyanatha
> Director, Storage Management Products, Quest
> Software Inc.
> Office : (972)-304-1170, E-mail : gajav_at_yahoo.com
>
> Author - Oracle Tuning 101 by Osborne McGraw-Hill
> "Opinions and views expressed are my own and not of
> Quest"
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Calendar - Get organized for the holidays!
> http://calendar.yahoo.com/
> --
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> --
> Author: Gaja Krishna Vaidyanatha
> INET: gajav_at_yahoo.com
>
> Fat City Network Services -- (858) 538-5051 FAX:
> (858) 538-5051
> San Diego, California -- Public Internet
> access / Mailing Lists
>
> 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
Received on Tue Nov 14 2000 - 12:34:38 CST
