pureQuery クライアントの最適化を使用して Java アプリケーションを有効にすると、アプリケーション・セキュリティー、アプリケーションの保守容易性およびパフォーマンスを向上させることができます。
pureQuery クライアントの最適化を有効にする主な利点は、アプリケーションを SQL の動的な実行から SQL の静的な実行に変換できる点です。
pureQuery クライアントの最適化のその他の利点には、以下のものがあります。
- アプリケーションのソース・コードをトレースバックするための機能を使用して SQL ステートメントに関する問題を診断する
- パフォーマンスの低い SQL ステートメントを最適化されたステートメントに置き換える
- 制限された SQL ステートメント一式を実行することによって、SQL インジェクション・アタックのリスクを低減させる。
pureQuery クライアントの最適化を使用すれば、データベース管理者は、組織内での既に存在しているスキルを使用してアプリケーションを管理することができます。
以下の各セクションでは、pureQuery クライアントの最適化と下の各領域での SQL の静的な実行の利点について説明しています。
機能と利点の要約
次のリストでは、pureQuery クライアントの最適化で使用できる能力が要約されています。
- 開発フレームワークの独立性
- ツールの統合 (各種 Optim™ 製品の使用による)
- SQL ステートメントによる検索
- パフォーマンスの低い SQL の特定 (他の Optim 製品と処理している場合)
- SQL のパフォーマンス・データの収集 (他の Optim 製品と処理している場合)
- SQL ステートメントのデータ型情報の収集
- SQL ステートメントを動的または統計的に実行する選択
- 前にキャプチャーされた SQL のみの実行
- SQL リテラルを SQL パラメーター・マーカーで置き換え可能
- SQL ステートメントの置換
次のリストでは、SQL ステートメントを静的に実行した場合の利点をまとめています。
- 安定した SQL のパフォーマンス
- 予測可能な SQL のアクセス・プラン
- SQL の実行時のデータベース・セキュリティーの向上
- ネットワーク・トラフィックの低減
- 実行時の PREPARE ステートメントと DESCRIBE ステートメントの除去
- SQL ステートメントによる検索
- SQL 実行のトラッキング
- DB2® Explain のサポート
- パフォーマンスの低い SQL を特定可能
- 実行時固有のエラー情報
開発プロセスの利点
アプリケーションを柔軟な環境で開発、テスト、およびデプロイすることができます。
以下のような利点があります。
- 開発時のフレームワークの選択
- アプリケーション開発者によってデータ・アクセスに使用される Java アプリケーション開発で、数種類のテクノロジーが使用できます。
pureQuery クライアントの最適化はフレームワークとともに機能し、アプリケーション開発における特定のフレームワークの選択に対して、何ら制約を課しません。
例えば、開発時に Spring、iBatis、Java Persistence
Architecture (JPA) などのフレームワークを使用することができます。pureQuery クライアントの最適化は、JDBC ドライバーとともに機能し、その上にあるアプリケーション・ロジックの層からの影響を受けません。
開発者は、動的 SQL を使用するアプリケーションを引き続き開発することができ、静的 SQL のセマンティクスやデプロイメントの考慮事項を心配する必要はありません。
pureQuery クライアントの最適化は、開発ステップというよりも構成ステップです。
pureQuery クライアントの最適化は、統合アプリケーション・テスト中に有効にする必要があります。
SQL ステートメントをテスト中にキャプチャーすると、SQL を静的に実行する最大の利点がもたらされるように、SQL ステートメントの大部分がキャプチャーされて、静的に実行するように変換することが確実に行えます。
pureQueryXML ファイルには SQL ステートメントが含まれており、pureQuery クライアント最適化対応のアプリケーションで使用することができます。
pureQueryXML ファイルは、以下のリソースのいずれかで作成することができます。
- JPA アプリケーションの XML ファイル: IBM® JPA 実装を使用する場合、wsdb2gen ユーティリティーを使用して、パーシスタンス・ユニットで使用された SQL ステートメントが含まれた XML ファイルを生成することができます。
wsdb2gen ユーティリティーによって生成されたファイルは、pureQuery クライアントの最適化と互換性があります。
必要に応じて、このファイルを使用して、pureQuery クライアント最適化対応のアプリケーションのために追加の SQL ステートメントをキャプチャーすることができます。
このファイルには、wsdb2gen ユーティリティーによって作成された SQL ステートメントと pureQuery Runtime によってキャプチャーされた追加の SQL ステートメントのすべてが含まれます。
このファイルを pureQuery の Configure ユーティリティーと StaticBinder ユーティリティーで使用して、SQL ステートメントが含まれた DB2 パッケージを作成し、このパッケージをデータベースにバインドします。
- SQL テキスト・ファイル: アプリケーションによっては、アプリケーション内で使用される SQL ステートメントをテキスト・ファイルに分離し、アプリケーション・ロジックを使用してこのファイルを処理するものもあります。
このテキスト・ファイルには、セミコロン (;) などの区切り記号で区切られた SQL ステートメントが含まれます。
pureQuery の GeneratePureQueryXml ユーティリティーを使用して、このテキスト・ファイルから pureQueryXML ファイルを生成することができます。
pureQueryXML ファイルを GeneratePureQueryXml ユーティリティーを使用して作成した後、このファイルを pureQuery Runtime で使用して、追加の SQL ステートメントをキャプチャーすることができます。
また、このファイルを pureQuery の Configure ユーティリティーと StaticBinder ユーティリティーで使用して、SQL ステートメントが含まれた DB2 パッケージを作成し、このパッケージをデータベースにバインドすることもできます。
- 動的 SQL または静的 SQL の実行の選択
- アプリケーションが pureQuery クライアント最適化対応になっている場合、アプリケーションによって実行される SQL ステートメントのうち、静的に実行するものと、動的に実行するものとを指定できます。
例えば、最も重要な SQL ステートメントは静的に実行し、他のものは動的に実行することを許可するように選択できます。
開発者は、静的 SQL の実行に影響を与えるデータベース成果物の詳細、または SQL を静的に実行するようにアプリケーションを変換するために必要なデプロイメント・ステップについて認識したり、理解したりする必要はありません。
開発者は、SQL を動的に実行するアプリケーションを自分が使い慣れたフレームワークに基づいて開発することができます。
開発者は、アプリケーションの機能特性とアプリケーションのビジネス・ロジックに集中することができます。
データベース管理者は、アプリケーションによって使用される SQL ステートメントのデプロイと最適化に集中することができます。
SQL の静的実行時に、pureQuery クライアントの最適化では、DB2 データベース・サーバー内で静的 SQL のパッケージ・バージョン管理機能を使用することができます。
静的 SQL の実行により、新規アプリケーション・コードと DB2 アクセス・プランの変更の並行実行を使用した段階的ロールアウトが可能になります。
パッケージ・バージョン管理により、既存の DB2 パッケージを保存したり、新規パッケージを作成したりすることができます。
パッケージ・バージョンを使用して、変更がマイナス効果の場合の明確で簡単なフォールバック手順を作成することができます。
JDBC ベースの動的 SQL アプリケーション内には、DB2 のアクセス・プランの変更用のフォールバック手順は存在しません。
SQL を静的に実行する場合、パッケージ・バージョン管理を使用して、前に生成されたアクセス・プランで SQL を実行することができます。
注: SQL を静的に実行するように pureQuery クライアント最適化が有効に設定されたアプリケーションの場合、実稼働環境にアプリケーションを移行する前に、テスト・フェーズで完成されたアプリケーションに対して構成およびバインドのステップを行うことをお勧めします。
これらのステップをテスト・フェーズで実行すると、SQL ステートメントのデプロイと静的実行のプロセスについての広範囲にわたるテストと検証を行うことができます。
pureQuery クライアントの最適化を有効に設定する手順については、
pureQuery クライアント最適化対応のステップを参照してください。
- ツールの統合
- pureQuery クライアントの最適化は、Optim Development Studio と統合されます。pureQuery は Java プロジェクトに対して有効にすることができます。
Optim Development Studio には、アプリケーションとその関連付けられたパッケージに関する洞察をさらに得るために役立つ多数のビューが用意されています。
チューニングと問題判別の利点
pureQuery Runtime では、正常に実行された SQL ステートメント、および SQL パラメーター情報や結果セット情報などの関連情報がキャプチャーされます。
pureQuery Runtime によってキャプチャーされた SQL ステートメントを調整することができます。また、pureQuery Runtime によってキャプチャーされた情報を使用して、問題の原因を判断することもできます。
以下のような利点があります。
- キャプチャーされた SQL ステートメントの型パラメーターと結果セットのメタデータ
- SQL ステートメントが動的に実行される場合、そのステートメントは JDBC ドライバーによって準備されて記述されます。
これらのアクションにより、SQL ステートメントの構文とセマンティックの妥当性検査が保証されます。
さらに、パラメーターと結果列は、型、長さ、CCSID、およびその他の属性についてターゲット・データベースの列と照合して検査されます。
静的 SQL の実行では、型検査は、動的 SQL の実行のように実行時ではなく、プログラム準備時に一度のみ実行されます。
キャプチャー・プロセス中に、pureQuery Runtime では JDBC ドライバーへの呼び出しをインターセプトし、情報をキャプチャーします。
SQL ステートメントは、それが正常に実行された場合にのみキャプチャーされます。
pureQuery によってキャプチャーされた SQL ステートメントからパッケージを作成し、このパッケージをデータベースにバインドする処理は、スムーズに進むことができます。これは、SQL ステートメントが正常にデータベースに対して実行されたためです。
また、型情報を使用して、バインド・プロセスはアクセス・パスに適切な索引を選択できます。
- 静的に実行された SQL ステートメントを使用したパッケージ・レベルのアカウンティングとスナップショットの情報
- パッケージ・レベルのアカウンティング情報は、DB2 for Linux, UNIX,
and Windows および DB2 for z/OS® の両方で使用できます。DB2 for Linux, UNIX, and Windows では、情報はパッケージのスナップショット内にあり、
DB2 for z/OS では、情報はアカウンティング・レポート内にあります。
パッケージ・レベルのパフォーマンス情報により、データベース管理者は、アプリケーション・レベルのトレースを必要とせずに、アプリケーションの問題の多い特定のセクションを特定できます。
また、パッケージ・レベルのパフォーマンス情報は、最も頻繁に実行されるコード・セクション、および詳細なチューニング分析のために、焦点を当てるべきコードのセクションを特定するために役立ちます。
動的環境では、アプリケーション内への埋め込みのユーザー固有のトレースの定義なしで、このコード・セクションを特定することは難しい場合があります。
pureQuery Runtime では、アプリケーションからスタック・トレースもキャプチャーします。
データベース管理者は、問題の原因を診断するために、スタック・トレースを使用して開発者と作業することができます。
- SQL ステートメントによる検索
- データベース管理者は、さらにチューニングするために、個々の SQL ステートメントを検索するための手法を複数使用することができます。
SQL を動的に実行するアプリケーション内の SQL ステートメントをキャプチャーするには、SQL トレースを有効にするか、キャッシュ内に含まれている情報を取得するか、または SQL ステートメントを DB2 EXPLAIN とともに使用して動的に実行する必要があります。
対照的に、静的 SQL ステートメントは事前定義して、ステートメントに関する情報を容易に取得することができます。
SQL ステートメントは、キャプチャーされて DB2 カタログ表内に保存され、それらのアクセス・プランは、事前に DB2 Explain 表内にキャプチャーすることができます。
カタログ表と Explain 表の照会により、問題の SQL ステートメントとそれに関連付けられているアクセス・プランを取得することができます。
- DB2 EXPLAIN の機能
SQL ステートメントのパフォーマンス特性は、開発時に Optim Development Studio 内で Visual Explain を使用するか、または pureQuery の StaticBinder ユーティリティーの実行時にバインド・オプションの EXPLAIN YES を使用することによって収集することができます。
バインド・オプションの EXPLAIN YES を使用することによって、データベース管理者は、DB2 オプティマイザーによって行われたアクセス・パスの決定を確認することができます。
管理者は、アクセス・パスの選択を向上させるために収集するデータ統計を決定することができます。
また、その他のツールは、SQL ステートメントを Explain 表内で分析して、それらの内容に基づいてチューニングの推奨事項を判断するために役立ちます。
アクセス・プランの分析とチューニングはプログラムの準備時に行うことができます。また、静的に実行される SQL ステートメント用に作成されたパッケージを使用して、事前定義されたアクセス・プランを組み込むことができます。
SQL を動的に実行する場合は、アクセス・プランを事前定義することはできません。
- DB2 のエラー・メッセージ
- DB2 データベースの使用時に、SQL が静的に実行されると、ロックのタイムアウト、デッドロック、リソース利用不可エラーなどのエラー・メッセージにパッケージ名が含まれることがよくあります。
データベース管理者は、このパッケージ情報を使用してエラーをアプリケーション・モジュールに関連付けることで、エラーを引き起こしている、またはエラーによって影響を受けている SQL ステートメントを特定することができます。
DB2 for z/OS のエラー・メッセージには、実行中のパッケージに関する情報が含まれています。
これらのエラー・メッセージには、場所、パッケージ名、および整合性トークンに関する情報が含まれています。
これらの情報は、アプリケーションのソースを素早く特定するために使用できます。
SQL ステートメントが動的に実行される場合に生成される類似したエラー・メッセージでは、その SQL を発行したアプリケーションに関する情報が提供されません。
すべての SQL ステートメントは、同じ JDBC パッケージを経由します。
DB2 for Linux, UNIX,
and Windows では、静的 SQL ステートメントで使用される場合、db2deadlock イベント・モニターなどのツールは、デッドロックにかかわる特定のロック・リソースに加えて、デッドロック・イベントのパッケージ名とセクション番号情報も提供します。
この情報は、DB2 db2evmon ツールで表示することができます。
- アプリケーションのスタック・トレース
- アプリケーションの Java コードにアクセスできる場合は、pureQuery Runtime によってキャプチャーされたスタック・トレース情報を使用して、SQL ステートメントを Java ソース・コード内の場所に関連付けることができます。
pureQuery Runtime では、SQL ステートメントとともにスタック・トレース情報を pureQueryXML ファイル内に保管します。
Optim Development Studio では、スタック・トレース情報を使用して、このステートメントを発行した Java コードを見つけることができます。
操作上の利点
pureQuery クライアント最適化が有効に設定されたアプリケーションで SQL ステートメントを静的に実行している場合、プログラム実行の前に SQL ステートメントがデータベースに提供されます。
SQL ステートメントを特定すると、データベース管理者は、チューニング・ツールのフルセットを自由に活用することができ、SQL ステートメントを特定するためにオンライン・トレースを行う必要はなくなります。
以下のような操作上の利点があります。
- セキュリティー・モデル (SQL ステートメントの静的実行時)
- SQL の静的実行モデルでは、実行時に使用される許可 ID に、ベース・データベース・オブジェクトへのアクセス権は必要ありません。
動的 JDBC 実装内のようにベース・データベース・オブジェクトへのアクセス権を与えるのではなく、実行時許可 ID には、特定の事前定義パッケージと組み込まれた SQL ステートメントに対するアクセス権が与えられます。
許可 ID ではプログラミング・ロジックを使用して SQL ステートメントを変更することができないため、パッケージの許可によりセキュリティー実装を向上させることができます。
さらに、ID がセキュリティー・ブリーチのために、代替のアクセス機構からの接続に使用される場合、この ID では SQL を動的に実行することはできません。
また、パッケージの許可により、表集合に対して実行される SQL ステートメントすべてに厳密な監査を行うことができます。
静的モデルでは、基本表にアクセスする権限を持つユーザーが、パッケージをバインドしてパッケージ所有者になります。
この後、パッケージ所有者は、WebSphere® Application Server のデータ・ソース定義内に保管されたユーザー ID などのランタイム環境の許可 ID に対してパッケージを実行する能力を付与することができます。
WebSphere WebSphere のユーザー ID では、データベース・オブジェクトに対して、パッケージ内に定義された SQL ステートメント以外の他のすべての SQL を動的に実行することはできません。
対照的に動的 SQL 環境内では、アプリケーション・サーバーに接続されたユーザーを代表して 1 つのユーザー ID がすべてのデータ・アクセスに使用されます。
このユーザー ID は、アプリケーション・サーバー環境から独立して、データベースに対して SQL を動的に実行することができます。
- SQL リテラルの置換
- pureQuery Runtime には、アプリケーションで実行する非パラメーター化 SQL ステートメントをパラメーター化 SQL ステートメントに変換できる SQL リテラルの置換機能があります。
この機能は、実行時に SQL ステートメントをオンザフライで生成するアプリケーションに役立ちます。
さらに、動的に実行する SQL ステートメントの場合、SQL リテラルの置換により、サーバーの動的キャッシュ内の SQL ステートメントの総数が減少します。これにより、ステートメントに対するキャッシュ・ヒット率が増加します。
- キャプチャーされた SQL のみを実行する機能
- pureQuery クライアントの最適化には、キャプチャーされた SQL ステートメントのみを実行する機能があります。
この機能では、SQL ステートメントが動的に実行している場合でも、アプリケーションで実行できるステートメントをデータベース管理者が承認していて、pureQueryXML ファイル内に存在するものに限定します。
キャプチャーされた SQL のみを実行することにより、すべてのアプリケーションのセキュリティーが向上します。
この機能は、静的 SQL をサポートしない環境で役立ちます。この機能は、SQL インジェクション・アタックの防止に役立ちます。
また、pureQuery クライアントの最適化では、SQL ステートメントの実行を静的に実行できるステートメントに限定することもできます。
- SQL ステートメントの置換
- pureQuery クライアントの最適化を既存の JDBC アプリケーションに対して使用すると、実行される SQL を最適化された同等の SQL に置き換えることが容易になります。
データベース管理者は、アプリケーションを変更せずに、パフォーマンスが低いステートメントを最適化された SQL ステートメントに置き換えることができます。
置換される SQL ステートメントには、索引の選択度をより良くするための追加の WHERE 節のような変更を含めることができます。
置換される SQL ステートメントでは、パラメーターまたは結果列を追加することはできません。これは、メタデータが既にキャプチャーされているためです。
パフォーマンスの利点
静的 SQL の実行では、操作、チューニング、および開発の利点に加えて、パフォーマンスを向上させることもできます。
以下のようなパフォーマンスのチューニングの利点があります。
- 実行時の PREPARE と DESCRIBE の除去
静的 SQL の実行では、ステートメントの準備はランタイム環境でステートメントが実行される前に行われ、この準備は一度のみ行われます。
この結果、準備と記述のアクティビティーは、各トランザクションの SQL ステートメントに対して、それらが動的 SQL の実行で繰り返されるようには繰り返されません。
静的 SQL の実行により、準備が発生するデータベース・サーバーと PreparedStatement オブジェクトが生成されるアプリケーション・サーバーの両方で、CPU 使用量の減少がもたらされます。
JDBC 環境では、SQL のキャッシュ・ヒットを向上させることで、これらの準備済みステートメントのコストの削減を試みることができます。
ただし、キャッシングの実装により 100% のヒット率が保証されるわけではありません。
- ネットワーク・フローの低減
- 各 SQL ステートメントを準備する必要がなければ、各ステートメントについてのネットワーク全体にわたるフローの準備と記述のアクティビティーも必要ありません。
したがって、ネットワーク・トラフィックとトランザクションの経過時間も、一緒に減少します。
- 予測可能なアクセス・パスの選択
- SQL ステートメントのアクセス・プランは、事前に作成されて実行時には作成されません。
アクセス・パスは、RUNSTATS の実行や、データ分散の変化によって変更されることはありません。
テストされたアプリケーションでは、同じ SQL ステートメントを繰り返し実行することができます。また、選択されたアクセス・パスが、データの変更またはデータベースの保守によって変化することはありません。