Oracle NoSQL Database Migratorのワークフロー

NoSQL Data Migratorユーティリティのダウンロード

Oracle NoSQL Database Migratorユーティリティは、Oracle NoSQLのダウンロード・ページからダウンロードできます。マシンにダウンロードして解凍すると、コマンドライン・インタフェースからrunMigratorコマンドにアクセスできます。

ノート:

Oracle NoSQL Database Migratorユーティリティを実行するには、Java 11以降のバージョンが必要です。

ソースとシンクの指定

マイグレータを使用する前に、データ・ソースとシンクを指定する必要があります。たとえば、オンプレミスのOracle NoSQL DatabaseからJSON形式のファイルにNoSQL表を移行する場合、ソースはOracle NoSQL Databaseになり、シンクはJSONファイルになります。「サポートされるソースとシンク」を参照して、指定したソースとシンクがOracle NoSQL Database Migratorでサポートされていることを確認します。これは、ターゲットまたはシンクのNoSQL表のスキーマを決定して作成するための適切なフェーズでもあります。

シンク表スキーマの指定: シンクがオンプレミスまたはクラウドのOracle NoSQL Databaseの場合は、シンク表のスキーマを指定し、ソース・データがターゲット・スキーマと一致することを確認する必要があります。必要に応じて、変換を使用してソース・データをシンク表にマップします。
- デフォルト・スキーマ: NoSQL Database Migratorには、表のスキーマを事前定義する必要なく、デフォルト・スキーマを使用して表を作成するオプションが用意されています。これは、主にJSONソース・ファイルをOracle NoSQL Databaseにロードする場合に役立ちます。
  ソースがMongoDB形式のJSONファイルの場合、表のデフォルト・スキーマは次のようになります。
```
CREATE TABLE IF NOT EXISTS <tablename>(ID STRING, DOCUMENT JSON,PRIMARY KEY(SHARD(ID))
```
  説明:
  
  — tablename = 構成のtable属性に指定された値。
  
  — ID = mongoDBでエクスポートされたJSONソース・ファイルの各ドキュメントの_id値。
  
  — DOCUMENT = mongoDBでエクスポートされたファイル内のドキュメントごとに、_idフィールドを除く内容がDOCUMENT列に集計されます。
  ソースがDynamoDB形式のJSONファイルの場合、表のデフォルト・スキーマは次のようになります。
```
CREATE TABLE IF NOT EXISTS <TABLE_NAME>(DDBPartitionKey_name DDBPartitionKey_type, 
[DDBSortKey_name DDBSortKey_type],DOCUMENT JSON,
PRIMARY KEY(SHARD(DDBPartitionKey_name),[DDBSortKey_name]))
```
  説明:
  
  — TABLE_NAME = 構成内のシンク表に指定された値
  
  — DDBPartitionKey_name = 構成内のパーティション・キーに指定された値
  
  — DDBPartitionKey_type = 構成内のパーティション・キーのデータ型に指定された値
  
  — DDBSortKey_name = 構成内のソート・キーに指定された値(ある場合)
  
  — DDBSortKey_type = 構成内のソート・キーのデータ型に指定された値(ある場合)
  
  — DOCUMENT = NoSQL JSON列に集計されたDynamo DB表アイテムのパーティションおよびソート・キーを除くすべての属性
  
  ソース形式がCSVファイルの場合、ターゲット表ではデフォルトのスキーマはサポートされていません。ソースCSVファイルと同じ数の列とデータ型を含む表定義を持つスキーマ・ファイルを作成できます。スキーマ・ファイルの作成の詳細は、「表スキーマの提供」を参照してください。
  その他すべてのソースでは、デフォルト・スキーマは次のようになります。
```
CREATE TABLE IF NOT EXISTS <tablename> (ID LONG GENERATED ALWAYS AS IDENTITY, DOCUMENT JSON, PRIMARY KEY(ID))
```
  説明:
  
  — tablename = 構成のtable属性に指定された値。
  
  — ID = 自動生成されたLONG値。
  
  — DOCUMENT = ソースによって提供されるJSONレコードがDOCUMENT列に集計されます。
  
  ノート:
  MongoDB形式のJSONファイルで_id値が文字列として指定されていない場合、NoSQL Database Migratorは、デフォルト・スキーマに挿入する前に値を文字列に変換します。
表スキーマの提供: NoSQL Database Migratorでは、ソースはschemaInfo属性を使用して表データのスキーマ定義を提供できます。schemaInfo属性は、まだ暗黙的スキーマが定義されていないすべてのデータ・ソースで使用できます。シンク・データ・ストアでは、次のオプションのいずれかを選択できます。
- NoSQL Database Migratorで定義されたデフォルトのスキーマを使用します。
- ソース提供のスキーマを使用します。
- 独自のスキーマを定義して、ソース提供のスキーマをオーバーライドします。たとえば、ソース・スキーマから別のスキーマにデータを変換する場合は、ソース提供のスキーマをオーバーライドし、NoSQL Database Migratorツールの変換機能を使用する必要があります。
図source_sink_schema_example.pngの説明

たとえば、表スキーマ・ファイルmytable_schema.ddlには、表DDL文を含めることができます。NoSQL Database Migratorツールは、移行を開始する前にこの表スキーマ・ファイルを実行します。マイグレータ・ツールでは、スキーマ・ファイルの1行に1つのDDL文のみをサポートします。たとえば、次のようになります。
```
CREATE TABLE IF NOT EXISTS(id INTEGER, name STRING, age INTEGER, PRIMARY KEY(SHARD(ID)))
```
ノート:
表がシンクに存在し、schemaPathのDDLが表と異なる場合、移行は失敗します。
シンク表の作成: シンク表スキーマの指定後は、管理CLIまたはシンク構成ファイルのschemaInfo属性を使用してシンク表を作成します。シンク構成テンプレートを参照してください。

ノート:
ソースがCSVファイルの場合は、ターゲット表のスキーマに対するDDLコマンドを使用してファイルを作成します。シンク構成ファイルのschemaInfo.schemaPathパラメータにファイル・パスを指定します。

表の行のTTLメタデータの移行

NoSQL表の移行の実行時に、表の行のTTLメタデータを実際のデータとともに含めるように選択できます。NoSQL Database Migratorには、表の行のTTLメタデータのエクスポートおよびインポートをサポートする構成パラメータが用意されています。さらに、このツールにはインポート操作中に表の行の相対的な有効期限を選択するオプションもあります。オプションで、includeTTLパラメータを使用してTTLメタデータをエクスポートまたはインポートできます。

ノート:

表の行のTTLメタデータ移行のサポートは、Oracle NoSQL DatabaseおよびOracle NoSQL Database Cloud Serviceのみ使用できます。

TTLメタデータのエクスポート

表がエクスポートされると、有効な有効期限を持つ表の行のTTLデータがエクスポートされます。行が失効しない場合、有効期限値は常に0であるため、この行はエクスポートされたデータに明示的に含まれません。TTL情報は、エクスポートされた各行の_metadata JSONオブジェクトに含まれています。NoSQL Database Migratorは、各行の有効期限を、UNIXエポック(1970年1月1日)以降のミリ秒数としてエクスポートします。たとえば、次のようになります。

//Row 1
{
    "id" : 1,
    "name" : "xyz",
    "age" : 45,
    "_metadata" : {
        "expiration" : 1629709200000   //Row Expiration time in milliseconds
    }
}

//Row 2
{
    "id" : 2,
    "name" : "abc",
    "age" : 52,
    "_metadata" : {
        "expiration" : 1629709400000   //Row Expiration time in milliseconds
    }
}

//Row 3 No Metadata for below row as it will not expire
{
    "id" : 3,
    "name" : "def",
    "age" : 15
}

TTLメタデータのインポート

オプションで、構成パラメータincludeTTLを使用してTTLメタデータをインポートできます。インポート操作では、TTLメタデータを含む表の行を移行する際に次のユースケースが処理されます。これらのユースケースは、includeTTL構成パラメータが指定されている場合にのみ適用されます。

ユースケース2および3では、インポート操作のデフォルトの参照時間は、NoSQL Database Migratorツールが実行されているマシンのSystem.currentTimeMillis()から取得された現在の時間(ミリ秒)です。ただし、有効期限を延長し、延長しなければすぐに期限切れになる行をインポートする場合は、ttlRelativeDate構成パラメータを使用してカスタム参照時間を設定することもできます。

ユースケース1: インポートする表の行にTTLメタデータ情報がありません。
外部ソースから生成された、または以前のバージョンの移行を使用してエクスポートされたJSONソース・ファイルをインポートする場合、インポートする行にはTTL情報がありません。ただし、includeTTL構成パラメータはtrueと等しいため、マイグレータは表の行にTTL=0を設定します。つまり、インポートする表の行は失効しません。
ユースケース2: 表の行がインポートされると、ソース表の行のTTL値が参照時間に対して失効します。
表の行をファイルにエクスポートし、これを表の行の有効期限後にインポートしようとすると、表の行は無視され、ストアに書き込まれません。
ユースケース3: 表の行がインポートされると、ソース表の行のTTL値が参照時間に対して失効しません。
表の行をファイルにエクスポートし、これを表の行の有効期限より前にインポートしようとすると、表の行がTTL値でインポートされます。ただし、TimeToLiveクラスの整数時間と日の期間の制約のため、表の行の新しいTTL値はエクスポートされたTTL値と等しくない場合があります。たとえば、次のようになります。
エクスポートされた表の行
```
{
  "id" : 8,
  "name" : "xyz",
  "_metadata" : {
    "expiration" : 1629709200000 //Monday, August 23, 2021 9:00:00 AM in UTC
  }
}
```
インポート中の参照時間は1629707962582で、2021年8月23日月曜日午前8:39:22.582です。
インポートされた表の行
```
{
  "id" : 8,
  "name" : "xyz",
  "_metadata" : {
    "ttl" :  1629712800000 //Monday, August 23, 2021 10:00:00 AM UTC
  }
}
```

IDENTITY列を含むシンクへのデータのインポート

有効なソースからIDENTITY列を含むシンク表(オンプレミス/クラウド・サービス)にデータをインポートできます。IDENTITY列は、GENERATED ALWAYS AS IDENTITYまたはGENERATED BY DEFAULT AS IDENTITYのいずれかとして作成します。IDENTITY列を含む表の作成の詳細は、SQLリファレンス・ガイドのIDENTITY列を含む表の作成を参照してください。

データをインポートする前に、シンクのOracle NoSQL Database表(存在する場合)が空であることを確認してください。シンク表に既存のデータがある場合、移行によって、シンク表の既存のデータの上書きやインポート中のソース・データのスキップなどの問題が発生する可能性があります。

IDENTITY列がGENERATED ALWAYS AS IDENTITYであるシンク表

IDENTITY列がGENERATED ALWAYS AS IDENTITYとして作成されたシンク表について考えます。データ・インポートは、ソースが構成ファイルのIDENTITY列およびignoreFields変換パラメータに値を指定するかどうかによって異なります。

たとえば、JSONファイル・ソースのデータをシンクとしてのOracle NoSQL Database表にインポートします。シンク表のスキーマは次のとおりです:

CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED ALWAYS AS IDENTITY, name STRING, course STRING, PRIMARY KEY
      (ID))

Migratorユーティリティは、次のケースで説明するようにデータ移行を処理します:

ソース条件ユーザー・アクション移行結果

ソース条件	ユーザー・アクション	移行結果
ケース1: ソース・データでシンク表のIDENTITYフィールドに値が指定されていません。例: JSONソース・ファイル`sample_noID.json` `{"name":"John", "course":"Computer Science"} {"name":"Jane", "course":"BioTechnology"} {"name":"Tony", "course":"Electronics"}`	構成ファイルを作成/生成します。	データ移行に成功しました。IDENTITY列の値は自動生成されます。Oracle NoSQL Databaseシンク表`migrateID`にデータを移行しました: `{"ID":1001,"name":"Jane","course":"BioTechnology"} {"ID":1003,"name":"John","course":"Computer Science"} {"ID":1002,"name":"Tony","course":"Electronics"}`
ケース2: ソース・データでシンク表のIDENTITYフィールドに値が指定されます。例: JSONソース・ファイル`sampleID.json` `{"ID":1, "name":"John", "course":"Computer Science"} {"ID":2, "name":"Jane", "course":"BioTechnology"} {"ID":3, "name":"Tony", "course":"Electronics"}`	構成ファイルを作成/生成します。シンク構成テンプレートのID列にignoreFields変換を指定します。 `"transforms" : { "ignoreFields" : ["ID"] }`	データ移行に成功しました。指定されたID値はスキップされ、IDENTITY列の値は自動生成されます。 Oracle NoSQL Databaseシンク表`migrateID`にデータを移行しました: `{"ID":2003,"name":"John","course":"Computer Science"} {"ID":2002,"name":"Tony","course":"Electronics"} {"ID":2001,"name":"Jane","course":"BioTechnology"}`
IDENTITY列のignoreFields変換なしで、構成ファイルを作成/生成します。	データ移行は次のエラー・メッセージで失敗します: `"Cannot set value for a generated always identity column".`

ケース1: ソース・データでシンク表のIDENTITYフィールドに値が指定されていません。

例: JSONソース・ファイルsample_noID.json

{"name":"John", "course":"Computer Science"}
{"name":"Jane", "course":"BioTechnology"}
{"name":"Tony", "course":"Electronics"}

構成ファイルを作成/生成します。

データ移行に成功しました。IDENTITY列の値は自動生成されます。Oracle NoSQL Databaseシンク表migrateIDにデータを移行しました:

{"ID":1001,"name":"Jane","course":"BioTechnology"}
{"ID":1003,"name":"John","course":"Computer Science"}
{"ID":1002,"name":"Tony","course":"Electronics"}

ケース2: ソース・データでシンク表のIDENTITYフィールドに値が指定されます。

例: JSONソース・ファイルsampleID.json

{"ID":1, "name":"John", "course":"Computer Science"}
{"ID":2, "name":"Jane", "course":"BioTechnology"}
{"ID":3, "name":"Tony", "course":"Electronics"}

構成ファイルを作成/生成します。シンク構成テンプレートのID列にignoreFields変換を指定します。

"transforms" : { "ignoreFields" : ["ID"] }

データ移行に成功しました。指定されたID値はスキップされ、IDENTITY列の値は自動生成されます。

Oracle NoSQL Databaseシンク表migrateIDにデータを移行しました:

{"ID":2003,"name":"John","course":"Computer Science"}
{"ID":2002,"name":"Tony","course":"Electronics"}
{"ID":2001,"name":"Jane","course":"BioTechnology"}

IDENTITY列のignoreFields変換なしで、構成ファイルを作成/生成します。

データ移行は次のエラー・メッセージで失敗します:

"Cannot set value for a generated always identity column".

変換構成パラメータの詳細は、「変換構成テンプレート」のトピックを参照してください。

IDENTITY列がGENERATED BY DEFAULT AS IDENTITYであるシンク表

IDENTITY列がGENERATED BY DEFAULT AS IDENTITYとして作成されたシンク表について考えます。データ・インポートは、ソースがIDENTITY列およびignoreFields変換パラメータに値を指定するかどうかによって異なります。

たとえば、JSONファイル・ソースのデータをシンクとしてのOracle NoSQL Database表にインポートします。シンク表のスキーマは次のとおりです:

CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED BY DEFAULT AS IDENTITY, name STRING, course STRING, PRIMARY KEY
      (ID))

Migratorユーティリティは、次のケースで説明するようにデータ移行を処理します:

ソース条件ユーザー・アクション移行結果

ソース条件	ユーザー・アクション	移行結果
ケース1: ソース・データでシンク表のIDENTITYフィールドに値が指定されていません。例: JSONソース・ファイル`sample_noID.json` `{"name":"John", "course":"Computer Science"} {"name":"Jane", "course":"BioTechnology"} {"name":"Tony", "course":"Electronics"}`	構成ファイルを作成/生成します。	データ移行に成功しました。IDENTITY列の値は自動生成されます。Oracle NoSQL Databaseシンク表`migrateID`にデータを移行しました: `{"ID":1,"name":"John","course":"Computer Science"} {"ID":2,"name":"Jane","course":"BioTechnology"} {"ID":3,"name":"Tony","course":"Electronics"}`
ケース2: ソース・データがシンク表のIDENTITYフィールドに値を提供し、これが主キー・フィールドです。例: JSONソース・ファイル`sampleID.json` `{"ID":1, "name":"John", "course":"Computer Science"} {"ID":2, "name":"Jane", "course":"BioTechnology"} {"ID":3, "name":"Tony", "course":"Electronics"}`	構成ファイルを作成/生成します。シンク構成テンプレートのID列にignoreFields変換を指定します(推奨)。 `"transforms" : { "ignoreFields" : ["ID"] }`	データ移行に成功しました。指定されたID値はスキップされ、IDENTITY列の値は自動生成されます。 Oracle NoSQL Databaseシンク表`migrateID`にデータを移行しました: `{"ID":1002,"name":"John","course":"Computer Science"} {"ID":1001,"name":"Jane","course":"BioTechnology"} {"ID":1003,"name":"Tony","course":"Electronics"}`
IDENTITY列のignoreFields変換なしで、構成ファイルを作成/生成します。	データ移行に成功しました。ソースから指定された`ID`値は、シンク表の`ID`列にコピーされます。 ID値を指定せずに表に追加行を挿入しようとすると、順序ジェネレータがID値の自動生成を試みます。シーケンス・ジェネレータの開始値は1です。その結果、生成されたID値がシンク表内の既存のID値のいずれかを複製する可能性があります。これは主キー制約違反であるため、エラーが返され、行は挿入されません。詳細は、順序ジェネレータを参照してください。主キー制約違反を回避するために、順序ジェネレータは、シンク表の既存のID値と競合しない値で順序を開始する必要があります。START WITH属性を使用してこの変更を行うには、次の例を参照してください: 例: Oracle NoSQL Databaseシンク表`migrateID`にデータを移行しました: `{"ID":1,"name":"John","course":"Computer Science"} {"ID":2,"name":"Jane","course":"BioTechnology"} {"ID":3,"name":"Tony","course":"Electronics"}` 順序ジェネレータがID列に挿入する適切な値を検索するには、次の問合せを使用して`ID`フィールドの最大値をフェッチします: `SELECT max(ID) FROM migrateID` 出力: `{"Column_1":3}` シンク表の`ID`列の最大値は3です。複製を避けるために、順序ジェネレータで3を超えるID値の生成を開始する必要があります。次の文を使用して、順序ジェネレータのSTART WITH属性を4に更新します: `ALTER Table migrateID (MODIFY ID GENERATED BY DEFAULT AS IDENTITY (START WITH 4))` これにより、順序は4から開始されます。これで、ID値を指定せずにシンク表に行を挿入すると、順序ジェネレータによってID値が4以降から自動生成され、IDの重複が回避されるようになります。

ケース1: ソース・データでシンク表のIDENTITYフィールドに値が指定されていません。

例: JSONソース・ファイルsample_noID.json

{"name":"John", "course":"Computer Science"}
{"name":"Jane", "course":"BioTechnology"}
{"name":"Tony", "course":"Electronics"}

構成ファイルを作成/生成します。

データ移行に成功しました。IDENTITY列の値は自動生成されます。Oracle NoSQL Databaseシンク表migrateIDにデータを移行しました:

{"ID":1,"name":"John","course":"Computer Science"}
{"ID":2,"name":"Jane","course":"BioTechnology"}
{"ID":3,"name":"Tony","course":"Electronics"}

ケース2: ソース・データがシンク表のIDENTITYフィールドに値を提供し、これが主キー・フィールドです。

例: JSONソース・ファイルsampleID.json

{"ID":1, "name":"John", "course":"Computer Science"}
{"ID":2, "name":"Jane", "course":"BioTechnology"}
{"ID":3, "name":"Tony", "course":"Electronics"}

構成ファイルを作成/生成します。シンク構成テンプレートのID列にignoreFields変換を指定します(推奨)。

"transforms" : { "ignoreFields" : ["ID"] }

データ移行に成功しました。指定されたID値はスキップされ、IDENTITY列の値は自動生成されます。

Oracle NoSQL Databaseシンク表migrateIDにデータを移行しました:

{"ID":1002,"name":"John","course":"Computer Science"}
{"ID":1001,"name":"Jane","course":"BioTechnology"}
{"ID":1003,"name":"Tony","course":"Electronics"}

IDENTITY列のignoreFields変換なしで、構成ファイルを作成/生成します。

データ移行に成功しました。ソースから指定されたID値は、シンク表のID列にコピーされます。

ID値を指定せずに表に追加行を挿入しようとすると、順序ジェネレータがID値の自動生成を試みます。シーケンス・ジェネレータの開始値は1です。その結果、生成されたID値がシンク表内の既存のID値のいずれかを複製する可能性があります。これは主キー制約違反であるため、エラーが返され、行は挿入されません。

詳細は、順序ジェネレータを参照してください。

主キー制約違反を回避するために、順序ジェネレータは、シンク表の既存のID値と競合しない値で順序を開始する必要があります。START WITH属性を使用してこの変更を行うには、次の例を参照してください:

例: Oracle NoSQL Databaseシンク表migrateIDにデータを移行しました:

{"ID":1,"name":"John","course":"Computer Science"}
{"ID":2,"name":"Jane","course":"BioTechnology"}
{"ID":3,"name":"Tony","course":"Electronics"}

順序ジェネレータがID列に挿入する適切な値を検索するには、次の問合せを使用してIDフィールドの最大値をフェッチします:

SELECT max(ID) FROM migrateID

出力:

{"Column_1":3}

シンク表のID列の最大値は3です。複製を避けるために、順序ジェネレータで3を超えるID値の生成を開始する必要があります。次の文を使用して、順序ジェネレータのSTART WITH属性を4に更新します:

ALTER Table migrateID (MODIFY ID GENERATED BY DEFAULT AS IDENTITY (START WITH 4))

これにより、順序は4から開始されます。

これで、ID値を指定せずにシンク表に行を挿入すると、順序ジェネレータによってID値が4以降から自動生成され、IDの重複が回避されるようになります。

変換構成パラメータの詳細は、「変換構成テンプレート」のトピックを参照してください。

runMigratorコマンドの実行

runMigrator実行可能ファイルは、抽出されたNoSQL Database Migratorファイルで使用できます。runMigratorコマンドを正常に実行するには、システムにJava 11以上のバージョンおよびbashをインストールする必要があります。

runMigratorコマンドは、次の2つの方法で実行できます。

次のように、runMigratorコマンドのランタイム・オプションを使用して構成ファイルを作成します。
```
[~]$ ./runMigrator
configuration file is not provided. Do you want to generate configuration? (y/n)                                                                              
 
[n]: y
...
...
```
- runMigratorユーティリティを起動すると、一連のランタイム・オプションが提供され、各オプションの選択内容に基づいて構成ファイルが作成されます。
- ユーティリティによって構成ファイルが作成された後は、同じ実行で移行アクティビティを続行するか、将来の移行のために構成ファイルを保存できます。
- 生成された構成ファイルでの移行アクティビティの続行または延期に関係なく、将来の要件を満たすようにファイルを編集またはカスタマイズできます。カスタマイズした構成ファイルは、後で移行に使用できます。
-cまたは--configオプションを使用して、手動で作成した構成ファイル(JSON形式)を実行時パラメータとして渡します。-cまたは--configオプションを指定してrunMigratorコマンドを実行する前に、構成ファイルを手動で作成する必要があります。ソースとシンクの構成パラメータのヘルプは、ソースとシンクを参照してください。
```
[~]$ ./runMigrator -c </path/to/the/configuration/json/file>
```

Migratorの進捗状況のロギング

NoSQL Database Migratorツールには、トレース、デバッグおよび進行状況のメッセージを標準出力またはファイルに出力できるオプションが用意されています。このオプションは、特に表またはデータ・セットが大規模な場合に、移行操作の進捗状況を追跡するために役立ちます。

ログ・レベル

NoSQL Database Migratorツールを使用してロギング動作を制御するには、--log-levelまたは-l run timeパラメータをrunMigratorコマンドに渡します。書き込むログ情報の量を指定するには、適切なログ・レベルの値を渡します。

$./runMigrator --log-level <loglevel>

次に例を示します。

$./runMigrator --log-level debug

表5-1 NoSQL Database Migratorでサポートされるログ・レベル

ログ・レベル	説明
warning	エラーおよび警告を出力します。
info (デフォルト)	ソースの検証、シンクの検証、表の作成、移行されたデータ・レコードの数など、データ移行の進捗状況ステータスを出力します。
debug	追加のデバッグ情報を出力します。
all	すべてを出力します。このレベルはロギングのすべてのレベルをオンにします。

ログ・ファイル:
--log-fileまたは-fパラメータを使用して、ログ・ファイルの名前を指定できます。--log-fileがランタイム・パラメータとしてrunMigratorコマンドに渡された場合、NoSQL Database Migratorはすべてのログ・メッセージをファイルに、それ以外の場合は標準出力に書き込みます。
```
$./runMigrator --log-file <log file name>
```
次に例を示します。
```
$./runMigrator --log-file nosql_migrator.log
```