用orabm测试oracle服务器的TPS值

用orabm测试oracle服务器的TPS值

用orabm测试oracle服务器的TPS值

1、orabm简介
   Orabm是一个开源的oracle性能测试工具，，包含了一套SQL脚本和几个命令行程序。

作者Geoff Ingram，是《High-Performance Oracle: Proven Methods for Achieving Optimum Performance and Availability》一书的作者。

该工具可以从作者的主页（http://www.dbcool.com/）获得，具体下载地址是http://www.linxcel.co.uk/orabm/orabm.tar

2、安装orabm
   下载的orabm是一个tar包，一般可以将该文件上传到oracle服务器上，方便直接运行SQL脚本。
   本次测试的环境是：AIX 5.2 ，oracle 9.2.0.1，操作系统用户是oracle

   使用orabm的用户必须具有oracle的相关环境变量，本次测试中用的是oracle用户。

（1）解包
$ tar xvf orabm.tar
x orabm, 0 bytes, 0 tape blocks
x orabm/src, 0 bytes, 0 tape blocks
x orabm/src/orabmload.pc, 24200 bytes, 48 tape blocks
x orabm/src/orabm.c, 9346 bytes, 19 tape blocks
x orabm/src/init.ora, 1442 bytes, 3 tape blocks
x orabm/src/BUILD_FROM_SOURCE.txt, 863 bytes, 2 tape blocks
x orabm/install, 0 bytes, 0 tape blocks
x orabm/install/orabm_analyze.sql, 1068 bytes, 3 tape blocks
x orabm/install/orabm_cache.sql, 1116 bytes, 3 tape blocks
x orabm/install/orabm_ind.sql, 1124 bytes, 3 tape blocks
x orabm/install/orabm_query_cache.sql, 497 bytes, 1 tape blocks
x orabm/install/orabm_serverside_stress.sql, 8528 bytes, 17 tape blocks
x orabm/install/orabm_tab.sql, 2321 bytes, 5 tape blocks
x orabm/install/orabm_tab_rm.sql, 197 bytes, 1 tape blocks
x orabm/install/orabm_user.sql, 233 bytes, 1 tape blocks
x orabm/bin, 0 bytes, 0 tape blocks
x orabm/bin/orabm_tps.awk, 182 bytes, 1 tape blocks
x orabm/bin/orabm_tps.sh, 70 bytes, 1 tape blocks
x orabm/bin/solaris, 0 bytes, 0 tape blocks
x orabm/bin/solaris/orabmload, 85940 bytes, 168 tape blocks
x orabm/bin/solaris/orabm, 53140 bytes, 104 tape blocks
......

解包完成以后就可以开始安装了，其实主要就是运行SQL脚本建立测试环境。

安装进度表如下：
# Operation Command
1 create the ORABM user (assumes TOOLS tablespace, TEMP temporary tablespace) sqlplus system/pwd @orabm_user
2 create the tables sqlplus system/pwd @orabm_tab
3 load the data $ orabmload Warehouses 1
4 create the indexes sqlplus system/pwd @orabm_ind
5 analyze the tables and indexes sqlplus system/pwd @orabm_analyze
6 create the stress-test PL/SQL procedures sqlplus system/pwd @orabm_serverside_stress
7 cache the table and index data in the SGA sqlplus system/pwd @orabm_cache

（2）建数据库用户和表
对应于安装进度表的第1、2两个步骤

注意：由于所建用户ORABM的缺省表空间是TOOLS，因此最好在安装之前（起码在装载数据之前）将TOOLS表空间扩大到150MB左右。虽然一般TOOLS表空间都设置为AUTOEXTENT，但是还是会影响装载数据的速度，后面的步骤会看到装载的数据是比较大的。

$ ls
orabm_analyze.sql            orabm_serverside_stress.sql
orabm_cache.sql              orabm_tab.sql
orabm_ind.sql                orabm_tab_rm.sql
orabm_query_cache.sql        orabm_user.sql

$ sqlplus "/ as sysdba" @orabm_user

SQL*Plus: Release 9.2.0.1.0 - Production on Wed Jan 26 14:32:48 2005

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - 64bit Production
With the Partitioning and OLAP options
JServer Release 9.2.0.1.0 - Production
User created.

Grant succeeded.

User altered.

User altered.

Revoke succeeded.

Disconnected from Oracle9i Enterprise Edition Release 9.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 – Production

$ sqlplus "/ as sysdba" @orabm_tab

SQL*Plus: Release 9.2.0.1.0 - Production on Wed Jan 26 14:32:48 2005

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - 64bit Production
With the Partitioning and OLAP options
JServer Release 9.2.0.1.0 - Production

Table created.

Table created.

Table created.

Table created.

Table created.

Table created.

Table created.

Table created.

Table created.

Disconnected from Oracle9i Enterprise Edition Release 9.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production

（3）装载数据
对应于安装进度表中的第3个步骤

按照步骤描述，本来这个应该在oracle服务器上运行orabmload来完成，但是程序包中的orabmload程序只有linux、solaris、windows三个平台下的，没有AIX平台下的。

但orabm是开源的程序，在src目录下就是源程序
$ ls -l
total 88
-rw-r--r--   1 oracle   dba             863 Nov 07 2002  BUILD_FROM_SOURCE.txt
-rw-r--r--   1 oracle   dba            1442 Nov 07 2002  init.ora
-rw-r--r--   1 oracle   dba            9346 Nov 07 2002  orabm.c
-rw-r--r--   1 oracle   dba           24200 Nov 07 2002  orabmload.pc

其中 orabm.c、orabmload.c 是两个应用程序的源程序，BUILD_FROM_SOURCE.txt 是编译说明。我按照编译说明上的指导，make了一下，但是最后运行程序的时候出错，也许是还有什么编译选项不对吧。下面是运行错误：
$ ./orabmload Warehouse 1
exec(): 0509-036 Cannot load program ./orabmload because of the following errors
:
        0509-150   Dependent module /home/oracle/OraHome1/lib32/libclntsh.a(shr.
o) could not be loaded.
        0509-124 The program is a discontinued 64-bit object file.

------------后记------------
后面发现是程序链接的库文件错了，不应该链接 /home/oracle/OraHome1/lib32/ 目录，这是为32位程序准备的，应该链接 /home/oracle/OraHome1/lib/ ，缺省就是64位。
按此修改了一下主机用户oracle的.profile文件，然后重新登录，再编译一下，最后运行是没有问题的。
------------后记结束------------

还好的是，orabm预先提供windows版本的数据装载程序，在 orabm/bin/windows 目录下就是。
将orabm拷贝或者FTP到windows平台的机器上，配置好oracle连接，即可装载数据了，如下：

E:\temp>set LOCAL=ccbver

E:\temp>orabmload Warehouse 1

Connected to ORACLE as user: ORABM
using timestamp=20050126103630
TPCC Data Load Started...
Loading Item
.................... 20000
.................... 40000
.................... 60000
.................... 80000
.................... 100000
Item Done.
Loading Warehouse
Loading Stock Wid=1
.................... 20000
.................... 40000
.................... 60000
.................... 80000
.................... 100000
 Stock Done.
Loading District
Loading Customer for DID=1, WID=1
...Customer Done.
Loading Customer for DID=2, WID=1
...Customer Done.
Loading Customer for DID=3, WID=1
...Customer Done.
Loading Customer for DID=4, WID=1
...Customer Done.
Loading Customer for DID=5, WID=1
...Customer Done.
Loading Customer for DID=6, WID=1
...Customer Done.
Loading Customer for DID=7, WID=1
...Customer Done.
Loading Customer for DID=8, WID=1
...Customer Done.
Loading Customer for DID=9, WID=1
...Customer Done.
Loading Customer for DID=10, WID=1
...Customer Done.
Loading Orders for D=1, W= 1
. 1000
. 2000
. 3000
Orders Done.
Loading Orders for D=2, W= 1
. 1000
. 2000
. 3000
Orders Done.
Loading Orders for D=3, W= 1
. 1000
. 2000
. 3000
Orders Done.
Loading Orders for D=4, W= 1
. 1000
. 2000
. 3000
Orders Done.
Loading Orders for D=5, W= 1
. 1000
. 2000
. 3000
Orders Done.
Loading Orders for D=6, W= 1
. 1000
. 2000
. 3000
Orders Done.
Loading Orders for D=7, W= 1
. 1000
. 2000
. 3000
Orders Done.
Loading Orders for D=8, W= 1
. 1000
. 2000
. 3000
Orders Done.
Loading Orders for D=9, W= 1
. 1000
. 2000
. 3000
Orders Done.
Loading Orders for D=10, W= 1
. 1000
. 2000
. 3000
Orders Done.

...DATA LOADING COMPLETED SUCCESSFULLY

成功装载数据，需要的时间可能有点长。

 

（4）建索引、分析表和索引、建压力测试存储过程、将数据装载到cache
对应于安装进度表中的第4、5、6、7步骤
这几个步骤都是执行SQL脚本，在oracle服务器上执行即可。
$ cd  install
$ ls
orabm_analyze.sql            orabm_ind.sql                orabm_serverside_stress.sql  orabm_tab_rm.sql
orabm_cache.sql              orabm_query_cache.sql        orabm_tab.sql                orabm_user.sql
$ sqlplus "/ as sysdba" @orabm_ind
SQL*Plus: Release 9.2.0.1.0 - Production on Wed Jan 26 14:32:48 2005

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - 64bit Production
With the Partitioning and OLAP options
JServer Release 9.2.0.1.0 - Production
......
$ sqlplus "/ as sysdba" @ orabm_analyze
...........
$ sqlplus "/ as sysdba" @ orabm_serverside_stress
......
$ sqlplus "/ as sysdba" @ orabm_cache
......

这后面执行的SQL脚本都不会有什么问题，记住步骤顺序即可。

至此，orabm的安装已经完成了。

3、测试TPS值
   Orabm安装完成以后，就可以开始测试oracle服务器的TPS值了。
   同样的，在本次测试中，由于应用程序没有AIX版本，所以只能在windows平台作为oracle客户端来执行测试程序了。

（1）orabm的原理
我们先通过作者主页上的一段话来了解一下orabm的原理。

Orabm works by running a user-specified number of database transactions in each of a user-specified number of concurrent database sessions.
Orabm通过在用户指定的并发下运行指定数量的事务来测试系统性能.
The transactions are executed by the ORABM_SERVERSIDE_STRESS stored procedure, under the schema ORABM.
事务通过执行orabm用户的ORABM_SERVERSIDE_STRESS过程来实现.

For each concurrent session, ORABM_SERVERSIDE_STRESS runs the number of transactions specified on the orabm command line, and returns the transactions per second (TPS) value for that session during the sampling interval on completion.
对于每个并发session,ORABM_SERVERSIDE_STRESS运行在orabm命令行指定数量的事务，并返回在完成所有任务的采样间隔内每秒的事务数量.
To ensure that all concurrent sessions are processing transactions during the sampling interval, the TPS value only includes results from the middle 80% of transactions: the first 10% and last 10% are ignored.
为了保证准确性,TPS值只取中间的80%数据,头尾的10%都将被忽略.

The transactions are loosely based on the TPC-C Order-Status and Stock-Level transactions, using a predefined distribution of transactions.
事务是松散的,基于标准的TPC-C测试的订单、库存事务模型,使用预定义的事务分布.
The transaction split, which is based on data returned by the DBMS_RANDOM package, should be:
事务基于DBMS_RANDOM包的返回值进行分割,应该是:

Stock-Level:Order-by-Customer-Name:Order-by-Customer-Id
50% :30% :20%

The string returned by ORABM_SERVERSIDE_STRESS includes the transaction split during the test, to ensure that the transaction distribution is correct, subject to random fluctuations e.g.:
为了确保事务分布的正确性,ORABM_SERVERSIDE_STRESS的输出包含事务分割比例,输出结果具有随机波动,例如:

...sl=4042(50.5%) on=2384(29.8%) oi=1573(19.7%)...

Once you have set up the test tables, data, and indexes, you're ready to run orabm. The following command shows orabm running 20000 transactions in a single session against the Oracle database identified by ORACLE_SID in the UNIX environment:
在成功安装了orabm之后,在UNIX下定义好了ORACLE_SID环境变量之后,我们可以如下运行orabm命令进行测试:

$ orabm 1 20000

This command line runs the same workload against a remote database identified by the Oracle Net alias linxceld1.co.uk from a Windows command box:
以下是在WINDOWS下远程运行方式:

C:\> orabm 1 20000 linxceld1.co.uk

Note: running against a remote database has little (if any), affect on the transaction throughput, because all processing takes place on the DBMS server.

Execution of a single Orabm session should show a single CPU at close to 100% utilization, provided that all table and index data is present in the Oracle block buffer cache and no other workload is running on the database server. On UNIX or Linux, you can use the “top” command to confirm this, or check that no "db file sequential read" event waits are taking place for the Oracle session using info in the V$SESSION_EVENT view - these indicate waits for physical I/O.

如果所有的测试表和相关索引都已经Cache到内存中,系统上没有其他任务运行,那么你可以看到单个Orabm Session会使用将近100%的CPU资源.在Linux或者Unix上，可以使用Top来查看CPU使用情况,或者检察数据库中不存在"db file sequential read"等待事件.

Alternatively, if your Oracle DBMS is running on Linux, you can use the gkrellm performance monitor to show that CPU utilization of a single CPU is at ~100% and no physical I/O is taking place. Gkrellm can be downloaded from:

http://web.wt.net/~billw/gkrellm/gkrellm.html

Here's an example of the command line you would use to run 10000 transactions against a local Oracle database for three iterations. In the first iteration, one session runs, in the second iteration two concurrent sessions run, and in the third iteration, six concurrent sessions run:

以下是一个测试例子,对本地数据库进行三个阶段测试,分别以1,2,6个并发执行10000个事务.

$ orabm 1,2,6 10000

Keep in mind that the specified number of transactions is run in each concurrent session.

注意,这里定义的10000个事务是对每个session来说的.

Note: you should specify sufficient transactions such that the TPS results produced don't fluctuate significantly between runs for a given number of sessions; 100000 is a good value to choose.

注意：你应该定义足够的事务以便TPS结果在不同数量并发下波动尽量小,通常100,000是一个好的选择.

Results Output

Output is appended to a log file orabm.database.log, where database is either the ORACLE_SID or TNS alias that identifies the database where the test was run e.g. orabm.t92.log. For each iteration, the TPS value for each concurrent session appears between begin and end markers. For example, the following shows the contents of the log for two concurrent sessions - in this case the second iteration for the previous command line example - where txn(all) displays the total transaction count, and xn(sam) and t(sam) show the total transactions and time for the middle 80% of transactions for which sampling took place:

输出结果的说明:
txn(all)----代表Total transaction Count,总的事务数量.
xn(sam)-----采样的事务数量
t(sam)------采样事务运行的时间.

---begin sess=2 txn=10000 ORACLE_SID=t92 Fri Nov 8 20:31:48 2002
T92.WORLD txn(all)=10000 xn(sam)=7999 t(sam)=44 tps=182 ...
T92.WORLD txn(all)=10000 xn(sam)=7999 t(sam)=45 tps=178 ...
---end - Fri Nov 8 20:32:46 2002

The total TPS for this iteration is the sum of the TPS for the two concurrent sessions (182+178=360).
对于以上输出,在2个并发下,TPS值为182+178=360

A shell script (orabm_tps.sh) can be used to process output from the log on UNIX and Linux. The script aggregates the TPS values for concurrent sessions in a single iteration into a total TPS value for that iteration. The output based on the log info from the previous command line (3 iterations with 1, then 2, then 6 concurrent sessions) shows:
也可以用shell script(orabm_tps.sh)进行输出日志分析.

$ orabm_tps.sh orabm.t92.log
ORACLE_SID=t92 sess=1 tps=182
ORACLE_SID=t92 sess=2 tps=360
ORACLE_SID=t92 sess=6 tps=364

In this example the server was a 2 CPU model - as a result, 2 concurrent sessions running in orabm are enough to completely utilize all available CPU capacity.
在这个例子中,Server有两个CPU,测试中两个并发足以消耗所有的CPU资源.

Additional sessions should result in the total TPS remaining unchanged, or even falling slightly as the operating system performs context switches to share the overloaded CPU resource between more ready-to-run sessions than available CPUs.
继续增加并发并不会导致TPS值得增加,甚至有可能会下降.

（2）测试TPS值
下面我们来具体跑一下程序。

 

在跑程序之前，要注意一下：前面的例子应该可以看到，在windows平台下运行orabmload时，设置了 LOCAL 变量，这个变量相当于UNIX平台下的ORACLE_SID，这次运行orabm程序，却有所不同，见下面的运行日志：

E:\temp>orabm 1,2,6,10 10000
ORACLE_SID not set

E:\temp>set LOCAL=ccbver

E:\temp>orabm 1,2,6,10 10000
ORACLE_SID not set

E:\temp>set ORACLE_SID=ccbver

E:\temp>orabm 1,2,6,10 10000
---begin sess=1 txn=10000 ORACLE_SID=ccbver Wed Jan 26 11:03:45 2005
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=17 tps=471 sl=3918(49%) on=2483(31%) o
i=1598(20%) end=260105-10:05:58
---end - Wed Jan 26 11:04:09 2005
---begin sess=2 txn=10000 ORACLE_SID=ccbver Wed Jan 26 11:04:09 2005
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=17 tps=471 sl=3999(50%) on=2441(30.5%)
 oi=1559(19.5%) end=260105-10:06:19
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=17 tps=471 sl=4025(50.3%) on=2396(30%)
 oi=1578(19.7%) end=260105-10:06:19
---end - Wed Jan 26 11:04:31 2005
---begin sess=6 txn=10000 ORACLE_SID=ccbver Wed Jan 26 11:04:31 2005
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=43 tps=186 sl=4041(50.5%) on=2372(29.7
%) oi=1586(19.8%) end=260105-10:07:13
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=43 tps=186 sl=4017(50.2%) on=2404(30.1
%) oi=1578(19.7%) end=260105-10:07:13
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=42 tps=190 sl=3917(49%) on=2505(31.3%)
 oi=1577(19.7%) end=260105-10:07:14
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=43 tps=186 sl=4016(50.2%) on=2394(29.9
%) oi=1589(19.9%) end=260105-10:07:14
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=43 tps=186 sl=4038(50.5%) on=2316(29%)
 oi=1645(20.6%) end=260105-10:07:14
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=47 tps=170 sl=4011(50.1%) on=2380(29.8
%) oi=1608(20.1%) end=260105-10:07:15
---end - Wed Jan 26 11:05:26 2005
---begin sess=10 txn=10000 ORACLE_SID=ccbver Wed Jan 26 11:05:26 2005
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=72 tps=111 sl=3969(49.6%) on=2390(29.9
%) oi=1640(20.5%) end=260105-10:08:45
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=72 tps=111 sl=4061(50.8%) on=2407(30.1
%) oi=1531(19.1%) end=260105-10:08:45
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=73 tps=110 sl=3996(50%) on=2444(30.6%)
 oi=1559(19.5%) end=260105-10:08:46
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=72 tps=111 sl=4089(51.1%) on=2334(29.2
%) oi=1576(19.7%) end=260105-10:08:46
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=71 tps=113 sl=3935(49.2%) on=2468(30.9
%) oi=1596(20%) end=260105-10:08:46
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=74 tps=108 sl=4015(50.2%) on=2380(29.8
%) oi=1604(20.1%) end=260105-10:08:47
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=72 tps=111 sl=4008(50.1%) on=2446(30.6
%) oi=1545(19.3%) end=260105-10:08:47
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=76 tps=105 sl=3939(49.2%) on=2454(30.7
%) oi=1606(20.1%) end=260105-10:08:48
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=76 tps=105 sl=4061(50.8%) on=2333(29.2
%) oi=1605(20.1%) end=260105-10:08:48
CCBVER txn(all)=10000 xn(sam)=7999 t(sam)=77 tps=104 sl=3932(49.2%) on=2432(30.4
%) oi=1635(20.4%) end=260105-10:08:48
---end - Wed Jan 26 11:06:59 2005

原来还要设置 ORACLE_SID 变量！

我跑的这个例子是分四个案例：
第一个是1个并发session跑10000个事务；
第二个是2个并发session跑10000个事务；
第三个是6个并发session跑10000个事务；
第四个是10个并发session跑10000个事务。

测试程序运行结束后，会生成一个orabm.{ORACLE_SID}.log的文件，比如上面这个例子，生成的文件是 orabm.ccbver.log，该文件是累加的，如果继续跑测试程序，其测试结果会累加到这个文件中。

（3）格式化输出
其实从上面的运行结果中已经差不多可以看出TPS的值了，把并发session的TPS值相加即可。不过，orabm程序包中有一个格式化输出结果的SHELL脚本，可以看得更加清楚。
当然，得把日志文件上传到服务器上去运行，毕竟是SHELL程序嘛。
看结果：
$ ./orabm_tps.sh orabm.ccbver.log
ORACLE_SID=ccbver sess=1 tps=471
ORACLE_SID=ccbver sess=2 tps=942
ORACLE_SID=ccbver sess=6 tps=1104
ORACLE_SID=ccbver sess=10 tps=1089

可以看出，这台机器的TPS值大概在1100左右。

后来把事务数变为100000，再跑了一下，结果也差不多，如下：
$ ./orabm_tps.sh orabm.ccbver.log
ORACLE_SID=ccbver sess=1 tps=530
ORACLE_SID=ccbver sess=2 tps=979
ORACLE_SID=ccbver sess=6 tps=1106
ORACLE_SID=ccbver sess=10 tps=1097

 

转载于： http://www.cnblogs.com/rootq/archive/2009/07/09/1520127.html