基本的な流れ
流れは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と比較しないでください。ベースとなるマシンのスペックが全然違いますので、何の比較にもなりません。
まとめ
- やはり若干パラメータが異なる。
- MySQLと異なり、テスト用ユーザーの作成もbuildschemaの中で行う。むしろ先に存在していてはいけない。
- でも、表領域は事前に作成されていないとbuildschemaできない。
パーティション周り、実際どうなるのか試してみたい。あとRACパラメータ。
- 作者:樋口剛,篠田典良,谷口慶一郎,大沼由弥,豊島正規,三村益隆,笹田耕一,牧大輔,大原壯太,門松宏明,鈴木恭介,新倉涼太,末永恭正,久保田祐史,池田拓司,竹馬光太郎,はまちや2,竹原,粕谷大輔,泉征冶
- 出版社/メーカー:技術評論社
- 発売日: 2019/08/24
- メディア:単行本（ソフトカバー）
- この商品を含むブログを見る