This topic describes the most important solidDB server-side parameters and their default settings.

Servers use network names (that distinguish the server in the network) to listen to one or more protocols. A client application uses a similar network name (connect string) to specify which protocol to use and which server to connect to.

The network name is defined with the Listen parameter in the [Com] section, for example:

The default value is operating system dependent. See Managing network connections for details on the format of the parameter value.

For details of the parameters in the Com section, see Communication section (server-side).

In solidDB, data and indexes are stored in the same file or files. The term "index file" is used as a synonym for the term "database file". The [IndexFile] section of the solid.ini file contains parameters that specify the name and location of the file or files that are used to store the database. The [IndexFile] section of solid.ini also controls the parameters that are related to caching, see IndexFile section.

The Indexfile.FileSpec parameter describes the location and the maximum size of an index file (database file).

The Indexfile.FileSpec parameter is also used to divide the database into multiple files and onto multiple disks. To divide the database into multiple files, specify another Indexfile.FileSpec parameter identified by the number 2. The index file is written to the second file if it grows over the maximum value of the first Indexfile.FileSpec parameter.

In the following example, the parameters divide the database file on the disks C:, D:, and E: to be split after growing larger than about 1 GB (=1073741824 bytes). The example does not use the optional device number.

Although the database files reside in different directories, the file names must be unique. In the example, the different device numbers indicate that C:, D:, and E: partitions reside on separate disks.

There is no practical limit to the number of database files you can use.

Splitting the database file on multiple disks increases the performance of the server because multiple disk heads provide parallel access to the data in your database.

You might need to have multiple files on a single disk if your physical disk is partitioned into multiple logical disks and no single logical disk can accommodate the size of the database file you expect to create.

If the database file is split into multiple physical disks, the multithreaded solidDB can assign a separate disk I/O thread for each device. This way the server can perform database file I/O in a parallel manner.

The optional device number that you can specify for each data file helps the server optimize performance when you have different database files on the same physical device.

If you have different files on the same physical device, use the same device number for each of those files. For example, on a Windows system that has two physical disk drives, the first physical disk drive is typically C:. A second physical disk drive could be partitioned into two logical disk drives, D: and E:. If one data file is put on C:, one on D:, and one on E:, the solid.ini file might look have the following entries:

In this case, FileSpec_2 and FileSpec_3 use the same physical device (even though the device names D: and E: are different) and so they are assigned the same device number.

If your database has reached the maximum size specified by the FileSpec parameter, you must increase the maximum file size limit or divide the database into multiple files. For information about what to do if your database has reached the maximum size, see Troubleshooting database file size (file write fails).

The IndexFile.CacheSize parameter defines the amount of main memory that is used to maintain the shared buffer pool of a disk database. This buffer pool is called the database cache.

The cache size that is required depends on the size of the database, the number of connected users, and the nature of the operations executed on the server.

Although the solidDB server is able to run with a small cache size, a larger cache size generally speeds up the server. There is no practical upper limit to the cache size, you can set the size of the cache so that the database can fit completely in the cache.

For disk-based tables (D-tables), at least 2% of the D-table size should be allocated as cache.

solidDB in-memory tables (M-tables) do not directly benefit from increased cache size. However, for M-tables, the cache size should be at least 8MB.

The solidDB external sorter uses the database cache for sorting. If you have large sort operations, increase this value and configure the external sorter to properly utilize the cache, see Sorting.

For a pure in-memory database (M-tables only), the cache size is mostly irrelevant, as long as it is not less than 8 MB.

For more information about controlling solidDB memory sizes, see Controlling memory consumption.

By default, new tables are created as in-memory tables (M-tables). You can set the default table type with the General.DefaultStoreIsMemory parameter.

You can override the value set with General.DefaultStoreIsMemory by using the STORE clause in the CREATE TABLE statement.

For example:

Backups of the database, log files, and the configuration file solid.ini are copied to the local backup directory. The directory must exist and it must have enough disk space for the backup files because all the database files that are associated with one database are copied to the same directory. The backup directory can be set to any existing directory except the solidDB database file directory, the log file directory, or the working directory.

The name and location for your backup directory is defined with the BackupDirectory parameter in the [General] section.

The default location is a directory relative to your solidDB working directory.

For example, with the following configuration,

the backup is written to a subdirectory of the solidDB directory that is named backup.

The backup directory entered must be a valid path name in the operating system. For example, if the server runs on a UNIX operating system, path separators must be slashes instead of backslashes.

The target directory (on the NetBackup server), that is used for backup files, log files, and the configuration file, is set by configuring parameters in the source server, or the source server and the target (NetBackup) server.

The parameter General.NetBackupDirectory in the source server sets the directory in the target (NetBackup server) to which files are backed up. The value of the parameter should be a relative path that uniquely identifies the source server. The actual path is determined by the configuration of the NetBackup server.

If the remote directory does not exist, it is created (write permission required).

The parameter Srv.NetBackupRootDir in the NetBackup server sets the root directory for all netbackup operations. The value of the Srv.NetBackupRootDir parameter can be absolute or relative to the working directory.

To ensure the durability of committed transactions, transaction results are written immediately to a file in a specified directory when the transaction is committed. To avoid problems with network I/O and to achieve better performance, store the file on a local drive using local disk names. The default log file directory is the solidDB working directory.

The Logging.FileNameTemplate parameter defines a filename structure for the transaction log files. For example, the following setting instructs solidDB to create log files in directory d:\logdir and to name them sequentially starting from sol00001.log.

The filename can also be structured by using the Logging.FileNameTemplate parameter together with the Logging.LogDir parameter. The Logging.LogDir parameter defines the directory prefix of the filename and the Logging.FileNameTemplate parameter defines the actual filename. For more information, see Logging section.

In addition to the communication, I/O, and log manager threads, solidDB can start general-purpose worker threads to execute user tasks in the server tasking system.

The Threads parameter in the [Srv] section defines the number of general-purpose worker threads used by solidDB. General purpose threads are used in solidDB merge, checkpoint, and backup tasks. Increasing this value has most effect on the merge task, where a larger value might increase merge performance.

For example:

The optimum number of threads depends on the number of processors the system has installed. Usually it is most efficient to have between 2 and 8 threads per processor.

You must experiment to find the value that provides the best performance on your hardware and operating system. A good formula to start with is:

The SQL Info facility lets you specify a tracing level on the SQL Parser and Optimizer. For details on each level, see SET SQL.

The SQL Info facility is turned on by setting the Info parameter in the [SQL] section to a non-zero value of the configuration file. The output is written to a file named soltrace.out in the solidDB directory.

Use this parameter for troubleshooting purposes only as it slows down the server performance significantly. This parameter is typically used for analyzing performance for a specific single query or specific queries. Standard solidDB monitoring is a better choice for generic application SQL database tracing.

The communication tracing facility is necessary, for instance, if the network hardware is not functioning properly. By turning on the tracing, the communication layer can log even the system-specific errors. System-specific errors can help in diagnosing the real problem in the network. For details, read Troubleshooting. The following parameters control the outputting of network trace information.

Trace: If you change the Trace parameter default setting from No to Yes, solidDB starts logging trace information about network messages for all the established network connections to the default trace file or to the file specified in the TraceFile parameter.

TraceFile: If the Trace parameter is set to Yes, then trace information about network messages is written to a file specified by the TraceFile parameter. If no file name is specified, the server uses the default value soltrace.out. Be default, the soltrace.out file is written to the current working directory of the server or client, depending where the tracing is started.