Sorry for the inconvenience but I have made a drastic move to merge the individual websites I maintain into one. Over the next couple of weeks, hopefully sooner, Everything, websites & blogs will be merged into a single website: www.jameskoopmann.com. This will enable me to communicate via a single website and hopefully make it easier on you and myself. You will quickly notice that I have taken a huge leap of faith and am using a blogging interface for this. So come stop by, take a look around, and let me know what you think. Just remember I am just now begging the transition so be a bit patience. But I DO want your comments.
Please change bookmarks, RSS, etc. as thecheapdba.com, blog.thecheapdba.com, and blog.jameskoopmann.com will be going away soon.
To increase your ability to model the physical aspects of an Oracle database it is advantageous for the designer to test a disk configuration before they actually install an Oracle database on top of it. For this reason I suggest you take a look at Oracle’s ORION tool to help benchmark your storage architecture. The proper benchmarking can be the difference between the same hardware having poor or excellent performance. Through the use of Oracle’s ORION workload tool Database Architects can effectively develop a workload that can mimic and stress a storage array in the same manner as the planned application with an Oracle backend database. Because the ORION tool does not require a running Oracle database, multiple configurations can be tested such that an optimal storage configuration can be obtained while providing for reliability, stability, and scalability.
Take a look at this introductory article Measuring Disk I/O - Oracle’s ORION Tool
How do you know if the disks you will be using from ANY particular vendor can muster up the IOPS and MBPS required to satisfy your current or future workloads?
In the article, Measuring Disk I/O, we took a quick look at the amount of IOPS and MBPS, or workload, that our Oracle database is generating. These numbers are very important when we start to look at our system for available throughput, especially out to the disk subsystem. Why are these numbers important? As a very simple example, and no real meaning, suppose you, after running the scripts from that article, find out that your database is requesting, and getting, 100,000 IOPS. Well, if your disk subsystem has 1,000 disks and if every disk is participating in satisfying 100,000 IOPS, you could sort of say that each disk is performing about 100 IOPS. You then have to ask yourself the following questions:
Is this good on a per disk basis?
Do I have room to grow if my throughput were to double or triple?
How much breathing room do I really have?
So let’s take a quick dive into these from a truly vendor perspective in the article : Measuring Disk I/O - A Vendor View