Re: Sizing - RAC, storage subsystem EMC

I'm beginning to think that we're having this wonderful discussion about RAID-5 time and again because the vendors keep coming up with arguments to prove that the general laws of nature don't apply to this particular technology.

In the 50s we had a prime minister here in Denmark that said to the assembled parliament: "If that's the facts, then I deny the facts". Somehow you have to admire a guy like that.

Since disks are now cheap, how on Earth is it that we allow various IO-vendors to bundle cheap disks, expensive cache which we won't need, and stupid technologies like RAID-5 into a box called SAN/NAS or whatever and charge 42 billion units of some real currency for it?

Why don't we take our swords and shotguns and AK-74s (that's the small calibre), and point them at them until they actually just bundle a bunch of inexpensive disks into RAID 1+0 which we ALL know is superior to RAID-S, RAID-5 (notice how S looks like 5 - it's no coincidence). It's superior to RAID 0+1 even. It doesn't require (the expensive) cache either.

One of my wonderful experiences was with a TelCo here, where the vendor kept saying that they should of course just add cache if performance wasn't sufficient. When they finally reached the 32GB (yep, thirty-two giga-bytes) of cache alone, they gave up, ripped the stuff apart and reconfigured it as RAID 0+1 and it finally performed on the small writes. We all loved it - except possibly the disk-vendor, who kept saying RAID-<some letter that resembles the number 5> was of course fantastic, and that they shouldn't listen to all these bitter, old, twisted Oracle people who just hated RAID-5 and the likes ... ahhh... just because!

It's got nothing to do with Oracle or not. It's got to do with money and brains.

RAID 1+0 is the best you can buy.
RAID 0+1 is almost as good.
RAID 5 sucks - in all its disguises and permutations - compared to 0+1 or 1+0.

If RAID-5 is good enough for you, fine. But remember to test the good, old restore of the backup and time it so that you're prepared if it happens. It should of course take about four times as long as the backup.

As Connor said (and Cary has said it in his excellent, but futile, RAID-5 paper) it's when you really, really need disk performance that RAID-5 will let you down.

Yo.

Mogens

Arun Annamalai wrote:

> Hi George.
>
> I would recommend go with Raid 5 and its not that one transaction
> triggers that many writes as you have mentioned/calculated.
> It is all buffered with recovery mechanism.
>
> Have you thought about Raid4(Network appliance) hardware. (I am no way
> affliated with Network appliance, except that we use in our site.)
> Most of the big names use them, such as
> 1, Yahoo. (you can see network appliance logo when you logout of your
> yahoo email account)
> 2. Oracle
> 3. Southwest airlines.
>
> I mean Yahoo, Southwest Airlnes are all heavy transaction oriented
> shop on a given per minute interval.
> The most common overhead of SAN is that the throughput of the switch
> that connects your server to the san storage.
>
> Also, heard that Net App (best in NAS) is colloborating with Hitachi
> (best in SAN storage) to get the best technology for storage and
> thoroughput performance. But this might take a while or might already
> be in the market. Check out with your local Hitachi or Netapp
> representatives.
>
> Hope this helps.
> -Arun.
>
>
> ----- Original Message -----
> From: George.Leonard_at_za.didata.com
> <mailto:George.Leonard_at_za.didata.com>
> To: Multiple recipients of list ORACLE-L
> <mailto:ORACLE-L_at_fatcity.com>
> Sent: Tuesday, May 20, 2003 2:06 AM
> Subject: Sizing - RAC, storage subsystem EMC
>
> Hi all, hope you can give some input ideas.
>
>
>
> I am in the process of designing a system for a client of ours for
> a proposal
>
>
>
> The sizing information I have been given is as follows.
>
>
>
> 58.1 million tickets/day at 351 bytes per record. The record was
> complete populated (all columns filled to max) in a table and then
> analyzed. Average row size 351 bytes.
>
> =~ 19 GB/day. Raw data. Plus overhead (indexes, temp space,
> rollback, some other data etc) here and there I have requested 5 TB.
>
>
>
> We need to keep records for a month. Table design I am looking at
> is a date partition with a second level hash partition. This is so
> that I can move data in the oldest week/table space off line and
> write them to optical storage for possible retrieval at a later
> date (requirement).
>
>
>
> Of course this will be on locally managed table spaces with auto
> storage management for segments.
>
>
>
> Hardware:
>
> The database will be a Oracle RAC 9.2.0.4 on Sun cluster 3 build
> on 2 x Sun StarFire V880, 4 CPU's, 4 GB RAM each,
>
> Connected to an EMC SAN via Fiber Channel
>
>
>
> I do not have more information about the EMC array at the moment.
> Hitachi has been mentioned. (excuse the spelling)
>
>
>
> Question I have.
>
>
>
> I have been asked how many writes the Database will be doing to
> the SAN per second.
>
> I have determined that I should expect about 2000 tickets/second.
>
> The table in question will have 2 indexes.
>
>
>
> Now following rough guessing I said I should expect at least 16
> 000 writes/second
>
>
>
> This was done by say/assuming
>
>
>
> 2 writes for the redo log files (2 members)
>
> 2 writes for the control files (2 control files)
>
> 2 writes to index blocks
>
> 1 write to undo table space block
>
> 1 write to table block for data
>
> total 8 blocks written to per ticket.
>
>
>
> Now I know the above is a real rough. And probably very wrong, if
> someone can shed some more light on it and give me a more accurate
> method/guess I would appreciate it.
>
>
>
> Another question.
>
> The hardware SAN engineers are telling me they want to configure
> the SAN in a RAID 5 configuration. I have requested Raid 0 + 1.
> They say this is going to be to expensive and the new technology
> allows them to give me the performance I want using RAID 5.
>
>
>
> I would prefer to err on the side of caution and follow Oracle
> industry wide recommendation and follow the SAME methodology.
>
> Comment.
>
>
>
> Thx.
>
>
>
> George
>
> ________________________________________________
>
> George Leonard
>
>
>
> You Have The Obligation to Inform One Honestly of the risk, And As
> a Person
>
> You Are Committed to Educate Yourself to the Total Risk In Any
> Activity!
>
> Once Informed & Totally Aware of the Risk, Every Fool Has the
> Right to Kill or Injure Themselves as They See Fit!
>
>
>
>
>
> This email and all contents are subject to the following disclaimer:
>
> "http://www.didata.com/disclaimer.asp"
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: =?windows-1252?Q?Mogens_N=F8rgaard?=
  INET: mln_at_miracleas.dk

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).