Setting Store Parameters

The three Oracle NoSQL Database service types, Admin, Storage Node, and Replication Node, have configuration parameters. You can modify some parameters after deploying the service. Use the following Admin CLI command to see the parameter values that you can change:

show parameters -service <>

You identify an Admin, Storage Node, or Replication service using a valid string. The show parameters -service command displays service parameters and state for any of the three services. Use the optional -policy flag to show global policy parameters.

Changing Parameters

All of the CLI commands used for creating parameter-changing plans share a similar syntax:

plan change-parameters -service <id>...

All such commands can have multiple ParameterName=NewValue assignment arguments on the same command line. If NewValue contains spaces, then the entire assignment argument must be quoted within double quote marks. For example, to change the Admin parameter collectorPollPeriod, you would issue the command:

kv-> plan change-parameters -all-admins -params \
    "collectorPollPeriod=20 SECONDS">

If your configProperties for all Replication Nodes is set to:

"configProperties=je.cleaner.minUtilization=40;">

And you want to add new settings for configProperties, you would issue the following command:

kv-> plan change-parameters -all-rns -params \
     "configProperties=je.cleaner.minUtilization=40;\
     je.env.runVerifier=false;">

If for some reason, different Replication Nodes have different configProperties parameter values, then the change-parameters command will need to be tailored for each Replication Node.

The following commands are used to change service parameters:

In all cases, you can choose to create a plan and execute it; or to create the plan and execute it in separate steps by using the -noexecute option of the plan command.

Setting Store Wide Policy Parameters

Most admin, Storage Node, and replication node parameters are assigned to default values when a store is deployed. It can be inconvenient to adjust them after deployment, so Oracle NoSQL Database provides a way to set the defaults that are used during deployment. These defaults are called store-wide Policy parameters.

You can set policy parameters in the CLI by using this command:

change-policy -params [name=value]

The parameters to change follow the -params flag and are separated by spaces. Parameter values with embedded spaces must be separated by spaces. Parameter values with embedded spaces must be quoted. For example: name = “value with spaces”. If the optional dry-run flag is specified, the new parameters are returned without changing them.

Admin Parameters

You can set the following parameters for the Admin service:

Changing Admin JVM Memory Parameters

Admin processes can run out of memory. One of the most likely reasons is that the default memory setting was insufficient for the Admin services to represent all of the metadata associated with the store. Metadata includes information about tables, security information about users and roles, and information about incomplete plans. Stores with large amounts of metadata may need to increase the memory setting for Admin services if the activity logs show that Admin services are failing with OutOfMemoryError. This topic describes increasing the memory setting of the javaAdminParamsOverride.

The system continues to use the old javaMiscParams setting to specify the initial JVM memory settings for the admin. The system does not use javaAdminParamsOverride since it is reserved for use if you want to override the default settings.

To change the javaAdminParamsOverride requires a comprehensive all or nothing change. You cannot change individual parameters within the set. To change any setting, declare them all in the plan change-parameters command, described next.

First determine the basic information about all Admin services using the show admins command. You get the output as shown below.

show admins

Output:

admin1: Storage Node sn1 storageDir=/home/opc/nosql/kvroot type=PRIMARY (connected RUNNING,MASTER)
admin2: Storage Node sn2 storageDir=/home/opc/nosql/kvroot type=PRIMARY (RUNNING,REPLICA)
admin3: Storage Node sn3 storageDir=/home/opc/nosql/kvroot type=PRIMARY (RUNNING,REPLICA)

Note: The above output is just an example. Here the replication factor RF=3 for the primary nodes. Your output will reflect your topology.

To determine the current settings of javaAdminParamsOverride and configProperties, enter the Admin CLI show parameters -service admin command as follows:

kv-> show parameters -service admin1

Output:

adminId=1
adminLogFileCount=20
adminLogFileLimit=5242880
adminMountPoint=/home/opc/nosql/kvroot
collectEnvStats=true
collectorPollPeriod=20 SECONDS
disabled=false
eventExpiryAge=30 DAYS
hideUserData=true
javaAdminParamsOverride=
loggingConfigProps=com.sleepycat.je.util.FileHandler.level=OFF
maxEvents=10000
storageNodeId=1

In this example, the javaAdminParamsOverride parameters that specify the Admin JVM memory shows the default value.

javaAdminParamsOverride=

Note: The value may or may not have a default value. The value in your setup could also be different.

To increase Admin JVM memory when Admins are operational, use the plan change-parameters command from the Admin CLI, as follows:

kv-> plan change-parameters -wait -all-admins  -params \
javaAdminParamsOverride="-Xms2048m -Xmx2048m

Note: It is recommended that you apply the modification to all of the admins by using the all-admins option. However, you can modify the admin parameters of every primary admin individually, but only if you have three or more primary admins. When you have only two admins, you must use the all-admins parameter; otherwise, the restart needed during this operation will cause the admins to lose the quorum.

Specifying these new values changes the Java heap size from the default values to 2 GB for both as shown below.

kv-> show parameters -service admin1

Output:

adminId=1
adminLogFileCount=20
adminLogFileLimit=5242880
adminMountPoint=/home/opc/nosql/kvroot
collectEnvStats=true
collectorPollPeriod=20 SECONDS
disabled=false
eventExpiryAge=30 DAYS
hideUserData=true
javaAdminParamsOverride=-Xms2048m -Xmx2048m
loggingConfigProps=com.sleepycat.je.util.FileHandler.level=OFF
maxEvents=10000
storageNodeId=1

Make sure that you locate the existing javaAdminParamsOverride from the Admin CLI as shown above, and update the individual entries. The javaAdminParamsOverride setting must represent all desired flags, not just new ones, so be sure to include any previously existing flag values that you want to retain.

If the Admin loses quorum, then you must use the Admin CLI repair-admin-quorum command.

Storage Node Parameters

You can set the following Storage Node parameters:

The following store-wide parameter settings apply to statistics files and performance files, as well as the service debug logs across all Storage Nodes, Replication Nodes, Admins, and Arbiters. The associated Storage Node Agent must be restarted to reflect any changes in the settings.

Replication Node Parameters

The following parameters can be set for Replication Nodes:

Arbiter Node Parameters

The following parameters can be set for Arbiter Nodes:

javaAnParamsOverride=<String>

A string that is added to the command line when the Arbiter Node process is started. This parameters is intended for specifying miscellaneous JVM properties. If the string is not a valid sequence of tokens for the JVM command line, the Admin process fails to start.

No default value is provided for this parameter.

It is recommended that to specify the heap sizes for Arbiter Nodes you use Storage Node’s memoryMB and other JVM parameters. For more information about these parameters see, Storage Node Parameters.

Global Parameters

The following store-wide non-security parameters can be implicitly and uniformly set across all Storage Nodes, Replication Nodes and Admins:

The following store-wide parameters can be set for the debug log files:

Security Parameters

The following store-wide security parameters can be implicitly and uniformly set across all Storage Nodes, Replication Nodes and Admins:

The following password security parameters can be set:

Parameter Name Value Range and Type Description
passwordAllowedSpecial Sub set or full set of #$%&’()*+,-./:; <=>?@[]^_`{|} (string)~ Lists the allowed special characters.
passwordComplexityCheck [true|false] (boolean) Whether to enable the password complexity checking. The default value is true.
passwordMaxLength 1 - 2048 (integer) The maximum length of a password. The default value is 256.
passwordMinDigit 0 - 2048 (integer) The minimum required number of numeric digits. The default value is 2.
passwordMinLength 1 - 2048 (integer) The Minimum length of a password. The default value is 9.
passwordMinLower 0 - 2048 (integer) The minimum required number of lower case letters. The default value is 2.
passwordMinSpecial 0 - 2048 (integer) The minimum required number of special characters. The default value is 2.
passwordMinUpper 0 - 2048 (integer) The minimum required number of upper case letters. The default value is 2.
passwordNotStoreName [true|false] (boolean) If true, password should not be the same as current store name, nor is it the store name spelled backwards or with the numbers 1-100 appended. The default value is true.
passwordNotUserName [true|false] (boolean) If true, password should not be the same as current user name, nor is it the user name spelled backwards or with the numbers 1-100 appended. The default value is true.
passwordProhibited list of strings separated by comma (string) Simple list of words that are not allowed to be used as a password. The default reserved words are: oracle,password,user,nosql.
passwordRemember 0 - 256 (integer) The maximum number of passwords to be remembered that are not allowed to be reused when setting a new password. The default value is 3.
passwordHashIterations 5000 - 10000000 (integer) The number of PBKDF2-HMAC-SHA256 iterations used when a local password hash is generated. The default value is 600000. Existing password hashes continue to use the iteration count stored with the digest.

Note: You should not need to change passwordHashIterations unless local password authentication latency or CPU usage is measured to be unacceptable in your environment. Lowering this value reduces the password-hash work factor and should be treated as a security tradeoff. Very high values can make local password authentication, user creation, and password changes noticeably slower. To apply the current policy value to existing local password hashes, use the ALTER USER command to update the corresponding user passwords so that the hashes are recreated.

For more information on top-level, transport, and password security parameters see the Security Guide.

Admin Restart

Changes to the following Oracle NoSQL Database parameters will result in a Admin restart by the Storage Node Agent:

Admin parameters:

For example:

kv-> plan change-parameters -all-admins
-params adminLogFileCount=10

Output:

Started plan 14. Use show plan -id 14 to check status.
        To wait for completion, use plan wait -id 14
kv-> show plan -id 14

Output:

Plan Change Admin Params (14)
Owner: null
State:                 INTERRUPTED
Attempt number:        1
Started:               2026-05-01 20:12:06 UTC
Ended:                 2026-05-01 20:12:06 UTC
Total tasks:           4
 Successful:           1
 Interrupted:          1
 Not started:          2
Tasks not started
   Task StartAdmin start admin1
   Task WaitForAdminState waits for Admin admin1 to reach RUNNING state
kv-> plan execute -id 14

Output:

Started plan 14. Use show plan -id 14 to check status.
        To wait for completion, use plan wait -id 14
kv-> show plan -id 14

Output:

Plan Change Admin Params (14)
State:                 SUCCEEDED
Attempt number:        1
Started:               2026-05-01 20:20:18 UTC
Ended:                 2026-05-01 20:20:18 UTC
Total tasks:           2
 Successful:           2

Note: When you change a parameter that requires an Admin restart using the plan change-parameters command, the plan ends in an INTERRUPTED state. To transition it to a SUCCESSFUL state, re-issue the plan a second time using the plan execute -id<id> command.

Replication Node Restart

The Storage Node Agent must be restarted to reflect any changes in the setting of the following parameters.

Storage Node parameters:

Replication Node parameters: