SAND CDBMS Administration Guide
The Nucleus.ini File


Previous Topic:
Nucleus.ini file Parameters - Client Section
Chapter Index
Next Topic:
Nucleus.ini file Parameters - License Section


Nucleus.ini file Parameters

[DCL] Section Parameters

The [DCL] section contains parameters used by the SAND CDBMS Data Loader program (ndlm) when performing import operations in Parallel Loader mode. These parameters are global, meaning that they apply to all import operations on the same machine.

As an alternative, the SCTFILE and LOAD parameters can appear in the load specification script used to create an SCT File. When the parameters are set locally in this manner, they apply only to the import operation that uses the load specification script.

Note that if the parameters appear in multiple locations, SAND Searchable Archive will use the following order of precedence:

  1. NUCLEUS environment variable
  2. nucleus.ini file
  3. load specification script (SCTFILE and LOAD parameters)

For instance, if a parameter appears in the NUCLEUS environment variable, it will override the same parameter in the nucleus.ini file or the load specification script.



Enables SCT File creation for all Parallel Loader import operations and specifies the path of the resulting SCT File. Note that when this parameter is set, each successive load operation will overwrite the previously created SCT File. To avoid this situation, do not set the SCTFILE parameter in the nucleus.ini file; instead, include it in each load specification script with a unique SCT destination path.


Enables simultaneous loading of data into both SCT File and SAND database. Note that the LOAD and DDL parameters are incompatible, so if the DDL parameter is set, the LOAD parameter must be disabled.

The possible values:

1 or YES or TRUE
Enables simultaneous loads

0 or NO or FALSE
Disables simultaneous loads

Default: 1

Specifies the path to a text file containing the SQL DDL commands that fully describe the destination table. When the optional DDL parameter is included (pointing to a valid DDL file), a running SAND database is not required to create an SCT File.

The file referenced by the DDL parameter can contain any number of CREATE TABLE and CREATE DOMAIN statements, not necessarily related only to one load specification script, but to any number of scripts. When the load operation is started, ndlm will look for the first CREATE TABLE statement that corresponds to the table specified in the load script. If that CREATE TABLE statement references a custom domain, ndlm will also look for the appropriate CREATE DOMAIN statement. If all of the required SQL statements are found in the DDL file, ndlm has sufficient information to create the SCT File.


Specifies the level of integrity verification performed at creation time for all new SCT files. By default, all integrity tests are performed when an SCT file is created.

Note that checksum verification can increase the amount of time it takes to create an SCT file by up to 20% for a single processor; although, the presence of multiple processors will decrease this overhead by a proportional amount.

The possible values:

Disable file verification.

Verify metadata integrity only.

Perform checksum verification. This includes a checksum of the data being read from the source, as well as a checksum of the compressed data in the resulting SCT file.

Perform full verification, including checksum and metadata integrity tests.

Default: 3 (full verification)


Specifies the level of compression for all new SCT files. By default, SCT files are created with a moderate degree of compression, but the amount of compression for new SCT files can be configured to accommodate different needs. The following levels of compression are available:

Low compression. SCT files created with this level of compression are created more quickly, and user queries executed against them are relatively faster. However, such SCT files can require more disk space than those at higher levels of compression. This compression level suits data that is expected to be queried more often.

Medium compression. SCT files created with this level of compression strike a balance between query speed and disk space savings.

High compression. SCT files created with this level of compression require more time to create, and user queries against them are slowest. However, these SCT files require the least amount of disk space. This compression level is ideal for long-term archival storage of data that does not need to be queried often.

Default: HIGH


Sample [DCL] Section



Previous Topic:
Nucleus.ini file Parameters - Client Section
Chapter Index
Next Topic:
Nucleus.ini file Parameters - License Section