HammerDBをCLIで使うなど（４）：OracleにTPC-Cを実行してみる

基本的な流れ

流れはMySQLやPostgreSQL同じですが、やっぱりパラメータがちょっと違います。
さっそく順を追ってみていきましょう。

対象DBMSとベンチマークの選択

hammerdb>dbset db ora
Database set to Oracle

hammerdb>dbset bm TPC-C
Benchmark set to TPC-C for Oracle

Oracleもフルネームじゃなくてoraだけ。

詳細パラメータの表示と設定

hammerdb>print dict
Dictionary Settings for Oracle
connection {
 system_user     = system
 system_password = manager
 instance        = oracle
 rac             = 0
}
tpcc       {
 count_ware       = 1
 num_vu           = 1
 tpcc_user        = tpcc
 tpcc_pass        = tpcc
 tpcc_def_tab     = tpcctab
 tpcc_ol_tab      = tpcctab
 tpcc_def_temp    = temp
 partition        = false
 hash_clusters    = false
 tpcc_tt_compat   = false
 total_iterations = 1000000
 raiseerror       = false
 keyandthink      = false
 checkpoint       = false
 ora_driver       = test
 rampup           = 2
 duration         = 5
 allwarehouse     = false
 timeprofile      = false
}

気になるパラメータがチラチラ見えてますね。

PostgreSQLと同様、管理ユーザーとベンチマーク実行ユーザーが別々になっていますが、その管理側のパラメータの位置が、connectionの要素に存在しています。

また、「rac」というパラメータもありますが、公式サイトのドキュメントにこのパラメータの説明が書いてない。。。
GUI版で起動しても、racに相当するパラメータがぱっと見つからない。。。
そんな状態から、RAC環境用意して手探りで挙動確認するのは時間的につらいので、またあとで。

tpccパラメータの意味は以下のとおりです。

名称	説明	初期値
count_ware	シナリオに登場する「倉庫（warehouse）」の数＝データのサイズ（≒スケールファクタ）。	1
num_vu	同時実行ユーザー数。	1
tpcc_user	接続先oracleデータベースに接続するTPCCトランザクション用のユーザー。	tpcc
tpcc_pass	接続先oracleデータベースに接続するTPCCトランザクション用のユーザーのパスワード。	tpcc
tpcc_def_tab	接続先oracleデータベースのデフォルト表領域。	tpcctab
tpcc_ol_tab	倉庫（warehouse=cont_ware）が200以上のとき、Order_Lineテーブルがアクティブになるが、その際に使用するブロックサイズが異なる表領域を別途使用することができる。	tpcc
tpcc_def_temp	接続先oracleデータベースのデフォルト一時表領域。	temp
partition	倉庫（warehouse=cont_ware）が200以上のとき、Order_Lineテーブル）を100のパーティションに分割する。	false
hash_clusters	パーティショニングが有効なときに、HASHパーティショニングを採用する。	false
tpcc_tt_compat	OracleTimesTenデータソース名を利用する。	false
total_iterations	トランザクションの実行回数。	1000000
raiseerror	エラーが起きても続ける（false)か、exitする（true）かのスイッチ。	false
keyandthink	公式TPC-C要件により近づけるための「思考判断時間」のシミュレートを行うスイッチ。	false
ora_driver	環境整整備、動作検証までは「test」を、実計測時は「timed」を指定する。	test
rampup	いわゆるテスト開始～計測開始までの暖気処理時間。	2
duration	複数ユーザーが時差を持ってアクセスするための遅延処理。	5
allwarehouse	シナリオに登場する倉庫（warehouse）に対し、ユーザーが利用する倉庫はデフォルトでは固定されるが、trueにするとランダムに倉庫を選択するようになる。	false
timeprofile	応答時間プロファイル（etprof）の生成スイッチ。trueにすると、10秒間隔での応答時間パーセンタイル、完了時の累積値がレポートされる。	false

Incetant Clientを使用していて、TNSNAMESの設定を行っていない場合、EZCONNECTで接続することになります。
その場合は、「instance」を「{hostname or ip}:{port}/{database_name}」の形式で指定します。

今回も、driverとtimeprofileを変更して実行します。

hammerdb>diset tpcc ora_driver timed
Clearing Script, reload script to activate new setting
Script cleared
Changed tpcc:ora_driver from test to timed for Oracle

hammerdb>diset tpcc timeprofile true
Changed tpcc:timeprofile from false to true for Oracle

余談ですが、MySQLやPostgreSQLのときのように、パラメータ名に「ora」ってついてない（ものが多い）ですね。
これ、HammerDBがOracle用ベンチマークソフト「hammerora」として生まれた名残かと思います。

スキーマ作成

テストで流す前に必要なスキーマ作成、及び、テストデータの投入を実行します。

テスト用ユーザー「TPCC」はbuildschemaの中で自動作成してくれます（むしろ先に存在してはいけない）が、表領域は先に作成されている必要があります。
すでに作ってあるテーブルスペースに設定し直すか、tpcctabというテーブルスペースを新規に作成しておきましょう。

MySQLと同様、num_vuで指定した数だけクライアントが立ち上がり、並列実行でテストデータを投入します。

hammerdb>buildschema
....
ALL VIRTUAL USERS COMPLETE

処理が完了しても、データ生成のために立ち上がったクライアントプロセスは起動したままになります。
次の処理の前に、スキーマ作成用のユーザーセッションが完了しているか確認するコマンドを投げて確認し、完了ステータスになっていたら、そのセッションは一度破棄しておきます。

hammerdb>vustatus
1 = FINISH SUCCESS

hammerdb>vudestroy
Destroying Virtual Users
Virtual Users Destroyed
vudestroy success

hammerdb>vustatus
No Virtual Users found

テストスクリプトのロード

ここから先はMySQLやPostgreSQLと同じですので、さらっと流します。

hammerdb>loadscript
Script loaded, Type "print script" to view

テスト実行用クライアント（Virtual User）の設定

ワークロードを実行するために接続する同時実行ユーザー数を確認・調整します。

hammerdb>print vuconf
Virtual Users = 1
User Delay(ms) = 500
Repeat Delay(ms) = 500
Iterations = 1
Show Output = 1
Log Output = 0
Unique Log Name = 0
No Log Buffer = 0
Log Timestamps = 0

hammerdb>vuset
Usage: vuset [vu|delay|repeat|iterations|showoutput|logtotemp|unique|nobuff|timestamps] value

hammerdb>vuset vu 4

hammerdb>vuset logtotemp 1

hammerdb>vuset unique 1

hammerdb>vuset timestamps 1

hammerdb>print vuconf
Virtual Users = 4
User Delay(ms) = 500
Repeat Delay(ms) = 500
Iterations = 1
Show Output = 1
Log Output = 1
Unique Log Name = 1
No Log Buffer = 0
Log Timestamps = 1

テスト実行用クライアント（Virtual user）の起動

設定に従ってクライアント（Virtual user）を起動します

hammerdb>vucreate
Vuser 1 created MONITOR - WAIT IDLE
Vuser 2 created - WAIT IDLE
Vuser 3 created - WAIT IDLE
Vuser 4 created - WAIT IDLE
Vuser 5 created - WAIT IDLE
Logging activated
to /tmp/hammerdb_5D64B872591103E283538383.log
5 Virtual Users Created with Monitor VU

hammerdb>vustatus
1 = WAIT IDLE
2 = WAIT IDLE
3 = WAIT IDLE
4 = WAIT IDLE
5 = WAIT IDLE

テストの実行

hammerdb>vurun

で実行し、終わるまで待ちます。

実行結果の出力例

大量に出力されますが、スコアを見るのはこの1行ですね。

Vuser 1:TEST RESULT : System achieved 77123 Oracle TPM at 25992 NOPM

読み方はMySQL、PostgreSQLのTPC-Cのときと同じです。
しつこいですが、数字は前回のMySQLやPostgreSQLと比較しないでください。ベースとなるマシンのスペックが全然違いますので、何の比較にもなりません。

こんな感じで、Oracleに対するTPC-Cが実行できました。

まとめ

• やはり若干パラメータが異なる。
• MySQLと異なり、テスト用ユーザーの作成もbuildschemaの中で行う。むしろ先に存在していてはいけない。
• でも、表領域は事前に作成されていないとbuildschemaできない。

パーティション周り、実際どうなるのか試してみたい。あとRACパラメータ。

WEB+DB PRESS Vol.112