This page will be used to offer quick links to the latest SLOB kit contents.

 2014.12.11

Where To Get The Latest Kit

The following is a link to the SLOB 2.2 release tar archive
(md5 is 2d1293c175569103ca4209683fc8df88 ):

SLOB 2.2 (Click here).

Generic SLOB 2 README: Click here.

More information about SLOB 2.2: Click here.

Helpful Information

One can simply google “Oracle SLOB” to find a wealth of SLOB community information. Additionally, I’ll continue to update the following list of helpful SLOB links on this blog:

  1. SLOB Deployment – A Picture Tutorial.  Click the following link: SLOB Tutorial.
  2. SLOB Data Loading Case Studies – Part I. A Simple Concurrent + Parallel Example. Click the following link: Data Loading Part I.
  3. SLOB Physical I/O Randomess.  Click the following link: About I/O Randomness.
  4. SLOB Failing To Generate AWR Reports? Red Hat Bug 919793! Click this link.

Prior Releases

The following links remain for historical purposes. As of 2014.12.04 all prior SLOB releases and patches are deprecated.

2014.03.19:

Patch README

SLOB Patch

2014.09.01:

Please visit the following blog post to read about a patched version of awr_info.sh: Click here.

SLOB Patch Deployment (2014.03.19) (DEPRECATED, LEGACY INFO)

Note: If you download the SLOB 2.2 kit you do not need this patch.

The following screenshot shows how to deploy the base SLOB kit and apply the patch. Please note the patch extracts into your current working directory:

deploy-slob

 

45 Responses to “SLOB Resources”


  1. 1 Stanley Raj May 29, 2014 at 8:12 am

    Is ORA-01653 expected when you setup SLOB with 100 users on a bigfile TS?
    Bigfile TS max size=db block size * total # of blocks.

    Each of the 10K row CF1 table is using 10K blocks.
    For 100 users total blocks is 1 million (10,000*100 = 1,000,000).

    My db block size is 8k.

    So bigfile max size is: 8192 * 1 mil blocks = 8 GB.

    Setup eventually fails with ORA-01653 even though TS has 20 GB free.

    • 2 kevinclosson May 30, 2014 at 9:37 am

      are you sure the ORA-01653 is happening because of the tablespace given to setup.sh for SLOB schemas and not, perhaps, UNDO? You might try setting autoextend on the bigfile TS and see how big it wants to be… but, in the end, your math is right. It should fit.

  2. 3 Vladimir Sitnikov (@VladimirSitnikv) April 9, 2015 at 6:28 am

    Please, post sources to github. It would greatly simplify porting SLOB to other DBs.

    Can you please make licensing explicit (i.e. include LICENSE file with well-known license)?
    You know, software without explicit license is very very moot.

    • 4 kevinclosson April 13, 2015 at 12:58 pm

      I’m sorry you find SLOB moot.

      • 5 Vladimir Sitnikov (@VladimirSitnikv) April 14, 2015 at 12:54 am

        I mean: software without license that covers basic operations of use, modify, redistribute is vague/foggy/obscure. I thought “moot” has such meaning, but it looks like it does not.

        I could have confused it with Russian “мутный” (click “prononciation”): https://translate.google.ru/#ru/en/%D0%BC%D1%83%D1%82%D0%BD%D1%8B%D0%B9

        I am pretty happy if it is forbidden to redistribute SLOB. Well, I am not, but the thing that disturbs me the most is there is _no_ explicit approval/denial in the SLOB sources for redistribution of mods.

        Once every couple of months I think of fixing SLOB bugs here and there, then I realize “SLOB’s license does not tell anything about mods”. This makes me a sad panda.

        • 6 kevinclosson April 14, 2015 at 8:22 am

          The license is granted for “use.” Rights for anything else one might think about doing with software in general (e.g., redistribution–also known as republishing) is not explicitly granted therefore is not permitted.

          I know you only want to do “good things”, Vladimir, but I’m not yet sure your “good things” match my “good things.”

          SLOB *must* remain *simple*.

        • 11 kevinclosson April 15, 2015 at 1:38 pm

          @Vladimir : May I ask if you push other providers of such freeware for a move to open source? Perhaps a good example would be swingbench (firm license and much compiled code in the distribution) ?

          • 12 Vladimir Sitnikov (@VladimirSitnikv) April 16, 2015 at 2:47 pm

            That depends.

            1) Usually it is quite clear that the software won’t get immediate contributions. For instance, if OracleDB went open source, it is quite clear it would take a long while to contribute anything meaningful.

            2) Sometimes, the license is clear enough that you deal with freeware.
            A case from my recent experience is JD java decompiler (http://jd.benow.ca/) was freeware for a long time (~5 years?) and recently it went open source. I did not send a single note to JD team, but I know there were lots of asks for that move.

            3) Sometimes the software is already open source. Once I faced very strange community that was literally rude. So, I know that “open source” != “open for contributions”.

            4) I do not approach projects that I do not use. I do not use swingbench, orion, etc. Sorry.

            5) I thought SLOB could benefit from contributions. I was wrong. Not a big deal.

            —-

            In fact it is the first time you mention “freeware”.
            I do not blame you for that, on contrary, the more “free” the better (see [1]).

            I would like to stress a bit: I try not to push, but I kindly ask you if that is planned/suitable for you.

            You say SLOB is just freeware. Ok, that closes my github questions. As I said, it would be nice if you put that into readme/license since it is otherwise very tempting to look into SLOB sources, modify it, publish it on a blog post, etc.

            If you play Oracle-like “use until I bite you” licensing game, well, that is your right =)

            Regarding “in-house” SLOB mods, I think peer-review benchmarks are much better than just “some SQL workload derived from SLOB”. In other words, you can easily get nonsense results and no one will point you into an invalid test harness since you are the only user of your SLOB mod.

            I understand even “official SLOB from Kevin” can produce nonsense results if brain is out of the equation.

            [1]: I wish PostgreSQL had optimizer hints. PG is free, but their motto is “never implement optimizer hints” (how on Earth can that fly?!). Here OracleDB wins.

  3. 13 Vladimir Sitnikov (@VladimirSitnikv) April 16, 2015 at 2:52 pm

    2013.05.05.slob2.tar use unfair random selection for select/update

    v_do_update := MOD(v_random, 2) = 0;

    I believe this is not fair. Effectively, with low update pct you “spend” all the updates early since probability of v_do_update is always 0.5.
    With high update_pct you spend all the selects too early.

    Can you please fix that, so probability of update/select is taken from the benchmark configuration?

    • 14 kevinclosson April 17, 2015 at 9:59 am

      I will consider it and if I change it I’ll give attribution to you for the suggestion. May I ask, however, what significant impact this has to usability or predictability? I see your point about up-front modify intensity but what if you had hundreds of sessions with think time? That dices the mix extremely. No ?

      • 15 Vladimir Sitnikov (@VladimirSitnikv) April 17, 2015 at 11:33 pm

        If I read the code correctly, it cannot generate 75% updates (or any other 51..99% updates).
        Well, in “update only” it obviously generates 100% updates, but you cannot guarantee stable 75% since mod(, 2) never generates more than “50% on average”.
        Am I correct?

        If I am wrong, that alone explains why code needs adjustments.

        Frankly speaking I would remove v_select_only_workload and v_update_only_workload to make the code simpler.

        There are cases when even scientific conclusions were biased by bad random generators, so I think it is better to fix problem before it bites you.

        • 16 kevinclosson April 18, 2015 at 8:18 am

          > If I read the code correctly, it cannot generate 75% updates (or any other 51..99% updates).

          @VladimirSitnikv : The SLOB documentation is here: https://my.syncplicity.com/share/lzszutodedekfuv/SLOB2_README-2012.05.04 and on page 6 it has *always* said the following regarding UPDATE_PCT:

          Values between 51 and 99 are non-deterministic.

          So let me ask you again, “what significant impact this has to usability or predictability”?

          You’ve repeatedly made your strong objections to the fact that I’m not open sourcing SLOB. Please don’t continue to throw academic arguments at the functionality of SLOB (e.g., handling of UPDATE_PCT 51-99 in spite of what the documentation says about the matter). If you find something broken in a way that makes SLOB less usable then say so.

          • 17 Vladimir Sitnikov (@VladimirSitnikv) April 18, 2015 at 10:01 am

            >and on page 6 it has *always* said the following regarding UPDATE_PCT
            >Values between 51 and 99 are non-deterministic.

            Would you please fix that?
            If you would like to keep the issue intact, would you please just say “not an issue”?

            ^^ That was the only my question. Nothing to do with OSS.

            > less usable then say so

            I do find SLOB less useful if it can’t measure 51..99.

            >So let me ask you again, “what significant impact this has to usability or predictability”?

            I do not want to get garbage results from SLOB.
            It turns out, lots of engineers just run the benchmark. Nobody verifies all the corner cases.

            > academic arguments (e.g. UPDATE_PCT 51-99)

            update_pct is hardly academic. It is used in the wild:

            For instance slide 31 obviously uses 60 and 90 update_pct http://www.slideshare.net/GilbertStanden/nyouglxcdecember12final-42650050

            I bet lots of engineers just try different values without thorough RTFM sessions. Who knows that SLOB legally (as per documentation) executes “rm -rf /” if you use update_pct=69?

            If you think SLOB is designed to shoot in the one’s foot, just confirm that and tell me you are not going to fix update_pct>50 issue.

            > You’ve repeatedly made your strong objections to the fact that I’m not open sourcing SLOB.

            Kevin, I am clever enough not to bang my head into a wall more than once.
            Please note this thread (and the other two in “awaiting moderation”) has nothing to do with the “open source” question.
            I would never ask you regarding “SLOB moving open source” since you’ve made your vision clear.

            I just report bugs/feature requests.
            If you do not want bug reports/feature requests, please just say that.

            • 18 kevinclosson April 18, 2015 at 4:09 pm

              @VladimirSitnikv : You do know, don’t you, that Oracle cannot modify a block of data that is not in the SGA. I’ve explained this countless times in many articles I’ve written. If the SGA buffer pool is smaller than the active data set then even UPDATE_PCT=100 is a 50% read, 50% write (datafile access) workload. May I ask why you think multiple sessions doing, for example, UPDATE_PCT=67 is going to but much different than, say, UPDATE_PCT=80?

              Why don’t you make the mod yourself to slob.sql and post how much more astoundingly precise the I/O profiles are with, for example, UPDATE_PCT=75 versus UPDATE_PCT=80. You’re going to find it doesn’t change much. I’ve actually tested the difference (imagine that…there’s more to SLOB than I make available to the user community?) and it is not meaningful enough to make any changes to SLOB in this regard.

              This thread is over.

              • 19 Vladimir Sitnikov (@VladimirSitnikv) April 19, 2015 at 9:32 am

                >UPDATE_PCT=67 is going to but much different than, say, UPDATE_PCT=80?

                I mean update_pct=50 and update_pct=100 behave much different (~33% writes vs 50% writes), so it makes sense to have at least a single point in between.

                My rough estimates are:

                storage operations for 50 update_pct: reads=100, writes=50. write/(write+read) = 50/(50+100) = 33%

                storage operations for 67 update_pct: reads=100, writes=67. write/(write+read) = 67/(67+100) = 40%

                storage operations for 80 update_pct: reads=100, writes=80. write/(write+read) = 80/(80+100) = 44%

                storage operations for 100 update_pct: reads=100, writes=100. write/(write+read) = 100/(100+100) = 50%

                33% writes, 40% writes, and 50% writes are different storage workloads.

                You prefer jumping from 33% right to 50%. That’s your right.

                >Why don’t you make the mod yourself to slob.sql and post how much more astoundingly precise the I/O profiles are with

                I am forbidden to publish mods, so this can’t be my weekend project
                My day-to-day work has other priorities.

                • 20 kevinclosson April 19, 2015 at 10:50 am

                  @VladimirSitnikv : Your calculations do not appear to factor in redo writing? Redo writing does not scale linearly with datafile writes due to piggyback writes.

                  • 21 Vladimir Sitnikov (@VladimirSitnikv) April 19, 2015 at 1:05 pm

                    They are _rough_ calculations as I stated above. No redo, no undo, no archive logs, no flashback logs, no smart flash cache writes, no control file sequential read or whatever is there else.

                    I know you know saying “50% reads 50% writes” is nothing unless file system, “RAID” configuration, working set size, etc, etc is given.

                    So, what?

                    • 22 kevinclosson April 19, 2015 at 2:27 pm

                      @VladimirSitnikv : Please *do not* post any more comments until you have personally studied how SLOB behaves and have a specific AWR-backed I/O pattern that you can argue needs addressed.

                      No more academic indictments of SLOB. I will not approve any more such comments.

          • 23 Vladimir Sitnikov (@VladimirSitnikv) April 18, 2015 at 11:57 am

            >on page 6 it has *always* said
            >So let me ask you again

            I understand not reading the documentation is not a very smart move.
            I’ve never launched a single SLOB test either, so I do not think I should remember all the SLOB’s peculiarities.

            I just review numbers that my colleagues get with SLOB. I was innocent in my belief that SLOB can do all those 50%, 60%, 70% updates that I was shown one day.

            I think, good software should protect user from typing invalid values.
            Read how Therac killed multiple patients before bug was identified: http://en.wikipedia.org/wiki/Therac-25.


  1. 1 SLOB 2 — A Significant Update. Links Are Here. | Kevin Closson's Blog: Platforms, Databases and Storage Trackback on May 15, 2014 at 12:03 pm
  2. 2 Oracle Meetup | Oracle Scratchpad Trackback on July 3, 2014 at 1:23 am
  3. 3 Interesting SLOB Use Cases – Part I. Studying ZFS Fragmentation. Introducing Bart Sjerps. | Kevin Closson's Blog: Platforms, Databases and Storage Trackback on July 17, 2014 at 9:35 am
  4. 4 When Storage is REALLY Fast Even Zero-Second Wait Events are Top 5. Disk File Operations I/O: The Mystery Wait Event. | Kevin Closson's Blog: Platforms, Databases and Storage Trackback on July 18, 2014 at 8:37 am
  5. 5 New section: Oracle SLOB Testing | flashdba Trackback on July 18, 2014 at 9:13 am
  6. 6 Oracle Database 12c Release 12.1.0.2 – My First Observations. Licensed Features Usage Concerns – Part I. | Kevin Closson's Blog: Platforms, Databases and Storage Trackback on July 24, 2014 at 1:12 am
  7. 7 Oracle Database 12c Release 12.1.0.2 – My First Observations. Licensed Features Usage Concerns – Part II. | Kevin Closson's Blog: Platforms, Databases and Storage Trackback on July 25, 2014 at 2:02 pm
  8. 8 Oracle ASM vs ZFS on XtremIO | Dirty Cache Trackback on August 11, 2014 at 12:37 am
  9. 9 How Do I Know I Have The Latest SLOB Kit? | Kevin Closson's Blog: Platforms, Databases and Storage Trackback on December 11, 2014 at 4:26 pm
  10. 10 Announcing SLOB 2.2 : Think Time and Limited-Scope User-Data Modification | Kevin Closson's Blog: Platforms, Databases and Storage Trackback on December 11, 2014 at 4:41 pm
  11. 11 SLOB Data Loading Case Studies – Part II. SLOB 2.2 For High-Bandwidth Data Loading. | Kevin Closson's Blog: Platforms, Databases and Storage Trackback on December 15, 2014 at 11:44 pm
  12. 12 SLOB 2.2 Not Generating AWR reports? Testing Large User Counts With Think Time? Think Processes and SLOB_DEBUG. | Kevin Closson's Blog: Platforms, Databases and Storage Trackback on December 16, 2014 at 4:30 pm
  13. 13 Measure the impact of remote versus local NUMA node access thanks to processor_group_name | bdt's oracle blog Trackback on January 7, 2015 at 6:51 am
  14. 14 cpu binding (processor_group_name) vs Instance caging comparison during LIO pressure | bdt's oracle blog Trackback on January 15, 2015 at 1:47 pm
  15. 15 Modify on the fly the cgroup properties linked to the processor_group_name parameter | bdt's oracle blog Trackback on January 19, 2015 at 9:11 am
  16. 16 SLOB Patch. AWR Post-Processing Script (awr_info.sh) Fix. | Kevin Closson's Blog: Platforms, Databases and Storage Trackback on January 20, 2015 at 5:58 pm
  17. 17 Introducing SLOB – The Silly Little Oracle Benchmark | Kevin Closson's Blog: Platforms, Databases and Storage Trackback on January 31, 2015 at 8:39 am
  18. 18 Scrutinizing Exadata X5 Datasheet IOPS Claims…and Correcting Mistakes | Kevin Closson's Blog: Platforms, Databases and Storage Trackback on February 2, 2015 at 6:37 pm
  19. 19 SLOB LIO against Oracle on AIX different page sizes | Luís Marques Trackback on April 3, 2015 at 12:51 am

Leave a Reply

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

WordPress.com Logo

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

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s




EMC Employee Disclaimer

The opinions and interests expressed on EMC employee blogs are the employees' own and do not necessarily represent EMC's positions, strategies or views. EMC makes no representation or warranties about employee blogs or the accuracy or reliability of such blogs. When you access employee blogs, even though they may contain the EMC logo and content regarding EMC products and services, employee blogs are independent of EMC and EMC does not control their content or operation. In addition, a link to a blog does not mean that EMC endorses that blog or has responsibility for its content or use.

This disclaimer was put into place on March 23, 2011.

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

Join 2,355 other followers

Oracle ACE Program Status

Click It

website metrics

Fond Memories

Copyright

All content is © Kevin Closson and "Kevin Closson's Blog: Platforms, Databases, and Storage", 2006-2013. 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.

Follow

Get every new post delivered to your Inbox.

Join 2,355 other followers

%d bloggers like this: