[General]
|
Description
|
Factory Value
|
Access mode
|
---|---|---|---|
BackupBlockSize
|
Block size for backup file writing
Note 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 |
BackupCopyIniFile
|
If set to yes, solid.ini file will be copied to the backup directory
|
yes
|
RW/
Startup |
BackupCopyLog
|
If set to yes, backup operation will copy log files to the backup directory
|
yes
|
RW/
Startup |
BackupCopySolmsgOut
|
If set to yes, solmsg.out file is copied to the backup directory
|
yes
|
RW/
Startup |
BackupDeleteLog
|
If set to yes, old log files will be deleted after backup operation
|
yes
|
RW/
Startup |
BackupDirectory
|
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 on directory 'abc'.
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 |
BackupFlushInterval
|
Specifies the maximum number of blocks (pages) that can be stored in memory before they are flushed to disk during backup operation.
|
100
|
RW
|
BackupStepsToSkip
|
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 |
CheckpointDeleteLog
|
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.
Note If you are using HotStandby and if you set CheckpointDeleteLog=yes on the Primary server, the server deletes only the logs that are already acknowledged by Secondary. For example, if the Secondary is down and the Primary is in PRIMARY ALONE state, the Primary will keep the logs even after the data has been checkpointed on the Primary.
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 |
CheckpointInterval
|
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.
Note CheckpointInterval and MinCheckpointTime use different units of measurement. CheckpointInterval is based on the number of log writes, while MinCheckpointTime specifies the minimum time between consecutive checkpoints.
|
50000 log writes
|
RW
|
DataDictionaryErrorMaxWait
|
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/
Startup |
DecimalPrecAsNumeric
|
If set to yes, the precision of NUMERIC is allowed to be greater than specified.
|
no
|
RW/
Startup |
DefaultDomainName
|
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.
Note This parameter applies to Windows systems only.
|
no factory value
|
RO
|
DefaultStoreIsMemory
|
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.
Note System tables are stored on disk, even if this parameter is set to yes.
|
yes
|
RW
|
DisableIdleMerge
|
If set to yes, database is set to disable idle merge.
|
no
|
RW/
Startup |
FileWriteFlushMode
|
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 |
GSKitLoginRequired
|
Specifies that to connect to the solidDB® server with an ODBC client using a network protocol, the IBM Global Security Kit (GSKit) must be enabled on the (client) computer.
When set to yes, solidDB® server expects that the network connection over which passwords are sent uses strong encryption.
This parameter has impact only when internally authenticated users connect to solidDB® server over a network connection. The network connection over which the passwords of externally authenticated users are sent always uses strong encryption.
Possible values are yes (GSKit) and no.
If GSKitLoginRequired is set to yes, Client.UseGSKit must be set to yes also.
|
no
|
RW/
Startup |
GSKitPath
|
This parameter defines the path to the directory where the IBM Global Security Kit (GSKit) library is located.
The value of the parameter must be a valid path. For example:
[General] GSKitPath=/home/sol/solidDB-7.0/bin/
See also General.UseGSKit and General.GSKitLoginRequired.
|
no factory value
|
RO
|
LockHashSize
|
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 |
MaxWriteConcurrency
|
(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.
|
|
|
MergeInterval
|
Sets the number of index inserts made in the database that causes the merge process to start
|
Cache size dependent
|
RW
|
MinCheckpointTime
|
Specifies the minimum time in seconds between two checkpoint operations.
See also CheckpointInterval.
Note CheckpointInterval and MinCheckpointTime use different units of measurement: CheckpointInterval is based on the number of log writes, while MinCheckpointTime specifies the minimum time between consecutive checkpoints.
|
300
Unit: 1 second
|
RW
|
MinMergeTime
|
This sets a minimum time (in seconds) between two merge operations. For more information about merge operations, see Tuning I/O.
|
0
|
RW
|
MultiprocessingLevel
|
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.
Note 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 |
NetBackupConnect
|
This sets the connect string to the Netbackup server.
|
No factory value.
|
RW/
Startup |
NetBackupConnectTimeout
|
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 |
NetBackupCopyIniFile
|
If set to yes, the solid.ini configuration file is copied to the remote backup directory.
|
yes
|
RW/
Startup |
NetBackupCopyLog
|
If set to yes, the log files are copied to the remote backup directory.
|
yes
|
RW/
Startup |
NetBackupCopySolmsgOut
|
If set to yes, the solmsg.out message file is copied to the remote backup directory.
|
yes
|
RW/
Startup |
NetBackupDeleteLog
|
If set to yes, the backed-up log files are deleted from the source server after the NetBackup has accomplished.
|
yes
|
RW/
Startup |
NetBackupDirectory
|
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 |
NetBackupReadTimeout
|
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 |
NetBackupReceiveBufferSize
|
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
|
PAMServiceName
|
The General.PamServiceName parameter defines the solidDB® program name that is used in the PAM configuration to define how solidDB® users are authenticated.
Note This parameter applies to Linux and UNIX systems only.
|
solid
|
RO
|
Pessimistic
|
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.
ALTER TABLE base_table_name SET {OPTIMISTIC | PESSIMISTIC}
|
no
|
RW/
Startup |
ReadLevelMaxTime
|
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 |
Readonly
|
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 |
RSAKeySize
|
Defines the RSA algorithm key length that is used in IBM Global Security Kit (GSKit) encryption. The unit is bits. Possible values are 1024, 2048, and 4096.
|
1024
|
RO
|
SearchBufferLimit
|
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 |
StartupForceMerge
|
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 |
TableLockWaitTimeout
|
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:
IMPORT SUBSCRIPTION
MESSAGE message_name EXECUTE (only with NO EXECUTE option)
MESSAGE message_name FORWARD
MESSAGE message_name GET REPLY
DROP SUBSCRIPTION
See also LockWaitTimeOut.
|
30
Unit: 1 second
|
RW
|
TransactionEarlyValidate
|
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 |
TransactionHashSize
|
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.
Note You can monitor the status of this hash table using ADMIN COMMAND 'report filename'.
For example:
ADMIN COMMAND 'report myfile.txt'
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 |
UseEncryption
|
This parameter defines whether passwords are encrypted. If set to 'no', passwords are not encrypted.
For more details, see Encryption.
|
yes
|
RW/
Startup |
UseGSKit
|
This parameter defines whether IBM Global Security Kit (GSKit) is used for encryption of passwords and database and log files.
For more details, see Encryption.
Note If General.UseEncryption parameter is set to no, this parameter is not effective.
See also General.GSKitPath.
|
no
|
RO
|
VersionedPessimisticReadCommitted
|
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 |
VersionedPessimisticRepeatableRead
|
If this parameter is set to yes, pessimistic D-tables with REPEATABLE READ isolation use versioned reads.
|
yes
|
RW/
Startup |
WriterIOThreads
|
Number of helper threads dedicated to writing tasks (per IO device).
Note The IOThreads must be greater than WriterIOThreads. If this rule is violated, the factory value is used.
If IOThreads=1 then the setting WriterIOThrreads=0 is enforced.
|
1
|
RW/
Startup |