Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Sizing - RAC, storage subsystem EMC

Re: Sizing - RAC, storage subsystem EMC

From: Arun Annamalai <oracle_at_shakaboom.com>
Date: Wed, 21 May 2003 13:48:22 -0800
Message-ID: <F001.0059F353.20030521134822@fatcity.com>


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.

  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: Arun Annamalai
  INET: oracle_at_shakaboom.com

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). Received on Wed May 21 2003 - 16:48:22 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US