Oracle FAQ Your Portal to the Oracle Knowledge Grid

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

RE: Sizing - RAC, storage subsystem EMC

From: Cunningham, Gerald <>
Date: Wed, 21 May 2003 08:11:54 -0800
Message-ID: <>

Hi all,  

If you blow out your cache (probably not likely on indexed access), the same old rules apply - more spindles is better. We've had full table scans of large tables (~30-40 Gb.) blow out our 2 Gb. EMC cache. Reconfiguring EMC (changing the stripe size, disk layout, #of HBA's, etc. - not sure on the exact terms as I'm not an EMC guy) led to a 2x performance boost on the unavoidable full table scans in our case (users executing Brio queries can do anything they want).         

	-----Original Message-----
	From: Koivu, Lisa [] 
	Sent: Wednesday, May 21, 2003 10:57 AM
	To: Multiple recipients of list ORACLE-L
	Subject: RE: Sizing - RAC, storage subsystem EMC
	Hi Yeichel, 
	If the database is writing to the cache memory (and then to disk
behind the scenes), then does the rule of separating tables and indexes on different devices still apply? Last implementation I did on a SAN I followed that rule anyway, figuring it couldn't hurt. What do you think?          
	Lisa Koivu 
	Oracle Database Administrator 
	Fairfield Resorts, Inc. 
	5259 Coconut Creek Parkway 
	Ft. Lauderdale, FL, USA  33063 
	Office: 954-935-4117  
	Fax:    954-935-3639 
	Cell:    954-683-4459 
		-----Original Message-----
		From: Yechiel Adar []
		Sent: Wednesday, May 21, 2003 8:55 AM
		To: Multiple recipients of list ORACLE-L
		Subject: Re: Sizing - RAC, storage subsystem EMC
		With EMC, or any other SAN, you do not write to the
disks. You write into a cache memory on the controller and the controller then writes the data to the disks at his own time. If you have big enough write cache on the controller the raid-5 write speed does not concern you.                  

                Raid-5 might be a little slow but it save almost 1/2 the disk space needed to ensure the correctness of the data since it can use one parity disk for 10-20 disks.                  

		Yechiel Adar
			----- Original Message ----- 
			To: Multiple recipients of list ORACLE-L
			Sent: Tuesday, May 20, 2003 9: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.                          

			The database will be a Oracle RAC 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.



			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:                         



Please see the official ORACLE-L FAQ:

Author: Cunningham, Gerald

Fat City Network Services    -- 858-538-5051
San Diego, California        -- Mailing list and web hosting services
To REMOVE yourself from this mailing list, send an E-Mail message to: (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 - 11:11:54 CDT

Original text of this message