Oracle 大量データの作成はCOMMITによってどれくらい遅くなるか

2015.04.01 株式会社システムインテグレータ

「テストのためなど、大量のデータを作成するとき、COMMITの回数が増えるとそのオーバーヘッドによりデータの作成に時間がかかる」と言われています。わりと知られている情報なので、ご存知の方もいるのではないでしょうか。しかし、実際どれくらい遅くなるかを試した方はそれほどいないのではないかと思います。
１回ずつコミット、ある件数単位でコミット、最後にまとめてコミット、などによりどのような速度の違いがあるか、法則性はあるのかを具体的に検証していきたいと思います。

Oracle 大量データの作成はCOMMITによってどれくらい遅くなるか 1

検証内容

適当なテーブルを作成、同件数の大量データを作成し、コミット回数を変化させ、そのデータ作成にかかる時間を計測します。今回は　SI Object Browser（以下OB）に搭載されている、データ生成機能を利用します。
詳細は以下の通りです。

検証詳細

・サンプルテーブルに10万件のデータを作成
・その際、COMMITを作成件数1件に1回、10件に１回、100件に１回、1,000件に１回、
10,000件に１回、100,000件に1回、またOBのデフォルト値である50件に1回で行い、
それぞれデータ生成終了までの時間を計測
・それぞれ5回実施し、中間の結果を採用する
・一回の検証ごとにテーブルデータを削除し、DBバッファキャッシュをクリア
・データ生成には OBのデータ生成機能を使用

データ生成機能

OBにはデータ生成機能というものがあります。これは指定件数分データを自動で作成する機能です。パフォーマンステストなど大量のデータが必要な場合非常に役立つ機能です。
単独テーブルのデータを生成する通常機能のほか、親テーブル（マスタデータ）を意識したデータや、既存データをUPDATEし、住所などをマスキングした状態にすることも可能です。

Oracle 大量データの作成はCOMMITによってどれくらい遅くなるか 2

図１：データ生成画面

各項目には連番やランダムな値、住所・氏名電話番号等あらかじめ用意されたテンプレートから選択することも可能です。今回の検証ではCOL1に連番、COL2に乱数値（数値）を選択しました。
つづいて、今回の検証テーマであるコミット回数についてです。OBでは、こちらも任意の数に設定が可能です。
メニューバー　ツール→オプション→詳細設定タブ　にあります、「データ生成ツールコミット件数」に指定した件数ごとにコミットが可能ですので、こちらの値を生成ごとに切り替えていきます。（デフォルトは50）

Oracle 大量データの作成はCOMMITによってどれくらい遅くなるか 3

図２：コミット実施件数の指定

※使用するOBは今回の検証用にデータ生成時間を計測できるよう
カスタマイズされています。現在の製品版には時間計測機能はありません。

検証環境

今回の検証環境は以下の通りです。

マシン	OS	Windows7
	CPU	Intel Core i7-3770 3.40GHz
	メモリ	8GB
	その他	特に無し
DB	対象RDBMS	Oracle11.0.2.0.1.0
	テーブル名	TEST_COMMIT
	テーブル項目	COL1(NUMBER10),COL2(NUMBER10)　※主キー設定なし

検証結果

以下のようになりました。

Oracle 大量データの作成はCOMMITによってどれくらい遅くなるか 4

中間値での処理時間の推移は以下の通りです。

Oracle 大量データの作成はCOMMITによってどれくらい遅くなるか 5 10万件生成を行う間、コミット回数が減少するにつれて経過時間も少なくなっていきましたが、1000件ごと以降はあまり変化はなくなりました（数値的には少々上昇しているようにも見えます。）

追加検証

今回は検証を追加し、100万件の場合でも検証を行いました。環境面では同条件ですが、データ1件ずつのコミット(=100万回コミット) をやめて、100万件でのコミット（=1回コミット）を追加します。

Oracle 大量データの作成はCOMMITによってどれくらい遅くなるか 6 中間値での処理時間の推移は以下の通りです。

Oracle 大量データの作成はCOMMITによってどれくらい遅くなるか 7

こちらも、1000件ごと以降に大きな短縮は見られず、ほぼ同じ時間となりました。

[RELATED_POSTS]

結論

今回の検証結果では、1000件ごとのコミット以上にコミット数を減らしても、効果がありませんでした。もちろん、メモリ状況やロールバックセグメントなど様々な要因が絡むので一概には言えませんが、このあたりが一つの指標となるものと考えます。少なくとも、「コミット回数が最小＝処理時間が最短」ではない、ということが言えます。

コミットやロールバック自体の動作、それに伴うパフォーマンスについては、また別の機会に検証していきたいと思います。

また、初期の頃こうした検証を行って50件ずつのコミットが最速と判断していたのですが、この結果を見た限り、最後にまとめてコミットでも速度的に差がないようです。
もう少しDBラボチームで検証して初期値を変更すべきか検討してみます。