My First Experience Running SLOB - ORION vs SLOB - 2:0

1. I am talking about PHYSICAL IO testing for the storage systems based on traditional hard disks that use spinning parts. If you would like to test anything else, please forget about using ORION. ORION is good for physical IO testing ONLY.
2. My interest is to test random physical reads typically seen as major IO consumers in OLTP systems. The focus here is on IOPS and Latency characteristics of a storage subsystem. If you are interested in a throughput or anything else, this blog post isn't for you.

• Can you control or easily predict how much storage cache (on any level) an application is going to use at different points in time (load patterns)?
• Can you dedicate just a small part of physical disks to your application and make sure that no other applications are using the rest of the space?
• If you don't have the luxury to reserve just a small part of the disks for your application, can you make sure that your application data is located just in certain areas of the disk?

1. Eliminate any caches and test back-end HDD's response time. Later on we can make an assumption on what % of Oracle physical IO requests is going to be served from storage cache under different application load patterns at different time frames and therefore forecast possible storage response time. As it's really dependent on the application's specifics and is different at certain processing time frames (e.g. reporting periods, batch processing, active consumer's time frames, etc.), physical IO testing served from cache has little value. We can assume that any cashed IO is much faster than physical IO. In such cases, we should focus our attention on CPU testing.
2. If we can't control how our OLTP data is located over our physical hard drive surface, we should assume that it's located randomly across available space. Note that we CAN control where our data located (e.g. we can allocate a partition to be used by data and leave the rest of the disk empty). We should make sure that we test the whole space that the application could use, not just a small part of it.

ORION vs SLOB - 2:0

• Kevin Closson said: "Orion may give It's VERY easy to get huge Orion nums but reasonable SLOB"
• Alex Gorbachev said: "lots of the system IO bound below the CPU level so you should see similar number with Orion or SLOB."

1. The first issue is Oracle kernel IO optimization. As an example, I can mention "db file parallel read", and Kevin Closson is going to address the problem in the next drop of the SLOB kit. However, it may limit SLOB usage in your system as you may not implement the workaround in your production system. If you used SLOB for physical IO testing, check your AWR reports. If you see "db file parallel read" under "Top 5 Timed Foreground Events," you just wasted your time and should redo the testing again. See this blog post for the explanation and fix.
2. The second issue isn't as easy to address. It is related to the fact that if your data is located in one area of a physical disk (tests 2 & 3), your physical IO response time is much better (by 100%) than if your data was randomly spread across the whole disk surface (test 4). Please note that it doesn't matter if your data is located at INNER or OUTER parts of the disks. The performance is more or less the same independently of what part of the disk your data is located. The key is that the testing tool should read data randomly from all areas of the disks used by the application.

For the record - There is no silver bullet