チューニングガイド

Transcription

1 Symfoware Server V チューニングガイド Windows/Solaris/Linux J2X Z0(00) 2010 年 1 月

2 まえがき 本書の目的本書は アプリケーションの性能チューニングについて説明しています 本書の読者本書は アプリケーションの性能チューニングを行う方に読んでいただくように書かれています 本書を読むためには 以下の知識が必要です コンピュータについての一般的な知識 リレーショナルデータベースについての知識 Symfowareデータベースについての知識 SQLに関する知識 データベースシステムの性能チューニングに関する知識 業務に関する知識 本書の構成 本書の構成と内容は以下のとおりです 第 1 章チューニングの概要 アプリケーションのチューニングの手順 チューニングの例を説明しています 第 2 章パフォーマンスモニタ パフォーマンスモニタの使用方法を説明しています 第 3 章原因の特定 性能が悪くなっている原因の特定方法を説明しています 第 4 章チューニング 性能を改善するためのチューニング方法を説明しています 付録 A 性能チューニングのためのパラメタ一覧 性能チューニングのためのパラメタを説明しています コマンド操作例について 本書で説明しているコマンド操作例は UNIX 系システムを前提として記載しています Windows(R) で操作する場合は 以下の表に従って読み替えてください UNIX 系での操作の場合 /tmp/out_data /tmp/sqlfile.txt /tmp/plan /tmp/trace.log /tmp/sql.snp /tmp/tbl.log /tmp/exec.log /tmp/index.log /tmp/statistics.log Windows(R) での操作の場合 E:\TMP\OUT_DATA E:\TMP\SQLFILE.TXT E:\TMP\PLAN E:\TMP\TRACE.LOG E:\TMP\SQL.SNP E:\TMP\TBL.LOG E:\TMP\EXEC.LOG E:\TMP\INDEX.LOG E:\TMP\STATISTICS.LOG - i -

3 平成 22 年 1 月初版 - ii -

4 目次 第 1 章チューニングの概要 チューニングの手順 原因の調査とチューニングの例 表の全件検索となっている場合 ASSIST 指定が無効となっている場合 資源の占有待ちが多く発生している場合 入出力待ちが多く発生している場合...6 第 2 章パフォーマンスモニタ パフォーマンスモニタの概要 パフォーマンスモニタの使用方法 処理時間が長い SQL 文を特定する SQL 文のアクセスプランと実行状態の内訳を表示する 動作環境の設定変更 処理に時間がかかっていると判断する時間の変更 情報の保存期間の変更 システム情報の採取間隔の変更 動作環境の設定内容の確認...15 第 3 章原因の特定 アクセスプランを確認する サンプリングした実行状態の内訳...19 第 4 章チューニング アクセス方式のチューニング ジョイン方法のチューニング ジョイン順のチューニング アドバイスに応じたチューニング ソートサイズ ワークサイズのチューニング 処理が待ち状態となっていた場合のチューニング その他のチューニング CAST を使用した SQL 文のチューニング トランザクション占有のチューニング...31 付録 A 性能チューニングのためのパラメタ一覧...33 A.1 パラメタ一覧...33 索引 iii -

5 第 1 章チューニングの概要 本章では チューニングの手順を説明します 1.1 チューニングの手順 アプリケーションの処理が遅いなど アプリケーションの性能に問題が発生した場合には 動作環境や SQL 文をチューニングする必要があります 問題となっている事象の原因特定には パフォーマンスモニタを使用します チューニングの手順を説明します 1.2 原因の調査とチューニングの例 パフォーマンスモニタを利用した原因調査と その結果によるチューニング実施の概要を 例を挙げて説明します なお パフォーマンスモニタの詳細については 第 2 章パフォーマンスモニタ を参照してください 表の全件検索となっている場合 rdbpmsqllist コマンドを使用して 処理が長くなっている SQL 文のアクセスプランと処理の内訳を表示した例および対策を以下に示します 表示例 Symfoware Server Performance Monitor / SQL detailed information Start time: 2008/10/16 11:21: End time: 2008/10/16 11:21: Running time: Connection ID: Connection information: Uid: I4874 Pid: Sid: Type: SQL Name: APL001/CONNECT1 Client information: Client: u=userid,i=requestid,h=hostname Module: IJServer01-1 -

6 Action: Termination status: Status: normal Message Number: 2001 SQL statement: SELECT C1 FROM USR1.TBL1 WHERE C2=100 Access plan: Convert SQL statement: SELECT TBL1.C1 FROM USR1.TBL1 WHERE TBL1.C2=? Advice to an SQL statement: JYP2401I 表の全件検索を行います. =============================================================================== Main query =sno===sectname=====input1==============input2==============output/update====== 1 : SCAN [TBL1DSO ][ ][APPL ] [ 1] SCAN ELEMENT table name USR1.TBL1 scan type TABLE ALL SCAN dso name TBL1DSO [NONE/NONE] condition evaluation Yes scan record number 1 [ 2] OUTPUT ELEMENT record length 23 Execution environment transaction access mode : READ WRITE transaction isolation level : READ UNCOMMITTED 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 SS_RATE : Sampling status: ACTIVE: 3 WAITING: 10 DB_READ: 10 対策 アクセスプランの情報を見ると 表 USR1.TBL1 からデータをとってくるだけの単純な検索処理です SCAN エレメントのアクセス方式を見ると TABLE ALL SCAN となっており 表から全レコードを取り出す処理が動作していることがわかります 表から全レコードを取り出す処理は その表の最初のデータから最後のデータまでをくまなく参照することになるため 表に格納されているデータの量に依存して処理時間が長くなります そのため データ量の多い表に対しては避けるべきアクセス方式となります 確認のためにサンプリングした実行状態の内訳を参照すると DB_READ が 10 回となっており 多くのタイミングでデータベースからのデータ読込み待ちが発生していることがわかります このことから データ量の多い表からすべてのデータを読み込んで参照しているため時間が長くかかっていることが確認できます このようにデータ量の多い表に対して避けるべきものとしては 他に NESTED LOOP JOIN エレメントがあります この問題は 適切なインデックスを付けることで解決します SQL 文の WHERE 句を見てみると C2 カラムでの検索条件がついています しかし この表には C2 カラムにはインデックスを付けていませんでした C2 カラムにインデックスを付ければ 表に対する全データの読出し処理ではなく インデックスを用いた高速な検索処理が動作するようになるため 性能は大幅に改善されます - 2 -

7 SQL 文に記述されている検索条件やジョインの条件を見て 適切なインデックスを付けることで このような問題は解決することができます ASSIST 指定が無効となっている場合 ASSIST 指定が無効となっているため 処理に時間がかかっている例および対策を以下に示します 以下の例では アクセスプランにアドバイスが出力されています 表示例 Symfoware Server Performance Monitor / SQL detailed information Start time: 2008/10/16 11:21: End time: 2008/10/16 11:21: Running time: Connection ID: Connection information: Uid: I4874 Pid: 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 /* ASSIST USE_INDEX(TBL1(TBL1IXDSO1)) */ C1 FROM USR1.TBL1 WHERE C1=80 Access plan: Convert SQL statement: SELECT /* ASSIST USE_INDEX(TBL1(TBL1IXDSO1)) */ TBL1.C1 FROM USR1.TBL1 WHERE TBL1.C1=? Advice to an SQL statement: JYP2410I ASSIST 要素 USE_INDEX に指定されたインデックス TBL1IXDSO1 が定義されていません. JYP2401I 表の全件検索を行います. =============================================================================== Main query =sno===sectname=====input1==============input2==============output/update====== 1 : SCAN [TBL1DSO ][ ][APPL ] [ 1] SCAN ELEMENT table name USR1.TBL1 scan type TABLE ALL SCAN dso name TBL1DSO [NONE/NONE] condition evaluation Yes scan record number 1 [ 2] OUTPUT ELEMENT record length 23 Execution environment transaction access mode : READ WRITE transaction isolation level : READ UNCOMMITTED R_LOCK : YES JOIN_RULE : AUTO JOIN_ORDER : INSIDE SCAN_KEY_ARITHMETIC_RANGE : YES SCAN_KEY_CAST : YES TID_SORT : YES - 3 -

8 TID_UNION : YES USQL_LOCK : SH IGNORE_INDEX : NO SS_RATE : Sampling status: ACTIVE: 3 WAITING: 10 DB_READ: 10 対策 アクセスプランのアドバイスをみると ASSIST 指定で指定したインデックスが未定義であることが分かります 可能性として 運用中に何らかの理由でインデックスが削除されたことが考えられます この問題は 適切なインデックスを付けることで解決します SQL 文の WHERE 句を見てみると C1 カラムでの検索条件がついています しかし この表にはアドバイスのとおり C1 カラムにはインデックスは付いていません C1 カラムにインデックスを付ければ 表に対する全データの読出し処理ではなく インデックスを用いた高速な検索処理が動作するようになるため 性能は大幅に改善されます 資源の占有待ちが多く発生している場合 適切なインデックスを使った検索を行っているにもかかわらず 処理に時間がかかっている例および対策を以下に示します 表示例 Symfoware Server Performance Monitor / SQL detailed information Start time: 2008/10/16 13:45: End time: 2008/10/16 13:45: Running time: Connection ID: Connection information: Uid: I4874 Pid: 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 C2 FROM USR1.TBL1 WHERE C1=80 Access plan: Convert SQL statement: SELECT TBL1.C2 FROM USR1.TBL1 WHERE TBL1.C1=? =============================================================================== 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 1-4 -

9 [ 2] INSERT ELEMENT table name SORT0001 insert record length : SCAN [SORT0001 ][TBL1DSO ][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] OUTPUT ELEMENT record length 23 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 SS_RATE : Sampling status: ACTIVE: 1 WAITING: 5 LOCK: 5 対策 アクセスプランを見ると アクセス方式は INDEX KEY SCAN となっており 適切にインデックスを使用した検索となっていることが確認できます インデックスを検索したあとも インデックスから取り出した情報をもとに TABLE KEY SCAN により正しく表へのアクセスが行われており アクセスプラン自体には問題がないことがわかります 遅くなっている原因を調べるために サンプリングした実行状態の内訳を参照すると 処理中断の状態 (WAITING) を 5 回検出しており 5 回ともトランザクション占有待ち (LOCK) で待ちとなっていることがわかります このことから 検索対象となっているレコードへのアクセスが 他のトランザクションのアクセスと競合したため 処理に時間がかかったことがわかります rdbpmreport コマンドでこの SQL 文が実行されていたときの資源の占有待ちに関する情報を確認することで 裏付けをとることができます 対策として 以下が考えられます 排他の単位が行になっていなければ行に変更する トランザクションの独立性水準を変更する 排他の単位は アクセスプラン情報の R_LOCK の項目で確認ができます この例では YES となっているため 排他の単位は行になっており 問題ないことがわかります トランザクションの独立性水準は アクセスプラン情報の transaction isolation level の項目でわかります この例では REPEATABLE READ となっています 処理の論理上問題ないか否かを確認して 独立性水準を READ UNCOMMITTED に変更するということが対策として考えられます - 5 -

10 1.2.4 入出力待ちが多く発生している場合 資源の占有待ちが多く発生している場合 とは異なる理由で 適切なインデックスを使った検索を行っているにもかかわらず 処理に時間がかかっている例および対策を以下に示します 表示例 Symfoware Server Performance Monitor / SQL detailed information Start time: 2008/10/16 14:32: End time: 2008/10/16 14:32: Running time: Connection ID: Connection information: Uid: I4874 Pid: 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 : 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-6 -

11 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 SS_RATE : Sampling status: ACTIVE: 1 WAITING: 3 DB_READ: 3 対策 アクセスプランを見ると アクセス方式は INDEX KEY SCAN となっており 適切にインデックスを使用した検索となっていることが確認でき その後の処理も問題ないことがわかります サンプリングした実行状態の内訳を見ると 処理中断の状態 (WAITING) を 3 回検出しており 3 回ともデータベースからのページの読込み待ち (DB_READ) が原因であることがわかります また rdbpmreport コマンドでデータベーススペースの性能に関する情報を見ることで データベースに関する入出力の動作状態を確認することができます 対策として 以下が考えられます データベースバッファの設計を見直し 頻繁にアクセスされる資源に対するバッファの割当てを増やす データベースのディスク配置を見直し 入出力の負荷を複数のディスクに分散させる - 7 -

12 第 2 章パフォーマンスモニタ 本章では パフォーマンスモニタの使用方法を説明します 2.1 パフォーマンスモニタの概要 パフォーマンスモニタは SQL 文の処理時間の監視を行い 処理に時間がかかっている SQL 文を検出すると その SQL 文に関する情報を収集し パフォーマンスデータ格納ファイルに蓄積します 処理に時間がかかっている SQL 文に関する情報以外にも アプリケーションの動作状況 システム資源の使用情報 アプリケーションによって獲得される資源の占有情報の定常的な採取を行い 同様にパフォーマンスデータ格納ファイルに蓄積します パフォーマンスデータ格納ファイルに蓄積されているデータは rdbpmsqllist コマンドおよび rdbpmreport コマンドを用いて取り出すことができます rdbpmsqllist コマンドでは 処理に時間がかかっている SQL 文の一覧を表示し さらに その SQL 文を依頼したクライアントの情報 アクセスプランの情報を調べることができます rdbpmreport コマンドでは アプリケーションの動作状況 システム資源の使用情報 アプリケーションによって獲得される資源の占有情報に関して 情報が保存されている期間の任意の時間の情報を取り出して表示することができます 各コマンドを使用して パフォーマンスデータ格納ファイルに蓄積されているデータを取り出すイメージを以下に示します これらの情報を活用することで 処理が遅くなっている SQL 文を特定することができ アクセスプランやシステム資源の状態を用いて 処理が遅くなっている原因の調査と 対策の検討を行うことができます 2.2 パフォーマンスモニタの使用方法 パフォーマンスモニタの使用方法を説明します 以下の手順で使用します - 8 -

13 1. 処理時間が長い SQL 文を特定する 2. SQL 文のアクセスプランと実行状態の内訳を表示する 処理時間が長い SQL 文を特定する rdbpmsqllist コマンドを使用し 処理時間が長い SQL 文から順番に一覧を表示します コマンドの実行例と表示内容を以下に示します $ rdbpmsqllist Symfoware Server Performance Monitor / SQL list information Period of analysis: 2008/10/15 08:00: /10/15 11:48:33 (1) (2) (3) (4) (5) (6) time connection-id running-time status SQL 2008/10/15-09:18: normal SELECT COUNT(*)FROM USR1.TBL1 2008/10/15-11:33: normal UPDATE USR1.TBL8 SET COL1=COL /10/15-10:08: normal COMMIT (1) SQL 文の処理時間の解析を行った対象の期間 ( 処理時間が長い SQL 文の調査を行う対象とした期間です 遅い処理が発生した時間帯が判っている場合には 対象となる期間を指定することで 情報を絞り込むことができます 対象となる期間を指定するには rdbpmsqllist コマンドの p オプションを使用します ) (2) SQL 文の開始時刻 (SQL 文の実行を開始した時刻です 表示形式は 西暦 / 月 / 日 - 時 : 分 : 秒. ミリ秒 です ) (3) SQL 文を実行したコネクションのコネクション ID ( コネクション ID は Symfoware/RDB が自動的に採番して割り当てます コネクション ID および SQL 文の開始時刻を rdbpmsqllist コマンドの c オプションおよび t オプションに指定して実行すると コネクションおよび SQL 文に関する詳細な情報を表示することができます ) (4) SQL 文の処理時間 (Symfoware/RDB が SQL 文を処理していた時間です 単位は秒. ミリ秒です 一覧はこの時間が長い順番にソートされて表示されています ) (5) SQL 文の終了ステータス normal : 正常に終了した error : エラーで終了した canceled : タイムアウトや rdbterm コマンドにより処理が中断した (6) SQL 文 ( 実行した SQL 文です 先頭から 50 文字以内を表示します 英小文字は英大文字で表示します SQL 文の前後の空白は削除して表示します SQL 文中の冗長な空白は削除して表示します ) この例では 2008 年 10 月 15 日の 9 時 18 分 19 秒に実行した単一行 SELECT 文で約 14 秒の時間がかかっていることがわかります この SQL 文の処理が長かった原因を調査するための詳細な情報を取得する方法については SQL 文のアクセスプランと実行状態の内訳を表示する を参照してください 注意 処理が完了していない SQL 文に関する情報は表示されません 動作中の SQL 文に関する情報を参照するには その SQL 文の処理の完了を待ってから 情報の表示を行ってください 採取対象となる SQL 文は 以下のとおりです - CALL 文 - 9 -

14 - COMMIT 文 - DELETE 文 : 位置づけ - DELETE 文 : 探索 - INSERT 文 - OPEN 文 - ROLLBACK 文 - 単一行 SELECT 文 - UPDATE 文 : 位置づけ - UPDATE 文 : 探索 - 問合せ式 (Java 連携 ODBC 連携または.NET Framework 連携のアプリケーションの場合 ) 採取対象の SQL 文が OPEN 文の場合 カーソルが閉じられるまでに Symfoware Server がそのカーソルを処理するのにかかった時間が 処理時間となります SQL 文のアクセスプランと実行状態の内訳を表示する 処理時間が長い SQL 文に対して 原因を調査するため SQL 文のアクセスプランと実行状態の内訳を表示します 処理時間が長い SQL 文を特定する で表示されたコネクション ID および SQL の開始時刻を rdbpmsqllist コマンドの c オプションおよび t オプションに指定して実行します アクセスプラン アクセスプランは SQL 文を実行するときのデータベースへのアクセス手順を表現したものです データベースの同じ資源に対してアクセスを行うときでも アクセス手順には複数の方法があり それが適切に選択されていない場合には 処理時間が大幅に長くなることがあります 参照 アクセス手順にどのようなものがあり それらがアクセスプランでどのように表現されるかの詳細については アプリケーション開発ガイド ( 共通編 ) の アプリケーションの性能 を参照してください 実行状態の内訳 サンプリングした実行状態の内訳は SQL 文が実際に動作した状況をサンプリングしたものです 一定時間間隔で処理状態を確認し 集計した結果です どのような処理に時間がとられていたのかということを判断するためのヒントになります SQL 文のアクセスプランと実行状態の内訳の表示例を説明します $ rdbpmsqllist -c t 2008/10/15-09:18: Symfoware Server Performance Monitor / SQL detailed information Start time: 2008/10/15 09:18: (1) End time: 2008/10/15 09:18: (2) Running time: (3) Connection ID: (4) Connection information: Uid: I4874 (5) Pid: (6) Sid: (7) Type: SQL (8) Name: APL001/CONNECT1 (9) Client information: Client: u=userid,i=requestid,h=hostname (10)

15 Module: IJServer01 (11) Action: (12) Termination status: Status: normal (13) Message Number: 2001 (14) SQL statement: (15) SELECT COUNT(*)FROM USR1.TBL1 Access plan: (16) Convert SQL statement: SELECT COUNT(*) FROM USR1.TBL1 Advice to an SQL statement: JYP2401I 表の全件検索を行います. =============================================================================== Main query =sno===sectname=====input1==============input2==============output/update====== 1 : SCAN [TBL1DSO ][ ][ ] GROUP [ ][ ][APPL ] [ 1] SCAN ELEMENT table name USR1.TBL1 scan type TABLE ALL SCAN dso name TBL1DSO [NONE/NONE] condition evaluation No scan record number 10 [ 2] GROUPING ELEMENT condition evaluation No [ 3] OUTPUT ELEMENT record length 8 Execution environment transaction access mode : READ WRITE transaction isolation level : READ UNCOMMITTED 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 SS_RATE : Sampling status: (17) ACTIVE: 2 WAITING: 11 LOCK_TEMPORARY: 1 DB_READ: 10 (1) SQL 文の開始時刻 (SQL 文の実行を開始した時刻です 表示形式は 西暦 / 月 / 日時 : 分 : 秒. ミリ秒 です ) (2) SQL 文の終了時刻 (SQL 文の実行が終了した時刻です 表示形式は 西暦 / 月 / 日時 : 分 : 秒. ミリ秒 です ) (3) SQL 文の処理時間 (Symfoware/RDB が SQL 文を処理していた時間です 単位は秒. ミリ秒です 途中で処理を中断し 別の SQL 文の処理を行ったあとで 再開することもあるため 処理時間は SQL 文の終了時刻と SQL 文の開始時刻の差よりも小さくなることがあります ) (4) SQL 文を実行したコネクションのコネクション ID ( コネクション ID は Symfoware/RDB が自動的に採番して割り当てます )

16 (5) ログイン名 (6) プロセス ID ( コネクションの接続を行っているアプリケーションプロセスのプロセス ID です トランザクションモニタ配下のアプリケーションの場合は この SQL 文の実行を依頼したクライアントプロセスのプロセス ID になります ) (7) セション ID ( マルチスレッド環境で動作しているアプリケーションのセション ID です マルチスレッド環境で動作していない場合には となります ) Solaris/Windows の場合 (8) クライアントプロセス種別 SQL : システム内通信のアプリケーション SQL-XA : トランザクションモニタ配下のアプリケーション TCP/IP : RDB2_TCP 接続のアプリケーション RDA-SV : RDA-SV 接続のアプリケーション ODOS : ODOS 連携の ODBC アプリケーション (9) モジュール名システム内通信のアプリケーション : アプリケーションロードモジュール名 / コネクション名 ( アプリケーションロードモジュール名が 15 バイトを超える場合は 先頭の 15 バイトのみが出力されます ) トランザクションモニタ配下のアプリケーション : データベース名 / コネクション名 ( トランザクションモニタ配下のアプリケーションのデータベース名 / コネクション名は OPEN-INFO 文字列に指定された値が表示されます ) RDB2_TCP 接続のアプリケーション : 接続端末の IP アドレス / コネクション名 RDA-SV 接続のアプリケーション : 接続端末の IP アドレス / コネクション名 ODOS 連携の ODBC アプリケーション : 接続端末の IP アドレス / データソース名またはアプリケーションのロードモジュール名 / データソース名 Linux の場合 (8) クライアントプロセス種別 SQL : システム内通信のアプリケーション SQL-XA : トランザクションモニタ配下のアプリケーション TCP/IP : RDB2_TCP 接続のアプリケーション ODOS : ODOS 連携の ODBC アプリケーション (9) モジュール名システム内通信のアプリケーション : アプリケーションロードモジュール名 / コネクション名 ( アプリケーションロードモジュール名が 15 バイトを超える場合は 先頭の 15 バイトのみが出力されます ) トランザクションモニタ配下のアプリケーション : データベース名 / コネクション名 ( トランザクションモニタ配下のアプリケーションのデータベース名 / コネクション名は OPEN-INFO 文字列に指定された値が表示されます ) RDB2_TCP 接続のアプリケーション : 接続端末の IP アドレス / コネクション名 ODOS 連携の ODBC アプリケーション : 接続端末の IP アドレス / データソース名またはアプリケーションのロードモジュール名 / データソース名

17 (10) クライアント情報 (Interstage Application Server と連携している場合 Web サーバ接続情報が設定されます ( 設定される情報の形式は Interstage Application Server のマニュアルを参照してください )) (Interstage Application Server と連携していない場合 が表示されます ) (11) モジュール情報 (Interstage Application Server と連携している場合 IJServer 名が設定されます ( 設定される情報の形式は Interstage Application Server のマニュアルを参照してください )) (Interstage Application Server と連携していない場合 が表示されます ) (12) アクション情報 ( 常に が表示されます ) (13) SQL 文の終了ステータス normal: 正常に終了した error: エラーで終了した canceled: タイムアウトや rdbterm コマンドにより処理が中断した (14) メッセージ変数に設定されるメッセージの番号 ( 表示されるのは数字部分の 4 桁になります ) (rdbprtmsg コマンドの jyp オプションにより メッセージに関する情報を表示できます ) SQL 文の終了ステータスが canceled の場合には --- となります (15) SQL 文 ( 実行した SQL 文です 先頭から 50 文字以内を表示します 英小文字は英大文字で表示します SQL 文の前後の空白は削除して表示します SQL 文中の冗長な空白は削除して表示します ) (16) アクセスプラン SQL のアクセスプランです 表示項目の詳細に関しては SQLTOOL ユーザーズガイド を参照してください (17) サンプリングした実行状態の内訳 SQL 文が動作中のときにサンプリングした 処理状態の内訳です 一定時間間隔で処理状態を確認し集計した結果です ACTIVE: 動作中の状態を検出した回数 WAITING: 入出力処理待ち 資源の占有待ちなどにより処理が一時的に中断中の状態を検出した回数 処理状態に WAITING がある場合には さらに待ち状態となった原因に関する内訳がその後に続きます LOCK : トランザクション占有待ちを検出した回数 LOCK_TEMPORARY : トランザクション一時占有待ちを検出した回数 DB_BUFFER : 共用バッファの空き待ちを検出した回数 DB_READ : ページ読込み待ちを検出した回数 DB_WRITE : ページ書込み待ちを検出した回数 DB_WRITE_TRNEND : トランザクション終了時のページ書込み待ちを検出した回数 DB_SEND : メモリ常駐ページの待機系システムへの送信待ちを検出した回数 LOG_BI_BUFFER : BI ログバッファの空き待ちを検出した回数 LOG_AI_BUFFER : AI ログバッファの空き待ちを検出した回数 LOG_RCP : リカバリログ量の減少待ちを検出した回数 LOG_BI_READ : BI ログ読込み待ちを検出した回数 LOG_BI_WRITE : BI ログ書込み待ちを検出した回数 LOG_AI_WRITE : AI ログ書込み待ちを検出した回数 LOG_ARC_FULL: アーカイブログファイルの満杯状態の解消待ちを検出した回数 COM_BUFFER : RDB システム間通信の通信バッファの空き待ちを検出した回数 COM_SEND : RDB システム間通信の送信待ちを検出した回数 COM_RECV : RDB システム間通信の受信待ちを検出した回数 OTHER : 上記以外の待ちを検出した回数 アクセスプランの内容を参照することで どのデータベース資源に対して どのようなアクセスを行っているかを見ることができます

18 この例では 表の全件検索が行われていることがわかります 表の全件検索では 表に格納されているすべてのデータを参照するため 表に格納されているデータ量に応じて処理時間がかかります また 表に格納されているすべてのデータがメモリ上に読み込まれていることも少ないため データの読込み処理が多く発生し さらに時間がかかることになります このことは サンプリングした実行状態の内訳に記載されている 13 回中 10 回がデータベースからのデータ読込み待ちで止まっているという状況からも見てとれます このように アクセスプランの情報や サンプリングした実行状態の内訳を見ることで どのような点に問題があるのかを判断することができます 注意 以下のSQL 文ではアクセスプランは表示されません CALL 文 COMMIT 文 ROLLBACK 文 2.3 動作環境の設定変更 パフォーマンスモニタの動作環境の変更を説明します 処理に時間がかかっていると判断する時間の変更 標準の設定では 1 秒以上の処理時間がかかっている SQL 文を処理に時間がかかっている SQL 文であると判断します しかし 全体的にアクセスデータ量が多く SQL 文の処理時間が通常の状態でも 1 秒を超えることがあるようなシステムも考えられます そのようなシステムでは 性能的になんら問題はないのに アクセスプランの情報が採取されてしまい パフォーマンスデータ格納ファイルを格納する領域として 必要以上に多くのディスクを使用してしまうことになります そのような場合には 処理に時間がかかっていると判断する時間を 1 秒より大きな値に変更することで ディスク領域の無駄を減らすことができます 処理に時間がかかっていると判断する時間を変更するには まず 性能異常と判断する処理時間を決定してください 次に Symfoware/RDB が停止している状態で rdbpmsetup コマンドの t オプションにより決定した時間に変更してください Symfoware/RDB が動作しているときには 変更できません 例 1 処理に時間がかかっていると判断する時間を 3 秒に変更する場合 $ rdbstop $ rdbpmsetup -t 3000 逆に 軽い処理ばかりのシステムの場合 1 秒未満でも処理に時間がかかりすぎているということもあります そのような場合には 処理に時間がかかっていると判断する時間を 1 秒よりも小さい値に設定することもできます その場合には 実行状態の内訳をサンプリングする間隔も合わせて小さい値に変更してください 実行状態の内訳をサンプリングする間隔は rdbpmsetup コマンドの s オプションにより変更します 例 2 処理に時間がかかっていると判断する時間を 800 ミリ秒に 実行状態をサンプリングする間隔を 200 ミリ秒に変更する場合 $ rdbstop $ rdbpmsetup -t 800 -s

19 注意 実行状態をサンプリングする間隔を短くすると パフォーマンスデータ格納ファイルを配置するディスクに必要な容量が多くなります セットアップガイド の 資源の見積り式 を参照して ディスクに必要な容量を算出し 十分な容量のディスクを用意してください 情報の保存期間の変更 パフォーマンスモニタは 収集した情報をパフォーマンスデータ格納ファイル内のデータとして ディスク上に保存します データの保存期間は 標準の設定では 24 時間となります アプリケーションのレスポンス異常を検出してから 24 時間以内に調査を行うことができない場合には 情報の保存期間を変更することで 調査に必要な情報を保存している期間を延ばすことができます 注意 情報の保存期間を変更すると パフォーマンスデータ格納ファイルを配置するディスクに必要な容量も変化します セットアップガイド の 資源の見積り式 を参照して ディスクに必要な容量を算出し 十分な容量のディスクを用意してください 情報の保存期間を変更するには Symfoware/RDB が停止している状態で rdbpmsetup コマンドの r オプションで行います 例 情報の保存期間を 48 時間に変更する場合 $ rdbstop $ rdbpmsetup -r システム情報の採取間隔の変更 標準の設定では 30 秒間隔でアプリケーションの動作状況 システム資源の使用情報 アプリケーションによって獲得される資源の占有情報の採取を行います 採取間隔は 通常変更する必要はありません なんらかの理由により変更する必要が生じた場合には Symfoware/RDB が停止している状態で rdbpmsetup コマンドの i オプションにより変更してください 例 システム情報の採取間隔を 60 秒に変更する場合 $ rdbstop $ rdbpmsetup -i 動作環境の設定内容の確認 パフォーマンスモニタが現在どのような設定内容で動作しているかを確認する方法は rdbpmsetup コマンドの q オプションにより行います 例 パフォーマンスモニタの動作環境の状態表示 $ rdbpmsetup -q Threshold time : 1000 (1) Status sampling interval : 1000 (2) Retention period : 24 (3)

20 System information collecting interval : 30 (4) (1) SQL 文のアクセスプラン情報を収集する基準時間 ( 単位はミリ秒 ) (2) SQL 文の処理状態をサンプリングする時間間隔 ( 単位はミリ秒 ) (3) 採取した情報の保存期間 ( 単位は時間 ) (4) アプリケーションの動作状況 システム資源の使用情報 およびアプリケーションによって獲得される資源の占有情報を採取する時間間隔 ( 単位は秒 )

21 第 3 章原因の特定 パフォーマンスモニタで取得したアクセスプランおよびサンプリングした実行状態の内訳から 処理が長くなっている原因を特定します 本章では 原因を特定する方法を説明します 3.1 アクセスプランを確認する アクセスプランの確認ポイントとしては 以下があります アクセス方式を確認する処理に時間がかかるアクセス方式が選択されていないか インデックスが適切に使用されているかを確認します ジョイン方法を確認する適切なジョイン系アクセスモデルが選択されているかを確認します アドバイスを確認する SQL 文に対するアドバイスを確認します また ASSIST 指定が有効となっているかを確認します ソート作業域 ワーク作業域を確認するソート作業域 ワーク作業域が不足していないかを確認します 参照 アクセスプランの出力形式や出力内容は SQLTOOL ユーザーズガイド を参照してください アクセス方式を確認する アクセスプランの SCAN エレメントの scan type でアクセス方式を確認します scan type の表示内容 TABLE KEY SCAN TABLE ALL SCAN TABLE PARALLEL SCAN INDEX KEY SCAN(n) INDEX ALL SCAN INDEX TABLE SCAN(n) 表をキー値で検索 表の全文検索 アクセス方式 表の全件を並列に検索 インデックス検索 インデックスの全件を順検索 インデックスをキー範囲検索しながら表のレコードも取り出す 処理に時間がかかるアクセス方式が選択されていないか インデックスが適切に使用されているかを確認します 適切なアクセス方式でない場合には アクセス方式をチューニングします アクセス方式のチューニング方法については 4.1 アクセス方式のチューニング を参照してください ジョイン方法を確認するアクセスプランのエレメント情報で ジョイン方法を確認します

22 エレメント名の表示内容 意味 特長 MERGE JOIN マージジョインを行う 複数の表をジョインキー ( ジョインで使用する列 ) の データの昇順に読み込み ジョインキーの等しい 行を結合します FETCH JOIN フェッチジョインを行う 一方の表のレコードごとに ジョインキーで他方の表へのアクセスを繰り返すため 大量データの検索を行う場合に十分な共用バッファがないと 結合される側の表のI/O 効率が低下します 一般的には 大量データのジョインには向きません 反面 少量データのジョインには向いています NESTED LOOP JOIN ネスティドループジョインを行う ジョインする表のすべてのレコードを組み合わせて結合を行うため ジョイン結果を求めるのに時間がかかります ジョイン方法の特長を考慮し 適切なジョイン方法が選択されているかを確認します ジョイン方法の選択が適切でない場合には ジョイン方法をチューニングします 参照 ジョイン方法についての詳細は アプリケーション開発ガイド ( 共通編 ) を参照してください また チューニング方法については 4.2 ジョイン方法のチューニング 4.3 ジョイン順のチューニング を参照してください アドバイスを確認する アクセスプランの Advice to an SQL statement で アドバイスを確認します アドバイスは 以下の場合に出力されます ASSIST 指定が無効となっている場合 SQL 文に対するアドバイスがある場合 アドバイスが出力されている場合には 出力された内容に応じて チューニングを実施します チューニング方法については 4.4 アドバイスに応じたチューニング を参照してください ソート作業域 ワーク作業域を確認する アクセスプランのセクション情報で 出力先の資源名を確認します 出力先の資源名として 以下が表示されている場合は ソート作業域 ワーク作業域が使用されています SORTxxxx WORKxxxx 次に SQL 性能情報の実行エレメント情報に出力される以下の内容を確認します 実行エレメント名詳細情報出力内容 SORT SCAN/ SORT INSERT SCAN WORK SCAN/ WORK INSERT SCAN file size run merge file size ソート処理時の二次記憶使用量 マージした回数 ソート処理時の二次記憶使用量

23 参照 SQL 性能情報については SQLTOOL ユーザーズガイド を参照してください ソート処理などを行う場合に 二次記憶を大量に使用していることで性能が劣化している可能性があります また ソート処理時に 2 回以上のマージ処理が行われていることで メモリが不足し 性能が悪くなっている可能性があります これらの場合には ソートサイズ ワークサイズのチューニングを実施します チューニング方法については 4.5 ソートサイズ ワークサイズのチューニング を参照してください 3.2 サンプリングした実行状態の内訳 データベースのデータを参照するには ディスク上にあるデータをメモリに読み込む必要があります ディスクからデータを読み込むためには それなりの時間がかかるため その読込み処理が完了するまではデータの参照を行うことができません 他にも 参照しようとしているデータを他のトランザクションが更新している可能性があります 適切に整合性のとれたデータを参照するためには 他のトランザクションの更新処理が完了するのを待つ必要があります このように データベースのデータを参照したり 更新したりするためには 様々な状態に対応して 処理を一時的に中断して待ち状態になることがあります サンプリングした実行状態の内訳を見ることで 発生した状況や どのような理由で処理が待ち状態になっていたのかを推測することができます サンプリングした実行状態の内訳で 待ち状態 (WAITING) となった回数と待ち状態となった原因を確認します 待ち状態 (WAITING) の場合の表示内容と発生した状況を以下に示します LOCK 表示内容待ち状態となった原因状況 LOCK_TEMPO RARY DB_BUFFER トランザクションの占有待ち トランザクションの一時占有待ち 共用バッファの空き待ち 検索対象となっているレコードへのアクセスが 他のトランザクションのアクセスと競合したため 待ち状態になったことを示します rdbpmreport コマンドで SQL 文が実行されていたときの資源の占有待ちに関する情報を確認することができます ページ長が大きくかつレコード長が短い というような 1 つのページの中に存在するレコードの数が多い場合に発生しやすくなります 共用バッファプール あるいはデフォルトバッファプールに未使用のページがなくなったときに発生します DB_READ ページ読込み待ち データベースからのページの読み込み待ちが発 生しています rdbpmreportコマンドで データベー スに関する入出力の動作状況を確認できます DB_WRITE ページ書込み待ち 共用バッファ上でページを変更しようとする際に 当該ページがデータベーススペースへ書き込み中であったため 書き込みが完了するまで待ちになったことを示します DB_WRITE_T RNEND LOG_BI_BUFF ER LOG_AI_BUFF ER LOG_RCP トランザクション終了時のページ書込み待ち BI ログバッファの空き待ち AI ログバッファの空き待ち リカバリログ量の減少待ち トランザクションのロールバック またはリカバリなしの利用規定を設定している DSI のデータ変更を行ったトランザクションのコミットで発生する場合があります テンポラリログファイルの BI ログバッファの空き待ちが発生したことを示します テンポラリログファイルの AI ログバッファの空き待ちが発生したことを示します テンポラリログファイルの AI ログ量がリカバリログ量を超過したため リカバリログ量が減少するまで待ちとなったことを示します

24 表示内容待ち状態となった原因状況 LOG_BI_READ BIログ読込み待ち テンポラリログファイルのBIログ域への読込み待ち が発生したことを示します LOG_BI_WRIT E LOG_AI_WRIT E LOG_ARC_FU LL BI ログ書込み待ち AI ログ書込み待ち アーカイブログファイルの満杯状態の解消待ち テンポラリログファイルの BI ログ域への書込み待ちが発生したことを示します テンポラリログファイルの AI ログ域への書込み待ちが発生したことを示します 動作環境ファイルに ARC_FULL=WAIT を指定している場合に アーカイブログファイルが満杯になったため アーカイブログファイルのバックアップまたは破棄が行われるまで待ち状態となったことを示します 処理が待ち状態となっていた場合のチューニング方法については 4.6 処理が待ち状態となっていた場合のチューニング を参照してください 参照 以下の項目についての詳細は クラスタ導入運用ガイド を参照してください DB_SEND COM_BUFFER COM_SEND COM_RECV

25 第 4 章チューニング 処理が長くなっている原因を特定後 性能を改善するためのチューニングを実施します 本章では 特定した原因に応じたチューニング方法を説明します 4.1 アクセス方式のチューニング 表の全件検索が行われている場合アクセスプランに表示される以下を参考にして インデックスを使用した検索処理に変更します CONVERT SQL Statement Advice to an SQL statement インデックスのチューニング Symfoware/RDB は 検索に利用できるインデックスが複数存在する場合に 検索範囲の最も小さいインデックスを採用します 検索範囲の大きさは WHERE 探索条件に指定した条件と インデックスに設定している最適化情報の異なるキー値数から計算しています すでに インデックス検索を実施しているが 使用するインデックスを変更したい場合のチューニング方法を説明します 比較述語に比較演算子 = を指定している場合 インデックスの検索範囲は インデックスのデータ部の 1/ 異なるキー値数 の範囲を検索すると計算します したがって 異なるキー値数の大きいインデックスの方が検索範囲が狭いと考え 優先的に選択されます 例 1 例 2 インデックス A の検索範囲の大きさは 1/10 で全体の 10% となります 一方 インデックス B の検索範囲の大きさは 1/5 で全体の 20% となるので インデックス A が選択されます もし インデックス B を優先的に選択させたい場合は インデックス B の異なるキー値数を 10 より大きくすることで インデックス A よりも優先して使用されるようになります マルチカラムインデックスの場合

26 マルチカラムインデックスの場合は 比較述語の比較演算子 = 条件が続く部分までの 1/ 異なるキー値数が検索範囲の大きさとなります 上記例では インデックス A の検索範囲の大きさは 1/10 で 10% となります なお インデックスの途中の列に条件を指定しない場合は それ以降の列に条件を指定しても検索範囲の大きさは変わりません IN 述語を指定している場合の検索範囲は (1/ 異なるキー値数 ) IN 値リスト数となります 同じ列に対して 比較述語 = を OR で複数指定した場合も同じです 比較述語 = 以外を指定している場合 BETWEEN 述語や比較述語 >(=) や <(=) LIKE 述語を指定している場合は それぞれの述語に応じた固定的な検索範囲の割合 ( 選択率といいます ) で検索範囲の大きさを決定します 各述語ごとの選択率は デフォルトで次のようになっています 述語の種類 BETWEEN 0.2 (20%) >(=) と <(=) の両方をANDで指定 0.25 (25%) LIKE 述語を指定 0.4 (40%) >(=) または <(=) のみを指定 0.5 (50%) 選択率 これらの値は 最適化パラメタ SS_RATE で変更することができます 参照 SS_RATE の詳細については SQLTOOL ユーザーズガイド の CHANGE ENV 文 を参照してください インデックス A の検索範囲の大きさは全体の 20% となります 一方 インデックス B の検索範囲の大きさは全体の 40% となるので インデックス A が選択されます 実際には LIKE 述語の方が絞り込める確率が高い場合は 最適化パラメタ SS_RATE で LIKE 述語の選択率を 20% より小さくすると インデックス B が優先して使用されるようになります

27 同じ述語を指定した場合は 異なるキー値数の大きいインデックスが優先されます この場合は インデックス A が選択されます インデックス B を選択したい場合は インデックス B の異なるキー値数を 100 より大きい値に変更するか または 次のように SQL 文を書き換えてください SELECT * FROM SCM1.TBL1 WHERE C1 >=1 AND C1 <=30 AND C2 BETWEEN 1 AND 20 上記のように SQL 文を変更すると インデックス A の検索範囲は 25% となり インデックス B が優先して選択されます マルチカラムインデックスの場合は 比較述語の比較演算子 = 条件が続く部分までの 1/ 異なるキー値数に 比較述語 = 以外を指定した述語の選択率を掛けたものが検索範囲の大きさとなります この場合は 1/ で 2% の大きさとなります ASSIST 指定によるチューニング 最適化情報や最適化パラメタを変更すると 他のアプリケーションや SQL 文に悪影響がでる場合があります このような場合 ASSIST 指定の USE_INDEX を利用すると 最適化情報や最適化パラメタを変更することなく 検索で使用するインデックスを固定化することができます 最適化パラメタについては 付録 A 性能チューニングのためのパラメタ一覧 を参照してください 参照 ASSIST 指定の使用方法については アプリケーション開発ガイド ( 共通編 ) を参照してください ポイント 検索に使用できるインデックスが複数ある場合は 次の優先順位で使用するインデックスを決定しています a. 検索範囲が最も小さいインデックスを優先する b. (a) で同じものが複数あれば インデックスで判定できる条件の多いものを優先する

28 c. (b) で同じものが複数あれば 検索範囲に使用した構成列までの異なるキー値数の大きいものを優先する 4.2 ジョイン方法のチューニング ジョインには マージジョイン フェッチジョイン ネスティドループジョインの 3 種類のジョイン方法があります ネスティドループジョインは 異なる表間の列を比較述語 = で指定していない場合に動作します マージジョインは大量のデータをジョインする場合に有効な手法です フェッチジョインは OLTP 業務での少量データ検索に有効なジョイン手法です 適切なジョイン方法を選択する ジョインの方法は Symfoware/RDB が自動的に選択しますが 最適化パラメタ JOIN_RULE で マージジョインを優先して選択するか フェッチジョインを優先して選択するかを指定することができます ただし ASSIST 指定のジョイン ASSIST によるチューニングを行わない場合 フェッチジョインを有効にするためには 表の結合列にインデックスを定義しているか 表の結合列がクラスタキーになっていなければなりません インデックスやクラスタキーになっていない場合は JOIN_RULE でフェッチジョインを優先するように指定しても マージジョインが選択されるので注意が必要です 参照 ASSIST 指定のジョイン ASSIST によるチューニングの詳細については アプリケーション開発ガイド ( 共通編 ) を参照してください フェッチジョインにおけるジョインする方向 フェッチジョインでは ジョインする方向により 性能値が左右されます フェッチジョインの軸となる表は なるべくレコード件数が絞り込まれている表である方が性能は良くなります 上記の例で TBL1 側が TBL1.C2 BETWEEN 10 AND 20 で十分に絞り込まれるのであれば TBL1 TBL2 の順でジョインを行った方が性能が良くなります Symfoware が選択するアクセスモデルの精度を上げるには IX-2 を BETWEEN 述語で検索するときに 何パーセントぐらいのデータを検索するのかがなるべく正確である方が良いです Symfoware がアクセスプランを選択したときの読み込むレコード件数の見積もり結果はアクセスプランに出力されるので 性能情報で取得される実際の検索結果件数と大きく異なる場合は インデックスの異なるキー値数を変更したり SS_RATE による選択率を変更して 実際に検索する件数に近くなるようにチューニングすると Symfoware のアクセスプランの選択精度が向上します 上記の例で もし TBL2 TBL1 の順でジョインしているなら BETWEEN の選択率を SS_RATE で小さくすることにより TBL1 TBL2 でジョインするようになります また フェッチジョインは ジョインする表のジョインキーにインデックスが定義されていないと選択されないことを利用して IX-1 を削除することにより TBL1 TBL2 へのフェッチジョインしか行うことができなくなります 定型的にジョイン方向が決まるような場合 ( 絞り込める表が必ず決まっているような場合 ) は その表に対するジョインキーにあえてインデックスを定義しないのも 1 つのチューニング手法です ASSIST 指定によるチューニング 最適化情報や最適化パラメタを変更すると 他のアプリケーションや SQL 文に悪影響がでる場合があります このような場合 ASSIST 指定を利用すると 最適化情報や最適化パラメタを変更することなく ジョイン方法やフェッチジョインする方向を固定化することができます ジョイン方法を固定化したい場合は JOIN_RULE を フェッチジョインする方向などジョイン順を固定化したい場合は LEADING_TABLE を利用します

29 上記の SQL 文例で TBL1 TBL2 の順にジョインしたい場合は 以下のように LEADING_TABLE を指定します SELECT /* ASSIST LEADING_TABLE(TBL1,TBL2) */ * FROM SCM1.TBL1,SCM2.TBL2 WHERE TBL1.C1=TBL2.C1 AND TBL1.C2=10 AND TBL2.C2=1 ジョインする方向に加えて ジョイン方法をフェッチジョインにしたい場合は 以下のように JOIN_RULE 指定します SELECT /* ASSIST LEADING_TABLE(TBL1,TBL2) JOIN_RULE(FETCH) */ * FROM SCM1.TBL1,SCM2.TBL2 WHERE TBL1.C1=TBL2.C1 AND TBL1.C2=10 AND TBL2.C2=1 また ジョインに利用するインデックスを指定したい場合は JOIN_RULE LEADING_TABLE USE_INDEX を同時に指定します SELECT /* ASSIST LEADING_TABLE(TBL1,TBL2) JOIN_RULE(FETCH) USE_INDEX(TBL2(IX_4)) */ * FROM SCM1.TBL1,SCM2.TBL2 WHERE TBL1.C1=TBL2.C1 AND TBL1.C2=10 AND TBL2.C2=1 参照 JOIN_RULE LEADING_TABLE および USE_INDEX の詳細については アプリケーション開発ガイド ( 共通編 ) を参照してください 共用バッファのチューニング フェッチジョインで表を結合するときは 結合する表のクラスタキーやインデックスにランダムにアクセスするため 結果件数が多いときに 結合される側の表とインデックスに共用バッファを十分に用意しておかないと ページの再読み込みが多く発生して性能が悪くなることがあります DSI の読み込みページ数は rdbps コマンドで知ることができます 読み込みが多く発生しているようなら 結合される側のインデックスと表に十分な共用バッファを与えるようにしてください 4.3 ジョイン順のチューニング FROM 句に表と結合表を指定したとき 表と結合表 ( 結合型が LEFT の場合 ) の左側の表を先にジョインし その後 右側の表とジョインしたい場合があります また 結合表 ( 結合型が LEFT の場合 ) を複数指定したとき 左側の表どうしを先にジョインし その後 右側の表とジョインしたい場合があります このような場合 最適化パラメタ JOIN_ORDER で FROM 句全体のジョイン順を最適化することによって 意図したジョイン順を選択できます

30 TBL2 が大量件数で TBL1.C2=10 の検索範囲が小さい場合 TBL2 が大量件数で TBL1.C1=10 の検索範囲が小さい場合 TBL1 TBL2 TBL3 の順にジョインした方が性能がよくなります このような場合は 最適化パラメタ JOIN_ORDER に AUTO または OUTSIDE を指定します TBL2 が少量件数で TBL1.C2=10 の検索範囲が大きい場合 TBL2 が少量件数で TBL1.C1=10 の検索範囲が大きい場合 TBL2 TBL3 TBL1 の順にジョインした方が性能がよくなります このような場合は 最適化パラメタ JOIN_ORDER に AUTO または INSIDE を指定します 適切なジョイン順を選択する 一般的に 最適化パラメタ JOIN_ORDER には AUTO と指定しておくことをお奨めします その上で 最適化情報を設定または変更しても意図したジョイン順にならない場合は OUTSIDE または INSIDE を指定して ジョイン順をチューニングしてください ASSIST 指定によるチューニング 最適化パラメタ JOIN_ORDER を変更すると 他のアプリケーションや SQL 文に悪影響がでる場合があります このような場合 ASSIST 指定の LEADING_TABLE を利用すると 最適化パラメタを変更することなく ジョイン順を固定化することができます 参照 ASSIST 指定の使用方法については アプリケーション開発ガイド ( 共通編 ) を参照してください

31 4.4 アドバイスに応じたチューニング アドバイスに ASSIST 指定のメッセージが出力された場合 以下の状態になるまでチューニングを行います ASSIST 指定が有効になる 意図したアクセスプランになる たとえば 以下のように TBL1 に以下のインデックス DSO が定義されている場合 定義されていない IX3 を USE_INDEX に指定すると インデックスが定義されていない旨のメッセージが出力されます このような場合には 適切なインデックスを使用することで ASSIST 指定が有効となります [TBL1] インデックスのDSO 名 IX1 IX2 [ アドバイスの出力例 ] C1 C2 構成列名 : SQL statement: SELECT /* ASSIST USE_INDEX(TBL1(IX3)) */ C2 FROM SCM1.TBL1 WHERE TBL1.C2 = 1 Access plan: : Advice to an SQL statement: JYP2410I ASSIST 要素 USE_INDEX に指定されたインデックス IX3 が定義されていません. 4.5 ソートサイズ ワークサイズのチューニング 性能情報を取得してソートやワークでファイルを使用している場合 ソートメモリやワークメモリを増やすことで ソートやワークで二次記憶を使用しないようにして性能を改善することができます ソートメモリやワークメモリを増やすには 動作環境ファイルの実行パラメタ SORT_MEM_SIZE および WORK_MEM_SIZE で行うことができます 作業域の大きさは 次のように見積もることができます また アプリケーション単位で使用するソートまたはワークの最大量は rdbps コマンド (s オプション指定 ) で知ることもできます 4.6 処理が待ち状態となっていた場合のチューニング サンプリングした実行状態の内訳に 待ち状態 (WAITING) が表示されていた場合 資源の占有待ち 入出力待ちなどにより 一時的に処理が中断していたことを示します このような場合には 事象に応じて 以下の対処を実施します

32 事象対処備考 トランザクションの占有待ち (LOCK) トランザクションの一時占有待ち (LOCK_TEMPOR ARY) 共用バッファの空き待ち (DB_BUFFER) ページ読込み待ち (DB_READ) ページ書込み待ち (DB_WRITE) トランザクション終了時のページ書込み待ち (DB_WRITE_TR NEND) BI ログバッファの空き待ち (LOG_BI_BUFFE R) AI ログバッファの空き待ち 排他の単位を行に変更 トランザクションの独立性水準を変更 ページ長の変更 格納構造の変更 バッファプールのページ数の増量 データベースバッファの再設計 ディスク配置の変更 テンポラリログファイルのリカバリログ量の変更 トランザクション当たりの変更データ量の削減 ( ロールバックで多く発生している場合 ) DSI のリカバリなしの利用規定の解除 ( コミットで多く発生している場合 ) ディスク配置の変更 BI ログバッファ数の変更 ディスク配置の変更 アクセスプラン情報の R_LOCK で確認できます アクセスプラン情報の transaction isolation level で確認できます 処理の論理上問題ないかを確認して 独立性水準を READ UNCOMMITTED に変更するなどの対処を実施します ページ長を小さくすると 1 つのページに格納されるレコードの件数が少なくなり 1 つのページへのアクセスの競合が少なくなります ただし ページ長を小さくすると必要となるデータベーススペースの容量が多くなります ページ長の変更は 十分なデータベーススペースの容量を確保した上で行ってください RANDOM 構造に変更した場合 データは割り付けを行った領域全体に分散されて格納されます そのため 1 つのページに格納されるレコード数は少なくなるため 1 つのページへのアクセスの競合が少なくなります メモリに余裕のある範囲でバッファプールのページ数を増やしてください 頻繁にアクセスされる資源に対するバッファの割当てを増やしてください データベースのディスク配置を見直し 入出力の負荷を複数のディスクに分散させてください 一般的にリカバリログ量が多いほど データベーススペースへのページの書き込み頻度は少なくなる反面 ダウンリカバリ時間が長くなります このためダウンリカバリ時間に問題がない程度までリカバリログ量を多くとるようにしてください トランザクション当たりの変更データ量が多いほど ロールバックに時間がかかります DSI のリカバリなしの利用規定を設定している場合 当該 DSI のデータ変更はトランザクションのコミットと同期してデータベーススペースへ反映します これに対してリカバリなしの利用規定を設定していない場合は データベーススペースへの反映はバックグラウンドで行います テンポラリログファイルの BI ログ域について ディスク配置の見直しを行い I/O 効率の向上を図ります テンポラリログファイルの BI ログ域と同じ物理ディスク上に 頻繁にアクセスが行われる他のファイルを配置している場合は それらのファイルを別の物理ディスクへ配置します ディスク配置に問題がないと判断した場合 メモリに余裕のある範囲で BI ログバッファ数を増やしてください テンポラリログファイルの AI ログ域およびアーカイブログファイルについて ディスク配置の見直

33 事象対処備考 (LOG_AI_BUFFE R) リカバリログ量の減少待ち (LOG_RCP) BI ログ読込み待ち (LOG_BI_READ) BI ログ書込み待ち (LOG_BI_WRITE ) AI ログ書込み待ち (LOG_AI_WRITE ) アーカイブログファイルの満杯状態の解消待ち (LOG_ARC_FUL L) AI ログバッファ数の変更 テンポラリログファイルのリカバリログ量の変更 ディスク配置の変更 ディスク配置の変更 アーカイブログファイルの容量 アーカイブログファイルのバックアップ およびアーカイブログファイルの破棄の契機について 見直しを実施 しを行い I/O 効率の向上を図ります テンポラリログファイルの AI ログ域およびアーカイブログファイルと同じ物理ディスク上に 頻繁にアクセスが行われる他のファイルを配置している場合は それらのファイルを別の物理ディスクへ配置します ディスク配置に問題がないと判断した場合 メモリに余裕のある範囲で AI ログバッファ数を増やしてください ダウンリカバリ時間に影響を与えないように RDB システムは常時 AI ログ量がリカバリログ量を超えないように制御しています 一般的にリカバリログ量が多いほど この制御は働かない反面 ダウンリカバリ時間が長くなります このためダウンリカバリ時間に問題がない程度までリカバリログ量を多くとるようにしてください テンポラリログファイルの BI ログ域について ディスク配置の見直しを行い I/O 効率の向上を図ります テンポラリログファイルの BI ログ域と同じ物理ディスク上に 頻繁にアクセスが行われる他のファイルを配置している場合は それらのファイルを別の物理ディスクへ配置します テンポラリログファイルの AI ログ域について ディスク配置の見直しを行い I/O 効率の向上を図ります テンポラリログファイルの AI ログ域と同じ物理ディスク上に 頻繁にアクセスが行われる他のファイルを配置している場合は それらのファイルを別の物理ディスクへ配置します アーカイブログファイルが満杯になったことで バックアップまたは破棄が行われるまで 待ち状態となります 4.7 その他のチューニング その他の原因によるチューニングについて説明します CAST を使用した SQL 文のチューニング CAST オペランドにインデックス構成列を指定して インデックスの範囲検索を行いたい場合があります 最適化パラメタ SCAN_KEY_CAST で インデックス検索の適用を拡大することで CAST オペランドについてもインデックスの範囲検索を行います 範囲検索のチューニング 以下の場合 チューニングの効果があります - WHERE 句または結合表の結合条件に CAST に指定した列と 列を含まない値式を比較述語 = で指定している場合 例 インデックス定義 人事テーブル.IX1< 従業員番号 > 従業員番号 :DEC(6)

34 SELECT 等級 FROM 人事テーブル WHERE CAST( 従業員番号 AS CHAR(8)) = '123456' ジョインのチューニング 以下の場合 チューニングの効果があります - WHERE 句または結合表の結合条件に 表の列同士を比較演算子 = で指定した条件 ( 表の結合関係を表す条件 ) を指定している かつ - 上記の条件の比較演算子 = で指定した片方または両方の列を CAST オペランドに指定している場合 例 インデックス定義 人事テーブル.IX1< 従業員番号 > 従業員番号 :DEC(6) 目標管理テーブル.IX2< 従業員番号 > 従業員番号 :INTEGER SELECT 人事テーブル. 従業員名, 目標管理テーブル. 難易度 FROM 人事テーブル, 目標管理テーブル WHERE 人事テーブル. 従業員番号 = CAST( 目標管理テーブル. 従業員番号 AS DEC(6))

35 4.7.2 トランザクション占有のチューニング アクセスプランを取得すると データベース資源 (DSO) に対する占有単位 占有モードを知ることができます 競合するアプリケーションの占有単位および占有モードを確認して デッドロックの発生の可能性が高い場合には トランザクション占有のチューニングを実施します カーソルの更新可能性句に FOR UPDATE を指定する カーソルを使用してデータベースの更新を行う場合 カーソルの更新可能性句に FOR UPDATE を指定すると 占有モードは非共用モードとなります 読み込み時から非共用モードでデータベース資源を占有するため デッドロックが発生しにくくなります 占有単位のチューニング アクセスプランの占有範囲が DSI となっている場合は 表の全件検索やインデックスの全件検索が選択されています DSI 全体を占有したくない場合は 検索に利用できるインデックスを定義して データベースの読込み範囲を小さくします なお 占有単位に REC が表示されている場合は 行単位の排他を指定している場合です このときのアクセスモデルが表の全件検索であると 占有のためにレコード件数に比例したメモリを使用するため 表の全件検索とならないようにデータベースをチューニングしなければなりません UPDATE 文 : 探索または DELETE 文 : 探索の検索パスの占有モード

36 UPDATE 文 : 探索や DELETE 文 : 探索において 更新対象レコードを位置づける部分の表の占有モードは 共用モード がデフォルトです OLTP 業務などで UPDATE 文 : 探索や DELETE 文 : 探索を利用するときは USQL_LOCK に EX を指定すると 更新対象レコードを位置づけるときに 非共用モード で占有するので デッドロックを起こしにくくなります

37 付録 A 性能チューニングのためのパラメタ一覧 本章では 性能チューニングのためのパラメタを説明します A.1 パラメタ一覧 アプリケーションの動作環境をチューニングすることで アプリケーションの処理性能を向上させることができます 以下のいずれかの方法で 性能チューニングのためのパラメタの値を変更することで 動作環境をチューニングできます 動作環境ファイルのパラメタの値を変更 rdbexecsql コマンドの CHANGE ENV 文でパラメタの値を変更 参照 rdbexecsql コマンドでパラメタの値を変更する方法については SQLTOOL ユーザーズガイド を参照してください 性能チューニングのためのパラメタを 以下に示します 最適化パラメタ 並列クエリ 分類実行パラメタ概要 IGNORE_INDEX JOIN_RULE JOIN_ORDER SCAN_KEY_ARITHMET IC_RANGE SCAN_KEY_CAST SS_RATE TID_SORT TID_UNION USQL_LOCK MAX_PARALLEL PARALLEL_SCAN インデックスを使用しないアクセスプランを選択するか否か ジョインする方法 結合表と他の表のジョイン順 四則演算の検索範囲について インデックス範囲検索 または クラスタキーの検索を行うか否か 探索条件の CAST オペランドに指定した列でインデックスの範囲検索 または クラスタキー検索を行うか否か 述語ごとの検索範囲の選択率の値 インデックス検索と表データ取得のアクセスモデル TID ソートを利用するか否か TID ユニオンマージのアクセスモデルを有効にするか否か UPDATE 文 : 探索または DELETE 文 : 探索の更新標的レコードを位置づける部分の占有モード データベースを並列に検索する場合の多重度 アプリケーション単位またはコネクション単位にデータベースを並列に検索するか否か 排他 R_LOCK 排他の単位を行とする

38 分類実行パラメタ概要 作業領域 SORT_HASHAREA_SIZ E SORT_MEM_SIZE WORK_MEM_SIZE ソート処理がレコードをハッシングして格納するための領域サイズ 作業用ソート領域として使うメモリサイズ 作業用テーブルとして使うメモリサイズ 注意 ASSIST 指定を指定した場合 CHANGE ENV 文または動作環境ファイルで設定した以下のパラメタよりも ASSIST 指定が優先されます IGNORE_INDEX JOIN_RULE JOIN_ORDER SCAN_KEY_ARITHMETIC_RANGE SCAN_KEY_CAST SS_RATE TID_SORT TID_UNION パラメタの詳細を説明します 最適化パラメタ IGNORE_INDEX 指定形式 IGNORE_INDEX = ({YES NO}) 実行パラメタの意味 データベースを検索するときに インデックスを使用しないアクセスプランを選択するか否かを指定します データウェアハウジングにおいて大量のデータを検索および集計する場合には インデックスだけではデータが絞りきれず インデックスを使う分だけ無駄なオーバヘッドが発生することがあります このような場合は 当パラメタに YES を指定することにより 表の全件検索または並列スキャンのアクセスモデルを採用します 省略値は NO です ただし SQL 文に ASSIST 指定の USE_INDEX を指定した場合 ASSIST 指定が優先され IGNORE_INDEX の指定に関わらず ASSIST 指定に指定されたインデックスを使用した検索を行います パラメタの意味 YES: NO: JOIN_RULE 指定形式 インデックスを使用しないアクセスプランを選択します インデックスが使用できるときは インデックスを使用したアクセスプランを選択します JOIN_RULE = ({AUTO MERGE FETCH})

39 実行パラメタの意味 ジョインする方法を指定します 省略値は AUTO です ただし SQL 文に ASSIST 指定の JOIN_RULE を指定した場合 ASSIST 指定が優先され JOIN_RULE の指定に関わらず ASSIST 指定に指定されたジョイン方法に従います パラメタの意味 AUTO: Symfoware/RDB が自動的に選択します MERGE: マージジョインのアクセスモデルを優先します FETCH: JOIN_ORDER 指定形式 フェッチジョインのアクセスモデルを優先します JOIN_ORDER = ({AUTO INSIDE OUTSIDE}) 実行パラメタの意味 結合表と他の表をジョインする場合のジョイン順を指定します 省略値は INSIDE です ただし SQL 文に ASSIST 指定の LEADING_TABLE を指定した場合 ASSIST 指定が優先され JOIN_ORDER の指定に関わらず ASSIST 指定に指定されたジョイン順に従います パラメタの意味 AUTO: Symfoware/RDB が自動的に選択します INSIDE: 結合表から先にジョインします OUTSIDE: 結合表の中に指定した表と結合表の外に指定した表から先にジョインします SCAN_KEY_ARITHMETIC_RANGE 指定形式 SCAN_KEY_ARITHMETIC_RANGE = ({YES NO}) 実行パラメタの意味 四則演算の検索範囲について インデックス範囲検索やクラスタキーの検索を行います 省略値は YES です ただし SQL 文に ASSIST 指定の USE_INDEX を指定した場合 ASSIST 指定が優先され SCAN_KEY_ARITHMETIC_RANGE の指定に関わらず ASSIST 指定に指定されたインデックスを使用した検索を行います パラメタの意味 YES: NO: 四則演算の検索埴について インデックス範囲検索 または クラスタキーの検索を行う 四則演算の検索埴について インデックス範囲検索 または クラスタキーの検索を行わない SCAN_KEY_CAST 指定形式 SCAN_KEY_CAST = ({YES NO})

40 実行パラメタの意味 インデックス構成列やクラスタキーが WHERE 句または ON 句の CAST に指定されてもインデックスの範囲検索やクラスタキー検索を行います 省略値は YES です ただし SQL 文に ASSIST 指定の USE_INDEX を指定した場合 ASSIST 指定が優先され SCAN_KEY_CAST の指定に関わらず ASSIST 指定に指定されたインデックスを使用した検索を行います パラメタの意味 YES: NO: SS_RATE 指定形式 探索条件の CAST オペランドに指定した列でインデックスの範囲検索 または クラスタキー検索を行う 探索条件に指定したインデックスキーまたは クラスタキーで範囲検索を行う SS_RATE = ([ 選択率 1][,[ 選択率 2][,[ 選択率 3][,[ 選択率 4][,[ 選択率 5]]]]]) 実行パラメタの意味 BETWEEN 述語 比較述語 LIKE 述語および CONTAINS 関数でインデックスを検索するとき インデックスの検索範囲の割合を指定します 小数点付きの小数 (0 n 1) の範囲を指定します 値は 0 以上 1 以下の小数を指定してください 小数第 6 位まで指定できます ただし SQL 文に ASSIST 指定の USE_INDEX を指定した場合 ASSIST 指定が優先され SS_RATE の割合に関わらず ASSIST 指定に指定されたインデックスを使用した検索を行います パラメタの意味 選択率 1: BETWEEN 述語を指定した場合のインデックスの検索範囲 省略値は 0.2 選択率 2: 比較述語 > >= と < <= でインデックスの検索開始位置および検索終了位置の両方が指定されている場合のインデックスの検索範囲 省略値は 0.25 選択率 3: 比較述語 > >= < <= でインデックスの検索開始位置または検索終了のみが指定されている場合のインデックスの検索範囲 省略値は 0.5 選択率 4: LIKE 述語を指定した場合のインデックスの検索範囲 省略値は 0.4 選択率 5: TID_SORT 指定形式 CONTAINS 関数を指定した場合のインデックスの検索範囲 省略値は TID_SORT = ({YES NO}) 実行パラメタの意味 インデックス検索と表データ取得のアクセスモデルにおいて TID ソートを利用するか否かを指定します 省略値は YES です ただし SQL 文に ASSIST 指定の FIRST_ROWS を指定した場合 ASSIST 指定が優先され TID_SORT の指定に関わらず TID ソートを利用しません パラメタの意味 YES: TID ソートを利用します

41 NO: TID_UNION 指定形式 TID ソートを利用しません TID_UNION = ({YES NO}) 実行パラメタの意味 TID ユニオンマージのアクセスモデルを有効にするか否かを指定します 省略値は YES です ただし SQL 文に ASSIST 指定の USE_INDEX を指定した場合 ASSIST 指定が優先され TID_UNION の指定に関わらず ASSIST 指定に指定されたインデックスを使用した検索を行います パラメタの意味 YES: NO: USQL_LOCK 指定形式 TID ユニオンマージのアクセスモデルを有効にします TID ユニオンマージが効果的と判断した場合に選択します TID ユニオンマージのアクセスモデルを有効にしません USQL_LOCK = ({SH EX}) 実行パラメタの意味 UPDATE 文 : 探索および DELETE 文 : 探索において 更新レコードを検索するアクセスモデルの表の占有モードを指定します 省略値は SH です パラメタの意味 SH: EX: 更新標的レコードを検索するアクセスモデルで共用モードで表を占有します 更新標的レコードを検索するアクセスモデルで非共用モードで表を占有します 並列クエリに関する実行パラメタ MAX_PARALLEL 指定形式 MAX_PARALLEL = ( 多重度 ) 実行パラメタの意味 SQL 文でデータベースを並列に検索する場合の多重度を 2~100 の範囲で指定します 省略した場合は システム用の動作環境ファイルにおける MAX_PARALLEL の指定に従って並列検索 ( 並列クエリ ) を行います SQL 文でデータベースを並列に検索できるのは 単一行 SELECT 文またはカーソル宣言で並列指定を指定した場合です 表の DSI の数が 指定した多重度よりも少ない場合は DSI の数を多重度として並列検索を行います PARALLEL_SCAN 指定形式 PARALLEL_SCAN = ({YES NO}) 実行パラメタの意味 アプリケーション単位またはコネクション単位に データベースを並列に検索する ( 並列クエリ ) か否かを指定します 省略した場合は NO が指定されたとみなします

42 パラメタの意味 YES: NO: データベースを並列に検索します この場合 そのアプリケーションの単一行 SELECT 文および OPEN 文を並列検索で実行できます ただし 以下のいずれかの条件を満たす場合 並列検索は実行されず従来のアクセス手順でデータベースをアクセスします - 表が DSI 分割されていない または 1 つの DSI に対するアクセスの場合 - クラスタキーを利用したデータベースアクセスが可能な場合 - 探索条件に ROW_ID を指定した検索の場合 - インデックスを利用したデータベースアクセスが可能な場合 データベースを並列に検索しません 排他に関する実行パラメタ R_LOCK 指定形式 R_LOCK = ({YES NO}) 実行パラメタの意味 占有の単位を行とするかどうかを指定します 省略した場合は システム用の動作環境ファイルにおける R_LOCK の指定に従います パラメタの意味 YES: NO: 占有の単位を行とします このパラメタを指定した場合 クライアント用およびサーバ用の動作環境ファイルに DSO_LOCK パラメタを指定することはできません 占有の単位は DSO_LOCK の指定に従います このパラメタを指定し かつ DSO_LOCK が指定されていない場合は Symfoware/RDB によって自動的に占有の単位が選択されます 参照 詳細については アプリケーション開発ガイド ( 共通編 ) の 排他制御 を参照してください 注意 - 動作環境ファイルの R_LOCK が NO の場合 動作環境ファイルの DEFAULT_ISOLATION に REPEATABLE_READ を指定 または SET TRANSACTION 文に REPEATABLE READ を指定しても 独立性水準は SERIALIZABLE になります - 動作環境ファイルの R_LOCK が YES の場合 動作環境ファイルの DEFAULT_ISOLATION または SET TRANSACTION 文に SERIALIZABLE を指定しても 独立性水準は REPEATABLE READ になります 作業領域に関する実行パラメタ SORT_HASHAREA_SIZE 指定形式 SORT_HASHAREA_SIZE = ( メモリサイズ ) 実行パラメタの意味 ソート処理がレコードをハッシングして格納するための領域のサイズです 2112~ の範囲で指定します 単位はキロバイトです 省略した場合は メモリ上のすべてのレコードをハッシングして格納します

43 SORT_MEM_SIZE 指定形式 SORT_MEM_SIZE = ( メモリサイズ ) 実行パラメタの意味 ソート処理のために作業用ソート領域としてサーバ側で使用するメモリの大きさを 64~ の範囲で指定します 単位はキロバイトです 省略した場合は システム用の動作環境ファイルにおける SORT_MEM_SIZE の指定に従います この領域は RDB プロセスのローカルメモリにセション単位に獲得されます WORK_MEM_SIZE 指定形式 WORK_MEM_SIZE = ( メモリサイズ ) 実行パラメタの意味 作業用テーブルとしてサーバ側で使用するメモリのサイズを 64~ の範囲で指定します 単位はキロバイトです 省略した場合は システム用の動作環境ファイルにおける WORK_MEM_SIZE の指定に従います この領域は RDB プロセスのローカルメモリにセション単位に獲得されます

44 索引 [A] ASSIST 指定が無効となっている場合...3 [C] CAST を使用した SQL 文のチューニング...29 [I] IGNORE_INDEX...34 [J] JOIN_ORDER...35 JOIN_RULE...34 [M] MAX_PARALLEL...37 [O] OPEN 文...38 [P] PARALLEL_SCAN...37 [R] rdbpmsetup コマンド...14,15 rdbpmsqllist コマンド...9,10 R_LOCK...38 [S] SCAN_KEY_ARITH...35 SCAN_KEY_CAST...35 SORT_HASHAREA_SIZE...38 SORT_MEM_SIZE...39 SQL 文のアクセスプランと処理の内訳を表示する...10 SQL 文の一覧...8 SQL 文の処理時間の監視...8 SQL 文を依頼したクライアントの情報...8 SS_RATE...36 [T] TID_SORT...36 TID_UNION...37 [ さ ] 最適化パラメタ...34 作業用ソート領域...39 作業用テーブル...39 サンプリングした実行状態の内訳...19 資源の占有情報...8 資源の占有待ちが多く発生している場合...4 システム資源の使用情報...8 システム情報の採取間隔の変更...15 ジョイン順のチューニング...25 ジョイン方法のチューニング...24 情報の保存期間の変更...15 処理が待ち状態となっていた場合のチューニング...27 処理時間が長い SQL 文を特定する...9 処理に時間がかかっていると判断する時間の変更...14 性能チューニングのためのパラメタ一覧...33 占有の単位...38 その他のチューニング...29 ソートサイズ ワークサイズのチューニング...27 [ た ] 単一行 SELECT 文...37,38 チューニング...21 チューニングの概要...1 チューニングの手順...1 チューニングの例...1 動作環境の設定内容の確認...15 動作環境の設定変更...14 トランザクション占有のチューニング...31 [ な ] 入出力待ちが多く発生している場合...6 [ は ] パフォーマンスモニタ...8 パフォーマンスモニタの概要...8 パフォーマンスモニタの使用方法...8 表の全件検索となっている場合...1 並列クエリ...37 [U] USQL_LOCK...37 [W] WORK_MEM_SIZE...39 [ あ ] アクセスプランの情報...8 アクセスプランを確認する...17 アクセス方式のチューニング...21 アドバイスに応じたチューニング...27 アプリケーションの動作状況...8 [ か ] 原因の調査...1 原因の特定