Migration Toolkit command options#
移行の詳細を制御するには、Migration
Toolkitを実行するときに移行オプションを追加します。たとえば、データベース内のすべてのスキーマを移行するには、コマンドに-allSchemas
オプションを追加します。
$ ./runMTK.sh -allSchemas
注釈
-allSchemas パラメーターは、Oracle、 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 |
|---|---|
-offlineMigration |
|
-sourcedbtype, -targetdbtype, -schemaOnly, -dataOnly |
|
-dropSchema, -targetSchema |
|
-allTables, -tables, -excludeTables,<br /><br />-constraints, -ignoreCheckConstFilter,<br /><br />-skipCKConst, -skipFKConst,<br /><br />-skipColDefaultClause,<br /><br />-indexes, -triggers,<br /><br />-allViews, -views, -excludeViews,<br /><br />-allSequences, -sequences, -excludeSequences,<br /><br />-allProcs, -procs, -excludeProcs,<br /><br />-allFuncs, -funcs, -excludeFuncs,<br /><br />-checkFunctionBodies,<br /><br />-allPackages, -packages, -excludePackages,<br /><br />-allDomains,<br /><br />-allQueues, -queues, -excludeQueues<br /><br />-allRules,<br /><br />-allgroups, -groups |
|
-truncLoad, -enableConstBeforeDataLoad,<br /><br />-retryCount, -safeMode, -fastCopy,<br /><br />-analyze, vacuumAnalyze, -replaceNullChar,<br /><br />-copyDelimiter, -batchSize,<br /><br />-cpBatchSize, -lobBatchSize,<br /><br />-fetchSize, -filterProp<br /><br />-customColTypeMapping, -customColTypeMappingFile |
|
-connRetryCount, -connRetryInterval, -abortOnConnFailure |
|
-allUsers, -users,<br /><br />-allProfiles, -profiles,<br /><br />-importPartitionAsTable,<br /><br />-objectTypes,<br /><br />-copyViaDBLinkOra, -allDBLinks<br /><br />-allSynonyms, -allPublicSynonyms, -excludeSynonyms,<br /><br />-allPrivateSynonyms, -useOraCase,<br /><br />-skipUserSchemaCreation |
|
-help, -logDir, -logFileCount, -logFileSize, -logBadSQL -verbose, -version |
|
-loaderCount, -parallelLoadRowLimit, -tableLoaderLimit |
オフライン移行オプション#
コマンドラインで-offlineMigration
オプションを指定すると、Migration
Toolkitはオフライン移行を実行します。オフライン移行中に、Migration
Toolkitは選択された各オブジェクトの定義を読み取り、後で実行時にPostgresの各オブジェクトをレプリケートするSQLスクリプトを作成します。
注釈
次の例は、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>
注釈
-singleDataFile オプションは、プレーンSQL形式でデータを移行する場合にのみ使用できます。 ‑singleDataFile オプションを含める場合、 -safeMode キーワードを含める必要があります。
オフライン移行スクリプトの実行#
edb-psqlまたはpsqlコマンドラインを使用して、オフライン移行中に生成されたスクリプトを実行できます。次の例では、 EDB Postgres Advanced Serverに保存されている新しいデータベースacctgという名前にスキーマ hr という名前を復元する方法を説明します。
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
インポートオプション#
デフォルトでは、Migration
ToolkitはソースデータベースがOracleであり、ターゲットデータベースが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
オプションとともに使用できません。
スキーマ作成オプション#
デフォルトでは、Migration
Toolkitはソーススキーマオブジェクトまたはデータを同じ名前のスキーマにインポートします。ターゲットスキーマが存在しない場合、Migration
Toolkitはスキーマを作成します。または、 ‑targetSchema
オプションを使用してカスタムスキーマ名を指定できます。次のオプションを使用して、既存のスキーマを削除し、新しいスキーマを作成することを選択できます。
-dropSchema [true|false]
このオプションをtrue に設定すると、Migration
Toolkitは既存のスキーマとそのスキーマ内のオブジェクトを削除し、新しいスキーマを作成します。デフォルトでは、-dropSchema
はfalse です。
-targetSchema <schema_name>
-targetSchema
オプションを使用して、移行したスキーマの名前を指定します。複数のスキーマを移行する場合は、スペース文字を介さないコンマ区切りのリストで各スキーマの名前を指定します。
-targetSchema
オプションを使用しない場合、新しいスキーマの名前はソーススキーマの名前と同じになります。
information-schema 、dbo 、sys 、またはpg_catalog
はターゲットスキーマ名として指定できません。これらのスキーマ名は、 EDB
Postgres Advanced Serverのメタデータストレージ用に予約されています。
スキーマオブジェクト選択オプション#
次のオプションを使用して、移行する特定のスキーマオブジェクトを選択します。
-allTables
ソーススキーマからすべてのテーブルをインポートします。
-tables <table_list>
選択したテーブルをソーススキーマからインポートします。 table_list
は、スペース文字を含まないテーブル名のコンマ区切りリストたとえば
-tables emp,dept,acctg 。
-excludeTables <table_list>
選択したテーブルを移行から除外します。 table_list
は、スペース文字を含まないテーブル名のコンマ区切りリストたとえば
-excludeTables emp,jobhist
。このオプションは、スキーマのすべてのテーブルが-allTables
オプションを使用して移行のために選択された場合に適用されます。
-constraints
テーブルコンストレインをインポートします。このオプションは、スキーマ全体をインポートする場合、または-allTables
または-tables <table_list>
オプションを指定する場合にのみ有効です。
-ignoreCheckConstFilter
デフォルトでは、Migration
ToolkitはSybaseデータベースからのチェック制約とデフォルト句の移行を実装しません。制約とデフォルト句をSybaseデータベースから移行するには、
-constraints
パラメーターを指定するときに‑ignoreCheckConstFilter
パラメーターを含めます。
-skipCKConst
チェックコンストレインの移行を省略します。このオプションは、ターゲットデータベースでサポートされていないソースデータベースのビルトインファンクションに基づいたチェック制約を移行する場合に役立ちます。
このオプションは、スキーマ全体をインポートする場合、または-allTables
または-tables <table_list>
オプションが指定された場合にのみ有効です。
-skipFKConst
外部キーコンストレインの移行を省略します。このオプションは、スキーマ全体をインポートする場合、または-allTables
または-tables <table_list>
オプションが指定された場合にのみ有効です。
-skipColDefaultClause
列のDEFAULT 句の移行を省略します。
-indexes
テーブルインデックスをインポートします。このオプションは、スキーマ全体をインポートする場合、または-allTables
または-tables <table_list> オプションが指定された場合に有効です。
-triggers
テーブルトリガーをインポートします。このオプションは、スキーマ全体をインポートする場合、またはallTables
または-tables <table_list> オプションが指定された場合に有効です。
-allViews
ソーススキーマからビューをインポートします。このオプションは、動的ビューとマテリアライズドビューをソースから移行します。 OracleおよびPostgresのマテリアライズドビューがサポートされています。
-views <view_list>
指定されたマテリアライズドビューまたはダイナミックビューをソーススキーマからインポートします。
OracleおよびPostgresのマテリアライズドビューがサポートされています。
view_list
は、スペース文字を含まないビュー名のコンマ区切りリストたとえば
-views all_emp,mgmt_list,acct_list 。
-excludeViews <view_list>
選択したビューを移行から除外します。 view_list
は、スペース文字を含まないビュー名のコンマ区切りリストたとえば
-excludeViews all_emp,acct_list
。このオプションは、スキーマのすべてのビューが-allViews
オプションを使用して移行のために選択された場合に適用されます。
-allSequences
ソーススキーマからすべてのシーケンスをインポートします。
-sequences <sequence_list>
選択したシーケンスをソーススキーマからインポートします。
<sequence_list>
は、スペース文字を含まないシーケンス名のコンマ区切りリストです。
-excludeSequences <sequence_list>
選択した配列を移行から除外します。 sequence_list
は、スペース文字を含まないシーケンス名のコンマ区切りリストです。このオプションは、スキーマのすべてのシーケンスが-allSequences
オプションを使用して移行のために選択される場合に適用されます。
例
-allSequences -excludeSequences my_sequence,my_sequence_with_increment
-allProcs
ソーススキーマからすべてのストアドプロシージャをインポートします。
-procs <procedures_list>
選択したストアドプロシージャをソーススキーマからインポートします。
procedures_list
は、スペース文字を含まないプロシージャ名のコンマ区切りリストです。
-excludeProcs <procedures_list>
選択したプロシージャを移行から除外します。 procedures_list
は、スペース文字を含まないプロシージャ名のコンマ区切りのリストです。このオプションは、スキーマのすべてのプロシージャが-allProcs
オプションを使用して移行のために選択された場合に適用されます。
例 -allProcs -excludeProcs show_notice,show_custom_notice
-allFuncs
ソーススキーマからすべてのファンクションをインポートします。
-funcs <function_list>
選択したファンクションをソーススキーマからインポートします。
function_list
は、スペース文字を含まないファンクション名のコンマ区切りリストです。
-excludeFuncs <function_list>
選択した機能を移行から除外します。 function_list
は、スペース文字を含まないファンクション名のコンマ区切りリストです。このオプションは、-allFuncs
オプションを使用して移行のためにスキーマのすべてのファンクションが選択された場合に適用されます。
例 -allFuncs -excludeFuncs calculate_average_salary,add_two_numbers
-checkFunctionBodies [true/false]
false
の場合、ファンクション作成中にファンクション本体の検証を無効にします。この検証を無効にすると、ファンクションに前方参照が含まれる場合、エラーが回避されます。デフォルト値はtrue
です。
-allPackages
ソーススキーマからすべてのパッケージをインポートします。
-packages <package_list>
選択したパッケージをソーススキーマからインポートします。
package_list
は、スペース文字を含まないパッケージ名のコンマ区切りリストです。
-excludePackages <package_list>
選択したパッケージを移行から除外します。 package_list
は、スペース文字を含まないパッケージ名のコンマ区切りリストです。このオプションは、スキーマのすべてのパッケージが-allPackages
オプションを使用して移行のために選択された場合に適用されます。
例 -allPackages -excludePackages my_package1, mypackage2
-allDomains
すべてのドメイン、列挙、および複合タイプをソースデータベースからインポートします。このオプションは、ソースとターゲットの両方がPostgresホストに保存されている場合にのみ有効です。
-allQueues
ソーススキーマからすべてのキューをインポートします。これらは、
DBMS_AQおよび
DBMS_AQADMビルトインパッケージによって作成および管理されるキューです。
Oracleがソースデータベースの場合、 -objectTypes
オプションも指定する必要があります。 EDB Postgres Advanced
Serverがソースデータベースの場合、 -allDomains
および-allTables オプションも指定する必要があります。
OracleおよびEDB Postgres Advanced Serverキューがサポートされています。
-queues <queue_list>
選択したキューをソーススキーマからインポートします。 queue_list
は、スペース文字を含まないキュー名のコンマ区切りリストです。これらは、
DBMS_AQおよび
DBMS_AQADMビルトインパッケージによって作成および管理されるキューです。
Oracleがソースデータベースの場合、-objectTypes
も指定する必要があります。 EDB Postgres Advanced
Serverがソースデータベースの場合、 -allDomains
および-allTables も指定する必要があります。 OracleおよびEDB
Postgres Advanced Serverキューがサポートされています。
-excludeQueues <queue_list>
選択したキューを移行から除外します。 queue_list
は、スペース文字を含まないキュー名のコンマ区切りリストです。このオプションは、スキーマのすべてのキューが-allQueues
オプションを使用して移行のために選択される場合に適用されます。
例 -allQueues -excludeQueues EMP_QUEUE1,EMP_QUEUE2
-allRules
ソースデータベースからすべてのルールをインポートします。このオプションは、ソースとターゲットの両方がPostgresホストに保存されている場合にのみ有効です。
-allGroups
ソースデータベースからすべてのグループをインポートします。
-groups <group_list>
ソースデータベースから選択されたグループ。 <group_list>
は、グループ名のコンマ区切りリストです。例-groups acct_emp,mkt_emp
.
移行オプション#
移行オプションを使用して、移行プロセスの詳細を制御します。
-truncLoad
新しいデータをインポートする前に、テーブルからデータを切り捨てます。このオプションは-dataOnly
オプションとともに使用します。
-enableConstBeforeDataLoad
非パーティションソーステーブルがパーティションテーブルにマップされる場合、
-enableConstBeforeDataLoad
オプションを含めます。このオプションは、データの移行の前に、ターゲットテーブルのすべてのトリガーを有効にします。データを個々のパーティションにリダイレクトするトリガーを含みます。
-enableConstBeforeDataLoad は、 -truncLoad
パラメーターも指定した場合にのみ有効です。
-retryCount [<value>]
複数のスキーマの移行を実行している場合、スキーマ間の依存関係のため、最初の移行試行中に移行に失敗したオブジェクトは、後の移行中に正常に移行される場合があります。
-retryCount オプションを使用して、Migration
Toolkitが最初の移行試行中に失敗したオブジェクトの移行を試行する回数を指定します。
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です。
Out of Memory例外が発生した場合は、-batchSize の値を減らします。
-cpBatchSize
COPYコマンドで使用するバッチサイズをMB単位で指定します。 0より大きい値は有効です。デフォルトのバッチサイズは8MBです。
-lobBatchSize
LOBデータ型の場合、バッチでロードする行数を指定します。 BYTEA
、BLOB 、またはCLOB
などのラージオブジェクトタイプLOB列を含むテーブルのデータ移行は、デフォルトで一度に1行ずつ実行されます。これは、個々のLOB列が数百メガバイトのデータを保持する場合のヒープ領域不足エラーを回避するためです。
LOB列の平均データサイズが下限にある場合、各バッチの行数を0より大きい値で指定することにより、LOBバッチサイズをカスタマイズできます。
-fetchSize
-fetchSize
オプションを使用して、結果セットで取得される行数を指定します。指定された-fetchSize
が大きすぎる場合、Out of
Memory例外が発生する可能性があります。大規模なテーブルを移行するときにこの落とし穴を回避するには、
-fetchSize
オプションを含めます。デフォルトのフェッチサイズはJDBCドライバー実装に固有であり、データベースによって異なります。
MySQLユーザーの注 デフォルトでは、MySQL
JDBCドライバーは、テーブルのすべての行を1回のネットワークラウンドトリップでMigration
Toolkitに取得します。この動作は、大規模なテーブルの使用可能なメモリを簡単に超過する場合があります。ヒープ領域不足エラーが発生した場合は、コマンドライン引数として-fetchSize 1
を指定して、Migration
Toolkitに一度に1行ずつテーブルデータをロードするように強制します。
-filterProp <file_name>
<file_name>
は、key=valueペアのコンストレインを含むファイルの名前を指定します。データベースから読み取られた各レコードは、制約に対して評価されます。制約を満たすものが移行されます。ペアの左側にはテーブル名がリストされます。
テーブル名はスキーマ修飾されていない必要があります。
Oracleテーブル名は大文字と小文字を区別しませんが、Oracleはデフォルトで大文字です。一方、Postgresはデフォルトで小文字です。 Oracleデータを移行するときは、使用している大文字と小文字がOracleの大文字と小文字が一致することを確認します。それ以外の場合、Migration Toolkitはそれと一致せず、コンストレインを無視します。右側は、移行される各行にtrueが必要な条件を指定します。
たとえば、このコードは、 AR と等しくないCOUNTRY_ID
値を持つ国のみを移行します。
COUNTRIES=COUNTRY_ID<>'AR'
この制約は、 COUNTRIESテーブルに適用されます。
複数のテーブルに条件を指定することもできます。ただし、各テーブルの条件はプロパティファイルの新しい行にある必要があります。
例#
プロパティファイルの次のエントリは、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
で終わる列をINTEGER
型にマップするには、次のカスタムマッピングエントリを使用します。
.*ID=INTEGER
カスタムマッピングは、列がテーブル修飾されていない限り、基準に一致するすべてのテーブル列に適用されます。
'\\' 文字はエスケープ文字列として機能します。 '.'
は正規表現の予約文字であるため、Linuxでは '\\.' を使用して'.'
文字を表します。たとえば、カスタムマッピングを使用してEMP
テーブルのEMP_ID
列から行を選択するには、次のカスタムマッピングエントリを指定します。
EMP\\.EMP_ID=INTEGER
Windows、 '\.' を使用して'.' 文字を表します。
EMP\.EMP_ID=INTEGER
または、複数のカスタムタイプマッピングを<property_file>
に含めることができます。
-customColTypeMappingFile <property_file>
ファイルの各エントリをkey=valueのペアで個別の行に指定します。各ペアの左側は、正規表現を使用して列を選択します。各ペアの右側は、その列が想定するデータ型を名前付けます。
<property_file> で使用される場合、 '\\'
文字は、オペレーティングシステムでエスケープ文字列として機能します。
接続再試行オプション#
データの移行中にターゲットデータベースとの接続障害が発生するたび、移行トゥーキットはターゲットデータベースに再接続を試行して、テーブルをスキップせずに移行を完了します。接続が再確立されると、Migration Toolkitは、接続が失われたときに移行中であったテーブルのデータコピーを再起動または再開します。次に、残りのテーブルのデータコピーを実行します。
Migration Toolkitは、データの移行に使用していたモードに基づいて、移行を再開します。
Migration ToolkitがコピーAPIを使用してデータを移行していた場合、最後に失敗した行からデータのコピーを続行します。 Copy APIは、ターゲットデータベースとしてPostgreSQLおよびEDB Postgres Advanced Serverと互換性があります。
他のデータ移行モードでは、Migration Toolkitはターゲットテーブルのデータを切り捨て、障害が発生したテーブル全体を再コピーします。
!!!note スコープと制限 データベーススコープ 接続再試行機能により、Migration Toolkitはターゲットデータベースに再接続できます。ソースデータベースの問題の再試行はサポートされていません。
移行スコープ この機能により、Migration Toolkitはデータの移行を再試行できます。スキーマの移行に関する問題の再試行はサポートされていません。
モダリティスコープ この再接続機能は、データ移行モード-dataOnly
で利用できます。 -dataOnly または-schemaOnly
オプションを指定せずに移行を実行する場合にも使用できます。
-connRetryCount [<connection_attempts>]
-connRetryCount
オプションを使用して、ターゲットデータベース接続が失敗した場合に実行する再試行回数を指定します。
[<connection_attempts>]
値は0〜50の数値である必要があります。デフォルトは3回の再試行です。
再試行はデータの移行に適用されるため、 -schemaOnly
オプションとは互換性がありません。
例
$ ./runMTK.sh -connRetryCount 2 -dataOnly -tables dept,emp,jobhist public
-connRetryInterval [<seconds>]
-connRetryInterval
オプションを使用して、ターゲットデータベース接続が失敗した場合に、後続の各再接続を試行する前に待機する秒数を指定します。
[<seconds>]
値は、0〜900の数値である必要があります。デフォルトは30秒です。
再試行はデータの移行に適用されるため、 -schemaOnly
オプションとは互換性がありません。
例
$ ./runMTK.sh -connRetryCount 2 -connRetryInterval 50 -dataOnly -tables dept,emp,jobhist public
-abortConnOnFailure [true/false]`
すべての再接続試行が失敗した場合に、移行を中止するかどうかを指定します。
障害が発生したテーブルの移行をスキップして、次のテーブルに進むには、
-abortConnOnFailure をfalse
に設定します。デフォルトはtrue で、指定された-connRetryCount
しきい値の後に接続が失敗した場合にセッションを中止します。
再試行はデータの移行に適用されるため、 -schemaOnly
オプションとは互換性がありません。
例
$ ./runMTK.sh -connRetryCount 2 -connRetryInterval 50 -abortConnOnFailure false -dataOnly -tables dept,emp,jobhist public
-pgIdleTxSessionTimeOut [<seconds>]
PostgreSQLまたはEDB Postgres Advanced Server
idle_in_transaction_session_timeout
を指定します。これは、移行トランザクションがアイドル状態にあるときにデータベースがセッションを終了するまでの時間を定義します。
[<seconds>] は、0より大きい値です。デフォルトは180秒です。
例
runMTK.sh -connRetryCount 2 -connRetryInterval 50 -pgIdleTxSessionTimeOut 90 -dataOnly -tables dept,emp,jobhist public
並列データのロードのための移行オプション#
比較的多数のテーブルまたは大規模なテーブルを扱う場合、通常のデータの移行には時間がかかります。この問題の解決策として、Migration Toolkitには、スキーマレベルおよびテーブルレベルで並列にデータを移行できる並列データのロードアルゴリズムがあります。
スキーマレベルでの並列データの移行では、マルチプルのスレッドを使用して複数のテーブルを同時に移行します。テーブルレベルでの並列データのロードでは、マルチプルのスレッドを使用して、単一のテーブルをソースデータベースからターゲットデータベースにより効率的かつ短時間で移行します。
注釈
パラレルロードは、大規模なテーブルの場合にのみ役立ちます。小さなテーブルの場合、並列スレッドはさらに時間がかかる場合があります。したがって、比較的大規模なテーブルの場合、テーブルレベルでの並列データのロードを使用することをお勧めします。
並列データのロードは、主キー/一意キーのないテーブルには適用されません。
並列データのロードでは
fastCopyパラメーターを使用できません。パラレルロード機能は、ソースOracle、 EDB Postgres Advanced Server、およびPostgreSQLデータベースにのみ適用されます。
次のオプションは、MTKがデータを並列して移行する方法を制御します。
-loaderCount [<value>]
-loaderCount
オプションを使用して、データのロードを並列実行するためにプールで使用可能な並列スレッドの数を指定します。このオプションは、Migration
Toolkitを実行しているホストシステムにハイエンドのCPUおよびRAMリソースがある場合に特に役立ちます。
value
にはゼロ以外の正の数を指定できますが、その値がCPUコア数を超えないことをお勧めします。たとえば、デュアルコアCPUには、2
の最適値があります。デフォルトは1 です。
テーブルレベルのスレッドの数は、テーブルサイズとshared_buffers
やwork_mem
などの特定のメモリ構成に応じて、ソースデータベースサーバーにオーバーヘッドを発生させる可能性があります。メモリ構成はデータベースサーバーに最適な値に設定する必要があります。非常に大規模なテーブルの場合、マシンで使用可能な合計コアに従って、より低い-loaderCount
オプション値を試して、最適な-loaderCount
値を計算することをお勧めします。
注釈
マルチプルのスレッドが使用される場合、実際のスレッド数とテーブルデータのサイズによっては、 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つのステップで動作します。
テーブルとテーブルチャンクのリストは、テーブル名でソートされた、移行するテーブルの順序付けリストから作成されます。リストは、
-parallelLoadRowLimitおよび-tableLoaderLimitオプション値に基づいて作成されます。スレッドプールは、
-loaderCountオプション値に基づいて作成されます。並列データのロードアルゴリズムは、テーブルとテーブルチャンクのリストからテーブル/チャンクごとにタスクを作成し、スレッドプールで実行します。スレッドの数と同じ数のタスクが並列実行されます。タスクの実行が完了すると、そのスレッドはリストから次のタスクの実行を開始します。パラレルデータのロードは、リストの最後のタスクが完了するとすぐに完了します。
例#
このシナリオでは、並列データのロードを使用して4つのテーブルtab1, tab2, tab3, tab4
—を移行します。
# ./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 は2つのチャンク、tab1_chunk1
およびtab1_chunk2
にロードされます。各チャンクの行数は、totalRowCount/tableLoaderLimit
に基づいて決定されます。この場合、両方のチャンクに25,000行50,000/2があります。
テーブルtab3 は、2つのチャンク、tab3_chunk1
およびtab3_chunk2 にもロードされます。テーブル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)
システムリソースの推奨事項と制約#
Migration Toolkitを実行しているホストシステムで利用可能なCPUおよびRAMリソースに応じて、スレッド数を選択します。ソースデータベースにはCPU、IO、ディスクの使用に関して特定のオーバーヘッドが存在するため、並列スレッド数が特定のしきい値を超えて超過すると、Migration Toolkitのパフォーマンスが低下します。
Oracle固有のオプション#
次のオプションは、ソースデータベースがOracleの場合にのみ適用されます。
-objectTypes
runMTK.sh
コマンドの最後に指定されたスキーマリストからユーザー定義オブジェクトタイプをインポートします。
-allUsers
すべてのユーザーとロールをソースデータベースからインポートします。
‑allUsers オプションは、OracleデータベースからEDB Postgres Advanced
Serverデータベースに移行する場合にのみサポートされます。
-users <user_list>
選択したユーザーまたはロールをソースOracleデータベースからインポートします。
<user_list>
は、スペース文字を含まないユーザー/ロール名のコンマ区切りリストです
-users MTK, SAMPLE, acctg など。 -users
オプションは、OracleデータベースからEDB Postgres Advanced
Serverデータベースに移行する場合にのみサポートされます。
-allProfiles
すべてのカスタムつまりユーザー作成のプロファイルをソースデータベースからインポートします。
DEFAULT やMONITORING_PROFILE
などの他のOracle非カスタムプロファイルはインポートされません。
インポートされたプロファイルの場合、プロファイルに関連付けられている次のパスワードパラメーターのみがインポートされます。
FAILED_LOGIN_ATTEMPTS
PASSWORD_LIFE_TIME
PASSWORD_REUSE_TIME
PASSWORD_REUSE_MAX
PASSWORD_LOCK_TIME
PASSWORD_GRACE_TIME
PASSWORD_VERIFY_FUNCTION
Oracleリソースパラメーターなど、他のすべてのプロファイルパラメーターはインポートされません。
SRC_DB_USER
で指定されたOracleデータベースユーザーは、OracleデータディクショナリビューDBA_PROFILES
に対するSELECT 特権を持っている必要があります。
注釈
‑allProfiles オプションは、OracleデータベースからEDB Postgres Advanced Serverデータベースに移行する場合にのみサポートされます。
-profiles <profile_list>
選択したカスタムつまりユーザー作成のプロファイルをソースOracleデータベースからインポートします。
profile_list
は、スペース文字を含まないプロファイル名のコンマ区切りリストたとえば
-profiles ADMIN_PROFILE,USER_PROFILE 。 DEFAULT
やMONITORING_PROFILE
などのOracleの非カスタムプロファイルはインポートされません。
-allProfiles
オプションと同様に、パスワードパラメーターのみがインポートされます。
SRC_DB_USER
で指定されたOracleデータベースユーザーは、OracleデータディクショナリビューDBA_PROFILES
に対するSELECT 特権を持っている必要があります。
注釈
-profiles オプションは、OracleデータベースからEDB Postgres Advanced Serverデータベースに移行する場合にのみサポートされます。
-importPartitionAsTable <table_list>
-importPartitionAsTable
パラメーターを含めて、Oracleホストにあるパーティションテーブルの内容を単一の非パーティションテーブルにインポートします。
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
を参照してください。
-allDBLinks [link_Name_1=password_1,link_Name_2=password_2,...]
Oracleデータベースリンクを移行するには、このオプションを選択します。ソースデータベースの各リンク接続のパスワード情報は暗号化されるため、指定しない限り、ダミーパスワード edb に置き換えられます。
接続したユーザーのダミーパスワードとしてedbを使用して、すべてのデータベースリンクを移行するには
$./runMTK.sh -allDBLinks HR
または、スペース文字を介さないname=valueペアのコンマ区切りリストを介して、各データベースリンクのパスワードを指定できます。ペアの左側にリンク名を指定し、右側にパスワード値を指定します。
コマンドラインで指定された実際のパスワードを使用してすべてのデータベースリンクを移行するには
$./runMTK.sh -allDBLinks LINK_NAME1=abc,LINK_NAME2=xyz HR
Migration Toolkitは、EnterpriseDBで現在サポートされているデータベースリンクタイプのみを移行します。これらのタイプには、パブリックおよびプライベートタイプの固定ユーザーリンクが含まれます。
-allSynonyms
-allSynonyms
オプションを含めて、すべてのパブリックおよびプライベートシノニムをOracleデータベースからEDB
Postgres Advanced
Serverデータベースに移行します。同じ名前のシノニムがターゲットデータベースに既に存在する場合、既存のシノニムは移行したバージョンに置き換えられます。
-allPublicSynonyms
-allPublicSynonyms
オプションを含めて、すべてのパブリックシノニムをOracleデータベースからEDB
Postgres Advanced
Serverデータベースに移行します。同じ名前のシノニムがターゲットデータベースに既に存在する場合、既存のシノニムは移行したバージョンに置き換えられます。
-excludeSynonyms <synonym_list>
選択した同義語を移行から除外します。 synonym_list
は、スペース文字を含まないシノニム名のコンマ区切りリストです。このオプションは、スキーマのすべてのシノニムが-allSynonyms
オプションを使用して移行のために選択される場合に適用されます。
例 -allSynonyms -excludeSynonyms SYNEMP1,SYNEMP2
-allPrivateSynonyms
-allPrivateSynonyms
オプションを含めて、すべてのプライベートシノニムをOracleデータベースからEDB
Postgres Advanced
Serverデータベースに移行します。同じ名前のシノニムがターゲットデータベースに既に存在する場合、既存のシノニムは移行したバージョンに置き換えられます。
-useOraCase
-useOraCase オプションを含めて、OracleデータベースからEDB Postgres
Advanced
Serverデータベースに移行するときに、すべてのデータベースオブジェクトのOracleのデフォルトの大文字の命名規則を保持します。
大文字の命名規則は、テーブル、ビュー、シーケンス、プロシージャ、ファンクション、トリガー、パッケージなどで保持されます。これらのデータベースオブジェクトの場合、大文字の命名規則は以下に適用されます。
データベースオブジェクトの名前
テーブル、ビューのカラム名、キー名、インデックス名、制約名など
ビューの
SELECT列リストプロシージャまたはファンクションヘッダーの一部であるパラメーター名
注釈
プロシージャ、ファンクション、トリガー、またはパッケージのプロシージャルコード本体では、エラーなしで実行するにはプログラムの識別子参照を手動で編集する必要がある場合があります。このような修正は、発生した可能性のある識別子参照の適切な大文字と小文字の変換に関するものです。
注釈
-useOraCase オプションを指定する場合、 -skipUserSchemaCreation オプションも指定する必要がある場合があります。詳細については、 -skipUserSchemaCreation オプションの説明を参照してください。
-useOraCase オプションを使用しないMigration
Toolkitのデフォルト動作は、データベースオブジェクトが引用符で囲まれてOracleで明示的に作成されていない限り、引用符で囲まずにOracleからデータベースオブジェクト名が抽出されることです。以下は、Migration
Toolkitで-offlineMigration
オプションを使用して生成されたテーブルコマンドの一部です。
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
Oracleユーザーが移行されると、ロールがまだ存在しない場合、Oracleユーザーのターゲットデータベースサーバーにロールつまりユーザー名が作成されます。ロール名は小文字で作成されます。新しいロールが作成されると、同じ名前のスキーマも小文字で作成されます。
-skipUserSchemaCreation
オプションを指定すると、移行されたOracleユーザー名の自動スキーマ作成が防止されます。このオプションは、
-useOraCase
オプションが指定されている場合に特に役立ち、大文字と小文字のみが異なる同じ名前で2つのスキーマを作成するのを防ぎます。
-useOraCase オプションを指定すると、Migration
Toolkitが呼び出されるときにオプションリストに続いて指定されたソーススキーマの大文字のOracle命名規則でスキーマが作成されます。
したがって、 -skipUserSchemaCreation
オプションを使用せずに-useOraCase
オプションを指定すると、ターゲットデータベースには、1つは小文字、もう1つは大文字の2つの同じ名前のスキーマがあります。
-useOraCase オプションが-skipUserSchemaCreation
オプションとともに指定された場合、ターゲットデータベースには大文字のスキーマのみが含まれます。
その他のオプション#
これらの移行オプションを使用して、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>
新しいログファイルにローテーションする前に、このオプションを含めて最大ファイルサイズ制限をMB単位で指定します。
file_size は0より大きい必要があります。デフォルトは50です。
-logBadSQL
失敗したオブジェクトのスキーマ定義DDLスクリプトをファイルに保存するには、このオプションを含めます。ファイルはエラーログに使用されるのと同じパスの下に保存され、次の形式で名前付けられます。
mtk_bad_sql_<schema_name_timestamp>.sql
schema_name はスキーマの名前であり、timestamp はMigration
Toolkit実行のタイムスタンプです。
-verbose [on|off]
アプリケーションログメッセージを標準出力に表示します。デフォルトでは、 verboseはオンになっています。
-version
Migration Toolkitのバージョンを表示します。
例#
この例では、 Oracleから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
__OUTPUT__
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)
**** **** **** **** **** **** **** **** **** **** **** **** **** **** **** *
スキップされたサポートされていないデータベースオブジェクトは省略されます。移行情報は、実行の最後にある移行の概要に要約されます。