I beg to differ. I am not so sure whether what you are
suggesting is even feasible on most VLDB environments
today. Imagine if you have to implement at 2TB hybrid
database with 500 datafiles on a RAID 1, you will have
to individually maintain a large number of
"independent RAID 1 logical volumes". It will become a
management nightmare.
OK, agreed that you are trying to achieve I/O
isolation, but you are giving up big time on the
ability to "divide and conquer", that a striped volume
provides, both for "reads and writes". If 1 disk drive
supports 100 IOPS, then a 4-way striped volume on
independent disks will provide 400 IOPS, assuming that
your controller has enough bandwidth. When implemented
as a RAID 1+0, the throughput is 800 IOPS. A single
drive failure will result only in a 12.5% loss in
IOPS, for that RAID 1+0 logical volume. This number is
progressively halved, when each time you double the
"degree of striping".
If everything is implemented as RAID 1 in an
environment, then assuming 20 Mb/sec. data transfer
rates and 100 IOPS throughput rate per disk, you will
never be able to achieve more than 40 Mb/sec. or 200
IOPS on any of your logical volumes. The single disk
failure will result in a 50% loss in IOPS for that
RAID 1 logical volume.
Can you guarantee yourself that this bandwidth (with
or without the loss of the 1 disk drive) will always
be sufficient? What if one of the partitions in the
partitioned table, grows and becomes much larger than
the others? It is a lot easier to deal with the growth
at the I/O sub-system level, rather than manually
managing I/O on a per mirrored disk level and/or
re-partitioning the table because the amount of data
stored in 1 database partition is much larger than
others.
I am not suggesting that one gives up complete
physical placement control by configuring 1 logical
volume with all available drives (a' la SAME). But we
need to strike a balance between what SAME suggests
and the pure "RAID 1 only" environment. With only RAID
1 volumes, you may end up with partition-level segment
hotspots (assuming that you have implemented
table/index partitioning as you suggested) and will
not have much leeway to do anything about it.
Configuring multiple RAID 1+0 logical volumes,
provides the required flexibility and "physical
independence" for balancing the I/O load on your
system. That along with one or more RAID 3/5 logical
volumes (as appropriate) for the "read-intensive"
components of your database, should be strongly
considered, as maintaining 100s of logical volumes
that are "only mirrored" may not provide the necessary
flexibility, throughput and scalability for the I/O
system. That in turn affects the throughput for the
database and finally the throughput for the
application. Striping is a significant feature that is
available in today's disk sub-systems and it will be a
shame to let it go like that.
Best regards,
Gaja
- Charlie Mengler <charliem_at_mwh.com> wrote:
> I believe RAID-1+0 has more cost than benefit.
> I want to see & measure total I/O's to each spindle.
> While RAID-1 has higher cost to maintain, it gives
> me maximum flexibility to evenly distribute I/O
> loads.
> I contend that with proper table partitioning I can
> achieve & sustain higher I/O rates with RAID-1 than
> can be gotten from RAID-1+0.
>
> HTH & YMMV
>
> HAND!
>
> John.Dailey_at_ing-fsi-na.com wrote:
> >
> > Thanks for all the replies. We are determined
> to lay out the data as
> > well as we can across the disks we are about to
> purchase - with the goal of
> > striping across array groups and smaller, faster
> drives. The real
> > argument for us is 18GB vs. 73GB disk drives and
> how we can stripe. The
> > Hitachi is configured into groups of 4 physical
> disks called "parity
> > groups" and you can choose RAID 5 or RAID 1+0 for
> that 4 disk set. If
> > you have 73GB drives in a 4-disk RAID 5
> configuration you get roughly 219GB
> > of usable space in each parity group (this is what
> we are being told is the
> > best option for us). This means our heavily
> concurrently accessed 400GB
> > production database goes on 2 parity groups (2
> sets of 4 disks). To
> > me, this sounds like a nightmare waiting to happen
> and we are trying to
> > stop it. The 18GB drives are less capacity but
> we can get ourselves
> > spread over more parity groups for better
> concurrency. We do have about
> > 10GB of cache but it is being shared across the
> enterprise with various
> > other applications. We as a DBA group are
> really trying to sell the
> > 18GB RAID 1+0 drive solution especially after
> reading the groups'
> > experiences - unfortunately we are fighting a lot
> of marketing hype.
> >
> > If anyone has additional experiences or feedback
> with Hitachi or EMC they
> > would like to share or comments (agree/disagree)
> with my thoughts, I'd love
> > to hear them. I'm open for learning!
> >
> > Thanks,
> >
> > John Dailey
> > Oracle DBA
> > ING Americas - Application Services
> > Atlanta, GA
> >
> >
> > "Don
> > Granaman" To:
> Multiple recipients of list ORACLE-L
> <ORACLE-L_at_fatcity.com>
> > <granaman_at_cox cc:
> > .net> Subject:
> Re: disk subsystem performance question
> > Sent by:
> > root_at_fatcity.
> > com
> >
> >
> > 04/10/2002
> > 01:08 PM
> > Please
> > respond to
> > ORACLE-L
> >
> >
> >
> > Short answer - NO! Nobody's disk subsystem is so
> fast that no intelligence
> > is required in the layout. This is common vendor
> blather and one of the
> > most popular myths. I have been hearing it for at
> least six years - and it
> > still isn't true. Layout still makes a huge
> difference. RAID levels still
> > make a huge difference. Cache won't solve all
> your problems (it does help
> > though). I've redone the disk layout on some of
> the biggest, fastest
> > fully-loaded with cache EMC Syms available that
> had some "don't worry about
> > it" layout and seen database throughput go up by
> as much as 8x.
> >
> > See Gaja's whitepaper on RAID at
> http://www.quest.com/whitepapers/Raid1.pdf
> > .
> >
> > Don Granaman
> > [certifiable oraSaurus]
> >
> > ----- Original Message -----
> > To: "Multiple recipients of list ORACLE-L"
> <ORACLE-L_at_fatcity.com>
> > Sent: Wednesday, April 10, 2002 10:38 AM
> >
> > > Hi all,
> > >
> > > We are running both a Hitachi 7700E and a 9960
> disk subsystem here and we
> > > are getting ready to move our production DBs
> from the old(7700E) to the
> > > new(9960) Hitachi. We have had trouble in
> the past on the 7700E due
> > to
> > > disk contention and layout, i.e. we weren't
> striped across the array
> > groups
> > > very well.... this caused pretty poor I/O
> performance. This has
> > been
> > > a learning experience for the DBAs and the SAs
> here for the logical vs.
> > > physical aspects of our disks. Anyway, to
> make a long story short,
> > we
> > > are ordering disk for the move to the 9960 and
> we have 2 choices in disk
> > > sizes - 18GB and 73GB, and 2 choices in RAID -
> 1+0 and 5. I would
> > like
> > > to get the smaller, faster 18GB drives in a RAID
> 1+0 configuration and
> > > stripe our data across the array groups as wide
> as possible. However,
> > I
> > > am running into objections from the Hitachi
> people that their system is
> > > "soooo fast we need not worry about such minor
> details". I'm having a
> > > hard time believing that given our I/O problems
> on the 7700E.
> > Performance
> > > is given a high priority here.
> > >
> > > What I would like to know is others' experience
> with disk subsystems -
> > > specifically Hitachi but EMC and others as
> well.... have you been able
> > to
> > > "throw the disk in and forget it" or have you
> had success in getting to
> > the
> > > dirty details? Have you tested or noticed
> an improvement with
> > smaller,
> > > faster drives in a disk subsystem like the
> Hitachi or have you traveled
> > > that path and found no noticeable improvement?
> I'm looking for
> > either
> > > a) ammunition that my view is correct, or b) I'm
> wrong and we can get
> > > bigger drives which will make Enterprise
> Planning very happy from a $$$
> > > standpoint because our Hitachi capacity will
> last longer.
> > >
> > > We are running Oracle 8.1.7 / AIX 4.3.3 /
> Peoplesoft Financials version
> > 8.
> > > 2 production databases , one 400 GB and the
> other about 1TB. We've
> > got
> > > some other production DBs but these are our big
> guys.
> > >
> > > Thanks in advance for any and all input - any
> help is greatly
> > appreciated.
> > > I'd be happy to share any info we have found up
> to this point and our
> > > experiences on the 7700E as well if anyone is
> interested - despite the
> > fact
> > > I will probably bore you to death :-)
> > >
> > > John Dailey
> > > Oracle DBA
> > > ING Americas - Application Services
> > > Atlanta, GA
> > >
> > >
> > >
>
=== message truncated ===
Gaja Krishna Vaidyanatha
Director, Storage Management Products,
Quest Software, Inc.
Co-author - Oracle Performance Tuning 101
http://www.osborne.com/database_erp/0072131454/0072131454.shtml
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Gaja Krishna Vaidyanatha
INET: oraperfman_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).
Received on Thu Apr 11 2002 - 17:38:35 CDT
