## Support Database Parameters

### Use

Most support database parameters are for troubleshooting. In normal operation, it is not necessary to change the support database parameters. Changing support database parameters requires very detailed knowledge of the database system. For information about other database parameters, see General Database Parameters, Special Database Parameters and liveCache Database Parameters.

Changes to database parameters do not take effect until the database instance is restarted.

You can also change some database parameters while the database is running. In addition you can choose how long the change is to be effective for these database parameters:

■ Until the next restart

■ Not until after the next restart

■ Immediately and permanently

Support Database Parameters

Parameter | Meaning | How can I change this Parameter?
_BACKUP_HISTFILE | Name of the history file for data and log backups | It cannot be altered.
_BACKUP_MED_DEF | Name of the file containing the definitions of the backup templates | It cannot be altered.
_EVENTFILE | Name of the file in which the database system logs internal events | Changes only apply after restart
_EVENSIZE | Size of the file in which the database system logs internal events | Changes only apply after restart

_IDXFILE_LIST_SIZE

Number of temporary intermediate result files in the case of parallel indexing

The database system indexes large tables using multiple server tasks. These server tasks write their results in temporary files. When the number of these files reaches the value of this parameter, the database system has to merge the files before it can generate the actual index. This results in a decline in performance.

Can be changed during operation

_IOPROCS_PER_DEV | Number of threads that the database system can use for asynchronous I/O operations (per data volume and system) | Changes only apply after restart
_KERNELDIAGFILE | Name of the log file of the kernel | Changes only apply after restart
_KERNELDUMPFILE | Name of the dump file that is written by the kernel when the system crashes To this file, the database system writes, among other things, the contents of the data cache and the converter. Size your system so that sufficient memory space is available for this file (approximately CACHE_SIZE + 10%). Note also parameter DIAG_HIST_NUM. | Changes only apply after restart
_KERNELTRACEFILE | File in which the kernel writes the trace entries The kernel only writes trace entries if you previously activated the database trace. | Changes only apply after restart
_MAXEVENTTASKS | Maximum number of event tasks The database system uses event tasks both for Event Dispatcher and for the DBM commands event_wait, event_receive, event_available, auto_extend and auto_update_statistics. These commands can be active simultaneously for this database instance. The default value of the Database Manager for this parameter is 2. | Changes only apply after restart
_MAXTASK_STACK | Size of the stack that is used by the user tasks | Changes only apply after restart
_MINREPLY_SIZE | Minimum size of the memory that is available in a package (shared memory segment) for the reply 0: For the application as well as for the kernel, the whole package is available for the request/reply. | Changes only apply after restart
_MULT_IO_BLOCK_CNT | see DATA_IO_BLOCK_COUNT and LOG_IO_BLOCK_COUNT |
_PACKET_SIZE | Size of the packages (shared memory segments) into which SQL statements and data are transmitted A package consists of a request part and a reply part. | Changes only apply after restart

_READAHEAD_BLOBS

Number of pages from which large LONG values are imported in advance by additional server tasks

If a LONG value is too large to be transferred to the client in a single request package, the database system splits it into several request packages. To increase performance, server tasks can import further parts of the LONG value while the first request package is being sent.

Can be changed during operation

_RESTART_TIME

Minimum time between two savepoints (in seconds); corresponds to the time that is required for a restart after a system crash

Beyond this, the database system always writes a savepoint in the following cases:

● When you have created an index

● When the number of pages released by a savepoint is larger than the number of free blocks in the data volumes

Changes only apply after restart

_RTEDUMPFILE | File in which the kernel writes information about the runtime environment if the system crashes | Changes only apply after restart
_SERVERDB_FOR_SAP | Specifies whether the database instance is being used in an SAP system | Can be changed during operation
_TASKCLUSTER_01 to _03 | These parameters describe how the database system distributes user tasks to the threads. Only change these parameters after consulting support. | Changes only apply after restart
_USE_ASYNC_IO | Specifies whether operating system functions or special I/O threads are used for asynchronous I/O operations | Changes only apply after restart
_USE_IOPROCS_ONLY | YES: I/O operations are executed only by special I/O threads NO: the kernel decides whether a task is to execute an I/O operation itself or give the I/O operation to a special I/O thread | Can be changed during operation
ALLOW_MULTIPLE_SERVERTASK_UKTS | Specifies whether the database system distributes the server tasks to the available user kernel threads or if they all run in the same user kernel thread | Changes only apply after restart
COLUMNCOMPRESSION | Determine whether the column values can be stored in variable length or not. Default value: YES (columns have variable length, so the values can be compressed if necessary) Only for columns that are not primary key columns | Can be changed during operation
DATA_IO_BLOCK_COUNT | Block size that the database system uses when writing data pages from the data cache to the data area. The optimum block size depends on the hardware and software that is used. | Changes only apply after restart
ENABLE_SYSTEM_TRIGGERS | Defines whether system triggers are called when the database is restarted | Changes only apply after restart
EXPAND_COM_TRACE | Specifies whether memory space is reserved when COM trace files are created | Changes only apply after restart
INIT_ALLOCATORSIZE | Initial size of the working memory that is reserved at the start of a database session | Changes only apply after restart
LOAD_BALANCING_DIF | Only for load balancing; specifies by how much longer the task to be moved had to wait in its user kernel thread than the task that has been waiting the longest in the target user kernel thread (as a percentage) | Changes only apply after restart
LOAD_BALANCING_EQ | For load balancing; specifies which time delay should be regarded as equal when comparing waiting tasks (as a percentage) | Changes only apply after restart
LOG_IO_BLOCK_COUNT | Block size that the database system uses when writing log pages from the log queues to the log area The optimum block size depends on the hardware and software that is used. | Changes only apply after restart
LOG_QUEUE_COUNT | Number of log queues =0: Number calculated from the MAXCPU parameter >0: Value of the USED_LOG-QUEUE_COUNT parameter is adopted | Changes only apply after restart
MAX_SERVERTASK_STACK | Maximum size of the stack that is used by the server tasks | Changes only apply after restart
MAX_SPECIALTASK_STACK | Maximum size of the stack that is used by special tasks (all except user tasks and server tasks) | Changes only apply after restart
MAXPAGER | Maximum number of pagers; calculated by the database system from MAXDATAVOLUMES, among other parameters | Not changeable You can override this parameter with XP_MAXPAGER.
MAXVOLUMES | Maximum number of data and log volumes including mirrored volumes; calculated by the system | Changes only apply after restart

MINI_DUMP

Defines whether the system writes the memory dumps knlmini.dmp and srvmini.dmp (for postmortem debugging) and how much information these dumps contain

DISABLED: the system does not write any memory dumps

NORMAL (default value): the system writes all stacks and system handle information in the memory dump

FULL: the system writes all stacks and data segments in the memory dump

Changes only apply after restart

OMS_STREAM_TIMEOUT | Maximum wait time for all database sessions that may elapse until the reply to an OMS stream request to a client (in seconds) | Can be changed during operation
OPTIM_CACHE | Defines whether the database system determines the search strategy only once or every time it executes a parsed SQL statement For prepared statements with parameters, it may be sufficient to determine the search strategy only once. | Can be changed during operation
OPTIMIZE_OPERATOR_JOIN | Defines whether the database system uses optimized join implementation (saves resources) | Can be changed during operation
SET_VOLUME_LOCK | Specifies whether the database system sets a lock when a volume is added, which prevents the same volume from being added again later In the following cases it may make sense to set this parameter to NO: ● NFS-mounted volume ● Hot Standby System | Changes only apply after restart
SHOW_MAX_STACK_USE | Logs the maximum stack usage of each task in the kernel log Only set this parameter to YES for diagnosis purposes as it compromises performance. | Changes only apply after restart
SUPPRESS_CORE | Defines whether the database system suppresses core dumps of the kernel | Changes only apply after restart
SYMBOL_DEMANGLING | Defines whether the database system performs C/C++ demangling | Changes only apply after restart
UPDATESTAT_PARALLEL_SERVERS | Defines how many parallel server tasks the database system uses for updating the SQL Optimizer statistics Value -1: update of statistics is done sequentially Value 0: database system decides how many parallel server tasks should be used Value n>0: database system uses a maximum of n parallel server tasks | Can be changed during operation
USE_OPEN_DIRECT | YES: the database system uses the O_DIRECT flag when opening volumes (if this flag is supported by the file system). You use this flat to configure that the operating system does not use a separate cache for I/O operations. Note that this flag is ignored for Linux kernel < 2.4.18. | Changes only apply after restart
USE_SYSTEM_PAGE_CACHE | Defines whether the database instance uses the system page cache for buffering memory pages that are no longer required | Changes only apply after restart