Database Reference
In-Depth Information
As you can easily see, these are BASH-style variables sourced into the runit.sh script at runtime to provide the
configuration. The most important variables for the purpose of evaluating storage are listed here:
UPDATE_PCT . This parameter replaces the explicit number of readers to writers in the
initial release. Specify in percent how many statements should be DML. A setting of 0 or 100
is equivalent to a call to runit.sh with 0 readers or writers respectively. The readme states
that values between 51 and 99 are non-deterministic.
RUN_TIME . Setting RUN_TIME to a value in seconds allows you to terminate a given
benchmark run after a given interval. The documentation recommends that when you
decide to use RUN_TIME, please set WORK_LOOP to 0.
WORK_LOOP . Instead of terminating an execution of runit.sh after a fixed amount of time,
you could alternatively specify WORK_LOOP to measure how long it takes for your system
to complete a given number of iterations of the workload. When doing so, you should set
RUN_TIME to a large number to allow for WORK_LOOP iterations to complete.
For a basic set of tests, the other parameters can be left at their defaults. But SLOB 2 does not stop there. SLOB is
made for the Oracle researcher, and there are plenty of methods for trying it in different ways.
Executing a Benchmark
The actual benchmark is initiated by the script runit.sh . It takes just one parameter: the number of sessions to
be spawned. The script performs the following steps for locally executed tests in a single-instance Oracle database
environment:
1.
Defines a default set of parameters in case those in slob.conf are incomplete before it
sources the slob.conf file into the currently executing environment.
2.
Provides sanity checks to the environment.
3.
Performs a log switch in the database.
4.
Sets up operating system monitoring using vmstat , iostat , and mpstat .
5.
Creates the required number of user sessions. Values from slob.conf are passed to the
script responsible for the benchmark, named slob.sql . The processes do not execute just
yet—they are “held in check” by a semaphore.
6.
Creates an AWR snapshot and gets the current wall clock time.
7.
Starts the execution of all withheld processes.
8.
Waits for the execution of all sessions to finish.
9.
Calculates the run time, creates another snapshot, and generates AWR reports in text and
HTML format.
Notice that the resulting AWR reports are not preserved; subsequent executions of SLOB will overwrite them.
Users of SLOB, especially Yury Velikanov, commented that for very long running benchmarks, you should disable
automatic AWR snapshots. Depending on your AWR settings, it is perfectly possible to have an automatic snapshot in
between your benchmark run. The logic in the runit.sh script takes the last two snapshots and generates the AWR
report, which causes problems if an automatic snapshot has been taken after the initial one. The automatic snapshot
interval should be set to a high enough value, not 0, because this will turn off automatic AWR snapshots.
 
Search WWH ::




Custom Search