“1.2.3 資源の占有待ちが多く発生している場合”とは異なる理由で、適切なインデックスを使った検索を行っているにもかかわらず、処理に時間がかかっている例および対策を以下に示します。
表示例
Symfoware Server Performance Monitor / SQL detailed information
Start time: 2008/10/16 14:32:18.934
End time: 2008/10/16 14:32:23.166
Running time: 4.232
Connection ID: 2008101015375000000458
Connection information:
Uid: I4874
Pid: 12521
Sid: -----
Type: SQL
Name: APL001/CONNECT1
Client information:
Client: u=UserID,i=RequestID,h=HostName
Module: IJServer01
Action: -----
Termination status:
Status: normal
Message Number: 2001
SQL statement:
SELECT SUM(C2)FROM USR1.TBL1 WHERE C1 BETWEEN 20 AND 30
Access plan:
Convert SQL statement:
SELECT SUM(TBL1.C2) FROM USR1.TBL1 WHERE TBL1.C1 BETWEEN ? AND ?
===============================================================================
Main query
=sno===sectname=====input1==============input2==============output/update======
1 : SCAN [TBL1IXDSO1 ][ ][SORT0001 ]
-------------------------------------------------------------------------------
[ 1] SCAN ELEMENT
table name USR1.TBL1
scan type INDEX KEY SCAN(1)
dso name TBL1IXDSO1 [REC/SH]
condition evaluation No
scan record number 2
[ 2] INSERT ELEMENT
table name SORT0001
insert record length 12
-------------------------------------------------------------------------------
2 : SCAN [SORT0001 ][TBL1DSO ][ ]
GROUP [ ][ ][APPL ]
-------------------------------------------------------------------------------
[ 1] SCAN ELEMENT
table name SORT0001
scan type TABLE ALL SCAN
condition evaluation No
[ 2] SCAN ELEMENT
table name USR1.TBL1
scan type TABLE KEY SCAN
dso name TBL1DSO [REC/SH]
condition evaluation Yes
scan record number 1
[ 3] GROUPING ELEMENT
condition evaluation No
[ 4] OUTPUT ELEMENT
record length 9
Execution environment
-------------------------------------------------------------------------------
transaction access mode : READ WRITE
transaction isolation level : REPEATABLE READ
R_LOCK : YES
JOIN_RULE : AUTO
JOIN_ORDER : INSIDE
SCAN_KEY_ARITHMETIC_RANGE : YES
SCAN_KEY_CAST : YES
TID_SORT : YES
TID_UNION : YES
USQL_LOCK : SH
IGNORE_INDEX : NO
INACTIVE_INDEX_SCAN : YES
SS_RATE : 0.200000 0.250000 0.500000 0.400000 0.000100
Sampling status:
ACTIVE: 1
WAITING: 3
DB_READ: 3
対策
アクセスプランを見ると、アクセス方式は“INDEX KEY SCAN”となっており、適切にインデックスを使用した検索となっていることが確認でき、その後の処理も問題ないことがわかります。
サンプリングした実行状態の内訳を見ると、処理中断の状態(WAITING)を3回検出しており、3回ともデータベースからのページの読込み待ち(DB_READ)が原因であることがわかります。また、rdbpmreportコマンドでデータベーススペースの性能に関する情報を見ることで、データベースに関する入出力の動作状態を確認することができます。
対策として、以下が考えられます。
データベースバッファの設計を見直し、頻繁にアクセスされる資源に対するバッファの割当てを増やす
データベースのディスク配置を見直し、入出力の負荷を複数のディスクに分散させる