|
|
この章では、ファイルをソースDB2データベースからターゲットOracleデータベースへ移行するために、Rehosting Workbench DB2-to-Oracleコンバータをインストール、実装および構成する方法を説明します。
DB2を移行する場合、COBOL、JCL、z/OSユーティリティ、DB2およびOracleデータベースと、UNIX/Linux Kornシェルの知識が必要です。
移行プロセスの包括的な視点については、Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイドのデータ変換およびCOBOL変換の章とCOBOL変換の章を参照してください。
z/OS DB2ソース・プラットフォームからOracle UNIXターゲット・プラットフォームへ移行する時の最初の問題は、どの表を移行するべきかということです。すべてのDB2表を移行するわけではない場合、移行するオブジェクトのサブセットを示すDB2 DDLを作成する必要があります。
この章で詳しく説明する、DB2からOracleへの移行プロセスの原則的な手順は次のとおりです。
DB2からOracleへの移行はカタロガの結果に依存します。DB2からOracleへの移行はCOBOL変換に影響を与えるので、プログラムの変換作業の開始前に完了する必要があります。
この項では、DB2データベースからOracleデータベースへデータを移行するときに、Rehosting Workbenchにより適用されるリエンジニアリング・ルールについて説明します。
Oracleへの移行に含まれるDB2オブジェクトのリストは生成されたOracleオブジェクトの作成で説明します。
Rehosting Workbenchの名前の変更ルールの適用を除き、Oracleへの移行時に、移行されたDB2オブジェクトの名前は保持されます(名前の変更ルールの準備および実装を参照)。
列プロパティによりアプリケーション・プログラムの動作を変更できます。
次の表にすべてのDB2の列プロパティと、ターゲットOracleデータベース用に変換する方法を示します。
Oracle Tuxedo Application Rehosting Workbenchでは、DDLソース・ファイル内の様々な名前(表名、列名)を変更できます。
| 注: | Rehosting Workbenchの実行時に、Oracleの予約語がDDLソースに見つからない場合、エラーが報告され、Rehosting WorkbenchはDDLの分析を続行します。 |
名前の変更ルールはrename-objects-<スキーマ名>.txt.という名前のファイルに置かれます。このファイルは$PARAM/rdbmsパラメータで示されたディレクトリに置かれます。
% Modification applied to the AUALPH0T table
column;AUANPR0U;AUALPH0T;NUM_ALPHA;MW_NUM_ALPHA
この例では、DB2 DDLに、主キーおよびXCUSTIDENという名前の一意の索引を持つ、ODCSF0という名前の表が含まれます。
DROP TABLE ODCSF0;
COMMIT;
CREATE TABLE ODCSF0
(CUSTIDENT DECIMAL(6, 0) NOT NULL,
CUSTLNAME CHAR(030) NOT NULL,
CUSTFNAME CHAR(020) NOT NULL,
CUSTADDRS CHAR(030) NOT NULL,
CUSTCITY CHAR(020) NOT NULL,
CUSTSTATE CHAR(002) NOT NULL,
CUSTBDATE DATE NOT NULL,
CUSTEMAIL CHAR(040) NOT NULL,
CUSTPHONE CHAR(010) NOT NULL,
PRIMARY KEY(CUSTIDENT))
IN DBPJ01A.TSPJ01A
CCSID EBCDIC;
COMMIT;
CREATE UNIQUE INDEX XCUSTIDEN
ON ODCSF0
(CUSTIDENT ASC) USING STOGROUP SGPJ01A;
COMMIT;
移行ルールの適用後、名前の変更ルールを実装せずに、次のOracleオブジェクトが取得されます。
WHENEVER SQLERROR CONTINUE;
DROP TABLE ODCSF0 CASCADE CONSTRAINTS;
WHENEVER SQLERROR EXIT 3;
CREATE TABLE ODCSF0 (
CUSTIDENT NUMBER(6) NOT NULL,
CUSTLNAME CHAR(30) NOT NULL,
CUSTFNAME CHAR(20) NOT NULL,
CUSTADDRS CHAR(30) NOT NULL,
CUSTCITY CHAR(20) NOT NULL,
CUSTSTATE CHAR(2) NOT NULL,
CUSTBDATE DATE NOT NULL,
CUSTEMAIL CHAR(40) NOT NULL,
CUSTPHONE CHAR(10) NOT NULL);
WHENEVER SQLERROR CONTINUE;
DROP INDEX XCUSTIDEN;
WHENEVER SQLERROR EXIT 3;
CREATE UNIQUE INDEX XCUSTIDEN ON ODCSF0
(
CUSTIDENT ASC
);
WHENEVER SQLERROR CONTINUE;
ALTER TABLE ODCSF0 DROP CONSTRAINT CONSTRAINT_01;
WHENEVER SQLERROR EXIT 3;
ALTER TABLE ODCSF0 ADD
CONSTRAINT CONSTRAINT_01 PRIMARY KEY (CUSTIDENT);
この項では、DB2データをOracleに移行するのに使用するコンポーネントを生成する前に実行するタスクについて説明します。
移行するDB2 DDLソース・ファイルがカタログ操作の準備前に検出されます。移行プロセス中に、SQL CREATEコマンドだけが処理されOracleに移行されますが、すべての有効なDB2構文が受け入れられます。
DB2からOracleへの移行では、すべてのRehosting Workbenchツールで使用するsystem.desc システム記述ファイルに、パラメータを設定する必要があります。
スキーマは一貫性のあるオブジェクトのセットから構成される必要があります(たとえば、スキーマに存在しない表に対してのCREATE INDEXはありません)。
デフォルトでは、DB2 DDLのSQLコマンドに修飾子または認可識別子の接頭辞が付く場合(たとえばCREATE TABLE <修飾子または認可識別子>.表名)、この接頭辞はRehosting Workbenchによりスキーマ名として使用されます。
スキーマ名は、 system.descファイルのglobal-options句を使用して、Rehosting Workbenchが決定することもできます。
system STDB2ORA root ".."
global-options
catalog="..",
sql-schema=<schema name>.
また、各DDLディレクトリのスキーマ名は、system.descファイルのdirectory options句を使用してRehosting Workbenchが決定することもできます。「カタロガ」の章の「オプション句」の項を参照してください。
directory "DDL" type SQL-SCRIPT
files "*.sql"
options SQL-Schema = "<schema name>".
次の1つのファイルだけは$PARAMで記述されたRehosting Workbenchのファイル構造に置く必要があります。
これらのファイルはRehosting Workbenchのインストール時にファイル構造に自動的に生成されます。これらのファイルの特定のバージョンが必要な場合は、PARAM/rdbmsファイル構造に置かれます。
Rehosting Workbenchの実行前に次の環境変数を設定します。
#
# This configuration file is used by FILE & RDBMS converter
# Lines beginning by "#" are ignored
# write information in lower case
#
# common parameters for FILE and RDBMS
# source information is written into system descriptor file (OS, DBMS=, # DBMS-VERSION=)target_rdbms_name:oracle
target_rdbms_version:11
target_os:unix
#
# specific parameters for FILE to RDBMS conversion
file:char_limit_until_varchar:29
# specific parameters for RDBMS conversion
rdbms:date_format:YYYY/MM/DD
rdbms:timestamp_format:YYYY/MM/DD HH24 MI SS FF6
rdbms:time_format:HH24 MI SS
# rename object files
# the file param/rdbms/rename-objects-<schema>.txt is automatically loaded by # the tool if it exists.
パラメータtarget_<xxxxx>およびrdbms:<xxxxx>だけが適用される必要があります。
3つのrdbmsパラメータは、z/OS DB2により使用され、DSNZPARMに格納される日付、タイムスタンプおよび時間形式を示します。これらのパラメータは再ロード操作およびCOBOL日付および時間の操作に影響を与えます。
| 警告: | これらのパラメータを適切に設定することは重要です。 |
データのDB2データベースからOracleデータベースへの移行に使用されるコンポーネントを生成するのに、Rehosting Workbenchはrdbms.shコマンドを使用します。この項ではこのコマンドについて説明します。
rdbms.sh - DB2からOracleデータベースへの移行コンポーネントを生成。
rdbms.sh [ [-c|-C] [-g] [-m] [-r] [-i <installation directory>] <schema name> ] -s <installation directory> (<schema name>,...) ]
rdbms.shはz/OS DB2データベースのUNIX Oracleデータベースへの移行に使用されるRehosting Workbenchコンポーネントを生成します。
mapper.reおよびDatamap.re)。エラーまたは警告が発生してもプロセスは異常終了しません。
config-cobolファイル(COBOL変換構成ファイル)にある、オプションsql-remove-schema-qualifierを使用して、スキーマ名もCOBOLコンポーネントから削除できます。
$PARAM/dynamic-configに作成されます。
rdbms.sh -Cgrmi $HOME/trf PJ01DB2
Makeはターゲット(ファイルまたはアクション)の構成を自動化および最適化することを目的としたUNIXユーティリティです。
すべての操作が実装されるソース・ディレクトリにmakefileという名前の記述子ファイルが存在する必要があります(makefileはプロジェクトの初期化中にソース・ディレクトリに準備されます)。
次の2つの項では、Makeファイルの構成と、 Makeファイルを使用したRehosting Workbench DB2-To-Oracleコンバータ機能の使用方法について説明します。
$PARAMのversion.mk構成ファイルを使用して、Makeユーティリティで必要な変数およびパラメータを設定します。
version.mkには、各種のコンポーネントがインストールされる場所とその拡張を、使用される様々なツールのバージョンとともに指定します。このファイルにはログ・ファイルの編成方法も記述します。
次の一般的な変数を、version.mkファイルでの移行プロセスの最初に設定する必要があります。
また、RDBMS_SCHEMAS変数はDB2の移行に特有で、処理する様々なスキーマを示します。
この構成はMakeファイルの使用の前に完了する必要があります。
makefileおよびversion.mkファイルはRehosting Workbench Simple Applicationとともに提供されます。
make RdbmsConvert コマンドを使用してRehosting Workbench DB2-To-Oracleコンバータを起動できます。これによりDB2データベースからOracleへの移行に必要なコンポーネントを生成できます。
Makeファイルは rdbms.shツールを、-C、-g、-r、-mおよび-iオプションを使用して、RDBMS_SCHEMAS変数に含まれるすべてのスキーマに対して起動できます。
-i $HOME/trfオプションを使用して生成されたアンロードおよびロード・コンポーネントは次の場所に置かれます。
Oracleオブジェクトを作成するのに使用されるSQLスクリプトの<スキーマ名>による場所。この章で使用される例では、次の3つのスクリプトがあります。 |
|
SQL*LOADERにより使用されるCTLファイルの<スキーマ名>による場所。この章の例では、次の1つのCTLがあります。 |
|
生成されたコンポーネントはプロジェクトの固有のスクリプトを使用して変更できます。これらのスクリプト(sed、awk、 perlなど)は次の場所に置かれる必要があります。
$PARAM/rdbms/rdbms-modif-source.sh
あれば、このファイルは生成プロセスの最後に自動的に実行されます。引数として、<スキーマ名>を使用して呼び出されます。
この項では、Rehosting Workbenchを使用して生成されたコンポーネント(コンポーネントの生成を参照)を使用する、アンロード、転送および再ロードのタスクについて説明します。
アンロードに使用されるコンポーネント($HOME/trf/unload/rdbmsに生成)は、ソースz/OSプラットフォームにインストールする必要があります。生成されたJCLは、JOBカード、ライブラリ・アクセス・パス、入力および出力ファイル(データ・セット名: DSN)へのアクセス・パスを含む、特定のサイトの制約への適合が必要な場合があります。
再ロードに使用されるコンポーネント($HOME/trf/reload/rdbmsに生成)はターゲット・プラットフォームにインストールする必要があります(実行時)。
表4-4は、ターゲット・プラットフォームに設定する必要がある環境変数を示しています。
次の変数はOracle Tuxedo Application Rehosting Workbenchのインストレーション・ガイドの情報に従って設定する必要があります。
再ロード・スクリプトloadrdbms-<表名>.kshはSQL*LDR Oracleユーティリティを使用します。このユーティリティがアクセスできるのはORACLEサーバーに限られるため、このスクリプトはORACLEサーバーで使用する必要があり、クライアント接続では使用できません。特にこの再ロード手順では、この変数に@<oracle_sid>文字列を含めることはできません。
COBOLプログラムによって呼び出されるパッケージの機能(Oracle Tuxedo Application Rehosting Workbench COBOLコンバータによって変換)をターゲット・プラットフォーム(ランタイム)にインストールする必要があります。
パッケージは、REFINEDIR/convert-data/fixed-components/MWDB2ORA.plbに配置されます。このパッケージは、Oracle Tuxedo Application Rehosting Workbench DB2 to Oracleコンバータで説明されているように、SQLPLUSの下にインストールする必要があります。
各DB2表をアンロードするには、IBM DSNTIAULユーティリティを使用するJCLを実行します。DSNTIAULユーティリティは各表に対し次の3つのファイルを生成します。
これらのアンロードJCLの名前は<表名>.jclunloadです。
表名が8文字よりも短いまたは長い場合、Rehosting Workbenchはできるだけ元の名前に近い8文字の名前をz/OS JCLの名前とみなします。この名前の変更プロセスにより各表名の一意性が保たれます。
この章で使用される例では、ODCSF0という表名が、z/OS JCLの名前を付けるときにODCSF0X1に伸ばされます。
アンロードされたデータ・ファイルは、サイトで使用可能なファイル転送ツール(CFT、FTPなど)を使用して、バイナリ形式で、ソースz/OSプラットフォームとターゲットUNIXプラットフォーム間で転送される必要があります。
LOGおよびSYSPUNCHファイルはテキスト・モードで転送される必要があります。
ターゲットUNIXプラットフォームに転送されたファイルは$DATA_SOURCEディレクトリに格納される必要があります。
Oracleオブジェクト(表、索引、制約など)を作成するスクリプトは$HOME/trf/SQL/rdbms/<スキーマ名>ディレクトリに作成されます。これらはターゲットOracleインスタンスで実行される必要があります。
<スキーマ名>.lstファイルにはすべての表の名前が階層的な順序で(親表の次に子表)含まれます。
表4-5にRehosting Workbenchで管理されるDB2オブジェクトとそれを作成するために使用するスクリプトの名前をリストします。
トランスコードに使用される生成されたCOBOLプログラムの名前は次のとおりです。
この章で使用される生成されたプログラムの例は次のとおりです。
このプログラムはMicrofocus COBOLまたはCOBOL-IT、およびOracle Tuxedo Application Rehosting Workbenchリファレンス・ガイドに記載されたオプションを使用してコンパイルされる必要があります。
このプログラムは出力時にRECORD SEQUENTIALファイルを生成し、それは次にSQL*LOADERユーティリティに読み取られます。
SELECT MW-SORTIE
ASSIGN TO "SORTIE"
ORGANIZATION IS RECORD SEQUENTIAL
ACCESS IS SEQUENTIAL
FILE STATUS IS IO-STATUS.
データのトランスコードおよび再ロードを可能にするスクリプトは次のディレクトリに生成されます。
$HOME/trf/reload/rdbms/<schema name>/ksh
loadrdbms-<table name>.kshloadrdbms-ODCSF0.ksh
各スクリプトはトランスコードを実行し次にSQL*LOADERユーティリティを実行するCOBOLプログラムを起動します。SQL*LOADERにより使用されるCTLファイルの名前は次のとおりです。
<table name>.ctl.この章の例で使用されるCTLファイルの名前は次のとおりです。
ODCSF0.ctl
トランスコードおよび再ロード・スクリプトには次のパラメータがあります。
loadrdbms-<table name>.ksh [-t] [-l] [-c: <method>]
DB2オブジェクトの移行の例での例で、生成されるスクリプトは次のとおりです。
この確認は loadrdbms-<表名>.kshの次のオプションを使用します。
-c dsntiaul
| 注: | このオプションは、再ロード後、再ロードされたOracle表に、DSNTIAULユーティリティによりz/OSからアンロードされた等価の表と同じレコード数が含まれていることを検証します。レコード数が異なる場合、エラー・メッセージが生成されます。 |
この項では、データをDB2データベースからターゲットOracleデータベースへ移行するときに発生した使用エラーにより生じる問題について説明します。
Rehosting Workbenchツールを実行するときに、ユーザーは次のことを確認する必要があります。
rdbms-converter-<スキーマ名>.logファイルにエラーが含まれているか(共通の問題と解決策を参照)。エラー・メッセージと関連する説明はOracle Tuxedo Application Rehosting Workbenchリファレンス・ガイドの付録にリストされています。
Fatal RDBMS error.
Error: RDBMS-0105: Catalog for /home2/wkb9/param/system.desc is out of date
and needs to be updated externally.
Refine error...
Refine error...
/tmp/refine-exit-status.MOaZwgTphIN14075
ERROR : conversion aborted . Can not read /home2/wkb9/tmp/outputs/SCHEMA/rdbms-converter-SCHEMA.log log file
abort
*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=--=-
#########################################################################
CONVERSION OF DDLs and CTL files and GENERATION of directive files
ERROR : Configuration file /db-param.cfg is missing !
ERROR : Error in reading configuration file
Abort
*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-
Target output directory /home2/wkb9/bad-directory is missing
Check parameters: -i <output_directory> <schema>
ERROR : usage : rdbms.sh [ [-c|-C] [-g] [-m] [-r] [-i <output_directory>] <schema_name> ] -s <output_directory> (<schema>,...) ]
abort
  
|