A0: Solaris A1: Oracle Software, SYSTEM Tablespace A2: REDO logs B3: A0 soft mirror B4: A1 soft mirror B5: A2 soft mirror C6: Archived REDO logs, TOOLS tablespace C7: ROLLBACK tablespace D8: C6 soft mirror D9: C7 soft mirror E[RAID 0+1]10-17: DATA tablespace F[RAID 0+1]18-25: INDEX, TEMP tablespaces Setup II: A0: Solaris B3: A0 soft mirror E[RAID 0+1]10-17: DATA, SYSTEM, REDO logs, Oracle Software F[RAID 0+1]18-25: INDEX, TEMP, Archived REDO logs, TOOLS,ROLLBACK (extra disks used in other systems)
This really is an issue for one of the Oracle experts, and I think even they will be hard pressed to give a good answer due to the difficulty in predicting how Oracle will perform on a given Solaris configuration.
The Oracle engine is highly tuned for each implementation platform. What works well on a Z Series mainframe, may or may not work well on an AS-400, and nearly certainly won't work well on an Intel or Solaris platform. Because of the Oracle engine's knowledge of the Solaris platform, it will make many tuning adjustments to its behavior once it determines the hardware configuration. This tuning effect will make it difficult or impossible to accurately predict the engine's behavior under a given load.
As a general rule with Oracle 8i, avoiding write contention will produce the fastest OLTP processing, while maximizing RAID and data redundancy will produce the fastest OLAP processing. I realize that this isn't a concrete answer, but without doing some extensive testing with your particular data and applications, I don't think a concrete answer is possible.
For More Information
- What do you think about this answer? E-mail us at editor@searchDatabase.com with your feedback.
- The Best Database Design Web Links: tips, tutorials, scripts, and more.
- Have a Database Design tip to offer your fellow DBA's and developers? The best tips submitted will receive a cool prize--submit your tip today!
- Ask your technical Database Design questions--or help out your peers by answering them--in our live discussion forums.
- Ask the Experts yourself: Our Database Design guru is waiting to answer your toughest questions.
This was first published in April 2001