5Oracle Database Provider for DRDAの管理およびカスタマイズ

この章では、様々な管理およびカスタマイズの問題について説明します。

この章には次のトピックが含まれます:

Oracle Database Provider for DRDAを使用した移行手順
Oracle Database Provider for DRDAソフトウェアのインストールおよび構成
Oracle DatabaseへのOracle Database Provider for DRDAオブジェクトのインストール
DRDAパッケージの権限の管理
DB2データの移行
アプリケーションのターゲット再設定
SQL文の翻訳およびデータ型の調整

Oracle Database Provider for DRDAを使用した移行手順

Oracle Databaseへの既存のDB2アプリケーションの移行はデータおよびターゲットに依存する作業ですが、一般には次の6つの手順で構成されます。

Oracle Database Provider for DRDAソフトウェアのインストールおよび構成
Oracle DatabaseへのOracle Database Provider for DRDAオブジェクトのインストール
DRDAパッケージの権限の管理
DB2データの移行
アプリケーションのターゲット再設定
SQL翻訳およびデータ型の調整

Oracle Database Provider for DRDAソフトウェアのインストールおよび構成

Oracle Database Provider for DRDAソフトウェアをインストールする前に、運用およびリソースに関する複数の事項を組織内で検討する必要があります。スタンドアロンのOracleホーム、既存のデータベース内でのOracleホーム、Oracle Databaseとは完全に切り離されたマシン上のスタンドアロンのOracleホームのいずれが最適なインストール環境であるかを判断する際に最も重要な要素は、マシンとネットワークのリソースの柔軟性とパフォーマンスです。また、このインストール環境を使用する必要があるすべてのDB2クライアントの特性も、決定要因の1つです。この場合、DB2はクライアントとみなされます。

第3章「Oracle Database Provider for DRDAのインストールおよび構成」を参照してください。

Oracle DatabaseへのOracle Database Provider for DRDAオブジェクトのインストール

Oracle DatabaseにOracle Database Provider DRDAオブジェクトをインストールする前に、1人以上のユーザーをDRDA管理者とし、管理者ロールを付与する必要があります。管理者ロールを参照してください。

同様に、Oracle Database Provider for DRDAまたはDB2アプリケーションからOracle Databaseにアクセスするユーザーを指定し、DRDAユーザーの役割と権限を付与します。ユーザー・ロールを参照してください。DRDAユーザーの権限と構成の設定の一部は、移行プロセスの後半まで遅らせる必要があります。そのほとんどは、アプリケーションで使用される特定のDRDAパッケージ、および特定のSQL翻訳またはデータ型の調整に関連しています。移行前にアプリケーションのパッケージが特定されている場合は、パッケージ認可ワークフローにおいてそれらを適用できます。

DRDAパッケージ権限の管理

DRDAまたはDB2アプリケーションからOracle Database Provider for DRDAを介してOracle Databaseへアクセスできるようにするには、パッケージ認可が適用されている必要があります。SQL Translator Interface Packageの使用を参照してください。最小限でもアプリケーションとそのユーザーに関する次の情報を収集する必要があります。

パッケージ・コレクションID (NULLIDなど)
パッケージ名(DSNPBD3など)
パッケージのバージョン名(存在する場合) (01またはNULLなど)
データベースにアクセスする必要があるOracleユーザーの名前 (DRDAUSRなど)

パッケージが表すアプリケーションのSQL翻訳プロファイル名も指定する必要があります。パッケージを参照してください。

DB2データの移行

DB2ではオブジェクトを任意のスキーマに作成できますが、Oracle Databaseではスキーマ名は任意ではありません。したがってDB2からOracleにデータを移行する際にはスキーマを慎重に使用することを考慮する必要があります。Oracleでは、表、ビュー、シノニムなどのすべてのスキーマ・オブジェクトを実際のユーザーのスキーマに割り当てる必要があります。当然これは、これらのオブジェクトの名前の指定、作成およびアクセス方法に影響します。

たとえば、USER1が表"USER1"."TABLE1"および"USER2"."TABLE2"を作成するとします。DB2ではTABLE1およびTABLE2はUSER1によって作成されるため、USER1がこれらの表を所有します。Oracleでは表"USER2"."TABLE2"の所有者はユーザーUSER2です。また、USER1にCREATE ANY TABLE権限が付与されていない場合には、USER1はTABLE2を作成できません。かわりに、USER2がTABLE2を作成し、この表へのアクセス権限をUSER1に付与する必要があります。

また、DB2からOracleに移行されるデータは、Oracleデータ型に基づいて定義されている必要があります。OracleではANSI定義のデータ型名が使用されていますが、その範囲制限またはセマンティクスはDB2実装と必ずしも同一ではありません。既存のDB2アプリケーションのデータ型を正確にモデル化するには、第8章「Oracle Database Provider for DRDAのデータ・ディクショナリを参照してください。

適切なデータ型を使用してスキーマとオブジェクトを作成した後で、データをOracleにインポートできます。

アプリケーションのターゲット再設定

次の例は、DB2 z/OSアプリケーションを移行する方法を示しています。DB2/LUWまたはDB2/400アプリケーションを移行する際には同様の手順を実行する必要があります。各製品での同等の手順の詳細は、IBMのドキュメントを参照してください。

アプリケーションは、ネイティブ・アプリケーションおよびリモート・アプリケーションという2種類の一般的なカテゴリに分類されます。

ネイティブ・アプリケーションのターゲット再設定

標準的なDB2アプリケーションはネイティブと呼ばれます。これは、このようなアプリケーションは内部IPCメカニズムを介してローカルDB2システムと直接連携するためです。これらのアプリケーションは、埋込みSQLプログラミングとDB2 SQLプリプロセッサを使用します。ソースの事前処理の結果生成される実行計画は、Database Resource Module (DBRM)に格納されます。プログラムの実行前に、ユーザーが実行計画をアップロードし、ローカルDB2インスタンスにバインドする必要があります。

実行計画には、アプリケーション・ソースに埋め込まれているすべての静的SQLおよびlocation (Current Serverとも呼ばれる)などの追加属性が含まれています。デフォルトでは、Current Serverは空白であり、サーバーがローカルDB2インスタンス上にあることを示します。ただし、すべての操作を別のサーバーで実行するように実行計画のターゲットを再設定できます。このためにはCurrent Server属性に新しい値を設定します。

次の手順は、IBM DB管理者が実行する必要があります。

実行計画を使用してネイティブ・アプリケーションのターゲットを再設定します。

DB2 Communications Databaseにロケーション・エントリを作成します。

DB2には、リモートDB2インスタンスに接続するための内部通信システムがあります。リモート・インスタンスのアドレスを指定するため、SYSIBM.IPNAMES表とSYSIBM.LOCATIONS表にレコードを挿入します。この場合、オプションでSYSIBM.USERNAMES表にもレコードを挿入できます。

DB2 Communications Database機能の詳細は、IBM DB2のドキュメントを参照してください。

次のコマンドは、リンク名REMHOST、ロケーション・エントリDRDAASおよびオプションでユーザー名マッピング・エントリを、DB2 Communications Databaseに挿入します。リンク名は、Oracle Database Provider for DRDAが稼働しているコンピュータのホスト名またはIPアドレスを表します。ロケーションはそのリンク名を使用するRDB名を表し、ポート番号はOracle Database Provider for DRDAがリッスンするポートを表します。これらは、Oracle Database Provider for DRDA構成パラメータDATA_PORTおよびRDB_MAPに対応しています。ロケーション名は、RDB_MAPパラメータに指定されたRDB()値と完全に一致する必要があることに注意してください。
```
INSERT INTO SYSIBM.IPNAMES (LINKNAME,SECURITY_OUT,USERNAMES,IPADDR)
  VALUES ('REMHOST','P','O','remotehost.remotedomain.com');

INSERT INTO SYSIBM.LOCATIONS (LOCATION,LINKNAME,PORT)
  VALUES ('DRDAAS','REHMOST','1446');

INSERT INTO SYSIBM.USERNAMES (TYPE,AUTHID,LINKNAME,NEWAUTHID,PASSWORD)
  VALUES ('O',' ','REMHOST','DRDAUSER', 'userpwd' );
```
Oracle Database Provider for DRDAにアプリケーションの計画をリモートでバインドします。

ロケーション・エントリの挿入後に、アプリケーションの実行計画をリモートでバインドする必要があります。次のコードは、DSNコマンド・プロセッサIKJEFT01を介して計画DSNPBD3をバインドします。ロケーションDRDAASがコレクションIDに接頭辞として付加される点に注意してください。
```
BIND PACKAGE(DRDAAS.NULLID) MEMBER(DSNPBD3) -
            ACT(REP) ISO(CS) CURRENTDATA(YES) ENCODING(EBCDIC)
```
パッケージを現行サーバーにローカルでバインドします。

実行のターゲットを再設定するため、計画をリモートでバインドした後で、現行サーバー・オプションを使用してロケーション計画を再バインドします。次のコードは、DSNコマンド・プロセッサIKJEFT01を介して計画DSNPBD3をバインドします。

この計画が、リモート計画でパッケージ・リストPKLISTを介して参照される必要があること、また計画ではパッケージ参照DRDAAS.NULLID.DSNPBD3で場所を指定し、このロケーションを含むCURRENTSERVERオプションを指定する必要があることに注意してください。
```
BIND PLAN(DSNPBD3) -
   PKLIST(DRDAAS.NULLID.DSNPBD3) -
   ACT(REP) ISO(CS) CURRENTDATA(YES) ENCODING(EBCDIC) -
   CURRENTSERVER(DRDAAS)
```
計画がリモートでバインドされローカルで再バインドされた後に、計画DSNPBD3を使用してアプリケーションが実行され、ローカルDB2からOracle Database Provider for DRDAへのリモート接続が暗黙的に確立され、計画のすべての操作がリモートで実行されます。この構成では、パススルーの調整はローカルのDB2が引き続き行います。

リモート・アプリケーションのターゲット再設定

通常、リモート・アプリケーションはローカルDB2に直接関連付けられていません。通常、このようなアプリケーションはネットワーク対応またはネットワーク指向と呼ばれ、接続する対象と接続先の場所を指定するために使用されるリモート・サーバー・ロケーション構成属性が含まれています。

このようなアプリケーションは、ネットワーク・プロトコルを介してOracle Database Provider for DRDAを利用します。このタイプのアプリケーションのターゲット再設定は容易に構成できます。

実行計画を使用してリモート・アプリケーションのターゲットを再設定するには、次のようにします。

Oracle Database Provider for DRDAで構成したホスト名(またはIPアドレス)、ポート番号およびRDB名を使用するように、アプリケーションの構成オプションを変更します。この例として、ODBCを使用する場合(DSNエントリにネットワーク・パラメータが含まれている場合)があります。

この例では、NetworkおよびPortNumberパラメータは、前述のDB2 Communication Databaseの例で挿入されたLinknameおよびLocationのエントリに対応しています。DatabaseパラメータはLocation名に対応しています。これらはすべて、構成済Oracle Database Provider for DRDAのDATA_PORTパラメータおよびRDB_MAPパラメータに対応しています。

次にodbc.iniファイルの例を示します。
```
[DRDAAS]
       Network=remotehost.remotedomain.com
       PortNumber=1446
       Database=DRDAAS
```
アプリケーションのパッケージ・リソース・バインディング操作を実行します。

多くの場合、この手順はアプリケーション自体によって暗黙的に処理されるか、リモートDB2インスタンスへのアプリケーションによるアクセスとリソースを設定するための1回かぎりの手順として記載されています。バインディングの手順については、個々のアプリケーションのドキュメントを参照してください。

SQL文の翻訳およびデータ型の調整

アプリケーションによっては、SQL翻訳の自動翻訳メカニズムでは処理できないDB2固有のSQLが含まれている場合や、問合せで特定の列に非常に特殊なデータ型が必要となる場合があります。このような場合には、代替のSQL文を手動で挿入するか、アイテム固有のデータ型操作を追加する必要があります。

たとえば、アプリケーションの特定のSQL文の構文が、DB2固有の構文(SELECT LOG2(COL1) FROM TABLE1)であるとします。Oracleで正しく動作するためには、このSQLをSELECT LOG10(COL1,2) FROM TABLE1文に翻訳する必要があります。

SQL翻訳の登録機能を使用して、例5-1に示すように、このSQL文に対して直接翻訳を登録できます。これは、SQL文を実行するユーザーが実行する必要があること、そのユーザーのリソースとしてSQL翻訳プロファイルを作成する必要があることに注意してください。

例 5-1 代替のSQL文の登録

アプリケーションのパッケージにはプロファイル名DB2ZOSが割り当てられています。

connect DRDAUSER/userpwd
execute dbms_sql_translator.register_sql_translation('DB2ZOS',
   'SELECT LOG2(COL1) FROM TABLE1',
   'SELECT LOG10(COL1,2) FROM TABLE1')

SQLトランスレータの登録後に、アプリケーションにより元のSQLが発行されると、新しいSQLおよびプロセスに暗黙に翻訳されます。

ごくまれに、アプリケーション・クライアントで、問合せのSELECTの項目のデータ型が非常に特殊な形式で戻されなければならないことがあります。

たとえば、翻訳後の問合せSELECT LOG10(COL1,2) FROM TABLE1の結果としてDECFLOAT34データ型が戻されるが、アプリケーションがこのデータ型を処理できず、このデータ型を別の互換性のある型に暗黙かつ強制的に変換する可能性があります。

アプリケーションでDOUBLE PRECISIONデータ型がサポートされている場合、TYPEMAP機能を使用して、この強制的な変換を追加できます。詳細は、例5-2を参照してください。

例5-2 オンデマンド・データ型変換の登録

connect DRDAADM/adminpwd

execute DBMS_DRDAAS_ADMIN.SET_TYPEMAP('NULLID', 'DSNPBD3', NULL,
   'TABLE1:LOG10(COL1,2)', 'NUMBER=DOUBLE')

execute DBMS_DRDAAS_ADMIN.SET_TYPEMAP('NULLID', 'DSNPBD3', NULL,
   'TABLE1:LOG10(COL1,2)', 'NUMBER(0,-127)=DOUBLE')

詳細は、同等のデータ型および再マッピングを参照してください。