This section describes the most important solidDB^® server-side parameters and their default settings.

When a server is started, it starts listening to one or more protocols with network names that distinguish it in the network. 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 parameter format.

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 used to store the database. The [IndexFile] section of solid.ini also controls the caching-related parameters.

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

To define the location and maximum size, the FileSpec parameter accepts the following three arguments:

Example:

The default value for the Indexfile.FileSpec parameter is solid.db 2147483647 (2 GB-1 expressed in bytes).

The size unit is 1 byte. You can use K and M unit symbols to denote kilobytes and megabytes. The maximum file size is (4G - 1) * blocksize. With the default 16 KB block size, the maximum is 64 TB - 1.

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 its performance. The actual device number serves only as a means for you to designate a distinct number for each physical device. The device number serves no other purpose, such as indicating the brand, model, or other characteristics of your storage 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 like the following:

In this case, FileSpec_2 and FileSpec_3 use the same physical device (even though the device names D: and E: are different), so they are assigned the same device number. The actual values used for the device number (1 for C:, 2 for D: and 2 E:) are arbitrary and meaningless.

If your database has reached the maximum size specified by the FileSpec parameter, you need to increase the maximum file size limit or divide the database into multiple files.

Do not attempt to use the FileSpec parameter to decrease the size of a database; you risk losing existing data and corrupting the database.

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 needed depends on the size of the database, the number of connected users, and the nature of the operations executed against the server. The default cache size is 32 MB. The absolute minimum size is 512 kilobytes.

Although the solidDB^® server is able to run with a small cache size, a larger cache size generally speeds up the server.

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.

The size unit is bytes. You can also specify the amount of space in units of megabytes, for example, “10M” for 10 megabytes.

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 of 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 above value backup, the backup is written to a directory that is a subdirectory of the solidDB^® directory.

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 in the NetBackup Server for the backup files, log files, and the configuration file is set with the NetBackupDirectory parameters in the source server and the network server side. If the remote directory does not exist, it is created (write rights needed).

The parameter General.NetBackupDirectory in the source server sets the remote directory for use of Network Backup. The value of the parameter is either absolute or relative to the root directory of the NetBackup Server.

The parameter Srv.NetBackupRootDir in the NetBackup Server sets the root directory for all netbackup operations in case the netbackup directory defined with the General.NetBackupDirectory parameter uses relative path expressions. The value of the Srv.NetBackupRootDir parameter can be absolute or relative to the working directory.

By default, the netbackup operation copies the database to one flat file in the NetBackupDirectory, even if the logical database consists of multiple files. Instead of flattening the structure to one file, you can define multiple files to which the source database files are mapped to during the netbackup operation. You map the source and target files in a backup.ini file that must be stored on the target server in the directory defined with the General.NetBackupDirectory parameter.

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 to 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’s tasking system.

The Threads parameter in the [Srv] section defines the number of general-purpose worker threads used by solidDB^®. 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 solidDB^® SQL Guide.

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 a problem. 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 is written to the current working directory of the server or client, depending on which end the tracing is started.