plan
ストア状態を変更する作業またはジョブをカプセル化します。interruptおよびwait以外のすべてのサブコマンドが永続的な状態を変更します。プランは非同期ジョブであるため、-wait
が使用されていなければすぐに返されます。プラン・ステータスはshow plans
を使用してチェックできます。すべてのプラン用のオプションの引数は、次のとおりです。
-
-wait
プランが返される前に終了するまで待機します。
-
-plan-name
プランの名前。これらは一意です。
-
-noexecute
プランを実行しません。指定された場合、プランは後で
plan execute
を使用して実行できます。 -
-force
プラン実行およびプラン再試行を強制実行するために使用されます。
-
-json | -json-v1
プランの出力をjsonまたはjson-v1として表示します。
-json
フラグを使用すると、新しいjson形式で出力できます。-json-v1
フラグを使用すると、json-v1形式で出力できます。古いバージョンのJSON出力に依存する既存のスクリプトがある場合は、既存のスクリプトが引き続き機能するように、-json-v1
フラグの使用を検討できます。
サブコマンドは次のとおりです。
plan add-index
plan add-index -name <name> -table <name> [-field <name>]*
[-desc <description>]
[-plan-name <name>] [-wait] [-noexecute] [-force]
ストア内の表に索引を追加します。
説明:
-
-name
表に追加する索引の名前を指定します。
-
-table
索引を追加する表名を指定します。表名はピリオドで区切られた名前で、フォーマットは
tableName[.childTableName]*
です。 -
-field
主キーのフィールド値を指定します。
plan add-table
plan add-table -name <name>
[-plan-name <name>] [-wait] [-noexecute] [-force]
ストアに新しい表を追加します。表名はピリオドで区切られた名前で、フォーマットはtableName[.childTableName]*
です。
表を追加する前に、まずtable create
コマンドを使用して指定された表を作成します。次の例では、表を定義します(名前で表を作成し、フィールドおよびその他の表メタデータを追加します)。
## Enter into table creation mode
table create -name user -desc "A sample user table"
user->
user-> help
Usage: add-array-field |
add-field |
add-map-field |
add-record-field |
cancel |
exit |
primary-key |
remove-field |
set-description |
shard-key |
show
## Now add the fields
user-> help add-field
Usage: add-field -type <type> [-name <field-name> ] [-not-required]
[-nullable] [-default <value>] [-max <value>] [-min <value>]
[-max-exclusive] [-min-exclusive] [-desc <description>]
[-size <size>] [-enum-values <value[,value[,...]]
<type>: INTEGER, LONG, DOUBLE, FLOAT, STRING, BOOLEAN, DATE, BINARY, FIX
ED_BINARY, ENUM
## Adds a field. Ranges are inclusive with the exception of String,
## which will be set to exclusive.
user-> add-field -type Integer -name id
user-> add-field -type String -name firstName
user-> add-field -type String -name lastName
user-> help primary-key
Usage: primary-key -field <field-name> [-field <field-name>]*
## Sets primary key.
user-> primary-key -field id
## Exit table creation mode
user-> exit
## Table User built.
table list -create
を使用すると、追加できる表の一覧を表示します。次の例はデプロイメントの準備が整っている表を一覧表示します。
kv-> table list
## Tables to be added:
## User -- A sample user table
kv-> table list -name user
## Add table User:
{
"type" : "table",
"name" : "User",
"id" : "User",
"description" : "A sample user table",
"shardKey" : [ "id" ],
"primaryKey" : [ "id" ],
"fields" : [ {
"name" : "id",
"type" : "INTEGER"
}, {
"name" : "firstName",
"type" : "STRING"
}, {
"name" : "lastName",
"type" : "STRING"
} ]
}
次の例では、ストアに表を追加します。
## Add the table to the store.
kv-> help plan add-table
kv-> plan add-table -name user -wait
Executed plan 5, waiting for completion...
Plan 5 ended successfully
kv-> show tables -name user
{
"type" : "table",
"name" : "User",
"id" : "r",
"description" : "A sample user table",
"shardKey" : [ "id" ],
"primaryKey" : [ "id" ],
"fields" : [ {
"name" : "id",
"type" : "INTEGER"
}, {
"name" : "firstName",
"type" : "STRING"
}, {
"name" : "lastName",
"type" : "STRING"
} ]
}
表設計の詳細と例は、SQLリファレンス・ガイドの表の管理を参照してください。
plan cancel
plan cancel -id <plan id> | -last - json
実行中ではないプランを取り消します。実行中のプランを取り消すにはその前に中断する必要があります。
show plans
を使用して、対応するプランIDおよびステータスとともに作成されているすべてのプランを一覧表示します。
-last
オプションを使用して、最も最近作成されたプランを参照します。kv-> plan cancel -id 23 -json
{
"operation" : "plan cancel|interrupt",
"returnCode" : 5000,
"description" : "Plan 23 was canceled",
"returnValue" : null
}
plan change-parameters
plan change-parameters -security | -service <id> |
-all-rns [-zn <id> | -znname <name>] | -all-ans [-zn <id> |
-znname <name>] | -all-admins [-zn <id> | -znname <name>]
[-dry-run] [-plan-name <name>]
[-json] [-wait] [-noexecute] [-force] -params [name=value]*
指定されたゾーンまたはすべてのゾーンにデプロイされた、指定されたサービスまたは同じタイプのすべてのサービス・インスタンスのパラメータを変更します。
-security
フラグにより、ストア全体のグローバル・セキュリティ・パラメータの変更が可能です。他のフラグとともに使用しないでください。
-service
フラグにより、単一インスタンスが影響を受けるようにできます。-zn
または-znname
フラグとともに使用しないでください。
-all-*
フラグは、サービス・タイプのすべてのインスタンスを変更する際に使用できます。変更するパラメータは-params
フラグの後に続き、スペースで区切られます。スペースが埋め込まれたパラメータ値は、name="value with spaces"のように引用符で囲む必要があります。
-all-*フラグの1つを-znまたは-znnameフラグを組み合せて、指定されたゾーンにデプロイされたサービス・タイプのすべてのインスタンスを変更できます。別のゾーンにデプロイされた指定タイプのインスタンスは変更しません。-all-*フラグの1つがゾーンを指定せずに使用された場合、必要なパラメータ変更は、ゾーンに関係なくストア内の指定されたタイプのすべてのインスタンスに適用されます。
-dry-run
が指定された場合、新規パラメータが変更されずに返されます。変更できるパラメータを表示するには、コマンドshow parameters
を使用します。詳細は、「show parameters」を参照してください。
ストア内のパラメータの変更の詳細は、「ストアのパラメータの設定」を参照してください。
注意:
plan change-parameters
は、コンポーネントが使用できない場合でも、ストア・メタデータ・データベースを更新します。コンポーネントの構成の不整合がKVStoreシステムによって検出されると、整合性がとられます。
kv-> plan change-parameters -service rg1-rn2 -json -wait -params
loggingConfigProps="oracle.kv.level=DEBUG"
{
"operation" : "Change RepNode Params",
"returnCode" : 5000,
"description" : "Operation ends successfully",
"returnValue" : {
"id" : 20,
"owner" : "root(id:u1)",
"name" : "Change RepNode Params",
"isDone" : true,
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:31:05 UTC",
"interrupted" : null,
"end" : "2017-09-28 05:31:10 UTC",
"error" : null,
"executionDetails" : {
"taskCounts" : {
"total" : 4,
"successful" : 4,
"failed" : 0,
"interrupted" : 0,
"incomplete" : 0,
"notStarted" : 0
},
"finished" : [ {
"taskNum" : 1,
"name" : "Plan 20 [Change RepNode Params] task [WriteNewParams rg1-rn2]",
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:31:05 UTC",
"end" : "2017-09-28 05:31:06 UTC"
}, {
"taskNum" : 2,
"name" : "Plan 20 [Change RepNode Params] task [StopNode rg1-rn2]",
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:31:06 UTC",
"end" : "2017-09-28 05:31:07 UTC"
}, {
"taskNum" : 3,
"name" : "Plan 20 [Change RepNode Params] task [StartNode]",
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:31:07 UTC",
"end" : "2017-09-28 05:31:07 UTC"
}, {
"taskNum" : 4,
"name" : "Plan 20 [Change RepNode Params] task [WaitForNodeState rg1-rn2 to reach RUNNING]",
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:31:07 UTC",
"end" : "2017-09-28 05:31:10 UTC"
} ],
"running" : [ ],
"pending" : [ ]
}
}
}
plan change-storagedir
plan change-storagedir -sn <id> -storagedir <path> -add | -remove
[-storagedirsize <size>] [-plan-name <name>] [-json] [-wait] [-noexecute]
[-force]
レプリケーション・ノードを格納するために、ストレージ・ノード上のストレージ・ディレクトリを追加または削除します。
説明:
-
-sn
ストレージ・ディレクトリを追加または削除するストレージ・ノードを指定します。
-
-storagedir
レプリケーション・ノードを格納するためのストレージ・ノード上のストレージ・ディレクトリへのパスを指定します。
-
-add | -remove
ストレージ・ディレクトリを追加(
-add)
するように指定します。ストレージ・ディレクトリを削除(
-remove
)するように指定します。 -
-storagedirsize
-storagedir
で指定したディレクトリのサイズを指定します。このパラメータはオプションです。ただし、すべてのストレージ・ディレクトリではありませんが、一部については、このパラメータを指定するとエラーになります。一部のハードウェアのストレージ容量が他のハードウェアよりも大きい異種インストール環境については、このパラメータを使用することをお薦めします。すべてのストレージ・ディレクトリについてこのパラメータを指定した場合、ストアのトポロジによって、記憶域が大きいシャードにより多くのデータが配置されます。このパラメータを使用しない場合は、すべてのシャード間でデータが均等に分散されます。
このパラメータに指定する値はlongである必要があり、オプションで、その後に単位文字列を付けることができます。使用可能な単位文字列は、KB、MB、GBおよびTBです(それぞれ1024、1024^2、1024^3、1024^4に対応)。指定可能な文字列では大/小文字は区別されません。long値と単位文字列の間の有効なデリミタは、「 」、「-」または「_」です。
-storagedirsize 200 MB -storagedirsize 4_tb -storagedirsize 5000-Mb kv-> plan change-storagedir -sn sn2 -storagedir /tmp/kvroot -add -json -wait { "operation" : "Change Storage Node Params", "returnCode" : 5000, "description" : "Operation ends successfully", "returnValue" : { "id" : 21, "owner" : "root(id:u1)", "name" : "Change Storage Node Params", "isDone" : true, "state" : "SUCCEEDED", "start" : "2017-09-28 05:33:14 UTC", "interrupted" : null, "end" : "2017-09-28 05:33:14 UTC", "error" : null, "executionDetails" : { "taskCounts" : { "total" : 1, "successful" : 1, "failed" : 0, "interrupted" : 0, "incomplete" : 0, "notStarted" : 0 }, "finished" : [ { "taskNum" : 1, "name" : "Plan 21 [Change Storage Node Params] task [WriteNewSNParams sn2]", "state" : "SUCCEEDED", "start" : "2017-09-28 05:33:14 UTC", "end" : "2017-09-28 05:33:14 UTC" } ], "running" : [ ], "pending" : [ ] } } }
plan change-user
plan change-user -name <user name>
[-disable | -enable] [-set-password [-password <new password>]
[-retain-current-password]] [-clear-retained-password]
[-plan-name <name>] [-wait] [-noexecute] [-force]
ストアで指定された名前でユーザーを変更します。-retain-current-password引数オプションによって、構成された保存時間の間または-clear-retained-passwordを使用して消去されるまで、-set-password操作で有効な代替パスワードとして現行パスワードを保持します。保持されたパスワードがすでにユーザーに設定されている場合、再度パスワードを設定するとエラーが発生し、レポートされます。
このコマンドは非推奨です。詳細は、セキュリティ・ガイドのユーザーの変更を参照してください。
plan create-user
plan create-user -name <user name>
[-admin] [-disable] [-password <new password>]
[-plan-name <name>] [-wait] [-noexecute] [-force]
ストアで指定された名前でユーザーを作成します。-admin引数は作成されたユーザーに完全な管理者権限があることを示します。
このコマンドは非推奨です。詳細は、セキュリティ・ガイドのユーザーの作成を参照してください。
plan deploy-admin
plan deploy-admin -sn <id> [-plan-name <name>]
[-wait] [-noexecute] [-force]
指定されたストレージ・ノードにAdminをデプロイします。管理のタイプ(PRIMARY/SECONDARY)は、ストレージ・ノードが置かれているゾーンのタイプと同じです。
kv-> plan deploy-admin -sn sn1 -json -wait
"operation" : "plan deploy-admin -sn 1",
"returnCode" : 5000,
"description" : "Operation ends successfully",
"returnValue" : {
"id" : 22,
"owner" : "root(id:u1)",
"name" : "Deploy Admin Service",
"isDone" : true,
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:34:26 UTC",
"interrupted" : null,
"end" : "2017-09-28 05:34:27 UTC",
"error" : null,
"executionDetails" : {
"taskCounts" : {
"total" : 4,
"successful" : 4,
"failed" : 0,
"interrupted" : 0,
"incomplete" : 0,
"notStarted" : 0
},
"finished" : [ {
"taskNum" : 1,
"name" : "Plan 22 [Deploy Admin Service] task [DeployAdmin admin1 on sn1]",
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:34:26 UTC",
"end" : "2017-09-28 05:34:27 UTC"
}, {
"taskNum" : 2,
"name" : "Plan 22 [Deploy Admin Service] task [WaitForAdminState admin1 to reach RUNNING]",
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:34:27 UTC",
"end" : "2017-09-28 05:34:27 UTC"
}, {
"taskNum" : 3,
"name" : "Plan 22 [Deploy Admin Service] task [UpdateAdminHelperHost admin1]",
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:34:27 UTC",
"end" : "2017-09-28 05:34:27 UTC"
}, {
"taskNum" : 4,
"name" : "Plan 22 [Deploy Admin Service] task [NewAdminParameters refresh admin1 parameter state
without restarting]",
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:34:27 UTC",
"end" : "2017-09-28 05:34:27 UTC"
} ],
"running" : [ ],
"pending" : [ ]
},
"planId" : 22,
"resourceId" : "admin1",
"snId" : "sn1"
}
}
plan deploy-sn
plan deploy-sn -zn <id> | -znname <name> -host <host> -port <port>
[-plan-name <name>] [-json] [-wait] [-noexecute] [-force]
指定されたホストおよびポートにおけるストレージ・ノードを指定されたゾーンにデプロイします。
説明:
-
-sn
デプロイするストレージ・ノードを指定します。
-
-zn <id> | -znname <name>
ストレージ・ノードをデプロイするゾーンを指定します。
-
-host
ストレージ・ノードをデプロイするホスト名を指定します。
-
-port
ホストのポート番号を指定します。
ストレージ・ノードのデプロイの詳細は、「残りのストレージ・ノードの作成」を参照してください。
kv-> plan deploy-sn -zn 1 -json -host localhost -port 10000 -wait
{
"operation" : "plan deploy-sn -zn 1 -host localhost -port 10000",
"returnCode" : 5000,
"description" : "Operation ends successfully",
"returnValue" : {
"id" : 25,
"owner" : "root(id:u1)",
"name" : "Deploy Storage Node",
"isDone" : true,
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:40:50 UTC",
"interrupted" : null,
"end" : "2017-09-28 05:40:51 UTC",
"error" : null,
"executionDetails" : {
"taskCounts" : {
"total" : 1,
"successful" : 1,
"failed" : 0,
"interrupted" : 0,
"incomplete" : 0,
"notStarted" : 0
},
"finished" : [ {
"taskNum" : 1,
"name" : "Plan 25 [Deploy Storage Node] task [DeploySN sn4(localhost:10000)]",
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:40:50 UTC",
"end" : "2017-09-28 05:40:51 UTC"
} ],
"running" : [ ],
"pending" : [ ]
},
"planId" : 25,
"resourceId" : "sn4",
"zoneId" : "zn1",
"host" : "localhost",
"port" : 10000
}
}
plan deploy-topology
plan deploy-topology -name <topology name> [-plan-name <name>]
[-json] [-wait] [-noexecute] [-force]
指定されたトポロジをストアにデプロイします。KVStoreのサイズによって、このコマンドがレプリケーションおよびアービタ・ノードをデプロイして、それらが完全に機能するシャード・メンバーになるまでに要する時間が決まります。plan deploy-topology
コマンドは、このコマンドの終了を待機しません。
plan deploy-topology
コマンドを実行したら、verify configuration
コマンドを使用して、トポロジ内のコンポーネントの実行状態をチェックしてください。トポロジ候補のデプロイを参照してください。
kv-> plan deploy-topology -name MyStoreLayout -json -wait
{
"operation" : "plan deploy-topology -name MyStoreLayout",
"returnCode" : 5000,
"description" : "Operation ends successfully",
"returnValue" : {
"id" : 26,
"owner" : "root(id:u1)",
"name" : "Deploy Topo",
"isDone" : true,
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:56:25 UTC",
"interrupted" : null,
"end" : "2017-09-28 05:56:26 UTC",
"error" : null,
"executionDetails" : {
"taskCounts" : {
"total" : 6,
"successful" : 6,
"failed" : 0,
"interrupted" : 0,
"incomplete" : 0,
"notStarted" : 0
},
"finished" : [ {
"taskNum" : 1,
"name" : "Plan 26 [Deploy Topo] task [UpdateDatacenterV2 zone=zn1]",
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:56:25 UTC",
"end" : "2017-09-28 05:56:25 UTC"
}, {
"taskNum" : 2,
"name" : "Plan 26 [Deploy Topo] task [UpdateDatacenterV2 zone=zn2]",
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:56:25 UTC",
"end" : "2017-09-28 05:56:25 UTC"
}, {
"taskNum" : 3,
"name" : "Plan 26 [Deploy Topo] task [UpdateDatacenterV2 zone=zn3]",
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:56:25 UTC",
"end" : "2017-09-28 05:56:25 UTC"
}, {
"taskNum" : 4,
"name" : "Plan 26 [Deploy Topo] task [BroadcastTopo]",
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:56:25 UTC",
"end" : "2017-09-28 05:56:26 UTC"
}, {
"taskNum" : 5,
"name" : "Plan 26 [Deploy Topo] task [BroadcastMetadata]",
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:56:26 UTC",
"end" : "2017-09-28 05:56:26 UTC"
}, {
"taskNum" : 6,
"name" : "Plan 26 [Deploy Topo] task [BroadcastTopo]",
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:56:26 UTC",
"end" : "2017-09-28 05:56:26 UTC"
} ],
"running" : [ ],
"pending" : [ ]
},
"planId" : 26,
"topoName" : "MyStoreLayout"
}
}
plan deploy-zone
plan deploy-zone -name <zone name>
-rf <replication factor>
[-type [primary | secondary]]
[-arbiters | -no-arbiters]
[-json ]
[–master-affinity | –no-master-affinity]
[-plan-name <name>] [-wait] [-noexecute] [-force]
-type
を指定しない場合、指定したゾーンがストアにデプロイされ、プライマリ・ゾーンが作成されます。
説明:
-
-name
デプロイするゾーンの名前を指定します。
-
-rf
ゾーンのレプリケーション係数を指定します。
-
-type
デプロイするゾーンのタイプを指定します。プライマリ・ゾーンまたはセカンダリ・ゾーンにすることができます。-typeを指定しない場合は、プライマリ・ゾーンがデプロイされます。
-
-json
コマンド出力の形式をJSONに設定します。
-
-arbiters | -no-arbiters
-arbiters
を指定すると、ゾーン内のストレージ・ノードにアービタ・ノードを割り当てることができます。このフラグは、プライマリ・ゾーンでのみ指定できます。-no-arbiters
を指定すると、ゾーン内のストレージ・ノードにアービタ・ノードを割り当てることはできません。デフォルト値は
-no-arbiters
です。 -
-master—affinity | -no-master-affinity
-master-affinity
を指定すると、このゾーンがマスターをホストできることを示します。-no-master-affinity
を指定すると、このゾーンがマスターをホストできないことを示します。デフォルト値は
-no-master-affinity
です。
ゾーンの作成に関する詳細は、「ゾーンの作成」を参照してください。
kv-> plan deploy-zone -name zn6 -rf 1 -json -wait
{
"operation" : "plan deploy-zone -name zn6 -rf 1 -type PRIMARY -no-arbiters -no-master-affinity",
"returnCode" : 5000,
"description" : "Operation ends successfully",
"returnValue" : {
"id" : 27,
"owner" : "root(id:u1)",
"name" : "Deploy Zone",
"isDone" : true,
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:57:29 UTC",
"interrupted" : null,
"end" : "2017-09-28 05:57:29 UTC",
"error" : null,
"executionDetails" : {
"taskCounts" : {
"total" : 1,
"successful" : 1,
"failed" : 0,
"interrupted" : 0,
"incomplete" : 0,
"notStarted" : 0
},
"finished" : [ {
"taskNum" : 1,
"name" : "Plan 27 [Deploy Zone] task [DeployDatacenter zone=zn6]",
"state" : "SUCCEEDED",
"start" : "2017-09-28 05:57:29 UTC",
"end" : "2017-09-28 05:57:29 UTC"
} ],
"running" : [ ],
"pending" : [ ]
},
"planId" : 27,
"zoneName" : "zn6",
"zoneId" : "zn4",
"type" : "PRIMARY",
"rf" : 1,
"allowArbiters" : false,
"masterAffinity" : false
}
}
plan deregister-es
plan deregister-es
deregister-es
planコマンドを使用して、ElasticsearchクラスタをOracle NoSQL Databaseストアから登録解除します。これは、plan remove-index
コマンドを使用してすべての全文索引を最初に削除した場合にのみ可能です。plan remove-indexを参照してください。
次に例を示します。
kv-> plan deregister-es
Cannot deregister ES because these text indexes exist:
mytestIndex
JokeIndex
詳細は、統合ガイドの全文検索のためのエラスティック・サーチとの統合を参照してください。
plan drop-user
plan drop-user -name <user name>
[-plan-name <name>] [-wait] [-noexecute] [-force]
ストア内の指定された名前でユーザーを削除します。ログイン・ユーザーは自身を削除することはできません。
このコマンドは非推奨です。詳細は、セキュリティ・ガイドのユーザーの削除を参照してください。
plan enable-requests
このコマンドは、一連のシャードまたはストア全体によってサポートされているユーザー・リクエストのタイプを変更します。
plan enable-requests
-request-type {all|readonly|none}
{-shards <shardId[,shardId]*> | -store}
[-plan-name <name>] [-wait]
[-noexecute] [-force]
[-json|-json-v1]
特定のシャードまたはストア全体に対して有効なリクエストのタイプを制限します。
-request-type
フラグは、読取りおよび書込みリクエストを構成します。このコマンドでは、次のリクエスト・タイプを構成できます。
- allは、ストアまたはシャードが読取りリクエストと書込みリクエストの両方を処理できることを意味します。
- readonlyは、ストアまたはシャードが読取りリクエストにのみ応答するようにします。
- noneは、ストアまたはシャードが読取りまたは書込みリクエストを処理しないことを意味します。
-shards
フラグは、構成を1つ以上のシャードで実行する場合に構成するシャードのリストを指定します。shardid
の詳細を取得するには、show topology
コマンドを実行します。トポロジ表示出力のrgXX
部分は、shardid
を示します。show topologyを参照してください。
-store
フラグは、ストア全体で構成を実行することを指定します。
-shard
フラグまたは-store
フラグを指定する必要があります。
例B-1 plan enable-requests
たとえば、シャードrg1を読取り専用モードにする場合は、shardid
としてrg1
を指定し、request-type
としてreadonly
を指定します。
kv-> plan enable-requests
-request-type readonly -shards rg1
Started plan 25. Use show plan -id 25 to check status.
To wait for completion, use plan wait -id 25
例B-2 plan enable-requests
たとえば、ストア全体を読取り専用モードにしてjson形式で出力を取得する場合は、store
属性、request-type
属性をreadonly
およびjson
属性として指定します。
kv-> plan enable-requests
-request-type readonly -store -json
{
"operation" : "plan enable-requests",
"returnCode" : 5000,
"description" : "Operation ends successfully",
"returnValue" : {
"planId" : 26
}
}
例B-3 plan enable-requests
たとえば、ストア全体を読取り専用モードにし、json v1形式で出力を取得する場合は、store
属性、request-type
属性をreadonly
およびjson-v1
属性として指定します。
kv-> plan enable-requests
-request-type readonly -store -json-v1
{
"operation" : "plan enable-requests",
"return_code" : 5000,
"description" : "Operation ends successfully",
"return_value" : {
"plan_id" : 27
}
}
plan evolve-table
plan evolve-table -name <name>
[-plan-name <name>] [-wait] [-noexecute] [-force]
ストア内で表を展開します。表名はピリオドで区切られ、フォーマットはtableName[.childTableName]*
です。
table evolve
コマンドを使用して、指定された表を展開します。次の例では、表を展開しています。
## Enter into table evolution mode
kv-> table evolve -name User
kv-> show
{
"type" : "table",
"name" : "User",
"id" : "r",
"description" : "A sample user table",
"shardKey" : [ "id" ],
"primaryKey" : [ "id" ],
"fields" : [ {
"name" : "id",
"type" : "INTEGER"
}, {
"name" : "firstName",
"type" : "STRING"
}, {
"name" : "lastName",
"type" : "STRING"
} ]
}
## Add a field
kv-> add-field -type String -name address
## Exit table creation mode
kv-> exit
## Table User built.
kv-> plan evolve-table -name User -wait
## Executed plan 6, waiting for completion...
## Plan 6 ended successfully
kv-> show tables -name User
{
"type" : "table",
"name" : "User",
"id" : "r",
"description" : "A sample user table",
"shardKey" : [ "id" ],
"primaryKey" : [ "id" ],
"fields" : [ {
"name" : "id",
"type" : "INTEGER"
}, {
"name" : "firstName",
"type" : "STRING"
}, {
"name" : "lastName",
"type" : "STRING"
}, {
"name" : "address",
"type" : "STRING"
} ]
}
table list -evolve
を使用すると、展開できる表の一覧を表示します。詳細は「plan add-table」を参照してください。
plan execute
plan execute -id <id> | -last
[-plan-name <name>] [-json] [-wait] [-noexecute] [-force]
まだ実行されていない既存のプランを実行します。プランは、-noexecute
フラグを使用して事前に作成されているはずです。
-last
オプションを使用して、最も最近作成されたプランを参照します。
kv-> plan execute -id 19 -json -wait
{
"operation" : "plan deploy-zone -name zn6 -rf 1 -type PRIMARY -no-arbiters -no-master-affinity",
"returnCode" : 5000,
"description" : "Operation ends successfully",
"returnValue" : {
"id" : 19,
"name" : "Deploy Zone",
"isDone" : true,
"state" : "SUCCEEDED",
"start" : "2017-09-28 09:35:31 UTC",
"interrupted" : null,
"end" : "2017-09-28 09:35:31 UTC",
"error" : null,
"executionDetails" : {
"taskCounts" : {
"total" : 1,
"successful" : 1,
"failed" : 0,
"interrupted" : 0,
"incomplete" : 0,
"notStarted" : 0
},
"finished" : [ {
"taskNum" : 1,
"name" : "Plan 19 [Deploy Zone] task [DeployDatacenter zone=zn6]",
"state" : "SUCCEEDED",
"start" : "2017-09-28 09:35:31 UTC",
"end" : "2017-09-28 09:35:31 UTC"
} ],
"running" : [ ],
"pending" : [ ]
},
"planId" : 19,
"zoneName" : "zn6",
"zoneId" : "zn4",
"type" : "PRIMARY",
"rf" : 1,
"allowArbiters" : false,
"masterAffinity" : false
}
}
plan failover
plan failover { [-zn <zone-id> | -znname <zone-name>]
-type [primary | offline-secondary] }...
[-plan-name <name>] [-wait] [-noexecute] [-force]
説明:
-
-zn <zone-id> | -znname <zone-name>
ゾーンは、ゾーンIDか名前で指定します。
-
-type [primary | offline-secondary]
関連するゾーンの新しいタイプを指定します。
プライマリ・ゾーンで障害が発生して定数が失われた場合は常に、ゾーン・タイプを変更してプライマリまたはセカンダリ・ゾーンにフェイルオーバーします。アービタが作成されたり、トポロジから削除されることはありません。アービタを含むゾーンをセカンダリ-オフラインとして指定した場合、このコマンドによって違反が発生することがあります。アービタ違反が発生する場合は、forceフラグを使用してください。
新しいタイプがprimaryのゾーンは、障害が発生したプライマリ・ゾーンを引き継いで定数を再確立します。これらのゾーンについては、ゾーン内の各シャードのストレージ・ノードの定数が使用可能であり、リクエストに応答している必要があります。
新タイプがoffline-secondaryのゾーンは、現在オフラインになっているプライマリ・ゾーンに対応します(これによって現在の定数不足が生じています)。このようなゾーンでは、ゾーン内のストレージ・ノードすべてが現在使用できません。コマンドの開始時にこのような要件が満たされない場合、ゾーン・タイプの変更を実行することはできません。
注意:
アービタ・ノードは現在、フェイルオーバーおよびスイッチオーバー操作中にはサポートされていません。
トポロジ・コンポーネントが修復された後に違反を修正するために、plan failover
コマンドはrebalance
コマンドを実行します。rebalance
の後に新しいトポロジを正常にデプロイするには、トポロジ・コンポーネントをホストしているストレージ・ノードが実行中である必要があります。セカンダリ・ゾーンにフェイルオーバーされたゾーン内のストレージ・ノードにアービタが含まれていた場合、SNが再起動すると、アービタはシャードに再び参加します。
データ・ストアについて他のプランが進行しているときに、このコマンドを実行することはできません。このプランを実行する前に、他のプランを取り消すか、中断してください。
plan grant
plan grant [-role <role name>]* -user <user_name>
ユーザーにロールを付与できるようにします。
説明:
-
-role <role name>
付与するロールを指定します。ロール名は、セキュリティ・ガイドに記載されているシステム定義ロール(
public
を除く)である必要があります。 -
-user <user_name>
ロールを付与するユーザーを指定します。
このコマンドは非推奨です。詳細は、セキュリティ・ガイドのロールまたは権限の付与を参照してください。
plan interrupt
plan interrupt -id <plan id> | -last [-json]
実行中のプランを中断します。中断されたプランは再実行または取消のみが可能です。-lastを使用して、最も最近作成されたプランを参照します。
kv-> plan interrupt -id 20 -json
{
"operation" : "plan cancel|interrupt",
"returnCode" : 5000,
"description" : "Plan 20 was interrupted",
"returnValue" : null
}
plan migrate-sn
plan migrate-sn -from <id> -to <id>
[-plan-name <name>] [-wait] [-noexecute] [-force]
あるストレージ・ノードから別のストレージ・ノードにサービスを移行します。古いノードは実行中ではないことが必要です。
説明:
-
-from
移行元の(古い)ストレージ・ノードを指定します。
-
-to
移行先の(新しい)ストレージ・ノードを指定します。
たとえば、ストレージ・ノード25から26に移行するとすると、次のようなコマンドを使用します。
kv-> plan migrate-sn -from sn25 -to sn26
plan migrate-sn
コマンドを実行する前に、-java -Xmx64m -Xms64m -jar KVHOME/lib/kvstore.jar stop -root KVROOT
を使用して、実行中の古いストレージ・ノードを停止できます。
plan network-restore
plan network-restore -from <id> -to <id> -retain-logs
[-plan-name <name>] [-wait] [-noexecute] [-force] [-json|-json-v1]
plan network-restore
コマンドは、レプリケーション・ノード(RN)をリストアして、ネットワーク接続を失ってからRNが受け取ることができなかった更新を反映します。ここで説明する自動手順でRNをリストアできない場合にのみ、これを使用します。
レプリケーション・ノードがなんらかの理由で切断されると、接続されていない間に行われた更新を受け取ることができません。Oracle NoSQL Databaseでは、2つの方法を使用して、リカバリされたRNがオンラインに戻った後にRNを更新します。
1つの方法は、RNのレプリケーション・グループ内で行われます。リカバリされたRNが復帰すると、レプリケーション・グループのマスター・ノードによって、RNが切断された時点から操作を再開した時点までの、受け取ることができなかったすべての更新がストリームされます。
再接続されたRNをリストアするもう1つの方法は、ネットワーク接続を介して行われます。ネットワーク・リストアを実行すると、データ・ログ・ファイル(*.jdb
)の完全なセットがピアからコピーされ、リカバリされたRNに包括的なデータ・セットが提供されます。この内容には、現在のストアの内容に反映されていない多くの中間変更が含まれています。これは、受信側のRNが収集するデータ・ログ・ファイル(*.jdb
)には、中間変更も含め、すべての変更が含まれているためです。
データ・ストアのアクティビティを格納するデータ・ログ・ファイル(*.jdb
)を、デバッグ目的で使用されるデバッグ・ログ・ファイル(*.log
)と混同しないでください。
Oracle NoSQL Databaseの自動RN再移入の試行がどちらも成功しない場合、予期しない状況や、複数のホスト上のデータを破壊する致命的な状況が原因となっている可能性があります。この場合は、管理CLIからplan network-restore
を手動で実行できます。ただし、これを行うには、更新されたデータを提供するRNを指定する必要があります。
plan network-restore
コマンドを使用します。 kv-> plan network-restore -help
Usage: plan network-restore -from <id> -to <id> [-retain-logs] \
[-plan-name <name>] [-wait] [-noexecute] [-force] [-json | json-v1]
Network restore a RepNode from another one in their replication group.
説明: -from
フラグ - 同じレプリケーション・グループ(一致するrgX)のレプリケーション・ノードIDを指定します。-from
ノードは、完全に最新であり、*.dbd
ログ・ファイルを宛先RNに提供できる必要があります。たとえば、受信側の-to
RN IDがrg1-rn3
であり、ping出力にrg1-rn2
がマスターであることが示されている場合、そのID (rg1-rn2
)は-from
の値に適しています。-to
フラグ - 受信側のRNのID (rgX-rnY)を指定します。-retain-logs
フラグ - 古いログ・ファイルを遅延レプリカに保持します。ファイルが削除されるかわりに、ファイルの名前が変更されます。リカバリする側のRNでログ・ファイルが破損している疑いがある場合を除き、通常、このフラグを使用する必要はありません。
plan register-es
plan register-es -clustername <name> -host <host>
-port <transport port> [-force]
register-es
planコマンドを使用して、ElasticsearchクラスタをOracle NoSQL Databaseストアに登録します。クラスタの1つのノードを登録するのみでかまいません。クラスタ内のその他のノードは自動的に検出されます。
説明:
-
-clustername
Elasticsearchクラスタの名前を指定します。
-
-host
クラスタ内のノードのホスト名を指定します。
-
-port
クラスタ内のノードのトランスポート・ポートを指定します。
詳細は、統合ガイドの全文検索のためのエラスティック・サーチとの統合を参照してください。
plan remove-admin
plan remove-admin -admin <id> | -zn <id> | -znname <name>
[-plan-name <name>] [-wait] [-noexecute] [-force]
必要な管理インスタンス(単一の指定されたインスタンスまたはデプロイされたすべてのインスタンス)を指定されたゾーンに移動します。
ストア内で実行されている管理が3つ以下で-admin
フラグを使用する場合、あるいは-zn
または-znname
フラグを使用して指定されたゾーンからすべての管理を削除することでストア内に残る管理が1つか2つのみの場合、-force
フラグを使用した場合にのみ必要な管理が削除されます。
また、ストア内の管理が1つのみで-admin
フラグを使用する場合、あるいは、-zn
または-znname
フラグを使用して指定されたゾーンからすべての管理を削除することでストアからすべての管理が削除されることになる場合、必要な管理は削除されません。
plan remove-index
plan remove-index -name <name> -table <name>
[-plan-name <name>] [-wait] [-noexecute] [-force]
表から索引を削除します。
説明:
-
-name
削除する索引の名前を指定します。
-
-table
索引を削除する表名を指定します。表名はピリオドで区切られた名前で、フォーマットはtableName[.childTableName]*です。
plan remove-sn
plan remove-sn -sn <id>
[-plan-name <name>] [-wait] [-noexecute] [-force]
指定されたストレージ・ノードをトポロジから削除します。ストレージ・ノードは、削除する前に自動的に停止されます。
このコマンドは、未使用の古いストレージ・ノードをストアから削除する場合に便利です。これを行うには、「障害が発生したストレージ・ノードの置換」を参照してください。
- まず、
topology change-replication-factor
およびplan deploy-topology
コマンドを使用してレプリケーション・ノードを削除する必要があります。また、 plan remove-admin
コマンドを使用して、管理ノードを削除する必要があります。
plan remove-table
plan remove-table -name <name> [-keep-data]
[-plan-name <name>] [-wait] [-noexecute] [-force]
ストアから表を削除します。指定された表が存在し、子表を持っていない必要があります。表の索引は自動的に削除されます。デフォルトでは、この表に格納されているデータも削除されます。表データは-keep-dataフラグを指定することにより、オプションで保存できます。索引および表に格納されているデータの量によっては、長時間のプランになる可能性があります。
次の例では、表を削除しています。
## Remove a table.
kv-> plan remove-table -name User
## Started plan 7. Use show plan -id 7 to check status.
## To wait for completion, use plan wait -id 7.
kv-> show tables
## No table found.
plan remove-zone
plan remove-zone -zn <id> | -znname <name>
[-plan-name <name>] [-wait] [-noexecute] [-force]
指定されたゾーンをストアから削除します。
このコマンドを実行する前に、plan remove-sn
コマンドを使用して、指定されたゾーンに属するすべてのストレージ・ノードをまず削除する必要があります。
plan repair-topology
plan repair-topology
[-plan-name <name>] [-wait] [-json] [-noexecute] [-force]
前回のdeploy-topologyまたはmigrate-snプランの中断か取消から発生した可能性がある、デプロイされた現行トポロジにおける位置メタデータの不整合を検証します。可能であれば、不整合は修復されます。この操作は、ストアのサイズおよび状態によって、時間がかかる場合があります。
kv-> plan repair-topology -json -wait
{
"operation" : "Repair Topology",
"returnCode" : 5000,
"description" : "Operation ends successfully",
"returnValue" : {
"id" : 25,
"name" : "Repair Topology",
"isDone" : true,
"state" : "SUCCEEDED",
"start" : "2017-09-28 09:43:06 UTC",
"interrupted" : null,
"end" : "2017-09-28 09:43:06 UTC",
"error" : null,
"executionDetails" : {
"taskCounts" : {
"total" : 1,
"successful" : 1,
"failed" : 0,
"interrupted" : 0,
"incomplete" : 0,
"notStarted" : 0
},
"finished" : [ {
"taskNum" : 1,
"name" : "Plan 25 [Repair Topology] task [VerifyAndRepair]",
"state" : "SUCCEEDED",
"start" : "2017-09-28 09:43:06 UTC",
"end" : "2017-09-28 09:43:06 UTC"
} ],
"running" : [ ],
"pending" : [ ]
}
}
}
plan revoke
plan revoke [-role <role name>]* -user <user_name>
ユーザーからロールを取り消すことができるようにします。
説明:
-
-role <role name>
取り消されるロールを指定します。ロール名は、セキュリティ・ガイドに記載されているシステム定義ロール(
public
を除く)である必要があります。 -
-user <user_name>
ロールが取り消されるユーザーを指定します。
このコマンドは非推奨です。詳細は、セキュリティ・ガイドのロールまたは権限の取消しを参照してください。
plan start-service
plan start-service {-service <id> | -all-rns [-zn <id> |
-znname <name>] | -all-ans [-zn <id> | -znname <name>] |
-zn <id> | -znname <name> } [-plan-name <name>]
[-json] [-wait] [-noexecute] [-force]
指定されたサービスを開始します。サービスとして、有効な文字列によって識別されるレプリケーション・ノード、アービタ・ノードまたは管理サービスを指定できます。
たとえば、レプリケーション・ノードを識別するには、-service shardId-nodeId
を使用します。shardId-nodeId
は、ハイフンを1つ埋め込んだ、スペースなしの単一の引数として指定する必要があります。shardId
識別子はrgXで表されます。Xはシャード番号を指します。
説明:
-
-service
開始するサービスの名前を指定します。
-
-all-rns
指定した場合、ストア内のすべてのレプリケーション・ノードのサービスが開始されます。
-
-all-ans
指定した場合、指定したゾーン内のすべてのアービタ・ノードが開始されます。
注意:
このプランをストレージ・ノードの開始に使用することはできません。さらに、最初にストレージ・ノード自体を開始せずに、ストレージ・ノードのサービスを再開することはできません。ストレージ・ノードを開始するには、ストレージ・ノード・ホストに移動し、次のコマンドを入力します。
nohup java -Xmx64m -Xms64m \
-jar <KVHOME>/lib/kvstore.jar start -root <KVROOT> &
kv-> plan start-service -service rg1-rn3 -json -wait
{
"operation" : "Start Services",
"returnCode" : 5000,
"description" : "Operation ends successfully",
"returnValue" : {
"id" : 21,
"name" : "Start Services",
"isDone" : true,
"state" : "SUCCEEDED",
"start" : "2017-09-28 09:50:54 UTC",
"interrupted" : null,
"end" : "2017-09-28 09:50:57 UTC",
"error" : null,"executionDetails" : {
"taskCounts" : {
"total" : 2,
"successful" : 2,
"failed" : 0,
"interrupted" : 0,
"incomplete" : 0,
"notStarted" : 0
},
"finished" : [ {
"taskNum" : 1,
"name" : "Plan 21 [Start Services] task [StartNode]",
"state" : "SUCCEEDED",
"start" : "2017-09-28 09:50:54 UTC",
"end" : "2017-09-28 09:50:55 UTC"
}, {
"taskNum" : 2,
"name" : "Plan 21 [Start Services] task [WaitForNodeState rg1-rn3 to reach RUNNING]",
"state" : "SUCCEEDED",
"start" : "2017-09-28 09:50:55 UTC",
"end" : "2017-09-28 09:50:57 UTC"
} ],
"running" : [ ],
"pending" : [ ]
}
}
}
plan stop-service
plan stop-service {-service <id> |
-all-rns [-zn <id> | -znname <name>] | -all-ans [-zn <id> |
-znname <name>] | -zn <id> | -znname <name> }
[-plan-name <name>] [-json] [-wait] [-noexecute] [-force]
指定されたサービスを停止します。サービスとして、有効な文字列によって識別されるレプリケーション・ノード、アービタ・ノードまたは管理サービスを指定できます。
たとえば、レプリケーション・ノードを識別するには、-service shardId-nodeId
を使用します。shardId-nodeId
は、ハイフン(-)を1つ埋め込んだ、スペースなしの単一の文字列である必要があります。shardId
識別子はrgX
として表されます。Xはシャード番号を表します。
-service
の後に指定する他のオプションには、次のものがあります。
-
-all-rns
ストア内のすべてのレプリケーション・ノードのサービスを停止します。
-
-all-ans
指定したゾーン内のすべてのアービタ・ノードのサービスを停止します。
このコマンドを使用して、影響を受けるサービスを停止し、システムがサービスとの通信を試みても受け入れないようにします。1つ以上のサービスとの通信を停止すると、すでに認識している障害に関するエラー出力の量が減少します。
plan stop-service
コマンドを実行するたびに、ヘルス・チェックが自動的に開始されます。ヘルス・チェックでは、指定したサービスを停止すると定数が失われるかどうかが確認されます。それ以上のチェックは実行されず、サービスを停止した場合に定数が失われるかどうかのみがチェックされます。定数が失われるのを回避するために、ヘルス・チェックが失敗すると、plan stop-service
は実行に失敗し、次のような詳細なヘルス・チェック情報が出力されます。
One of the groups is not healthy enough for the operation:
[rg1] Only 1 primary nodes are running such that a simple
majority cannot be formed which requires 2 primary nodes.
The shard is vulnerable and will not be able to elect a new master.
Nodes not running: [rg1-rn1]. Nodes to stop: {rg1=[rg1-rn2]}
...
定数が失われるためにサービスを停止できない場合は、サービスの停止を試みる前に、発生している問題を確認する必要があります。
一方、サービスを停止すると定数が失われることがわかっていても、重要な変更を行うためにそのようなイベントが必要な場合は、-force
フラグを追加することでplan stop-service
コマンドを強制的に実行できます。
注意:
管理サービスを強制的に停止し、管理定数が失われた場合、それ以降はstart-service
プランを使用して管理サービスを開始できなくなります。それ以降、プランの操作もすべて失敗します。
plan stop-service
コマンドは、ディスク置換プロセス中にも役立ちます。障害が発生したディスクを削除する前に、このコマンドを使用して、影響を受けるサービスを停止します。詳細は、「障害が発生したディスクの置換」を参照してください。
注意:
-
このプランをストレージ・ノードの停止に使用することはできません。ストレージ・ノードを停止するには、まず、そのノード上で実行されているすべてのサービスを停止します。次に、ストレージ・ノード・ホストに移動し、次のコマンドを発行して、ストレージ・ノード・プロセスのIDを確認します。
ps -af | grep -e "kvstore.jar.*start.*<KVROOT>"
次を使用してプロセスを強制終了します。
kill <storage node id>
-
また、
plan stop-service -all-rns
コマンドでは常に定数が失われるため、このオプションを指定してplan stop-service
を実行すると、ヘルス・チェックの実行はスキップされます。さらに、-all-rns
オプションを使用する場合、-force
フラグを使用する必要はありません。
plan verify-data
plan verify-data
[-verify-log <enable|disable> [-log-read-delay <milliseconds>]]
[-verify-btree <enable|disable> [-btree-batch-delay <milliseconds>]
[-index <enable|disable>] [-datarecord <enable|disable>]]
[-valid-time <time>]
[-show-corrupt-files <enable|disable>]
-service <id> | -all-services [-zn <id> | -znname <name>] |
-all-rns [-zn <id> | -znname <name>] |
-all-admins [-zn <id> | -znname <name>]
[-plan-name <name>] [-wait] [-noexecute] [-force] [-json|-json-v1]
verify-data
の各パラメータおよびオプションの説明は、次のとおりです。
オプション | 説明 |
---|---|
-verify-log |
JEのJEログ・ファイル内の各データ・レコードのチェックサムを検証します。Berkeley DB Java Edition (JE)は、Oracle NoSQL Databaseのデータ・ストレージ・エンジンです。 デフォルトは有効です。 |
-log-read-delay |
ファイル読取り間の遅延時間を構成します。 デフォルト値は100ミリ秒です。 |
-verify-btree |
メモリー内のデータベースのBツリーに、ディスク上の各データ・レコードへの有効な参照が含まれていることを検証します。 デフォルトは有効です。 |
-btree-batch-delay |
バッチ間の遅延時間をミリ秒単位で構成します。 遅延のデフォルト値は10ミリ秒です。 |
-datarecord
|
データ・レコードがキャッシュ内にない場合、ディスクからデータ・レコードを読み取って検証します。 これはデフォルトでは無効です。 |
-index
|
索引を検証します。 デフォルトは有効です。 |
-valid-time |
既存の検証が有効とみなされ、再実行されない時間を指定します。形式は'number unit'で、unitは分または秒です。unitは大/小文字が区別されず、スペース、"-"または"_"でnumberと区切ることができます。 デフォルトは'10 minutes'です。 |
-show-corrupt-files |
参照されている欠落ファイルおよび予約済ファイルを含め、破損したファイルを表示するかどうかを指定します。 これはデフォルトでは無効です。 |
-service id |
指定したサービス(id)で検証を実行します |
-all-services [-zn id | -znname name] |
指定したゾーンまたはすべてのゾーン(何も指定しなかった場合)内のすべてのサービス(RNと管理の両方)で検証を実行します。 |
| -all-rns [-zn id | -znname name]
|
指定したゾーンまたはすべてのゾーン(何も指定しなかった場合)内のすべてのRNで検証を実行します。 |
| -all-admins [-zn id | -znname name] |
指定したゾーンまたはすべてのゾーン(何も指定しなかった場合)内のすべての管理で検証を実行します。 |
[-plan-name name] |
保存した指定のプランを実行して、plan verify-data および使用可能なそのオプションを実行します。
|
[-wait] |
プランを同期的に実行して、コマンドが完了したらコマンドライン・プロンプトが返されるようにします。 |
[-noexecute] |
プランを作成しますが、その実行を遅らせます。逆に、プランを実行するには、plan execute コマンドを使用します。
|
[-force] |
フラグを検証せずに、CLIで入力したとおりにプランを実行します。 |
[-json|-json-v1] |
プランの出力をjsonまたはjson-v1として表示します。 |
verify-dataの実行
plan verify-data
コマンドを使用して、プライマリ表とセカンダリ索引の両方を検証できます。このコマンドでは、データ・レコードのチェックサムまたはデータベースのBツリーを検証できます。
注意:
Oracle NoSQL Databaseでは、基盤となるストレージ・エンジンとしてOracle Berkeley DB Java Edition (JE)が使用されるため、plan verify-data
を使用したデータの検証は、ここでは説明していない、また参照することもできない下位レベルのいくつかのJE機能に依存しています。この項全体を通して、Oracle Berkeley DB Java Edition (JE)に関連する用語や概念は、その組織を表すBerkeleyという用語で示しています。Oracle Berkeley DB Java Editionの詳細は、Oracle Berkeley DB Java Editionを参照してください。
plan verify-data
には、検証の対象として次の2つの部分があります。
- ディスク上のログ・レコードの整合性
- Bツリーの整合性
verify-data
は各レコードのチェックサムにアクセスして検証します。この手順にはディスク読取りが含まれるため、I/Oリソースを消費し、比較的時間がかかります。パフォーマンスに対する検証の影響を軽減するには、ログ・ファイルの各バッチを読み取る間の遅延時間を長めに構成します。遅延時間を長くすると、全体的な操作時間が長くなりますが、消費するI/Oアクティビティは少なくなります。この選択肢が要件に適している場合は、-btree-batch-delay
を使用して、I/O操作のピーク中におけるログ・ファイルの整合性チェック間の遅延を長くします。
Bツリーの整合性を検証する場合、plan verify-data
プロセスはメモリー内の整合性を検証します。基本検証では、プライマリ表内の各データ・レコードのLSN (Berkeley)が有効かどうかのみがチェックされます。セカンダリ索引の整合性に加え、ディスク上のデータ・レコードを含むように検証を構成できます。
データ・レコードの検証を有効にしない場合、セカンダリ索引の検証では、セカンダリ索引からプライマリ表への参照のみがチェックされ、プライマリ表から索引への参照はチェックされません。基本検証ではメモリー内データ構造のみがチェックされるため、ディスク読取りを含む検証よりも大幅に高速になるとともに、リソース消費量が少なくなります。
plan wait
plan wait -id <id> | -last [-seconds <timeout in seconds>] [-json]
オプションのタイムアウトが指定されていない場合は、指定したプランが完了するまで無期限に待機します。
-seconds
オプションを使用すると、プランが完了するまで待機する時間を指定できます。
-last
オプションは、最も最近作成されたプランを参照します。
kv-> plan wait -id 26 -json
{
"operation" : "plan wait",
"returnCode" : 5000,
"description" : "Operation ends successfully",
"returnValue" : {
"planId" : 26,
"state" : "CANCELED"
}
}