default: depends on operating system or instance type
possible values: "BacktraceOnly" "BacktraceAndNormalMiniDump" "BacktraceAndFullMiniDump" "BacktraceAndCoreFile" "CoreFileOnly" (values depend on operating system)
change: OFFLINE
&if $OS in [ WIN32 ] AbortHandlingMode 'BacktraceOnly', 'BacktraceAndNormalMiniDump' or 'BacktraceAndFullMiniDump' BacktraceOnly: Do not produce a mini dump file BacktraceAndNormalMiniDump: Produce a normal mini dump file BacktraceAndFullMiniDump: Produce a full mini dump file &else AbortHandlingMode 'BacktraceOnly', 'BacktraceAndCoreFile' or 'CoreFileOnly' BacktraceOnly: Write a stack back trace to the KnlMsg and KnlMsgArchive files, do not produce a core file BacktraceAndCoreFile: Write a stack back trace to the KnlMsg and KnlMsgArchive files, additionally produce a core file CoreFileOnly: Write a core file only &endif
default: 0
change: OFFLINE
If set to a value greater than 0, an additional log queue is allocated. This queue is only used by special transactions which shall not affect the system performance. A transaction is bound to the additional queue by issuing the sql command LIMIT TRANSACTION LOG before any data manipulation took place. The parameter value defines the amount of logpages which are read in one chunk by the logwriter from the additional log queue. The amount is defined as the percentage of the LogIOClusterSize.
default: depends on operating system or instance type
possible values: "OFF" "LOW" "MID" "HIGH"
change: RUNNING
AllocatorRegistryCheckLevel "OFF", "LOW", "MID" or "HIGH"
'OFF' : No registry checks
'LOW' : Low level registry checks
'MID' : Mid-range registry checks
'HIGH' : High level registry checks
(char(8))
default: 0
change: RUNNING
Trace of owners of memory chunks 0 : off >0 : number of routines traced in calling sequence when allocating memory chunks
default: 0
change: RUNNING
The number of server tasks used for parallel check data execution. In case the value is set to 0 (default) the database will automatically use the number of attached data volumes. Any value n > 0 will use a maximum of n server tasks at a time regardless of the number of data volumes. There is no guarantee that as many server tasks as given will actually be used as there may be other database jobs competing for the server tasks available.
default: "NO"
possible values: "YES" "NO"
change: RUNNING
Enables checks for usage of 'versionsupport' container property
default: 524288
change: OFFLINE
In a communication packet, SQL statements and the data are transferred. CommandBufferSize limits the length of this communication packet and thus the maximum length of an individual SQL statement. Increasing the CommandBufferSize accelerates data transfer for bulk commands, and also enlarges the storage requirements per user task. The lower and upper limits are: 49152 <= CommandBufferSize <= 1048576 (4 bytes integer)
default: "YES"
possible values: "YES" "NO"
change: RUNNING
new in 7.9.09.01
CompactMultiphaseOutputColumns 'YES' or 'NO'
'YES': Stackcode will be optimized to eliminated duplicate output columns
'NO' : Stackcode will not be optimized to eliminated duplicate output columns
default: 3
change: RUNNING
new in 7.9.10.01
Controls the level of compression for compressed backups. A value of 1 results in less compression but faster runtime while 9 means best compression but also more runtime (4 bytes integer)
default: 50
change: OFFLINE
As soon as more than DataCacheIOAreaFlushThreshold percent of the data cache pages have been modified, the PAGER begin to search for modified pages using the data cache's I/O chain. These pages are written when they are in the area of the LRU list specified by the parameter DataCacheIOAreaSize. In this way, the quantity of pages to be written for a SAVEPOINT decreases. The lower and upper limits are: 30 <= DataCacheIOAreaFlushThreshold <= 80 (4 bytes integer)
default: 50
change: OFFLINE
Specifies the percentage of the LRU list of the data cache to be considered by the PAGER starting at the end of list. The data cache contains a list ( I/O chain ) of all modified pages to accelerate the detection of these pages by the PAGER. The found page will only be written by the PAGER when it belongs to the final DataCacheIOAreaSize percent of the LRU list. In this way, only the modified pages are written that have not been accessed for a relatively long time. The lower and upper limits are: 10 <= DataCacheIOAreaSize <= 90 (4 bytes integer)
default: 25
change: OFFLINE
This parameter defines a condition starting at which the PAGER must wake up to write out the modified pages from the final part of the data cache's LRU list. As soon as more than DataCacheLRUAreaFlushThreshold percent of modified pages are contained in the final 10% of the data cache's LRU list, the corresponding PAGER begin to write out these pages. Therefore, sufficient buffer space will usually be available at the end of the LRU list. This means, user tasks needing free space in the data cache will usually find it without having to swap pages from the data cache. It must be avoided that user tasks itself must swap pages from the data cache. The lower and upper limits are: 10 <= DataCacheLRUAreaFlushThreshold <= 80 (4 bytes integer)
default: 5
change: RUNNING
The value specifies the maximum percentage of the data cache used for database objects (tables, indexes etc.) that has a CACHE attribute. A part of the data cache specified by this value is dedicated for database objects with the CACHE attribute only. However, if the accessed CACHE data is less than this value, normal database object data will occupy the remaining part of pin area. If DataCachePinAreaThreshold is smaller than total size of database objects having the CACHE attribute the hit rate of CACHE data may be poor. If the value is 0, CACHE database objects are handled in same way as normal database objects The lower and upper limits are: 0 <= DataCachePinAreaThreshold <= 50 (4 bytes integer)
change: OFFLINE
DataCacheSyncGranularity, which is used in combination with UseFineGranularSynchronization, represents fine granularity of data cache synchronization. The larger value enables the more parallel operations for cached pages in data cache. Note that DataCacheSyncGranularity is effective only if UseFineGranularSynchronization, which supports higher level of parallelism than DataCacheStripes supports, is set to YES. The default value is: if (( CacheMemorySize / 128 ) < ( DataCacheStripes * 2 )) DataCacheSyncGranularity = DataCacheStripes * 2 else /* usual case */ DataCacheSyncGranularity = CacheMemorySize / 128 The lower and upper limits are: DataCacheStripes * 2 <= DataCacheSyncGranularity <= CacheMemorySize * 4 (4 bytes integer)
change: RUNNING
If a filename is set. This is used to dump all SQL locks into this file in the rundirectory. If the filename is left blank then no dump will be written in case a deadlock was detected. The format of the file can only be read analyzed by the developers or the development support. You have to use the tool diagnose.
default: "YES"
possible values: "YES" "NO"
change: OFFLINE
'YES': The server tasks will run in a dedicated set of UKTs 'NO' : User and server tasks will share a set off UKTs
default: depends on operating system or instance type
possible values: "YES" "NO"
change: OFFLINE
Specifies when the stack required for user session is allocated
DeferStackAllocation = 'NO' or 'YES'
'NO' : Stack is allocated when starting the database kernel.
Thus, certain incompatibilities regarding the database
configuration and too small swap space are detected immediately.
'YES' : Stack is allocated when user connects to the system.
Thus, the database kernel only uses only the actually required
virtual address space for user tasks.
Note however that the CONNECT command can fail due to insufficient
resources.
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
'YES': tables and indexes are deleted without reading the leaf pages. 'NO' : tables and indexes are deleted with iterating the leaf pages.
change: RUNNING
This parameter is used to control early garbage collection (EGC) of deleted committed objects. Apart from parameter EarlyGarbageCollectionThreshold some container may need more aggressive EGC. These containers may be specified using parameter EarlyGarbageCollectionContainer. value: list of braced tuples: (containerID,) containerID - containerId of a container which is to be handled more aggressively by EGC values are specified as hex values, leading zeroes of the containerIDs may be omitted - if corresponding container has more than objects, which have been marked for deletion, EGS is triggered. the list is of type char(256) example: (0000000000000566, 500) ( 0000058A,1000) (58C, 1000)(09ABF, 3000 )
default: 15
change: RUNNING
Early garbage collection will be triggered after waiting specified interval if - EarlyGarbageCollectionThreshold is greater than zero. - last triggered early garbage collection has finished its work The value is interpreted as time interval in minutes.
default: 0
change: RUNNING
This parameter is used to control early garbage collection of deleted committed objects. If the percentage of marked deleted object in relation to all objects allocated is higher than EarlyGarbageCollectionThreshold then the corresponding container will be handled by early garbagecollection. A garbage collector will iterate the complete container and will check for each object marked as deleted, if the object or some of its history is still consistent for some existing consistent view. If there is no consistent view, which still needs to access the object or its history, then the object frame will be freed by garbage collection. The benefit of this feature is, that there are potentially less frames to be skipped by iterators. If threshold is zero the feature is disabled The lower and upper limits are: 0 <= EarlyGarbageCollectionThreshold <= 100 (4 bytes integer)
default: "YES"
possible values: "YES" "NO"
change: OFFLINE
'YES': in case of a crash, the AK cache will be dumped
default: depends on operating system or instance type
possible values: "YES" "NO"
change: RUNNING
Enables grouping of adjacent pages into I/O cluster for better I/O performance. 'YES' : enables I/O clustering 'NO' : prevents I/O clustering
default: "YES"
possible values: "YES" "NO"
change: RUNNING
Enables the automatic data volume balancing after adding a new data volume or after restart of the database
default: "NO"
possible values: "YES" "NO"
change: RUNNING
new in 7.9.10.00
EnableDBSCommandStatistic 'YES' or 'NO'
'YES': DBS commands are logged in command statistic too.
'NO' : DBS commands are no logged in command statistic. Only prepare / execute calls are logged.
default: "YES"
possible values: "YES" "NO"
change: RUNNING
new in 7.9.09.01
EnableDeadlockLogging 'YES' or 'NO'
'YES': Detected SQL deadlocks will be inserted into system table DETECTEDDEADLOCKS
'NO' : No inserts into system table DETECTEDDEADLOCKS
default: "NO"
possible values: "YES" "NO"
change: RUNNING
EnableDelayedRootPageCreation 'YES' or 'NO'
'NO' : Root page is created on file creation.
'YES': Root page is created on first insert into the file
default: "No"
possible values: "YES" "NO"
change: RUNNING
new in 7.9.09.01
With this parameter additional statistic data for share locks are collected. These data can be analyzed by using the SHOW SHARE command of x_cons. This parameter can be changed in ONLINE mode. Valid types are: 'YES': enable extended share lock statistic 'NO' : extended time measurement not used Setting this database parameter to 'Yes' may have a bad performance impact.
default: depends on operating system or instance type
possible values: "YES" "NO"
change: RUNNING
new in 7.9.09.02
EnableFaultTolerantCreateFunc 'YES' or 'NO'
'YES': Memory shortage in QueryRewrite component won't hinder create function
'NO' : Memory shortage in QueryRewrite component result in error message at create function statement
default: "NO"
possible values: "YES" "NO"
change: RUNNING
EnableFetchReverseOptimization 'YES' or 'NO'
'YES': reverse fetch optimization for order by desc indexes is switched on
'NO' : reverse fetch optimization for order by desc indexes is switched off
default: "YES"
possible values: "YES" "NO"
change: RUNNING
If this parameter is set to 'YES' the database systems will periodically check if the system table SYSUPDATECOUNTERWANTED has any entries. If there are entries present, the database system will then try to initialize/reinitialize the statistics counters in the file directory for the tables/indexes in SYSUPDATECOUNTERWANTED while the database is idle. Setting the parameter to 'NO' deactivates these automatic checks and the background initialisation of the file directory counters. Setting this parameter to 'NO' while the database system is running will cancel a running file directory counter initialisation.
default: "YES"
possible values: "YES" "NO"
change: RUNNING
If ais given in SQL statement and this optimization is enabled we try to calculate an access stratetgy to get records as soon as possible. EnableFirstRowAccessOptimization 'YES' or 'NO' 'YES': extended strategy search if is given in SQL statement 'NO' : no optimization with
default: depends on operating system or instance type
possible values: "YES" "NO"
change: OFFLINE
new in 7.9.09.01
'YES': The garbage collector tasks can be balanced between the UKTs 'NO': All garbage collector tasks will reside in its home UKTs The overall balancing must be enabled which means that the parameter LoadBalancingCheckInterval is greater than 0.
default: "NO"
possible values: "YES" "NO"
change: OFFLINE
new in 7.9.10.00
EnableIncompleteRecovery 'YES' or 'NO'
'YES': An incomplete recovery will allow an attempt to restart the database.
The restart might succeed in case no critical pages are missing.
Use only as a last attempt if no valid backup medium is available.
This handles the recovery process after an error has been detected:
- a savepoint is written using as many pages as possible
- the database is marked as restartable
'NO' : An incomplete recovery will not allow an attempt to restart the database..
default: "YES"
possible values: "YES" "NO"
change: RUNNING
'YES' : I/O times will be collected 'NO' : I/O times will not be collected Setting this parameter to 'YES' starts collection of timing information used for monitoring I/O throughput. Since it is online changable, it is possible to enable or disable collection of time information during runtime. Measuring time of I/O operations adds only a minimal overhead, therefore it's turned on by default. (char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
EnableJoinHashTableOptimization 'YES' or 'NO'
'YES': usage of hashtables for join handling is switched on
'NO' : usage of hashtables for join handling is switched off
default: "YES"
possible values: "YES" "NO"
change: RUNNING
EnableJoinIntermediateSort 'YES' or 'NO'
'YES': create and sort temporary result if there isn't an join access path (key/index)
'NO' : if there is a join without access path between two tables coordinator join is used
default: "NO"
possible values: "YES" "NO"
change: OFFLINE
'YES': all liveCache data (with the exception of undo/history data) is considered to have the CACHE attribute and thus will use the part of the data cache reserved via DataCachePinAreaThreshold. 'NO': no liveCache data is considered to have the CACHE attribute
default: "NO"
possible values: "YES" "NO"
change: RUNNING
EnableLockOverflowDump = 'YES' or 'NO'
The first time the number of requested SQL locks exceeds the number
of available SQL locks, a diagnostic file is written containing
the internal structure of the SQL locks. This diagnostic file
is to be used by MaxDB support. To write the file a second time,
change this parameter to NO and then to YES again.
Possible values are:
'YES' : write a diagnostic file.
'NO' : don't write a diagnostic file.
(8 byte character)
default: "NO"
possible values: "YES" "NO"
change: RUNNING
EnableLogRedoMonitor 'YES' or 'NO'
The length of the list can be changed via
'LogRedoMonitorListLen' parameter.
'YES': Commands executed durig log redo are measured
'NO': No measuring overhead during the log redo phase.
default: "NO"
possible values: "YES" "NO"
change: RUNNING
EnableLogRestoreCompleteIndex 'NO' or 'YES'
'NO': During restart and redo log restore indexes are marked as BAD and have to be created after the restart and restore. This allows a quicker restart.
'YES': During restart and redo log restore indexes are created completely.
default: "YES"
possible values: "YES" "NO"
change: RUNNING
EnableMinMaxAggregationOptimizer 'YES' or 'NO'
'YES': optimization for MIN and MAX aggregation is switched on
'NO' : optimization for MIN and MAX aggregation is switched off
default: "YES"
possible values: "YES" "NO"
change: RUNNING
EnableOnePhaseJoin 'YES' or 'NO'
'YES': onephase join execution for complex commands is switched on
'NO' : onephase join execution for complex commands is switched off
default: depends on operating system or instance type
possible values: "YES" "NO"
change: OFFLINE
Use optimized system call for polling large set of network sockets, if set.
Depending on operating system, following optimized calls are available:
- Linux (all platforms): epoll interface
- Sun (all platforms) and HP (ia64): /dev/poll interface
- Windows (all platforms): ConnectEx/AcceptEx with overlapped I/O
Normally you should keep optimized network processing enabled. However,
there are certain rare cases where the optimized system call may actually
slow down the system. In such a case, you can try turning optimized
system call off.
Optimized system call works the best if there are many existing connections,
but only small percentage of these are actually sending/receiving data at
the same time (which is normally the case - most connections are idle
either waiting for server to prepare a response or waiting for client to
send the next command).
Due to allocation problems on Windows (wrong free block pattern) the default
is temporarily set to "NO" for Windows.
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
EnableOuterJoinOptimization 'YES' or 'NO'
'YES': join sequence search for outer joins is switched on
'NO' : join sequence search for outer joins is switched off
default: "YES"
possible values: "YES" "NO"
change: OFFLINE
new in 7.9.10.00
'NO' : Free Block Manager is constructed by one task 'YES': Free Block Manager may be constructed by several concurrent tasks (char(8))
default: "NO"
possible values: "YES" "NO"
change: RUNNING
EnablePartitionedHashJoin 'YES' or 'NO'
'YES': Partitioned hash join can be used
'NO' : Partitioned hash join cannot be used
default: "NO"
possible values: "YES" "NO"
change: OFFLINE
EnablePreAllocateIOWorker 'YES' or 'NO'
This switch controls allocation of resources for IO worker threads.
'YES': All configured IO worker threads are created during startup phase
'NO' : IO Worker threads are started when needed (default)
If configuration is near machine resource limits, it can happen that IO worker
thread resources are not available during runtime. This can even prevent a
successfull backup.
If the configuration is not near machine resource limits, it is much more
effectiv to create IO worker thread resources on demand, which is the default.
default: "NO"
possible values: "YES" "NO"
change: RUNNING
EnableQualificationBypass 'NO' or 'YES'
'NO' : don't bypass superfluous qualification for key-prefix queries
'YES': bypass superfluous qualification for key-prefix queries
default: "YES"
possible values: "YES" "NO"
change: RUNNING
EnableQualificationOnIndex 'YES' or 'NO'
'YES': search for addnl. qualification on indexes
'NO' : don't search for addnl. qualification on indexes
default: "NO"
possible values: "YES" "NO"
change: RUNNING
'YES': If not needed for history access or for garbage collector activity, undo files are removed by transactions itself. 'NO': Undo files are removed by garbage collection
default: depends on operating system or instance type
possible values: "YES" "NO"
change: OFFLINE
This parameter allows to enable the os based schedule-no-age-policy for the database kernel process. The schedule-no-age-policy allows threads in the user-level run queues to be assigned a fixed timeshare priority. These threads are linked to the same run queue as other threads with timeshare scheduling but their priority is not changed. ( see also: HP-UX, SCHED_NOAGE, SCHED_TIMESHARE). To enable this feature the os user group 'sdba' needs RTSCHED rights. Use the os command 'setprivgrp' to do this. Possible values are: 'NO' : No age scheduling policy disabled (default). 'YES' : No age scheduling policy enabled (default).
default: "YES"
possible values: "YES" "NO"
change: OFFLINE
new in 7.9.09.01
'YES': The server tasks can be balanced between the UKTs 'NO': All server tasks will reside in its home UKTs The overall balancing must be enabled which means that the parameter LoadBalancingCheckInterval is greater than 0.
default: "NO"
possible values: "YES" "NO"
change: RUNNING
EnableSharedSQLForInternalSQL 'YES' or 'NO'
'YES': internal SQL will be stored in SharedSQL
'NO' : internal SQL will not be stored in SharedSQL
default: "YES"
possible values: "YES" "NO" "ORDERED"
change: RUNNING
EnableStarJoinOptimization 'YES' or 'NO'
'YES': special star join sequence search is used
'NO' : normal join sequence search is used
default: "YES"
possible values: "YES" "NO"
change: RUNNING
EnableSubTreeLock 'YES' or 'NO'
'YES': subtree locks on primary trees are switched on
'NO' : subtree locks on primary trees are switched off
default: "YES"
possible values: "YES" "NO"
change: RUNNING
EnableSymbolDemangling 'YES' or 'NO'
'YES': During stack backtrace output, demangling of C++ symbols is allowed (default)
'NO' : During stack backtrace output, demangling of C++ symbols is suppressed
The demangling libraries of some operating systems could be buggy. If symbolic resolution leads
to a problem, this switch can be used to suppress demangling completely. Mangled symbols are harder
to read, but at least are shown.
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
EnableSymbolResolution 'YES' or 'NO'
This switch controls symbol resolution in stack backtrace for diagnostic output.
This feature is used especially in livecache procedure trace files.
'YES': symbol resolution in stack backtrace diagnostic output is allowed
'NO' : symbol resolution in stack backtrace diagnostic output is supressed
The symbolic resolution in a crash situation is not influenced.
default: "YES"
possible values: "YES" "NO"
change: RUNNING
'NO' : Any I/O will be handed over to I/O threads
'YES': I/O will be handed over to threads except that within an UKT
happens nothing but I/O. In this special case I/O will be made by the task itself.
(char(8))
default: "YES"
possible values: "YES" "NO"
change: OFFLINE
EnableVariableInput 'YES' or 'NO' 'YES': variable-length input-values can be send to the kernel 'NO' : variable-length input-values are not allowed In case EnableVariableOutput is set to 'YES', EnableVariableInput has to be 'YES', too. (char(8))
default: "NO"
possible values: "YES" "NO"
change: OFFLINE
EnableVariableOutput 'YES' or 'NO'
'YES': variable-length output-values can be send to the client
'NO' : variable-length output-values are not allowed
(char(8))
default: "knldiag.evt"
change: OFFLINE
This is the name of the event file used for internal diagnostic. The messages found in this file are database events of any priority. Normally this file is not written since its main purpose is development diagnosis of event generation. (char (256))
default: 0
change: OFFLINE
The event file specified by parameter EventFileName has fixed size. It is normally not written, but if it is written it is automatically overwritten in cycles if the EventFileSize limit is reached. This parameter specifies the fixed size (in KB) of the event file. Normally this file is not written since its main purpose is development diagnosis of event generation. The lower limit is: 0 <= EventFileSize (0 means event file is not written, which is default) (2 bytes integer)
default: 8
change: OFFLINE
Defines the number of service tasks that can be used to serve event- and DBAnalyzer-requests. ( see also: PreservedEventTasks and PreservedDBAnalyzerTasks). (4 bytes integer)
default: "DEFAULT"
possible values: "YES" "NO" "DEFAULT"
change: RUNNING
ForceSchedulePrioritizedTask = 'YES', 'NO' or 'DEFAULT'
'YES' means: A message is signaled to another UKT to interrupt
the running task in favor of a priority task.
'NO' means: This parameter has no effect.
'DEFAULT' means:
IF MaxCPUs > 1
THEN
act as if set to 'YES'
ELSE
act as if set to 'NO'
(char(8))
default: "NO"
possible values: "YES" "NO"
change: RUNNING
ForceSchemaSpecification 'NO' or 'YES'
'YES': Schema name has to be specified in procedures, triggers and functions.
'NO' : Schema name could be omitted.
change: OFFLINE
The lower and upper limits are:
1 <= GarbageCollectors <= MaxCPUs
(4 bytes integer)
default: 2
change: RUNNING
This value defines if index leaf pages are released after read. This is usefull if a large index scan would cause a high collision rate on the index. 0: means caching is disabled 1: means caching is always enabled 2: means caching is enabled but only used if the caller tells that a large index scan is done.
default: 0
change: OFFLINE
Initial size of the task-specific allocator (bytes). Minimum is 1 MB
default: 100
change: OFFLINE
Number of locks provided for every individual lock list region.
To avoid a high collision rate of the LOCKPOOLREGION,
the InternalLockStructureEntries should be increased.
The lower limit is 10
The upper limit is 100000
(4 bytes integer)
default: "BCD"
possible values: "BCD" "BASE100FORSUMMATION"
change: RUNNING
UseBase100AdditionSubtraction 'BCD' or 'BASE100FORSUMMATION'
'BCD' : add or subtract two BCD numbers using base-10 digit arrays
of integers
'BASE100FORSUMMATION' :
add or subtract two BCD numbers using base-100 digit arrays
of unsigned characters
default: 32768
change: OFFLINE
Default calculation, not changeable
InternalOrderQualificationSize = 32768
(4 bytes integer)
default: 262056
change: OFFLINE
The lower limit is 16384 The upper limit is 262056 (4 bytes integer)
default: 262056
change: OFFLINE
The lower and upper limits are:
8192 <= InterpreterWorkStackSize <= 262056
(4 bytes integer)
default: 0
change: OFFLINE
Maximum time in seconds an I/O pool worker is allowed to be idle before it is are released and the thread resources are returned to the operating system. The value 0 has the special meaning of INFINITE time. That means the I/O worker threads are never returned to the operating system, but kept in the pool. This idle timeout releases I/O worker threads only if the release does not shrink the I/O worker pool below MinIOPoolWorkers. If EnablePreAllocateIOWorker is set to YES, the timeout is always INFINITE. (4 bytes integer)
default: 1
change: RUNNING
Threshold for number of pending I/O requests accepted per I/O queue.
If the threshold is reached, next queue for the same priority is used.
In case all queues of requested priority are filled at least to the
threshold, the queue with lowest number of I/O requests in this and
lower priorities will be selected.
IOQueueFillingThreshold makes sense if any of IO_PRIO[012]_VOLUME_QUEUES
parameter is larger then 1.
(2 bytes integer)
default: depends on operating system or instance type
possible values: "DEFAULT" "LOCKING" "CAS1" "CAS2" (values depend on operating system)
change: OFFLINE
'DEFAULT': use default queue synchronization for current architecture
'LOCKING': use spinlock based queue
'CAS1' : use lock free queue based on single word compare and swap
'CAS2' : use lock free queue based on double word compare and swap
'CAS1' and 'CAS2' are not available on all platforms.
&endif
(char(8))
default: 0
change: OFFLINE
Specifies stack size for I/O worker thread in kilobytes. By default, platform-specific minimum stack size for I/O worker (currently 256KB on all platforms) will be used. In rare cases of stack overflow in I/O worker, a supporter may set this parameter to increase stack size as needed. Values below the platform-specific minimum stack size for I/O worker will be automatically increased to this minimum. (4 bytes integer)
default: 1
change: RUNNING
The minimal ratio between size of tables joined so far to the size of the next table to be joined which has to be exceeded to use hashing for this next table
default: "YES"
possible values: "YES" "NO"
change: RUNNING
KernelDumpBackup "NO" or "YES"
'YES' : Dump information will be written into the kernel dump file
'NO' : No dump information will be written.
The kernel dump file name can be set via KernelDumpFileName parameter.
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
KernelDumpCatalogCache "NO" or "YES"
'YES' : Dump information will be written into the kernel dump file
'NO' : No dump information will be written.
The kernel dump file name can be set via KernelDumpFileName parameter.
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
KernelDumpConfiguration "NO" or "YES"
'YES' : Dump information will be written into the kernel dump file
'NO' : No dump information will be written.
The kernel dump file name can be set via KernelDumpFileName parameter.
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
KernelDumpConverter "NO" or "YES"
'YES' : Dump information will be written into the kernel dump file
'NO' : No dump information will be written.
The kernel dump file name can be set via KernelDumpFileName parameter.
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
KernelDumpDataCacheControlBlock "NO" or "YES"
'YES' : Dump information will be written into the kernel dump file
'NO' : No dump information will be written.
The kernel dump file name can be set via KernelDumpFileName parameter.
(char(8))
default: "NO"
possible values: "YES" "NO"
change: RUNNING
KernelDumpDataCachePages "NO" or "YES"
'YES' : Dump information will be written into the kernel dump file
'NO' : No dump information will be written.
The kernel dump file name can be set via KernelDumpFileName parameter.
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
KernelDumpFileDirectory "NO" or "YES"
'YES' : Dump information will be written into the kernel dump file
'NO' : No dump information will be written.
The kernel dump file name can be set via KernelDumpFileName parameter.
(char(8))
default: "knldump"
change: OFFLINE
In the case of a database kernel crash or an emergency shutdown,
the kernel saves global data structures into the so-called dump file.
The dumped data structures can be changed via the following
parameters
KernelDumpConfiguration
KernelDumpConverter
KernelDumpDataCacheControlBlock
KernelDumpBackup
KernelDumpLocklist
KernelDumpRestartRecord
KernelDumpTransformation
KernelDumpGarbageCollector
KernelDumpFileDirectory
KernelDumpCatalogCache
KernelDumpLockManager
KernelDumpTransactionManager
KernelDumpIOManager
KernelDumpSavepointSync
KernelDumpPageLocks
KernelDumpDataCachePages
Be careful with your memory space! There must be sufficient
space for the dump file!
(char(256))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
KernelDumpGarbageCollector "NO" or "YES"
'YES' : Dump information will be written into the kernel dump file
'NO' : No dump information will be written.
The kernel dump file name can be set via KernelDumpFileName parameter.
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
KernelDumpIOManager "NO" or "YES"
'YES' : Dump information will be written into the kernel dump file
'NO' : No dump information will be written.
The kernel dump file name can be set via KernelDumpFileName parameter.
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
KernelDumpLocklist "NO" or "YES"
'YES' : Dump information will be written into the kernel dump file
'NO' : No dump information will be written.
The kernel dump file name can be set via KernelDumpFileName parameter.
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
KernelDumpLockManager "NO" or "YES"
'YES' : Dump information will be written into the kernel dump file
'NO' : No dump information will be written.
The kernel dump file name can be set via KernelDumpFileName parameter.
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
KernelDumpPageLocks "NO" or "YES"
'YES' : Dump information will be written into the kernel dump file
'NO' : No dump information will be written.
The kernel dump file name can be set via KernelDumpFileName parameter.
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
KernelDumpRestartRecord "NO" or "YES"
'YES' : Dump information will be written into the kernel dump file
'NO' : No dump information will be written.
The kernel dump file name can be set via KernelDumpFileName parameter.
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
KernelDumpSavepointSync "NO" or "YES"
'YES' : Dump information will be written into the kernel dump file
'NO' : No dump information will be written.
The kernel dump file name can be set via KernelDumpFileName parameter.
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
KernelDumpTransactionManager "NO" or "YES"
'YES' : Dump information will be written into the kernel dump file
'NO' : No dump information will be written.
The kernel dump file name can be set via KernelDumpFileName parameter.
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
KernelDumpTransformation "NO" or "YES"
'YES' : Dump information will be written into the kernel dump file
'NO' : No dump information will be written.
The kernel dump file name can be set via KernelDumpFileName parameter.
(char(8))
default: "knltrace"
change: OFFLINE
Trace entries will be written by the kernel to this file. The operator user must activate the trace facility using the DIAGNOSE VTRACE menu; otherwise no trace will be written. (char(40))
default: 5
change: RUNNING
Specifies the percentage the internal time values must differ before they are not treated as equal. (integer)
default: 10
change: RUNNING
Specifies the percentage of time the UKTs workload must differ before any task balancing is made. (integer)
default: 0
change: RUNNING
new in 7.9.09.01
If LockRescheduleInterval >= 10000:
The task reschedule triggered by a lock leave schedule request
will only be done if the runtime interval has expired.
The value is interpreted as task runtime interval in micro seconds.
If LockRescheduleInterval = -1:
Use the value of the parameter 'ScheduleInterval'.
If LockRescheduleInterval = 0:
The runtime interval check is disabled
default: depends on operating system or instance type
change: OFFLINE
The lower and upper limits are:
4 <= LogIOClusterSize <= 32
(2 bytes integer)
default: 100
change: OFFLINE
Defines the length of the log redo monitor list
default: depends on operating system or instance type
possible values: "YES" "NO"
change: OFFLINE
MapRunTimeMemoryToFile 'YES' or 'NO'
The runtime structures can be backed up automatically if memory mapped
files are used. This is very usefull for post mortem analysis after kernel
process died unexpected.
'YES': Use memory mapped file content as runtime memory
'NO' : Use heap memory as runtime memory
(char(8))
default: -1
change: RUNNING
This parameter is used to control the number of parallel and asynchronous processed read ahead (prefetch) requests produced by create index operations. This parameter will influence I/O behavior and main memory consumption. A huge number of requests may harm the I/O performance if the storage system is not efficient enough. A huge number of requests will also consume main memory. The effects can be monitored with the suitable system views. If MaxCreateIndexReadAheadRequests is zero the feature is disabled If MaxCreateIndexReadAheadRequests is -1, a value is chosen by the kernel The lower and upper limits are: -1 <= MaxCreateIndexReadAheadRequests <= 2147483647 (4 bytes integer)
default: 10
change: RUNNING
This parameter is used to control the number of parallel and asynchronous processed read ahead (prefetch) requests. Typically read ahead is used during range access and complete scan. This parameter will influence I/O behavior and main memory consumption. A huge number of requests may harm the i/o performance if the storage system is not efficient enough. A huge number of requests will also consume data cache memory. The effects can be monitored with the suitable system views. If MaxDataAreaReadAheadRequests is zero the feature is disabled The lower and upper limits are: 0 <= MaxDataAreaReadAheadRequests <= 2147483647 (4 bytes integer)
change: RUNNING
This parameter is used to control the number of parallel and
asynchronous processed write requests to the data area.
Typically write requests are generated in case of savepoints,
i.e. changed data pages and converter pages are written by the
savepoint coordinator task to the data area.
This parameter significantly influences the I/O behavior. A big
number of requests might harm the I/O performance if the
storage system is not able to manage a flood of I/O requests.
A small number of requests might subchallenge the storage layer
and savepoints take too long.
The effects can be monitored with the suitable system views.
The lower and upper limits are:
1 <= MaxDataAreaWriteRequests <= 256
(4 bytes integer)
default: 10
change: RUNNING
This parameter is used to control the number of parallel and asynchronous processed read ahead (prefetch) requests produced by drop operations. This parameter will influence I/O behavior and main memory consumption. A huge number of requests may harm the I/O performance if the storage system is not efficient enough. A huge number of requests will also consume main memory. The effects can be monitored with the suitable system views. If MaxDropDataReadAheadRequests is zero the feature is disabled The lower and upper limits are: 0 <= MaxDropDataReadAheadRequests <= 2147483647 (4 bytes integer)
default: 1
change: OFFLINE
new in 7.9.09.05
This parameter specifies the number of UKTs used to run floating service tasks.
1 <= MaxFloatingServiceTaskUKTs <= FloatingServiceTasks
default: 2
change: OFFLINE
new in 7.9.09.01
This parameter specifies the number of UKTs used to run garbage collector tasks.
The lower and upper limits are:
1 <= MaxGarbageCollectorTaskUKTs <= GarbageCollectors
default: 0
change: RUNNING
new in 7.9.09.02
This parameter defines the maximal number of parallel server tasks prefetching data for index scan accesses. This parameter will influence I/O behavior and main memory consumption. A huge number of requests may harm the I/O performance if the storage system is not efficient enough. A huge number of requests will also consume main memory cpu power. The effects can be monitored with the suitable system views. If MaxIndexKeyPrefetchRequests is zero the feature is disabled If MaxIndexKeyPrefetchRequests is -1, a value is chosen by the kernel The lower and upper limits are: -1 <= MaxIndexKeyPrefetchRequests <= 2147483647 (4 bytes integer)
default: 0
change: OFFLINE
Maximum number of IO worker threads assigned to the instance.
I/O subsystem tries to create additional I/O worker threads up to this
number. However, the number of I/O worker threads is increased only, if
another thread would increase parallelity of I/O execution by allowing
to work on I/O jobs on an addition volume queue in parallel.
The relation
MaxIOPoolWorkers >= MinIOPoolWorkers
is automatically enforced.
The value for MaxIOPoolWorkers is always kept identical with
MinIOPoolWorkers if EnablePreAllocateIOWorker is set to YES.
If EnablePreAllocateIOWorker is set to 'YES', the number of IO pool worker
only depends on setting of MinIOPoolWorkers.
If this parameter is set to zero, the maximum is computed as four times
number of data volumes plus number of log volumes plus one. If less than
two data volumes are configured, it is set to 10.
(4 bytes integer)
default: 0
change: OFFLINE
The parameter MaxLogQueues defines the number of log queues, which are allocated during startup of the database. Without restart this is the maximum number of log queues which can be used. If set to 0 the value of MaxCPUs is used. The lower and upper limits are: 0 <= MaxLogQueues <= MaxCPUs (2 bytes integer)
default: 0
change: OFFLINE
> 0 : The log writer waits for more log entries if the first log page
in the log queue is not full. The value is interpreted as maximum wait time in micro seconds.
default: 100
change: RUNNING
The maximum number of message per message list is limited by this parameter. The main cause of an error is still settable even if the message list length is limited. The second message in a message list indicates if message had to be ignored. A value of zero is handled as special value for unlimited message list length.
default: 0
change: RUNNING
Maximum number of entries in SYSMONITOR
default: 600
change: OFFLINE
Maximum number of seconds between two subsequent savepoints If the value of MaxSavepointTimeInterval is increased the number of savepoints within a unit of time and thus the system load decrease. Note: The time required for a restart after a system failure increases. Regardless of the above specified MaxSavepointTimeInterval a savepoint is written in the following cases: - COMMIT in a NOLOG session modifying data. - CREATE INDEX with COMMIT - The number of blocks released by a savepoint would be higher than the current number of free blocks on the data volumes - 2/3 of the log is filled The lower and upper limits are: 0 <= MaxSavepointTimeInterval <= 100000 (4 bytes integer)
default: 500
change: OFFLINE
Maximum of memory a server task can use as stack in KB.
The lower and upper limits are:
500 <= MaxServerTaskStackSize <= 4096
(2 bytes integer)
default: 1
change: OFFLINE
Specifies the maximum number of UKTs used to run server tasks.
The lower limits are:
1 <= MaxServerTaskUKTs <= MaxServerTasks
default: 500
change: OFFLINE
The list of special tasks are found in task cluster description.
Special tasks are all tasks that are not utility, user or server tasks.
The lower and upper limits are:
500 <= MaxSpecialTaskStackSize <= 4096
(2 bytes integer)
default: 1000
change: RUNNING
Number of hot loops for all spinlocks with default loop count. Spinlocks with own specific hot loop values are not influenced. This parameter is used only if more than one physical CPU is found. Hot loops make only sence on multiprocessor machines. After the given number of hot loops an unlimited number of yield loops are executed. A value of 1 turn off any hot loops
default: 50000
change: RUNNING
new in 7.9.09.06
SQL commands consist of syntax nodes like columnnames, expressions, modifiers etc. MaxSQLSyntaxTreeNodes specifies the number of SQL nodes of one SQL command. Nodes of views and function tables are included in this limitation since the nodes are combined with the SQL command before execution. Increasing the MaxSQLSyntaxTreeNodes enlarges the storage requirements per user task. The lower and upper limits are: 32767 <= MaxSQLSyntaxTreeNodes <= 1048576 (4 bytes integer)
default: depends on operating system or instance type
change: OFFLINE
Maximum of memory a task can use as stack in KB.
The lower and upper limits are:
1024 <= MaxTaskStackSize <= 4096
For liveCache-Databases, a minimum value of 1500 is enforced
(2 bytes integer)
change: RUNNING
This parameter influences the parallel create index. It defines the maximum number of temporary files used for the merge algorithm. A larger number of files decreases the number of merge steps, and thus increases performance. The best value is always calculated as long as the user did not set an individual value. The user is able to switch off the parallel create index durable by assign the MaxTempFilesPerIndexCreation to -1. If the user assigned MaxTempFilesPerIndexCreation to zero the best value will be computed implicitly depending on the value of CacheMemorySize. CacheMemorySize must be at least three times larger than MaxTempFilesPerIndexCreation Possible values are: {-1, 0, 128, 1024, 2048, 4096, 8192, 16384, 32768, 65536, 131072 } (4 bytes integer)
default: 3
change: OFFLINE
Maximum number of concurrent transactions
Use a prime number to optimize the work load.
IF TransactionLockManagementStripes = 1
THEN
EstimatedMaxTransactions
IF TransactionLockManagementStripes > 1
THEN
EstimatedMaxTransactions * TransactionLockManagementStripes DIV 2
IF TransactionLockManagementStripes * 10 > MaxTransactions
THEN
TransactionLockManagementStripes * 10
IF MaxTransactions > 32767
THEN
32767
(4 bytes integer)
default: 0
change: OFFLINE
Minimum number of IO worker threads assigned to the instance. The instance allocates at least MinIOPoolWorkers when starting. If MinIOPoolWorkers is set to less than number of priorities, then at least as many workers are started, as many priorities are defined (normally three priorities - low, medium and high). All I/O workers are shared among all database within an instance. If an I/O worker is released, the I/O worker thread is released to global I/O worker thread pool and will be reused later. (4 bytes integer)
default: 2147483647
change: RUNNING
Threshold defined for virtual reads 2147483647 : off other : number of virtual reads to be exceeded
default: 2147483647
change: RUNNING
Threshold defined for execution time 2147483647 : off other : number of milliseconds of execution time to be exceeded
default: 0
change: RUNNING
Threshold defined for defined for rate rows qualified/rows read 0 : off >0 : rate rows qual/rows read
default: 2
change: OFFLINE
Number of threads to process asynchronous network events. Network events occuring on communication sockets are processed asynchronously in worker threads. Each worker thread polls its share of socket descriptors, potentially using an optimized system call on given platform (see EnableOptimizedNetworkProcessing). Two worker threads should be normally sufficient even for big systems with hundreds of connections. A value of 0 means that asynchronous network processing is disabled. (4 bytes integer)
default: "YES"
possible values: "YES" "NO"
change: RUNNING
new in 7.9.09.01
'YES' : Try to cancel oldest OMS versions in case of 'OmsMaxHeapSize' reached situation. (default) 'NO' : Do not try to cancel OMS versions in case of 'OmsMaxHeapSize' reached situation.
default: 30
change: RUNNING
Restricts for all database sessions the waiting time for the answer of an OMS stream
request to the client. The time is specified in seconds.
If no answer is returned within the specified time, the database
session concerned receives an error.
The lower and upper limits are:
30 < OmsStreamTimeout <= 32400
OmsStreamTimeout = 0 : no timeout of session
(4 bytes integer)
default: 1000000
change: RUNNING
Minimal size of base table (measured in records) to take parallel join into account join
default: 0
change: RUNNING
The number of server tasks used for parallel join execution and parallel index reading.
ParallelJoinServerTasks = 0 disables parallel join execution and parallel index reading.
This number should not exceed the number of disks used for data volumes.
default: 64
change: RUNNING
The lower and upper limits are:
8 <= PartitionedHashJoinMaxPinPages <= 256
(4 bytes integer)
default: 2
change: OFFLINE
A pool of floating service tasks is used to serve event handler- and DBAnalyzer-requests. This parameter preserves some of these service tasks for service requests different from DBAnalyzer. This way, the available number of service tasks cannot be used up by a single service type. ( see also: FloatingServiceTasks and PreservedEventTasks ). (4 bytes integer)
default: 3
change: OFFLINE
A pool of floating service tasks is used to serve event handler- and DBAnalyzer-requests. This parameter preserves some of these service tasks for service requests different from event handling. This way, the available number of service tasks cannot be used up by a single service type. ( see also: FloatingServiceTasks and PreservedDBAnalyzerTasks). (4 bytes integer)
default: 25
change: RUNNING
This parameter is used to specify, if read operations of LOBs
should be optimized, i.e. if a LOB size is greater than the specified
value given in pages, a servertask will be used to read ahead pages
of this LOB.
The lower and upper limits are:
2 * CommandBufferSize (in pages) <= ReadAheadLobThreshold <= 262143
(4 bytes integer)
default: 100
change: RUNNING
This parameter is used to specify, if read operations of tables
should be optimized, i.e. if during a table access more than the
specified value in pages is affected, servertasks will be used to
read ahead pages of this table.
If threshold is zero the feature is disabled
The lower and upper limits are:
0 <= ReadAheadTableThreshold <= 2147483647
(4 bytes integer)
default: "YES"
possible values: "YES" "NO"
change: RUNNING
new in 7.9.09.05
ReCreateViewsInMigration 'YES' or 'NO'
'YES': Viewdefinitions will be recreated in catalogmigration
'NO' : Viewdefinitions will not be recreated in catalogmigration
default: 4096
change: OFFLINE
Memory size (in bytes) of the communication packet part reserved for the database kernel responses. ReservedCommandBufferReplySize should not be modified! The lower and upper limits are: 400 <= ReservedCommandBufferReplySize <= 4096 (4 bytes integer)
default: 0
change: OFFLINE
This value defines the amount of memory (in KB) used for grouping of used blocks by volume in the course of a system restart or a complete data backup. Using this kind of grouping may speed up the restart or backup in case of huge databases. The default value of 0 means that no grouping by volume takes place, a value greater 0 must be >= 1024. For databases with configured data area >= 4 TB the parameter is set to 512 MB implicitely.
default: "CACHEOPTIMIZEDTREE"
possible values: "TREE" "CACHEOPTIMIZEDTREE" "EXTERNALMERGESORT"
change: RUNNING
- TREE Utilizing traditional B*Tree handling up to release 7.8 - CACHEOPTIMIZEDTREE Cache optimized B*Tree handling as of release 7.9 - EXTERNALMERGESORT Implies CACHEOPTIMIZEDTREE and includes further optimization by utilizing External Merge Sort algorithm
default: 8
change: OFFLINE
Number of retired I/O job descriptions per context to keep for analysis purposes. After an I/O job is completed and waiting task notified, the I/O job description can be reused later by another I/O job. For analysis purposes, however, it makes sense to keep certain number of already-completed I/O jobs, so you can see what I/O jobs have been completed in the past time. The jobs are kept per context (task), so even if there is a task executing the jobs quickly, I/O jobs from other tasks will not be lost. (4 bytes integer)
default: "rtedump"
change: OFFLINE
In the case of a database kernel crash or an emergency shutdown, the kernel saves some global data structures into the so-called dump file. Be careful with your memory space! There must be sufficient space for the dump file! (char(256))
default: 1048576
change: OFFLINE
RunTimeMemoryMapFileSize
The whole memory area which is used by the internal runtime allocator is
partitioned in memory chunks. Those chunks have a file system
representation by using so-called memory mapped files.
The size of those files or memory chunks respectively is given by this
parameter.
On huge databases the number of memory mapped files may cause a performance
issue. Therefore raising the file size will reduce the number of those
files.
default: "DIAGNOSTICS"
possible values: "OFF" "DIAGNOSTICS" "ABORT"
change: RUNNING
SavepointDeadlockDetection 'OFF', 'DIAGNOSTICS' or 'ABORT'
'OFF': Detection of savepoint deadlocks is not attempted.
'DIAGNOSTICS': Diagnostic information is written in case a savepoint deadlock is assumed
'ABORT': The database is stopped in case a savepoint deadlock is assumed
default: depends on operating system or instance type
change: OFFLINE
Priority level of the schedule-no-age-policy. This database parameter has no
effect if the parameter EnableSchedNoAgePolicy was set to 'NO'.
The lower and upper limits are:
178 <= SchedNoAgePriority <= 255
Default is 178
( see also: HP-UX, SCHED_NOAGE, SCHED_TIMESHARE).
default: 10000
change: RUNNING
The task reschedule triggered by a speculative schedule request
will only be done if the runtime interval has expired.
The value is interpreted as task runtime interval in micro seconds.
default: 1
change: OFFLINE
Task-specific allocator deallocates a memory block only when the number of allocated memory blocks is larger than the given value.
default: 131072
change: OFFLINE
The default block size of task-specific allocator. Only the first block size is decided by InitialAllocatorSize.
default: "NO"
possible values: "YES" "NO"
change: RUNNING
ShowDataAccessMaxStackUsage = 'YES' or 'NO'
This is a diagnostic feature.
The maximum KB stack consumption of each task can be
calculated using a stack pattern check. For this
the stack is initialized with a pattern. The last
modification of the pattern then indicates the
maximum stack usage.
Since the search is very time consuming this feature
normally should be turned off.
The calculation is done for each KB call.
The result is written in KnlMsg only.
Possible values are:
YES - Show maximum stack usage
NO - (Default) Do not show maximum stack usage
(8 byte character)
default: "NO"
possible values: "YES" "NO"
change: OFFLINE
ShowMaxStackUsage = 'YES' or 'NO'
This is a diagnostic feature.
The maximum stack consumption of each task can be
calculated using a stack pattern check. For this
the stack is initialized with a pattern. The last
modification of the pattern then indicates the
maximum stack usage.
Since the search is time consuming this feature is
normally turned off.
The calculation is done after a task finished or was
finished due to a shutdown request.
The result is written in KnlMsg only.
Possible values are:
YES - Show maximum stack usage for each task
NO - (Default) Do not show maximum stack usage
(8 byte character)
default: 1
change: RUNNING
Base value for exponential backoff loops. In each iteration of the
spinlock lock hot loop a backoff delay loop is executed. The backoff
delay is increased with every iteration by the formula
firstDelay = SpinlockBackoffBase
nextDelay = min( lastDelay * SpinlockBackoffFactor ,
SpinlockBackoffMaximum )
A value of 0 turns off any backoff delay loop.
default: 2
change: RUNNING
Base value for backoff loops. In each iteration of the spinlock lock
hot loop a backoff delay loop is executed. The backoff delay is
increased with every iteration by the formula
firstDelay = SpinlockBackoffBase
nextDelay = min( lastDelay * SpinlockBackoffFactor ,
SpinlockBackoffMaximum )
Minimum factor value is 2.
default: 64
change: RUNNING
Base value for backoff loops. In each iteration of the spinlock lock
hot loop a backoff delay loop is executed. The backoff delay is
increased with every iteration by the formula
firstDelay = SpinlockBackoffBase
nextDelay = min( lastDelay * SpinlockBackoffFactor ,
SpinlockBackoffMaximum )
A value of 0 truns off any backoff delay.
default: "Low"
possible values: "Low" "AboveLow" "BelowNormal" "Normal" "AboveNormal" "BelowHigh" "High" "AboveHigh"
change: RUNNING
This parameter specifies the task priority for communication packet pending requests.
default: "COROUTINES"
possible values: "COROUTINES" "THREADS" "MIXED"
change: OFFLINE
TaskingMode = 'COROUTINES', 'THREADS' or 'MIXED'
COROUTINES : Use coroutines to perform task switching for both
server and user tasks.
THREADS : Use threads to perform task switching for both
server and user tasks.
MIXED : Use coroutines to perform task switching for server
tasks and threads to perform task switching for user
tasks.
Tasks in UKTs are scheduled cooperatively. When one task has to wait
for something (or voluntarily gives up CPU), another runnable task
in the UKT is activated. There are two possibilities to switch to
another task. In thread mode, each task is represented by own thread
in operating system and task switching means we need to switch to
another context on operating system level. This is usually a fairly
costly operation. In coroutine mode, each task only has its own stack.
Switching means only updating a few registers to point to the new
stack, but operating system context is unchanged. This switching mode
is order of magnitude faster than thread switching, but has some
other disadvantages (e.g., you don't see each task as a thread in
operating system).
default: "AboveHigh"
possible values: "Low" "AboveLow" "BelowNormal" "Normal" "AboveNormal" "BelowHigh" "High" "AboveHigh"
change: RUNNING
new in 7.9.09.06
This parameter specifies the task priority for the task wakeup request when IO has finished.
default: "AboveHigh"
possible values: "Low" "AboveLow" "BelowNormal" "Normal" "AboveNormal" "BelowHigh" "High" "AboveHigh"
change: RUNNING
This parameter specifies the task priority for the task wakeup request when lock owner is granting the ownership to another task.
default: "AboveLow"
possible values: "Low" "AboveLow" "BelowNormal" "Normal" "AboveNormal" "BelowHigh" "High" "AboveHigh"
change: RUNNING
new in 7.9.09.01
This parameter specifies the task priority for the task yield request when lock could not be acquired before entering the wait queue.
default: 80
change: OFFLINE
The parameter TaskNiceElevationValue defines the amount of priority elevation a
niced (prioritized) task gets.
(See: TaskRequestPriorityLow ... TaskRequestPriorityAboveHigh)
default: 400
change: OFFLINE
This parameter specifies the priority value of the highest prioritized requests (level 8 priority of a nice group). ( see also: TaskNiceElevationValue )
default: 30
change: OFFLINE
This parameter specifies the priority value of the above-low prioritized requests (level 2 priority of a nice group). ( see also: TaskNiceElevationValue )
default: 90
change: OFFLINE
This parameter specifies the priority value of the above-normal prioritized requests (level 5 priority of a nice group). ( see also: TaskNiceElevationValue )
default: 100
change: OFFLINE
This parameter specifies the priority value of the below-high prioritized requests (level 6 priority of a nice group). ( see also: TaskNiceElevationValue )
default: 50
change: OFFLINE
This parameter specifies the priority value of the below-normal prioritized requests (level 3 priority of a nice group). ( see also: TaskNiceElevationValue )
default: 240
change: OFFLINE
This parameter specifies the priority value of the high prioritized requests (level 7 priority of a nice group). ( see also: TaskNiceElevationValue )
default: 10
change: OFFLINE
This parameter specifies the priority value of the low prioritized requests (level 1 priority of a nice group). ( see also: TaskNiceElevationValue )
default: 80
change: OFFLINE
This parameter specifies the priority value of the normal prioritized requests (level 4 priority of a nice group). ( see also: TaskNiceElevationValue )
default: "BelowHigh"
possible values: "Low" "AboveLow" "BelowNormal" "Normal" "AboveNormal" "BelowHigh" "High" "AboveHigh"
change: RUNNING
This parameter specifies the task priority for the task resume request.
default: 1000
change: RUNNING
new in 7.9.09.01
A task runtime without scheduling that exceeds this threshold will be counted and can be shown via database console and system views.
The threshold is interpreted as time value in milliseconds and must be greater than 50.
-1: means threshold disabled
default: depends on operating system or instance type
change: RUNNING
Maximum number of dispatcher loops for finding a new task in its queues. When the specified value is reached, this UKT interrupts itself using the semop systemcall. (4 bytes integer)
default: depends on operating system or instance type
change: OFFLINE
Minimum size (in bytes) of the catalog cache allocated to task-specific parse and catalog information. Default calculation, not changeable IF (CommandBufferSize <= 32768) AND (131072 > TaskSpecificCatalogCacheMinSize) THEN TaskSpecificCatalogCacheMinSize := 131072 ELSIF (CommandBufferSize > 32768 ) AND (262144 > TaskSpecificCatalogCacheMinSize) TaskSpecificCatalogCacheMinSize := 262144 ELSE TaskSpecificCatalogCacheMinSize := ((TaskSpecificCatalogCacheMinSize -1) / 8192 + 1) * 8192 (4 bytes integer)
default: "AboveLow"
possible values: "Low" "AboveLow" "BelowNormal" "Normal" "AboveNormal" "BelowHigh" "High" "AboveHigh"
change: RUNNING
This parameter specifies the task priority for yield requests.
default: 10
change: RUNNING
Maximum number of pinned pages (% of CacheMemorySize) used for temporary resultsets.
The lower and upper limits are:
0% <= TempResultsetPinPagesThreshold <= 50% of the DataCache
default: "NONE"
possible values: "NONE" "AUTO" "IDEAL_PROCESSOR" "USER_DEFINED" (values depend on operating system)
change: OFFLINE
In order to speed up the kernel on multiprocessor or hyperthreading systems,
it might be useful to activate binding of UKTs to specific CPUs. This
prevents UKTs from floating between CPUs, which may in the end bring better
performance (e.g., due to better L2-cache hitrate). Following options are
possible:
NONE:
No CPU binding will be done.
AUTO:
Each UKT will be bound to one processor. In case of hyperthreading,
the UKT will be bound to both logical cores on single processor. If
MaxCPUs specifies more than available processors in the system, they
will be used round-robin (e.g., more UKTs will be bound to one CPU).
The UKT will be only allowed to run on bound processor(s).
IDEAL_PROCESSOR (Windows only):
Ideal processor settings sets a preferred processor for each UKT. If
MaxCPUs specifies more than available processors in the system, they
will be used round-robin (e.g., more UKTs will be bound to one CPU).
The system schedules the UKTs on their preferred processors whenever
possible, but the thread may still run on another processor.
USER_DEFINED:
The binding of UKTs to CPUs is defined manually via parameter
UKTCPUBindingList.
Note: Hyperthreading is an advanced feature of high-end versions of the Intel
Pentium 4 and later. A hyperthreaded processor acts like multiple processors
embedded on the same microchip. Some of the resources on the chip are duplicated
(such as the register set), but other resources are shared (such as execution units
and the cache). Some resources (such as the buffers that store micro operations)
are partitioned, with each logical processor receiving a portion.
Since some resources are shared, there may be collisions on them and thus it is
sometimes more appropriate not to run two UKTs on a single processor. On the other
hand, one UKT can be scheduled on any logical processor without penalty, since
they share the cache. Therefore, in AUTO mode, we schedule single UKT on all
logical cores on single processor.
change: OFFLINE
This parameter specifies user-defined CPU binding for UKTs. It is only
relevant, if UKTCPUBinding is set to USER_DEFINED.
The parameter should contain list of physical processor IDs for each UKT.
Each list is separated by a semicolon, processors for each UKT are separated
by comma. You can also use ranges, like -2, 3-5 or 7-, where open ends are
CPU 0 or n-1, respectively, n being the highest ID of a physical processor
in the system. See the list of detected processor IDs in startup messages
of the kernel.
Alternatively, you can list also logical processor IDs, by prefixing each
processor number or processor range by a star ('*'). Please note that
assignment of logical processor IDs may change over time and restarting
the database may bind the UKTs to different processors.
Specifying several processors for one UKT is supported only on Linux and
Windows. For other operating systems, only the first one will be taken.
If there are two or more logical processors in one physical processor,
either all of them will be associated or just one of them. All processors
will be associated on Linux and Windows, otherwise just one processor.
In latter case, the processor with the least bound threads will be chosen.
Example 1:
The operating system uses 8 processors with processor IDs from 0 to 7.
You want to use 8 processors for UKTs, every UKT should use a separate
processor:
Set MaxCPUs to 8
Set UKTCPUBindingList to 0;1;2;3;4;5;6;7
Example 2:
The operating system uses 8 processors with processor IDs from 0 to 7.
You want to use 8 processors for UKTs, every UKT is allowed to run on
two CPUs (NOTE: currently possible only on Windows and Linux):
Set MaxCPUs to 8
Set UKTCPUBindingList to 0,1;0,1;2,3;2,3;4,5;4,5;6,7;6,7
Example 3:
The operating system uses 4 physical processors with processor IDs
from 0 to 3, which contain each 2 logical processors, with IDs from
0 to 7. It is a hyperthreading system. You want to experimentally
use 8 UKTs, every UKT should run on a separate logical processor,
every two UKTs should share one physical processor (NOTE: this
configuration is NOT RECOMMENDED):
Set MaxCPUs to 8
Set UKTCPUBindingList to *0;*1;*2;*3;*4;*5;*6;*7
Example 4:
The operating system uses 4 physical processors with processor IDs
from 0 to 3, which contain each 2 logical processors, with IDs from
0 to 7. It is a hyperthreading system. You want to use 4 UKTs,
every UKT should run on a separate physical processor, but only
on one logical processor:
Set MaxCPUs to 4
Set UKTCPUBindingList to *0;*2;*4;*6
Example 4:
The operating system uses 4 physical processors with processor IDs
from 0 to 3, which contain each 2 logical processors, with IDs from
0 to 7. It is NOT a hyperthreading system, but each two logical
cores share L2-cache. You want to use 8 UKTs, every 2 UKTs can run
on either logical processor:
Set MaxCPUs to 8
Set UKTCPUBindingList to *0-1;*0-1;*2-3;*2-3;*4-5;*4-5;*6-7;*6-7
default: depends on operating system or instance type
possible values: "Hash" "RoundRobin" "Equally"
change: RUNNING
new in 7.9.10.00
UndoHistoryDistribution 'Hash' 'RoundRobin' 'Equally'
Defines how UNDO files are distributed to history files
'Hash' : an UNDO file is assigned to a histroy file using a hash function based on the taskid
'RoundRobin' : an UNDO file is assigned to a history file in a round robin manner
'Equally' : an UNDO file is assigend to the smallest history file
default: "YES"
possible values: "YES" "NO"
change: RUNNING
UnknownSessionContextYieldsNull 'YES' or 'NO'
'YES': Call of SESSION_CONTEXT function with unknown variable yields NULL
'NO' : Call of SESSION_CONTEXT function with unknown variable yields error
default: 0
change: RUNNING
The maximum number of server tasks used for parallel execution of update statistics commands. The default value of 0 will automatically use the number of attached data volumes. Any value n > 0 will use a maximum of n server tasks at a time regardless of the number of data volumes. There is no guarantee that as many server tasks as given will actually be used as there may be other database jobs competing for the server tasks available. Typically the number should not exceed the number of disks used for data volumes.
default: 1
change: RUNNING
new in 7.9.09.01
This parameter specifies the number of UKTs used to run garbage collector tasks. The MaxGarbageCollectorTaskUKTs parameter defines the maximum of UKTs used to run garbage collector tasks. UseableGarbageCollectorTaskUKTs allows online modifications and can be used to narrow down or raise the currently used UKTs during runtime. 1 <= UseableGarbageCollectorTaskUKTs <= MaxGarbageCollectorTaskUKTs The parameter LoadBalancingCheckInterval must be greater 0 to set a value that differs to MaxGarbageCollectorTaskUKTs.
default: 1
change: RUNNING
new in 7.9.09.01
Specifies the number of UKTs used to run server tasks when the database is in ONLINE mode. The MaxServerTaskUKTs parameter defines the maximum of UKTs used to run server tasks. UseableServerTaskUKTs allows online modifications and can be used to narrow down or raise the currently used UKTs during runtime. 1 <= UseableServerTaskUKTs <= MaxServerTaskUKTs The parameter EnableServerTaskBalancing must be set to 'YES' and the parameter LoadBalancingCheckInterval must be greater 0 to set a value that differs to MaxServerTaskUKTs.
default: 1
change: OFFLINE
new in 7.9.09.06
Specifies the number of UKTs used to run server tasks when the database is in ADMIN mode. The MaxServerTaskUKTs parameter defines the maximum of UKTs used to run server tasks. UseableServerTaskUKTsInAdminMode defines the number of server tasks used when the database is in state ADMIN. It affects operations like restoring a backup and the database restart phase. 1 <= UseableServerTaskUKTsInAdminMode <= MaxServerTaskUKTs The parameter EnableServerTaskBalancing must be set to 'YES' and the parameter LoadBalancingCheckInterval must be greater 0 to set a value that differs to MaxServerTaskUKTs.
default: "YES"
possible values: "YES" "NO"
change: OFFLINE
UseAlternateAllocatorForServer = YES choses a different implemenation to allocate
memory from the operating system.
default: depends on operating system or instance type
change: OFFLINE
Specifies whether operating system functionality is used for asynchronous I/O.
UseAsynchronousIO = 'YES' or 'NO'
'YES': Asynchronous I/O is supported by the operating system
'NO' : Asynchronous I/O uses volumes processes
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
UseAsynchronousLogTransport 'YES' or 'NO'
'YES': Log is transported asynchronously from master to standby
(remote request, local io, remote receive)
'NO': Log is transported synchronously from master to standby
(remote request, remote receive, local io)
default: "YES"
possible values: "YES" "NO"
change: OFFLINE
UseBackupCheck 'YES' or 'NO'
'YES': check if recovered backup files are complete and do not contain any pages more than once
'NO' : do not check recovered backup files
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
'YES': Consistency checks on indexes can be suspended to allow changes to the index 'NO' : Changes to the index will be executed only after a consistency check has finished
default: "YES"
possible values: "YES" "NO"
change: RUNNING
UseColumnCompression 'YES' or 'NO'
'YES': all non-primary-key columns are of variable length
'NO' : numeric columns and char-columns with length less than 31 bytes are of fixed length
default: "YES"
possible values: "YES" "NO"
change: RUNNING
Defines whether converter stripes locks will be periodically yielded shortly
during data backup start period to allow other tasks accessing the converter.
Possible values are:
'YES' : Converter stripes locks will be yielded during data backup start period
'NO' : Converter stripes locks will not be yielded at all during data backup
start period and converter stays locked during this period
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
UseDDLTrigger 'YES' or 'NO'
'YES': DDL system triggers are switched on
'NO' : DDL system triggers are switched off
default: "YES"
possible values: "YES" "NO"
change: RUNNING
new in 7.9.09.01
UseDMLLocksForSelectForUpdate 'YES' or 'NO'
'YES': SELECT statements with FOR UPDATE clause generate SQL locks identical to DML statement
'NO' : SELECT statements with FOR UPDATE clause generate SQL locks which could be removed by UNLOCK statement
default: depends on operating system or instance type
possible values: "YES" "NO"
change: OFFLINE
For local client kernel communication shared memory segments are used
for communication. Those segments are created always by the kernel.
This can be done dynamically while a connection is established or the
kernel can create an adequate amount of segments at database start to
fulfill all future connects.
It is recommended to use the default which is the dynamic variant because the
communication is more secure and faster this way. And it saves of course
resources by creating a shared memory segment only when it is needed.
In case of problems the legacy method of using static (big) segments can
be used.
'YES': Using dynamic communication segments (default)
'NO' : Using static (big) communication segments
default: "YES"
possible values: "YES" "NO"
change: RUNNING
UseExtendedOracleSQLMode 'YES' or 'NO'
'YES': database is used as SAP liveCache or by SAP system
'NO' : database is neither used as SAP liveCache nor by SAP system
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
This parameter allows to enforce extended time measurement with database start. The default value for this database parameter is YES (enable time measurement). The reasons for this are that time measurement: - Produces negligible overhead - Is necessary to provide useful statistics regarding command monitoring - Allows the Database Analyzer to collect more detailed statistics Time measurement can be switched off with the console command TIME DISABLE or by setting this database parameter to NO, which you can do in ONLINE mode. Note that command monitoring is not possible when time measurement is switched off. Valid types are: 'YES': extended time measurement used 'NO' : extended time measurement not used
default: depends on operating system or instance type
possible values: "YES" "NO"
change: OFFLINE
UseFilesystemCacheForBackup 'YES' or 'NO'
&if $OSSPEC in [ WIN32 ]
When file system caching is disabled ('NO'), all backup read and write operations
directly access the physical disk. However, the file metadata may still be cached.
If 'YES' the database kernel enables full-file-system-caching for backup
I/O operation. With full caching enabled, data and metadata is written and read
into the OS system cache.
&else
When file system caching is disabled ('NO'), all read and write operations
directly access the physical disk ( O_DIRECT flag will be used for volume open ).
However, the file metadata may still be cached.
O_DIRECT is ignored for Linux kernel < 2.4.18. Newer Linux kernel
use this to bypass the file system cache completely.
&endif
(char(8))
default: "YES"
possible values: "YES" "NO"
change: OFFLINE
UseFineGranularSynchronization 'YES' or 'NO'
'YES': synchronize data cache access in hash-head-list level
'NO' : synchronize data cache access in stripe level
default: depends on operating system or instance type
possible values: "YES" "NO"
change: OFFLINE
Specifies if I/O via windows I/O completion port is used instead of
using I/O worker of own I/O worker pool.
UseIOCompletionPort = 'YES' or 'NO'
'YES': I/O via windows I/O completion port is used
'NO' : Only I/O via I/O worker pool is used
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
new in 7.9.10.00
UseMultiPhaseDropTable 'YES' or 'NO'
'YES': Dropping a table via a garbage collector runs in 2 phases. First phase drops LOBs, second phase drops the table tree
'NO' : Dropping a table via a garbage collector runs in 1 phase
default: "NO"
possible values: "YES" "NO"
change: OFFLINE
UseMultiVersionReadSupport 'YES' or 'NO'
'YES': the database is able to support multi version read
'NO' : the database is not able to support multi version read
default: "YES"
possible values: "NO" "YES"
change: RUNNING
new in 7.9.09.10
This parameter defines whether read operations of scan operations in the course of a join execution are accelerated by reading pages in advance asynchronously. 'NO' : read ahead in the course of a join never takes place 'YES': the system decides when to use read ahead
default: "YES"
possible values: "NO" "YES"
change: RUNNING
This parameter defines whether read operations of LOBs are accelerated by reading them in advance asynchronously. 'NO' : read ahead of LOBs never takes place 'YES': the system decides when to use read ahead for LOBs
default: "YES"
possible values: "NO" "YES"
change: RUNNING
This parameter defines whether read operations in the course of UNDO/REDO operations are accelerated by reading data in advance asynchronously. 'NO' : read ahead in the course of UNDO/REDO operations never takes place 'YES': the system decides when to use read ahead in the course of UNDO/REDO operations
default: "NO"
possible values: "YES" "NO"
change: RUNNING
UseRestrictedPredicatePushDown 'YES' or 'NO'
'YES': special algorithm for predicate push down is used for outer joins
'NO' : inner and outer joins uses the same algorithm for local predicate push down
default: "YES"
possible values: "YES" "NO"
change: RUNNING
UseSelectFetchOptimization 'YES' or 'NO'
'YES': select-fetch-optimization is switched on
'NO' : select-fetch-optimization is switched off
(char(8))
default: "YES"
possible values: "YES" "NO"
change: RUNNING
new in 7.9.10.00
UseSevereCatalogLocking 'YES' or 'NO'
'YES': reduces the probability of deadlocks caused by parallel DDL operations
'NO' : requires fewer locks which allows more concurrred DDL operations but increases the probability of deadlocks
default: "NO"
possible values: "YES" "NO"
change: RUNNING
UseShareLockForForeignKey 'YES' or 'NO'
'YES': use share lock to lock row in foreign key table
'NO' : use exclusive lock to lock row in foreign key table
default: "NO"
possible values: "YES" "NO"
change: RUNNING
UseStrategyCache 'YES' or 'NO'
'YES': strategy is only detected once for a parsed statement
'NO' : strategy is detected at every execution of a parsed statement
(char(8))
default: "YES"
possible values: "YES" "NO"
change: OFFLINE
This parameter controls whether system triggers are called in the restart phase Valid values are: 'YES': all system triggers will be called 'NO' : no system trigger will be called
default: "NO"
possible values: "YES" "NO"
change: RUNNING
UseTableWidthCheckDuringDDL 'YES' or 'NO'
'YES': table definitions which exceeds internal record length are rejected
'NO' : table definition could exceed internal record length,
record length is only checked at insert time
default: "YES"
possible values: "YES" "NO"
change: RUNNING
UseTenantBackupRegion 'YES' or 'NO'
'YES': Use region "TenantBackup" to prevent deadlocks between backup and tenant import
'NO' : Use old behaviour in case of problems
default: depends on operating system or instance type
possible values: "NEVER" "IF_OPEN_DIRECT" "IF_RAW_DEVICE" "IF_OPEN_DIRECT_OR_RAW_DEVICE" "ALWAYS"
change: OFFLINE
This parameter controls whether system calls for scatter/gather transfer by readv()/writev() have to be simulated. Simulation means, that individual read/write calls for I/O are used. Valid values are: "NEVER" never simulate "IF_OPEN_DIRECT" simulate for OPEN_DIRECT mode only "IF_RAW_DEVICE" simulate for raw device access only "IF_OPEN_DIRECT_OR_RAW_DEVICE" simulate for both "ALWAYS" always simulate (char(32))
default: "YES"
possible values: "YES" "NO"
change: OFFLINE
UseVolumeLock 'YES' or 'NO'
'YES': While volumes are attached a lock is set to prevent a second attach of volume
'NO' : Volume is just opened during attach, but no locking takes place
The enforced locking is a security feature, that i.e. protects the administrator from using the same volume
twice in a same database. It is therefore discouraged to modify the default. But in case of NFS mounted
volumes, it can be helpful and if the volumes have to be copied while the database has attached them.
If the parameter HotStandbyStorageDLLPath is set to 'libhsscopy', such a copy of volumes takes place. In that case
this parameter must be set to 'NO'.
(char(8))
default: 1
change: OFFLINE
Number of I/O queues for priority 2 (high) jobs per volume. High priority
jobs may use all queues (i.e., high, medium and low prio queues).
The lower and upper limits are:
0 <= VolumeIOQueuesForHighPriority <= 10
(2 bytes integer)
default: 5
change: OFFLINE
Number of I/O queues for priority 0 (low) jobs per volume. Low priority
jobs may only use these queues.
The lower and upper limits are:
1 <= VolumeIOQueuesForLowPriority <= 100
(2 bytes integer)
default: 4
change: OFFLINE
Number of I/O queues for priority 1 (medium) jobs per volume. Medium priority
jobs may use these queues as well as low priority queues.
The lower and upper limits are:
1 <= VolumeIOQueuesForMediumPriority <= 100
(2 bytes integer)
default: "YES"
possible values: "YES" "NO"
change: RUNNING
WriteRTEDumpDuringDBOffline "NO" or "YES"
'YES' : A RTEDump will be written during normal database offline request
'NO' : No RTEDump will be written.
(char(8))