1. 管理者ガイド
  2. 管理CLIリファレンス
  3. plan

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-datacenter

非推奨。かわりに「plan deploy-zone」を参照してください。

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を指定する必要があります。

ネットワーク・リストアを試行するには、管理CLIから次の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-datacenter

plan remove-datacenter

このコマンドは非推奨です。かわりに「plan remove-zone」を参照してください。

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ツリーに、ディスク上の各データ・レコードへの有効な参照が含まれていることを検証します。-verify-btreeを-datarecordおよび-indexと組み合せることができます。

デフォルトは有効です。
-btree-batch-delay

バッチ間の遅延時間をミリ秒単位で構成します。

遅延のデフォルト値は10ミリ秒です。
-datarecord

データ・レコードがキャッシュ内にない場合、ディスクからデータ・レコードを読み取って検証します。-datarecordオプションを指定すると、キャッシュ内のレコードのみを検証する場合よりも時間がかかり、読取りI/Oが増加します。

これはデフォルトでは無効です。
-index

索引を検証します。-indexオプションのみを使用すると、索引からプライマリ表への参照のみが検証され、プライマリ表から索引への参照は検証されません。索引からプライマリ表への参照とプライマリ表から索引への参照の両方を検証するには、-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"
	}
}