2017/9/7 db tech showcase Tokyo 2017(JPOUG in 15 minutes)にて発表した内容です。 SQL大量発行に伴う処理遅延は、ミッションクリティカルシステムでありがちな性能問題のひとつです。 SQLをまとめて発行したり、処理の多重度を上げることができれば高速化可能です。ですが・・・ AP設計に起因する性能問題のため、開発工程の終盤においては対処が難しいことが多々あります。 そのような状況において、どのような改善手段があるのか、Oracleを例に解説します。

1. SQL大量発行処理を
いかにして高速化するか
若山 勝吾
2017. 09. 07
© Shogo Wakayama

2. はじめに
SQL大量発行に伴う処理遅延は、ミッションクリティ
カルシステムでありがちな性能問題のひとつです。
SQLをまとめて発行したり、処理の多重度を上げるこ
とができれば高速化可能です。ですが・・・
AP設計に起因する性能問題のため、開発工程の終盤
においては対処が難しいことが多々あります。
そのような状況において、どのような改善手段がある
のか、Oracleを例に解説します。
2
ループ処理で1件ずつ順次処理していくAPは、シンプルなため設計がしやすく、メモリ等のリソース使用量が
少なくて済むなどの理由から、レガシーシステムで用いられている傾向が多いです。
将来を見据えてシステムをリプレースする際に、そのような設計・実装をそのまま踏襲すると、クラウド環境
にみられるスケーラブルなサーバを利用しても、十分な性能が出ないという問題に直面しやすくなります。

3. 自己紹介: 若山 勝吾
• ミッションクリティカルシステム専門
性能改善エンジニア
⇒ 性能試験と性能問題解決が得意です。
• 10年間、性能プロフェッショナルチームに所属
(50を超えるプロジェクトで実績を積む)
• Javaプロファイラ、性能モニタリングツール、
負荷生成ツールの開発・導入支援を経験
3

4. • SQL大量発行処理の改善方針
• SQL大量発行処理のチューニング10選
4
アジェンダ

5. ユーザ セッション
ありがちなSQL大量発行処理の例
5
バッチAPプロセス DBプロセス
実行スレッド
APサーバ DBサーバ
参照SQL ×N本
SQL実行
更新SQL ×N本
SQL実行
DBコネクション作成
DBコネクション切断
コミット
LOBデータ
アクセス
処理開始
終了
ユーザ セッション
遅い！
1件あたり6msで処理できたとしても、100万件の場合は100分かかる！
ループ処理で
1件ずつ実行
×100万件
テーブルA, B, Cから1レコードずつ
取得(PKアクセス)
テーブルC, Dに対して、1レコード
ずつ更新(PKアクセス)
テーブルCから取得したバイナリ
データを加工し、テーブルDに登録
文字列処理や
データ型変換など
ファイル操作など

6. (理想論)SQL大量発行処理の性能改善方針
【改善ポイント】
• 処理をまとめていない or まとめた際の効率が悪い
• 処理の多重度が足りない
【改善方針】
• ループ処理を廃止。複数レコードを一括処理する実装に変更
• 並列実行フレームワーク/分散処理技術を活用
しかし、開発工程の終盤では、まず現場は受け入れてくれない。
⇒AP修正/テストの期間が無い、デグレのリスクが高い、等。
6

7. 限界スループットの算出式
限界スループット(処理件数／経過時間)
= 多重度／1件あたり処理時間(CPU時間+待機時間)
例) 1件あたり2秒かかる処理を6多重で実行した場合、
6多重／2秒 = 3件/秒
7
2秒 2秒
1件目
6多重
2秒 2秒
2件目 3件目 30件目
60秒経過
2秒 2秒 2秒 2秒
2秒 2秒 2秒 2秒
2秒 2秒 2秒 2秒
2秒 2秒 2秒 2秒
2秒 2秒 2秒 2秒
リトルの法則により、店内にいる顧客の平均的な数 L は、到着率 λ に 顧客が店内で過ごす平均時間 W を掛けたものになる。
「L = λ W」 ←→ 「λ = L / W」
<出典：待ち行列理論のリトルの法則 - Wikipedia>
https://ja.wikipedia.org/wiki/リトルの法則
スキマなく詰め込んでも、
60秒間で180件が限界

8. 限界スループットを改善するには？
限界スループット(処理件数／経過時間)
= 多重度／1件あたり処理時間(CPU時間+待機時間)
• CPU時間・待機時間を減らす
– 高速なハードウェアを利用する
– 不必要な(冗長な)処理を省く
– I/O, 通信処理をまとめることで効率化する
• さらに多重度を上げる(ことができるようにする)
– 1多重あたりのリソース使用量を減らす ⇒CPU時間・待機時間を削減
– 多重実行時の競合を減らす ⇒待機時間を削減
8

9. 限界スループットを改善するには？
限界スループット(処理件数／経過時間)
= 多重度／1件あたり処理時間(CPU時間+待機時間)
性能は「かけ算」。
たとえチリツモな改善しかできなくても・・・
1.2倍 × 1.2倍 × 1.2倍 × 1.2倍 = 2.07倍
9
CPU時間の削減効果
として、サーバCPU
に余裕ができたので
多重度UPできる！
チューニングに伴い
多重実行時の競合が
緩和されたことで、
多重度UPできる！
処理に不要なデータを省い
たり、AP側キャッシュ等で
SQL発行を抑止することで、
高速化！
データ加工や型変換
処理、SQL実行計画
をチューニングする
ことで、高速化！
※この数字は、あくまで改善効果のイメージ例です

10. (現実解)SQL大量発行処理の性能改善方針
【改善ポイント】
• CPU時間・待機時間の占める割合が大きい箇所を特定する
(調査するまでは改善ポイントは不明)
【改善方針】
• CPU時間・待機時間を可能な限り削減する
• 処理の多重度を可能な限り上げる
現場において、AP修正に伴う開発影響を配慮した、
シンプルな理論的アプローチ。(計測と分析を重視)
10

11. ユーザ セッション
SQL大量発行に伴う、様々なオーバーヘッド
11
バッチAPプロセス DBプロセス
実行スレッド
APサーバ DBサーバ
参照SQL ×N本
SQL実行
更新SQL ×N本
SQL実行
DBコネクション作成
DBコネクション切断
ループ処理で
1件ずつ実行
コミット
LOBデータ
アクセス
REDOログ同期書き込みに伴う
オーバーヘッド
ループ処理で1件ずつ取得すること
に伴うI/Oオーバーヘッド
※キャッシュヒット率が悪い場合
APーDB間のラウンドトリップ
に伴うオーバーヘッド
※LOBロケータを使ってOpen/
Read/Write/Closeを行うため
ユーザ セッション
APーDB間のラウンドトリップ
に伴うオーバーヘッド
ハードパースに伴うオーバーヘッド
※SQL文のリテラル値が変動する場合
ハードパースに伴うオーバーヘッド
※SQL文のリテラル値が変動する場合
更新ブロック競合や行ロック獲得
に伴うオーバーヘッド(待機時間)
※多重実行している場合
文字列処理や
データ型変換など
APーDB間のラウンドトリップ
に伴うオーバーヘッド
APーDB間のラウンドトリップ
に伴うオーバーヘッド
ファイル操作など

12. ユーザ セッション
各レイヤにおける処理時間の調査手段
※Oracle+Linux環境の場合
12
バッチAPプロセス DBプロセス
実行スレッド
APサーバ DBサーバ
参照SQL ×N本
SQL実行
更新SQL ×N本
SQL実行
DBコネクション作成
DBコネクション切断
コミット
LOBデータ
アクセス
ユーザ セッション
APーDB間のラウンドトリップ
に伴うオーバーヘッド
※LOBロケータを使ってOpen/
Read/Write/Closeを行うため
APーDB間のラウンドトリップ
に伴うオーバーヘッド
APーDB間のラウンドトリップ
に伴うオーバーヘッド
APーDB間のラウンドトリップ
に伴うオーバーヘッド
文字列処理や
データ型変換など
ファイル操作など
ループ処理で
1件ずつ実行
REDOログ同期書き込みに伴う
オーバーヘッド
ループ処理で1件ずつ取得すること
に伴うI/Oオーバーヘッド
※キャッシュヒット率が悪い場合
更新ブロック競合や行ロック獲得
に伴うオーバーヘッド(待機時間)
※多重実行している場合
・strace + lsof
※Oracle Javaの場合
FlightRecorderで
・V$SESS_TIME_MODEL
・V$SESSION_EVENT
・V$SQLSTATS
・SQL Trace
・/proc/PID/stat
・perf record
※Oracle Javaの場合
FlightRecorderで
調査
調査
調査
ハードパースに伴うオーバーヘッド
※SQL文のリテラル値が変動する場合
ハードパースに伴うオーバーヘッド
※SQL文のリテラル値が変動する場合

13. 各レイヤにおける処理時間の調査手段(AP側)
※Linux(RHEL6以降)の場合
13
APプロセス - 実行スレッド
処理時間の調査手段 調査できること
/proc/PID/stat
※スレッドの場合は下記参照
/proc/PID/task/TID/stat
当該プロセス(スレッド)が要した時間内訳
・CPU時間(ユーザモード)の合計
・CPU時間(カーネルモード)の合計
・I/O待機時間の合計
perf record 当該プロセス(スレッド)のCPU時間内訳
・CPU時間(ユーザモード)を要している関数名, ライブラリ名
・CPU時間(カーネルモード)を要しているシステムコール名
・関数のコールグラフ(stack chain/backtrace)
strace + lsof 当該プロセス(スレッド)の外部で要した時間内訳
・I/O, 通信の応答時間
・I/O, 通信の対象(ファイル名, TCPポート等) ※lsof結果と突合
・I/O, 通信の量(バイト数)
・システムコール以外の時間(≒CPU時間(ユーザモード))
# プロセス内部で、CPU負荷の高い処理の調査 (関数ごとの%CPU, コールグラフ)
perf record -F 997 -g -o <出力ファイル名> -p <PID> sleep <計測時間[秒]>
perf report -v -n --showcpuutilization --stdio -i <出力したファイル名>
# プロセスの外部(システムコール)で待ちが生じている箇所の調査 ※strace実行前にlsofを取得
lsof -p <PID>
strace -f -ff -tt -T -v -x -s 256 -o <出力ファイル名> -p <PID>
Oracle Javaの場合、
FlightRecorderを使えば丸わかり
ここに時間がかかっている場合、
前後に実行されたシステムコール
を手がかりに、被疑処理を類推

14. 各レイヤにおける処理時間の調査手段(DB側)
※Oracle(11g以降)の場合
14
処理時間の調査手段 調査できること
V$SESS_TIME_MODEL 当該セッションが要した時間内訳
・経過時間, CPU時間
・DBセッションの接続/切断に要した時間
・ハードパースに要した時間
・シーケンス番号取得に要した時間
・バインド変数(新値の)設定に要した時間
V$SESSION_EVENT 当該セッションが要した待機時間内訳
・待機イベント名
・待機時間(累計/平均/最大)
V$SQLSTATS 当該SQLが要した時間内訳
・SQL実行回数、取得レコード数
・ハードパース時間(平均)
・SQL実行時間の詳細
(ELAPSED_TIME, CPU_TIME, USER_IO_WAIT_TIME, CLUSTER_WAIT_TIME,
APPLICATION_WAIT_TIME, CONCURRENCY_WAIT_TIME)
SQL Trace 当該セッションのアクティビティ
・トレースを取得することで、時系列で色々わかる。
https://docs.oracle.com/cd/E16338_01/server.112/b56312/sqltrace.htm#i4640
DBプロセス - ユーザ セッション
特定AP処理に限定せずにシステム全体を分析する
場合は、AWR/STATSPACKレポートも有効。
SQLのElapsedTimeだけを
確認していても分からない
時間を確認できる
V$SQLではハードパース時間を
確認できないため、意外に貴重

15. • SQL大量発行処理の改善方針
• SQL大量発行処理のチューニング10選
15
アジェンダ

16. #1 SQL発行数の削減 その①
同じデータを頻繁にSELECTする場合
Oracle11g機能「クライアント結果キャッシュ」
・ほぼ更新されないテーブルに対して、繰り返し同データを参照する場合に効果的。
・AP修正ができない状況下において強力な機能。
16
最初のアプリケーション・セッションが問合せを実行すると、データベースから行が取得され、クライアントの結果キャッシュに
キャッシュされます。その他のアプリケーション・セッションが同じ問合せを実行する場合も、行はクライアントの結果キャッシュ
から取得されます。
<出典：Oracle Databaseパフォーマンス・チューニング・ガイド 11gR2>
https://docs.oracle.com/cd/E16338_01/server.112/b56312/memory.htm#BGBBIACC
2回目以降、クライアント側の
結果キャッシュから取得
※SQLをDBに発行しない
初回アクセス時、クライアント側
にSELECT結果をキャッシュ

17. #2 SQL発行数の削減 その②
空振りSQLが大量発行されている場合
従属テーブルの外部キー値をAP側に事前キャッシュしておき、
外部キーが存在しないSQLは発行しない実装にする。
・SQL発行回数は大量だが、1回あたりヒット件数がほぼ0に近い場合、効果的。
・対象APの前提として、他処理によってキー値が追加/削除されても影響がないこと。
17
レガシーシステムでは、RDBとは異なるDBデータ構造(階層型, ネットワーク型など)になっていることが多い。
RDBへシステムをリプレースする際に、旧DBデータ構造のRDB変換に伴い、ほとんどレコードが存在しない
従属テーブル(エンティティ)が発生しうる。
親
テーブル
従属(子)
テーブル
AP処理の例 テーブル構成(関係)
CUSTOMER_IDが「0001～9999」
を対象に、1件ずつ処理を実行
select … from テーブル名
where CUSTOMER_ID=xxxx
データ変換・加工・出力
ループ処理で
1件ずつ実行
1件ヒット
0件ヒット
0件ヒット0件ヒット
1件ヒット
AP側キャッシュに外部キー
が存在しない場合、SQLを
発行させない

18. #3 SQL発行数の削減 その③
SELECTの場合
複数テーブルへの単発SQLを、1SQLにまとめる。
※テーブル毎のレコード取得件数に注意。(件数差異がある場合は外部結合やunion allで対処)
18
【Before】
SELECT … from TBL_A where ID=1001;
SELECT … from TBL_B where ID=1001;
【After】
select … from TBL_A, TBL_B where TBL_A.ID=TBL_B.ID
and TBL_A.ID=1001 and TBL_B.ID=1001;
APーDB間のラウンドトリップ
オーバーヘッドが、SQL 1本分。
APーDB間のラウンドトリップ
オーバーヘッドが、SQL N本分。
念のため、SQL実行計画を確認すること。
テーブル結合方法がNestedLoop以外になっていたり、
結合したことでFull Scanが発生すると性能劣化に。

19. #4 SQL発行数の削減 その④
INSERTの場合
複数テーブルへの単発SQLを、1SQLにまとめる。(insert all)
19
【Before】
insert into TBL_A (ID, …) values (1002, …);
insert into TBL_B (ID, …) values (1002, …);
【After】
insert all
into TBL_A (ID, …) values (1002, …)
into TBL_B (ID, …) values (1002, …)
select * from dual;
APーDB間のラウンドトリップ
オーバーヘッドが、SQL N本分。
SQL実行計画
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | INSERT STATEMENT | | 1 | 2 (0)| 00:00:01 |
| 1 | MULTI-TABLE INSERT | | | | |
| 2 | FAST DUAL | | 1 | 2 (0)| 00:00:01 |
| 3 | INTO | TBL_A | | | |
| 4 | INTO | TBL_B | | | |
--------------------------------------------------------------------------
APーDB間のラウンドトリップ
オーバーヘッドが、SQL 1本分。
SQL実行計画を確認すると、
マルチテーブル・インサート
になっていることがわかる。

20. #5 SQL発行数の削減 その⑤
複数DML(INSERT/UPDATE/DELETE)の場合
20
【Before】
INSERT …;
UPDATE …;
DELETE …;
【After】
BEGIN
INSERT …;
UPDATE …;
DELETE …;
END;
複数DMLによる更新SQLを、PL/SQLでまとめる。
※複雑なデータ加工や判定ロジックが必要な状況では、不向きな場合もある。
APーDB間のラウンドトリップ
オーバーヘッドが、SQL N本分。
APーDB間のラウンドトリップ
オーバーヘッドが、SQL 1本分。

21. #6 LOBオーバーヘッドの削減 その①
従来LOB(BASICFILE)を使用している場合
21
Oracle11g機能「SecureFiles」を使用する。※12cデフォルト
・AP修正不要で、LOB性能を大幅改善できる。
・Oracle10g以前からのバージョンアップの際に、是非利用したい機能。
<出典：津島博士のパフォーマンス講座 第28回 表圧縮とLOBデータ型について>
http://www.oracle.com/technetwork/jp/database/articles/tsushima/tsushima-28-1966240-ja.html
【従来LOB】 【SecureFiles】
SGA(メモリ内)で領域管理を行うことで、
オーバーヘッドが改善。
このほかにも、データ転送効率や容量効率
を高める様々な改良が施されている。
従来は、LOBセグメント領域の
管理をLOB索引で行っていた。

22. 【Before】
INSERT INTO BLOB_TEST (COL_BLOB) VALUES (empty_blob())
RETURNING COL_BLOB INTO lob_locator;
DBMS_LOB.OPEN(lob_locator, DBMS_LOB.LOB_READWRITE);
DBMS_LOB.WRITE(lob_locator, 5, 1, utl_raw.cast_to_raw('ABCDE'));
DBMS_LOB.CLOSE(lob_locator);
#7 LOBオーバーヘッドの削減 その②
LOBWRITEの場合
22
【After】
INSERT INTO BLOB_TEST (COL_BLOB) VALUES (utl_raw.cast_to_raw('ABCDE'));
LOBロケータを使わずに、データ・インタフェースを使用する。
永続LOB用のデータ・インタフェースを使用するメリット
・逐次アクセス技法を使用するOCIアプリケーションの場合は、パフォーマンスが向上します。データ・インタフェースを使用してピース単位
のINSERTまたはフェッチを実行すると、OCILobRead2()やOCILobWrite2()などのOCI関数を使用する場合と同様のパフォーマンスが得られま
す。データ・インタフェースを使用すると、1回のOCIコールでLOBに4KBを超えるデータを挿入できるため、サーバーへのラウンドトリップ
を削減できます。
・最初にLOBロケータをフェッチしてからOCILobRead2()をコールするかわりに、1回のOCIStmtFetch()コールでLOBデータを読み取ることが
できます。これにより、LOBデータを最初から読み取る場合のパフォーマンスが向上します。
・配列のバインドおよび定義インタフェースを使用すると、LOBを含む複数の行を1回のラウンドトリップで挿入および選択できます。
<出典：Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド 11gR2 - 20 永続LOB用のデータ・インタフェース>
https://docs.oracle.com/cd/E16338_01/appdev.112/b56263/adlob_data_interface.htm
LOBロケータ操作に伴う
APーDB間のラウンドトリップが発生
直接データを登録することで、
ラウンドトリップを抑止

23. #8 LOBオーバーヘッドの削減 その③
LOBREADの場合
23
LOBデータを取得する際に、LOBロケータを使わずに、
ORACLE関数「cast_to_varchar2()」を使って直接取得する。
【Before】
select COL_BLOB, dbms_lob.getlength(COL_BLOB) into lob_locator, lob_len
from BLOB_TEST where ID=1;
DBMS_LOB.OPEN(lob_locator, DBMS_LOB.LOB_READONLY);
DBMS_LOB.READ(lob_locator, lob_len, 1, buffer);
DBMS_LOB.CLOSE(lob_locator);
【After】
select utl_raw.cast_to_varchar2(dbms_lob.substr(COL_BLOB, 2000, 1))
from BLOB_TEST;
直接データを取得することで、
ラウンドトリップを抑止
LOBロケータ操作に伴う、
APーDB間のラウンドトリップ
オーバーヘッドが発生。
varchar2型にあわせて
トリミング

24. #8 LOBオーバーヘッドの削減 その③
LOBREADの場合 (注意事項)
24
LOBデータを取得する際に、LOBロケータを使わずに、
ORACLE関数「cast_to_varchar2()」を使って直接取得する。
SQL> select * from nls_database_parameters where parameter like '%CHARACTERSET';
PARAMETER VALUE
------------------------------ --------------------
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_CHARACTERSET AL32UTF8
#export NLS_LANG='Japanese_Japan.AL32UTF8'
SQL> select utl_raw.cast_to_varchar2(dbms_lob.substr(COL_BLOB, 2000, 1)) from BLOB_TEST;
UTL_RAW.CAST_TO_VARCHAR2(DBMS_LOB.SUBSTR(COL_BLOB,2000,1))
--------------------------------------------------------------------------------
ABCDE
あいうえお
#export NLS_LANG='Japanese_Japan.JA16SJIS'
SQL> select utl_raw.cast_to_varchar2(dbms_lob.substr(COL_BLOB, 2000, 1)) from BLOB_TEST;
UTL_RAW.CAST_TO_VARCHAR2(DBMS_LOB.SUBSTR(COL_BLOB,2000,1))
--------------------------------------------------------------------------------
ABCDE
ｦｨ
※環境変数「NLS_LANG」が
「NLS_CHARACTERSET」と合って
いないと、取得データが化ける。
VARCHAR2への変換時、そのVARCHAR2内の文字に対して現行のグローバリゼーション・サポート・キャラクタ・セットが使用されます。
<出典：Oracle Database PL/SQLパッケージおよびタイプ・リファレンス11gR2>
https://docs.oracle.com/cd/E16338_01/appdev.112/b56262/u_raw.htm#BABJFGBH
データ化け

25. #9 COMMITオーバーヘッドの削減
ループ処理で1件ごとにCOMMITしている場合
25
1件ごとにCOMMITせず、ある程度の処理単位で(例えば1万件ごと)
まとめる。
・ORACLE待機イベント「log file sync」が頻発している状況では効果的。
・COMMIT単位を数100万件などに大きくする場合、UNDO表領域の枯渇に注意。
・ORACLE待機イベント「enq: TX - row lock contention」の発生が見られる場合、
安易にCOMMIT単位を変更しないほうがよい。
2多重以上で処理している場合、同一レコードを同時更新する可能性があるAPでは、COMMIT単位をまとめる
ことで、行ロック競合確率がさらに高まる可能性がある。
※COMMITするまで行ロックを解除できないため、行ロック待機で遅延してしまう。
⇒ 行ロックが生じないよう事前に対象データを整理(実行スレッド毎に分割/ソート)しておくか、
COMMIT単位を大きくするのではなく、行ロックを掛けるトランザクション区間を短くするのも、
対応案としてあげられる。

26. #10 職人技チューニング
ヤスリがけの如く、非効率(冗長な)処理を削ぎ落とす。
【APロジック】
• ループ処理内で、毎回決まった結果になるロジック部分は、ループ処理
の外へ移動。
• 型変換や文字列処理は、メモリ操作に伴うCPU時間が発生するため、
最低限の型変換やキャッシュ活用を検討する。
(対策例として、日付文字列⇔Date型オブジェクトの変換では、キャッシュした
変換済みオブジェクトで代替、などの手段で重複排除を行えるか検討する)
【SQL】
• ElapsedTime(実行時間)の短縮だけでなく、多重実行時の競合緩和のため、
BufferGets(アクセスブロック数)の削減も意識する。
• ハードパース時間削減のため、「SQL文のバインド変数化」＋「ヒント
句指定でSQL実行計画を固定化」することも有効。
26
使わない「列」を取得しないことで、
AP側の負担も減らすことが出来る。

27. おわりに
SQL大量発行に伴う処理遅延は、ミッションクリティ
カルシステムでありがちな性能問題のひとつです。
ミッションクリティカルシステムのリプレースの際は、
処理の並列実行や一括処理を意識して、AP設計の改良
を検討したいものです。
しかしながら、「現行AP設計を踏襲」の呪縛は、想像
以上に根強いかもしれません・・・
そのような状況において、本解説を参考に、対策を
練っていただければと思います。
27