MaxDB log files
This page gives an overview of the most important log files of MaxDB.
If not stated otherwise, these files are located in the rundirectory of the database instance (see SAP MaxDB directory structure).
knldiag/knldiag.old
knldiag.err
knltrace
knldump
rtedump
dbm.utl
dbm.prt
dbm.knl/dbm.ebp/dbm.ebl
dbm.ebf/dbm.mdf
dbm.ins
dbahist
xserver_<hostname>.prt
appldiag
lcinit.log/lcinit.his
DIAGHISTORY
knldiag/knldiag.old
These files contain status and error messages of the database instance.
File knldiag is the current file. It is created with a configured size (database parameter KERNELDIAGSIZE) when the database is started.
In the first part of this file messages of the database start into ADMIN mode are logged. This first part is separated from the second part of the file by a dashed line. The messages in this first part won't be overwritten.
In the second part of this file the database instance writes messages during online operation. These messages will be overwritten cyclically.
In case of a database crash a stack back trace is written into knldiag.
When the database is started, the last version of knldiag is copied to file knldiag.old.
You can get more information about the startup messages in knldiag in section MaxDB Database Start.
As of version 7.7. knldiag is renamed to KnlMsg and written in a new format. More information can be found here: HowTo - New "knldiag" Message File Format in MaxDB 7.7
back to top
knldiag.err
This file contains error messages of the database instance.
The content of this file is not overwritten cyclically. If you need to analyze a database problem and files knldiag and knldiag.old don't contain the relevant information anymore, you should check file knldiag.err
As of version 7.7. knldiag.err is renamed to KnlMsgArchive and written in a new format. More information can be found here: HowTo - New "knldiag" Message File Format in MaxDB 7.7
back to top
knltrace
This file contains the data of the database trace. For more information see MaxDB database trace.
back to top
knldump
In case of an emergency shutdown the global memory of the database instance is dumped into file knldump. The size of this file is approx. the size of parameter CACHE_SIZE (Data Cache + Converter Cache). The corresponding file directory needs to be large enough to store this file. The development team might need to analyse the knldump to find the cause of an emergency shutdown.
back to top
rtedump
In case of a database crash you can see in file rtedump which tasks were active in the database at the time of the crash. This file contains the output of command
x_cons <database name> show all
back to top
dbm.utl
This is the kernel administration log. This file contains administrative commands sent to the database kernel (e.g. SHUTDOWN, BACKUP, CHECK DATA) including their return code(s), it is written by the kernel. Column "No." contains an ascending numbering of the lines per "Kernel-Session-ID:".
This file has a fixed size and is overwritten cyclically.
As of MaxDB version 7.7, this file does not exist anymore. Equivalent information is written to dbm.prt by the DBM Server, whenever it sends an administrative command to the kernel resp. whenever it receives the reply of an administrative command. Here, the columns "Kernel-Session-ID:", "No:" and "Label:" don't exist.
Example:
| Date: |
Time: |
Kernel-Session-ID: |
No: |
Label: |
Text: |
| 2008-04-21 |
18:35:29 |
480D16B10002 |
0000 |
RDB |
RESTORE DATA QUICK FROM 'J:\Backup\PRD001' FILE BLOCKSIZE 8 MEDIANAME 'PRD-Backup' |
| 2008-04-21 |
20:53:22 |
480D16B10002 |
0001 |
RET |
RETURNCODE 0 |
| 2008-04-21 |
20:53:22 |
480D16B10002 |
0002 |
TAP |
DATE.............. 2008-04-21 |
| 2008-04-21 |
20:53:22 |
480D16B10002 |
0003 |
TAP |
TIME.............. 18:35:30 |
| : |
: |
: |
: |
: |
: |
| 2008-04-22 |
12:37:50 |
480E145E0003 |
0000 |
RLG |
RESTORE LOG QUICK FROM 'J:\Backup\PRD_LOG.783' FILE BLOCKSIZE 8 MEDIANAME 'PRD-LOG' |
| 2008-04-22 |
12:43:36 |
480E145E0003 |
0001 |
RET |
RETURNCODE -8020 |
| 2008-04-22 |
12:43:36 |
480E145E0003 |
0002 |
TAP |
DATE.............. 2008-04-22 |
| : |
: |
: |
: |
: |
: |
| 2008-04-22 |
12:43:36 |
480E145E0003 |
0017 |
TAP |
DB_IDENT.......... sap-kpro-prd:PRD_20060206_010247 |
| 2008-04-22 |
12:43:36 |
480E145E0003 |
0018 |
TAP |
MAX USED DATA PNO. UNDEF |
| 2008-04-22 |
12:43:37 |
480E145E0003 |
0019 |
RLG |
RESTORE LOG REPLACE 'J:\Backup\PRD_LOG.784' FILE |
back to top
dbm.prt
This is the database manager log file. It contains commands sent from the DBM clients (like DBMCLI or DBMGUI) to the DBM server. You can see e.g. if a data or log volume was added or if a parameter was changed.
back to top
dbm.knl/dbm.ebp/dbm.ebl
These files contain detailed information about backups created for your database instance.
dbm.knl:
This is the backup history. This file contains e.g. the label, date, time, size, return code of all backup actions.
dbm.ebp:
This file contains information about backups created using external backup tools (like Networker, ADSM, Backint,...)
File dbm.ebp is overwritten when a new request is sent to an external backup tool.
File dbm.ebl contains a history of dbm.ebp files - the size depends on the dbmserver parameter DBM_EBLSIZE.
back to top
dbm.ebf/dbm.mdf
These files contain further information about created backups.
File dbm.ebf is written in case an external backup tool is used for a backup. It then contains the command ID, the backup label, and the external backup id (EBID).
File dbm.mdf contains the command ID, the backup label and current backup medium definition of each backup.
back to top
dbm.ins
This log file contains information about the loading of the system tables. If an error occured during DBMCLI command load_systab you will find further information in this file.
back to top
dbahist
This page provides information about the log files of administrative tasks (like backup, recovery, update statistics, ...) which are located in directory DBAHIST. DBA History
back to top
xserver_<hostname>.prt
This is the log file of the TCP/IP listener (X-Server). It contains error messages concerning remote communication.
If network problems occur, error messages are logged in this file.
The first part contains information about operating system settings and the user envronment in which the x_server was started (e.g. limits concerning heap usage or number of open files).
This file is stored in directory <independent_data_path>\wrk.
back to top
appldiag
This file contains error messages of the MaxDB runtime environment.
UNIX/LINUX:
File appldiag is created in directory <independent_data_path>/wrk/<username>. For each os user a separate file is written.
Windows:
File appldiag is only written when the environment variable DIAGFILE is set to YES. The file is created in directory <independent_data_path>/wrk.
Example for the content of file appldiag:
2006-04-25 11:33:09 45754 ERR -11987 COMMUNIC kernel released connection!
2006-04-25 11:33:16 175096 ERR 11517 XUSER Could not open USER file, Permission denied
2006-04-25 11:33:16 175096 ERR 11534 XUSER Could not read USER data, rc = -1
back to top
lcinit.log/lcinit.his
These files are only written when you use liveCache.
File lcinit.log is written whenever you start/stop/initialize the liveCache using transaction LC10. It is logged, which action has been performed and if any errors occured.
File lcinit.his is the history of all these actions - each lcinit.log file is attached to lcinit.his.
Both files are located in the rundirectory of the database.
You can view these files in transaction LC10 -> Problem Analysis -> Logs -> Operating.
back to top
DIAGHISTORY
Directory DIAGHISTORY is a subdirectory of the rundirectory.
When the database determines during the startup that the previous shutdown was not a 'normal' shutdown but an emergency shutdown or a crash, the most important log files are copied to the DIAGHISTORY. In this directory a directory is created which is called <database name>_<timestamp>. The timestamp is the time of this restart - not of the crash.
These are the files which are copied/moved - if they have been written:
knldiag, knltrace, knldump, rtedump, *.dmp, *.buf, *.stm, core
The location of the DIAGHISTORY directories can be changed using the database parameter DIAG_HISTORY_PATH.
The number of histories which are stored can be changed using the database parameter DIAG_HISTORY_NUM. The default is 2.
If the log files cannot be copied successfully the database is nevertheless started.
back to top | 
