The upcoming SLOB 2.4 release will bring improved data loading error handling. While still using SLOB 2.3, users can suffer data loading failures that may appear–on the surface–to be difficult to diagnose.
Before I continue, I should point out that the most common data loading failure with SLOB in pre-2.4 releases is the concurrent data loading phase suffering lack of sort space in TEMP. To that end, here is an example of a SLOB 2.3 data loading failure due to shortage of TEMP space. Please notice the grep command (in Figure 2 below) one should use to begin diagnosis of any SLOB data loading failure:
If you are testing SLOB against 18.104.22.168 and find that the AWR report generation phase of runit.sh is taking an inordinate amount of time (e.g., more than 10 seconds) then please be aware that, in the SLOB/awr subdirectory, there is a remedy script rightly called 11204-awr-stall-fix.sql.
Simply execute this script when connected to the instance with sysdba privilege and the problem will be solved.
This is a hasty blog post to get SLOB 2.2 out to those who are interested.
Please visit kevinclosson.net/slob
In addition to doing away with the cumbersome “seed” table and procedure.sql, this kit introduces 5 new slob.conf parameters. By default these parameters are disabled.
This SLOB distribution does not require re-executing setup.sh. One can simply adopt the kit and use it to test existing SLOB databases. The following explains the new slob.conf parameters:
When set to TRUE, modify SQL will no longer affect random rows spanning each session’s schema. Instead, each session will only modify HOTSPOT_PCT percent of their data.
I recently read a blog post by Kyle Hailey regarding some lack of randomness he detected in the Orion I/O generator tool. Feel free to read Kyle’s post but in short he used dtrace to detect Orion was obliterating a very dense subset of the 96GB file Orion was accessing.
This is the first installment in a series of posts I’m launching to share interesting use cases for SLOB. I have several installments teed up but to put a spin on things I’m going to hit two birds with one stone in this installment. The first bird I’ll hit is to introduce a friend and colleague, Bart Sjerps, who I just added to my blogroll. The other bird in my cross-hairs is this interesting post Bart wrote some time back that covers a study of ZFS fragmentation using SLOB.
As always, please visit the SLOB Resources Page for SLOB kit and documentation.
This is a very simple script to extract some helpful information from the awr reports generated from a SLOB run.
First, rename it to awr_info.sh and chmod it for execute permission:
$ mv awr_info.sh_.txt awr_info.sh
$ md5 awr_info.sh
MD5 (awr_info.sh) = 48c39d920a2c128899cff74901ceae1b
$ chmod +x awr_info.sh
By convention you should rename awr.txt after a run of runit.sh. It is best to rename to some arbitrary name that makes sense to you but have 2 dot-seperated suffixes to track the number of writer and reader sessions. For example:
$ sh ./runit.sh 0 32
$ mv awr.txt awr.txt.0.32
This is the February 1, 2013 drop of the SLOB tar archive. After downloading it, please compute an md5sum on it. For example, using OSX md5 command you will see the following type of output. The md5 checksum will, of course, be the same whether computed by Linux md5sum or any other such command.
The changes in this tarball are to the cr_db.sql script which had a faulty alter tablespace command in it. I've also added a very crude yet helpful awr post-processing script called awr_info.sh under the misc directory. See the README in that directory for more info on the script.
$ ls -l 2013.02.01-slob-kit.tar_.gz
-rw-r--r--@ 1 clossk staff 10040 Feb 1 16:16 2013.02.01-slob-kit.tar_.gz
$ md5 2013.02.01-slob-kit.tar_.gz
MD5 (2013.02.01-slob-kit.tar_.gz) = f157b1c51b553f90df53fcea95f89632