Simple SLOB Init.ora Parameter File For Read IOPS Testing

This is just a quick blog entry to show the very simple init.ora parameter file I use to stress simple read IOPS testing with SLOB.  On 2s16c32t E5-2600 servers attached to very fast storage this init.ora parameter delivers on the order of 275,000 physical IOPS with 64 SLOB sessions.

I’ll post an init.ora that I use for the REDO model and DBWR testing as soon as possible.

Thanks to Yury for the recommended hidden init.ora parameters to boost the ratio of db file sequential reads.

Additional information can be found here: README file.

Here is the init.ora:

db_block_size = 8192
db_files = 20000
processes = 500
shared_pool_size = 5000M

9 Responses to “Simple SLOB Init.ora Parameter File For Read IOPS Testing”

  1. 1 Martin Berger (@martinberx) June 10, 2012 at 9:29 pm

    I had a reasonable amount of “simulator hash latch” / “simulator lru latch” while playing with LIO tests. According to I set
    db_cache_advice=off (default=on)
    in the init.ora – Now these waits are gone.

  2. 2 Matt June 12, 2012 at 4:21 pm

    I have not tried a 10M SGA yet. I will try that later this evening time allowing.

    To echo from several of your posts. You have to have several tools for measuring performance. We use SLOB as one them, as a baseline we know it will deliver on server platform x and array configuration y. Being able run this “same” test in different platforms it allows us to develop a profile.

    We find ourselves using IO calibrate more often than Orion but we use them both so that we can add to the overall profile of the ecosystem.

  3. 3 FC June 18, 2012 at 4:51 am


    Setting a small cache_size will increase the number of PIO, that’s a fair objective. But the other options (which I don’t know so it might be a useless message) seems to change the way physical IOs are done.

    By starting to use hidden parameter to boost the number of LIOs, aren’t you getting away from your first goal ? And by excessively customizing it to get higher results starting to have an “unrealistic platform performance measurement tools”, excepted the tool is fine, but the platform is not?
    I mean, if i’m using a database in production with a number of parameters, when I’m testing with SLOB or any other thing, for sure I want to see how _my system_ performs, with my settings no?


    • 4 kevinclosson June 18, 2012 at 7:37 am

      Hello FC,

      The hidden parameters I use in this example init.ora are to neutralize a recent Oracle optimization that substitutes db file sequential read with multiblock reads in some situations. We want SLOB to be a single block rand read engine driven by SQL. These parameters do not (in my testing) affect LIO. If anyone has measured otherwise it would be helpful if they would point it out.

      If using SLOB to measure maximum demonstrable platform capability for Oracle I/O then use whatever init.ora it takes to achieve that goal. After you have that measurement then switch to setting that mimic what you have to use in production so see if it is different.

      P.S., Say “Hi” to Eric G. for me (if you work in the same area as him).

  4. 5 FC July 2, 2012 at 7:18 am


    You have the hello from Eric 🙂 (for some days actually)
    Ok, thank you for response. It’s very clear and sounds obvious now.

    Following this comment about the size of the tables:
    Do you have any guideline, or feedback?
    I mean, when you are using SLOB to compare the speed of SSD, size doesn’t matter I agree because you have no cache. But when using , in our case, a NAS with hard drives and some caching (32GB of memory in my case) then, the size of tables has to be taken into account. Because at some point, increasing the number of SLOB sessions would just make the tables’sizes bigger than our NAS memory. Which decreases a lot the performance, but it is not really due to the number of PIO per second, but rather to the size of the dataset we are working on.
    Which could lead to different slopes
    -1/everything fits in the cache of the NAS
    -2/And then suddenly, as we are increasing the number of SLOB sessions, it no longer fits in the cache. So in a hidden way, we are actually changing two parameters at the same time: number of SLOB sessions + reading from the hard drives

    I don’t know if what I mean is very clear. :-S



  5. 6 vaurob October 31, 2018 at 3:28 am

    Hello I’ve posted a question on OTN regarding these hidden parameters.
    Could you please check it and comment it?
    I’m testing scaleio performance.

  1. 1 Introducing SLOB – The Silly Little Oracle Benchmark « Kevin Closson's Blog: Platforms, Databases and Storage Trackback on August 31, 2012 at 9:22 am
  2. 2 Collection of links, tips and tools for running SLOB | Pardy DBA Trackback on February 15, 2013 at 5:53 pm

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.


I work for Amazon Web Services. The opinions I share in this blog are my own. I'm *not* communicating as a spokesperson for Amazon. In other words, I work at Amazon, but this is my own opinion.

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 744 other subscribers
Oracle ACE Program Status

Click It

website metrics

Fond Memories


All content is © Kevin Closson and "Kevin Closson's Blog: Platforms, Databases, and Storage", 2006-2015. Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Kevin Closson and Kevin Closson's Blog: Platforms, Databases, and Storage with appropriate and specific direction to the original content.

%d bloggers like this: