Registration

Dear SAP Community Member,
In order to fully benefit from what the SAP Community has to offer, please register at:
http://scn.sap.com
Thank you,
The SAP Community team.
Skip to end of metadata
Go to start of metadata

SAP® MaxDB - Log Files

 

This section is used as knowledge base to support SAP MaxDB databases using the SAP MaxDB log files.

Moderators: Birgit Malik

WIKI Space Editor: Thiago Lüttig.

 

If not stated otherwise, these files are located in the run directory of the database (see SAP MaxDB directory structure).

SAP MaxDB Kernel Log Files

Please be informed about KnlMsg,Knlsmg.old and KnlMsgArchive have to be converted into readable files (diag_pack).

SAP MaxDB History of log files
SAP MaxDBliveCache specific Log Files
SAP MaxDB Database Manager Log Files
SAP MaxDB Database Analyzer Log Files
SAP MaxDB Database Studio Log Files
SAP MaxDB Loader Log Files
SAP MaxDB Documentation
Details

KnlMsg, KnlMsg.old

(warning) As of version 7.7. knldiag, knldiag.old are renamed to KnlMsg, KnlMsg.old  and written in a new format. More information can be found here:  HowTo - New knldiag Message File Format in SAP MaxDB 7.7

These files contain status and error messages of the database. File KnlMsg/knldiag is the current file. It is created with a configured size (database parameter KernelMessageFileSize/ KERNELDIAGSIZE) when the database is started. In the first part of this file messages of the database start into operational state ADMIN 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 writes messages during ONLINE operation. These messages will be overwritten cyclically. In case of a database crash a stack back trace is written into KnlMsg/knldiag.

Each kernel area is identified by a letter-number combination. The following table shows the meaning of each combination:

Name

Meaning

AK51 / A51

Catalog cache

K38

Backup

KB50

Lock list

K51 / LOCK

Lock list elements

K55

Log queue

K56

Rollback cache

K57

Restart record

KB90 / K90

Server tasks

B10

Free block management (not in 7.4)

B12

Data writer (not in 7.4)

B15

I/O manager (not in 7.4)

B16

Converter (not in 7.4)

B20

Data cache

B77 / TREELOCK

Treelock list

B94

History

B930

Garbage collector

When the database is started, the previous version of KnlMsg/knldiag is copied to file KnlMsg.old/knldiag.old. You can get more information about the startup messages in knldiag in section SAP MaxDB Database Start. All information about KnlMsg and other log files can also be found in online documentation: Kernel Log File

back to top

KnlMsgArchive

(warning) 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 SAP MaxDB 7.7

This file contains database error messages  only. The content of this file is not overwritten cyclically. If you need to analyze a database problem and files KnlMsg and KnlMsg.old don't contain the relevant information anymore, you should check file KnlMsgArchive.

back to top

knltrace

This file contains the data of the database trace. For more information see SAP MaxDB database trace.

back to top

knldump

In case of an emergency shutdown the global memory of the database is dumped into file knldump. The size of this file is approx. the size of parameter CacheMemorySize (Data Cache + Converter Cache). The corresponding fdirectory (run directory by default)  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. Because of the huge size of knldump the analyzsis is typically done directly on the affected database server via ssh/WTS connection. It is not necessary to send this knldump to the support teams.

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

DIAGHISTORY

The directory DIAGHISTORY is a sub directory of the database run directory. 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 sub directory is created which is called <database_name>_<timestamp>. The timestamp is the time of this database restart - not of the crash. These are the files which are copied/moved - if they have been written: KnlMsg, knltrace, knldump, rtedump, *.dmp, *.buf, *.stm, core, RTEMemory_Chunk*.

The location of the DIAGHISTORY directories can be changed using the database parameter DiagnoseHistoryPath (DIAG_HISTORY_PATH). The number of histories which are stored can be changed using the database parameter DiagnoseHistoryCount (DIAG_HISTORY_NUM). The default is 2.

History_KnlMsg

As of SAP MaxDB version 7.9, the old knlMsg file is copied both to the run directory to KnlMsg.old and to the subdirectory DIAGHISTORY/History_KnlMsg with the name KnlMsg_<yyyymmdd>_<hhmmss>. The number of KnlMsg versions in this subdirectory is configured using the database parameter KernelMessageHistoryCount (default = 20).
back to top

RTEMemory_Chunk Files

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. In the case of a database crash, the current content of the memory segments is synchronized with the memory mapped files. The RTEMemory_Chunk files enhance the analysis options after a database crash.
The RTEMemory_Chunk files are not ASCII files. The SAP support team can evaluate them using the postmortem console (x_cons <database_name> -p <archive_path> <command>). For more information please check SAP note: 936058.

back to top

dbm.utl

(warning) As of SAP MaxDB version 7.7, dbm.utl 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.

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.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 Database Studio) 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. 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. dbm.ebl: File dbm.ebl contains a history of dbm.ebp files - the size depends on the DBM server parameter DBM_EBLSIZE. The parameter can be set via dbm_configset -raw DBM_EBLSIZE ... and accepts the values "NONE" or any positive integer as the limit of action logs kept in the dbm.ebl file. When the parameter is not specified the default value of 13 actions to be kept is used. The value "NONE" disables the writing of this file. (PTS 1115527)

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 DBM command load_systab you will find further information in this file.

back to top

dbahist.prt

The extended DBA action logging must be switched on once after the installation of the database/liveCache using: dbmcli -d <database_name> -n <database_server> -u <dbm_operator>,<password> dbm_configset DBADTL 1

Extended log files

The following directory and log files are automatically created after the extended logging is switched on:

  • Directory dbahist in the run directory of the database
  • File dbahist.prt in directory dbahist. This file contains one line per DBA action.
  • One file dba<timestamp>.<functionID> for each DBA action (e.g. dba20020314133643.sda). This file contains the kernel log of the DBA action (as written into dbm.utl) as well as log information from the DBM server and (if used) the backup tool from other provider.
Identification of DBA actions

All DBA actions are uniquely identified by their timestamp and function ID.

  • The timestamp is of the form YYYYMMDDHHMMSS and corresponds to the start time of the action.
  • The timestamp of an action can be found
    • In column Beg in file dbahist.prt
    • In the name of the log file for each dba action

The function ID identifies the kind of DBA action. The following actions are logged for example in directory dbahist (the function IDs differ depending on the database version).

FID

Action

ase

Deactivate automatic log backup

aso

Activate automatic log backup

sda

Complete data backup

ssaArchive log backup files

slo

Log backup

spa

Incremental data backup

cda

Check complete data backup

cloCheck log backup 
cpaCheck incremental data backup
cdb

Check Database Structure

csn

Check Database Strucutre from Snapshot

cde

Check Database Structure (only Tables)

oscUpdate all optimizer statistics
ochMark tables requiring statistics update
osrUpdate statistics for marked tables

The function ID of an action can be found

  • In column Fid in file dbahist.prt
  • In the name of the log file for each DBA action

 

Accessing the log files with tool dbmgetf
  • dbmgetf -d <database_name> -n <database_server> -u <dbm_operator>,<password> -k DBAHIST delivers log file dbahist.prt
  • dbmgetf -d <database_name> -n <database_server> -u <dbm_operator>,<password> -k DBADTL#<timestamp>.<functionID> delivers log file dba<timestamp>.<functionID> (e.g. dbmcli -d <database_name> -n <database_server> -u <dbm_operator>,<password> -k DBADTL#20020314133643.sda delivers log file dba20020314133643.sda)
Integration into the SAP System

As of SAP Basis 6.10, information about DBA actions are taken from the new dbahist directory instead of files dbm.knl and dbm.utl (transaction DB13, DB13C, DB12).

The log concept for update statistics actions performed with transaction DB13 as of SAP Basis 6.10 is introduced: The log files of those actions are located in the work directory of the SAP system and named <timestamp>.<fileid> (e.g. 20020716143339.osc) with:

  • timestamp = YYYYMMDDHHMMSS
  • fileid: och = Mark tables requiring statistics update osc = Update all optimizer statistics osr = Update statistics for marked tables

These files can not be read with dbmgetf. The new update statistics logging does not have to be activated with Database Manager CLI.

 back to top

xserver_<host_name>.prt

This is the log file of the TCP/IP listener (global 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 or - in the case of the isolated installation - in the directory  <GlobalDataPath>/wrk.
For information about the remote SQL server (X server, global listener)
see SAP Note 1694323.

back to top

appldiag

This file contains error messages of the SAP MaxDB runtime environment.

There are the following possibilites to activate the writing of appldiag trace:

  • If the environment variable APPLDIAG=<file_name> is set, the trace output will be written to the file <file_name>. Make sure that the user running the process has sufficient access rights. The environment variables DBAPPLDIAG and SQLADIAG are legacy.
  • Using the SQLDBC Trace you can specify the path for the trace output (sqldbc_cons CONFIG TRACE SYSTEM FILENAME <file_name>) and switch the appldiag trace on or off (sqldbc_cons [CONFIG] TRACE SYSTEM ON | OFF).
  • For Microsoft Windows only: There are two registry-entries that can be used to specify and enable the appldiag trace:

    ApplDiagEnabled
         (REG_DWORD)
       <missing value>            Disabled  
       0                                      Disabled 
       1                                      Enabled

    ApplDiagFileName   (REG_SZ)
      <file_name>

The registry path for the entries is: HKEY_USERS\<SID>\Software\SAP\SAP DBTech

If the process is started with current users credentials, use the path: HKEY_CURRENT_USER\SOFTWARE\SAP\SAP DBTech
Keep in mind: The registry path of the process owner is used by the Software.

 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

See also SAP note 2049163 with information about a special error situation in version 7.9.

back to top

lcinit.log/lcinit.his

These files are only written when you use SAP liveCache. File lcinit.log is written whenever you start/stop/initialize the SAP liveCache using liveCache assistant (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 run directory of the database. You can view these files in liveCache assistant (transaction LC10) -> Problem Analysis -> Logs -> Operating.

back to top