機械翻訳について

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

以下のセクションでは、Oracle Database Gateway for DRDAに固有の情報を提供します。

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

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

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

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

• Oracle DatabaseのSQL構文の処理

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

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

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

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

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

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

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

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

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

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

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

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

フェッチの再ブロック

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

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

クライアントとOracleデータベース間の配列サイズは、Oracleアプリケーションによって決まります。 詳細は、ご使用のプラットフォームに応じて「Oracle Database Gatewayインストールおよび構成ガイドfor IBM AIX on POWER Systems (64-Bit), Linux x86-64, Oracle Solaris on SPARC (64-Bit), Oracle Solaris on x86-64 (64-Bit)およびHP-UX Itanium」または「Oracle Database Gatewayインストールおよび構成ガイドfor Microsoft Windows」を参照してください。

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

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

Oracleストアド・プロシージャは、Oracle Databaseのローカル・インスタンスおよびリモート・インスタンスに配置できます。 図4-1は、2つのストアド・プロシージャ: oraproc1 は ORA1 Oracleインスタンスに格納されているプロシージャで、 oraproc2 はORA2 Oracleインスタンスに格納されているプロシージャです。

図4-1 分散Oracle環境でのOracleストアド・プロシージャのコール

「"図4-1分散Oracle環境でのOracleストアド・プロシージャのコール"の説明」

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

CREATE SYNONYM oraproc2 FOR oraproc2@ora2;

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

「図4-1」では、oraproc1の2番目の文を使用して、ORA2インスタンス内の表にアクセスします。 同様に、Oracleストアド・プロシージャを使用して、ゲートウェイを介してDB2表にアクセスすることもできます。

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

ゲートウェイのプロシージャ機能により、ネイティブDRDAサーバーのストアド・プロシージャ の起動が可能になります。 ストアド・プロシージャがDRDAサーバーに定義されると、ゲートウェイは既存のDRDAサーバー定義を使用してプロシージャを実行できます。 ゲートウェイでは、DB2ストアド・プロシージャをコールするための特別な定義は必要ありません。 標準のOracle PL/SQLは、ストアド・プロシージャを実行するためにOracleアプリケーションによって使用されます。

「図4-2」では、Oracleアプリケーションが、DRDAサーバー(たとえば、DB2 UDB for z/OS)に定義されている empproc ストアド・プロシージャを呼び出します。

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

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

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

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

OracleアプリケーションがDB2ストアド・プロシージャを呼び出すには、まず、DB2 SQLのIBM参照資料に記載されている手順を使用して、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サーバー上でストアド・プロシージャを実行するためにコールを受け取ると、まずサーバー・カタログ内のプロシージャ名が検索されます。 ストアド・プロシージャを定義する情報は、各DRDAサーバー上の異なる形式で格納されます。 例えば、DB2 UDB for iSeriesは、表QSYS2.SYSPROCSとQSYS2.SYSPARMSを使用します。 ゲートウェイには、アクセスするDRDAサーバーに応じて、検索する既知のカタログのリストがあります。

カタログの検索順序は、カタログがロケーション指定子(SYSIBM.SYSPROCEDURESのLUNAMEなど)、および認可または所有者ID (SYSIBM.SYSPROCEDURESのAUTHIDまたはSYSIBM.SYSROUTINESのOWNERなど)をサポートしているかどうかによって異なります。

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

一致規則では、最初にパブリック定義が検索され、次に所有者で修飾されたプロシージャ名が検索されます。 詳細については、DB2 SQLのIBM参照資料を参照してください。

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

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

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

• ゲートウェイは、DB2ストアド・プロシージャのGENERALとDB2SQLリンケージ・コンテナをサポートしています。 両方のリンケージ規則では、DB2ストアド・プロシージャとの間で受け渡されるパラメータをヌルにすることはできません。

結果セットとストアド・プロシージャ

Oracle Database Gateway for DRDAは、結果セットを返すストアド・プロシージャをサポートしています。 デフォルトでは、すべてのストアド・プロシージャおよびファンクションからユーザーに結果セットが戻されることはありません。 結果セットを使用可能にするには、初期化パラメータ・ファイルでHS_FDS_RESULTSET_SUPPORTパラメータを設定します。

関連項目:

初期化パラメータ・ファイルとHS_FDS_RESULTSET_SUPPORTパラメータの編集については、「初期化パラメータ」を参照してください。 Oracle以外のデータベースの結果セットに対するOracleサポートの詳細は、「Oracle Database異機種間接続ユーザーズ・ガイド」を参照してください。

注意:

HS_FDS_RESULTSET_SUPPORTゲートウェイ初期化パラメータを設定する場合は、既存のすべてのストアド・プロシージャのプロシージャexecute文の構文を変更するか、エラーが発生する必要があります。

Oracle Database Gateway for DRDAを使用して結果セットを含むストアド・プロシージャにアクセスすると、異機種間サービスの順次モードになります。 ゲートウェイは、プロシージャの説明の間、異機種間サービスに以下の情報を戻します:

• リモート・ストアド・プロシージャのすべての入力引数

• 出力引数はなし

• タイプがref cursorの1つの引数(ストアド・プロシージャから返される最初の結果セットに対応)

クライアント・プログラムは、仮想パッケージ関数DBMS_HS_RESULT_SET.GET_NEXT_RESULT_SETを使用して、後続の結果セットの参照カーソルを取得する必要があります。 最後に返された結果セットは、プロシージャからの出力引数です。

結果セットへのアクセスの制限は次のとおりです:

• リモート・ストアド・プロシージャによって返される結果セットは、ワイヤー上に置かれた順序で取得する必要があります。

• ストアド・プロシージャの実行時に、以前に実行されたストアド・プロシージャによって返されたすべての結果セットは、データが完全に取得されたかどうかにかかわらず閉じられます。

次の例では、UDBストアド・プロシージャを実行して、UDBからEMPおよびDEPT表の内容をフェッチします:

CREATE PROCEDURE REFCURPROC (IN STRIN VARCHAR(255), OUT STROUT VARCHAR(255) ) 
  RESULT SETS 3  LANGUAGE SQL 
BEGIN
  DECLARE TEMP CHAR (20); 
 DECLARE C1 CURSOR WITH RETURN TO CALLER FOR 
      SELECT * FROM TKHOEMP; 
  DECLARE C2 CURSOR WITH RETURN TO CALLER FOR 
     SELECT * FROM TKHODEPT; 
 OPEN C1; 
 OPEN C2; 
 SET STROUT = STRIN; 
 END

結果セットからのOCIプログラムの順次モードによるフェッチ

次の例は、結果セットから順次モードでフェッチするOCIプログラムを示しています:

OCIEnv *ENVH;
OCISvcCtx *SVCH;
OCIStmt *STMH;
OCIError *ERRH;
OCIBind *BNDH[3];
OraText arg1[20];
OraText arg2[255];
OCIResult *rset;
OCIStmt *rstmt;
ub2 rcode[3];
ub2 rlens[3];
sb2 inds[3];
OraText *stmt = (OraText *) "begin refcurproc@UDB(:1,:2,:3); end;";
OraText *n_rs_stm = (OraText *)
  "begin :ret := DBMS_HS_RESULT_SET.GET_NEXT_RESULT_SET@UDB; end;";
 
/* Prepare procedure call statement */
 
/* Handle Initialization code skipped */
OCIStmtPrepare(STMH, ERRH, stmt, strlen(stmt), OCI_NTV_SYNTAX, OCI_DEFAULT);
 
/* Bind procedure arguments */
inds[0] = 0;
strcpy((char *) arg1, "Hello World");
rlens[0] = strlen(arg1);
OCIBindByPos(STMH, &BNDH[0], ERRH, 1, (dvoid *) arg1, 20, SQLT_CHR,
             (dvoid *) &(inds[0]), &(rlens[0]), &(rcode[0]), 0, (ub4 *) 0, 
             OCI_DEFAULT);
 
inds[1] = -1;
OCIBindByPos(STMH, &BNDH[1], ERRH, 1, (dvoid *) arg2, 20, SQLT_CHR,
             (dvoid *) &(inds[1]), &(rlens[1]), &(rcode[1]), 0, (ub4 *) 0, 
             OCI_DEFAULT);
 
inds[2] = 0;
rlens[2] = 0;
OCIDescriptorAlloc(ENVH, (dvoid **) &rset, OCI_DTYPE_RSET, 0, (dvoid **) 0);
OCIBindByPos(STMH, &BNDH[2], ERRH, 2, (dvoid *) rset, 0, SQLT_RSET,
             (dvoid *) &(inds[2]), &(rlens[2]), &(rcode[2]),
             0, (ub4 *) 0, OCI_DEFAULT);
 
/* Execute procedure */
OCIStmtExecute(SVCH, STMH, ERRH, 1, 0, (CONST OCISnapshot *) 0,
               (OCISnapshot *) 0, OCI_DEFAULT);
 
/* Convert result set to statement handle */
OCIResultSetToStmt(rset, ERRH);
rstmt = (OCIStmt *) rset;
 
/* After this the user can fetch from rstmt */
/* Issue get_next_result_set call to get handle to next_result set */
/* Prepare Get next result set procedure call */
 
OCIStmtPrepare(STMH, ERRH, n_rs_stm, strlen(n_rs_stm), OCI_NTV_SYNTAX,
               OCI_DEFAULT);
 
/* Bind return value */
OCIBindByPos(STMH, &BNDH[1], ERRH, 1, (dvoid *) rset, 0, SQLT_RSET,
             (dvoid *) &(inds[1]), &(rlens[1]), &(rcode[1]),
             0, (ub4 *) 0, OCI_DEFAULT);
 
/* Execute statement to get next result set*/
OCIStmtExecute(SVCH, STMH, ERRH, 1, 0, (CONST OCISnapshot *) 0,
               (OCISnapshot *) 0, OCI_DEFAULT);
 
/* Convert next result set to statement handle */
OCIResultSetToStmt(rset, ERRH);
rstmt = (OCIStmt *) rset;
 
/* Now rstmt will point to the second result set returned by the
remote stored procedure */
 
/* Repeat execution of get_next_result_set to get the output arguments */

順次モードでの結果セットからのPL/SQLプログラムのフェッチ

表LOC_EMPは、「UDB EMP」表とまったく同じローカル表であるとします。 同じ仮定がLOC_DEPTに適用されます。 OUTARGSは、SQL Serverストアド・プロシージャのout引数に対応する列を持つ表です。

create or replace package rcpackage is  type RCTYPE is ref cursor;end rcpackage;/
declare
  rc1 rcpackage.rctype;
  rec1 loc_emp%rowtype;
  rc2 rcpackage.rctype;
  rec2 loc_dept%rowtype;
  rc3 rcpackage.rctype;
  rec3 outargs%rowtype;
  out_arg varchar2(255);
 
begin
 
  -- Execute procedure
  out_arg := null;
  refcurproc@UDB('Hello World', out_arg, rc1);
 
  -- Fetch 20 rows from the remote emp table and insert them into loc_emp
  for i in 1 .. 20 loop
    fetch rc1 into rec1;
    insert into loc_emp (rec1.empno, rec1.ename, rec1.job,
    rec1.mgr, rec1.hiredate, rec1.sal, rec1.comm, rec1.deptno);
  end loop;
 
  -- Close ref cursor
  close rc1;
 
  -- Get the next result set returned by the stored procedure
  rc2 := dbms_hs_result_set.get_next_result_set@UDB;
 
  -- Fetch 5 rows from the remote dept table and insert them into loc_dept
  for i in 1 .. 5 loop
    fetch rc2 into rec2;
    insert into loc_dept values (rec2.deptno, rec2.dname, rec2.loc);
  end loop;
 
  --Close ref cursor
  close rc2;
 
  -- Get the output arguments from the remote stored procedure
  -- Since we are in sequential mode, they will be returned in the
  -- form of a result set
  rc3 := dbms_hs_result_set.get_next_result_set@UDB;
 
  -- Fetch them and insert them into the outarguments table
  fetch rc3 into rec3;
  insert into outargs (rec3.outarg, rec3.retval);
 
  -- Close ref cursor
  close rc3;
 
end;
/

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

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

Oracle DatabaseのSQL構文の処理

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

• 互換型

• 変換型

• 補正型

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

互換型SQL関数

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

変換型SQL関数

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

補正型SQL関数

Oracleデータベースでサポートされている一部の高度なSQL構成は、DRDAデータベースによって同じ方法でサポートされない場合があります。 Compensated関数は、DRDAサーバーで認識されない、またはDRDAサーバーによって認識されるSQL関数ですが、DRDAサーバーとOracleデータベースを比較するときには、関数のセマンティクスが異なって解釈されます。 これらの関数のいずれかを含むSELECT文がOracle Databaseからゲートウェイに渡されると、ゲートウェイではSQL文をDRDAサーバーに渡す前にその関数を削除します。 ゲートウェイは、選択されたDRDAデータベースの行をOracle Databaseに渡します。 Oracle Databaseは、その関数を適用します。

後処理

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

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

SELECT COS(X_COOR) FROM TABLE_X;

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

SELECT X_COOR FROM TABLE_X;

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

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

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

通常補正される一部のSQL関数は、ネイティブ・セマンティクス機能を通じて上書きすることも可能です。 ネイティブ・セマンティクスでSQL関数が使用可能になっている場合、その関数は、補償される代わりに、処理のためにDRDAデータベースに渡されます。 SQL関数は、DRDAデータベースでネイティブに処理されます。 詳細については、「"ネイティブ・セマンティクス"」を参照してください。

DB2 UDB for z/OS SQL互換性

「表4-1」は、Oracleデータベースとゲートウェイがz/OS用のDB2 UDBの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	はい	-	-	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	-	STRIP	はい	はい
TRUNC	-	-	はい	はい
UID	-	-	はい	-
UPPER	はい	-	-	UCASE
USER	-	-	はい	-
USERENV	-	-	はい	-
VARIANCE	-	-	はい	はい
VSIZE	-	-	はい	はい

DB2 UDB for UNIX、Linux、およびWindowsの互換性

「表4-2」は、OracleデータベースとゲートウェイがDB2/UDBデータベースのSQL関数をどのように処理するかを示します。

表4-2 DB2 UDB for UNIX、Linux、およびWindowsの互換性(Oracle 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 (すべての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	-	-	はい	はい

DB2 UDB for iSeriesの互換性

「表4-3」は、DB2 UDB for iSeriesデータベースのOracleデータベースおよびゲートウェイがSQL関数をどのように処理するかを説明します。

表4-3 DB2 UDB for iSeriesとの互換性、Oracle 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 (すべての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	はい	-	v	-
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	はい	v	-	はい
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	-	UCASE
USER	-	-	はい	-
USERENV	-	-	はい	-
VARIANCE	-	VAR	-	はい
VSIZE	-	-	はい	はい

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

Oracleデータベースでサポートされている高度なSQL構成の一部は、DRDAデータベースによって同じようにサポートされない場合があります。 この場合、Oracleデータベースは、Oracleデータベース機能を使用してDRDAデータベース・データを後処理することによって、欠落しているか互換性のない機能を補う

関連項目:

「"Oracle Database SQL構文処理"」詳細については、

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

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

ネイティブ・セマンティクスに関する考慮事項

特定の関数でネイティブ・セマンティクス機能を有効化する場合、ネイティブ・セマンティクスには一般的に透過性とパフォーマンスのトレードオフ関係に対応するメリットおよびデメリットが存在するため、様々なことを考慮する必要があります。

• このような考慮事項の1つとして、データ強制変換の透過性があげられます。 Oracle Databaseでは、多くのSQL関数について強制変換(暗黙的データ変換)が行われます。 つまり、特定の関数に対して指定された値が正しくない場合、その値は処理の前にOracle Databaseによって強制的に変換されます(正しい値タイプに変更されます)。 ただし、ネイティブ・セマンティック機能を有効にすると、提供されたとおりの値が処理のためにDRDAサーバーに渡されます。 多くの場合、DRDAサーバーでは値を正しいタイプに強制変換できないため、エラーが発生します。

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

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

これらの機能を有効または無効にする方法の詳細については、"HS_FDS_CAPABILITY"を参照してください。 Oracleデータベース形式の場合は、「Oracle Database SQL言語リファレンス」の次の機能を参照してください。

有効化可能なSQL関数

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

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

無効化可能なSQL関数

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

• GROUPBY

• HAVING

• ORDERBY

• WHERE

ORDERBYにより、ソート順序が制御されます(ソート順序は様々なソートの場所に応じて変化します)。 たとえば、ORDERBY ONでは、DB2ソートは拡張バイナリ・コード10進インター・チェンジ・コード (EBCDIC)ソート順)に基づいていますが、ORDERBY OFFではOracleデータベース・ソートはASCIIソート順に基づいています。

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

SQLの集合演算子および句

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

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

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

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

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

表4-4 データ型のマッピングと制限

DRDAサーバー	Oracle外部データ型	基準	Oracleが大きなvarchar (32k)を使用する場合
CHAR(N)	CHAR(N)	N < = 2000
VARCHAR (N)	VARCHAR2(N) LONG	N < = 4000 4000 < N	N <= 32767 32767 < N
LONG VARCHAR(N)	VARCHAR2(N)	N 4000	N <= 32767
LONG VARCHAR(N)	LONG	4000 < N	32767 < N
CHAR(N) FOR BIT DATA	RAW(N)	N 255
VARCHAR(N) FOR BIT DATA	RAW(N)	1 N 2000	1 <= N <= 32767
VARCHAR(N) FOR BIT DATA	LONG RAW	2000 < N	N < 32767
LONG VARCHAR(N) FOR BIT DATA	RAW(N)	1 <= N <= 2000	1 <= N <= 32767
LONG VARCHAR(N) FOR BIT DATA	LONG RAW	2000 < N	N < 32767
DATE	DATE	日付および時刻操作の実行 を参照
TIME	CHAR(8)	日付および時刻操作の実行 を参照
TIMESTAMP	CHAR(26)	日付および時刻操作の実行 を参照
GRAPHIC	CHAR(2N)	N <= 1000
VARGRAPHIC	VARCHAR2(2N) LONG	N <= 2000 2000 <= N	N <= 16370 16370 < N
LONG VARGRAPHIC	VARCHAR2(2N) LONG	N <= 2000 2000 < N	N <=16370 16370 < N
単精度浮動小数点数	FLOAT(24)	該当なし
倍精度浮動小数点数	FLOAT(53)	該当なし
小数 (P, S)	NUMBER(P,S)	該当なし
CLOB	LONG	該当なし
BLOB	LONG RAW(N)	該当なし
DBLOB	LONG	該当なし
SMALLINT	NUMBER(5)	該当なし
INTEGER	NUMBER(10)	該当なし

文字列操作の実行

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

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

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

文字列データ型の変換

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

Oracleデータベースが32767の最大VARCHAR2サイズを使用するように構成されている場合、DRDA VARCHARデータ型は1と32767文字の間になることができます。 それ以外の場合は、制限は4000です。 DRDA VARCHARデータ型がOracleが構成したVARCHAR2制限サイズより大きい場合は、Oracle LONGデータ型に変換されます。

DB2 VARCHARデータ型は、32767バイトを超えることはできません。これは、Oracle LONGデータ型の最大サイズよりもはるかに短くなります。 長さが32767バイトより大きいOracle LONGデータ型を定義すると、DB2 VARCHARデータ型にマップされたときにエラー・メッセージが表示されます。

GRAPHIC文字列操作の実行

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

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

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

日付および時刻データの実装は、IBM DRDAデータベースとOracle Databaseでは大きく異なります。 Oracleデータベースには、1つの日付 データ型DATEがあり、カレンダの日付と時間情報の両方を含むことができます。

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

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

TIMEは、時刻専用です。

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

TIMEおよびTIMESTAMPデータの処理

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

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

DATEデータの処理

OracleおよびIBMのDATEデータ型は、相互にマップされます。 IBMのDATEが照会された場合、は0 (真夜中)の時間でOracle DATEに変換されます。 Oracle DATEがIBM 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のアクセス対象データ・ストア間で移植可能です。

挿入値以外の日付リテラルは、処理のためにDB2に送信する前にOracle NLS_DATE_FORMATと一致するかどうかがチェックされます。 TG4DB2 v10.2は、NLS_DATE_FORMAT形式と一致するかどうかをチェックしません。 このような互換性が必要な場合は、HS_FDS_CAPABILITYパラメータの一部としてNODATECHK/ONの値を指定する必要があります。 次に、DB2で使用可能な任意の日付形式を使用できます:

• YYYY-MM-DD (ISO/JIS)

• DD.MM.YYYY(ヨーロッパ)

• MM/DD/YYYY(USA)

次に例を示します。

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

同様に、Oracleの7バイト・バイナリ日付形式である入力バインド変数についても、TO_DATEは必要ありません。 これらの値は、ゲートウェイで日付として認識されます。 DB2 UDB for z/OSの場合、提供されたDATE EXITゲートウェイをインストールすると、2つの追加のOracle日付形式を使用することもできます: DD-MON-RRおよびDD-MON-YYYY

日付の計算の実行

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

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

日付と番号の加算と減算 (date + number,number + date,date - number) フォームは、DRDAサーバーに送信され、そこで拒否されます。 サポート対象のサーバーでは、日付に対する数値の加算または減算は許可されません。

サポートされているサーバーでは、日付の減算の解釈が異なるため、2つの日付を減算すると、サーバーによって異なる結果が得られます。

注意:

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

日付

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

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

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

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

• TO_DATE関数

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

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

• NLS_DATE_FORMATパラメータ

  ALTER SESSION SET NLS_DATE_FORMATを使用して、SQLで使用される日付形式を設定する必要があります。

NLS_DATE_FORMATのサポート

次の表に、ALTER SESSION SET NLS_DATE_FORMATの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 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';

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) 関数形式はサポートされていません。

Oracle TO_DATE関数の単純な値への前処理は、INSERT VALUES句で有効です。これは、DB2が VALUES clauseの関数を許可しないためです。 この場合、DB2では、VALUESリストに単純な値を取得します。 1つ、2つまたは3つのオペランドを含むすべての形式のTO_DATE関数がサポートされます。

数値データ型操作の実行

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

たとえば、 PRICE がIBM DRDAデータベース内の PRODUCT 表の整数列である場合、次の例に示す更新は、アイスクリーム・コーンの価格を$1.00に不正確に設定します。IBM DRDAサーバーは浮動小数点を自動的に整数:

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

PRICE は整数なので、IBM DRDAサーバーは1.50の10進データ値を自動的に1に変換します。

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関数のサポートを示すこともできます:

HS_FDS_CAPABILITY=(COUNTCOL=YES)

すべての形式のCOUNTをサポートしていない既知のDRDAサーバーについては、「SQLの制限」を参照してください。

ゾーン10進数操作の実行

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

ゲートウェイを通じたネイティブ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の実行に使用されます。

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

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

上記のとおり、DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATE 関数によって処理されるSQL文は、Oracleデータベースによって解釈されません。 その結果、Oracleデータベースは、そのような文がDRDAサーバーを変更しているかどうかを認識しません。 つまり、DRDAサーバーの変更後にOracleデータベースのキャッシュされた情報を最新の状態に保たない限り、データベースは同じセッション内の後続の問合せで不正確または古い情報に依然として依存する可能性があります。

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

Oracleデータベースが新しい形式の表を取得するには、ゲートウェイとの既存のセッションを閉じて、新しいセッションを開く必要があります。 これを行うには、次の2つの方法があります。

• Oracleデータベースでアプリケーション・セッションを終了し、DRDAサーバーに変更が加えられた後で新しいセッションを開始する。または

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

上記のアクションのいずれかがキャッシュされた表定義を無効にし、Oracleデータベースに次の参照時に新しい定義を取得させます。

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を除く)。 文にバインド変数を含めることはできません。 DRDAサーバーは、動的に準備できないネイティブSQL文を拒否します。 DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATEファンクションにより渡されるSQL文は、文字列である必要があります。 有効なSQL文の詳細は、特定のDRDAサーバーのSQLリファレンスを参照してください。

例

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;
   /

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

Oracle Database Gateway for DRDAには、パススルーを通じて入力されたSELECT SQL文から結果セットを取得する機能があります。 詳細については、「Oracle Database異機種間接続ユーザーズ・ガイド」を参照してください。

例

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;
/ 

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

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

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

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

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

DRDAカタログの使用

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