Block size for backup file writing

The minimum value for General.BackupBlockSize is the server block size (defined with IndexFile.BlockSize parameter).

The maximum value is 8MB. If the parameter value exceeds the maximum value, the default value is used (64K).

The value of General.BackupBlockSize needs to be a multiple of the database block size of the server (defined with IndexFile.BlockSize parameter).

64 KB

Unit: 1 byte k=KB

RW/
Startup

If set to yes, solid.ini file will be copied to the backup directory

yes

RW/
Startup

If set to yes, backup operation will copy log files to the backup directory

yes

RW/
Startup

If set to yes, solmsg.out file is copied to the backup directory

yes

RW/
Startup

If set to yes, old log files will be deleted after backup operation

yes

RW/
Startup

Makes a backup of the database, log files, and the configuration file solid.ini, using the factory value backup or a given name. For example, BackupDirectory=abc, creates a backup in the abc directory.

The backup directory must exist and it must have enough disk space for the backup files. It can be set to any existing directory, except the solidDB^® database file directory, the log file directory, or the working directory.

All directory definitions are relative to the solidDB^® working directory unless the full path is provided.

Note that the backup directory entry must be a valid path name in the server’s operating system. For example, if the server runs on a UNIX operating system, path separators must be slashes instead of backslashes.

'backup' directory

RW/
Startup

Specifies the maximum number of blocks (pages) that can be stored in memory before they are flushed to disk during backup operation.

100

RW

Controls how frequently netcopy and backup tasks are executed. The value is a number of the tasking system steps that are skipped between backup execution phases. Reasonable values are in the range of 2 - 20.

With the factory value 0, the backup proceeds with the maximum speed.

0 (no skipping)

RW/
Startup

If this parameter is set to yes, the server deletes the transaction log file(s) after each successful checkpoint. This saves disk space, but makes it impossible to recover data by rolling forward the logs.

The transaction logs contain a copy of the transactions executed by the server. If the database file is erased or corrupted, and if you have kept the transaction log files, then you can restore the data by restoring the backup database file and then rolling forward all the transaction logs that accumulated since the last backup. If you deleted those transaction logs, then you will lose all transactions since the last successful backup.

You should only set CheckpointDeleteLog to yes if your database has data that you are willing to risk losing (for example, test data created during development). See also the BackupDeleteLog parameter.

If LogReader.LogReaderEnabled is set to yes, the CheckpointDeleteLog parameter is not effective: the log files are not deleted after a checkpoint. Instead, the log entries are removed only after the log size defined by LogReader.MaxLogSize has been reached.

no

RW/
Startup

The number of writes to the log files made in the database which causes automatic checkpoint creation. A large setting can delay checkpoints and make them larger. A small setting will guarantee a small checkpoint size.

See also MinCheckpointTime.

50000 log writes

RW

Enable compression for all tables. If CompressAllTables=YES, all tables are compressed regardless of ALTER TABLE commands. If CompressAllTables=NO, compression can be turned on per table by ALTER TABLE.

yes/no

Startup

When a data “dictionary operation active” error for prepared statements occurs, the server automatically attempts to reprepare the SQL statement, for the time specified with this parameter. If the table is still compatible with the SQL statement, the operation can continue without any errors reported to the user. This parameter should only be enabled when the thread/client mode is used (Srv.ReadThreadMode=2), because the wait blocks the waiting thread.

0 (Disabled) Unit: 1 second

RW

If set to yes, the precision of NUMERIC is allowed to be greater than specified.

no

RW/
Startup

On Windows systems, defines the domain name solidDB^® uses to resolve two-part user IDs of externally authenticated users. Two-part user IDs are composed of a domain and user name (domain_name\user_name).

If the domain name is specified with the DefaultDomainName parameter, solidDB^® stores only the user_name in SYS_USERS table. Users can also log on to solidDB^® using user_name only.

This parameter applies to Windows systems only.

no factory value

RO

If set to yes, new tables are created as in-memory tables, unless they are created without an explicit STORE clause in the CREATE TABLE statement. If set to no, new tables are stored on disk by default. You can override the factory value by using the STORE clause in the CREATE TABLE statement.

System tables are stored on disk, even if this parameter is set to yes.

yes

RW

If set to yes, database is set to disable idle merge.

no

RW/
Startup

0 means no flushing after write or read operations.

1 means flush before reading from the file.

2 means flush after write operations

0 on most platforms.

RW/
Startup

The server uses a hash table (array) to store lock information. If the size of the array is remarkably underestimated the performance degrades. Too large hash table does not affect performance directly although it causes memory overhead. The LockHashSize determines the number of elements in hash table.

This information is needed when the server is using pessimistic concurrency control (locking). The server uses separate arrays for in-memory tables and disk-based tables. This parameter applies to disk-based tables.

In general, the more locks you need, the larger this array needs to be. However, it can be difficult to calculate the number of locks that you need, so you might need to experiment to find the best value for your applications.

The value that you enter is the number of hash table entries. Each table entry has a size of one pointer (4 bytes in 32-bit architectures). Thus, for example, if you choose a hash table size of 1,000,000, then the amount of memory required is 4,000,000 bytes (assuming 32-bit pointers).

1000000

RW/
Startup

(update/deletes/insert) performed at a time.

The optimal value depends on the number of available cores (CPUs) and the scattering of updates among different tables. The more cores available and the more scattered the writes are, the higher the optimal value. The value cannot be higher than the number of available cores (CPUs).

Value 0 means that there is no limit on the number of concurrent writes.

 

 

Sets the number of index inserts made in the database that causes the merge process to start

Cache size dependent

RW

Specifies the minimum time in seconds between two checkpoint operations.

See also CheckpointInterval.

300

Unit: 1 second

RW

This sets a minimum time (in seconds) between two merge operations. For more information about merge operations, see Tuning I/O.

0

RW

This parameter defines the number of processing units (processors, cores) available in the computer system. Typically, the concurrency of write operations in the database can be improved if the value matches the number of physical processors (cores) in your system.

As of V6.5 Fix Pack 4, the factory value is read from the system as the number of logical processing units. The auto-detected value is output to solmsg.out at server startup. With some processor architectures, the number of logical processing units might not be the same as the number of physical cores. In such cases, the optimal value for this parameter typically varies between the number of the physical cores and the number of logical processing units.

In releases before V6.5 Fix Pack 4, the factory value of this parameter is 4.

As of V6.5 Fix Pack 4, the value of the MME.RestoreThreads parameter defaults to the value of this parameter, unless set to a different value explicitly.

Read from system

RW/
Startup

This sets the connect string to the Netbackup server.

No factory value.

RW/
Startup

Sets the maximum time in milliseconds that a netbackup operation waits for a connection to a NetBackup server.

For example, to set the timeout to 60 seconds use value 60000 (milliseconds).

0 (no timeout)

30000

RW/
Startup

If set to yes, the solid.ini configuration file is copied to the remote backup directory.

yes

RW/
Startup

If set to yes, the log files are copied to the remote backup directory.

yes

RW/
Startup

If set to yes, the solmsg.out message file is copied to the remote backup directory.

yes

RW/
Startup

If set to yes, the backed-up log files are deleted from the source server after the NetBackup has accomplished.

yes

RW/
Startup

Sets the remote backup directory. The path expression may be relative or absolute. Non-absolute paths are related to the working directory of the NetBackup server.

No factory value.

RW/
Startup

Sets the maximum time in milliseconds that any operation waits for the response from the NetBackup server.

For example, to set the timeout to 60 seconds use value 60000 (milliseconds).

30000

RW/
Startup

Defines the buffer size at the NetBackup server for storing data during backup. When the buffer is full, writes of backup data are throttled.

32M

Unit: 1 byte k=KB m=MB

RW

The General.PamServiceName parameter defines the solidDB^® program name that is used in the PAM configuration to define how solidDB^® users are authenticated.

This parameter applies to Linux and UNIX systems only.

solid

RO

If set to yes, the server uses pessimistic concurrency control for D-tables. With pessimistic concurrency control, the server places locks on rows to control the level of consistency and concurrency when users are submitting queries or updates to rows.

The factory value is “no”; D-tables uses optimistic concurrency control by default.

When setting the Pessimistic parameter to “yes”, the server defaults to pessimistic locking for any new tables that are created and for any old tables for which the concurrency control method was never explicitly set with the ALTER TABLE command.

If you set the locking mode of a table by using the following ALTER TABLE command, it takes precedence over this parameter.

no

RW/
Startup

This parameter specifies in seconds how long an SQL execute can hold the transaction read level in the READ COMMITTED isolation level until it is released.

The default value is 10 seconds.

10

RW/
Startup

If set to yes, the database is set to read-only mode.

You can query the read-only mode of the database by using the ADMIN COMMAND 'getreadonlyflag' command.

no

RW/
Startup

Sets the maximum percentage of search buffers from the total buffered memory reserved for open cursors.

The search buffer contains a local copy of the last B-tree page. Because of this, active searches do not need to go through the index and cache manager to get to the next row in the search. Instead, the searches read the local copy residing in the cache manager. Other searches can also access the page for read-only purposes unless it has been modified by a transaction.

When calculating the buffer limit value, take the approximate number of active searches in the database and multiply it by two. The result is the need for search buffers. After this, you can calculate the suitable percentage from the cache size.

50

RW/
Startup

If this parameter is set to yes, it forces a merge operation to run when the server is started. The server accepts no user commands until the merge operation has been completed.

no

RW/
Startup

This parameter sets the time in seconds that a transaction waits to get a lock. When messages are executed in the replica, it is possible to run them in pessimistic or mixed concurrency mode, which means table level locks are used.

There are times when a transaction will acquire an exclusive lock to a table. If there is a conflict, the TableLockWaitTimeout setting provides wait period of the transaction until the exclusive or shared lock is released. This parameter is used for synchronized databases only.

Table-level locks are used when the PESSIMISTIC keyword is explicitly provided in the following solidDB^® commands:

See also LockWaitTimeOut.

30

Unit: 1 second

RW

When set to yes, early validation of transaction is used (transaction is validated at the time each statement is written, not at commit time). Early validation is applicable with optimistic locking only.

The possible values are yes and no.

yes

RW/
Startup

The hash table contains slots that are occupied by incomplete (open) transactions. The transaction hash size sets the size of the table for open transactions. Once the number of occupied slots increases, the operations with this table become slower.

The database offers higher performance when the average number of transactions per slot is lower. For example, 5 is a good initial limit for the transaction per slot average.

You can monitor the status of this hash table using ADMIN COMMAND 'report filename'. For example:

The output contains the following related information:

tablesize = setting

nused = slots taken from hash table

list length = sum of all transactions in the table

Minimum value is 1000.

1046527

RW/
Startup

This parameter defines whether passwords are encrypted. If set to “no”, passwords are not encrypted.

For more details, see Encryption.

yes

RW/
Startup

If this parameter is enabled, pessimistic D-tables with READ COMMITTED isolation use versioned reads. Reads with SELECT FOR UPDATE work as before. In other words, pessimistic D-tables work like M-tables.

yes

RW/
Startup

If this parameter is set to yes, pessimistic D-tables with REPEATABLE READ isolation use versioned reads.

yes

RW/
Startup

Number of helper threads dedicated to writing tasks (per IO device).

If IOThreads=1 then the setting WriterIOThrreads=0 is enforced.

1

RW/
Startup