シナリオ: pureQuery クライアント最適化のテスト環境から実稼働環境へのマイグレーション

テスト環境で、アプリケーションを pureQuery クライアント最適化に対応させます。アプリケーションの機能およびパフォーマンスをテストしたり、SQL ステートメントおよびバインド・プロシージャーをレビューするなどしてテスト要件を満たしたら、アプリケーションを実稼働環境にデプロイする準備が整います。
このトピックでは、パッケージを移動または作成して実稼働環境のデータベースにバインドする方法を説明します。次のセクションが含まれています。

理想的な環境で、pureQuery クライアント最適化に対応したアプリケーションを実行し、SQL データをキャプチャーして、実稼働環境と同じ環境で SQL の静的な実行をテストします。ただし、同一のテスト環境と実稼働環境を用意できない場合があります。例えば、テスト・システムで、DB2® for Linux, UNIX, and Windows を使用するが、実稼働環境では、DB2 for z/OS® を使用する場合があります。

pureQuery クライアント最適化に対応したアプリケーションをマイグレーションするときに、pureQueryXML ファイル内のパッケージおよびコレクション名など、DB2 パッケージの特性を変更する必要がある場合があります。実動固有のオプションを指定して pureQueryXML ファイルに対して Configure ユーティリティーを実行した後に、StaticBinder ユーティリティーを使用すると、パッケージを実動データベースに作成し、パッケージをデータベースにバインドできます。

pureQuery ランタイム・プロパティーおよび pureQueryXML データも実稼働環境で使用するためにマイグレーションします。finalRepositoryProperties プロパティー、captureMode プロパティー、および allowDynamicSQL プロパティーを変更する必要がある場合があります。

リポジトリーを使用している場合は、実稼働環境にもリポジトリーを作成し、アプリケーションの実行時グループ・バージョンを作成して、pureQuery ランタイム・プロパティー情報および pureQueryXML ファイルをリポジトリーにアップロードします。

pureQuery Configure および StaticBinder ユーティリティーを使用した SQL ステートメントのマイグレーションの例

このシナリオの前のタスクで、pureQuery クライアント最適化を使用するアプリケーションをテスト・システム上で構成しました。テストが完了したので、これから pureQueryXML ファイル内の SQL ステートメントを実動データベースにバインドしようとしています。次の例では、実動コレクションが PRODCOL および QUALIFIER PROD であると仮定しています。したがって、パッケージが認識されるようにデータ・ソースを正しい packagePath 設定で更新します。また、このトピックの例では、実動データベースがパッケージ名 PRODPKG のパッケージ命名規則を使用すると仮定しています。

マイグレーションの一環として、テスト環境で作成した pureQueryXML ファイルを取得します。ファイルがリポジトリーにある場合は、pureQuery ManageRepository ユーティリティーを使用してファイルを取り出します。次のようなコマンドを実行します。
java com.ibm.pdq.tools.ManageRepository 
  -extract runtimeGroup 
  -repositoryDriverClass com.ibm.db2.jcc.DB2Driver 
  -repositoryURL "jdbc:db2://testserver.test.com:32706/sample" 
  -repositoryUsername "myuser" -repositoryPassword "mypwd" 
  -runtimeGroupId testApp -runtimeGroupVersion V2 
  -outputDirectory C:¥TEMP¥out 
  –pureQueryXml prodApp.pdqxml 

ファイルを取得したら、適切なオプションを指定して、pureQuery Configure および StaticBinder ユーティリティーを pureQueryXML ファイルに対して実行します。

下記の Configure ユーティリティーを実行すると、ルートのパッケージ名が PRODAPPL に変更され、デフォルトのコレクションが PRODCOL に変更されます。オプション -cleanConfigure true は、pureQueryXML ファイル内のすべての SQL ステートメントを処理することを指定します。これには、新規 SQL ステートメントに加え、既存のすべての SQL ステートメントが含まれます。オプション -replaceSchemas は、pureQueryXML ファイルで指定されているスキーマ名を TEST から PROD に変更します。 オプション -validateXml true を指定すると、Configure ユーティリティーは、XML スキーマ検証を入力ファイルに対して実行して、それが有効な pureQueryXML ファイルであることを確認します。
java com.ibm.pdq.tools.Configure -pureQueryXml prodApp.pdqxml 
  –validateXml true
  –collection PRODCOL 
  -rootPkgName PRODAPPL 
  -replaceSchemas "(TEST>PROD)"
  -cleanConfigure true
下記のオプションを指定して StaticBinder ユーティリティーをターゲット・データベース・サーバーに対して実行すると、pureQueryXML ファイルからの SQL ステートメントを含むパッケージがデータベースに作成され、パッケージがバインドされます。
java com.ibm.pdq.tools.StaticBinder 
  –url jdbc:db2://prodserver.prod.com:446/STLEC1” 
  -username "myuser" -password "mypwd" 
  -isolationLevel CS 
  -bindOptions "QUALIFIER PROD" 
  -pureQueryXml prodApp.pdqxml 
  -showDetails true

オプション -showDetails true を指定すると、StaticBinder ユーティリティーによって、それが生成する DB2 パッケージについてのサマリー情報が表示されます。

StaticBinder オプション -isolationLevel CS は、StaticBinder が分離レベルとしてカーソル固定 (CS) を使用して単一パッケージを作成することを指定します。CS 分離レベルは、DB2 for Linux, UNIX, and Windows データベースのデフォルト・レベルです。

以下のサンプルに類似したものが、StaticBinder コマンドに対する出力となります。
The StaticBinder utility is beginning to bind the pureQueryXml file capture.xml.

Starting to process options : -username "*****" -password "*****" 
 -url "jdbc:db2://prodserver.prod.com"
 -pureQueryXml prodApp.pdqxml 
 -isolationLevel "CS" 
 -bindOptions "QUALIFIER PROD" 
 

The StaticBinder utility successfully bound the package 'PRODAPPL2' for the isolation level 'CS'.

実稼働環境にマイグレーションする際の静的 SQL 識別情報の変更

アプリケーションを実稼働環境にマイグレーションするときに、整合性トークンおよびパッケージ・バージョンなどの静的 SQL 識別情報を変更する必要がある場合があります。

整合性トークンおよびパッケージ・バージョンの変更
DB2 パッケージを異なる DB2 サブシステムまたはデータベースにマイグレーションするときに同じ整合性トークンおよびパッケージ・バージョン情報を維持するには、pureQueryXML ファイルに対して StaticBinder ユーティリティーを実行して、追加の DB2 データベースまたはサブシステムにファイルをバインドします。pureQueryXML ファイルを変更しない場合は、マイグレーション中、pureQueryXML ファイル内の整合性トークンと DB2 パッケージ・バージョン内の整合性トークンが一致したままになることを保証できます。ファイルを変更し、Configure ユーティリティーを使用する場合は、整合性トークンが変更される場合があります。整合性トークンおよび DB2 パッケージ・バージョンについては、DB2 パッケージ識別情報を参照してください。
注: pureQuery Configure ユーティリティーを使用すると、ステートメント・セットへの変更が必要な場合に整合性トークンが変更されます。pureQueryXML ファイルを構成する必要があるが、整合性トークンを変更したくない場合は、Configure ユーティリティーが pureQueryXML ファイル内の既存の指定したステートメント・セットを変更しないようにする必要があります。例えば、-setPreStatusOfAllPkgs REQUIRED オプションまたは -cleanConfigure true オプションを指定してファイルを構成してはいけません。
JDBC プロパティーの変更
コレクション ID がテスト・システムと実動システムで異なる場合は、DB2 サブシステム間のパッケージのマイグレーション中に正しいコレクションを指定するように対応するランタイム環境を更新する必要があります。コレクションは、WebSphere® データ・ソース定義の一環として、currentPackageSet プロパティー (または DB2 for Linux,UNIX, and Windows または DB2 for z/OS の currentPackagePath プロパティー) を使用して指定されます。

実行時に、WebSphere JDBC プロバイダーのカスタム・プロパティー currentPackageSet が WebSphere Application Server データ・ソースで PRODCOL1B に設定されていない場合は、pureQueryXML ファイル内のコレクション PRODCOL が使用されます。パッケージは STLEC1B では見つからず、SQLCODE 805 がアプリケーションに返されます。

動的 SQL ステートメントを使用する場合、データ・ソース・プロパティー currentPackagePath を指定する必要があります。 JDBC 動的パッケージがコレクション NULLID にバインドされる 場合は、WebSphere Application Server データ・ソース上の currentPackagePath プロパティーの 値を PRODCOL1B,NULLID に設定する必要があります。

DB2 for z/OS データベースへのマイグレーション
StaticBinder ユーティリティーに加え、DB2 for z/OS は、DSN リモート BIND COPY コマンドを提供します。これを使用すると、異なる DB2 for z/OS システム上のパッケージを再バインドできます。BIND PACKAGE の引数としてリモート・ロケーション名を指定して、BIND PACKAGE コマンドを発行し、COPY オプションを指定します。

pureQueryXML ファイル内の SQL ステートメントが、コレクション PRODCOL を含むテスト用のロケーション、例えば、STLEC にバインドされている場合。BIND COPY コマンドを使用すると、コレクション PRODCOL1B を含む実動ロケーション STLEC1B にパッケージをコピーできます。


フィードバック