solidDB Help : solidDB reference : Server-side configuration parameters : Logging section
  
Logging section
The following table describes the parameters that can be used in the [Logging] section of the server-side solid.ini file.
For a description of the access modes, see Access mode and persistence of parameter modifications.
 
[Logging]
Description
Factory value
Access mode
BlockSize
Block size (in bytes) of log files.
Follow the value with K (to specify a value in KB).
For example: BlockSize=32K
The log block size can be changed between startups. Logs that have a block size different to the one set with this parameter are accepted at recovery. Large blocks reduce the overhead of log writing.
The value must be a multiple of 1K (1KB) and the maximum value is 64K (64KB).
16K
RW/
Startup
DigitTemplateChar
Template character that is replaced in the name template of the log files.
See the description of the Logging.FileNameTemplate parameter for more details.
#
RW/
Startup
DirectIO
If set to yes, the log file uses Direct I/O.
Direct I/O means that operating system buffer pool is bypassed in file I/O.
This parameter is not effective in Windows environments; in Windows environments, database files always use Direct I/O.
no
RW/
Startup
DurabilityLevel
Transaction durability level. The following values are valid:
1 (relaxed durability): Writes are asynchronous; there can be a delay between the time that the transaction is committed and the time that the transaction is logged.
2 (adaptive durability): Applies only to primary servers in HotStandby (HSB) operations:
If HotStandby.SafenessLevel is set to 2safe:
If both the primary and secondary servers in an HSB system are active, the primary server uses relaxed durability.
In all other situations, the primary server uses strict durability.
If HotStandby.SafenessLevel is set to any value other than 2safe, the primary server uses relaxed durability.
If HSB is not enabled, the server uses strict durability.
3 (strict durability): Writes to the transaction log are synchronous; as soon as a transaction has been committed, the transaction is written to the transaction log. See Controlling transaction durability.
The DurabilityLevel parameter affects the server behavior only if transaction logging is turned on. If you turn off transaction logging by setting Logging.LogEnabled to no, your data is not be logged to disk, regardless of the setting of DurabilityLevel.
If Logging.LogEnabled is set to no and DurabilityLevel is set, the server displays a warning message at the time that it starts. See also, Logging.LogWriteMode and HotStandby.2SafeAckPolicy.
1
RW
FileFlush
If set to no, the operating system (rather than the solidDB engine) flushes the log file.
This parameter is only valid for platforms supporting Synchronized I/O Data Integrity Completion, such as Solaris and Linux.
yes
RW/
Startup
FileNameTemplate
Path (optional) and naming convention that is used when creating log files.
At a minimum, this parameter defines the naming convention that is used when creating log files. If a path is not defined with this parameter, you can define a path with the Logging.LogDir parameter.
Note If both LogDir and FileNameTemplate parameters are specified, the values are concatenated, so make sure that the concatenated values result in a valid path and file name.
Template characters (for example, #) are replaced with sequential numbers. For example, the following file entry instructs the server to create log files in directory C:\soliddb\log and to name them sequentially starting from sol00001.log.
FileNameTemplate=c:\soliddb\log\sol#####.log
Your template can use 4 - 10 template characters. If you do not want to use the # sign as a template character, you can specify a different character by setting the parameter Logging.DigitTemplateChar.
After the last digit in the log file name sequence is reached (for example, sol99999.log), the server restarts the numbering from 0 (for example, sol00000.log).
The path (if specified) can be an absolute path or relative to the solidDB working directory and must use the conventions of your operating system. For example, in Windows environments, if the path contains white space characters, the path must be enclosed in double quotation marks. If the server runs on a UNIX operating system, path separators must be slashes instead of backslashes.
To achieve better performance by avoiding problems with network I/O, store the log files on a local drive using local disk names.
sol#####.log
RW/
Startup
LogDir
Directory prefix of the log file path, if it is not specified with the Logging.FileNameTemplate parameter.
Note If both LogDir and FileNameTemplate parameters are specified, the values are concatenated, so make sure that the concatenated values result in a valid path and file name.
For example: LogDir=c:\soliddb\log
The path should be an absolute path and must use the conventions of your operating system. For example, in Windows environments, if the path contains white space characters, the path must be enclosed in double quotation marks. If the server runs on a UNIX operating system, path separators must be slashes instead of backslashes.
The specified log directory must exist prior to starting the server. If the directory does not exist, the server returns the following type of error:
SsBOpenLocal failed, file 'log/sol00001.log', errno = 2, retries = 0, open files = 1
"." (the server working directory)
RW/
Startup
LogEnabled
If set to no, transaction logging is disabled.
If transaction logging is disabled, you get better performance but lower transaction durability. If logging is disabled and the server shuts down unexpectedly, you lose any transactions since the last checkpoint.
This parameter applies to in-memory tables and disk-based tables.
yes
RW/
Startup
LogSoftMemoryLimit
Maximum amount of memory (in bytes) that write queue items (writeq) can use.
Follow the value with K (to specify a value in KB), M (to specify a value in MB, or G (to specify a value in GB).
For example: LogSoftMemoryLimit=128M
The limit is a soft limit: it can be exceeded temporarily, for example, in case of large write operations.
The minimum value is 1M.
64M
RW
LogWriteMode
Mode in which the log is written. The following values are valid:
0: ping-pong method
2: overwrite method (factory value)
The choice of logging method depends on the log file media and the level of security required. For details on each of these methods, see Transaction logging.
2
RW/
Startup
MinSplitSize
Log file size (in bytes) after which the log is written to a new log file.
Follow the value with K (to specify a value in KB), M (to specify a value in MB, or G (to specify a value in GB).
For example: MinSplitSize=20M
The new log file is created after the next checkpoint.
10M
RW/
Startup
RelaxedMaxDelay
Maximum time (in milliseconds) that the server waits before committed transactions are written to the log.
This parameter applies only when the transaction durability level is set to RELAXED (by using the Logging.DurabilityLevel=1 parameter or the SET DURABILITY statement).
Minimum parameter value is 100.
5000
(5 seconds)
RW/
Startup
SyncWrite
If set to yes, the solidDB server assumes that the platform supports Synchronized I/O Data Integrity Completion.
This parameter applies only to platforms, such as Solaris and Linux, which support Synchronized I/O Data Integrity Completion. The parameter must be set to no on all other platforms.
no
RW/
Startup
ThreadPriority
Logging thread priority in Linux, AIX, and Solaris environments.
Defining the logging thread priority can increase throughput in case of write-intensive workloads when solidDB is under high load.
The following values are valid:
Normal - Logging thread is not prioritized.
Realtime - Logging thread is prioritized using the realtime scheduler of the operating system. If the Realtime priority cannot be set, the server does not start.
Adaptive - Server tries to set the logging thread priority as Realtime. If the Realtime priority cannot be set, the server defaults to Normal priority and an error is output in solmsg.out.
Note Before setting the Logging.ThreadPriority parameter to Realtime or Adaptive, you might need to adjust the security settings for real time use in your environment.

For example, in Linux 64-bit environments add the following two lines in /etc/security/limits.conf:

* hard rtprio 99
* soft rtprio 99

To activate the new security settings for all users, restart the operating system.
Normal
RW
Go up to
Server-side configuration parameters