Migration Toolkit command options¶
Migration
Toolkitを実行するときに移行オプションを追加して、移行の詳細を制御します。例、データベース内のすべてのスキーマを移行するには、コマンドに-allSchemasオプションを追加します。
$ ./runMTK.sh -allSchemas
!!! Note * --allSchemasパラメータは、 オラクル、 EDB Postgres
Advanced
Server、およびPostgreSQLソースデータベースでのみサポートされます。
Sybase、MS SQL
Server、およびMySQLソースデータベースではサポートされていません。
Migration
Toolkitは、データの移行中にユーザーが作成したトリガーを無効にします。ただし、
PostgreSQL/ EDB Postgres Advanced
Serverでは、ALTER TABLEのDISABLE TRIGGER USER句を使用して継承された子パーティショントリガーを無効にできないため、パーティションテーブルのデータ移行中にトリガーがアクティブになり、予期しない結果が生じる可能性があります。
Migration Toolkitで機能するコマンドオプションは、表に示すように、動作によってグループ化されています。
Feature |
Relevant options |
|---|---|
[Offline migration options](#offline-migration-options) |
-offlineMigration |
[Import options](#import-options) |
|
[Schema creation options](#schema-creation-options) |
|
[Schema object selection options](#schema-object-selection-options) |
|
[Migration options](#migration-options) |
|
[Oracle-specific options](#oracle-specific-options) |
|
[Miscellaneous options](#miscellaneous-options) |
|
[Parallel data loading options](#parallel-loading-options) |
|
</ div>
オフライン移行オプション¶
コマンドラインで-offlineMigrationオプションを指定すると、
Migration Toolkitはオフライン移行を実行します。オフライン移行中、
Migration
Toolkitは選択された各オブジェクトの定義を読み取り、後で実行されるときにPostgresの各オブジェクトを複製するSQLスクリプトを作成します。
!!! Note * 次の例は、LinuxでMigration Toolkitを呼び出します。
WindowsでMigration
Toolkitを呼び出すには、runMTK.shコマンドの代わりにrunMTK.batコマンドを使用します。
スキーマとデータの両方のオフライン移行を実行するには、‑offlineMigrationキーワードに続けてスキーマ名前を指定します。
$ ./runMTK.sh -offlineMigration <schema_name>
各データベースオブジェクト定義は、ホームフォルダー内のスキーマ名前とオブジェクトタイプから派生した名前を持つ個別のファイルに保存されます。代替ファイルの宛先を指定するには、‑offlineMigrationオプションの後にディレクトリ名前を含めます。
$ ./runMTK.sh -offlineMigration <file_dest> <schema_name>
スキーマオブジェクトのみのオフライン移行(空のテーブルの作成)を実行するには、
Migration
Toolkitを呼び出すときに‑offlineMigrationキーワードに加えて‑schemaOnlyキーワードを指定します。
$ ./runMTK.sh -offlineMigration -schemaOnly <schema_name>
スキーマオブジェクト定義を省略してデータのみのオフライン移行を実行するには、
Migration
Toolkitを呼び出すときに‑dataOnlyキーワードと‑offlineMigrationキーワードを指定します。
$ ./runMTK.sh -offlineMigration -dataOnly <schema_name>
デフォルトでは、データはCOPYフォーマットで書き込まれます。データをプレーンなSQLフォーマットで書き込むには、‑safeModeキーワードを含めます。
$ ./runMTK.sh -offlineMigration -dataOnly -safeMode <schema_name>
デフォルトでは、テーブルデータを含むオフライン移行を実行すると、テーブルごとに個別のファイルが作成されます。マルチプルのテーブルからのデータを含む単一のファイルを作成するには、‑singleDataFileキーワードを指定します。
./runMTK.sh -offlineMigration -dataOnly -singleDataFile -safeMode <schema_name>
!!! Note *
-singleDataFileオプションは、プレーンSQLフォーマットのデータを移行する場合にのみ使用できます。
‑singleDataFileオプションを含める場合は、-safeModeキーワードを含める必要があります。
</ div>
オフライン移行スクリプトの実行¶
edb-psqlまたはpsqlコマンドラインを使用して、オフライン移行中に生成されたスクリプトを実行ます。次の例では、スキーマ(hr名前付け)をEDB Postgres Advanced Serverに保存されている新しいデータベース(acctg名前付け)に復元する方法について説明します。
createdbコマンドを使用してacctgデータベースを作成し、そこに移行したデータベースオブジェクトを復元します。createdb -U enterprisedb acctg
edb-psqlを使用して新しいデータベースに接続します。
edb-psql -U enterprisedb acctg
\iメタコマンドを使用して、オブジェクト定義を作成する移行スクリプトを呼び出します。acctg=# \i ./mtk_hr_ddl.sql
-offlineMigrationコマンドに‑singleDataFileキーワードが含まれていた場合、mtk_hr_data.sqlスクリプトには、新しいターゲットデータベース内のすべてのオブジェクトを再作成するために必要なコマンドが含まれます。次のコマンドでデータベースを作成します。acctg=# \i ./mtk_hr_data.sql
</ div>
インポートオプション¶
デフォルトでは、 Migration Toolkitはソースデータベースがオラクル
、ターゲットデータベースがEDB Postgres Advanced
Serverであると想定します。
‑sourcedbtypeおよび-targetdbtypeキーワードを含めて、デフォルト以外のソースまたはターゲットデータベースを指定します。
デフォルトでは、 Migration Toolkitはスキーマの移行時にデータとオブジェクト定義の両方をインポートします。または、データまたはオブジェクト定義のいずれかをインポートすることもできます。
-sourcedbtype <source_type>
-sourcedbtypeオプションは、ソースデータベースタイプを指定します。
source_typeには、mysql、oracle、sqlserver、sybase、postgresql、またはenterprisedbのいずれかの値を使用します。
source_typeは大文字と小文字を区別しません。デフォルトでは、source_typeはoracleです。
-targetdbtype <target_type>
-targetdbtypeオプションは、ターゲットデータベースタイプを指定します。
target_typeの場合は、enterprisedb、postgres、またはpostgresqlのいずれかの値を使用します。
target_typeは大文字と小文字を区別しません。デフォルトでは、target_typeはenterprisedbです。
-schemaOnly
このオプションは、スキーマ定義をインポートし、選択したすべてのスキーマオブジェクトをターゲットデータベースに作成します。このオプションを‑dataOnlyオプションと併用することはできません。
-dataOnly
このオプションはデータのみをコピーします。
-tablesオプションと併用すると、 Migration
Toolkitは選択したテーブルのデータのみをインポートします。このオプションを-schemaOnlyオプションと併用することはできません。
</ div>
スキーマ作成オプション¶
デフォルトでは、 Migration
Toolkitはソーススキーマオブジェクトまたはデータを同じ名前のスキーマにインポートします。ターゲットスキーマが存在しない場合、
Migration
Toolkitは新しいスキーマを作成します。または、‑targetSchema optionを使用してカスタムスキーマ名前を指定できます。次のオプションを使用して、既存のスキーマを削除し、新しいスキーマを作成することを選択できます。
-dropSchema [true|false]
このオプションをtrueに設定すると、 Migration
Toolkitは既存のスキーマとそのスキーマ内のオブジェクトをすべて削除し、新しいスキーマを作成します。デフォルトでは、-dropSchemaはfalseです。
-targetSchema <schema_name>
-targetSchemaオプションを使用して、移行されたスキーマの名前を指定します。マルチプルのスキーマを移行する場合は、各スキーマの名前を、間にスペース文字を入れずにコンマ区切りリストで指定します。
-targetSchemaオプションを使用しない場合、新しいスキーマの名前はソーススキーマの名前と同じです。
ターゲットスキーマ名としてinformation-schema、dbo、sys、またはpg_catalogを指定することはできません。これらのスキーマ名は、
EDB Postgres Advanced Serverのメタデータストレージ用に予約ています。
</ div>
スキーマオブジェクト選択オプション¶
次のオプションを使用して、移行する特定のスキーマオブジェクトを選択します。
-allTables
ソーススキーマからすべてのテーブルをインポートします。
-tables <table_list>
選択したテーブルをソーススキーマからインポートします。
table_listは、スペース文字を含まないコンマ区切りのテーブル名のリストです(-tables emp、dept、acctgなど)。
-constraints
テーブルコンストレインをインポートします。このオプションは、スキーマ全体をインポートするとき、または-allTablesまたは-tables <table_list>オプションを指定するときにのみ有効です。
-ignoreCheckConstFilter
デフォルトでは、 Migration
Toolkitはチェックコンストレインとデフォルト句のSybaseデータベースからの移行を実装していません。
-constraintsパラメータを指定してSybaseデータベースからコンストレインとデフォルト句を移行する場合は、‑ignoreCheckConstFilterパラメータを含めます。
-skipCKConst
チェックコンストレインの移行を省略します。このオプションは、ターゲットデータベースでサポートされていないソースデータベースのビルトイン関数に基づくチェックコンストレインを移行するときに役立ちます。
このオプションは、スキーマ全体をインポートする場合、または-allTablesまたは-tables <table_list>オプションが指定されている場合にのみ有効です。
-skipFKConst
外部キーコンストレインの移行を省略します。このオプションは、スキーマ全体をインポートする場合、または-allTablesまたは-tables <table_list>オプションが指定されている場合のみ有効です。
-skipColDefaultClause
列のDEFAULT句の移行を省略します。
-indexes
テーブルインデックスをインポートします。このオプションは、スキーマ全体をインポートするとき、または-allTablesまたは-tables <table_list>オプションが指定されているときに有効です。
-triggers
テーブルトリガーをインポートします。このオプションは、スキーマ全体をインポートするとき、またはallTablesまたは-tables <table_list>オプションが指定されているときに有効です。
-allViews
ソーススキーマからビューをインポートします。このオプションは、ソースから動的ビューとマテリアライズドビューを移行します。 オラクルおよびPostgresのマテリアライズドビューがサポートされています。
-views <view_list>
指定されたマテリアライズドビューまたは動的ビューをソーススキーマからインポートします。
オラクルおよびPostgresのマテリアライズドビューがサポートされています。
view_listは、間にスペース文字のないビュー名のコンマ区切りリストです(例:-views all_emp、mgmt_list、acct_list)。
-allSequences
ソーススキーマからすべてのシーケンスをインポートします。
-sequences <sequence_list>
選択したシーケンスをソーススキーマからインポートします。
<sequence_list>は、間にスペース文字を入れないシーケンス名のコンマ区切りリストです。
-allProcs
ソーススキーマからすべてのストアドプロシージャをインポートします。
-procs <procedures_list>
選択したストアドプロシージャをソーススキーマからインポートします。
procedures_listは、間にスペース文字を入れないプロシージャ名のコンマ区切りリストです。
-allFuncs
ソーススキーマからすべての関数をインポートします。
-funcs <function_list>
選択した関数をソーススキーマからインポートします。
function_listは、間にスペース文字を入れないファンクション名のコンマ区切りリストです。
-checkFunctionBodies [true/false]
falseの場合、ファンクションの作成中にファンクション本体のバリデーションを無効にします。このバリデーションを無効にすると、ファンクションに前方参照が含まれている場合のエラーを回避できます。デフォルト値はtrueです。
-allPackages
ソーススキーマからすべてのパッケージソフトをインポートします。
-packages <package_list>
選択したパッケージソフトをソーススキーマからインポートします。
package_listは、間にスペース文字を入れないパッケージ名のコンマ区切りリストです。
-allDomains
すべてのドメイン、列挙、および複合型をソースデータベースからインポートします。このオプションは、ソースとターゲットの両方がPostgresホストに保存されている場合にのみ有効です。
-allQueues
ソーススキーマからすべてのキューをインポートします。これらは、
DBMS_AQおよびDBMS_AQADMビルトインパッケージソフトによって作成および管理されるキューです。
オラクルがソースデータベースの場合、-objectTypesオプションも指定する必要があります。
EDB Postgres Advanced
Serverがソースデータベースの場合、-allDomainsおよび-allTablesオプションも指定する必要があります。
オラクルおよびEDB Postgres Advanced Serverキューがサポートされています。
-queues <queue_list>
選択したキューをソーススキーマからインポートします。
queue_listは、間にスペース文字を入れないキュー名のコンマ区切りリストです。これらは、
DBMS_AQおよびDBMS_AQADMビルトインパッケージソフトによって作成および管理されるキューです。
オラクルがソースデータベースの場合、-objectTypesも指定する必要があります。
EDB Postgres Advanced
Serverがソースデータベースの場合、-allDomainsおよび-allTablesも指定する必要があります。
オラクルおよびEDB Postgres Advanced Serverキューがサポートされています。
-allRules
ソースデータベースからすべてのルールをインポートします。このオプションは、ソースとターゲットの両方がPostgresホストに保存されている場合にのみ有効です。
</ div>
移行オプション¶
移行オプションを使用して、移行プロセスの詳細を制御します。
-truncLoad
新しいデータをインポートする前に、テーブルからデータを切り捨てます。このオプションは、-dataOnlyオプションとともに使用します。
-enableConstBeforeDataLoad
パーティション化されていないソーステーブルがパーティション化されたテーブルにマップされる場合は、-enableConstBeforeDataLoadオプションを含めます。このオプションは、データ移行前に、個々のパーティションにデータをリダイレクトするトリガーを含む、ターゲットテーブルのすべてのトリガーを有効にします。
-enableConstBeforeDataLoadは、-truncLoadパラメータも指定した場合にのみ有効です。
-retryCount [<value>]
複数スキーマの移行を実行している場合、スキーマ間の依存関係が原因で最初の移行試行中に移行に失敗したオブジェクトは、後の移行中に正常に移行する可能性があります。
-retryCountオプションを使用して、 Migration
Toolkitが最初の移行試行中にmakeしたオブジェクトの移行を試行する回数を指定します。
0より大きい値を指定します。デフォルト値は2です。
-safeMode
-safeModeオプションを含めると、 Migration
Toolkitは移行された行をコミットします。移行がすべてのレコードの転送に失敗した場合、障害点の前に挿入された行はターゲットデータベースに残ります。
-fastCopy
-fastCopyオプションを含めると、Migration
ToolkitがWALロギングをバイパスして、最適化された方法でCOPYオペレーションを実行するように指定されます。デフォルトでは無効になっています。
-fastCopyオプションの使用を選択した場合、移行が中断された場合、ターゲットデータベース内の移行されたデータを回復できない可能性があります。
-replaceNullChar <value>
Migration
Toolkitは、値がNULLの列のインポートをサポートしています。ただし、
Migration Toolkitは、
JDBC接続プロトコルでのNULL文字値(埋め込みバイナリゼロ0x00)のインポートをサポートしていません。
NULL文字を含むデータをインポートする場合は、-replaceNullCharオプションを使用して、NULL文字を単一の非NULL置換文字に置き換えます。置換文字を引用符またはアポストロフィで囲まないでください。
データを移行したら、
SQLステートメントを使用して、-replaceNullCharで指定された文字をバイナリのゼロに置き換えます。
-analyze
-analyzeオプションを含めて、ターゲットデータベースに対してPostgres
ANALYZEオペレーションを呼び出します。オプティマイザは、効率的なクエリープランをコンストラクトするための情報を使用して、ANALYZEオペレーションによって収集された統計を調べます。
-vacuumAnalyze
-vacuumAnalyzeオプションを含めて、ターゲットデータベースに対してVACUUM操作とANALYZE操作の両方を呼び出します。オプティマイザは、効率的なクエリープランをコンストラクトするための情報を使用して、ANALYZEオペレーションによって収集された統計を調べます。
VACUUMオペレーションは、ターゲットデータベース内の無効なタプルによって占有されているストレージスペースを再利用します。
-copyDelimiter
テーブルデータをローディングするときにCOPYコマンドでデリミタとして使用する単一の文字を指定します。デフォルト値は'\t'(タブ)です。
-batchSize
一括挿入のバッチサイズを指定します。有効な値は1〜1000です。デフォルトのバッチサイズは1000です。メモリ不足例外が発生する場合は、-batchSizeの値を減らします。
-cpBatchSize
COPYコマンドで使用するバッチサイズをメガバイト単位で指定します。 0より大きい値はすべて有効です。デフォルトのバッチサイズは8 メガバイトです。
-lobBatchSize
LOBデータ型のバッチでロードする行数を指定します。
BYTEA、BLOB、CLOBなどのラージオブジェクトタイプ(LOB)列を含むテーブルのデータ移行は、デフォルトで一度に1行ずつ実行されデフォルト。これは、個々のLOB列が数百メガバイトのデータを保持している場合に、ヒープ領域不足エラーを回避するためです。
LOB列の平均データサイズが下限にある場合、各バッチの行数を0より大きい値で指定することにより、LOBバッチサイズをカスタマイズます。
-fetchSize
-fetchSizeオプションを使用して、結果セットでフェッチされる行の数を指定します。指定された-fetchSizeがラージすぎる場合、メモリ不足例外が発生する可能性があります。ラージテーブルを移行するときにこの落とし穴を避けるために、-fetchSizeオプションを含めます。デフォルトのフェッチサイズはJDBCドライバの実装に固有であり、データベースによって異なります。
MySQLユーザーのノート:デフォルトでは、MySQL
JDBCドライバは1回のネットワークラウンドトリップでテーブル内のすべての行をMigration
Toolkitにフェッチします。この動作は、ラージテーブルで使用可能なメモリを簡単に超える可能性があります。ヒープ領域不足エラーが発生した場合は、コマンドライン引数として-fetchSize 1を指定して、
Migration Toolkitにテーブルデータを一度に1行ずつロードさせます。
-filterProp <file_name>
<file_name>は、キー=値のペアでコンストレインを含むファイルの名前を指定します。データベースから読み取られた各レコードは、コンストレインに対して評価されます。コンストレインを満たすものは移行されます。ペアの左側には、テーブル名前がリストされます。テーブル名前はスキーマ修飾されていてはなりません。右側は、移行される行に対して真でなければならない条件を指定します。例、プロパティファイルに次のコンストレインを含める
countries=country_id<>'AR'
country_idの値がARと等しくない国のみを移行します。この制約は、国テーブルに適用されます。
マルチプルのテーブルの条件を指定することもできます。ただし、各テーブルの条件は、プロパティファイルの新しい行にある必要があります。
例:
プロパティファイルの次のエントリは、EMPLOYEESおよびDEPARTMENTSテーブルから関連データのみを移行します。
EMPLOYEES=(LAST_NAME IN ('Grant','Weiss') AND PHONE_NUMBER LIKE '650%')
DEPARTMENTS=(DEPARTMENT_ID BETWEEN 10 AND 30)
-customColTypeMapping <column_list>
カスタム型マッピングを使用して、移行された列のデータタイプを変更します。各ペアの左側は、正規表現で列を指定します。各ペアの右側には、その列が想定するデータタイプの名前が付けられます。
<column_list>のセミコロン区切りリストにマルチプルのペアを含めることができます。例、名前がIDで終わる列をマップと入力するには、次のカスタムマッピングエントリーを使用します。
.*ID=INTEGER
列がテーブル修飾されていない限り、条件にマッチするすべてのテーブル列にカスタムマッピングが適用されます。
'\\'文字はエスケープ文字列として機能します。
'.'は正規表現の予約文字であるため、Linuxでは'\\.'を使用して'.'文字を表します。例、カスタムマッピングを使用してEMPテーブルのEMP_ID列から行を選択するには、次のカスタムマッピングエントリーを指定します。
EMP\\.EMP_ID=INTEGER
Windows、'\.'を使用して'.'文字を表します。
EMP\.EMP_ID=INTEGER
-customColTypeMappingFile <property_file>
<property_file>にはマルチプルのカスタムタイプマッピングを含めることができます。ファイルの各エントリーを、キー=値のペアで別々の行に指定します。各ペアの左側は、正規表現で列を選択します。各ペアの右側には、その列が想定するデータタイプの名前が付けられます。
</ div>
並列データローディングの移行オプション¶
比較的ラージのテーブルまたはラージサイズのテーブルを処理する場合、通常のデータ移行には長い時間がかかります。この問題の解決策として、 Migration Toolkitには、スキーマレベルおよびテーブルレベルでデータを並列に移行できる並列データローディングアルゴリズムがあります。
スキーマレベルでの並列データ移行では、マルチプルのスレッドを使用して複数のテーブルを同時に移行します。テーブルレベルでの並列データローディングでは、マルチプルのスレッドを使用して、ソースデータベースからターゲットデータベースに単一のテーブルをより効率的かつ短時間で移行します。
!!! Note * -並列ローディングはラージテーブルにのみ役立ちます。小さなテーブルの場合、並列スレッドには時間がかかる場合があります。したがって、比較的ラージテーブルに対しては、テーブルレベルで並列データローディングを使用することをお勧めします。
-並列データのローディングは、プライマリキー/一意キーのないテーブルには適用されません。
-
fastCopyパラメータは、並列データのローディングでは使用できません。-並列ローディング機能は、ソースオラクル、 EDB Postgres Advanced Server、およびPostgreSQLデータベースにのみ適用されます。
次のオプションは、MTKがデータを並行して移行する方法を制御します。
-loaderCount [<value>]
-loaderCountオプションを使用して、プールで使用可能な並列スレッドの数を指定して、データロードを並列に実行します。このオプションは、Migration
Toolkitを実行しているホストシステムにハイエンドのCPUおよびRAMリソースがある場合に特に役立ちます。
valueは非ゼロの正の数にすることができますが、CPUコアの数を超えないことをお勧めします。例、デュアルコアCPUの最適値は2です。デフォルトは1です。
!!! Note * マルチプルのスレッドを使用する場合、実際のスレッド数とテーブルデータサイズに応じて、 Migration Toolkitのメモリヒープサイズを調整する必要があります。
-parallelLoadRowLimit [<value>]
-parallelLoadRowLimitオプションを使用して、テーブルレベルでデータロードを並行して実行するためにテーブルに必要な最小行数を指定します。
<value>パラメータは0より大きいなければなりません。デフォルトは100,000です。
例、-parallelLoadRowLimitの値が10,000の場合、行数が10,000以上のテーブルのみがテーブルレベルで並列にロードされます。他のテーブルは、シーケンシャルモードまたはスキーマレベルで移行します。
-tableLoaderLimit [<value>]
-tableLoaderLimitオプションを使用して、スレッドプールから割り当てるスレッドの最大数を指定し、テーブルレベルで単一のテーブルデータを並列チャンクでロードします。
<value>パラメータは、-loaderCountの値をより大きいてはなりません。デフォルト値は、-loaderCountオプションの値と同じです。このオプションは、-loaderCountのデフォルト以外のカスタム値に基づいて暗黙的に変更されます。
例、-loaderCountが4に設定され、-tableLoaderLimitが指定されていない場合、-tableLoaderLimitも4に設定されます。したがって、すべてのスレッドが単一のテーブルロードに使用されることを意図していない場合、-tableLoaderLimitをより低い値に減らします。
並列データ読み込みアルゴリズムの概要¶
アルゴリズムは3つのステップで機能します。
1.テーブルとテーブルチャンクのリストは、移行されるテーブルの順序付きリストから作成され、テーブル名前でソートされます。リストは、-parallelLoadRowLimitおよび-tableLoaderLimitオプションの値に基づいて作成されます。
-loaderCountオプション値に基づいてスレッドプールが作成されます。
1.並列データ読み込みアルゴリズムは、テーブルおよびテーブルチャンクのリストから各テーブル/チャンクのタスクを作成し、スレッドプールで実行します。スレッド数と同じ数のタスクが並行して実行されます。タスクの実行が完了するとすぐに、そのスレッドはリストから次のタスクの実行を開始します。リストの最後のタスクが完了するとすぐに、並列データのローディングが完了します。
例:
このシナリオでは、4つのテーブル&mdash;
tab1, tab2, tab3, tab4&mdash;を並列データローディングで移行します。
# ./runMTK.sh -sourcedbtype enterprisedb -targetdbtype enterprisedb -loaderCount 4 -parallelLoadRowLimit 10000 -tableLoaderLimit 2 -tables tab1,tab2,tab3,tab4 public
テーブルtab1には50,000行、テーブルtab2には9,500行、テーブルtab3には50,001行、テーブルtab4には9,999行があります。ステップ1のテーブルのリストは、tab1, tab2, tab3およびtab4です。
テーブルtab1およびtab3のみが、テーブルレベル(-parallelLoadRowLimit 10000)での並列ローディングの修飾となります。
-tableLoaderLimitオプションの値は2であるため、テーブルtab1はtab1_chunk1とtab1_chunk2の2つのチャンクでロードされます。各チャンクの行数は、totalRowCount/tableLoaderLimitに基づいて決定されます。この場合、両方のチャンクには25,000行(50,000
/ 2)があります。
テーブルtab3も、tab3_chunk1とtab3_chunk2の2つのチャンクでロードされます。テーブルtab3の行の総数が奇数(50,001)であるため、最初のチャンクは追加の行を収容するため、tab3_chunk1には25,001行、tab3_chunk2には25,000行が含まれます。
作成されるテーブルとテーブルチャンクのリストは次のとおりです。
* tab1_chunk1 (25,000 rows)
* tab1_chunk2 (25,000 rows)
* tab2 (9500 rows)
* tab3_chunk1 (25,001 rows)
* tab3_chunk2 (25,000 rows)
* tab4 (9999 rows)
4つのスレッドT1, T2, T3, T4を持つスレッドプールが作成されます。ステップ1で作成されたリストからテーブル/チャンクを移行するタスクは、スレッドプールで実行されます。
T1 → tab1_chunk1 (25,000 rows)
T2 → tab1_chunk2 (25,000 rows)
T3 → tab2 (9500 rows)
T4 → tab3_chunk1 (25,001 rows)
スレッドT3は最初に終了し、リストの次のチャンクであるtab3_chunk2の実行を開始します。
T1 → tab1_chunk1 (25,000 rows)
T2 → tab1_chunk2 (25,000 rows)
T3 → tab3_chunk2 (25,000 rows)
T4 → tab3_chunk1 (25,001 rows)
スレッドT1は2番目に終了し、tab4の実行を開始します。
T1 → tab4 (9999 rows)
T2 → tab1_chunk2 (25,000 rows)
T3 → tab3_chunk2 (25,000 rows)
T4 → tab3_chunk1 (25,001 rows)
このように、4つのスレッドを使用して、スキーマとテーブルの混在テーブルレベルで4つのテーブルを並行して移行します。コマンドオプションを変更して-tableLoaderLimitを1に設定する場合:
# ./runMTK.sh -sourcedbtype enterprisedb -targetdbtype enterprisedb -loaderCount 4 -parallelLoadRowLimit 10000 -tableLoaderLimit 1 -tables tab1,tab2,tab3,tab4 public
純粋なスキーマレベルの並列処理が可能です。各テーブルは1つのスレッドで同時に処理されます。
T1 → tab1 (50,000 rows)
T2 → tab2 (9500 rows)
T3 → tab3 (50,001 rows)
T4 → tab4 (9999 rows)
システムリソースの推奨事項とコンストレイン**¶
MTKを実行しているホストシステムで使用可能なCPUおよびRAMリソースに応じて、スレッドの数を選択します。 CPU、IO、およびディスク使用率に関してソースデータベースに特定のオーバーヘッドがあるため、特定のしきい値を超える並列スレッド数を超えると、MTKのパフォーマンスが低下します。
</ div>
Oracle固有のオプション¶
次のオプションは、ソースデータベースがオラクルの場合にのみ適用されます。
-objectTypes
runMTK.shコマンドの最後に指定されたスキーマリストからユーザー定義のオブジェクトタイプをインポートします。
-allUsers
ソースデータベースからすべてのユーザーとロールをインポートします。
‑allUsersオプションは、 オラクルデータベースからEDB Postgres
Advanced Serverデータベースに移行する場合にのみサポートされます。
-users <user_list>
選択したユーザーまたはロールをソースオラクルデータベースからインポートします。
<user_list>は、スペース文字を挟まないユーザ/ロール名のコンマ区切りリストです(-users MTK, SAMPLE, acctgなど)。
-usersオプションは、 オラクルデータベースからEDB Postgres Advanced
Serverデータベースに移行する場合にのみサポートされます。
-allProfiles
ソースデータベースからすべてのカスタム(つまり、ユーザー作成)プロファイルをインポートします。
DEFAULTやMONITORING_PROFILEなどの他のオラクル非カスタムプロファイルはインポートされません。
インポートされたプロファイルに関連付けられている次のパスワードパラメータのみがインポートされます。
FAILED_LOGIN_ATTEMPTS
PASSWORD_LIFE_TIME
PASSWORD_REUSE_TIME
PASSWORD_REUSE_MAX
PASSWORD_LOCK_TIME
PASSWORD_GRACE_TIME
PASSWORD_VERIFY_FUNCTION
オラクルリソースパラメータなど、他のすべてのプロファイルパラメータはインポートされません。
SRC_DB_USERで指定されたオラクルデータベースユーザには、
オラクルデータディクショナリビューDBA_PROFILESに対するSELECT権限が必要です。
!!! Note * ‑allProfilesオプションは、 オラクルデータベースからEDB
Postgres Advanced
Serverデータベースに移行する場合にのみサポートされます。
-profiles <profile_list>
選択したカスタム(つまり、ユーザー作成)プロファイルをソースオラクルデータベースからインポートします。
profile_listは、スペース文字を含まないコンマ区切りのプロファイル名のリストです(-profiles ADMIN_PROFILE,USER_PROFILEなど)。
DEFAULTやMONITORING_PROFILEなどのオラクル非カスタムプロファイルはインポートされません。
-allProfilesオプションと同様に、パスワードパラメータのみがインポートされます。
SRC_DB_USERで指定されたオラクルデータベースユーザには、
オラクルデータディクショナリビューDBA_PROFILESに対するSELECT権限が必要です。
!!! Note * -profilesオプションは、 オラクルデータベースからEDB
Postgres Advanced
Serverデータベースに移行する場合にのみサポートされます。
-importPartitionAsTable <table_list>
-importPartitionAsTableパラメータを含めて、
オラクルホスト上にあるパーティションテーブルの内容を単一の非パーティションテーブルにインポートします。
table_listは、間にスペース文字が入っていないテーブル名のコンマ区切りリストです(-importPartitionAsTable emp,dept,acctgなど)。
-copyViaDBLinkOra
dblink_oraモジュールは、 SQLレベルでEDB Postgres Advanced
ServerからOracleへの接続を提供します。 dblink_oraはバンドルされ、
EDB Postgres Advanced
Serverデータベースインストレーションのパートとしてインストールされます。
dblink_oraは、COPY APIメソッドを使用してデータベース間でデータを転送します。このメソッドは、JDBC COPYメソッドよりもかなり高速です。
この例では、dblink_ora
COPY APIを使用して、HRスキーマからすべてのテーブルを移行します。
$./runMTK.sh -copyViaDBLinkOra -allTables HR
ターゲットEDB Postgres Advanced
Serverデータベースにdblink_oraがインストールおよび構成されている必要があります。
dblink_oraについては、Database Compatibility for Oracle
Developersを参照してください。
-allDBLinks [link_Name_1=password_1,link_Name_2=password_2,...]
オラクルデータベースリンクを移行するには、このオプションを選択します。ソースデータベース内の各リンク接続のパスワード情報は暗号化されているため、指定しない限り、ダミーパスワードedbが代わりに使用されます。
接続ユーザのダミーパスワードとしてedbを使用してすべてのデータベースリンクを移行するには:
$./runMTK.sh -allDBLinks HR
または、スペース文字を介在させずに、名前=値のペアのコンマ区切りリストを使用して、各データベースリンクのパスワードを指定することもできます。ペアの左側にリンク名前を、右側にパスワード値を指定します。
すべてのデータベースリンクをコマンドラインで指定された実際のパスワードで移行するには:
$./runMTK.sh -allDBLinks LINK_NAME1=abc,LINK_NAME2=xyz HR
Migration Toolkitは、 EnterpriseDBで現在サポートされているデータベースリンクタイプのみを移行します。これには、パブリックおよびプライベートタイプの固定ユーザリンクが含まれます。
-allSynonyms
すべてのパブリックシノニムとプライベートシノニムをオラクルデータベースからEDB
Postgres Advanced
Serverデータベースに移行するには、-allSynonymsオプションを含めます。同じ名前の同義語がターゲットデータベースに既に存在する場合、既存の同義語は移行されたバージョンに置き換えられます。
-allPublicSynonyms
すべてのパブリックシノニムをオラクルデータベースからEDB Postgres
Advanced
Serverデータベースに移行するには、-allPublicSynonymsオプションを含めます。同じ名前の同義語がターゲットデータベースに既に存在する場合、既存の同義語は移行されたバージョンに置き換えられます。
-allPrivateSynonyms
すべてのプライベートシノニムをオラクルデータベースからEDB Postgres
Advanced
Serverデータベースに移行するには、-allPrivateSynonymsオプションを含めます。同じ名前の同義語がターゲットデータベースに既に存在する場合、既存の同義語は移行されたバージョンに置き換えられます。
-useOraCase
-useOraCaseオプションを含めて、 オラクルデータベースからEDB
Postgres Advanced
Serverデータベースに移行するときに、すべてのデータベースオブジェクトのオラクルのデフォルトの大文字の命名規則を保持します。
大文字の命名規則は、テーブル、ビュー、シーケンス、プロシージャ、関数、トリガー、パッケージソフトなどで保持されます。これらのデータベースオブジェクトでは、大文字の命名規則が適用されます:-データベースオブジェクトの名前-テーブルおよびビューの列名、キー名、インデックス名、制約名など-aのSELECT列リストビュープロシージャまたはファンクションヘッダーのパートであるパラメータ名
!!! Note * プロシージャ、 ファンクション 、triggerまたはpackageの手続きコード本体では、エラーなしで実行プログラムの識別子参照を手動で編集する必要がある場合があります。このような修正は、発生した可能性のある識別子参照の適切な大文字小文字変換に関するものです。
!!! Note *
-useOraCaseオプションを指定する場合、-skipUserSchemaCreationオプションも指定する必要があります。詳細については、-skipUserSchemaCreationオプションの説明を参照してください。
-useOraCaseオプションを使用しないMigration
Toolkitのデフォルトの動作では、データベース引用符オラクルは引用符で囲まずにオラクルから抽出されます。以下は、-offlineMigrationオプションを使用してMigration
Toolkitによって生成されたTABLEコマンドの一部です。
CREATE TABLE DEPT (
* DEPTNO NUMBER(2) NOT NULL,
* DNAME VARCHAR2(14),
* LOC VARCHAR2(13)
);
ALTER TABLE DEPT ADD CONSTRAINT DEPT_PK PRIMARY KEY (DEPTNO);
ALTER TABLE DEPT ADD CONSTRAINT DEPT_DNAME_UQ UNIQUE (DNAME);
その後、このテーブルを移行してEDB Postgres Advanced Serverで作成すると、引用されていないオブジェクト名はすべて小文字に変換されるため、テーブルは次のようにEDB Postgres Advanced Serverに表示されます。
Table "edb.dept"
Column | Type | Modifiers
--------+-----------------------+-----------
deptno | numeric(2,0) | not null
dname | character varying(14) |
loc | character varying(13) |
Indexes:
* "dept_pk" PRIMARY KEY, btree (deptno)
* "dept_dname_uq" UNIQUE CONSTRAINT, btree (dname)
EDB Postgres Advanced Serverアプリケーションが、引用符で囲まれた大文字の識別子を使用して移行されたデータベースオブジェクトを参照している場合、データベースオブジェクト名は小文字であるため、アプリケーションは失敗します。
usepostcase=# SELECT * FROM "DEPT";
ERROR: relation "DEPT" does not exist
LINE 1: SELECT * FROM "DEPT";
アプリケーションが引用符付きの大文字の識別子を使用する場合は、-useOraCaseオプションを使用して移行を実行します。
DDLは、すべてのデータベースオブジェクト名を引用符で囲みます。
CREATE TABLE "DEPT" (
* "DEPTNO" NUMBER(2) NOT NULL,
* "DNAME" VARCHAR2(14),
* "LOC" VARCHAR2(13)
);
ALTER TABLE "DEPT" ADD CONSTRAINT "DEPT_PK" PRIMARY KEY ("DEPTNO");
ALTER TABLE "DEPT" ADD CONSTRAINT "DEPT_DNAME_UQ" UNIQUE ("DNAME");
その後、このテーブルを移行してEDB Postgres Advanced Serverで作成すると、すべてのオブジェクト名が大文字で維持されるため、テーブルは次のようにEDB Postgres Advanced Serverに表示されます。
Table "EDB.DEPT"
Column | Type | Modifiers
--------+-----------------------+-----------
DEPTNO | numeric(2,0) | not null
DNAME | character varying(14) |
LOC | character varying(13) |
Indexes:
* "DEPT_PK" PRIMARY KEY, btree ("DEPTNO")
* "DEPT_DNAME_UQ" UNIQUE CONSTRAINT, btree ("DNAME")
アプリケーションは、引用符で囲まれた大文字の名前を使用してオブジェクトにアクセスできます。
useoracase=# SELECT * FROM "DEPT";
DEPTNO | DNAME | LOC
--------+------------+----------
10 | ACCOUNTING | NEW YORK
20 | RESEARCH | DALLAS
30 | SALES | CHICAGO
40 | OPERATIONS | BOSTON
(4 rows)
-skipUserSchemaCreation
オラクルユーザが移行されると、そのロールがまだ存在しない場合、 オラクルユーザのターゲットデータベースサーバにロール(ユーザ名前)が作成されます。ロール名前は小文字で作成されます。新しいロールが作成されると、同じ名前のスキーマも小文字で作成されます。
-skipUserSchemaCreationオプションを指定すると、移行されたオラクルユーザ名前の自動スキーマ作成が防止されます。このオプションは、-useOraCaseオプションを指定して、大文字と小文字が異なるだけで同じ名前の2つのスキーマを作成しないようにする場合に特に便利です。
-useOraCaseオプションを指定すると、 Migration
Toolkitの起動時にオプションリストに従って指定されたソーススキーマの大文字のオラクル命名規則でスキーマが作成されます。
したがって、-skipUserSchemaCreationオプションを指定せずに-useOraCaseオプションを指定すると、ターゲットデータベースには、一方が小文字でもう一方が大文字の2つの同じ名前付けのスキーマが作成されます。
-useOraCaseオプションが-skipUserSchemaCreationオプションとともに指定されている場合、ターゲットデータベースには大文字のスキーマのみが含まれます。
</ div>
その他のオプション¶
これらの移行オプションを使用すると、 Migration Toolkitのヘルプとバージョン情報がビューされます。これらのオプションを使用して、 Migration Toolkitのフィードバックとロギングオプションを制御することもできます。
-help
アプリケーションのコマンドラインの使用情報を表示します。
-logDir <log_path>
ログファイルを書き込む場所を指定するには、このオプションを含めます。
<log_path>は、ログファイルを保存する場所です。デフォルトでは、Linuxではログファイルは次の場所に書き込まれます。
$HOME/.enterprisedb/migration-toolkit/logs
Windowsでは、ログファイルは次の場所に保存されます。
%HOMEDRIVE%%HOMEPATH%\.enterprisedb\migration-toolkit\logs
-logFileCount <file_count>
ログファイルのローテーションで使用されるファイルの数を指定するには、このオプションを含めます。
0の値を指定して、ログファイルのローテーションを無効にし、単一のログファイルを作成します。このファイルは、logFileSizeオプションを使用して指定された値に達すると切り捨てられます。
<file_count>は0以上でなければなりません。デフォルトは20です。
-logFileSize <file_size>
新しいログファイルにローテーションする前に、
メガバイト単位で最大ファイルサイズ制限を指定するには、このオプションを含めます。
file_sizeは0より大きいなければなりません。デフォルトは50です。
-logBadSQL
失敗したオブジェクトのスキーマ定義(DDLスクリプト)をファイルに保存するには、このオプションを含めます。ファイルはエラーログに使用されたのと同じパスの下に保存され、次のフォーマットで名前が名前付けます。
mtk_bad_sql_<schema_name_timestamp>.sql
ここで、schema_nameはスキーマの名前であり、timestampはMigration
Toolkit実行のタイムスタンプです。
-verbose [on|off]
標準出力にアプリケーションログメッセージを表示します。デフォルトでは、詳細表示はオンになっています。
-version
Migration Toolkitバージョンを表示します。
</ div>
例¶
この例では、 オラクルからEDB Postgres Advanced Serverへの移行を実行します。
以下は、toolkit.propertiesファイルのコンテンツです。
SRC_DB_URL=jdbc:oracle:thin:@192.168.2.6:1521:xe
SRC_DB_USER=edb
SRC_DB_PASSWORD=password
TARGET_DB_URL=jdbc:edb://localhost:5444/edb
TARGET_DB_USER=enterprisedb
TARGET_DB_PASSWORD=password
次のコマンドは、 Migration Toolkitを呼び出します。
$ ./runMTK.sh EDB
Running EnterpriseDB Migration Toolkit (Build 48.0.0) ...
Source database connectivity info...
conn =jdbc:oracle:thin:@192.168.2.6:1521:xe
user =edb
password=*****\*
Target database connectivity info...
conn =jdbc:edb://localhost:5444/edb
user =enterprisedb
password=*****\*
Connecting with source Oracle database server...
Connected to Oracle, version 'Oracle Database 10g Express Edition
Release 10.2.0.1.0 - Production'
Connecting with target EnterpriseDB database server...
Connected to EnterpriseDB, version '9.4.0.0'
Importing redwood schema EDB...
Creating Schema...edb
Creating Sequence: NEXT_EMPNO
Creating Tables...
Creating Table: BAD_TABLE
MTK-15013: Error Creating Table BAD_TABLE
DB-42704: ERROR: type "binary_double" does not exist at position 58
-- CREATE TABLE BAD_TABLE (
-- F1 NUMBER NOT NULL,
-- Line 3: F2 BINARY_DOUBLE
-- ^
Creating Table: DEPT
Creating Table: EMP
Creating Table: JOBHIST
Creating Table: "MixedCase"
Creating Table: "lowercase"
Created 5 tables.
Loading Table Data in 8 MB batches...
Loading Table: DEPT ...
[DEPT] Migrated 4 rows.
[DEPT] Table Data Load Summary: Total Time(s): 0.147 Total Rows: 4
Loading Table: EMP ...
[EMP] Migrated 14 rows.
[EMP] Table Data Load Summary: Total Time(s): 0.077 Total Rows: 14
Loading Table: JOBHIST ...
[JOBHIST] Migrated 17 rows.
[JOBHIST] Table Data Load Summary: Total Time(s): 0.042 Total Rows: 17
Total Size(MB): 9.765625E-4
Loading Table: "MixedCase" ...
["MixedCase"] Table Data Load Summary: Total Time(s): 0.098 Total Rows:0
Loading Table: "lowercase" ...
["lowercase"] Table Data Load Summary: Total Time(s): 0.066 Total Rows:0
Data Load Summary: Total Time (sec): 0.806 Total Rows: 35 Total
Size(MB): 0.001
Creating Constraint: DEPT_PK
Creating Constraint: DEPT_DNAME_UQ
Creating Constraint: EMP_PK
Creating Constraint: JOBHIST_PK
Creating Constraint: SYS_C008958
MTK-15001: Error Creating Constraint SYS_C008958
DB-42P01: com.edb.util.PSQLException: ERROR: relation "bad_table" does
not exist
Creating Constraint: EMP_REF_DEPT_FK
Creating Constraint: EMP_SAL_CK
Creating Constraint: JOBHIST_REF_DEPT_FK
Creating Constraint: JOBHIST_REF_EMP_FK
Creating Constraint: JOBHIST_DATE_CHK
Creating Trigger: USER_AUDIT_TRIG
Creating Trigger: EMP_SAL_TRIG
MTK-13009:Warning! Skipping migration of trigger DROP_TRIGGER, currently
non-table triggers are not supported in target database.
Creating View: SALESEMP
Creating Function: EMP_COMP
Creating Package: EMP_ADMIN
MTK-16005:Package Body is Invalid, Skipping...
Schema EDB imported with errors.
MTK-12001: The user/role migration failed due to insufficient
privileges.
Grant the user SELECT privilege on the following Oracle catalogs:
DBA_ROLES
DBA_USERS
DBA_TAB_PRIVS
DBA_PROFILES
DBA_ROLE_PRIVS
ROLE_ROLE_PRIVS
DBA_SYS_PRIVS
One or more schema objects could not be imported during the migration
process. Please review the migration output for more details.
Migration logs have been saved to
/home/user/.enterprisedb/migration-toolkit/logs
******************** Migration Summary ********************
Sequences: 1 out of 1
Tables: 5 out of 6
Constraints: 9 out of 10
Triggers: 2 out of 3 (skipped 1)
Views: 1 out of 1
Functions: 1 out of 1
Packages: 1 out of 1
Total objects: 30
Successful count: 20
Failed count: 2
Skipped count: 1
Invalid count: 7
List of failed objects
======================
Tables
--------------------
1. EDB.BAD_TABLE
Constraints
--------------------
1. EDB.BAD_TABLE.SYS_C008958
List of invalid objects
=======================
1. EDB.HIRE_CLERK (FUNCTION)
2. EDB.NEW_EMPNO (FUNCTION)
3. EDB.EMP_ADMIN (PACKAGE BODY)
4. EDB.EMP_QUERY (PROCEDURE)
5. EDB.EMP_QUERY_CALLER (PROCEDURE)
6. EDB.LIST_EMP (PROCEDURE)
7. EDB.SELECT_EMP (PROCEDURE)
*************************************************************
スキップされ、サポートされていないデータベースオブジェクトは省略されます。移行情報は、実行の最後に移行概要に要約されます。