Simplifying Oracle/SLOB testing using OraSLOB

NOTE that this verison of OraSLOB has been deprecated - please use the version at OraSLOB, with ASM instead.

When it comes to testing storage performance from within Oracle, nothing beats Kevin Closson's SLOB.

What makes SLOB so great is that it doesn't actually generate I/O itself, instead it generates queries to an Oracle database, which then in turn generates the I/O. This gives real-world results, simply because it's actually Oracle that is generating the I/O, not some form of synthetic test tool.

The catch with SLOB is that it requires a moderate level of effort, and more importantly, skill to set it up - it requires you to setup and configure (and to some extent, tune) an Oracle database before the SLOB configuration takes over. If you're an Oracle DBA that might not sound very hard, but if you're not then it can be a steep learning curve, and extremely time consuming.

Thus OraSLOB was born!

OraSLOB is an attempt to automate the entire configuration SLOB deployment/configuration process. It consists of a CentOS Linux based OVA (intended for VMware, but will also potentially run on other virtual platforms), and some automation to handle the Oracle and SLOB installation and configuration.

Downloading OraSLOB

To use OraSLOB, you will need 2 things :

• The OraSLOB OVA
• A copy of Oracle 12c 12.1.0.2 Enterprise Edition for Linux x86-64. Other versions of 12c will also likely work, but 11g will not.

Note that whilst you need an Oracle OTN account to download Oracle, it does not need to be linked to a support contract. It's your responsibility to make sure that you meet the relevant license requirements for downloading/using Oracle!

Installing OraSLOB

Deploy the OVA onto a datastore located on the array that you want to test, preferably selecting “Thick Provisioned Eager Zero” as this will give the best performance results.

Once you’ve deployed the OVA, copy the 2 Oracle zip files to the home directory of the “oracle” user using scp (password "oraslob"), then login as the "oracle" user and run “./setup”. This will install Oracle, create a database and setup SLOB. All up, running setup will take about 15 minutes, or maybe longer depending on the speed of your storage.

The OVA includes 2 drives – one for the OS/Oracle binaries/etc (30GB, around 2GB used by default, growing to 15GB once Oracle is installed), and a second mounted on /slob for the database files (50GB, with a default setup using around 25GB of that).

Running it

Once the setup process is finished, to run SLOB, simply :
Login as oracle (password "oraslob")
cd SLOB
./runit.sh 64

The number after “runit.sh” is the number of “users” to simulate – 64 seems to give good results on an XtremIO, although you can vary it anywhere between 1 and 128 – but be aware that once you go above a certain point performance will degrade.

Both Oracle and SLOB are pre-configured to give good results. The only changes you should need to make for a general test are to the SLOB config, specifically for the time the test runs for and the “update percentage” which controls whether you’ve got a read-only or read/write workload.

The SLOB config is stored in ~oracle/SLOB/slob.conf, and the two lines of interest are the first two lines:
UPDATE_PCT=0 RUN_TIME=120

The first is the ratio of queries that are updates – 0 for a full read workload, 20 gives a good read-write mix, 100 will give you about a 50/50 read/write mix (not 100% writes as you might think – Oracle still needs to read the data before it can update it!)

The second setting is how long SLOB will run for in seconds.

After SLOB has finished running, it will create an “AWR” report in both .txt format and .html in ~oracle/SLOB/awr_rac.txt and .html.

If you need more instances, you can clone (or template) the installed image – including the database files. If the network doesn’t come up after reboot for a clone, delete the following file and reboot and it should start working - /etc/udev/rules.d/70-persistent-net.rules

Performance

As this setup uses a filesystem-based Oracle datafiles, and the filesystem is located on a VMWare Datastore, the peak performance will not be quite as good as it could be using ASM on raw devices (RDM) - but it'll be close. I've got plans for a future version using Oracle Grid/ASM in order to improve the results even further, but even with a single virtual disk on a single datastore this setup has no problems pushing past the 100K IOPS mark on an XtremIO array - from a single host!