Db2 DDFアプリケーションのコーディングに関するヒント

このセクションでは、Db2 DDFアプリケーションの効率を高めるための方法について説明します。

分散リレーショナルデータベースアーキテクチャプロトコルの使用

Db2プライベートプロトコル（PP）から分散リレーショナルデータベースアーキテクチャープロトコル（DRDAP）に切り替えることによって、パフォーマンスを向上させることができます。

DRDAPは、PPでは使用不可能な以下の機能をサポートします。

TCP/IPを使用した接続
z/OS以外のプラットフォームでのDb2データへの接続
SQL CONNECTステートメントを使用した接続
DDL SQLステートメント（たとえばCREATE、DROPなど）およびDCL SQLステートメント（たとえばGRANT、REVOKEなど）
ストアードプロシージャー。アプリケーションリクエスターとアプリケーションサーバー間のネットワークトラフィックを最小限に抑えます。
リモートバインド。リモートバインドはDb2 PPによってサポートされていないため、SQLはすべて動的SQLとして処理されます。これはパフォーマンス低下の原因になる可能性があります。
静的SQL。
ユーザー定義データタイプおよびLOBデータタイプ
スレッドプーリング
より簡潔で圧縮されたメッセージ形式。これによりネットワークパフォーマンスが向上します。

Db2ユニバーサルデータベースでのタイプ4ドライバーの使用

Db2ユニバーサルデータベース（UDB）は、現在、タイプ2、タイプ3、タイプ4の3つのタイプのドライバーをサポートしています。タイプ4のドライバーは、他のタイプに比べて以下の点で優れています。

Db2 CLIドライバーに依存しないため、Db2クライアントライブラリーは不要です。
アプレットドライバーとして使用できますが、アプレットサーバーへの接続が不要です。そのため、タイプ3ドライバーよりパフォーマンスが優れています。
Javaで開発され、タイプ2、タイプ3ドライバーよりもファイルサイズが非常に小さくなります。
DRDA AR（アプリケーションリクエスター）として実装され、Db2接続を介せずに直接Db2 UDBへの接続を提供します。
プラットフォーム全般に及ぶ共通のJDBCの実装により、汎用性と高度なパフォーマンスを提供します。

重要：今後、IBMは、タイプ2、タイプ3ドライバーのサポートを打ち切ります。将来のJava Database Connectivityに対する新機能では、すべて新しいユニバーサルドライバーアーキテクチャーが使用されます。

分散環境における複数行の操作

分散プラットフォームでINSERTステートメントを実行する場合、Db2 ODBCクライアントは配列入力を使用します。

INSERTステートメントは、ドライバーによって単一ネットワークメッセージにまとめられ、Db2 for z/OSシステムに送られます。
サーバーでは、メッセージが分離され、複数のINSERTステートメントが実行されて、入力配列を構成する行がすべて挿入されます。これによってネットワークトラフィックが軽減し、送信が必要なメッセージの数が少なくなります。

Db2 for z/OS V8では、配列入力によってDb2の複数行INSERTを使用する機能を活用できます。この場合、単一メッセージ（従来どおり）が単一（複数行）INSERTステートメントと共に送信されますが、INSERTステートメントは1つだけであるため、DDFとDBM1間のAPI交差数が減少します。そのため、CPU時間と経過時間が短縮されます。

複数行のフェッチ操作を利用できるようにアプリケーションを変更する必要があるかもしれません。たとえば、ホスト変数配列を使用するためにアプリケーションを設定する必要があります。ただし、リモートクライアントを使用してDb2に接続する場合（たとえば、ユニバーサルドライバーとタイプ4接続を使用するJavaアプリケーションなど）、クライアントに返信されるブロックの構築中に表から行を取り出す際、Db2は自動的に複数行フェッチを使用します。

複数行のフェッチ操作を利用できるようにDDF以外のアプリケーションを変更する必要があるかもしれません。たとえば、SQLでホスト変数配列や新しい複数行の文節を使用するためにアプリケーションのコーディングを行う必要があります。ただし、リモートクライアントを使用してDb2に接続する場合（たとえば、ユニバーサルドライバーとタイプ4接続を使用するJavaアプリケーションなど）、クライアントに返信されるブロックの構築中に表から行を取り出す際、Db2は自動的に複数行フェッチを使用できます。

Db2が分散アプリケーションの複数行フェッチを自動的に利用するには、以下の条件が必要です。

カーソルが読み取り専用
未確定カーソルでのCURRENTDATA NOの使用

これらの条件のいずれかが満たされると、Db2はブロックフェッチを有効にします。Db2がDDFアドレススペースでクライアントに送信されるデータのブロックをまとめる際に、DDFはFETCHステートメントを発行します。V8 Db2システムに対してブロックフェッチを使用している場合、DDFアドレススペースは複数行フェッチを使用してクライアントに送信されるデータのブロックを構築します。これは要求側に対して透過的に行われます。

IBM社によれば、この機能を使用することによって、CPUを大幅に節約することが可能です。多数の行がフェッチされる場合には最高50%まで節約できると言われています。

この新機能では、クライアントアプリケーションでFOR n ROWSやホスト変数配列を使用する必要がなく、DDFによるブロック化には影響しません。DDFとDBM1間のAPI交差数だけに影響します。

CREATE DECLARED GLOBAL TEMPORARY TABLEステートメントのON COMMIT DROP TABLEオプションの使用（V8での新機能）

Db2 DDFバージョン7では、COMMITの前に宣言された一時表を明示的にDROPしないと、リモート接続が非アクティブになりません。Db2 DDFバージョン8では、CREATE DECLARED GLOBAL TEMPORARY TABLEステートメントに対する新しいON COMMIT DROP表オプションが提供されています。宣言された一時表は、コミット時にそれに対する保留カーソルがオープン状態でない場合、暗示的にドロップされます。

例：

DECLARE GLOBAL TEMPORARY TABLE ...

ON COMMIT DELETE ROWS

ON COMMIT PRESERVE ROWS

ON COMMIT DROP TABLE

バージョン8より前では、Db2は宣言されたグローバル一時表をオープン状態の保留カーソルのある基本表として処理していました。リモート接続はコミット時に非アクティブにできず、プールに戻されるスレッドになることができません。

スクロール可能なカーソルは宣言された一時表を使用するため、オープン状態のスクロール可能なカーソルを使用する接続は、COMMIT時に非アクティブになることはできません（スクロール可能なカーソルをCLOSEすると、宣言された一時表がドロップされます）。

宣言された一時表は、割り振り解除構造で「疑似」解放として作成されます。ON COMMIT PRESERVE ROWSを指定して表が作成されていない場合、表に挿入されるデータはすべてコミット時に削除されます。明示的にドロップされないかぎり、表はコミット中ずっとアクティブなままです。スレッドの再使用が「新規ユーザー」のプロセスを介さない場合（たとえば、DDFの非アクティブな接続など）、宣言された一時表は、スレッドが終了して割り振り解除されるまでドロップされません。TEMP表スペースのロックは、表が存在するかぎり保持されます。接続プールを使用するアプリケーションでは、Webアプリケーションサーバーが実行中であるかぎり、すべての一時表が保持されます。一時表のロックは、COMMIT後も保持されます。

Db2 V8では、ON COMMIT DROP TABLEを使用して、アプリケーションがコミット前に宣言された一時表を明示的に削除しなくてもよいように、以下の宣言されたグローバル定義を行えます。

アクティブから非アクティブに切り替えることが可能な分散作業
オープン状態の保留カーソルがない一時表は、COMMIT時に自動的にドロップされます。

これにより、接続がINACTIVEに切り替わることができます。宣言された一時表がON COMMIT DROP TABLEを使用して定義されている場合、表でオープンしているカーソルにWITH HOLDとして定義されているものがなければ、宣言されたグローバル一時表はCOMMIT時に暗示的にドロップされます。

宣言された一時表は、ON COMMIT DROP TABLE節を指定するようにプログラム内で定義されている必要があるため、この機能を利用するためにはアプリケーションを修正する必要があるかもしれません。

KEEPDYNAMIC(YES)を使用したアカウンティングレコードの出力

Db2 DSNZPARM CMTSTATがINACTIVE（Db2 V8の新しいデフォルト）に設定されている場合、トランザクションがコミットし、接続が非アクティブになれる状態になると、Db2はアカウンティングレコードを出力します。

KEEPDYNAMIC(YES)バインドオプションを使用している場合、スレッドにはローカルにキャッシュされたステートメントに関する情報が含まれているため、Db2はスレッドから接続を切断できません（通常、接続がアクティブでなくなると切断されます）。

そのため、KEEPDYNAMIC(YES)の使用中は、DDFスレッドがアクティブである必要があります。その結果、アカウンティングレコードはトランザクション境界で切断されません。同様に、DDFはトランザクション境界でWLMエンクレーブを再確立しません。

Db2 V8ではKEEPDYNAMIC(YES)のためDDFスレッドが非アクティブになることはできませんが、KEEPDYNAMIC(YES)を使用することで、Db2がアカウンティングレコードをトランザクション境界で切断することができます。つまり、コミット時にDDF接続が非アクティブになれるかDb2によって評価される際、非アクティブ化できない唯一の理由がKEEPDYNAMIC(YES)によるキャッシュに入った動的SQLステートメントの存在である場合、DDFは（KEEPDYNAMYIC(YES)が指定されていないときと同様に）アカウンティングレコードを切断し、WLMエンクレーブも完了します。

新しい要求を（まだアクティブな）接続を介したクライアントシステムから受信すると、Db2は新しいエンクレーブを作成し、新しいアカウンティングインターバルを開始します。このような新しい動作によって、頻繁にコミットしてもKEEPDYNAMIC(YES)を使用するために非アクティブ化できないスレッドに対して、期間ベースのWLM目標を検討することができます。他の理由で非アクティブ化できないスレッドはWLMエンクレーブをリセットせず、（従来どおり）期間ベースの目標は適切ではありません。

この新しい動作は、DRDAクライアントのみでサポートされ、Db2 PPクライアントではサポートされません。Db2 V7と同様に、保留カーソルや宣言された一時表があると、スレッドはアクティブのままで、アカウンティングインターバルやWLMインクレーブは完了しません。

更新ロックを使用した読み取り専用（Db2 V8の新機能）

WebSphereの配置方法によって、（エンティティーBeanに代わってデータベースと対話する）パーシスタンス層は、WebSphereのエンティティーBeanをロードする際に、現在ISOLATION(RS)を使用してFOR UPDATE KEEP UPDATE LOCKS節のある1つまたは複数の行を検索しています。それによりJavaアプリケーションはそれらのBeanへの更新を行うことができ、更新は検索されたUPDATEステートメントとしてDb2に送信されます。行が読み込まれるとカーソルがクローズされるため、WebSphereは位置を指定した更新ができません。WebSphereは実行時にオープンしているカーソルの数を最小限に抑えるためにこの方法を使用します。

Db2バージョン7では、KEEP UPDATE（またはEXCLUSIVE） LOCKSはFOR UPDATEと組み合わせた場合のみ指定できます。カーソルがUPDATEまたはDELETE WHERE CURRENT OF（位置を指定した削除）に現れる可能性があるため、FOR UPDATE節によってDRDAは各操作（OPEN、FETCH、... CLOSE）に対して別のネットワークフローを使用します。

Db2 V8にアプリケーションを移行することで、パフォーマンスを著しく向上させることができます。Db2 V8はFOR READ ONLY照会で排他的なロックを獲得することができます。これにより、JDBCドライバーとDDFはSELECTに対してブロックフェッチを使用することができ、FOR UPDATE照会で必要な余分なネットワークメッセージが排除されるうえ、検索されたUPDATEステートメントに対してWebSphereが必要とするロックを獲得して保持することができます。

スクロール可能な動的カーソルの使用（Db2 V8の新機能）

Db2 V8ではスクロール可能な動的カーソルが導入されました。スクロール可能な動的カーソルは、結果表を具体化しません。代わりに、基本表を直接スクロールするため、コミットされたすべての挿入、更新、削除に対してセンシティブです。スクロール可能な動的カーソルは、索引走査と表スペース走査のアクセスパスでサポートされます。スクロール可能な動的カーソルは、行レベルの操作または行セットレベルの操作に使用できます。