MaxDB Administration – Runtime Environment – SAP liveCache
MaxDB Administration – Runtime Environment – SAP liveCache
This Post is intended for SAP MaxDB experts. It provides an overview of questions and answers about the SAP MaxDB Runtime Environment, and refers to sources of information.
The post refers in general to SAP MaxDB, but can similarly be applied to SAP liveCache instances.
Other Terms: FAQ; Runtime Environment; x_cons; , RTEMemory_Chunk
Reason and Prerequisites
You use SAP MaxDB Version 7.5 or higher as an OLTP, BW, Content Server or SAP liveCache in your SAP system.
- What is the SAP MaxDB runtime environment?
The runtime environment is the connection of an SAP MaxDB to the relevant operating system.
- Which processes are contained in an SAP MaxDB database on Windows?
- dbanalyzer.exe: Database Analyzer for performance long-term analysis
- dbmcli.exe: Database Manager CLI (Command Line Interface) for database administration
- dbmevtdisp.exe: Event dispatcher
- DBMGui3.exe: Database Manager GUI for database administration
- dbmsrv.exe: DBM server
- dbmsrvscd.exe: Event scheduler
- kernel.exe: Database system kernel. Each database has its own core process.
- loadercli.exe: Loader for unloading and loading data
- vserver.exe: X server responsible for communication between remote applications and the database kernel.
- sqlcli.exe: SQLCLI (Command Line Interface) for SQL queries
- SQLSto.exe: SQL Studio
- dbstudio.exe: Database Studio as of Version 7.7
- wahttp.exe: SAP MaxDB Web Server
- Which processes are contained in an SAP MaxDB database on Unix?dbanalyzer: Database Analyzer for performance long-term analysis
dbmcli: Database Manager CLI (Command Line Interface) for database administration
dbmevtdisp: Event dispatcher
dbmsrv: DBM server
dbmsrvscd: Event scheduler
kernel: Database system kernel. Each database has its own core processes (two).
loadercli: Loader for unloading and loading data
vserver: X server; a new child process is started for each database connection on UNIX/Linux.
niserver: Part of the X Server that is required for NI support for SAP MaxDB Support (SAPDB connection).
sqlcli: SQLCLI (Command Line Interface) for SQL queries
wahttp: SAP MaxDB Web Server
- What functions are performed by the database kernel?
The kernel performs all central database tasks for the database. These tasks include, for example, establishing connections, reading and writing data (I/O), monitoring the database, and processing SQL statements (user tasks).
The database kernel runs as a single operating system process (service) on Microsoft Windows. On UNIX, two operating system processes belong to the kernel: Upon startup, the database system generates a watchdog process that immediately branches itself and starts the actual kernel as a process.
- Which task types are contained in an SAP MaxDB database?
- Event-Task: The event task accepts events generated in the kernel and communicates them to the outside.
- Log-Writer: Log writers write the log entries from the log queue to the log area, for example, in the case of a COMMIT or savepoint.
- Pager (Data-Writer): Pagers write the data for each savepoint from the data cache to the data volumes. If the data cache is large, executing a savepoint may take a very long time. If necessary, pagers may also become active between the end of one savepoint and the start of the next savepoint. This allows the changed data to be written asynchronously to the data volumes.
- Server-Task: The server task run database functions in parallel. They are used, for example, to save data and log entries, create indexes and finally delete tables. When the system is restarted, the server tasks upload log entries and simultaneously process transactions.
- Timer-Task: The timer task is responsible for timeouts of SQL lock requests. It checks whether log entries can be saved.
- Trace-Writer-Task: When the database trace is activated, the trace writer task writes the trace entries from the working memory to the trace file (knltrace).
If the database crashes, the trace writer task writes the contents of the internal data structures to the file knldump.
The file knldump may become very large. You can determine a guide value for the size of the file using the system table MEMORYALLOCATORSTATISTICS (column: RTE_MEM_Allocator). You can use the database parameter KernelDumpFileName to specify an absolute path to which the file is written if a crash occurs.
- User-Task: User tasks execute SQL statements.
- Utility-Task (only versions < 7.7.): The utility task performs management tasks.
- Floating-Task (only versions >= 7.7): The floating task is only a service task that has no specific tasks at first. The floating task can be accessed only by database tools. In SAP MaxDB Version 7.7, the event mechanism and the Database Analyzer use this floating task. As soon as a tool utilizes a service task, the task name changes (for example, “Analyze”).
- Idle task (only versions >= 7.7): The idle task exists as of Version 7.7 but has a job only as of 7.8. There is an idle task for each UKT. You use this idle task for task scheduling. As of SAP MaxDB Version 7.8 or higher, the number of CPUs to be used by SAP MaxDB/liveCache (MaxCPUs) can be reduced dynamically (UseableCPUs). You require the idle task to implement this feature.
- How is the number of user tasks determined?
When a database user opens a database session, the database system permanently assigns a user task to this database user. You can configure the number of user tasks available with the general database parameter MaxUserTasks (MAXUSERTASKS).
- How is the number of server tasks configured?You can configure the number of server tasks available with the special database parameter MaxServerTasks (MAXSERVERTASKS).
Server tasks may have a special name, depending on their use: for example, Savepoint, BackupMedium, BackupVolume, AutosaveCoordinator, AutosaveMedium.
- Can I configure the number of pagers?
When the system is restarted, the pagers import the converter pages from the data volumes to the converter cache. The number of pagers required is calculated by the system. This number depends primarily on the size of the data cache (database parameter CacheMemorySize) and the number of data volumes. If SAP MaxDB specialists carry out a performance analysis and discover that the number of pagers is inadequate, you can use the database parameter XP_MAXPAGER (as of SAP MaxDB Version 7.6) or MaxPagerTasks (as of SAP MaxDB Version 7.7) to override the calculated number of pagers explicitly.
- Is a new process started for every database task?
No. The database kernel generates operating system threads for tasks that should be executed in parallel.
On Linux systems without NPTL (Native Posix Thread Library), every thread is simulated by a clone process.
- What is a user kernel thread (UKT)
The database system differentiates between two types of threads: UKTs (user kernel threads) and special threads.
UKTs contain a group of tasks (various task types). UKTs containing user tasks process the client requests. These are the threads that require the most processor time. A database generally had several UKTs that contain user tasks.
Several tasks share a UKT. The database system determines the sequence in which the tasks in a UKT are to run, and can thus avoid conflicts when resources are accessed (task switch). For optimum distribution of the tasks across the UKTs, the database system performs internal load balancing.
- What special threads are available?
Special threads have precisely one task. Some special threads provide services for the UKTs. Within special threads, the database system performs tasks whose duration cannot be forecast, such as operating system calls for reading and writing to volumes and connection requests from clients. The database system processes special threads asynchronously with the UKTs.
- Coordinator: The coordinator thread monitors all threads belonging to the database. This is the first thread created by the database system when the database is started. It coordinates the start activities for subsequent threads. If an error occurs, the coordinator thread can stop other threads.
- Requester: The requester thread accepts user logons on the database and assigns them to a user task within a user kernel thread.
- Console: The console thread processes the requests from the database tool XCONS (database console).
- Clock (only Windows): The clock thread sets a global time variable that guides internal time measurements.
- dev<n>: Dev threads are responsible for executing read and write requests for the tasks to the volumes. The dev threads are numbered sequentially (dev<n>). Dev thread dev0 performs a special role: it coordinates and monitors the other dev threads.
- asdev<i>: The database system activates temporary dev threads to carry out data backups.
- Timer: Timer threads are responsible for time monitoring during timeouts, internal load balancing, and additional time-dependent internal control functions.
- Worker: The worker thread is responsible for reporting completed asynchronous I/O operations.
- Which factors determine how the MaxCPUs (MAXCPU) database parameter is set?
The database parameter MaxCPUs (MAXCPU) is used to notify the database kernel of the number of CPUs from the threads that can be used by the database. However, this configuration affects only UKTs that contain user tasks. Other threads access an unlimited number of CPUs, even if the value of MaxCPUs (MAXCPU) is reduced. In general, the following applies:
MaxCPUs (MAXCPU) specifies the number of CPUs subject to intensive, simultaneous use.
The value of MaxCPUs (MAXCPU) plays a major role in influencing how the database kernel tasks are distributed among the operating system threads (parameter _TASKCLUSTER_<number> (TaskCluster_<number>)). If the host is used purely as a database server, MaxCPUs (MAXCPU) should be equal to the number of CPUs belonging to the host; otherwise, the value should be reduced to relieve some CPUs for other applications.
In the central SAP system: Ratio of CPUs of the database/SAP system: 1/3 – 1/5 of the available cores should be configured.
In the case of a pure database server with up to 7 CPUs: 100% of available cores are used for the database.
In the case of a pure database server with more than 7 CPUs: 100% of available CPUs -1
For more information, see the FAQ Note 820824 and SAP MaxDB training materials for WB550 in the section on parameters.
- Where can I find information about how MaxCPUs (MAXCPU) are to be set in virtual environments?Refer to SAP Note 1459538.
- What determines the number of threads created and which tasks are assigned to which thread?The database parameters MaxCPUs (MAXCPU) and MaxUserTasks (MAXUSERTAKS) control the number of UKTs, and therefore how the task cluster is set.The database parameters TaskCluster01 (_TASKCLUSTER_01), TaskCluster02 (_TASKCLUSTER_02), and TaskCluster03 (_TASKCLUSTER_03) specify how the tasks of the database kernel are distributed to the UKTs.The task cluster should not be changed by the customer.
- How do I interpret the setting of the database parameter TaskCluster_<number> (_TASKCLUSTER_<number>)?The following example explains the interpretation of the task cluster setting: MaxUserTasks = 40, MaxCPUs = 2
In this example, 40 user tasks are configured. Since MaxCPUs = 2, the database kernel can distribute these user tasks to two UKTs that contain user tasks.Definition of task cluster using the database parameter TaskCluster_<number> (_TASKCLUSTER_<number>):
TaskCluster_01 = ‘tw;al;ut;2000*sv;10*ev,10*gc;’
TaskCluster_02 = ‘ti,100*dw;20*us;’
TaskCluster_03 = ‘equalize’Tasks between two semicolons are assigned to a UKT.
The trace writer (tw), log writer (al), and utility task (ut) each run in a UKT.
Up to 2,000 (practically all) server tasks (sv) are grouped in one UKT.
Up to 10 event tasks (ev) and up to 10 garbage collectors (gc) run in a UKT.
The timer task (ti) and up to 100 pagers (dw) run in a UKT.
Up to 20 user tasks (us) (MaxUserTasks/MaxCPUs = 20) run in one UKT with user tasks (referred to as UKT1 below), up to 20 user tasks (MaxUserTasks/MaxCPUs) run in an additional UKT with user tasks (referred to as UKT2 below).
- equalize: When logging on to the database, the system assigns the connect requirements of the application to user tasks and distributes them to UKT1 and UKT2 equally. This means that the first connect requirement is assigned to UKT1, the second connect requirement is assigned to UKT2, the third connect requirement is assigned to UKT1, and so on.
- compress: The system assigns the maximum number of tasks possible to UKT1 (in our example, this is 20 user tasks) before assigning user tasks to UKT2. This setting is possible only if MaxCPUs=1.
- onetoone: Each task (trace writer, server tasks, event tasks, user-tasks, and so on) receives its own UKT. As a result, many UKTs exist depending on the number of tasks. For this setting to take effect, you must also enter the key word onetoone in the database parameters TaskCluster01 and TaskCluster02.
Special feature as of SAP MaxDB Version 7.9.09:
As of the use of SAP MaxDB Version 7.9.09. the layout of the task cluster has been changed.
The calculation and distribution of the user and server tasks to the UKTs now take place entirely in the database kernel. The calculation of the number of tasks for the task cluster by the DBM server is omitted and there is now a large X as a placeholder at this place in the task cluster.
For the user tasks, the number of tasks per UKT depends on the parameters MaxUserTasks, MaxCPUs, and UseableCPUs; for the server tasks, it depends on MaxServerTasks, MaxServerTaskUKTs, and UseableServerTaskUKTs. As a result, there is normally a fractional number and thus – in the past – an imprecise value in the task cluster for the tasks. In certain circumstances, the old task cluster analysis can result in inaccuracies in large systems (PTS 1260789).
If the number of tasks does not completely tally, the remainder is now distributed evenly to the UKTs with the same task type.
- How can I change the number of dev threads?
The number of dev threads depends primarily on the number of volumes in the database.
SAP MaxDB versions lower than 7.7.01
For each data volume and each log volume, the database system activates _IOPROCS_PER_DEV dev threads. The database system also activates a dev thread for the database trace file.
- What is a task change?
Within a UKT, only one task can ever use the processor (have running status). All other tasks are either executable or they wait for an external event such as the end of an I/O operation and a relevant message before they are executable again.
When the current task no longer requires the processor, it initiates a task switch (cooperative task switch), and the next task can use the processor in the same UKT.
More information about this topic is available is in the SAP MaxDB documentation (Note 767598) under the keyword “Task” and in the SAP MaxDB course document WB550.
- What is load balancing?
The operating system has no influence on how the database system distributes the tasks from a database among the available UKTs. Therefore it cannot intervene if, for example, a user kernel thread applies a 100% load on a processor, and the other three processors belonging to the computer are not used at all.
Within a user kernel thread, tasks operate in a cooperative manner. In other words, they decide when to suspend themselves and allow processing of the next task (see task switch). As a result of this behavior, a single task may block all other tasks in the same user kernel thread.
For optimum distribution of the tasks among the UKTs, the database system performs internal load balancing. In this way, the database system achieves more efficient resource utilization and short response times for the individual users, especially on computers using several processors.
For more information on load balancing, see the SAP MaxDB documentation (Note 767598) under the keyword “load balancing”. Also refer to the SAP Notes containing the recommended database parameters for load balancing:
- What database tool can I use to view how the database is using operating system resources?
The database tool XCONS (database console) is used to display the operating system resources used by the database system, the distribution of database sessions among threads and the status of active database sessions. XCONS is a command line tool. It can be used on all operating systems supported by the database system.
We recommend that you only use XCONS in productive systems for analysis if you have a thorough knowledge of database and operating systems.
- How can I display task states?At operating-system level using the database console X_CONS and the show tasks command: x_cons <database_name> show tasksBy calling the task manager in the SAP system using the database assistant (transaction DB50/LC10) by choosing Current Status -> Kernel-Threads -> Task Manager -> All TasksFor more information, see the SAP MaxDB documentation: Console (Database Console).
- Which task states are available and what do they mean?The task state indicates whether a task is currently active and what action it is currently executing. The names of some task states were changed as of Version 7.7. The new names appear in parentheses after each task state.AsynClose (Stream Close): Task closes I/O ports after saving or restoringAsynCntl: Task determines parameter or initializes a backup device
AsynIO(Stream IO): Task executes asynchronous I/O operation (when saving or restoring)
AsynOpen(Stream Open): Task opens I/O ports for saving or restoring
AsynWaitRead/Write(Stream Wait(R)/(W)): Task waits for the end of an I/O operation during a save or restore operation
Command reply: Task transfers the result of a request to the application
Command wait: Database session without request
Connect wait: free database session
DcomObjCalled(LCApp Called): Task executes a database procedure or a LCA object
Diaginit: Task initializes the trace file within the database
Inactive: Task is in the initial status and has no resources (stack, for example)
InsertEvent: Task generates an event
IO wait (W/R): Task waits for the result of an I/O operation (W:write, R:read)
Locked: Task was locked when the kernel was shut down (to avoid rescheduling of this task)
RescheduleMsec: short-term wait situation; task starts running again automatically after a specified period (microseconds).
Runnable: Task is immediately executable, but was suppressed owing to long runtime or prioritizing of another task.
Running: Task runs, uses CPU
Vsleep (sleep): short-term wait situation; task starts running again automatically after a specified period.
Stopped: Task was suspended by kernel and waits before running again
Terminated: Task or database session was terminated
UNKNOWN: Task state is unknown
Vattach(Attach Volume): Task opens I/O ports (volumes, normal operation)
Vbegexcl(Enter Region): Task waits to enter a protected region
Vdetach(Detach Volume): Task closes I/O ports (volumes, normal operation)
Vdevsize: Task determines the size of a volume or formats a volume
Vdualvectorio(Dual Vector IO): Task executes a vector I/O operation (write or read) on two volumes in parallel
Vendexcl (Leave Region): Task leaves a protected region
VenterRWRegion (Enter RWRegion): Task waits to enter a protected region (reader/writer region)
Vfclose(File Close): Task closes a file
Vfopen (File Open): Task opens a file
Vfwrite (File Write): Task writes to a file
VleaveRWRegion (Leave RWRegion): Task leaves a protected range (reader/writer region)
Vopmsg (Message Output): Task writes a message to one of the following database files: KnlMsg (knldiag), KnlMsgArchive (knldiag.err), opmsg[n]
Vrelease (Connect Close): Task terminates the database session
Vshutdown (DB OFFLINE): Task changes the operation status of the database from ONLINE (above offline) to ADMIN
Vsuspend (Suspend): Task is suspended and waits to be explicitly woken (Vresume) by another task. There are special Vsuspend wait statuses, each of which is displayed under its own name.
Vvectorio (Vector IO): Task executes a vector I/O operation (write or read)
Vwait (Wait): Task waits to be explicitly woken (Vsignal) by another task, for example, when the task waits for an SQL or object lock.
WaitForEvent (Wait For Event): Task waits for event
- What does a number entry in brackets after a task state mean?The number entry in brackets after a task status describes a wait situation that the relevant task is experiencing.For example: T171 8 49 User 16879 Prep-End (230)You can use the command x_cons < database_name> show suspend to determine the reason for the wait situation in the system in question.
Note: The display is version-dependent. In addition, the result does not display all possible wait situations; instead, it displays only those that have occurred in the system since the database was restarted.
For example: Prep-End (230) : 7 ( 0.00% ) bd13GetNode
- What does a ‘!’ after a task state mean?An exclamation mark after the task status indicates that this task was canceled either by the application (for example, due to a termination of the work process) or by a kill or cancel command from the database console.It is not uncommon for a task to have this status for a long time. The disconnect does not take place until the transaction that was cancelled is rolled back.Important: Tasks that have a wait status (for example, VWAIT) are not canceled until the wait situation is over.
- What does a ‘&’ after a task status mean?An ampersand (&) after the task status means that the task is in an LCAPPS routine that was called from SAP liveCache.For example: T169 8 55 User 1569 ObjRootExcl &
- What are the possible reasons for wait statuses on B* trees or page chains?
Wait statuses on B* trees should not appear for an extended period in the database console (X_CONS) in a system that is performing efficiently. Wait statuses may appear on B* trees if lock requests on either the root page or a leaf page (at index or leaf level) are in conflict with a lock that has already been assigned.
- Read access:
The following steps are carried out for a read access on a B* tree:
First, a read access is performed on the root of the B* tree. A shared lock is set on the root page.
If a DDL or DML statement that is running simultaneously wants to lock the B* tree exclusively, it must request the root page exclusively, which causes a collision due to the existing shared lock. The task waiting on the exclusive lock is not woken until the shared lock on the root is released. If other tasks want to access the tree or root in the meantime, they are also suspended to prevent the exclusive lock request from having to wait “forever”.
Once the shared lock is approved, separators are used to determine the leaf where the searched record should reside. If the number (PageNo) of the page is fixed, a shared lock on the leaf is requested and a read access is performed for the lock in the data cache. This access may be delayed due to a collision with an exclusive leaf lock.
- Write access:In a similar procedure to the read operation described previously, the root of the B* tree is requested with a shared lock. The subsequent access on the relevant leaf is executed with an exclusive lock, which may collide with another shared lock at leaf level.
If you cannot carry out the change operation locally on the current leaf, a lock escalation takes place: in this case, the exclusive lock on the leaf and the shared lock on the root is released. An exclusive lock on the root is requested so that the previously identified cross-leaf operation can be executed. A new descent down the B* tree is then required because the structure of the B* tree may have changed and the path and neighboring nodes must be redefined for the target leaf.
- Delete access:
Deleting of a B* tree requires an exclusive lock on the root. This lock should prevent another task from working on the B* tree. However, this lock does not result in synchronization with the savepoint to prevent any “hang operations” with the savepoint.
If the root page was already changed previously by another operation, it is written explicitly by the delete process to prevent the next savepoint from having to wait for completion of the delete operation.
- Read access:
- Which wait statuses (VSUSPEND) exist on B* trees and what do they mean?
- Wait statuses on B* trees that contain permanent data (tables):TableRootShare:
A task attempts to set a shared lock on the root page of a table and has to wait because of a lock collision.TableRootExcl:
A task attempts to set an exclusive lock on the root page of a table and has to wait because of a lock collision.TableNodeShare:
A task attempts to set a shared lock on a page (at index level greater than 1 or at leaf level) of a table and has to wait because of a lock collision.
A task attempts to set an exclusive lock on a page (at index level greater than 1 or at leaf level) of a table and has to wait because of a lock collision.
A task attempts to set a shared lock on a page (at index level equal to 1 or at leaf level) of a table and must wait because of a lock collision.
A task attempts to set an exclusive lock on a page at index level equal to 1 of a table and has to wait because of a lock collision.
- Wait statuses on B* trees that contain temporary dataTempRootShare:
A task attempts to set a shared lock on the root page of a temporary B* tree and has to wait because of a lock collision.TempRootExcl:
A task attempts to set an exclusive lock on the root page of a temporary B* tree and has to wait because of a lock collision.TempNodeShare:
A task tries to set a shared lock on a page (index or leaf level) of a temporary B* tree and has to wait because of a lock conflict.
A task tries to set an exclusive lock on a page (index or leaf level) of a temporary B* tree and has to wait because of a lock conflict.
- Wait statuses on B* trees of indexesInvRootShare:
A task attempts to set a shared lock on the root page of an index and has to wait because of a lock collision.InvRootExcl:
A task attempts to set an exclusive lock on the root page of an index and has to wait because of a lock collision.InvNodeShare:
A task tries to set a shared lock on a page (index or leaf level) of an index and has to wait because of a lock conflict.
A task tries to set an exclusive lock on a page (index or leaf level) of an index and has to wait because of a lock conflict.
- Wait statuses on B* trees that contain permanent data (tables):TableRootShare:
- Which wait statuses (VSUSPEND) exist on page chains and what do they mean?
- Wait statuses on page chains that contain object data:ObjRootShare:
A task attempts to set a shared lock on the root page of a page chain of an object and has to wait because of a lock collision.ObjRootExcl:
A task attempts to set an exclusive lock on the root page of a page chain of an object and has to wait because of a lock collision.ObjNodeShare:
A task attempts to set a shared lock on a page of a page chain of an object and has to wait because of a lock collision.
A task attempts to set an exclusive lock on a page of a page chain of an object and has to wait because of a lock collision.
- Wait statuses on page chains that contain undo data:The database system writes undo log entries (before images) for transactions that change data in the database to undo log files (page chains) in the data area. The undo log entries enable a transaction rollback or consistent views (for example, in SAP liveCache).UndoRootShare:
A task attempts to set a shared lock on the root page of an undo page chain and has to wait because of a lock collision.UndoRootExcl:
A task attempts to set an exclusive lock on the root page of an undo page chain and has to wait because of a lock collision.
A task attempts to set a shared lock on a page of an undo page chain and has to wait because of a lock collision.
A task attempts to set an exclusive lock on a page of an undo page chain and has to wait because of a lock collision.
- Wait statuses on page chains that contain history data:History files contain references to the terminated transactions belonging to the undo log files.
At each savepoint, the database system writes the updated history files (page chains) to the data area.For performance reasons, several history files are always open in parallel. The database system calculates the number of history files from the general database parameter MAXUSERTASKS. As of Version 7.6, the garbage collectors check the history files at regular intervals of a few seconds. Once the garbage collectors have deleted the data that requires deletion, they also delete the relevant undo log files. This relieves the user task of the delete operation of the undo log files. The database can send a faster confirmation of the commit/rollback to the application.
Collisions may occur on the history files between the user task and garbage collectors.HistRootShare:
A task attempts to set a shared lock on the root page of a history page chain and has to wait because of a lock collision.
A task attempts to set an exclusive lock on the root page of a history page chain and has to wait because of a lock collision.
A task attempts to set a shared lock on a page of a history page chain and has to wait because of a lock collision.
A task attempts to set an exclusive lock on a page of a history page chain and has to wait because of a lock collision.
- Wait statuses on page chains that contain object data:ObjRootShare:
- What do the task states ‘DC OvFlow’ and ‘DB FULL’ mean?DC OvFlow: The data cache is used intensively at this time and cannot accept new data. The data cache can only start accepting data again when pages from the data cache have been written again to the volumes.
If you frequently observe DC OvFlow statuses:
– Check that your data cache has a configuration that is large enough
– Check whether the I/O system you are using is too slowDB FULL: The database data area on the data volumes is full. The data area cannot accept any more pages. The database hangs. To resolve the problem, add a new data volume.
- What do the task states ‘LogQ FULL’ and ‘LOG FULL’ mean?LogQ FULL: This task state does not affect the log area on the log volumes; instead, it affects the log queue (log IO queue). The log queues (database parameter LOG_IO_QUEUE/LogQueueSize) are currently used intensively and cannot accept any new redo log entries. The log queues can only start accepting redo log entries again when the log writer has written data from the log queues to the log area.If you frequently observe the LogQ Full status, check the following:- whether your log queues have a configured size that is too small (database parameter LOG_IO_QUEUE/LogQueueSize)
– whether the I/O system you use that is located on the log volume is too slow.
LOG FULL: This task state indicates that the log area on the log volumes is full. Database operation stops because no more log entries can be written to the log volume. To solve this problem, you must save the log area. Adding a log volume does not help in this situation.
Further information about the log area is available in SAP Note 869267, FAQ: SAP MaxDB LOG area.
- What are regions or critical sections in SAP MaxDB?A critical section is an area of the SAP MaxDB code that must only be run by one instance (tasks/threads) at a particular time. Competing accesses are synchronized using special semaphores (regions, reader-writer locks).
- Can I debug individual tasks?Yes, you can use the database console command debugtask to write a stack back trace to the file KnlMsg or KnlMsgArchive (knldiag, knldiag.err). As of SAP MaxDB Version 7.6.00 build 10, this command is also available on UNIX.x_cons <database_name> debugtask <task_ID>Example: x_cons LCA debugtask 100
- What purpose do the RTEMemory_Chunk.<number> files serve?When you start the database kernel, shared memory segments are created for the database console (XCONS) in the form of memory mapped files (RTEMemory_Chunk.<number>). The files are cyclically synchronized.The RTEMemory_Chunk files are located in the run directory, in the subdirectory rtedump_dir. There are two versions of each RTEMemory_Chunk file here: A current one (RTEMemory_Chunk.<number>) and a previous version (RTEMemory_Chunk.<number>.old).In the case of a database crash, the current content of the memory segments is synchronized with the memory mapped segments. The RTEMemory_Chunk files enhance the analysis options after a database crash. SAP Support can evaluate them using a post-mortem console.
x_cons <database_name> -p <archive_path> <command>
Specify the path for <archive_path> that contains the RTEMemory_Chunk files that are to be analyzed.
The number and size of the generated RTEMemory_Chunk files depends on the number and the size of the shared memory segments of the database console.
- Storage volume:
The memory space depends on the memory that the runtime allocates (internal structures). You can calculate the required size in the file system using the system table MEMORYALLOCATORSTATISTICS.
The allocated size (in bytes) for the RTEMem_RteAllocator specifies the size of all RTEMemory_Chunk files. Because there are always two versions for each file in rtedump_dir, you must multiply the displayed value by 2.
- Number of files:
As of 7.9.07, the size of the chunk files can be configured with the database parameter RunTimeMemoryMapFileSize. The number of files is calculated as follows:
Number_of_Files = (memory_space_of_runtime_internal_RTEMem_RteAllokator) / RunTimeMemoryMapFileSize
Default: 1 MB per Chunk file
The RTEMemory_Chunk files are created in the run directory in the subdirectory rtedump_dir and are implicitly copied to the DIAGHISTORY directory after a crash when you restart the database.
- Storage volume:
- Where can I find more information on the subject of the runtime environment?For more information about the runtime environment, see the SAP MaxDB documentation (SAP Note 767598), the SAP MaxDB course document for workshop WB550, and the SAP Community. The documentation for the database console (X_CONS) is provided at: https://wiki.scn.sap.com/wiki/x/ZeQ
- This document refers to
- This document is referenced by