Specifies the time in minutes after an idle transaction is aborted; negative or zero value means infinite.

120

Unit: 1 min

RW/
Startup

This parameter takes the average number of rows returned to the client as the rows per message value. The start value grows as more rows are fetched. If set to no, the RowsPerMessage parameter value is used. That is also the default value.

yes

RW/
Startup

If set to no, only connections from solidDB^® Remote Control (solcon) or solidDB^® SQL Editor (solsql) are allowed

yes

RW/
Startup

This parameter can be used specify commands for automating administrative tasks, such as executing operating system commands, creating backups, checkpoints, and database status reports.

The syntax of the value for this parameter is the following:

For example:

If you specify a backup, the default backup directory is the one set with the General.BackupDirectory parameter.

If the day is not given, the command is executed daily.

There is no factory value for this parameter.

For more information about entering time commands, including a list of the available commands and their arguments, see Entering timed commands.

(no factory value)

RW

The setting contains the directory path for storing the audit info files. The directory has to exist prior to starting the server. If the directory becomes unreachable or full while Audit is in progress, audit will fail with appropriate error code.

 

Startup

Enable audit info logging into solaudit.out file.

No

Startup

Internal parameter to keep the latest audit log file number.

 

 

Filter of the database operations to be collected.

params: Parameter values for monitored statements are included.

allsql: All SQL statements are monitored, also those not directly initiated by the user. When this filter is set for example SQL statements executed in stored procedures are included in the monitor output.

read: SQL statements that read table data are included in the monitor output. This means all SELECT statements are monitored.

write: SQL statements that write table data are included in the monitor output. This means that all INSERT, DELETE and UPDATE statements are monitored.

call: Stored procedure calls are included in the monitor output. Since it is not possible to classify procedures as read or write operations a separate filter is used for them.

ddl: SQL DDL statements are included in the monitor output.

dml: SQL DML statements are included in the monitor output.

 

Startup

Max file size for audit info file logging, used if AuditInfoLogEnabled=Yes. Audit info logging uses multiple files with each of size AuditInfoLogFileSize. Latest file is solaudit.out and older files are renamed using a pattern solaudit.<number>.out.

100000000 (about 100 MB)

Startup

Max total size for audit info log files, used if AuditInfoLogEnabled=Yes. When max size is reached then oldest audit file is deleted.

1000000000 (about 1 GB)

Startup

Maximum memory queue length used to buffer audit info records. If audit info records are not processed when the queue gets full then applications need wait for new space in the queue.

10000

Startup

Max time to wait audit read operation before records are discarded.

5

Unit: seconds

Startup

This parameter specifies the number of seconds between connection status checks in thread/client mode.

To use this parameter, you must set the Srv.ReadThreadMode parameter to 0 and the Srv.Threads to a large enough value to accommodate the threads in your environment.

When the Srv.ReadThreadMode parameter is set to 2 (default), the server does not detect a broken connection until it tries to write something back to the client.

10

Unit: seconds

RW/
Startup

Specifies the continuous idle time in minutes after a connection is dropped; negative or zero value means infinite.

480

Unit: 1 min

RW/
Startup

When the database size exceeds the limit defined with this parameter, the system generates a report file. This parameter gives the delta after which the next report is printed. The minimum delta value is 1 MB. The report file name is repdb<mb>MB.dbg.

This parameter is useful, for example when tracing unexpected database size growth.

If you leave this parameter to its default value 0, no reports are generated. The minimum non-zero value for this parameter is 1 MB.

0 MB

RW/
Startup

Disables generation of the solmsg.out and the solerror.out files. For details on these files, see Viewing error messages and log files. To disable file generation, this parameter must be included in the solid.ini file and set to yes. If this parameter is set to no or it is not included in the solid.ini file, the log files are generated.

no

RO

If set to yes, contents of solmsg.out file are displayed also at the server’s command window.

no

RW/
Startup

This parameter specifies how many result rows are sent (prefetched) to the client driver in response to the SQLExecute call with a SELECT statement. The result rows are subsequently returned to the application with the first SQLFetch calls issued by the application. The default value of 2 allows for prefetching of single-row results. If your SELECT statements usually return larger number of rows, setting this to an appropriate value can improve performance significantly.

See also the RowsPerMessage parameter.

2

RW/
Startup

This parameter applies only to symmetric multiprocess (SMP) Solaris operating systems, in which the default scope provided by the threads of the runtime library can be set to process scope, system scope, or light weight process (lwp) scope. In Solaris environments, threads are lightweight processes.

The value yes can improve the server’s performance in a multi-CPU machine significantly. The actual performance improvement depends on how evenly the workload is already spread across your CPUs. If this parameter is set to no, you should get slightly better performance in single-CPU systems.

When this parameter is set to yes, it forces lwp threads to be run in system scope, instead of process scope. It also allows Solaris to schedule solidDB^® threads on any available CPU. This reduces bottlenecks and enhances the parallelization of operations, including I/O. For more information on lwp, see Solaris operating system documentation.

Solaris: yes

Other environments: no

RW/
Startup

When the parameter is set to yes, a periodical check is performed to detect a stalled server due to, for example, unexpected operating system stalls or software errors.

The check uses a timeout-based server deadlock detection algorithm that checks certain critical low-level concurrent programming synchronization objects (mutexes).

If a deadlock is detected, the server process terminates with an error and a message is printed to solerror.out.

For example in High Availability (HotStandby) configurations, a failover can be enforced upon the detection of a server deadlock.

no

RW/
Startup

This parameter sets the interval of the server deadlock check.

Unit: seconds

60

RW

This parameter sets the deadlock detection timeout time.

The factory value is high enough to escape false errors. If faster detection is needed, set the parameter to a lower value.

Unit: seconds.

60

RW

Defines whether in solid.ini configuration file lines that are longer than 79 characters are split into multiple lines when server saves the file.

For example, if you create comments longer than 79 characters, the server splits the comments on separate lines using a backslash (\) at the end of the line but without adding a comment marker (;) on the new line. The server handles the lines that have been split in this way; however, applications such as watchdogs might see the file as corrupted and thus fail.

Value no means lines are never split.

yes

RW/
Startup

If this parameter is set to yes, the solidDB^® message log (solmsg.out) and trace files are not overwritten with new contents. Instead, when a file limit is reached, a new file is created with an incremented file name number postfix. The starting value of the postfix is set by using parameters Srv.TraceBackupFileNum and Srv.SolmsgBackupFileNum.

no

RO

Number of server’s internal tasks that execute the local background statements that were started with command START AFTER COMMIT (without FOR EACH REPLICA).

Valid values range from 1 - 100.

In this case, you can have 1 to N tasks that execute the background operations. More tasks mean that background tasks reserve more resources and are handled faster, and that other operations (for example, interactive ones) will get fewer resources and be handled more slowly.

2

RW/
Startup

This parameter (MAXimum BackGround TASK MaxBgTaskInterval INTERVAL) tells the server the maximum length of time to wait before checking whether internal administrative tasks that are “sleeping” should be “awakened”. The units are seconds.

For example, if a connection has been broken or disconnected, this parameter specifies the maximum length of time that the server will wait before noticing that the connection is gone. This time is IN ADDITION TO whatever time is required for the underlying communication layer to detect that the connection is broken. For example, if you have a Connect Timeout of 100 seconds and a MaxBgTaskInterval of 50 seconds, then you may have to wait up to 150 seconds before a broken connection is detected and no longer counted as one of the connections.

You may want to set or adjust this parameter if you get errors similar to the following:

This parameter applies only to the server’s own internal administrative tasks. It does not affect the scheduling of user tasks.

Setting MaxBgTaskInterval to a small enough value may reduce performance and may reallocate some time from high-priority tasks to low-priority tasks. This can happen in systems where low-priority connections are not checked often enough to notice that they have been disconnected. However, because the parameter only affects server administrative tasks, not user tasks, the effect is generally small.

2 (seconds)

RW/
Startup

This parameter controls the maximum number of bytes that the server will search through in a string, for example in WHERE clauses such as:

For example, if the value is 1024, ASCII character strings are searchable up to 1024 characters and Unicode character strings are searchable up to 512 characters (1024 bytes).

This parameter applies to strings that have the following data types:

It does not apply to strings that have the data type(s):

The minimum valid value is 254. If you specify a smaller number, the server will still search the first 254 bytes. Although you can use any value from 254 to 2G-1, practical values are generally in the range of a few kilobytes, like 1024, or 8192.

254 (254 bytes = 254 ASCII characters, or 127 Unicode characters)

RW

The maximum number of cursors that a database client can have simultaneously open.

1000

RW/
Startup

This allows you to specify the maximum string length of a single SQL statement sent to the server. This is particularly useful if you are sending CREATE PROCEDURE commands that are longer than 64K. The value should be between 64K (65536) and 1024K (1048576). If the value is less than 64K, the server will use a minimum of 64K.

512K (524288)

RW/
Startup

Maximum number of simultaneous “uncommitted” START AFTER COMMIT statements. Valid values range from 0 - 1000000.

10000

RW/
Startup

Defines the maximum number of connections to solidDB^®.

When the number of maximum users has been exceeded, error 14507 is issued and you can connect to solidDB^® only with solidDB^® Remote Control (solcon).

Value 0 means that the maximum number of connections is not restricted

0

RW/
Startup

This parameter defines how much memory allocations must increase or decrease compared to the previous message before the new message is printed to solmsg.out.

20 MB

RW/
Startup

This parameter defines the minimum size for memory allocations after which reporting to solmsg.out is done.

0 (no reporting)

RW/
Startup

When the memory size exceeds the limit defined with this parameter, the system generates a report file. This parameter defines the delta after which the next report is printed. The minimum delta value is 1 MB. The report file name is repmem<mb>MB.dbg.

This is parameter is useful, for example when tracing unexpected memory growth in the server.

If you leave this parameter to its default value 0, no reports are generated. The minimum non-zero value for this parameter is 1 MB.

0 MB

RW/
Startup

The maximum size of the solmsg.out file in bytes.

1 MB

Unit: 1byte k=KB m=MB

RW/
Startup

Specifies the informal name of the server, equivalent to the -n command line option.

 

RW/
Startup

Sets the root directory for the network backups in NetBackup Server. The path is relative to the working directory.

The working directory

RW

Defines the binding method for character data types. The options are:

raw

See description

RW/
Startup

Pessimistic table locks are used to prevent other sessions from adding, editing, or deleting any records or placing any record or table locks on a given table. Table locks block other record or table lock attempts, but do not block any reads of the locked table.

If pessimistic tables are used, they force the RowsPerMessage value to 1 if the query locks any rows. You can enable the RowsPerMessage for pessimistic tables by enabling the PessimisticTableUseNFetch parameter. By default, it is disabled.

no

RW/
Startup

Causes a unique 8-character message code to be inserted before each status and error message in the message log files (solmsg.out and solerr.out).

no

RW/
Startup

The process size limits are checked periodically. The check interval is set with the ProcessMemoryCheckInterval parameter. The interval is given in milliseconds.

The minimum non-zero value is 1000 (ms). Only values 0 or 1000 or above 1000 (1 second) are allowed. If the given value is above 0 but below 1000, an error message is given.

The factory value is 0, that is, process size checking is disabled.

The ProcessMemoryLimit and ProcessMemoryCheckInterval parameters are interlinked; if the ProcessMemoryCheckInterval parameter is set to 0, the ProcessMemoryLimit parameter is not effective, that is, there is no process memory limit.

See also parameters ProcessMemoryLowPercentage and ProcessMemoryWarningPercentage.

0

RW

As the amount on memory used crosses different boundaries specified with, for example, the ImdbMemoryLowPercentage or the ProcessMemoryLimit parameter, system events are given. The event behavior expresses hysteresis in a way that the value triggering the BELOW event is somewhat lower than the specified value triggering the ABOVE event. The difference can be, for instance, 5%. As a result, the number of system events is not too large if the amount of memory alternates rapidly just above and below the specified boundaries. The ProcessMemoryHysteresisPercentage parameter is used to set the difference as a percentage value.

5

RW

This parameter specifies the maximum amount of virtual memory that can be allocated to the in-memory database process.

When this limit is exceeded, the server gives an error message and accepts admin commands only. The limit can be changed dynamically.

The ProcessMemoryLimit and ProcessMemoryCheckInterval parameters are interlinked; if the ProcessMemoryCheckInterval parameter is set to 0, the ProcessMemoryLimit parameter is not effective, that is, there is no process memory limit.

1G

Unit: 1 byte, G=GB, M=MB, K=KB

RW

The ProcessMemoryLowPercentage parameter sets a warning limit for the total process size. The limit is expressed as percentage of the ProcessMemoryLimit parameter value.

Prior to exceeding this limit, you have exceeded the warning limit defined by using the ProcessMemoryWarningPercentage parameter and received a warning. When the ProcessMemoryLowPercentage limit is exceeded, a system event is given.

The ProcessMemoryLowPercentage parameter value is automatically checked for consistency. It must be higher than the ProcessMemoryWarningPercentage parameter value.

See also parameters ProcessMemoryLimit, ProcessMemoryCheckInterval, and ProcessMemoryWarningPercentage.

90

RW

The ProcessMemoryWarningPercentage parameter sets the first warning limit for the total process size. The warning limit is expressed as percentage of the ProcessMemoryLimit parameter value. When the ProcessMemoryWarningPercentage limit is exceeded, a system event is given.

The ProcessMemoryWarningPercentage parameter value is automatically checked for consistency. It must be lower than the ProcessMemoryLowPercentage parameter value.

See also parameters ProcessMemoryLimit, ProcessMemoryCheckInterval, and ProcessMemoryLowPercentage.

80

RW

This parameter controls the number of threads that the server uses to service client requests. If the value is 0, the server uses the number of threads specified with the parameter Threads. If the value is 2, the server creates a separate thread for each client. Using more threads will generally improve performance, but also requires more memory.

This parameter only controls the number of threads serving client requests. It does not affect the number of threads doing other work within the server.

Some operating systems may limit the maximum number of threads allowed, and setting this parameter’s value to 2 may cause the server to request more threads than the OS allows. If you try to exceed the number of threads allowed, you will get the following type of error:

2

RW/
Startup

Number of Replica server’s internal tasks inside the server that execute the remote background statements started at Master with command START AFTER COMMIT... FOR EACH REPLICA. Valid values range from 1 - 100.

2

RW/
Startup

Enables automated generation of reports at the given interval (in seconds).

Automated reports are named reptimestamp>.dbg and output to the solidDB^® working directory.

Value 0 means that reports are not generated automatically.

0

RW

Specifies the number of rows returned from the server in one network message when an SQLFetch call is executed (and there are no prefetched rows).

See also the ExecRowsPerMessage configuration parameter.

100

RW/
Startup

If set to yes, no output is generated to the server’s command window. Only license information is displayed.

no

RW/
Startup

This parameter defines the starting digit of the message log file (solmsg.out) name postfix, if the KeepAllOutFiles parameter is set to yes.

For example, if the value is set to 5, the solmsg.out files are named as follows:

Valid values range from 0 to 999999.

0

RW/
Startup

The StackTraceEnabled parameter controls the stack trace functionality upon an assertion failure or a signal caused by server malfunction. When set to yes, the stack trace information is output to ssstacktrace-<process_id>-<thread_id>.out file.

The following signals invoke the stack traces output automatically:

The stack traces information is produced only about the thread that received the signal.

Additionally, you can generate the stack traces information for all currently running threads by sending the server the SIGUSR1 signal.

no (Linux 64-bit)

yes (Linux 32-bit and UNIX systems)

RW/
Startup

By default, solidDB^® uses the ISO/IEC/ANSI standard date representation, which is also the standard date literal format in SQL. The date is represented as shown in the timestamp example below:

2008-10-15 09:29:40

When set to no, the message log files (solmsg.out) use a date format such as 15.10 09:29:40. The solerror.out file uses a date format such as Mon Oct 22 15:16:35 2007.

yes

RO

This parameter switches on tracing for statements that have allocated memory over the defined value. These statements are put into the peak memory usage list. The peak memory list is printed to report file. Statements that use memory over the defined limit are also printed to the solmsg.out file.

0 MB

RW/
Startup

If the Srv.ReadThreadMode parameter is set to 0, this parameter specifies the number of concurrent threads that the server uses to process user requests. The helper threads, such as I/O threads, are not included in the count.

If the value of Srv.ReadThreadMode is other than 0, the value of this parameter is insignificant, as the server controls the number of threads automatically.

5

RW/
Startup

The starting value of the trace file name postfix appended to the file name if the KeepAllOutFiles parameter is set to yes.

Valid values range from 0 to 999999.

0

RW/
Startup

This parameter allows you to limit the maximum size of the trace log file. The size is specified in bytes; for example, TraceLogSize=10000 limits the size of the trace log file to 10000 bytes. The trace log file is the file to which the server writes information when you turn on monitoring.

For information about turning on monitoring, see the description of ADMIN COMMAND 'monitor...' in ADMIN COMMAND syntax and the -m command-line option in solidDB^® command-line options.

Monitoring uses the file named soltrace.out for output. After reaching the maximum size, the following takes place:

100 m

Unit: 1 byte k=KB m=MB

RW/
Startup

Number of second decimals in trace outputs. Allowed values are from 0 to 3.

3

RW/
Startup