General Extended Security Support By Name By Class History

SAP MaxDB Database Parameters (7.9.10.02, Support)


AbortHandlingMode

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


AdditionalLogQueueIOLimitation

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.

AllocatorRegistryCheckLevel

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))

CallStackLevel

default: 0

change: RUNNING

 Trace of owners of memory chunks

  0 : off
 >0 : number of routines traced in calling sequence when allocating memory chunks


CheckDataParallelServerTasks

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.
 

CheckLivecacheVersionSupport

default: "NO"

possible values: "YES" "NO"

change: RUNNING

 Enables checks for usage of 'versionsupport' container property

CommandBufferSize

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)

CompactMultiphaseOutputColumns

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


CompressionLevel

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)

DataCacheIOAreaFlushThreshold

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)

DataCacheIOAreaSize

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)

DataCacheLRUAreaFlushThreshold

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)

DataCachePinAreaThreshold

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)

DataCacheSyncGranularity

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)

DeadlockDumpFilename

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.

DedicatedServerTaskUKTs

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

DeferStackAllocation

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))

DeleteLeafsWithoutRead

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.

EarlyGarbageCollectionContainer

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 )
 

EarlyGarbageCollectionInterval

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.

EarlyGarbageCollectionThreshold

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)

EnableAKDump

default: "YES"

possible values: "YES" "NO"

change: OFFLINE

  'YES': in case of a crash, the AK cache will be dumped

EnableDataIOCluster

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


EnableDataVolumeBalancing

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

EnableDBSCommandStatistic

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.


EnableDeadlockLogging

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


EnableDelayedRootPageCreation

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


EnableExtendedShareLockStatistic

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.


EnableFaultTolerantCreateFunc

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


EnableFetchReverseOptimization

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

EnableFileCounterInitialization

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.

EnableFirstRowAccessOptimization

default: "YES"

possible values: "YES" "NO"

change: RUNNING

 If a  is 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 


EnableGarbageCollTaskBalancing

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.

EnableIncompleteRecovery

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..


EnableIOTimeStatistic

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))

EnableJoinHashTableOptimization

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

EnableJoinIntermediateSort

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


EnableLiveCachePinArea

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

EnableLockOverflowDump

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)

EnableLogRedoMonitor

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.

EnableLogRestoreCompleteIndex

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.


EnableMinMaxAggregationOptimizer

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

EnableOnePhaseJoin

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

EnableOptimizedNetworkProcessing

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))

EnableOuterJoinOptimization

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

EnableParallelFBMConstruction

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))

EnablePartitionedHashJoin

default: "NO"

possible values: "YES" "NO"

change: RUNNING

 Enables the use of partitioned hash join ('YES' or 'NO')

 'YES': Partitioned hash join can be used
 'NO' : Partitioned hash join cannot be used

EnablePreAllocateIOWorker

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.


EnableQualificationBypass

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


EnableQualificationOnIndex

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 

EnableRemoveUndoOnTransactionEnd

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

EnableSchedNoAgePolicy

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).
 

EnableServerTaskBalancing

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.

EnableSharedSQLForInternalSQL

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

EnableStarJoinOptimization

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 

EnableSubTreeLock

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

EnableSymbolDemangling

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))

EnableSymbolResolution

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.


EnableSynchronousTaskIO

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))

EnableVariableInput

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))

EnableVariableOutput

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))

EventFileName

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))

EventFileSize

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)

FloatingServiceTasks

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)

ForceSchedulePrioritizedTask

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))

ForceSchemaSpecification

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.


GarbageCollectors

change: OFFLINE

 Describes the number of garbage collector tasks
 The lower and upper limits are:
     1 <= GarbageCollectors <= MaxCPUs 
 (4 bytes integer)

IndexLeafCachingLevel

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.


InitialAllocatorSize

default: 0

change: OFFLINE

Initial size of the task-specific allocator (bytes). Minimum is 1 MB

InternalLockStructureEntries

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)

InternalNumberRepresentation

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 
        

InternalOrderQualificationSize

default: 32768

change: OFFLINE

 Default calculation, not changeable
 InternalOrderQualificationSize = 32768
 (4 bytes integer)

InternalOrderStackSize

default: 262056

change: OFFLINE

 Space (in bytes) provided by the system for stack code in the message block
 The lower limit is 16384

 The upper limit is 262056

 (4 bytes integer)

InterpreterWorkStackSize

default: 262056

change: OFFLINE

 Size (in bytes) of the work area for stack code processing
 The lower and upper limits are:
     8192 <= InterpreterWorkStackSize <= 262056

 (4 bytes integer)

IOPoolIdleTimeout

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)

IOQueueFillingThreshold

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)

IOTicketQueueSynchronizationMode

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))



IOWorkerStackSize

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)

JoinHashMinimalRatio

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


KernelDumpBackup

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))

KernelDumpCatalogCache

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))

KernelDumpConfiguration

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))

KernelDumpConverter

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))

KernelDumpDataCacheControlBlock

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))

KernelDumpDataCachePages

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))

KernelDumpFileDirectory

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))

KernelDumpFileName

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))

KernelDumpGarbageCollector

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))

KernelDumpIOManager

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))

KernelDumpLocklist

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))

KernelDumpLockManager

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))

KernelDumpPageLocks

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))

KernelDumpRestartRecord

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))

KernelDumpSavepointSync

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))

KernelDumpTransactionManager

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))

KernelDumpTransformation

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))

KernelTraceFile

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))

LoadBalancingWorkloadDeviation

default: 5

change: RUNNING

Specifies the percentage the internal time values must differ
before they are not treated as equal.

(integer)

LoadBalancingWorkloadThreshold

default: 10

change: RUNNING

Specifies the percentage of time the UKTs workload
must differ before any task balancing is made.

(integer)

LockRescheduleInterval

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      
       

LogIOClusterSize

default: depends on operating system or instance type

change: OFFLINE

 Size for LOG I/O writes in pages/blocks
 The lower and upper limits are:
     4 <= LogIOClusterSize <= 32

(2 bytes integer)

LogRedoMonitorListLen

default: 100

change: OFFLINE

 Defines the length of the log redo monitor list 

MapRunTimeMemoryToFile

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))

MaxCreateIndexReadAheadRequests

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)

MaxDataAreaReadAheadRequests

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)

MaxDataAreaWriteRequests

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)
 

MaxDropDataReadAheadRequests

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)

MaxFloatingServiceTaskUKTs

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
     
  

MaxGarbageCollectorTaskUKTs

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
     

MaxIndexKeyPrefetchRequests

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)

MaxIOPoolWorkers

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)

MaxLogQueues

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)

MaxLogwriterDelay

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.

MaxMessageListEntries

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.

MaxMonitorEntries

default: 0

change: RUNNING

 Maximum number of entries in SYSMONITOR


MaxSavepointTimeInterval

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)

MaxServerTaskStackSize

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)

MaxServerTaskUKTs

default: 1

change: OFFLINE

 Specifies the maximum number of UKTs used to run server tasks.  
  
 The lower limits are:
 
     1 <= MaxServerTaskUKTs  <= MaxServerTasks
  

MaxSpecialTaskStackSize

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)

MaxSpinlockHotLoops

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


MaxSQLSyntaxTreeNodes

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)

MaxTaskStackSize

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)

MaxTempFilesPerIndexCreation

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)

MaxTransactions

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)

MinIOPoolWorkers

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)

MonitorDataPageReadThreshold

default: 2147483647

change: RUNNING

 Threshold defined for virtual reads

 2147483647 : off
 other      : number of virtual reads to be exceeded


MonitorRunTimeThreshold

default: 2147483647

change: RUNNING

 Threshold defined for execution time

 2147483647 : off
 other      : number of milliseconds of execution time to be exceeded


MonitorSelectivityThreshold

default: 0

change: RUNNING

 Threshold defined for defined for rate rows qualified/rows read

  0 : off
 >0 : rate rows qual/rows read


NetworkWorkerThreadCount

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)

OmsMaxHeapCancelOmsVersion

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.

OmsStreamTimeout

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)

ParallelJoinMinThreshold

default: 1000000

change: RUNNING

 Minimal size of base table (measured in records) to take parallel join into account
 join

ParallelJoinServerTasks

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.

PartitionedHashJoinMaxPinPages

default: 64

change: RUNNING

 Specifies the maximum number of pinned pages at a time for each partitioned hash join operator
 The lower and upper limits are:
     8 <= PartitionedHashJoinMaxPinPages <= 256 
 
 (4 bytes integer)

PreservedDBAnalyzerTasks

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)

PreservedEventTasks

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)

ReadAheadLobThreshold

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)

ReadAheadTableThreshold

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)

ReCreateViewsInMigration

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


ReservedCommandBufferReplySize

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)

RestartVolumeGroupingMemorySize

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.

ResultsetStorageOptimization

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


RetiredIOJobCount

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)

RTEDumpFileName

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))

RunTimeMemoryMapFileSize

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.

SavepointDeadlockDetection

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


SchedNoAgePriority

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).

ScheduleInterval

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.

SessionAllocatorBlockKeepCount

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.

SessionAllocatorSupplementSize

default: 131072

change: OFFLINE

  The default block size of task-specific allocator.
  Only the first block size is decided by InitialAllocatorSize.

ShowDataAccessMaxStackUsage

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)

ShowMaxStackUsage

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)

SpinlockBackoffBase

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.


SpinlockBackoffFactor

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.


SpinlockBackoffMaximum

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.


TaskCommunicationRequestPriority

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.

TaskingMode

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).

TaskIOFinishedPriority

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.

TaskLockGrantRequestPriority

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.

TaskLockYieldPriority

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.

TaskNiceElevationValue

default: 80

change: OFFLINE


The parameter TaskNiceElevationValue defines the amount of priority elevation a 
niced (prioritized) task gets.

(See: TaskRequestPriorityLow ... TaskRequestPriorityAboveHigh)
	

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 )

TaskRequestPriorityAboveLow

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 )

TaskRequestPriorityAboveNormal

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 )

TaskRequestPriorityBelowHigh

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 )

TaskRequestPriorityBelowNormal

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 )

TaskRequestPriorityHigh

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 )

TaskRequestPriorityLow

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 )

TaskRequestPriorityNormal

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 )

TaskResumeRequestPriority

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.

TaskRuntimeThreshold

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 

TaskSchedulerRetryLoops

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)


TaskSpecificCatalogCacheMinSize

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)

TaskYieldRequestPriority

default: "AboveLow"

possible values: "Low" "AboveLow" "BelowNormal" "Normal" "AboveNormal" "BelowHigh" "High" "AboveHigh"

change: RUNNING

This parameter specifies the task priority for yield requests.

TempResultsetPinPagesThreshold

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


UKTCPUBinding

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.


UKTCPUBindingList

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


UndoHistoryDistribution

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

UnknownSessionContextYieldsNull

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


UpdateStatParallelServerTask

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. 

UseableGarbageCollectorTaskUKTs

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.
 

UseableServerTaskUKTs

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.
 

UseableServerTaskUKTsInAdminMode

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.
 

UseAlternateAllocatorForServer

default: "YES"

possible values: "YES" "NO"

change: OFFLINE

 UseAlternateAllocatorForServer = YES choses a different implemenation to allocate
 memory from the operating system. 

UseAsynchronousIO

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))


UseAsynchronousLogTransport

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)

UseBackupCheck

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))

UseCheckIndexYield

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

UseColumnCompression

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

UseConverterStripesLockYielding

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))

UseDDLTrigger

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

UseDMLLocksForSelectForUpdate

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


UseDynamicCommunicationSegments

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
 

UseExtendedOracleSQLMode

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))

UseExtendedTimeMeasurement

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


UseFilesystemCacheForBackup

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))


UseFineGranularSynchronization

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


UseIOCompletionPort

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))

UseMultiPhaseDropTable

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


UseMultiVersionReadSupport

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


UseReadAheadJoin

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 


UseReadAheadLob

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


UseReadAheadUndoRedo

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


UseRestrictedPredicatePushDown

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


UseSelectFetchOptimization

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))

UseSevereCatalogLocking

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   


UseShareLockForForeignKey

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


UseStrategyCache

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))

UseSystemTrigger

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

UseTableWidthCheckDuringDDL

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 

UseTenantBackupRegion

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


UseVectorIOSimulation

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))

UseVolumeLock

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))

VolumeIOQueuesForHighPriority

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)

VolumeIOQueuesForLowPriority

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)

VolumeIOQueuesForMediumPriority

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)

WriteRTEDumpDuringDBOffline

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))