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メタデータの移行

存続時間(TTL)は、表の行を自動的に期限切れにするためのメカニズムです。TTLは、データがストア内に存続できる時間として表されます。有効期限タイムアウト値に達したデータは取得できなくなり、ストア統計に表示されなくなります。

Oracle NoSQL Database表の移行の実行時に、表行のTTLメタデータを実際のデータとともに含めることを選択できます。NoSQL Database Migratorでは、次のソース・タイプについて、表行のTTLメタデータのエクスポートとインポートをサポートする構成パラメータが用意されています:

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

ソース・タイプ	ソース構成パラメータ	シンク構成パラメータ
Oracle NoSQL Database	`includeTTL`	`includeTTL`
Oracle NoSQL Database Cloud Service	`includeTTL`	`includeTTL`
DynamoDB形式のJSONファイル	`ttlAttributeName`	`includeTTL`
AWS S3に格納されたDynamoDB形式のJSONファイル	`ttlAttributeName`	`includeTTL`

Oracle NoSQL DatabaseとOracle NoSQL Database Cloud ServiceでのTTLメタデータのエクスポート

NoSQL Database Migratorでは、表行のTTLメタデータのエクスポートをサポートするincludeTTL構成パラメータが用意されています。

表がエクスポートされるときに、有効な期限がある表行について、TTLデータがエクスポートされます。行の期限がない場合、その期限値は必ず0であるため、その_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メタデータをインポートできます。

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

Extended time = expiration time - reference time

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

ユースケース1: インポートする表の行にTTLメタデータ情報がありません。
インポートする行にTTL情報が含まれていない場合は、NoSQL Database Migratorによって、その行についてTTL=0が設定されます。
ユースケース2: ソース表の行のTTL値が、その表行がインポートされるときに、参照時間に対して期限切れになっています。
期限切れになった表行は無視され、ストアに書き込まれません。
ユースケース3: ソース表の行のTTL値が、その表行がインポートされるときに、参照時間に対して期限切れになっていません。
その表行はTTL値とともにインポートされます。ただし、インポートしたTTL値は、TimeToLiveクラスでの、整数の時間と日による時間枠制約が原因で、元のエクスポートしたTTL値と一致しない場合があります。たとえば、次のようになります。
エクスポートした表行について考えてみます:
```
{
  "id" : 8,
  "name" : "xyz",
  "_metadata" : {
  "expiration" : 1734566400000 //Thursday, December 19, 2024 12:00:00 AM in UTC
  }
}
```
インポート中の参照時間は1734480000000であり、これは2024年12月18日水曜日の午前12:00:00です。
インポートされた表の行
```
{
  "id" : 8,
  "name" : "xyz",
  "_metadata" : {
    "ttl" :  1734739200000 //Saturday, December 21, 2024 12:00:00 AM
  }
}
```

DynamoDB形式のJSONファイル内およびAWS S3に格納されたDynamoDB形式のJSONファイル内のTTLメタデータのインポート

NoSQL Database Migratorでは、DynamoDB形式のJSONファイルのアイテムからのTTLメタデータのインポートをサポートする構成パラメータttlAttributeNameがさらに用意されています。

DynamoDBのエクスポートしたJSONファイルには、TTL有効期限タイムスタンプを格納するために、各アイテムに特定の属性が含まれています。オプションで、DynamoDBのエクスポートしたJSONファイルからTTL値をインポートするには、DynamoDB形式のJSONファイルまたはAWS S3に格納されたDynamoDB形式のJSONファイルのソース構成ファイルで、ttlAttributeName構成パラメータに値としてその特定の属性の名前を指定する必要があります。また、シンク構成テンプレートでincludeTTL構成パラメータを設定する必要があります。有効なシンクは、Oracle NoSQL DatabaseとOracle NoSQL Database Cloud Serviceです。NoSQL Database Migratorにより、インポートしたアイテムの_metadata JSONオブジェクトにTTL情報が格納されます。

このインポート操作では、DynamoDBのエクスポートしたJSONファイルの表アイテムを移行するときの次のようなユースケースに対処できます:

ユースケース1: ttlAttributeName構成パラメータ値が、DynamoDBのエクスポートしたJSONファイルで指定されているTTL属性名に設定されています。

NoSQL Database Migratorによって、このアイテムの有効期限が、UNIXエポック(1970年1月1日)からのミリ秒数としてインポートされます。
たとえば、DynamoDBのエクスポートしたJSONファイル内のアイテムについて考えてみます:
```
{
    "Item": {
        "DeptId": {
            "N": "1"
        },
        "DeptName": {
            "S": "Engineering"
        },
        "ttl": {
            "N": "1734616800"
        }
    }
}
```
ここでは、属性ttlで、アイテムの存続時間値が指定されています。DynamoDB形式のJSONファイルまたはAWS S3に格納されたDynamoDB形式のJSONファイルのソース構成ファイル内でttlAttributeName構成パラメータをttlとして設定した場合は、NoSQL Database Migratorによって、次のようにそのアイテムの有効期限がインポートされます:
```
{
  "DeptId": 1,
  "document": {
      "DeptName": "Engineering"
    }  
  "_metadata": {
    "expiration": 1734616800000
  }
}
```
ノート:
有効期限を計算するための参照時間として、シンク構成テンプレートでttlRelativeDate構成パラメータを指定できます。
ユースケース2: ttlAttributeName構成パラメータ値が設定されていますが、この値は、DynamoDBのエクスポートしたJSONファイルのアイテムに属性として存在していません。
NoSQL Database Migratorにより、指定されたアイテムのTTLメタデータ情報はインポートされません。
ユースケース3: ttlAttributeName構成パラメータ値が、DynamoDBのエクスポートしたJSONファイルのアイテムでの属性名と一致していません。
NoSQL Database Migratorにより、シンク構成に基づいて、次のいずれかの方法でインポートが処理されます:
- デフォルト・スキーマを使用してインポートするように構成されている場合は、その属性を標準フィールドとしてコピーします。
- ユーザー定義スキーマを使用してインポートするように構成されている場合は、その属性をスキップします。

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

表1-2 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
```