4 アプリケーションの開発

Oracle Database Gateway for DRDAでは、Oracle Database用に記述されたアプリケーションでDRDAデータベース内の表にアクセスできます。このアクセスは、データベース・リンクによりアクセスされるDRDA表のシノニムまたはビューを使用することで、事実上透過的に行うことができます。ただし、Oracle DatabaseとDRDAデータベース間には、SQL、データ型およびセマンティクスに関する根本的な違いが存在します。

この章では、Oracle Database Gateway for DRDAの11.1リリースに固有の情報を提供します。この章には、次の項が含まれます。

• アプリケーション・プログラムに対するゲートウェイの存在

• ゲートウェイによるOracleストアド・プロシージャの使用

• ゲートウェイによるDRDAサーバーのストアド・プロシージャの使用

• データベース・リンクの動作

• Oracle DatabaseのSQL構文の処理

• ネイティブ・セマンティクス

• DRDAデータ型からOracleデータ型への変換

• ゲートウェイを通じたネイティブSQL文の受渡し

• DRDAサーバーでのOracleデータ・ディクショナリのエミュレーション

• DRDAカーソルの数の定義

4.1 アプリケーション・プログラムに対するゲートウェイの存在

DRDAデータベースの情報にアクセスするために記述されたアプリケーションは、Oracle Databaseとのインタフェースになります。アプリケーションを開発する場合、次のことに注意してください。

• Oracle Databaseで定義されたデータベース・リンクを使用して、アプリケーションに対してDRDAデータベースを定義する必要があります。アプリケーションでは、データベース・リンクに定義された名前を使用して、DRDAデータベースに存在する表を指定する必要があります。たとえば、DRDAデータベース・リンク名をDRDAとするように定義されたデータベース・リンクがあり、アプリケーションでOracle DatabaseとDRDAデータベースからデータを取得する必要があるとします。アプリケーションでは、（2つの表を結合する）次のSQL文を使用します。

  SELECT EMPNO, SALARY
  FROM EMP L, EMPS@DRDA R
  WHERE L.EMPNO = R.EMPNO
  

  この例では、EMPはOracle Databaseの表であり、EMPSはDRDAサーバーの表です。DRDAサーバーの表にシノニムまたはビューを定義して、データベース・リンクの接尾辞なしで情報にアクセスすることもできます。

• 定義済のDRDAデータベースを対象にデータの読取りと書込みが可能です。SELECT、INSERT、UPDATEおよびDELETEは、すべて有効な操作です。

• 単一のトランザクションで、1つのDRDAデータベースと複数のOracle Databaseに書込みを実行できます。

• JOINを使用した単一のSQL文で、複数のOracle Databaseまたは複数のDRDAデータベース（あるいはその両方）の表を参照できます。

4.1.1 フェッチの再ブロック

Oracle Databaseでは、HS_RPC_FETCH_REBLOCKINGパラメータによるフェッチの再ブロックがサポートされます。

このパラメータの値をONに設定すると（デフォルト）、SELECT文の配列サイズがHS_RPC_FETCH_SIZEの値によって決定されます。HS_RPC_FETCH_SIZEパラメータでは、ゲートウェイからOracle Database 11gに対して各バッファにより送信されるバイト数が定義されます。バッファには、DRDAサーバーからの1つ以上の修飾行が含まれることがあります。この機能により、アプリケーション設計、インストール・タイプおよびワークロードに応じてパフォーマンスが大幅に向上する可能性があります。

クライアントとOracle Database 11gの間の配列サイズは、Oracleアプリケーションによって決定されます。詳細は、現在のプラットフォームに応じたOracle Database Gatewayのインストレーションおよび構成ガイドの第14章「Oracle Database Gateway for DRDAの構成」を参照してください。

4.2 ゲートウェイによるOracleストアド・プロシージャの使用

ゲートウェイのストアド・プロシージャ・サポートは、Oracleストアド・プロシージャの拡張機能です。Oracleストアド・プロシージャは、特定のタスクを実行するためにSQLのセットとその他のPL/SQLプログラミング言語の文を論理的にグループ化したスキーマ・オブジェクトです。Oracleストアド・プロシージャは、継続使用を目的としてデータベースに格納されます。アプリケーションでは、標準のOracle PL/SQLを使用してストアド・プロシージャをコールします。

Oracleストアド・プロシージャは、Oracle Databaseのローカル・インスタンスおよびリモート・インスタンスに配置できます。

アプリケーションで場所の透過性を維持するために、次のようにシノニムを作成できます。

CREATE SYNONYM oraproc2 FOR oraproc2@ora2;

このシノニムを作成すると、アプリケーションでは、リモートOracleインスタンスのストアド・プロシージャをコールするためにデータベース・リンク指定を使用する必要がなくなります。

4.3 ゲートウェイによるDRDAサーバーのストアド・プロシージャの使用

ゲートウェイのプロシージャ機能により、DRDAサーバーのネイティブ・ストアド・プロシージャを起動できます。つまり、ストアド・プロシージャは、Oracle Databaseに定義するのではなく、DRDAサーバー（DB2/OS390など）に定義します。ストアド・プロシージャを実行する場合、Oracleアプリケーションにより、前述した標準のOracle PL/SQLが使用されます。

ストアド・プロシージャがDRDAサーバー（DB2/OS390など）で定義されると、ゲートウェイでは、既存のDRDAサーバー定義を使用してプロシージャを実行できます。ゲートウェイでは、DB2ストアド・プロシージャをコールするための特別な定義は必要ありません。

図4-1は、OracleアプリケーションがDRDAサーバー（DB2/OS390など）に定義されたempprocストアド・プロシージャをコールする方法を示しています。

図4-1 DRDAサーバーのストアド・プロシージャの実行

「図4-1 DRDAサーバーのストアド・プロシージャの実行」の説明

アプリケーションの観点からすると、DB2ストアド・プロシージャを実行することは、リモートOracle Databaseインスタンスでストアド・プロシージャを起動することと変わりません。

4.3.1 OracleアプリケーションおよびDRDAサーバーのストアド・プロシージャの完了

OracleアプリケーションでDB2/OS390データベースのストアド・プロシージャを起動する場合を検討します。OracleアプリケーションでDB2ストアド・プロシージャをコールするには、IBM社のDB2 for OS/390 SQL用のリファレンス・ドキュメントに記載されたプロシージャを使用して、最初にDB2システムにDB2ストアド・プロシージャを作成する必要があります。

DB2でストアド・プロシージャが定義されると、ゲートウェイでは標準のPL/SQLコールを使用してデータにアクセスできます。たとえば、従業員名のJohn SmytheがDB2ストアド・プロシージャのREVISE_SALARYに渡されるとします。DB2ストアド・プロシージャでは、John Smytheの新しい年俸を計算するために、DB2データベースから給与の値を取得します。結果として戻される改訂版の給与の使用により、Oracle DatabaseのEMP表が更新されます。

DECLARE
  INPUT VARCHAR2(15);
  RESULT NUMBER(8,2);
BEGIN
  INPUT := 'JOHN SMYTHE';
  REVISE_SALARY@DB2(INPUT, RESULT);
  UPDATE EMP SET SAL = RESULT WHERE ENAME = INPUT;
END;

ゲートウェイでは、DRDAサーバー（DB2/OS390など）のストアド・プロシージャを実行するためのコールを受信すると、最初にサーバー・カタログでプロシージャ名を検索します。ストアド・プロシージャを定義する情報は、DRDAサーバーごとに異なる形式で格納されます。たとえば、DB2/OS390 V5.0では、表SYSIBM.SYSPROCEDURESを使用しますが、DB2/OS390 V6.1では表SYSIBM.SYSROUTINESおよびSYSIBM.SYSPARMSを使用します。また、DB2/400では、表QSYS2.SYSPROCSおよびQSYS2.SYSPARMSを使用します。ゲートウェイには、アクセスするDRDAサーバーに応じて、検索用の既知のカタログのリストが含まれます。

カタログの検索順序は、カタログで位置指定子（SYSIBM.SYSPROCEDURESのLUNAMEなど）がサポートされるかどうかと、権限または所有者ID（SYSIBM.SYSPROCEDURESのAUTHIDやSYSIBM.SYSROUTINESのOWNERなど）に応じて変化します。

一部のDRDAサーバーでは、空白またはパブリックの権限修飾子が許可されます。現在接続しているDRDAサーバーでいずれかの修飾形式がサポートされる場合、ゲートウェイはカタログでプロシージャ名を検索する際にそれらのネーミング規則を適用します。

一致規則では、最初にパブリック定義が検索され、次に所有者で修飾されたプロシージャ名が検索されます。詳細は、IBM社のDB2 for OS/390 SQL用のリファレンス・ドキュメントを参照してください。

4.3.2 DB2でのプロシージャ機能の考慮事項

次に、ゲートウェイでのプロシージャ機能の使用に関する特別な考慮事項について示します。

• DB2ストアド・プロシージャでは、IMSトランザクションや顧客情報管理システム（CICS）・トランザクションなどのリカバリ可能リソースに対して調整、コミットおよびロールバック操作を行うことはできません。したがって、DB2ストアド・プロシージャでCICSまたはIMSトランザクションをコールする場合、そのトランザクションは個別の作業ユニットとみなされ、ストアド・プロシージャの完了には影響しません。つまり、OracleアプリケーションからDB2ストアド・プロシージャを実行し、そのプロシージャでCICSまたはIMSトランザクションをコールする場合、ゲートウェイではCICSまたはIMSトランザクション内で発生したどのアクティビティからもデータをリカバリすることはできません。

  たとえば、CICSトランザクションでは作業ユニットをロールバックできますが、これによりゲートウェイがDB2ストアド・プロシージャ内に含まれる他のDB2作業をコミットできなくなることはありません。

  同様に、DB2ストアド・プロシージャでVideo Surveillance and Monitoring（VSAM）ファイルなどのリカバリ不能なリソースを更新した場合、ゲートウェイでは、そのアクティビティはリカバリ可能な独自の作業ユニットとは異なるものとみなされます。

• PL/SQLレコードは、DB2ストアド・プロシージャの起動時にパラメータとして渡すことはできません。

• ゲートウェイでは、DB2ストアド・プロシージャのSIMPLEリンケージ規約がサポートされます。SIMPLEリンケージ規約により、DB2ストアド・プロシージャを対象にやりとりされるパラメータには、NULLを指定できません。

4.4 データベース・リンクの動作

ゲートウェイへの接続は、Oracle Databaseセッションでの最初の使用時に、データベース・リンクを通じて確立されます。この場合の接続とは、Oracle Databaseとゲートウェイ間の接続、およびゲートウェイとターゲットDRDAデータベース間のDRDAネットワーク接続の両方を示します。接続は、Oracle Databaseセッションが終了するまで確立されたままとなります。別のセッションまたはユーザーが同じデータベース・リンクにアクセスし、ゲートウェイおよびDRDAデータベースに対する別個の接続を取得することも可能です。

4.5 Oracle DatabaseのSQL構文の処理

Oracle Open Gateway製品の最も重要な機能の1つは、ユーザーおよびアプリケーション・プログラマにSQL透過性を提供することです。外部のSQL構文は、次の4つの形式に分類されます。

• 互換型

• 変換型

• 補正型

• ネイティブ・セマンティクス

4.5.1 互換型SQL関数

Oracle Databaseでは、互換型SQL関数は自動的にDRDAデータベースに転送されます。同じ構文内容と意味を持つSQL構文は、Oracle DatabaseとDRDAデータベースの両方に存在します。これらのSQL構文は、変更されずに転送されます。互換性のあるすべての関数は、列関数です。互換性のない関数は、等価のDRDA SQL関数に変換されるか、DRDAデータベースからデータが戻された後にOracle Databaseにより補正（後処理）されます。

4.5.2 変換型SQL関数

変換型関数は、Oracle DatabaseとDRDAデータベース間で意味は同じですが異なる名前を持つ関数です。ただし、すべてのアプリケーションでは、Oracleの関数名を使用する必要があります。DRDAデータベースにより異なる構文（異なる関数名）でサポートされるSQL構文は、Oracle Databaseによって自動的に変換され、DRDAデータベースに転送されます。Oracle Databaseは、DRDAデータベースに関数名を送信する前に、アプリケーションに対して透過的な方法でその関数名を変更します。

4.5.3 補正型SQL関数

Oracle Databaseによりサポートされる一部の高度なSQL構文は、DRDAデータベースでサポートされるとしても、同じ形式ではサポートされない場合があります。補正型関数は、DRDAサーバーによって認識されないSQL関数です。これらの関数のいずれかを含むSELECT文がOracle Databaseからゲートウェイに渡されると、ゲートウェイではSQL文をDRDAサーバーに渡す前にその関数を削除します。ゲートウェイは、選択されたDRDAデータベースの行をOracle Databaseに渡します。Oracle Databaseは、その関数を適用します。

4.5.3.1 後処理

Oracle Databaseでは、DRDAデータベースに転送されたSQLリクエストから互換性のないSQL構文を自動的に除外することで、存在しない関数や互換性のない関数を補正できます。Oracle Databaseは、DRDAデータベースから必要なデータを取得し、関数を適用します。このプロセスは、後処理と呼ばれます。

ゲートウェイでは、すべてのSQL関数をDRDAデータベースに渡そうとします。ただし、計算に出現する関数がDRDAデータベースでサポートされない場合、ゲートウェイではその関数を変更します。たとえば、プログラムがDB2/OS390データベースに対して次の問合せを実行するとします。

SELECT COS(X_COOR) FROM TABLE_X;

データベースではCOS関数の多くがサポートされないため、ゲートウェイでは問合せが次のように変更されます。

SELECT X_COOR FROM TABLE_X;

TABLE_XのX_COOR列のすべてのデータが、DB2/OS390データベースからOracle Databaseに渡されます。Oracle Databaseにデータが移動してから、COS関数が実行されます。

DRDAデータベースに格納された大量のデータに対して操作を実行する場合、一部の関数では後処理が必要になることに注意してください。

4.5.4 ネイティブ・セマンティクスSQL関数

通常補正される一部のSQL関数は、ネイティブ・セマンティクス機能を通じて上書きすることも可能です。SQL関数でネイティブ・セマンティクスが有効化されている場合、関数は補正（後処理）されずに処理のためにDRDAデータベースに渡されます。SQL関数でネイティブ・セマンティクスが有効化されており、処理のためにDRDAデータベースに渡されると、SQL関数はDRDAデータベースでネイティブに処理されます。詳細は、「ネイティブ・セマンティクス」を参照してください。

4.5.5 DB2/OS390 SQLの互換性

表4-1に、Oracle DatabaseとゲートウェイがDB2/OS390でSQL関数を処理する方法を示します。

表4-1 Oracle SQL関数ごとのSQLの互換性

Oracle SQL関数	互換型	変換型	補正型	ネイティブ・セマンティクス候補
ABS	-	-	○	○
ACOS	-	-	○	○
ADD_MONTHS	-	-	○
ASCII	-	-	○	○
ASIN	-	-	○	○
ATAN	-	-	○	○
ATAN2	-	-	○	○
AVG	○	-	-	-
BITAND	-	-	○	○
CAST	-	-	○	○
CEIL	-	CEILING	-	○
CHARTOROWID	-	-	○	-
CHR	-	-	○	○
CONCAT	○	-	-	-
CONVERT	-	-	○	○
COS	-	-	○	○
COSH	-	-	○	○
COUNT(*)	○	-	-	-
COUNT (DISTINCT colname)	○	-	-	-
COUNT (ALL colname)	○	-	-	COUNTCOL
COUNT (column)	○	-	-	COUNTCOL
DECODE	-	-	○	○
DUMP	-	-	○	○
EXP	-	-	○	○
FLOOR	○	-	-	○
GREATEST	-	-	○	○
HEXTORAW	-	-	○	○
INITCAP	-	-	○	○
INSTR	-	-	○	○
INSTRB	-	-	○	○
LAST_DAY	-	-	○	-
LEAST	-	-	○	○
LENGTH	-	-	○	○
LENGTHB	-	-	○	○
LN	-	-	○	○
LOG	-	-	○	○
LOWER	-	-	○	○
LPAD	-	-	○	○
LTRIM	-	-	○	○
MAX	○	-	-	-
MIN	○	-	-	-
MOD	-	-	○	○
MONTHS_BETWEEN	-	-	○	-
NEW_TIME	-	-	○	-
NEXT_DAY	-	-	○	-
NLS_INITCAP	-	-	○	○
NLS_LOWER	-	-	○	○
NLS_UPPER		-	○	○
NLSSORT	-	-	○	○
NVL		VALUE
NVL2	-	-	○	○
POWER	-	-	○	○
RAWTOHEX	-	-	○	○
REPLACE	-	-	○	○
REVERSE	-	-	○	○
ROUND	-	-	○	○
ROWIDTOCHAR	-	-	○	-
RPAD	-	-	○	○
RTRIM	-	-	○	○
SIGN	-	-	○	○
SIN	-	-	○	○
SINH	-	-	○	○
SOUNDEX		-	○	-
SQRT	-	-	○	○
STDDEV	-	-	○	○
SUBSTR	-	-	○	○
SUBSTRB	-	-	○	○
SUM	○	-	-	-
SYSDATE	-	-	○
TAN	-	-	○	○
TANH	-	-	○	○
TO_CHAR	-	-	○	-
TO_DATE	-	-	○	-
TO_MULTI_BYTE	-	-	○	-
TO_NUMBER	-	DECIMAL	-	○
TO_SINGLE_BYTE	-	-	○	-
TRANSLATE	-	-	○	○
TRIM	-	STRIP	○	○
TRUNC	-	-	○	○
UID	-	-	○	-
UPPER	-	-	○	○
USER	-	-	○	-
USERENV	-	-	○	-
VARIANCE	-	-	○	○
VSIZE	-	-	○	○

4.5.6 DB2/Universal Database SQLの互換性

次の表に、Oracle DatabaseとゲートウェイがDB2/UDBデータベースでSQL関数を処理する方法を示します。

表4-2 Oracle SQL関数ごとのDB2/Universal Database SQLの互換性

Oracle SQL関数	互換型	変換型	補正型	ネイティブ・セマンティクス候補
ABS	○	-	-	○
ACOS	-	-	○	○
ADD_MONTHS	-	-	○	-
ASCII	-	-	○	○
ASIN	-	-	○	○
ATAN	-	-	○	○
ATAN2	-	-	○	○
AVG	○	-	-	-
BITAND	-	-	○	○
CAST	-	-	○	○
CEIL	-	CEILING	-	○
CHARTOROWID	-	-	○	-
CHR	○	-	-	○
CONCAT	○	-	-	-
CONVERT	-	-	○	○
COS	○	-	-	○
COSH	-	-	○	○
COUNT(*)	○	-	-	-
COUNT (DISTINCT colname)	○	-	-	-
COUNT (ALL colname)	○	-	-	COUNTCOL
COUNT (column)	○	-	-	COUNTCOL
DECODE	-	-	○	○
DUMP	-	-	○	○
EXP	○	-	-	○
FLOOR	○	-	-	○
GREATEST	-	-	○	○
HEXTORAW	-	-	○	○
INITCAP	-	-	○	○
INSTR	-	-	○	○
INSTRB	-	-	○	○
LAST_DAY	-	-	○	-
LEAST	-	-	○	○
LENGTH	-	-	○	○
LENGTHB	-	-	○	○
LN	○	-	-	○
LOG	-	-	○	○
LOWER	-	LCASE	-	○
LPAD		-	○	○
LTRIM	-	-	○	○
MAX	○	-	-	-
MIN	○	-	-	-
MOD	○	-	-	○
MONTHS_BETWEEN	-	-	○	-
NEW_TIME	-	-	○	-
NEXT_DAY	○	-	○	-
NLS_INITCAP	-	-	○	○
NLS_LOWER	-	-	○	○
NLS_UPPER			○	○
NLSSORT	-	-	○	○
NVL	-	VALUE	-	-
NVL2	-	-	○	○
POWER	○	-	-	○
RAWTOHEX	-	-	○	○
REPLACE	○	-	-	○
REVERSE	-	-	○	○
ROUND	○	-	-	○
ROWIDTOCHAR		-	○	-
RPAD			○	○
RTRIM	-	-	○	○
SIGN	○	-	-	○
SIN	○	-	-	○
SINH	-	-	○	○
SOUNDEX	-	-	○	-
SQRT	○	-	-	○
STDDEV	-	-	○	○
SUBSTR	-	-	○	○
SUBSTRB	-	-	○	○
SUM	○	-	-	-
SYSDATE	-	-	○	-
TAN	○	-	-	○
TANH	-	-	○	○
TO_CHAR	-	-	○	-
TO_DATE	-	-	○	-
TO_MULTI_BYTE	-	-	○	-
TO_NUMBER	-	DECIMAL	-	○
TO_SINGLE_BYTE	-	-	○	-
TRANSLATE	-	-	○	○
TRIM	-	-	○	○
TRUNC	○	-	-	○
UID	-	-	○	-
UPPER	-	UCASE	-	○
USER	-	-	○	-
USERENV	-	-	○	-
VARIANCE	-	-	○	○
VSIZE	-	-	○	○

4.5.7 DB2/400 SQLの互換性

次の表に、Oracle DatabaseとゲートウェイがDB2/400データベースでSQL関数を処理する方法を示します。

表4-3 Oracle SQL関数ごとのDB2/400 SQLの互換性

Oracle SQL関数	互換型	変換型	補正型	ネイティブ・セマンティクス候補
ABS	-	ABSVAL	-	○
ACOS	-	-	○	○
ADD_MONTHS	-	-	○	-
ASCII	-	-	○	○
ASIN	-	-	○	○
ATAN	-	-	○	○
ATAN2	-	-	○	○
AVG	○	-	-	-
BITAND	-	-	○	○
CAST	-	-	○	○
CEIL	-	CEILING	-	○
CHARTOROWID	-	-	○	-
CHR	-	-	○	○
CONCAT	○	-	-	-
CONVERT	-	-	○	○
COS	○	-	-	○
COSH	○	-	-	○
COUNT(*)	○	-	-	-
COUNT (DISTINCT colname)	○	-	-	-
COUNT (ALL colname)	○	-	-	COUNTCOL
COUNT (column)	○	-	-	COUNTCOL
DECODE	-	-	○	○
DUMP	-	-	○	○
EXP	○	-	-	○
FLOOR	○	-	-	○
GREATEST	-	-	○	○
HEXTORAW	-	-	○	○
INITCAP	-	-	○	○
INSTR	-	-	○	○
INSTRB	-	-	○	○
LAST_DAY	-	-	○	-
LEAST	-	-	○	○
LENGTH	-	-	○	○
LENGTHB	-	-	○	○
LN	○	-	-	○
LOG	-	-	○	○
LOWER	-	-	○	○
LPAD	-	-	○	○
LTRIM	-	-	○	○
MAX	○	-	-	-
MIN	○	-	-	-
MOD	-	-	○	○
MONTHS_BETWEEN	-	-	○
NEW_TIME	-	-	○
NEXT_DAX	-	-	○
NLS_INITCAP	-	-	○	○
NLS_LOWER	-	-	○	○
NLS_UPPER	-	-	○	○
NLSSORT	-	-	○	○
NVL	-	VALUE	-	-
NVL2	-	-	○	○
POWER	-	-	○	○
RAWTOHEX	-	-	○	○
REPLACE	-	-	○	○
REVERSE	-	-	○	○
ROUND	-	-	○	○
ROWIDTOCHAR	-	-	○	-
RPAD	-	-	○	○
RTRIM	-	-	○	○
SIGN	-	-	○	○
SIN	○	-	-	○
SINH	○	-	-	○
SOUNDEX	-	-	○	-
SQRT	○	-	-	○
STDDEV	○	-	-	○
SUBSTR	-	-	○	○
SUBSTRB	-	-	○	○
SUM	○	-	-	-
SYSDATE	-	-	○	-
TAN	○	-	-	○
TANH	○	-	-	○
TO_CHAR	-	-	○	-
TO_DATE	-	-	○	-
TO_MULTI_BYTE	-	-	○	-
TO_NUMBER	-	DECIMAL	-	○
TO_SINGLE_BYTE	-	-	○	-
TRANSLATE	-	-	○	○
TRIM	-	-	○	○
TRUNC	-	-	○	○
UID	-	-	○	-
UPPER	-	TRANSLATE	-	○
USER	-	-	○	-
USERENV	-	-	○	-
VARIANCE	-	VAR	-	○
VSIZE	-	-	○	○

4.6 ネイティブ・セマンティクス

Oracle Databaseによりサポートされる一部の高度なSQL構文は、DRDAデータベースでは同じ形式でサポートされない場合があるため、Oracle Databaseは、その機能でDRDAデータベースのデータを後処理することで、存在しない機能または互換性のない機能を補正します。

関連項目: 詳細は、「Oracle DatabaseのSQL構文の処理」を参照してください。

この機能により最大限の透過性が提供されますが、パフォーマンスに影響が出る可能性があります。また、特定のDRDAデータベースの新規バージョンでは、以前のサポート対象外の関数または機能が実装される可能性や、Oracle Database関数との互換性の高いサポート対象のセマンティクスが変更される可能性があります。

一部のDRDAサーバーでは、ユーザー定義関数もサポートされます。ユーザーは、状況に応じて（DRDAデータベースに）Oracle Database関数をネイティブに実装できます。これにより、DRDAサーバーでは、基礎となるデータベース実装（DB2など）に関数を渡すことができます。ネイティブ・セマンティクスにより、DRDAサーバーで特定の機能をネイティブに処理する方法が提供されます。

特定の関数でネイティブ・セマンティクス機能を有効化する場合、ネイティブ・セマンティクスには一般的に透過性とパフォーマンスのトレードオフ関係に対応するメリットおよびデメリットが存在するため、様々なことを考慮する必要があります。このような考慮事項の1つとして、データ強制変換の透過性があげられます。Oracle Databaseでは、多くのSQL関数について強制変換（暗黙的データ変換）が行われます。つまり、特定の関数に対して指定された値が正しくない場合、その値は処理の前にOracle Databaseによって強制的に変換されます（正しい値タイプに変更されます）。ただし、ネイティブ・セマンティクス機能が有効な場合、その値は、指定された値のままDRDAサーバーに渡されて処理されます。多くの場合、DRDAサーバーでは値を正しいタイプに強制変換できないため、エラーが発生します。

もう1つの考慮事項は、特定のSQL関数のパラメータの互換性に関することです。たとえば、SUBSTRのOracle Database実装では、文字列索引で負の値が許可されますが、ほとんどのDRDAサーバーのSUBSTR実装では、文字列索引で負の値が許可されません。ただし、DRDAサーバーと互換性のある形式でSUBSTRを起動するようアプリケーションが実装されている場合、関数はOracle DatabaseまたはDRDAサーバーと同じように動作します。

また別の考慮事項は、環境内のリソース制約を理由として、DRDAサーバーでの関数の処理が望ましくない場合があることです。

これらの機能を有効化または無効化する方法の詳細は、「DRDA_CAPABILITY」を参照してください。次の機能のOracle Database形式は、『Oracle Database SQL言語リファレンス』を参照してください。

4.6.1 有効化可能なSQL関数

次のリストには、デフォルトで無効化（OFF）されているSQL関数が含まれます。これらの関数は、オプションで有効化（ONに変更）できます。

表4-4 有効化可能なSQL関数のリスト

関数名	関数名	関数名	関数名
ABS	ACOS	ASCII	ASIN
ATAN	ATAN2	BITAND	CAST
CEIL	CHR	CONVERT	COS
COSH	COUNTCOL	DECODE	DUMP
EXP	FLOOR	GREATEST	HEXOTRAW
INITCAP	INSTR	INSTRB	LEAST
LENGTH	LENGTHB	LN	LOG
LOWER	LPAD	LTRIM	MOD
NLS_INITCAP	NLS_UPPER	NLS_LOWER	NLSSORT
NVL2	POWER	RAWTOHEX	REPLACE
REVERSE	ROUND	RPAD	RTRIM
SIGN	SIN	SINH	SQRT
STDDEV	SUBSTR	SUBSTRB	TAN
TANH	TO_NUMBER	TRANSLATE	TRIM
TRUNC	UPPER	VARIANCE	VSIZE

4.6.2 無効化可能なSQL関数

次のSQL関数は、デフォルトで有効化（ON）されています。

• GROUPBY

• HAVING

• ORDERBY

• WHERE

ORDERBYにより、ソート順序が制御されます（ソート順序は様々なソートの場所に応じて変化します）。たとえば、ORDERBYをONに設定すると、DB2のソートはExtended Binary Coded Decimal Interchange Code（EBCDIC）のソート順序に基づきますが、ORDERBYをOFFに設定すると、Oracle DatabaseのソートはASCIIのソート順序に基づきます。

他の3つの関数（GROUPBY、HAVINGおよびWHERE）は、追加の処理時間を要する可能性があります。コストのかかるリソースの使用を最小化する場合、コストのかからないリソースで処理を実行するようにこれらの関数の設定を選択する必要があります。また、前にリストした関数を無効化することもできます。

4.6.3 SQLの集合演算子および句

WHEREおよびHAVING句は、DRDAサーバーのすべてのバージョンで互換性があります。つまり、これらの句は、変更されることなく処理のためにDRDAサーバーに渡されます。GROUP BYおよびORDER BY句がDRDAサーバーに渡されるか、またはOracle Databaseによって補正されるかは、ネイティブ・セマンティクス・パラメータにより決定されます（前述の項を参照）。

集合演算子UNIONおよびUNION ALLは、DRDAサーバーのすべてのバージョンで互換性があり、変更されることなく処理のためにDRDAサーバーに渡されます。集合演算子INTERSECTおよびMINUSは、DB2/UDBを除くすべてのバージョンのDRDAサーバーで補正されます。DB2/UDBの場合、INTERSECTは互換性があり、MINUSはEXCEPTに変換されます。

4.7 DRDAデータ型からOracleデータ型への変換

アプリケーションとデータベース間でデータを移動する場合、ゲートウェイでは、特定のデータ型のホスト変数またはリテラルのデータ値を、データベースで認識されるデータ型にバインドします。したがって、ゲートウェイでは、任意のバージョンのDRDAサーバーの値を適切なOracleデータ型にマップしてから、それらの値をアプリケーションまたはOracleツールに戻します。

次の表に、データ型のマッピングおよび制限をリストします。表にリストされたDRDAサーバーのデータ型は、一般的なものです。データ型のサイズおよび値の制限の詳細は、使用しているDRDAデータベースのドキュメントを参照してください。

表4-5 データ型のマッピングおよび制限

DRDAサーバー	Oracle外部データ型	基準
CHAR(N)	CHAR(N)	N < = 255
VARCHAR (N)	VARCHAR2(N) LONG	N < = 2000 2000 < N < = 32740
LONG VARCHAR(N)	VARCHAR2(N)	N < = 2000
LONG VARCHAR(N)	LONG	2000 < N < = 32740
CHAR(N) FOR BIT DATA	RAW(N)	N < = 255
VARCHAR(N) FOR BIT DATA	RAW(N)	1 < = N < = 255
VARCHAR(N) FOR BIT DATA	LONG RAW(N)	255 < N < = 32740
LONG VARCHAR(N) FOR BIT DATA	RAW(N)	1 < = N < = 255
LONG VARCHAR(N) FOR BIT DATA	LONG RAW(N)	255 < N < = 32740
DATE	DATE	「日付および時刻操作の実行」を参照
TIME	CHAR(8)	「日付および時刻操作の実行」を参照
TIMESTAMP	CHAR(26)	「日付および時刻操作の実行」を参照
GRAPHIC	CHAR(2N)	N <= 127
VARGRAPHIC	VARCHAR2(2N) LONG	N <= 1000 1000 <= N <= 16370
LONG VARGRAPHIC	VARCHAR2(2N) LONG	N <= 1000 1000 <= N <= 16370
単精度浮動小数点数	FLOAT(21)	N/A
倍精度浮動小数点数	FLOAT(53)	N/A
小数 (P, S)	NUMBER(P,S)	N/A

4.7.1 文字列操作の実行

ゲートウェイでは、参照列のデータ型を使用してすべての文字列の比較、連結およびソートを実行し、ゲートウェイを使用するアプリケーションにより渡された文字列値の有効性を決定します。ゲートウェイでは、1つのデータ型から別のデータ型に文字列が自動的に変換され、必要に応じて文字列と日付間の変換が行われます。

DRDAデータベースが文字列に文字以外のバイナリ・データを保持するよう設計されていることはよくあります。DRDAシステムで実行されるアプリケーションは、通常、文字データが含まれる場合と同じようにデータを格納および検索できます。ただし、このデータにアクセスするアプリケーションが、異なるキャラクタ・セットを使用する環境で実行されると、不正確なデータが戻される可能性があります。

ホスト上で稼働するゲートウェイでは、DB2/400またはDB2/OS390ホストから取得された文字データが、EBCDICからASCIIに変換されます。文字データがホストからDB2/400またはDB2/OS390に送信されるときに、ASCIIデータはEBCDICに変換されます。文字が文字列内のバイナリ・データである場合、この変換により、アプリケーションでは間違った情報またはエラーが取得されます。これらのエラーを解決するには、文字以外のデータを保持するDB2/400またはDB2/OS390の文字列を、FOR BIT DATAオプション付きで作成する必要があります。アプリケーションでは、文字以外のデータを保持する文字列は、Oracleデータ型のRAWおよびLONG RAWを使用して処理される必要があります。ホスト上でFOR BIT DATAを使用して定義された文字列のDESCRIBE情報は、常にRAWまたはLONG RAWを示します。

4.7.2 文字列データ型の変換

ゲートウェイでは、ホスト変数の文字列のデータ値を固定長の文字列としてバインドします。バインド長は、文字列のデータ値の長さです。ゲートウェイでは、この変換をバインドごとに実行します。

DRDA VARCHARデータ型には、1〜32740バイトの長さを指定できます。このデータ型は、長さが1〜2000文字であると、Oracle VARCHAR2データ型に変換されます。長さが2000〜32740文字であると、Oracle LONGデータ型に変換されます。

DRDA VARCHARデータ型には32740バイト以下を指定できますが、これはOracle LONGデータ型の最大サイズよりずっと短くなっています。長さが32740バイトを超えるOracle LONGデータ型を定義すると、DRDA VARCHARデータ型へのマップ時にエラー・メッセージが出力されます。

4.7.3 GRAPHIC文字列操作の実行

DB2 GRAPHICデータ型は、ダブルバイトの文字列データのみを格納します。DB2 GRAPHICデータ型の最大サイズは、通常、その対応する文字データ型の半分です。たとえば、CHARの最大サイズが255文字であるとすると、GRAPHICの最大サイズは127文字になります。

Oracle Databaseには直接一致するデータ型がないため、ゲートウェイではOracleの文字データ型とDB2のGRAPHICデータ型間で変換が行われます。Oracle Databaseの文字データ型には、シングルバイト、混合バイトまたはダブルバイトの文字データを含めることができます。ゲートウェイでは、ターゲットのDB2列がGRAPHIC型であるかどうかと、ゲートウェイ初期化パラメータがこの変換を実行するよう設定されているかどうかに応じて、文字列データを適切なダブルバイト専用形式に変換します。構成情報の詳細は、付録B「初期化パラメータ」および付録C「DRDAのグローバリゼーション・サポート」を参照してください。

4.7.4 日付および時刻操作の実行

日付および時刻データの実装は、IBM DRDAデータベースとOracle Databaseでは大きく異なります。Oracle Databaseには、日の情報としてカレンダ日付および時刻の両方を格納できる単一の日付データ型であるDATEがあります。

IBM DRDAデータベースでは、次の3つの異なる日付および時刻のデータ型がサポートされます。

DATEは、カレンダ日付専用です。

TIMEは、時刻専用です。

TIMESTAMPは、カレンダ日付および時刻をIBM DRDAデータベースの内部形式のマイクロ秒単位と結合した数値です。

4.7.4.1 TIMEおよびTIMESTAMPデータの処理

IBM TIMEおよびTIMESTAMPデータをOracle DATEデータに変換する組込みメカニズムはありません。アプリケーションでは、TIMEデータ型を、長さが8バイトのOracle CHAR形式に処理する必要があります。また、アプリケーションでは、TIMESTAMPデータ型を、長さが26バイトのOracle CHAR形式に処理する必要があります。

アプリケーションでは、TIMEおよびTIMESTAMP機能を文字列として読み取り、その文字列の各部分を変換または分割して数値演算を実行します。TIMEおよびTIMESTAMP値は、IBM DRDAデータベースに適切な長さと形式の文字リテラルまたはバインド変数として送信できます。

4.7.4.2 DATEデータの処理

OracleおよびIBMのDATEデータ型は、相互にマップされます。IBM DATEが問い合されると、0時（真夜中）に設定されたOracle DATEに変換されます。IBM DATE列に対してOracle DATEが処理されると、日付値はIBM DATE形式に変換され、時刻値はすべて破棄されます。

日付の文字表現は、Oracle形式とIBM DRDA形式で異なります。OracleアプリケーションのSQL文が日付リテラルを含む場合、または文字バインド変数を使用して日付を転送する場合、ゲートウェイでは、その日付をIBM DRDA互換形式に変換する必要があります。

ゲートウェイでは、文字値がIBM DATE列に対して処理されるタイミングは自動的に認識されません。アプリケーションでは、文字日付値をOracle TO_DATE関数の表記法に従って囲むことで、文字日付値を区別する必要があります。たとえば、EMPがIBM DRDAデータベースのデータにアクセスするシノニムまたはビューである場合、次のSQL文は使用できません。

SELECT * FROM EMP WHERE HIREDATE = '03-MAR-81'

次の文を使用する必要があります。

SELECT * FROM EMP WHERE HIREDATE = TO_DATE('03-MAR-81')

適切な日付値用の文字バインド変数を使用するプログラム的インタフェースを持つプログラムの場合、次のSQL文を使用する必要があります。

SELECT * FROM EMP WHERE HIREDATE = TO_DATE(:1)

文がOracle Database表に対して実行される場合、前述のSQL表記法は、SQL文のセマンティクスに影響しません。文は、引き続きOracleおよびIBM DRDAのアクセス対象データ・ストア間で移植可能です。

TO_DATE関数は、次のいずれかの書式の日付には必要ありません。

• YYYY-MM-DD（ISO/JIS）

• DD.MM.YYYY（ヨーロッパ）

• MM/DD/YYYY（USA）

たとえば、次のようになります。

SELECT * FROM EMP WHERE HIREDATE = '1981-03-03'

同様に、Oracleの7バイト・バイナリ日付形式である入力バインド変数についても、TO_DATEは必要ありません。これらの値は、ゲートウェイで日付として認識されます。

4.7.4.3 日付の計算の実行

一般的に、次の形式のSQL式は、ゲートウェイで正しく動作しません。

date + number
number + date
date - number
date1 - date2

日付と数値の加算および減算を示す(date + number,number + date,date - number)の形式は、DRDAサーバーに送信されて拒否されます。サポート対象のサーバーでは、日付に対する数値の加算または減算は許可されません。

サポート対象のサーバーでは日付の減算の解釈が異なるため、2つの日付を(date1 - date2)のように減算すると、結果はサーバーごとに変化します。

注意: 日付の計算に関する問題が解決されるまで、すべてのゲートウェイSQLで日付の計算式を使用しないでください。

4.7.5 日付

日付処理には次の2つのカテゴリがあります。

• 2桁の年日付。2000年を基準としてその前後50年として処理されます。

• 4桁の年日付。2000年に関するあいまいさは存在しません。

Oracle Database 11gサーバーおよびゲートウェイのデフォルトのHS_NLS_DATE_FORMATパラメータは、4桁の年を含む書式に設定することをお薦めします。

次のいずれかの方法を使用して21世紀の日付を入力してください。

• TO_DATE関数

  4文字の年フィールドを含む任意の日付書式を使用します。使用可能な日付書式の文字列オプションの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

  たとえば、TO_DATE('2008-07-23', 'YYYY-MM-DD')は、任意のSELECT、INSERT、UPDATEまたはDELETE文で使用できます。

• HS_NLS_DATE_FORMATパラメータ

  HS_NLS_DATE_FORMATパラメータでは、パターンのないOracle Databaseの明示的なTO_DATE関数や、暗黙的に日付に変換される文字列用のデフォルト書式を定義します。

  たとえば、HS_NLS_DATE_FORMATが'YYYY-MM-DD'として定義されている場合、'2008-07-23'は任意のSELECT、INSERT、UPDATEまたはDELETE文で使用できます。

4.7.6 HS_NLS_DATE_FORMATのサポート

次の表に、HS_NLS_DATE_FORMATで使用できる4つのパターンを示します。

DB2の日付書式	パターン	例
EUR	DD.MM.YYYY	30.10.1994
ISO	YYYY-MM-DD	1994-10-30
JIS	YYYY-MM-DD	1994-10-30
USA	MM/DD/YYYY	10/30/1994

Oracle Databaseのデフォルト書式の'DD-MON-YY'は、DB2では許可されません。

次に、21世紀の日付値を入力および選択する方法の例を示します。

ALTER SESSION SET HS_NLS_DATE_FORMAT = 'YYYY-MM-DD';
INSERT INTO EMP (HIREDATE) VALUES ('2008-07-23');
SELECT * FROM EMP WHERE HIREDATE = '2008-07-23';
UPDATE EMP SET HIREDATE = '2008-07-24'
   WHERE HIREDATE = '2008-07-23';
DELETE FROM EMP WHERE HIREDATE = '2008-07-24';

4.7.7 Oracle TO_DATE関数

Oracle TO_DATE関数は、SQL INSERT、UPDATE、DELETEおよびSELECT WHERE句で前処理されます。SELECTの結果リストのTO_DATE関数は、前処理されません。

通常、日付列を対象とする更新または比較操作に値を提供する場合、TO_DATE関数が必要です。そのため、ゲートウェイでは、SQL文がDB2に送信される前にTO_DATE句に含まれる情報が受入れ可能な値で置換されます。

SELECTの結果リストを除き、すべてのTO_DATE関数は前処理され、TO_DATE関数の結果となる値に変換されます。TO_DATE(literal)またはTO_DATE(:bind_variable)のみが許可されます。SELECTの結果リストを除き、TO_DATE(column_name)という関数形式はサポートされません。

DB2ではVALUES句で関数を使用できないため、Oracle TO_DATE関数の前処理による単純な値への変換は、INSERTのVALUES句で役立ちます。この場合、DB2では、VALUESリストに単純な値を取得します。1つ、2つまたは3つのオペランドを含むすべての形式のTO_DATE関数がサポートされます。

4.7.8 数値データ型操作の実行

DRDAサーバーのIBMバージョンでは、宛先列の数値データ型（整数、倍精度浮動小数点数または小数など）の自動変換が実行されます。ユーザーにはこのデータ型変換を制御する方法はなく、この変換はデータベースの宛先列のデータ型とは無関係に発生します。

たとえば、PRICEがIBM DRDAデータベースのPRODUCT表の整数列である場合、IBM DRDAサーバーでは浮動小数点数が整数に自動変換されるため、次の例のように更新操作を行うとアイスクリーム・コーンの価格が$1.00に間違って設定されます。

UPDATE PRODUCT
SET PRICE = 1.50
WHERE PRODUCT_NAME = 'ICE CREAM CONE    ';

PRICEは整数であるため、IBM DRDAサーバーでは小数データ値の1.50が1に自動変換されます。

4.7.9 COUNT関数のマッピング

Oracle Databaseでは、COUNT関数で次の4つのオペランドがサポートされます。

• COUNT(*)

• COUNT(DISTINCT colname)

• COUNT(ALL colname)

• COUNT(colname)

一部のDRDAサーバーでは、サポートされないCOUNTの形式があります（特にCOUNT(colname)やCOUNT(ALL colname)など）。そのような場合、COUNT関数とその引数は、COUNT(*)に変換されます。そのため、特にカウント対象の列にNULLが含まれる場合、期待どおりの結果を取得できない可能性があります。

前述の形式がサポートされないDRDAサーバーでは、WHERE句を追加することで同等の機能を実現できる可能性があります。たとえば、次のようになります。

SELECT COUNT(colname) FROM table@dblink WHERE colname IS NOT NULL

または

SELECT COUNT(ALL colname) FROM table@dblink WHERE colname IS NOT NULL

サポートされない形式のCOUNTがある既知のDRDAサーバーの詳細は、第2章の「SQLの制限」を参照してください。

4.7.10 ゾーン10進数操作の実行

ゾーン10進数フィールドは、Oracle Databaseではパック10進数として記述されます。ただし、Pro*CプログラムなどのOracleアプリケーションでは、サポートされる任意のOracle数値データ型を使用してゾーン10進数列に挿入できます。ゲートウェイでは、この数値が最も適切なデータ型に変換されます。情報の欠落が発生しないかぎり、データはDRDAデータベースから任意のOracleデータ型にフェッチできます。

4.8 ゲートウェイを通じたネイティブSQL文の受渡し

パススルーSQL機能により、アプリケーション開発者は、Oracle Databaseによる文の解釈なしで直接DRDAサーバーにSQL文を送信できます。ゲートウェイにサポートされるDBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATE SQLパススルー文は、問合せ以外（INSERT、UPDATE、DELETEおよびDDL文）に制限され、それらの文にはバインド変数を含めることができません。ゲートウェイでは、DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATEを使用してネイティブSQL文を実行できます。

DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATEは、組込みゲートウェイ・ファンクションです。このファンクションは、1つの入力引数を受け取り、SQL文により影響される行の数を戻します。データ定義言語（DDL）文の場合、このファンクションは0（ゼロ）を戻します。

DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATEは、ゲートウェイの予約名であり、特にネイティブSQLの実行に使用されます。

11.1リリースのOracle Database Gateway for DRDAでは、パススルーで発行された問合せから結果セットを取得できます。構文は、DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATEファンクションとは異なります。詳細は、「パススルーを通じた結果セットの取得」を参照してください。

4.8.1 パススルーを通じたDDL文の処理

前述のとおり、DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATEファンクションを通じて処理されるSQL文は、Oracle Databaseサーバーでは解釈されません。その結果、Oracle Databaseサーバーでは、そのような文によりDRDAサーバーに変更が加えられたかどうかを認識できません。つまり、DRDAサーバーの変更後にOracle Databaseのキャッシュ情報を最新状態にしなければ、データベースは、同じセッション内の後続の問合せで間違った古い情報に依存し続ける可能性があります。

この例としてあげられるのが、列の追加や削除により表の構造を変更する場合です。アプリケーションがゲートウェイを通じて表を参照する場合（表に問合せを実行する場合など）、Oracle Databaseサーバーでは表の定義をキャッシュします。ここで、（同じセッション内で）アプリケーションが引き続きDBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATEを使用して列を追加し、表の形式を変更したとします。この場合、アプリケーションによる次の表参照で戻されるのは、表の古い列の定義であり、表の新しい列は無視されます。これは、Oracle Databaseサーバーが文を処理しなかったため、変更が認識されないことが原因です。データベースでは変更を認識していないため、表の形式を再度問い合せる理由はなく、すでにキャッシュされた形式を使用して新規問合せをすべて処理することになります。

Oracle Databaseサーバーで新規形式の表を取得するには、ゲートウェイの既存のセッションをクローズし、新規セッションをオープンする必要があります。これを行うには、次の2つの方法があります。

• Oracle Databaseサーバーでアプリケーション・セッションを終了し、DRDAサーバーを変更してから新規セッションを開始する方法。

• DRDAサーバーを変更してからALTER SESSION CLOSE DATABASE LINKコマンドを実行する方法。

これらのいずれかの操作により、キャッシュされた表の定義は無効化され、Oracle Databaseサーバーでは次の参照において新規定義が強制的に取得されます。

4.8.2 DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATEの使用

DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATEを使用してパススルーSQL文を実行するには、次の構文を使用します。

number_of_rows = DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATE@dblink ('native_DRDA_sql');

変数の意味は次のとおりです。

number_of_rowsは、パススルーSQLの完了により影響を受ける行の数が割り当てられる変数です。DDL文の場合、影響を受ける行の数として0（ゼロ）が戻されます。

dblinkは、ゲートウェイへのアクセスに使用されるデータベース・リンクの名前です。

native_DRDA_sqlは、問合せ以外の有効なSQL文です（CONNECT、COMMITおよびROLLBACKを除く）。文にバインド変数を含めることはできません。動的に準備できないネイティブSQL文は、DRDAサーバーにより拒否されます。DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATEファンクションにより渡されるSQL文は、文字列である必要があります。有効なSQL文の詳細は、特定のDRDAサーバーのSQLリファレンスを参照してください。

4.8.2.1 例

1. DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATEを使用してDB2表に行を挿入します。

   DECLARE
     num_rows integer;
   BEGIN
   num_rows:=DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATE@dblink
   ('INSERT  INTO SCOTT.DEPT VALUES (10,''PURCHASING'',''PHOENIX'')');
   END;
   /
   

2. DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATEを使用してDB2に表を作成します。

   DECLARE
     num_rows integer;
   BEGIN
     num_rows:=DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATE@dblink
     ('CREATE TABLE MYTABLE (COL1 INTEGER, COL2 INTEGER, COL3 CHAR(14),
     COL4 VARCHAR(13))');
   END;
   /
   

4.8.3 パススルーを通じた結果セットの取得

Oracle Database Gateway for DRDAには、パススルーを通じて入力されたSELECT SQL文から結果セットを取得する機能があります。詳細は、『Oracle Database Heterogeneous Connectivity管理者ガイド』を参照してください。

4.8.3.1 例

DECLARE
  CRS binary_integer;
  RET binary_integer;
  VAL VARCHAR2(10)
BEGIN
  CRS:=DBMS_HS_PASSTHROUGH.OPEN_CURSOR@gtwlink;
  DBMS_HS_PASSTHROUGH.PARSE@gtwlink(CRS,'SELECT NAME FROM PT_TABLE');
BEGIN
  RET:=0;
  WHILE (TRUE)
  LOOP
    RET:=DBMS_HS_PASSTHROUGH.FETCH_ROW@gtwlink(CRS,FALSE);
    DBMS_HS_PASSTHROUGH.GET_VALUE@gtwlink(CRS,1,VAL);
    INSERT INTO PT_TABLE_LOCAL VALUES(VAL);
  END LOOP;
  EXCEPTION
    WHEN NO_DATA_FOUND THEN
      BEGIN
        DBMS_OUTPUT.PUT_LINE('END OF FETCH');
        DBMS_HS_PASSTHROUGH.CLOSE_CURSOR@gtwlink(CRS);
      END;
    END;
END;
/

4.9 DRDAサーバーでのOracleデータ・ディクショナリのエミュレーション

ゲートウェイでは、オプションで、Oracleデータ・ディクショナリでモデル化されたデータ・ディクショナリ・ビューを使用してDRDAデータベース・カタログを拡張できます。これらのビューは、DRDAデータベースのディクショナリ表に基づいており、ビューのカタログ情報はOracleユーザーによく知られた形式で表示されます。ゲートウェイのインストール中に作成されたビューでは、各ユーザーの権限に基づいて、ユーザーごとに表示されるデータ・ディクショナリ情報が自動的に制限されます。

4.9.1 ゲートウェイのデータ・ディクショナリの使用

ゲートウェイのデータ・ディクショナリ・ビューにより、DRDAデータベースの内容および使用に関してOracleに似たインタフェースが提供されます。これらのビューの一部は、Oracle製品で必要とされます。ゲートウェイでは、DB2/OS390、DB2/400およびDB2/UDBのカタログ・ビューがサポートされます。

ゲートウェイのデータ・ディクショナリ・ビューを問い合せることで、DRDAデータベースのオブジェクトを参照し、DRDAデータベースの権限付与されたユーザーを確認できます。多くのOracleカタログ・ビューが、Oracle Database Gateway for DRDAによりサポートされます。Oracle DB2カタログ・ビューの詳細は、付録Aを参照してください。これらのビューは、ゲートウェイと完全に互換性があります。

4.9.2 DRDAカタログの使用

各DRDAデータベースには、独自のカタログ表およびビューがあり、使用すると役に立つことがあります。これらのカタログの詳細は、IBM社の適切なドキュメントを参照してください。

4.10 DRDAカーソルの数の定義

カーソルの数は、アプリケーション要件に応じて任意に定義できます。この数にはデフォルト値の100を使用することをお薦めします。ただし、デフォルト値が実際のアプリケーションに適切でない場合、インストール環境でカーソルの数を定義するときには次の2つの点を考慮する必要があります。

• カーソルごとに、追加の記憶域量と追加の管理が必要になります。

• DRDA_PACKAGE_SECTIONSを変更する場合、パッケージをリバインドする必要があります。

パラメータDRDA_PACKAGE_SECTIONSは、DRDAパッケージに固有です。このパラメータでは、セクションの数（IBMデータベースでのオープン・カーソル）を定義します。DRDA_PACKAGE_SECTIONSパラメータの設定方法の詳細は、付録B「初期化パラメータ」を参照してください。

---

戻る  次へ

Copyright © 2004, 2007, Oracle. All rights reserved.

目次 索引