Release 2.1 for Windows
For a brief overview of how to use Hammerora see the About page
Anything not clear or still not sure on how to get started? Post a message on the Support Forum. This is monitored regularly and the quickest way to get an answer to your question.
-
Documentation
The values in config.xml have the following meaning:
<?xml version="1.0" encoding="utf-8"?>
<hammerora>
<bm>TPC-C</bm>The name of the pre-built benchmark to be used for schema creation and the transaction counter. Can be either TPC-C or TPC-H
<service>
<system_password>manager</system_password>The password of the system user of the target instance for testing
<instance>oracle</instance>The service name of the target instance for testing
</service>
<tpcc>The following parameters apply to the TPC-C benchmark only
<schema>Parameters for the TPC-C schema creation, populates the dialogue under TPC->TPC-C Schema Options
<count_ware>1</count_ware>The number of warehouses set by the slider in the dialogue, by default 1 to 100
<tpcc_user>tpcc</tpcc_user>The username of the owner of the TPC-C schema, can be any acceptable oracle user name
<tpcc_pass>tpcc</tpcc_pass>The password for the owner of the TPC-C schema, can be any acceptable oracle user password
<tpcc_def_tab>tpcctab</tpcc_def_tab>The default tablespace for the TPC-C schema owner detailed in the option above, this tablespace must have already been created
<tpcc_def_temp>temp</tpcc_def_temp>The temporary tablespace for the TPC-C schema owner
<plsql>0</plsql>Whether by default the TPC-C schema will be created by TCL at the client side or PL/SQL on the server. On the same system TCL will be faster, PL/SQL should be chosen if the network performance between the client and server or the CPU's available on the server will result in a higher performing schema creation. By default this option is not selected
<directory>The server side directory to be used for logging the output of the PL/SQL schema creation. by default this is left blank and set to the temporary directory assuming the same operating system as the client.
</directory>
</schema>
<driver>Parameters for the TPC-C schema driver script, populates the editable options in the script loaded under TPC->TPC-C Driver Script
<total_iterations>1000</total_iterations>The total number of transactions that the driver script will complete before logging off. These iterations are internal to the driver script and therefore when this number is complete it will register as 1 iteration of the entire script to the virtual user. This number should be set according to the performance of your server and the time you wish the entire script to take to complete. It should be borne in mind that if the virtual user is destroyed it will complete the number of total iterations given within the script until it looks to see if it has been destroyed i.e. you cannot interrupt it except for closing the application. If the virtual user is destroyed it will continue to run in the background
<raiseerror>false</raiseerror>Whether Oracle errors are raised to the virtual user causing the thread in which the error was detected to stop execution. By default errors are printed as output but the user will continue with the next transaction. Can be set to true or false
<keyandthink>true</keyandthink>This parameter can be true or false and determines whether the users simulate the activites of real users by pausing for periods between the transactions. If set to true this will require the creation of a large number of users to achieve high transaction rates. Setting to false requires a small number of users to achieve high levels of throughput however will result in a different an somewhat artifical transaction profile. Setting to false is useful however for discovering the theoretical maximum throughput of the system being tested
</driver>
</tpcc>
<tpch>The following parameters apply to the TPC-H benchmark only
<schema>Parameters for the TPC-H schema creation, populates the dialogue under TPC->TPC-H Schema Options
<scale_fact>1</scale_fact>The scale factor to be used for creating the TPC-H schema, can be 1, 10, 30 or 100
<tpch_user>tpch</tpch_user>The username of the owner of the TPC-H schema, can be any acceptable oracle user name
<tpch_pass>tpch</tpch_pass>The password for the owner of the TPC-H schema, can be any acceptable oracle user password
<tpch_def_tab>tpchtab</tpch_def_tab>The default tablespace for the TPC-H schema owner detailed in the option above, this tablespace must have already been created
<tpch_def_temp>temp</tpch_def_temp>The temporary tablespace for the TPC-H schema owner
</schema>
<driver>
<total_querysets>1</total_querysets>The total number of query sets of queries 1 through 22 to be executed by each user thread, can be any number
<raise_query_error>false</raise_query_error>Whether Oracle errors are raised to the virtual user causing the thread in which the error was detected to stop execution. By default errors are printed as output but the user will continue with the next transaction. Can be set to true or false
<verbose>false</verbose>Whether the query text and output is printed for each query, can be true or false
<degree_of_parallel>2</degree_of_parallel>The degree of parallelism to be used by the server for executing queries on the Oracle server (will only take effect on Oracle Enterprise Edition)
<refresh_on>false</refresh_on>If this parameter is set to true one user will execute a refresh stream whilst the other users are executing query streams. It is important to note that attempting to run the same refresh stream twice will result in constraint violations and therefore before running the refresh stream provisons should be made to restore or flashback the data if it is wished to run the same refresh stream again
<update_sets>1</update_sets>The number of refresh stream sets to run. This number will depend on how long it is wished for the refresh stream to run whilst the query sets are also running
<trickle_refresh>1000</trickle_refresh>The refresh stream may be trickled slowly to the server rather than creating a significant workload compared to query sets. The value is given in milliseconds and represents the pause between transactions
<refresh_verbose>false</refresh_verbose>Set to true or false to report the progress of the refresh stream
</driver>
</tpch>
<virtual_user_options>Parameters for the Virtual Users, populates the dialogue under Virtual Users->Vuser Options
<virtual_users>1</virtual_users>The Virtual Users to create, can be any number but common sense should be applied to create the number of client users you would expect the load testing system to support
<user_delay>500</user_delay>The pause taken between each user starting to execute the script in milliseconds. The default is half a second and must be either 0 or any positive value
<repeat_delay>500</repeat_delay>The pause taken by each user before executing the script again
<iterations>1</iterations>The total number of times that each user should execute the script in the edor pane
<show_output>0</show_output>Can be 0 or 1 and determines whether the output generated by the virtual users is displayed in a grid format
<log_to_temp>0</log_to_temp>Can be 0 or 1, if 1 the output of the virtual users is also recorded to a file called hammerora.log in the temporary directory
<unwind_threads>1</unwind_threads>Can be 0 or 1 and determines whether when the virtual users are destroyed they will be gracefully unwound or terminated. In either case the command will only be received when the executing script has completed and therefore the default is recommended
</virtual_user_options>
<transaction_counter>The following parameters apply to the transaction counter
<connect_string>system/manager@oracle</connect_string>The full connect string for a user with permissions to view v$sysstat on the target instance
<refresh_rate>10</refresh_rate>The period in seconds to be taken between sampling the database performance data
<rac>0</rac>Can be 0 or 1 and if 1 the transaction values from gv$sysstat will be used to report the transaction rate from all instances of a RAC cluster, if 0 just the transaction of the connected instance will be reported
<autorange>0</autorange>Can be 0 or 1, if 1 the transaction counter graph will zoom in to the values currently displaying at the time, this produces a 'peakier' effect on the graph but a finer grained view of the transaction activitiy
</transaction_counter>
<mode>The following values determine the mode in which a particular instance will operate
<slave_options>
<hostname>localhost</hostname>Gives the name of a master instance of Hammerora to connect to
<id>0</id>Gives the id of a master instance of Hammerora to connect to
</slave_options>
</mode>
</hammerora>
HTML and Web Testing
Hammerora enables you to test Web applications as well as your Oracle database environment. Hammerora enables web testing through the integration of the TclCurl package. To use TclCurl view the documentation available at the TclCurl homepage. You should also see curl, The art of HTTP scripting RFC 2396.As an example of the sort of options available to you the following script gives you an example framework with which to begin investigate HTML and web testing using TclCurl. The script selects a random search term from a list and then searches for that term on Google. The script then parses the output and displays the links that were returned by Google for the search term and thetime taken to display them. By creating multiple users and setting the user delay and repeat delay to 0 you can create searches for as many terms as you care to add to the list.
package require TclCurl
proc randlist {list} {
set ranval [ lindex $list [expr {int(rand()*[expr [llength $list]])}]]
return $ranval
}
proc HMtest_parse {tag state props body} {
if {$tag == "a" } {
if {[string match *class=l $props]} {
if {[regexp {href=\"?(.*)\"} $props match link]} {
puts $link
}
}
}
}
proc HMparse_html {html {cmd HMtest_parse} {start hmstart}} {
regsub -all \{ $html {\&ob;} html
regsub -all \} $html {\&cb;} html
set exp {<(/?)([^\s>]+)\s*([^>]*)>}
set sub "\}\n$cmd {\\2} {\\1} {\\3} \{"
regsub -all $exp $html $sub html
eval "$cmd {$start} {} {} \{ $html \}"
eval "$cmd {$start} / {} {}"
}
proc writeproc { data } {
HMparse_html $data
}
proc getUrl {url } {
puts "\n get url $url\n"
set curlHandle [ ::curl::init ]
$curlHandle configure -url $url \
-verbose 0 \
-errorbuffer errorBuffer \
-writeproc writeproc \
-failonerror 1 \
-followlocation 1
if { [ catch { $curlHandle perform } r ] == 0 } {
set continue true
} else {
$curlHandle cleanup
return -code error "$r $errorBuffer"
}
set totalTime [ $curlHandle getinfo totaltime ]
puts " Time = $totalTime "
$curlHandle cleanup
}
set searchlist [ split {Open+Source:Oracle:Linux:Database+Benchmarks:Hammerora:Oracle+RAC} : ]
set searchterm [ randlist $searchlist ]
puts "Searching Google for $searchterm"
getUrl www.google.com/search?hl=en&q=$searchterm&btnG=Google+Search
Based on this example you should have the starting point for how you can use TclCurl within Hammerora to generate multi-user load tests to test Oracle web based applications such as E-business suite or Oracle Enterprise Manager.
Oracle
Load Testing
Just like you need to get familiar with
TclCurl
for Web Testing and familarility with Oratcl is crucial to Oracle load
testing with Hammerora. You should therefore consult the Oratcl Homepage to see whats
possible.
As an example here is a simple script to put in the hammerora editor window (of course you need to change the connect string to your own database). The after command specifies the time to wait in milliseconds so just increase the value if you want the users to wait longer before logging off. The Oratcl commands are as intuitive as could be possible to interact with Oracle and therefore oralogon is used to logon. oraopen to create a cursor and orasql to execute sql against that cursor, oraclose closes the cursor and oralogoff logs off.
set connect tpch/tpch@ham10
puts "logging on to $connect.."
set lda [oralogon $connect]
set curn1 [oraopen $lda ]
set sql1 "select user from dual"
orasql $curn1 $sql1
after 40000
oraclose $curn1
oralogoff $lda
puts "connection closed"
------------------------------
PROGRAM
----------------------------------------------------------------
TPCH
wish84t.exe
wish84t.exe
wish84t.exe
wish84t.exe
wish84t.exe
wish84t.exe
You have now created your first Oratcl based load testing script. Remember that anything written in the TCL language is possible and given that Hammerora itself is written in TCL you have unlimited potential to test any environment you wish. For examples review the built-in load test scripts and schema builds based on the TPC-C and TPC-H schemas.
SQL
Trace and Replay
To
begin using
Hammerora the first step is to load an Oracle trace file under the
File:Open menu option. Before doing this therefore an Oracle trace file
must be generated using Oracle Event 10046. (There are numerous methods
to generate Oracle trace files of which only event 10046, level 4 to
capture bind variables is covered here).
As an example the simplest method to trace a session interactively is as follows:
SQL> alter session set events '10046 trace name context forever, level 4';
Session altered.
SQL> select sysdate from dual;
SYSDATE
---------
08-JUL-03
SQL> quit
To manually stop tracing use the following command:
SQL> alter session set events ‘10046 trace name context off’
For more advanced use the creation of a logon trigger is recommended. This trigger can then be enabled or disabled to capture the trace information for a particular use. The example uses the user SH from the Oracle demo schema.
create or replace trigger logon_trigger
after logon on database
begin
if ( user = 'SH' ) then
execute immediate
'alter session set events ''10046 trace name context forever, level 4''';
end if;
end;
/
The trigger must be created as SYS with SYSDBA privileges, if created by system the trigger will create successfully but fail on the user login.
This event will produce a trace file in the user_dump_dest specified in the init.ora file on the database server. (Not on the client machine). The file will be identifiable by ora_SPID.trc (there are methods that can be used to set the name of the trace file).
Note that in a Shared Server environment (previously MTS) one users session may be distributed across numerous trace files as the user processes share multiple server processes. Therefore in this environment it is necessary to reassemble the trace file data manually before parsing. Similarly the use of Application Servers and connection pooling may distribute the database calls across multiple server processes making it difficult to successfully identify a single users session data.
An example cut down trace from the statement above is as follows. For more information on the trace file format the document Note:39817.1 Subject “Interpreting Raw SQL_TRACE and DBMS_SUPPORT.START_TRACE output “ available from metalink is a useful reference.
*** 2003-07-08 13:29:20.391
*** SESSION ID:(39.42864) 2003-07-08 13:29:20.390
APPNAME mod='SQL*Plus' mh=3669949024 act='' ah=4029777240
=====================
PARSING IN CURSOR #1 len=68 dep=0 uid=5 oct=42 lid=5 tim=1032878281632851 hv=675021986 ad='76e1e7f8'
alter session set events '10046 trace name context forever, level 4'
END OF STMT
EXEC #1:c=0,e=155,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=1032878281631235
*** 2003-07-08 13:29:34.242
=====================
PARSING IN CURSOR #1 len=24 dep=0 uid=5 oct=3 lid=5 tim=1032878295158547 hv=3742653144 ad='75b13e74'
select sysdate from dual
END OF STMT
PARSE #1:c=0,e=3278,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=1032878295158530
BINDS #1:
EXEC #1:c=0,e=127,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=1032878295158990
FETCH #1:c=0,e=129,p=0,cr=3,cu=0,mis=0,r=1,dep=0,og=4,tim=1032878295159203
FETCH #1:c=0,e=2,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1032878295159890
XCTEND rlbk=0, rd_only=1
STAT #1 id=1 cnt=1 pid=0 pos=1 obj=222 op='TABLE ACCESS FULL OBJ#(222) (cr=3 r=0 w=0 time=101 us)'
Copy the trace file to the client machine where Hammerora is running and use the File:Open menu options or the “Open an existing file button”.
The Open File dialog allows the specifying of the Directory and a filter for the file type, by default this is *.trc. Highlight the name of the trace file and click OK. The trace file will be loaded.
Click the “Convert Oracle Trace file to Oratcl” button. The Trace file will be converted to TCL with Oratcl for the Oracle based commands as shown in the example below.
#!/usr/local/bin/tclsh8.4
package require Oratcl
####UPDATE THE CONNECT STRING BELOW###
#set connect user/password@oracle
set lda [oralogon $connect]
set curn1 [oraopen $lda ]
set sql1 "alter session set events '10046 trace name context forever, level 4' "
orasql $curn1 $sql1
oraclose $curn1
set curn1 [oraopen $lda ]
set sql1 "select sysdate from dual "
orasql $curn1 $sql1
set row [orafetch $curn1 -datavariable output ]
while { [ oramsg $curn1 ] == 0 } {
puts $output
set row [orafetch $curn1 -datavariable output ]
}
oraclose $curn1
oralogoff $lda
Note that the trace file never records a users authentication details. Therefore the connect string must always be modified manually after an Oratcl script is generated before running it.
Remove the comment before the “set connect” line and enter the correct username and password. The SID will be set by default to the SID that the trace file was taken from.
Next to the “Convert” button there is a “Test current code” button. Click on this to test the code in an individual TCL interpreter environment. Once tested the window can be closed manually or by clicking the same button now containing a stop image. The test environment is only for testing functionality and will not operate correctly with for example the Transaction Counter.
Once the script has been tested and is ready for running select the Virtual Users:Vuser Options menu option. The first option is the number of virtual users to create. There is no programmed limit here though a sensible approach is recommended to select a value in keeping with the number of Oracle client sessions the client server would be expected to handle. The Delay value is the value in milliseconds for each user to wait between executing the script. The Iterations value is the number of times each user is to execute the script. The show output check-box creates and output window for each user. Again there is no programmed limit though a sensible approach is recommended and more than 10 may be unmanageable. Finally the unwind threads check-box will mean the program wait until each thread completes before closing it. Click on OK to use the Virtual User Options selected.
Once the options have been selected click on the “Load Virtual Users” button. This will create the selected number of virtual users with their thread ids and status appearing in the bottom pane. The button also changes to “Destroy Virtual Users” Clicking on this will terminate the threads either attempting to kill them or waiting until they have completed. If executing a lengthy command however it may take some time for the exit command to reach the executing threads, there is no method to interrupt a running TCL thread until it has completed its current actions.
Once the Virtual User threads have been created it is necessary to destroy them before changing any of the options such as iterations or time delay.
Finally click the Run Hammerora Loadtest button. This posts the TCL script in the main window to all the TCL threads configured in the bottom pane. The status of the scripts is recorded in the bottom pane with any error text recorded back in the original command shell window.
Once complete click on “Destroy Virtual Users” to return back to an original starting state.
The save menu option or “Save current file” button can be used to save the generate TCL script for reloading at a later point.
It must be remembered that simply replaying data from a previous transaction may result in constraint violations or updates of data that no longer exists that results in errors during replay. Therefore the real power of Hammerora can be found by taking a converted tracefile and using this as a base for TCL to generate a more complex script. This can vary the activities of the users. Complex activities such as simulating a TPC-C type scenario have been generated by this method.
The following example is taken from the SH user of the Oracle Demo Schema installed from the $ORACLE_HOME/demo/schema directory. This example also illustrates the use of bind variables although using the random procedures is just as valid in simple SQL statements.
The following SQL statement sets up the bind variables and executes a select statement against the products table.
%sqlplus sh/sh@test
...
SQL> variable num1 number
SQL> variable num2 number
SQL> variable num3 number
SQL> variable pname varchar2(30)
SQL> execute :num1 := 10
PL/SQL procedure successfully completed.
SQL> execute :num2 := 90
PL/SQL procedure successfully completed.
SQL> execute :num3 := 7
PL/SQL procedure successfully completed.
SQL> execute :pname := '%Trousers%'
PL/SQL procedure successfully completed.
SQL> SELECT prod_name, prod_list_price, WIDTH_BUCKET(prod_list_price, :num1, :num2, :num3) AS prod_hist FROM products where prod_name LIKE :pname;
(Lines Deleted...)
PROD_NAME PROD_LIST_PRICE PROD_HIST
------------------------------------------------------------------
Rolled Edge-Knit Trousers 46 4
Navy Blue Trousers 30.99 2
Soft Elastic-Waist Trousers 46 4
Funcel-Blend Trousers Set 106 8
Funcel-Blend Trousers Set 106 8
Paisley-Stamped Trousers Set 112 8
Paisley-Stamped Trousers Set 112 8
Paisley-Stamped Trousers Set 112 8
690 rows selected.
SQL>
The trace file is captured loaded into Hammerora and parsed into the following:
#!/usr/local/bin/tclsh8.4
package require Oratcl
####UPDATE THE CONNECT STRING BELOW###
set connect sh/sh@test
set lda [oralogon $connect]
set curn1 [oraopen $lda ]
set sql1 "BEGIN :num1 := 10; END; "
oraparse $curn1 $sql1
oraplexec $curn1 $sql1 :num1 {NULL}
oraclose $curn1
set curn1 [oraopen $lda ]
set sql1 "BEGIN :num2 := 90; END; "
oraparse $curn1 $sql1
oraplexec $curn1 $sql1 :num2 {NULL}
oraclose $curn1
set curn1 [oraopen $lda ]
set sql1 "BEGIN :num3 := 7; END; "
oraparse $curn1 $sql1
oraplexec $curn1 $sql1 :num3 {NULL}
oraclose $curn1
set curn1 [oraopen $lda ]
set sql1 "BEGIN :pname := '%Trousers%'; END; "
oraparse $curn1 $sql1
oraplexec $curn1 $sql1 :pname {NULL}
oraclose $curn1
set curn1 [oraopen $lda ]
set sql1 "SELECT prod_name, prod_list_price, WIDTH_BUCKET(prod_list_price, :num1, :num2, :num3) AS prod_hist FROM products where prod_name LIKE :pname "
orasql $curn1 $sql1 -parseonly
orabindexec $curn1 :pname {%Trousers%} :num1 {10} :num2 {90} :num3 {7}
set row [orafetch $curn1 -datavariable output ]
while { [ oramsg $curn1 ] == 0 } {
puts $output
set row [orafetch $curn1 -datavariable output ]
}
oraclose $curn1
oralogoff $lda
In this example it is decided to randomly select the product name. The random list function is inserted into the script by selected the Procedures:Random List Menu option.
The function is then modified for us and the top of the file now looks like the excerpt below. The random list procedure is inserted and the example list set to include a list of some of the product names from the Oracle Demo schema products table.
#!/usr/local/bin/tclsh8.4
package require Oratcl
###RANDOM LIST PROCEDURE
proc randlist {list} {
set ranval [ lindex $list [expr {int(rand()*[expr [llength $list]])}]]
return $ranval
}
set example [ split {Kenny Cool:Lucky Brand:Pure Stuff:Stretch:T3:Yordsom:Zip-Front} : ]
set variable [ randlist $example ]
This variable is then used to replace the static entry in the orabindexec command as below:
orabindexec $curn1 :pname "%$variable%" :num1 {10} :num2 {90} :num3 {7}
By this method TCL selects at random from the provided list of variables Kenny Cool, Lucky Brand, Pure Stuff, Stretch, T3, Yordsom, Zip-Front and substitutes this into the bind variable :pname. Therefore multiple users will execute this random selection on each run varying the data input.
Note that the substitution occurs at the TCL level before sending the statement to Oracle so for example if T3 was randomly selected from the list parsing the generated tracefile would look as below.
orabindexec $curn1 :pname {%T3%} :num1 {10} :num2 {90} :num3 {7}
In addition to the
random list procedure
there are other procedures provided for varying the data input. Also
Hammerora will run any TCL commands therefore all manner of procedures,
functions and routines can be built for complex scenarios.
Note
that when assigning a
value to a variable Oracle uses a NULL bind as in the following example:
set
sql1 "BEGIN :test := 4; END; "
oraparse $curn1 $sql1
oraplexec $curn1 $sql1 :test {NULL}
This is the correct behaviour
instead of what may be expected as below, however the following
statement is incorrect:
oraplexec $curn1
$sql1 :test {4}
The value will
be preserved for use in the trace file so for example
this SQL:
SQL>
variable test number;
SQL> exec :test :=
4;
PL/SQL procedure
successfully completed.
SQL> select
:test from dual;
:TEST
----------
4
generates the
following trace with the same output as the original SQL:
set
curn1 [oraopen $lda ]
set sql1 "BEGIN :test := 4; END; "
oraparse $curn1 $sql1
oraplexec $curn1 $sql1 :test {NULL}
oraclose $curn1
set curn1 [oraopen $lda ]
set sql1 "select :test from dual "
orasql $curn1 $sql1 -parseonly
orabindexec $curn1 :test {4}
set row [orafetch $curn1 -datavariable output ]
while { [ oramsg $curn1 ] == 0 } {
puts $output
set row [orafetch $curn1 -datavariable output ]
}
oraclose $curn1
As previously mentioned
replaying database transactions is complex and many scenarios can
result
in errors at the testing stage. One of the most common
error messages received is is the standard PL/SQL failure reported by
Oratcl oraplexec: SQL execution failed.
To get the actual Oracle error
message underlying this error you can
use the TCL "catch" command to capture the error and print it out
inline. For example if you wanted to see the error in the neword
procedure of the TPC-C script change the oraplexec line to look like
the
following :
if {[ catch {oraplexec
$curn1 $sql5 :no_w_id $no_w_id :no_max_w_id $w_id_input :no_d_id
$no_d_id :no_c_id $no_c_id :no_o_ol_cnt $ol_cnt :no_c_discount {NULL}
:no_c_last {NULL} :no_c_credit {NULL} :no_d_tax {NULL} :no_w_tax {NULL}
:no_d_next_o_id {0} :timestamp $date} message]} {
puts $message
puts [ oramsg $curn1 all ]
}
So you are
adding the statements as below to the oraplexec statement
if {[ catch { ... }
message] } {
puts $message
puts [ oramsg $curn1 all ]
}
Note that the
cursor variable $curn1 used in oramsg is the same
variable used in the previous oraplexec.
You can then run the script by
pressing the test current code button (
or running one user thread with an output window )
The $message variable will
contain and print out ( using the "puts"
command ) any TCL error and the [
oramsg $curn1 all ] command will then print out the
oracle error
from the cursor $curn1.
An example is if the procedure
neword has not yet been created:
This then gives the full output
from Oracle as shown here instead of
just the standard message :
new order
{6550 {ORA-06550: line 1, column 7:
PLS-00201: identifier 'NEWORD' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored} 0 0 4 8}
A Transaction counter is provided to monitor a level of transaction rates over a delta period.
A suggested next step for tracing an application is to use the “Sample Instrumented Application” provided in $ORACLE_HOME/otrace/demo. The instructions to create this are reproduced here for ease of use:
Log in as System and create the ATM user:
SQL> create user atm identified by sampleatm
2> default tablespace <atm_space> quota
3> unlimited on <atm_space>;
SQL> grant connect,resource, alter session to atm;
Login as atm, and execute the following:
SQL> @atmtab
SQL> @atmdat100
SQL> @atmind
Login as sys with sysdba privileges and create the logon trigger to trace the ATM user.
create or replace trigger logon_trigger
after logon on database
begin
if ( user = 'ATM' ) then
execute immediate
'alter session set events ''10046 trace name context forever, level 4''';
end if;
end;
/
Compile the sample OCI application as follows:
make –f atmoci.mk atmoci
Run the sample application interactively using ./atmoci.
After quitting the application collect the generated tracefile and convert to Oratcl using Hammerora. This is then a good starting point for building a first database load scenario.
When creating load-tests The TCL "time" and "clock" commands can prove
useful for showing the execution time in microseconds of SQL statements.
Back to Top
Remote Modes
Hammerora allows for multiple instances
of the Hammerora program to run in Master and Slave modes. Running with
multiple modes enables the additional instances to be controlled by a
single master instance either on the same load testing server or
accross the network. This functionality can be particulalry applicable
when testing Real Application Clusters and wishing to partition a load
precisely accross servers.
To
create a Master client select "Select
Mode" from the Mode menu
and select Master Mode.
On confirming the
switch a message box and the message printed in the console displays
the
id of the master client.
Note that at this point the Master Distribution button becomes active. It is then possible in another instance of the program to select to run in Slave mode. Firstly In the slave options choice from the mode menu enter the id number and hostname of the master.
The slave must be
able to resolve this hostname and this hostname to use should be
returned by
the TCL command "info". For example in the console window type the
following
(hammerora-2.1)
11 % puts [ info hostname ]
dragonfly.home
(hammerora-2.1) 12 %
Then
select slave mode under the "Select Mode" menu to connect
to the Master
At
this point after loading a file in the master it will
possible to distribute this file to one or more slave clients with
the now active
Master Distribution button. You may edit this text in each individual
slave to modify the behaviour of each client.
In addition all of
Virtual User functionality operated on the
master is
replicated on the slaves including setting virtual user parameters,
creating and destroying virtual users and running them. Full
functionality also remains on the slaves if a custom
configuration if required.