My SLOB IO Testing Index

Posted in: Technical Track

Martin Berger suggested to create this page to keep track of blog posts related SLOB IO testing. Here it is Martin ;)

References to my SLOB testing related blog posts:

  1. ALL Pythian blog posts with Post Tag #SLOB
  2. My First Experience Running SLOB – Status Update 1 – or why I started the testing
  3. Status Update 2 (first results) – first conclusions Orion vs SLOB – 1:0
  4. Don’t repeat my errors (AWR) – explains the AWR issue that can screw up results
  5. Final results – ORION vs SLOB – results
  6. ORION vs SLOB – 2:0final post and conclusions
  7. SLOB on steroids – Part 1
  8. SLOB LinkedIn Group

If you are seriously interested in getting a good understanding of your IO subsystem performance characteristics, then one of the tools that you may consider for putting your system IO on stress is SLOB. See Introducing SLOB – The Silly Little Oracle Benchmark from  Kevin Closson. I did and learned a lot. A bit of warning from my side: You should be ready to invest a bit of time (days in my case) to make sure that the results you are getting are reliable.

As SLOB takes the IO testing on Oracle Instance level, you need to watch for several things before you declare official testing results. My suggestion is: Don’t take any result for granted. You need to assess those before stating that you are done. Here is my list.

NOTE: This list is valid for Physical IO testing only as opposite to LIO or Oracle Physical IO stack testing (cached IO) and based on my personal experience. Your case/configuration may be different.

  • Make data cache as small as possible. Don’t worry about any concurrency issues before you hit them. I set db_cache_size=12M, and it didn’t give me any concurrency problems even with 128 readers test. Details are here.
  • Make sure that the SQL used by SLOB does what it’s intended to do – make a lot of “db file sequential read” based IOs. Newer Oracle versions bring some optimizations in the area, so you should carefully assess results before making them available to others.  You will find some recommendations on how to avoid some of version’s optimizations in this blog post (see hidden init.ora parameters).
  • Run SLOB several times and make sure that the results you are getting are consistent. Otherwise, question those. One thing that I found during my tests was the fact that earlier versions of SLOB had a “bug” generating awr.txt reports. AWR didn’t cover all my tests’ time. For details and solutions see “My First Experience Running SLOB – Don’t repeat my errors (AWR)“.
  • Keep in mind that Inner and Outer areas of HDDs have different performance characteristics. If your goal is to test your real application IO performance, then think about in which disk areas your application data will be located and try your best to locate SLOB data the same way (no blog post here as of now).
  • Don’t put  all your test data close to each other. If HDDs in your system are big, SLOB puts test data in the same/close area. Oracle doesn’t need to move HDDs’ heads that much to read the data in this case. It rarely happens in real world configurations. If you do use default SLOB data load tests, results may not be close to your application’s IO load (no blog post here as of now).
  • Switch ALL other load on your system if possible. If you seriously want to get reliable and consistent results, you should switch off all other things that may impact testing results. Even if you created an empty database (as I did), you should put some effort into switching off some IO impacting processes. The following are in my list as of now: Backups, Oracle Automatic Jobs, All other Scheduler and DBA_JOBS tasks, and Resource manager(no blog post here as of now).
  • Avoid any caches. If you want to test real Physical IO performance, you should make sure that no data is returned from any kind of cache. Some would say: “Hey, we do have caches in day to day operations, why should we switch those off?” Well, sit back for a moment and ask yourself what you are trying to achieve with these tests and read the note at the beginning of this list once again. As a rule of thumb, any IOs served in less than 5ms have a good chance to be returned from some sort of cache (unless you are using SSDs). Try your best to verify it and adjust your test accordingly.
  • Switch on 10046 trace for some of the SLOB sessions to verify the results. The AWR.txt report gives you the average numbers only. This means that there is no way to verify what percentage of your IO requests are returned from caches. In my case, AWR reported 5ms average IO response for “db file sequential read” events. This seemed to be a reasonable figure. However, luckily enough, I switched on 10046 trace for some of the SLOB sessions. Using Method-R MrTools, I easily found that 51% of all IOs for the test served in 0.1ms. Most of you know what that means: IOs has been served from cache. My 5ms response time results weren’t reliable. I had to redo the test.
  • Added on 2012.05.21: Make sure that “db file sequential read” is the only IO-related event in the AWR TOP 5 events. If there are other IO-related events, the SLOB test probably didn’t work well. As an example of other IO-related events, I would mention “db file parallel read”. If you see it in your SLOB AWR report, you should investigate why and redo the test.

I think I will stop here for now. I seem to have given you enough material to think and work on. I hope that my work will let some of you get back to your SLOB testing. I will try my best to add some more details to this post later on as time permits.

If you like my work, please do me a favor: Let me know about any other SLOB PHYSICAL IO testing-related blog posts in the comments!  :)

Good luck with your testing,


P.S. My current impression after 3+ days in SLOB testing is that it takes a lot of time and fine tuning to get reliable PIO testing results. Orion, however, just tests Physical IO, providing pessimistic results straight away.

Want to talk with an expert? Schedule a call with our team to get the conversation started.

About the Author

Yury is a nice person who enjoys meeting and working with people on challenging projects in the Oracle space. He started to work as an Oracle DBA 14 years ago (1997). For the past 10 years (since 2001) his main area of expertise is Oracle e-Business Suite. Yury is an OCP 7,8,9,10g and OCM 9i,10g. He is a frequent presenter at Oracle related conferences such as Hotsos, UKOUG and AUOUG. Yury is a socially active person. Apart from Social Media (Twitter, Bloging, Facebook) he is the primary organizer of Sydney Oracle Meetup group (250 people). So if you happen to be in Sydney (Australia) drop Yury a message and stop by at one of his Meetups.

16 Comments. Leave new

Marcin Przepiorowski
May 21, 2012 5:29 am

Hi Yury,

Good post. I was going to produce similar one but don’t have time now. So I use your blog to add two comments:
– you can run SLOB using your production database settings and see what are PIO/LIO/other boundaries (ex. I have used SLOB to test HugePages) – that’s is not possible with Orion

– AWR snapshot results can be impacted by DB connection time – you need to open a new session for every snapshot.

– Default loops for reader and writers in SLOB are probably too small for some tests but it can be easily fixed

– Size of SLOB tables – same as above too small for some tests and can be fixed as well.


Yury Velikanov
May 21, 2012 8:08 am

Hey Marcin.

Thank you for the valid point. IMHO: the other areas to look at are:
-a- Clustering factor for the index
-b- Get rid of random function usage as it introduces an additional chance of inconsistency


Kevin Closson
May 21, 2012 10:50 am

One word: KISS

Kevin Closson
May 21, 2012 11:00 am

Hi Yury,

When you say consistent, do you mean repeatable? I’m concerned about your specific environment introducing non-repeatability. I think there is something specific to your env. I’ve not had any such reports from other users.

Is your non-repeatability all just tied to that AWR anomaly you blogged about?

My First Experience Running SLOB – Final results – ORION vs SLOB – 2:0 | The Pythian Blog
June 3, 2012 4:37 am

[…] history and details why and how I got involved in SLOB and ORION comparison exercise you can find here (see Status Update 1). In short – Kevin Closson says SLOB is superior by ORION from IO testing […]

My First Experience Running SLOB – ORION vs SLOB – 2:0 | The Pythian Blog
June 3, 2012 7:54 am

[…] I made few blog posts. You can find references to all posts under “index” blog post here. Today I am ready to share my […]

My First Experience Running SLOB – Status Update 2 (first results) | The Pythian Blog
June 3, 2012 8:49 am

[…] NOTE: Other SLOB related posts list avaiable from “My SLOB IO testing index” […]

My First Experience Running SLOB – Don’t repeat my errors (AWR) | The Pythian Blog
June 3, 2012 8:50 am

[…] NOTE: Others SLOB related posts list avaiable from “My SLOB IO testing index” […]

My First Experience Running SLOB – Status Update 1 | The Pythian Blog
June 3, 2012 8:51 am

[…] Others SLOB related posts list avaiable from “My SLOB IO testing index” […]

Simple SLOB Init.ora Parameter File For Read IOPS Testing « Kevin Closson's Blog: Platforms, Databases and Storage
June 10, 2012 11:52 pm

[…] to Yury for the recommended hidden init.ora parameters to boost the ratio of db file sequential […]

SLOB on steroids – Part 1 | The Pythian Blog
July 8, 2012 4:14 am

[…] SLOB on steroids v0.1 (you use it on your own risk). If you don’t know what is SLOB read here. […]

DB Optimizer » NFS versus dNFS
July 16, 2012 12:16 am

[…] SLOB for spin. (BTW can one test dNFS with Orion at all?) Nice write up on SLOB by Pythian: I ran into the same issues Pythian came up […]

Collection of links, tips and tools for running SLOB | Pardy DBA
February 15, 2013 3:09 pm

[…] manager, and so on.  You want the database to be as idle as possible, other than SLOB.  See Yury’s SLOB index page which includes these […]

Collection of links, tips and tools for running SLOB | Pardy DBA
February 15, 2013 7:53 pm

[…] resource manager, and so on. You want the database to be as idle as possible, other than SLOB. See Yury’s SLOB index page which includes these […]


Hi Yuri,

How do I run SLOB2 for a specified amount of time (say a few hours) for a specified update percentage (say 20%)? I have tried setting 3600 for “RUN_TIME” and 30 for UPDATE_PCT. The run completes in about 1800 seconds instead of specified 3600 seconds. If I kick off a subsequent run keeping RUN_TIME and UPDATE_PCT setting the same in slob.conf file, the test runs randomly end within a few seconds (sometimes 5 seconds, sometimes 8 etc.).

Thank you.
– Saad

Jatin Gulati
June 1, 2015 1:27 am

Hi Yuri,

By any chance were you able to create drag race using work_loop, i’m finding its not working using SLOB 2.2 any suggestions ?



Leave a Reply

Your email address will not be published. Required fields are marked *