Scott's Blog

OraSLOB, with ASM

Scott Howard -

Some time ago I created a VMWare OVA that simplified the installation of Oracle + SLOB, called OraSLOB. This worked well, but as it used a single datastore device for the Oracle storage it didn't exactly deliver brilliant performance.

I've since updated this so that it uses Oracle Grid, and specifically uses ASM storage. Installation is largely similar to the original OraSLOB, with the two additional steps of downloading and copying Oracle Grid to the image, and manually assigning one or more disks to be used for storage. Note that it is no longer possible to use non-ASM storage.

Downloading OraSLOB

To use OraSLOB, you will need 3 things :

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”.

Once you’ve deployed the OVA, edit the VM that was created and assign at least 1 additional "hard disk" that will be assigned to ASM. This could either be a datastore device, or an RDM, with a total size of at least 40GB across the disks you assign (preferably much more!). If your goal is to test performance, then you should assign at least 4 disks (preferably spread across multiple controllers), with each being at least 250GB.

Next boot the VM, and copy the 4 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 Grid, install Oracle DBMS, create a database and setup SLOB. All up, running setup will take about 20 minutes, or maybe longer depending on the speed of your storage.

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.