default: depends on operating system or instance type
possible values: "BacktraceOnly" "BacktraceAndNormalMiniDump" "BacktraceAndFullMiniDump" "BacktraceAndCoreFile" "CoreFileOnly" (values are dependant 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: 0
change: RUNNING
BacktraceOnErrorWrites a backtrace, whenever the error identified by is triggered = 0 writes no backtrace
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
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for backup and recovery processing 0 : off 1 : hot 2 : default 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for catalog caches 0 : off 6 : check complete cache after most cache operations
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for commonly used code and Database Manager Commands 0 : off 1 : few checks 9 : all checks
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for converter 0 : off 1 : few checks 9 : all checks
default: "NO"
possible values: "YES" "NO"
change: RUNNING
CheckDataCache 'YES' or 'NO'
'YES': checking of data cache consistency is switched on
'NO' : checking of data cache consistency is switched off
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for index trees 0 : off 1 : few checks 9 : all checks
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for undo, redo, history data pages 0 : off 1 : few checks 9 : all checks
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: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for hashed tempfile 0 : off 3 : few checks 9 : all checks
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for hashed tempfile 0 : off 3 : few checks 9 : all checks
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for Free Block Management 0 : off 1 : few checks 9 : all checks
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for hashed resultset 0 : off 3 : few checks 9 : all checks
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for I/O manager 0 : off 1 : few checks 9 : all checks
default: "NO"
possible values: "YES" "NO"
change: RUNNING
Enables checks for usage of 'versionsupport' container property
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for read and write access of the log area 0 : off 1 : few checks 9 : all checks
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for consistent view and garbage collection 0 : off 1 : few checks 9 : all checks
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for pages on log volumes 0 : off 1 : few checks 9 : all checks
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for restart, savepoint and transactionhandling 0 : off 1 : few checks 9 : all checks
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for QUERYANALYSIS 0 : off 3 : few checks 9 : all checks
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for QUERYREWRITE 0 : off 3 : few checks 9 : all checks
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for work of servertasks 0 : off 1 : few checks 9 : all checks
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for UseSharedSQL 0 : off 3 : few checks 9 : all checks
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for consistency of sql lock management control structures 0 : off 1 : few checks 3 : check of consistency of lock management control structures 6 : check of lock region usage 8 : check of free space management (supply segments) 9 : all checks
default: "NO"
possible values: "YES" "NO"
change: RUNNING
CheckTaskSpecificCatalogCache 'YES' or 'NO'
'YES': checking of task-specific catalogcache is switched on
'NO' : checking of task-specific catalogcache is switched off
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for consistency of transaction with its control structures 0 : off 1 : few checks 9 : all checks
default: "NO"
possible values: "YES" "NO"
change: RUNNING
CheckTree 'YES' or 'NO'
'YES': checking of primary and secondary tree structure after modification is switched on
'NO' : checking of primary and secondary tree structure after modification is switched off
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: 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, indices 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)
default: 0
change: OFFLINE
This value describes how many days a dbanalyzer started by the Database Manager should preserves the history of collected data in the analyzer directory. Older log files and directories of the dbanalyzer will be deleted by the dbanalyzer. The special value 0 does suppress the deletion of the log files.
change: RUNNING
If a filename is set it 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 indices are deleted without reading the leaf pages. 'NO': tables and indices 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 garbage collection. 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 objectframe 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: "NO"
possible values: "YES" "NO"
change: OFFLINE
Do NOT USE this parameter
as it will be removed without further notice during
the last weeks of 2009 or the first ones of 2010.
It will be removed when the implementation of tenantdirectory has
reached the necessary state.
EnableClientSpecificOmsSchema 'YES' or 'NO'
'NO': All tenants share one common Oms-Default-Schema
'YES': Each tenant has an own Oms-Default-Schema
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 performce.
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: "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 parameter to 'Yes' may have a bad performance impact.
default: "NO"
possible values: "YES" "NO"
change: OFFLINE
'YES': allow external kernel dump requests
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/indices 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: "YES"
possible values: "YES" "NO"
change: RUNNING
Specifies if statements sent with execute-immediate shall be implicitly prepared and executed in separate steps.
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: "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 indices
'NO' : don't search for addnl. qualification on indices
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': Schemaname has to be specified in procedures, triggers and functions.
'NO' : Schemaname could be omitted.
default: 10
change: OFFLINE
The lower and upper limits are:
1 <= GarbageCollectors <= 64
(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
change: OFFLINE
if not empty, indicates that this parameter set belongs to a database and gives its instance (string)
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 are dependant 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: "jvm"
change: OFFLINE
The database kernel will use the Java Virtual Machine that is located at the specified path. If the path supplied here is not an absolute path, a path below the version-dependent installation directory is assumed. If 'JAVA_HOME' is specified, the system-specified value is used.
change: OFFLINE
When starting a a Java Virtual Machine, the options specified in this parameter are supplied to the Java Virtual Machine. These options can be used to set special system dependent flags for the embedded Java Virtual Machine, e.g. for diagnostic or debugging purposes.
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 behaviour 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 behaviour 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 behaviour. 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 behaviour 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: depends on operating system or instance type
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
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
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: depends on operating system or instance type
change: OFFLINE
default: depends on operating system or instance type
change: OFFLINE
In general, this is the name of the database console. The messages are database error and informative messages of mean priority. The messages will be sent to the database console and to the diag file. (char (256))
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: 1
change: RUNNING
Minimum number of password characters.
The lower and upper limits are:
1 <= MinPasswordLength <= 256
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: 0
change: OFFLINE
Port number to listen on for TCP/IP connections.
Zero port means the TCP/IP listener in kernel is disabled.
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 server task 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, server tasks 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
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: depends on operating system or instance type
change: OFFLINE
new in 7.9.09.01
Interval for additional TaskScheduler queue lookups.
0 : off
> 0 : interval in seconds (must be equal or below 3600 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: "NO"
possible values: "YES" "NO"
change: RUNNING
new in 7.9.09.06
Parameter enables the strict password policy.
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: 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: "70L80M85M90H95H96H97H98H99H"
change: RUNNING
An event of category ThrowDBFillingAboveLimitEvent is transmitted whenever
the filling level of the data area exceeds one of predetermined thresholds.
The thresholds 70, 80, 85, 90, 95, 96, 97, 98 and 99 percent are
predetermined by default.
The events of category ThrowDBFillingAboveLimitEvent can be activated and
deactivated. To activate or deactivate an event of category
ThrowDBFillingAboveLimitEvent the threshold for the filling level must be
specified as whole-numbered percentage between 0 and 99. Event activation
and deactivation can be used to override the predetermined events (change
the priorities or deactivate predetermined events).
An actual event of category ThrowDBFillingAboveLimitEvent contains usable
information within the following data fields:
NAME:
This data field contains the name of the event. The following value
can occur:
DBFillingAboveLimit
PRIORITY:
This data field contains the priority of the event. The following
values can occur:
LOW, The event is considered to be of low importance. This is
the default for the filling level of 70%.
MEDIUM, The event is considered to be of medium importance. This
is the default for the filling levels 80% and 85%.
HIGH, The event is considered to be of high importance. This is
the default for the filling levels 90%, 95%, 96%, 97%, 98%
and 99%. Under normal circumstances one should start to
add a new data volume immediately.
VALUE1:
This data field contains the number of used pages in the data area.
VALUE2:
This data field contains the number of used pages in the data area as a
percentage.
default: "70L80L85L90L95L"
change: RUNNING
An event of category ThrowDBFillingBelowLimitEvent is transmitted whenever
the filling level of the data area falls below one of predetermined
thresholds.
The thresholds 70, 80, 85, 90 and 95 percent are predetermined by default.
The events of category ThrowDBFillingBelowLimitEvent can be activated and
deactivated. To activate or deactivate an event of category
ThrowDBFillingBelowLimitEvent the threshold for the filling level must be
specified as whole-numbered percentage between 1 and 100. Event activation
and deactivation can be used to override the predetermined events (change
the priorities or deactivate predetermined events).
An actual event of category ThrowDBFillingBelowLimitEvent contains usable
information within the following data fields:
NAME:
This data field contains the name of the event. The following value
can occur:
DBFillingBelowLimit
PRIORITY:
This data field contains the priority of the event. The following
values can occur:
LOW, The event is considered to be of low importance. This is
the default for the preset thresholds 70%, 80%, 85%, 90%
and 95%.
MEDIUM, The event is considered to be of medium importance.
HIGH, The event is considered to be of high importance.
VALUE1:
This data field contains the number of used pages in the data area.
VALUE2:
This data field contains the number of used pages in the data area as a
percentage.
default: "50L75L90M95M96H97H98H99H"
change: RUNNING
The system transmits an event of the category ThrowLogAboveLimitEvent,
whenever the filling level of the log area exceeds one of predefined
thresholds.
By default ThrowLogAboveLimitEvent events are activated for the filling
level thresholds 50%, 75%, 90%, 95%, 96%, 97%, 98% and 99%.
The events of category ThrowLogAboveLimitEvent can be activated and
deactivated. To activate or deactivate an event of category
ThrowLogAboveLimitEvent the threshold value for the filling level must be
specified as whole-numbered percentage between 1 and 99. Event activation
and deactivation can be used to override previously activated
ThrowLogAboveLimitEvent events (change priorities or deactivate predefined
events), including the ThrowLogAboveLimitEvent events activated by default.
An actual event of category ThrowLogAboveLimitEvent contains usable
information within the following data fields:
NAME:
This data field contains the name of the event. The following value
can occur:
LogAboveLimit
PRIORITY:
This data field contains the priority of the event. The following
values can occur:
LOW, The event is considered to be of low importance. This is
the default for the filling levels 50% and 75%.
MEDIUM, The event is considered to be of medium importance. This
is the default for the filling levels 90% and 95%.
HIGH, The event is considered to be of high importance. This
is the default for the filling levels 96%, 97%, 98% and
99%. Under normal circumstances one should start to
backup the log area immediately.
VALUE1:
This data field contains the absolute number of currently used pages in
the log area.
VALUE2:
This data field contains the currently used pages in the log area as a
percentage.
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for access path optimizer 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: "NO"
possible values: "YES" "NO"
change: RUNNING
TraceAK 'YES' or 'NO'
'YES': tracing of all order packets (including internal packets) is switched on
'NO' : tracing of all order packets (including internal packets) is switched off
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for allocators 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: "NO"
possible values: "YES" "NO"
change: RUNNING
TraceAlterObject 'YES' or 'NO'
'YES': tracing of changing of objects is switched on
'NO' : tracing of changing of objects is switched off
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for work of servertasks 0 : off 1 : hot 2 : default 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for catalog management 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for catalog caches 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for communication between client and server 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for commonly used code and Database Manager Commands 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for communication 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for converter 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for the data agent 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of data cache tracing 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for operations on data page chains 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing on index trees 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing on lobs 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for page access with the new interface 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for data source 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for hashed tempfile 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for update statistics on trees 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for db-procedures, functions and triggers 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: "NO"
possible values: "YES" "NO"
change: RUNNING
TraceDefault 'YES' or 'NO'
'YES': tracing of INDEX, LOCK, LOB, PAGES, ORDER STANDARD, TABLE, ... is switched on
'NO' : tracing of INDEX, LOCK, LOB, PAGES, ORDER STANDARD, TABLE, ... is switched off
default: "NO"
possible values: "YES" "NO"
change: RUNNING
TraceDelete 'YES' or 'NO'
'YES': tracing of complete message buffer of DELETE is switched on
'NO' : tracing of complete message buffer of DELETE is switched off
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for the transforming DML statements into internal structure 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for accessing external data sources and distributed query processing 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for accessing external data sources and distributed query processing via ODBC 0 : off 3 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for accessing external data sources via TPT 0 : off 3 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for file directory operations 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for framecontrol 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for Free Block Manager 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: "NO"
possible values: "YES" "NO"
change: RUNNING
TraceFreeObject 'YES' or 'NO'
'YES': tracing of releasing of objects is switched on
'NO' : tracing of releasing of objects is switched off
default: "NO"
possible values: "YES" "NO"
change: RUNNING
TraceGetObject 'YES' or 'NO'
'YES': tracing of accesses to objects is switched on
'NO' : tracing of accesses to objects is switched off
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
trace level of legacy 'gg' source layer 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: "NO"
possible values: "YES" "NO"
change: RUNNING
TraceInsert 'YES' or 'NO'
'YES': tracing of complete message buffer of INSERT is switched on
'NO' : tracing of complete message buffer of INSERT is switched off
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for internal SQL statements 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for interpreter of internal command structure 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for interprocess communication 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for I/O manager 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for operator-join implementation 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for join path optimizer 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
trace level of legacy 'kb' source layer 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for lock manager activity 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing of actions in online, undo or redo case 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for read and write access of the log area 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for consistent view and garbage collection 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for pages on log volumes 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for restart, savepoint and transactionhandling 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for memory management 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of additional tracing for messages component 0 : off 1 : all error messages are additionally shown in KnlMsg and KnlMsgArchive after creation 2 : all warning and error messages are additionally shown in KnlMsg after creation 3 : all error, warning and info messages are additionally shown in KnlMsg after creation 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for the diagnostic information into internal structure 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing of multi version read 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: "NO"
possible values: "YES" "NO"
change: RUNNING
TraceNewObject 'YES' or 'NO'
'YES': tracing of creation of objects is switched on
'NO' : tracing of creation of objects is switched off
default: "NO"
possible values: "YES" "NO"
change: RUNNING
TraceObject 'YES' or 'NO'
'YES': tracing of accesses to objects (includes ADD, GET, ALTER, FREE) is switched on
'NO' : tracing of accesses to objects (includes ADD, GET, ALTER, FREE) is switched off
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for container for liveCache objects 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for OMS flush cache =0 : off >0, <=9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for OMS containerdirectoy =0 : off >0, <=9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for OMS context =0 : off >0, <=9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for OMS errors =0 : off >0, <=9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for OMS heap memory handling =0 : off >0, <=9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for OMS interface =0 : off >0, <=9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for OMS key handling =0 : off >0, <=9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for OMS keyranges =0 : off >0, <=9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for OMS locking =0 : off >0, <=9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for OMS memory handling =0 : off >0, <=9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for OMS new objects =0 : off >0, <=9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for OMS persistent objects =0 : off >0, <=9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for OMS sessions =0 : off >0, <=9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for OMS streams =0 : off >0, <=9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for OMS transactions =0 : off >0, <=9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for OMS objects of variable length =0 : off >0, <=9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for OMS versions =0 : off >0, <=9 : tracing of all information
default: "NO"
possible values: "YES" "NO"
change: RUNNING
TraceOptimizer 'YES' or 'NO'
'YES': tracing of optimizer output is switched on
'NO' : tracing of optimizer output is switched off
default: "NO"
possible values: "YES" "NO"
change: RUNNING
TraceOrder 'YES' or 'NO'
'YES': tracing of complete order packet is switched on
'NO' : tracing of complete order packet is switched off
default: "NO"
possible values: "YES" "NO"
change: RUNNING
TraceOrderStandard 'YES' or 'NO'
'YES': tracing of the beginning of all parts of the order packet is switched on
'NO' : tracing of the beginning of all parts of the order packet
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for the execution of an execution plan 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for the QUERY component 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for the QUERYREWRITE component 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for sql generation within the QUERY component 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for runtime environment 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for runtime diagnose 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: "NO"
possible values: "YES" "NO"
change: RUNNING
TraceSelect 'YES' or 'NO'
'YES': tracing of complete message buffer of SELECT, GET, FETCH and UNION is switched on
'NO' : tracing of complete message buffer of SELECT, GET, FETCH and UNION is switched off
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for work of servertasks 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for the SharedSQL component 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for common SQL execution 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of checking for consistency of transaction with its control structures 0 : off 1 : few checks 3 : tracing of collisions and their elimination 8 : traceing of free space management (supply segments) 9 : all checks
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for the SQL manager component 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
change: RUNNING
Errorcode which stops further tracing 0 means: no stop value specified
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for synchronization of shared resources 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for syntax analysis 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for management of systemviews 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for the new table handling 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: "NO"
possible values: "YES" "NO"
change: RUNNING
TraceTime 'YES' or 'NO'
'YES': tracing of elapsed time in kernel underneath of the message buffer is switched on
'NO' : tracing of elapsed time in kernel underneath of the message buffer is switched off
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing transaction creation deletion or change of status 0 : off 1 : only tracing of high priority information 3 : distributed transaction calls (OSF/XA calls) 9 : tracing of all information
default: "NO"
possible values: "YES" "NO"
change: RUNNING
TraceUpdate 'YES' or 'NO'
'YES': tracing of complete message buffer of UPDATE is switched on
'NO' : tracing of complete message buffer of UPDATE is switched off
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for the transforming of value expressions into internal structure 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: 0
possible values: 0 1 2 3 4 5 6 7 8 9
change: RUNNING
level of tracing for volume management in RTE 0 : off 1 : only tracing of high priority information 9 : tracing of all information
default: "NONE"
possible values: "NONE" "AUTO" "IDEAL_PROCESSOR" "USER_DEFINED" (values are dependant 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 hit rate). 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: "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: "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: "OFF"
possible values: "ALL" "UNIQUE" "OFF" "YES" "NO"
change: RUNNING
Displays the behavior of the database system in case bad indices are detected.
This parameter can have one of the following values:
'ALL' | 'YES' : All indices that are detected to be bad are automatically
repaired (recreated).
'UNIQUE' | 'NO' : Unique indices are automatically repaired (recreated) if
they are broken.
'OFF' : The database system does not perform any action if bad
indices are detected.
This parameter must not be modified manually. Instead, it is modified
automatically when the status of the AutoRecreateBadIndex feature is modified
(with the command auto_recreate_bad_index).
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 indices 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: 0
change: OFFLINE
Triggers automatic start and stop of the Database Analyzer. Value 0 (zero) deactivates this feature. Positive values define the number of seconds between two snapshots.
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 instance is used as liveCache or by R/3
'NO' : database instance is neither used as liveCache nor by R/3
(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
Specifies if you want to wait until volume I/O is written to disk.
UseFilesystemSynchronisation = 'YES' or 'NO'
'YES': Always open volumes with flags that specify I/O write operation to return
only if I/O blocks are written to disk
'NO' : Allow I/O operation to report completion after file system cache is written.
Even if this I/O is faster, you can loose data in case of a crash. It is therefore
definitely not recommended to use this mode. A COMMIT does no longer mean, information
is written in persistent manner.
(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: OFFLINE
This value forces the automatic load of the system tables during database startup, if the last loded version differs from the current version of the kernel executable.
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: "NO"
possible values: "YES" "NO"
change: RUNNING
new in 7.9.09.05
ReCreateViewsInMigration 'YES' or 'NO' 'YES': keys build by multiple columns are always filled with zeros 'NO' : keys build by multiple columns are filled by defined bytes
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: "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: -1
change: RUNNING
if not -1, only tasks in the UKT defined by this parameter are used for incoming connections. Tasks in other UKTs are only used for connections if there are no unconnected tasks left in the UKT defined by this parameter. May be used in situations where multiple clients are connected to one database kernel and it is wanted that each client only uses tasks that are running on his cpu. (4 bytes integer)
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))