Re: Sizing - RAC, storage subsystem EMC

Good points. When I read your arguments I couldn't help smiling because I saw the headline of this thread at the same time. If this is the time for doing without, isn't it funny that people invest in RAC? Heh-heh.

Mogens

Rachel Carmichael wrote:

>Here's the thing. Disks are cheap. Maybe. But buying 5 disks is still
>cheaper than buying 10 disks. And it is NOT the people who actually
>work with the disks (DBAs, Sysadmins, even developers) who have the
>authority to order the disks.
>
>You need places and floor space to put the disks as well. It's not like
>you can just hang them from the ceiling.
>
>And even more so these days, and it seems most especially in the US
>companies, companies are trying to cut costs to the bone (we just went
>through an exercise where we practically had to jump through hoops just
>to get more memory for a production system which obviously needed the
>memory). And cutting costs means as few disks as possible, means reuse,
>consolidate and do without.
>
>It kind of reminds me of one of the sayings my parents (who grew up
>during the Great Depression here) have told me of that time: "use it
>up, make it do, or do without"
>
>we're in the "do without" phase
>
>Rachel
>--- Mogens_Nørgaard <mln_at_miracleas.dk> wrote:
>
>
>>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
>>>
>>>
>>>
>=== message truncated ===
>
>
>__________________________________
>Do you Yahoo!?
>The New Yahoo! Search - Faster. Easier. Bingo.
>http://search.yahoo.com
>
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: =?ISO-8859-1?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).