| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Sizing - RAC, storage subsystem EMC
Hi there
Currently got 2 projects in the early stages,
One will be Sun + Sun Cluster 3+ Hitachi SAN Second is Sun + Veritas Cluster + HP Evo 5000 SAN with Veritas cluster file system.
George
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!
-----Original Message-----
Sent: 22 May 2003 02:47 AM
To: Multiple recipients of list ORACLE-L
I would appreciate if some more information is provided.
Are you planning on using Veritas cluster manager with Sun or SUN cluster.
If you are using SUN clusters with EMC, you probably are using RAW devices.
(unless EMC has another fileystem solution that i do not know about) Oracle
will not certify the SUN cluster file system solution for RAC due to poor
performance Nor would it certify SUN's GFS for RAC.
Regards
Murali
Yechiel Adar <adar76_at_inter.net.il> wrote:
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
Mehish
----- Original Message -----
To: Multiple <mailto:ORACLE-L_at_fatcity.com> recipients of list ORACLE-L
Sent: Tuesday, May 20, 2003 9:06 AM
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
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"
Murali Vallath
"We must be the change we wish to see in the world." Mahatma Gandhi.
Do you Yahoo!?
The New <http://us.rd.yahoo.com/search/mailsig/*http:/search.yahoo.com>
Yahoo! Search - Faster. Easier. Bingo.
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: INET: George.Leonard_at_za.didata.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-LReceived on Fri May 23 2003 - 02:06:50 CDT
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
 |
 |