|
|
この章では、ファイルをソース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-<schema name>.txt.という名前のファイルに置かれます。このファイルは$PARAM/rdbmsパラメータで示されたディレクトリに置かれます。
% Modification applied to the AUALPH0T table
column;AUANPR0U;AUALPH0T;NUM_ALPHA;MW_NUM_ALPHA
Oracle Tuxedo Application Rehosting Workbenchでは、CLOBおよびBLOBデータ型をダウンロードできます。DB2アンロード・ユーティリティは、CLOB列またはBLOB列の各行を別個のファイルにダウンロードします(PDSまたはHFSデータセット・タイプ)。このユーティリティ(DSNUTILB)は、すべての列のデータおよびNULLテクニカル・フラグを一意のMVSメンバー・ファイルにダウンロードします。ただし、個別のCLOBまたはBLOBファイルのファイル名で置き換えられるCLOBまたはBLOB列は除きます。
MVSシステム構成によっては、PDSデータセット・タイプで一部のファイルが許可されないため、CLOBまたはBLOB列のダウンロードに別のデータセット・タイプを選択しなければならないこともあります。
この2つの制約に基づいて、db-param.cfg構成ファイルで正しいパラメータを設定する必要があります(「構成ファイルの実装」を参照)。
Oracle Tuxedo Application Rehosting Workbenchでは、シングル・バイト・データのトランスコーディングが提供されています。ただし、DB2データにMBCS文字が含まれる場合は、DSNUPROCアンロード・ユーティリティを選択してcsvデータ形式を設定する必要があります。MBCSトランスコーディングは、転送ツールによって行われます。
この制約に基づいて、db-param.cfg構成ファイルで正しいパラメータを設定する必要があります(「構成ファイルの実装」を参照)。
この例では、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
# optional parameter
target_cobol:cobol_mf
#
# 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
rdbms:lobs_fname_length:75
rdbms:jcl_unload_lob_file_system:pds
rdbms:jcl_unload_utility_name:dsnutilb
#rdbms:jcl_unload_format_file:csv
# rename object files
# the file param/rdbms/rename-objects-<schema>.txt is automatically loaded by # the tool if it exists.
パラメータtarget_<xxxxx>およびrdbms:<xxxxx>だけが適用される必要があります。
COBOL言語の名前許容値は"cobol_mf"(デフォルト値)および"cobol_it"です。
次のrdbmsパラメータは、z/OS DB2により使用され、DSNZPARMに格納される日付、タイムスタンプおよび時間形式を示します。
これらのパラメータは再ロード操作およびCOBOLの日付および時間の操作に影響を与えます。これらはオプションで、DB2データベースにDATE、TIMEまたはTIMESTAMPフィールドが含まれる場合のみ必要です。
| 警告: | これらのパラメータを正しく設定することが重要です。 |
次のrdbmsパラメータはオプションで、DB2スキーマにCLOBまたはBLOBデータ型が含まれる場合にのみ必要です。
| 警告: | これらのパラメータを正しく設定することが重要です。 |
rdbms:jcl_unload_lob_file_system:pds / hfsPDSで作成できるメンバー・ファイル数は制限されています。DB2アンロード・ユーティリティはCLOB/BLOB列ごとに新しいメンバー・ファイルを作成するため、PDSデータセット・タイプで作成できる最大LOBSファイル数を超えることがあり、その場合はHFSデータセット・タイプを選択する必要があります。詳細は、DB2 MVSの管理者に問い合せてください。デフォルトでは、"pds"を使用します。
rdbms:lobs_fname_length:75DB2アンロード用JCLによって表データ・ファイルに書き込まれるCLOBまたはBLOBファイル名の最大長を計算する必要があります。
| 注意: | rdbms:jcl_unload_utility_nameパラメータには、値"dsnutilb"を設定する必要があります。 |
MVSにDB2アンロード・ユーティリティがあるかどうかによって、値を変更することもできます。
| 注意: |
データの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コンポーネントを生成します。
$TMPPROJECTに生成されます: DDL Oracle、SQL*LOADERのCTLファイル、COBOLコンバータで使用されるXMLファイル、構成ファイル(mapper.reおよびDatamap.re)。エラーまたは警告が発生してもプロセスは中断しません。
$TMPPROJECTに生成します。このオプションの前に-Cまたは-cコマンドを指定してrdbms.shコマンドを実行する必要があります。
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オプションで生成されるアンロード・コンポーネントおよびロード・コンポーネントは、次の場所に配置されます。
生成されたコンポーネントはプロジェクト固有のスクリプトを使用して変更できます。これらのスクリプト(sed、awk、 perlなど)は次の場所に配置する必要があります。
$PARAM/rdbms/rdbms-modif-source.sh
このファイルが存在している場合、生成プロセスの最後に自動的に実行されます。これは、引数として<schema name>を使用して呼び出されます。
この項では、Rehosting Workbenchを使用して生成されたコンポーネント(コンポーネントの生成を参照)を使用する、アンロード、転送および再ロードのタスクについて説明します。
アンロードに使用されるコンポーネント($HOME/trf/unload/rdbmsに生成)は、ソースz/OSプラットフォームにインストールする必要があります。生成されたJCLは、JOBカード、ライブラリ・アクセス・パス、入力および出力ファイル(データ・セット名: DSN)へのアクセス・パスを含む、特定のサイトの制約への適合が必要な場合があります。
再ロードに使用されるコンポーネント($HOME/trf/reload/rdbmsに生成)はターゲット・プラットフォームにインストールする必要があります(実行時)。
表4-4は、ターゲット・プラットフォームに設定する必要がある環境変数を示しています。
|
|||
『Oracle Tuxedo Application Rehosting Workbenchリファレンス・ガイド』およびその他のOracleドキュメントの説明に従って設定します。
|
次の変数は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およびREFINEDIR/convert-data/fixed-components/MWDB2ORA_CONST.plbに配置されます。MWDB2ORA_CONST.plbパッケージを変更して、これらのパッケージを「Oracle Tuxedo Application Rehosting Workbench DB2 to Oracleコンバータ」に説明されいるようSQLPLUSの下にインストールする必要があります。
各DB2表をアンロードするには、IBMアンロード・ユーティリティを使用するJCLを実行します。通常、アンロード・ユーティリティによって各表に3つのファイルが作成されます。
表にCLOBまたはBLOBデータ型が含まれる場合、アンロード・ユーティリティで次が作成されます。
これらのアンロード用JCLの名前は<表名>.jclunloadです。
表名が8文字よりも長い場合、Rehosting Workbenchはできるだけ元の名前に近い8文字の名前をz/OS JCLの名前とみなします。この名前の変更プロセスにより、各表名の一意性が保たれます。
この章で使用される例では、ODCSF0という表名が、z/OS JCLの名前を付けるときにODCSF0X1に伸ばされます。
アンロードされたデータ・ファイルは、サイトで使用可能なファイル転送ツール(CFT、FTPなど)を使用して、バイナリ形式で、ソースz/OSプラットフォームとターゲットUNIXプラットフォーム間で転送される必要があります。
LOGおよびSYSPUNCHファイルはテキスト・モードで転送される必要があります。
ターゲットUNIXプラットフォームに転送されたファイルは$DATA_SOURCEディレクトリに格納される必要があります。
CLOBおよびBLOBデータ・ファイルはバイナリ・モードで転送し、$DATA_SOURCE/<schema_name>.<column_name>ディレクトリに格納する必要があります。
MBCSデータ・ファイルはテキスト・モードで転送し、転送ツールによって適切にトランスコードする必要があります。詳細は、Oracle Tuxedo Application Workbenchリファレンス・ガイドを参照してください。
| 注意: | MVSでは、Rehosting Workbenchは6文字の名前に数値を加えたもの(表の最初のCLOBまたはBLOB列には1、2番目には2など)を データセットまたはディレクトリの<column_name>とみなします。UNIX/Linuxプラットフォームでは、loadrdbms.shスクリプトは実際のcolumn_nameを使用します。 |
Oracleオブジェクト(表、索引、制約など)を作成するスクリプトは$HOME/trf/SQL/rdbms/<スキーマ名>ディレクトリに作成されます。これらはターゲットOracleインスタンスで実行される必要があります。
<スキーマ名>.lstファイルにはすべての表の名前が階層的な順序で(親表の次に子表)含まれます。
表4-5にRehosting Workbenchで管理されるDB2オブジェクトとそれを作成するために使用するスクリプトの名前をリストします。
トランスコードに使用される生成されたCOBOLプログラムの名前は次のとおりです。
この章で使用される生成されたプログラムの例は次のとおりです。
このプログラムはターゲットCOBOLコンパイラと、『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.
CLOB列のトランスコードに使用される、生成されたCOBOLプログラムの名前は次のとおりです。
CLOB_<table name>_<column_name>.cbl
データのトランスコードおよび再ロードを可能にするスクリプトが次のディレクトリに生成されます。
$HOME/trf/reload/rdbms/<schema name>/ksh
loadrdbms-<table name>.kshloadrdbms-ODCSF0.ksh
各スクリプトは、トランスコードを実行するCOBOLプログラムを開始し、次にSQL*LOADERユーティリティを開始します。SQL*LOADERにより使用されるCTLファイルの名前は次のとおりです。
<table name>.ctl.この章の例で使用されるCTLファイルの名前は次のとおりです。
ODCSF0.ctl
トランスコードおよび再ロード・スクリプトには次のパラメータがあります。
loadrdbms-<table name>.ksh [-t | [-O|-T]] [-l] [-c: <method>]
DB2オブジェクトの移行の例での例で、生成されるスクリプトは次のとおりです。
この確認は loadrdbms-<表名>.kshの次のオプションを使用します。
-c rows
| 注意: | このオプションでは、再ロードの後でDB2アンロード・ユーティリティにより、再ロードされたOracle表に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
$REFINEDIR/$VERS/rdbms.sh -c WWARNの実行時に次のメッセージが表示されます。
*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-
WARNING: some unsupported db2 objects have been ignored by this tool.
Check file /home2/wkb9/tmp/outputs/WWARN/unsupported-WWARN.log to see a detail of those objects.
ERROR:
RDBMSWB-0199: conversion aborted due to 26 Warning message(s). Check previous error messages and try -C option instead of -c
abort
DDLにサポートされていない機能が含まれます。警告ファイルを確認してください。-cオプションを-Cオプションに置き換えることで、この中断を無視できます。
  
|