Live Caches Supported

Support Guide SAP DB and liveCache
Melanie Handreck (SAP AG)

Christiane Hienger (SAP AG)
Support Guide
SAP DB and
LiveCache
Status: 24. April 2001

Table of Contents
1 GUIDE OBJECTIVES..........................................................................................................1
2 INFORMATION....................................................................................................................1
3 IMPORTANT TOOLS..........................................................................................................1
3.1 XCONTROL..........................................................................................................................1
3.2 DBMGUI, DBMCLI AND WEBDBM...................................................................................1
3.3 XQUERY..............................................................................................................................2
3.4 SQLSTUDIO AND WEBSQL...............................................................................................2
3.5 IREPORT.PY.........................................................................................................................3
3.6 X_CONS..............................................................................................................................3
3.7 X_DIAG(NOSIS)...................................................................................................................3
3.8 XINSTINFO..........................................................................................................................3
4 IMPORTANT ANALYSIS FILES.......................................................................................4
4.1 KNLDIAG, KNLDIAG.OLD AND KNLDIAG.ERR......................................................................4
4.2 DBM.* BZW. CONTROL.*.....................................................................................................6
4.3 KNLTRACE..........................................................................................................................6
4.4 CORE...................................................................................................................................7
4.5 DRWTSN32.LOG.................................................................................................................7
4.6 APPLDIAG...........................................................................................................................7
4.7 LCINIT.LOG UND LCINIT.HIS................................................................................................7
5 DIFFERENT TYPES OF TRACE.......................................................................................9
5.1 VTRACE..............................................................................................................................9
5.2 SQL TRACE......................................................................................................................10
5.3 PRECOMPILER TRACE.......................................................................................................10
5.4 DEVELOPER TRACE..........................................................................................................11
6 IMPORTANT MESSAGE NUMBERS.............................................................................12
6.1 ERROR CATEGORY 1:........................................................................................................12
6.2 ERROR CATEGORY 2:........................................................................................................17
6.3 ERROR CATEGORY 3:........................................................................................................18
6.4 ERROR CATEGORY 4:........................................................................................................19
6.5 MISCELLANEOUS -9XXX ERRORS.....................................................................................20
7 DIRECTORY STRUCTURE.............................................................................................20
7.1 INSTALLATIONS USING DBROOT....................................................................................20
7.2 INSTALLATIONS NOT USING DBROOT............................................................................20
8 PROBLEMS INDEPENDENT OF INSTANCE TYPE...................................................21
8.1 DATABASE CRASH............................................................................................................21
8.2 PROBLEMS WITH DATABASE MIGRATIONS/INSTALLATIONS USING R3SETUP OR
LCSETUP........................................................................................................................23
8.3 PROBLEMS WITH THE SAPDBINSTALL TOOL OR SDBINST TOOL...............................23
8.4 UNINSTALLING.................................................................................................................23
8.4.1 Database software.....................................................................................................23
8.4.2 Database instance.....................................................................................................23
9 PROBLEMS WITH OLTP DATABASES (BC-DB-ADA*)............................................24
9.1 PERFORMANCE PROBLEMS...............................................................................................24

9.2 CONNECTION PROBLEMS..................................................................................................24
10 PROBLEMS WITH THE LIVECACHE (BC-DB-LVC*)............................................24
10.1 ADMINISTRATION...........................................................................................................24
10.2 PERFORMANCE PROBLEMS.............................................................................................25
10.2.1 The Data Cache......................................................................................................25
10.2.2 The Heap.................................................................................................................29
10.3 COM ROUTINE PROBLEMS.............................................................................................29
10.4 PROBLEMS WITH CONNECTION TO LIVECACHE..............................................................30
10.5 HRESULT ERROR..........................................................................................................31
10.6 MEMORY PROBLEMS......................................................................................................32
11 PROBLEMS WITH THE CONTENT SERVER (KM-KW-CDB)...............................32
11.1 LOG MODE......................................................................................................................32
11.2 BACKUP AND RECOVERY...............................................................................................32
12 MAINTENANCE OF XUSER DATA.............................................................................33
13 CONTACTING DEVELOPMENT SUPPORT..............................................................33

I. List of the notes quoted in this guide.................................................................................34
II. List of important transactions..........................................................................................35
1 Guide Objectives
This document is intended as a guide to assist SAP employees in analyzing customer
problems (general database problems). The guide describes the initial steps that should be
taken in the event of standard errors, and provides tips on finding notes. It describes the
errors, and possible analyses for database versions 6.2 (6.2.10 in particular), 7.1, and 7.2.
Database version 6.2 has not been released for the liveCache.
2 Information
For information on the liveCache, and general SAP DB info, access the internet, and go to:
1. BIS: Database Technology -> SAP DB/LiveCache
http://bis.wdf.sap-ag.de:1080/sapdb/
2. The Open Source page
www.sapdb.org
3. The SAP Help Portal
http://help.sap.com
4. The APO Development Support page
http://pal100075.pal.sap-ag.de/
Notes and SAPNet messages can be found and accessed within the following subject areas:
BC-DB-ADA, BC-DB-LVC, KM-KW-CDB, and BW-SYS-DB-ADA.
3 Important Tools
3.1 xcontrol
This tool is the administration tool for version 6.2 databases.
Documentation on this can be found in the SAP Help Portal:
http://help.sap.com
 SAP Library R/3
 SAP Library Release 4.6B
 HTML English or German
 Basis
 Database interface, database platforms (BC-DB)
 R/3 database guide: SAP DB
 R/3 database guide: SAP DB: SAP DB
 R/3 database administration (CONTROL)
Or in
http://help.sap.com/saphelp_46b/helpdata/de/07/ab533628fbac21e10000009b38f889/frameset.htm
3.2 DBMGUI, dbmcli and WebDBM

DBMGUI and dbmcli are the database administration tools as of version 7.2. DBMGUI is a
graphic variant for Windows, but which can also be administered by UNIX databases.
DBMGUI is available via sapserv. For installation information, see note 386714.
A WebDBM is currently in development. The BETA version can be obtained from
www.sapdb.org.
The NI interface can also be used to log onto a customer system using the locally installed
DBMGUI. See note 202344 for further information.
Page 1 of 38
Information on these tools can be found in the SAP Help Portal:

http://help.sap.com
 SAP Library R/3
 SAP Library Release 4.6C
 Basis
 R/3 Database Manager DBMGUI (BC) or
 R/3 Database Manager DBMCLI (BC)
Or,
http://help.sap.com/saphelp_46csr1/helpdata/de/07/ab533628fbac21e10000009b38f889/frameset.htm
Or in www.sapdb.org -> Documentation and
http://www.sapdb.org/sap_db_documentation.htm
3.3 xquery
The xquery tool can be used to execute SQL statements. This tool can only be used for
database version 6.2. Ensure that the function keys are working. Environment variables
DBTERM, and DBHIF can be used to establish this (note 28577). The xvttest tool can be used
to test the function keys.
The most important xquery commands, for when the function keys are not working, are listed
below:
Goto command field: Ctrl-R
Run a command: Run
Return to last screen: End
Goto input field: Enter
3.4 SQLStudio and WebSQL

SQLStudio can be used to execute SQL Statements for databases as of version 7.2. This is a
graphic tool for Windows. However, the tool can also be used to access UNIX databases from
a Windows PC. SQLStudio is available via sapserv. For installation information, see note
386714.
A WebSQL is currently in development. A BETA version can be obtained from the
www.sapdb.org page.
The NI interface can also be used to log onto a customer system using the locally installed
SQLStudio. See note 202344 for further information.
Documentation on these tools can be found in the SAP Help Portal:
http://help.sap.com
 SAP Library R/3
 SAP Library Release 4.6C
 Basis
 SQL Studio (BC)
or
http://help.sap.com/saphelp_46csr1/helpdata/de/07/ab533628fbac21e10000009b38f889/frameset.htm
Page 2 of 38
Or in www.sapdb.org -> Documentation and

http://www.sapdb.org/sap_db_documentation.htm
3.5 ireport.py
This tool is available as of version 7.2.4. It is located in directory <INSTROOT>1/bin. It
must also be accessed in this directory, as additional files are needed from this directory. The
tool is used to execute SQL statements. The following help functions are implemented:
- Information on call options:
ireport.py –h
- Information on possible commands:
ireport.py –d <DB_NAME> -u <sqluser>,<password>
===>help
3.6 x_cons
The x_cons tool is the database console. This tool can be used to monitor the status of the
database and database activities.
Call:
x_cons <DB_NAME> <Command> [<Time>]
All possible commands:
x_cons <DB_NAME>
The <Time> option specifies the amount of seconds that should pass before the command is
executed once more.
This tool can be called without specifying a path.
3.7 x_diag(nosis)
In version 6.2 the x_diag (NT), or x_diagnosis (UNIX) tool is located in the $DBROOT/bin
(UNIX) directory or %DBROOT%\bin (NT) directory and can be called without specifying a
path.
As of version 7.2.4 the tool is located in the <INSTROOT>/bin directory. As this directory is
not in the path, a path must be specified to call the tool.
Other functions are possible if x_diag(nosis) is called with the d <DB_NAME> -u
<controluser>, and <password> options. This guide will indicate if these options need
specifying at the appropriate places.
3.8 xinstinfo
The xinstinfo tool is available as of version 7.2.05 B04, and 7.3.00 B06, to provide all the
important information on a system’s installation directories. It can be called without
specifying a path:
- Call without parameters:
xinstinfo
Example output:
IndepData : /sapdb/IndepData
IndepPrograms : /sapdb/IndepPrograms
- Call with database name:
xinstinfo <DB_NAME>
1
Refer to section 7.2
Page 3 of 38
Example output:
IndepData : /sapdb/Data
IndepPrograms : /sapdb/Programs
InstallationPath : /sapdb/MUT/db
Kernelversion : KERNEL 7.2.5 BUILD 004-000-240-291
Rundirectory : /sapdb/Data/wrk/MUT
4 Important Analysis Files

CSN note 353158 describes which files should be saved by a customer in the event of a
database crash, or more generally, in the event of database problems.
In more recent database versions, the following diagnosis files are saved automatically. These
files therefore do not need to be saved explicitly by the customer:
as of 72.05.00 (NT), 72.05.01 (UNIX), 73.00.05, 74.00.00:
knldiag, knltrace, knldump, rtedump, *.dmp, *.buf, *.stm
as of 74.00.00 (UNIX) also:
core
This function should ensure that important diagnosis files are not lost (or in other words,
overwritten) on a restart after the database has crashed.
If the system recognizes that the database crashed immediately prior to this restart, the files to
be saved are saved in a directory according to the following naming convention:
<DB-NAME>_<DATE>_<TIME>
for example: DB72_20001114_12-09-45
The saved diagnosis files are deleted from the original directory.
The backup directory is located in the DIAG_HISTORY_PATH directory which is to be
configured and from now on will be referred to as the History.
The number of histories can also be configured (DIAG_HISTORY_NUM). If this number (of
histories) is reached, the oldest history will be deleted on a new save.
If a save can not be properly executed, it has no influence on the new restart of the database.
When a database instance is deleted, all histories from the corresponding database are deleted.
If the DIAG_HISTORY_PATH directory is subsequently empty, it will also be removed.
When saving the core files in another file system you must ensure that the file is expanded to
its full size, this means its spatial requirement can be considerable.
Parameter:
- DIAG_HISTORY_NUM:
Value >= 1: no check is made to see whether there is enough space available on the
device for the set value!
Default: 2
- DIAG_HISTORY_PATH:
The path name length can be 64 characters max.
Default: <RUNDIRECTORY>\DIAGHISTORY
4.1 knldiag, knldiag.old and knldiag.err

These files contain database kernel status and error messages.
The knldiag file is the current file. It is recreated with the configured size
(KERNELDIAGSIZE database parameters) during database restart. The file is written to the
database run directory (RUNDIRECTORY database parameter) – unless the file path has been
changed (KERNELDIAGFILE database parameter).
Page 4 of 38
At the beginning of the file, the state of messages relating to the database start is COLD – this
part has a double line separating it from the rest of the file, and is not overwritten. The
following messages from the current operation are then overwritten in cyclic fashion.
Example of knldiag version 6.2.10 on NT:
--------------------------------------------------------------------------------
Date Time TID(hex) Typ MsgID Label Message-Text
--------------------------------------------------------------------------------
10-19 10:01:43 0xFC 50000 TCLUSTER
tw;al;ut;2000*sv;10*ev;ti,100*dw,sn,rc,cs;30000*us;compress
10-19 10:01:43 0xFC 50001 TCLUSTER number of ' DW': 8
10-19 10:01:43 0xFC 50001 TCLUSTER number of ' EV': 0
10-19 10:01:43 0xFC 50001 TCLUSTER number of ' US': 5
10-19 10:01:43 0xFC 50001 TCLUSTER number of ' SV': 13
10-19 10:01:43 0xFC 18313 INFO Starting SERVERDB: 'DEM'
10-19 10:01:43 0xFC 18314 INFO SERVERNODE: 'P33439'
10-19 10:01:43 0xFC 18315 INFO Process ID: 0xe4
10-19 10:01:43 0xFC 18317 INFO Date: 00-10-19
10-19 10:01:43 0xFC 18316 INFO Owner: 'SYSTEM'
10-19 10:01:43 0xFC 18319 INFO Number of Processors: 1
10-19 10:01:43 0xFC 18320 INFO Max virtual memory: 2047 MB
10-19 10:01:43 0xFC 18321 INFO Total physical memory: 159 MB
10-19 10:01:43 0xFC 18322 INFO Available physical memory: 72 MB
10-19 10:01:43 0xFC 18323 INFO Kernel shared memory size: 7 MB
10-19 10:01:43 0x112 18257 TASKING UKT started, TID:0x112
10-19 10:01:43 0x1F1 18257 TASKING UKT started, TID:0x1F1
10-19 10:01:43 0x1FB 18257 TASKING UKT started, TID:0x1FB
10-19 10:01:43 0x144 54003 dynpool NUM DATAWRITER : 8
...
10-19 10:01:43 0x144 54003 DYNPOOL DYNP_B11_FBM_STRUC : 3212
10-19 10:01:43 0x144 18230 VERSION 'KERNEL 6.2.10 Build 025-000-044-836'
10-19 10:01:43 0x144 18230 VERSION 'NT/INTEL 6.2.10 Build 025-000-044-836'
10-19 10:01:43 0x144 54003 dynDATA DYND_K57_KB_PAGES : 11
...
10-19 10:01:44 0x144 53040 I/O DATAWRIT first datacache: 7
10-19 10:01:44 0x112 18245 DEVIO Attaching devspace 'knltrace'
10-19 10:01:46 0x16F 18243 DBSTATE I/O thread for 'knltrace' started
10-19 10:01:46 0x112 54003 dynDATA DYND_B12_VTRACE : 2
10-19 10:01:47 0x1C3 18231 DBSTATE SERVERDB is ready
============================= begin of write cycle =============================
10-19 10:02:26 0x106 18263 CONNECT Connect req. (T7, Node:'', PID:0x1BD)
10-19 10:02:26 0x106 18245 DEVIO Attaching devspace 'SYS_001'
10-19 10:02:26 0x110 18243 DBSTATE I/O thread for 'SYS_001' started
10-19 10:02:26 0x106 18247 DEVIO Single I/O attach, 'SYS_001', UKT:3
10-19 10:02:26 0x106 18246 DEVIO Detaching devspace 'SYS_001'
10-19 10:02:26 0x110 18244 DBSTATE I/O thread for 'SYS_001' stopped
10-19 10:02:26 0x20E 18248 DEVIO Single I/O detach, 'SYS_001', UKT:3
10-19 10:02:26 0x106 18245 DEVIO Attaching devspace 'diskl01'
10-19 10:02:26 0x113 18243 DBSTATE I/O thread for 'diskl01' started
10-19 10:02:26 0x106 18247 DEVIO Single I/O attach, 'diskl01', UKT:3
10-19 10:02:26 0x106 18246 DEVIO Detaching devspace 'diskl01'
10-19 10:02:26 0x113 18244 DBSTATE I/O thread for 'diskl01' stopped
10-19 10:02:26 0x20E 18248 DEVIO Single I/O detach, 'diskl01', UKT:3
10-19 10:02:26 0x106 18282 CONNECT Connection released, T7
10-19 11:28:25 0xFC 18241 DBSTATE SERVERDB is being stopped
10-19 11:28:25 0x112 18247 DEVIO Single I/O attach, 'knltrace', UKT:1
10-19 11:28:26 0x112 18249 TASKING Releasing tracewriter
10-19 11:28:26 0xFC 18320 TASKING Tracewriter termination timeout: 1200 sec
10-19 11:28:26 0xFC 18242 DBSTATE SERVERDB 'DEM' has stopped,
Version: 'KERNEL 6.2.10 Build 025-000-044-836'
---------------------------- current write position ----------------------------
On database restart, the name of the knldiag file is changed to knldiag.old. This means that an
older version of this diagnosis file is always available. If the database is repeatedly started, it
may be that important error messages can no longer be accessed, as the knldiag.old file has
already been overwritten with the current knldiag file on the next restart.
IMPORTANT: These files must therefore be saved after a crash, and before the next restart!
(see paragraph Error: Reference source not found for version dependencies)
Page 5 of 38
The knldiag.err file is not overwritten. All error messages are logged here. If the knldiag and
knldiag.old files no longer contain the error, you will find the error in this file. However, you
only see the original error message, the messages from the error environment are not logged.
New messages are attached to the end of the file. This can cause the file to become very large.
In NT, for every restart from COLD, the message 'Starting' is logged in the knldiag.err. In
UNIX this only occurs as of version 7.2.5.
Example of knldiag.err version 6.2.10 on NT:
09-27 14:41:22 --- Starting ---
09-27 14:43:57 --- Starting ---
09-27 14:43:58 0x175 ERR 55555 FBM BINI: to few fbm pages!
09-27 14:43:58 0x175 ERR 55555 FBM BINI:wanted:3, given:2
09-27 14:43:58 0x175 ERR 18088 DBCRASH Emergency Shutdown
09-27 14:44:09 --- Starting ---
09-27 14:44:09 0x182 ERR 55555 FBM BINI: to few fbm pages!
09-27 14:44:09 0x182 ERR 55555 FBM BINI:wanted:3, given:2
09-27 14:44:09 0x182 ERR 18088 DBCRASH Emergency Shutdown
09-27 14:44:17 --- Starting ---
09-27 14:44:18 0x1B3 ERR 55555 FBM BINI: to few fbm pages!
09-27 14:44:18 0x1B3 ERR 55555 FBM BINI:wanted:3, given:2
09-27 14:44:18 0x1B3 ERR 18088 DBCRASH Emergency Shutdown
09-27 14:48:48 --- Starting ---
09-27 14:48:52 0x1A5 ERR 53007 CONFIG ILLEGAL DATA DEV SIZES
09-27 14:48:52 0x1A5 ERR 53007 CONFIG RestartRec: Max Data Pno: 5999
09-27 14:48:52 0x1A5 ERR 53007 CONFIG XParam: Max Data Pno: 2999
09-27 14:48:52 0x1A5 ERR 18089 DBCRASH Emergency Shutdown, vbd15.c: 5660
09-27 14:51:32 --- Starting ---
10-19 10:01:43 --- Starting ---
Note 393048 describes some of the error messages that can appear in these files. The note is
currently being written.
4.2 dbm.* bzw. control.*

The DBMGUI and dbmcli database administration tools (version 7.x) plus the xcontrol
administration tool (version 6.x), also write log files. These can be found in the database’s run
directory. In the event of problems you should always look in the control.log files, the
dbm.prt files, and the *.utl files for error messages.
File Contents
*.knl Backup history

Administration commands that have been sent to the database
*.utl
kernel, such as save, and restart commands
*.ins The system table load log
Commands that have been sent to the DBM server from the
dbm.prt
DBMCLI or DBMGUI
control.log Log of the actions executed using the xcontrol
dbm.mmm bzw. control.med Definition of the backup media
4.3 knltrace
This file can contain important information on the causes of crashes. It is written in binary
format, and is reinitialized on database restart. It is therefore very important to save this file
Page 6 of 38
after a crash (BEFORE the next attempt at a restart) see paragraph Error: Reference source
not found for version dependencies).
Data will still be written to this file when the VTRACE is switched on.
The file is evaluated using the x_diag(nose) or xkernprot tools (see section 5.1)
4.4 core
During crashes, a core is often written in UNIX containing the stack back trace. This is very
important for problem analysis. The core can only be used for error analysis if it has been
written in full. As the core is written in the run directory of the database, this run directory
must be large enough to include the entire core in the event of an error. The size of the core
depends on the configured cache, as its contents (amongst other things) are written in the
core.
Notes 038037 and 037282 describe how to evaluate this core. The back trace must be made
available to development support (either via sapserv or copy into the message).
4.5 DrWtsn32.log
In NT the stack back trace is logged in the DrWtsn32.log file. For information on how to
evaluate this file, see note 49776.
If Dr.Watson does not appear on a crash, you should check whether note 115059 has been
correctly followed.
4.6 appldiag
UNIX Systems: the appldiag file is stored in the $DBROOT/wrk/<username> directory
(version 6.2) or in the <INDEPDATAPATH>2/wrk/<username> (version 7.2). A specific
file is written for each user (<sid>adm, sqd<sid>, and root).
NT Systems: the file is only written if the environment variable DIAGFILE has been set to
YES. It is stored directly in %DBROOT%\wrk (version 6.2) or <INDEPDATAPATH>/wrk
(version 7.2).
Database runtime environment error messages are logged in this file. Example:
02-26 15:56:49 15480 ERR 11546 XPARAM Could not find xparam file
02-26 15:56:49 15480 ERR 11545 XPARAM Could not open xparam file:
'/sapdb/data/config/S11'
03-26 11:15:25 14961 ERR -11608 COMMUNIC sql03_request: wrong connection
state, state is 'requested'
4.7 lcinit.log und lcinit.his

The lcinit.log file is written for example, when a restart or liveCache initialization is carried
out via transaction LC10. The action that has been carried out is also logged. The file is
written in directory %DBROOT% (NT, versions prior to 7.2.4), or <INDEPDATAPATH>\wrk
(version 7.2.4 and above).
You can display the lcinit.log file:
- at operating system level using an editor,
- via transaction SM49 -> dbmgetf:
-d <LC_NAME> -n <LC-SERVERNAME> -k LCINIT
- via transaction AL11, or
- via transaction LC10 -> Administration -> System messages -> Initialisation Log
Example of an lcinit.log file:
************************************************************
2
refer to 7.2
Page 7 of 38
INIT LIVECACHE lca (INIT)

Tue 03/16/1999
9:25a
************************************************************
SERVERDB: LCA
The database state is WARM

stopping lca
19869 INFO: 'LCA' stopped successfully
starting lca into COLD
19849 INFO: 'LCA' started successfully
starting INIT CONFIG
starting ACTIVATE SERVERDB
loading SYSTEM TABLES
Returncode: 0
liveCache DCOM registration
creating system COM routines
DBPROC 'COPY_AND_REG_DLL' (INPROC) created
DBPROC 'ACTIVATE_DLL' (INPROC) created
DBPROC 'REG_DLL' (INPROC) created
regLCCom ended successfully!

SET MONITOR ON
registration of sapapo.dll
COM-DLL 'L:\ADABAS\LCA\sap\sapapo.dll' successfully registered

registration of sapatp.dll
COM-DLL 'L:\ADABAS\LCA\sap\sapatp.dll' successfully registered

creating COM routines of sapapo.dll
Read Config-File L:\ADABAS\LCA\sap\sapapo.lst :

DBPROC 'SAPAPO_CHANGE_PROP_AREAS' (INPROC) created
DBPROC 'SAPAPO_GET_PROP_AREAS' (INPROC) created
...
DBPROC 'SAPAPO_GET_DRP_AGGREGATE_AMNTS' (INPROC) created
DBPROC 'SAPAPO_GET_DRP_IOS' (INPROC) created

creating COM routines of sapatp.dll
Read Config-File L:\ADABAS\LCA\sap\sapatp.lst :

DBPROC 'SAPATP_CREATE_ANCHOR_OBJECT' (INPROC) created
DBPROC 'SAPATP_DELETE_ANCHOR_OBJECT' (INPROC) created
...
DBPROC 'SAPATP_ALLOC_READ_ALL' (INPROC) created
DBPROC 'SAPATP_ALLOC_GET_ALL_ID' (INPROC) created

writing CHECKPOINT
liveCache lca successfully initialized
The file lcinit.his has the history of all these actions – every lcinit.log is copied into this file.
Like the lcinit.log file, this file is also located in directory %DBROOT% (NT, versions prior to
7.2.4) or <INDEPDATAPATH>\wrk (version 7.2.4 and above).
You can display the lcinit.his file:
- at operating system level using an editor,
- via transaction AL11, or
- via transaction SM49 -> dbmgetf:
-d <LC_NAME> -n <LC-SERVERNAME> -k LCINITHIS
Page 8 of 38
5 Different Types of Trace
5.1 Vtrace
The database kernel can write a trace (Vtrace). Developers use the trace to see which codes
will be run. Options can be used to specify specific modules for tracing.
As Vtrace restricts system performance, it should only be used for analysis purposes. If the
problem has been reproduced the Vtrace must be switched off and flushed. During this
flushing, information is written to the file knltrace from the cache. If flushing is not done, not
all information will be available in the trace.
- Version 6.2:
• Switch on DEFAULT Vtrace:
Tool xcontrol, Menu option Options -> Kernel VTrace -> On
• Switch off DEFAULT Vtrace:
Menu option Options -> Kernel VTrace -> Off
• Flush DEFAULT Vtrace:
Menu option Options -> Kernel VTrace -> Flush
The x_diag(nosis) tool can be used to start special trace variants. These special traces are
not usually required if a developer has not explicitly requested them.
• Call the x_diag(nosis) with the parameters –d <DB-Name> -u <user>,<password>.
• At the prompt, key in ‘diagnosis’
• Switch on: 1: VTRACE ON, then choose the required options
• Switch off: 2: VTRACE OFF
• Flush: 3: VTRACE FLUSH
To evaluate the Vtrace:
• xkernprot –d <SID> akbnx
The readable file <SID>.prt appears in the current directory. The file is analyzed by
the developer responsible.
- Version 7.2:
The Vtrace can be switched on using the DBMGUI: menu option Check -> Kernel Trace.
A choice can be made here whether to switch on only the DEFAULT-Vtrace, or
additional traces. The trace can also be switched on for a specific session, and set up in
such a way that it is switched off immediately after the occurrence of a specific error (the
Advanced tab).
The knltrace file is converted into a readable file via the Protocol tab. The Vtrace must be
'flushed' beforehand (using the button with the red zigzag line – ATTENTION: do not
press the button with the red cross, as this will delete the Vtrace!)
- OLTP environment as of R/3 version 4.6B SP26 or 4.6C:
Transaction DB50 can also be used to switch on the Vtrace:
Problem Analysis -> Kernel Trace
The following can be done:
• Choose trace components
• Switch on trace
• Switch off trace
• Switch on the trace but turn it off automatically when a specific error occurs (switch
off trace when error occurs)
• Flush the trace (duplicate trace buffer)
Page 9 of 38
• Initialize trace
• Format trace and display
• Display trace
5.2 SQL Trace

The SAP system can write a trace containing all the SQL commands sent to the database.
Notes 25099 and 31511 describe how to switch on this SQL trace. The SQL trace is used in
the event of performance problems. It is also used to determine which native SQL statement
within a program is responsible for the error that has occurred.
5.3 Precompiler Trace

The precompiler is the interface between SAP system and database. A trace from this
interface contains the SQL statements (sent by the application to the database kernel), its
parameters and the results.
- Datenbase kernel versions prior to 7.2.5 and precompiler versions prior to 7.2.4:
A parameter in the R/3 instance profile is used to switch on precompiler traces (file
<SID>_DVEBMGS<INSTANCE NR>_<host name> in directory
/usr/sap/<SID>/SYS/profile/). Once the parameter has been set, the R/3 system, or at
least the application server to be switched on for the trace, must be restarted. *.pct files
will then be written to the R/3 system work directory.
The following can be done:
• dbs/ada/sql_trace = 2
detailed trace; the PCT files can be very large, however there is no danger of the
required information being overwritten.
• dbs/ada/sql_trace = <X>
<X>: number larger than 2: alternating trace; X commands will be logged per PCT
file, then the corresponding file will be overwritten. There is no danger of the file
system running at full capacity (if X is not chosen as too large a number), but if the
trace is not switched off early enough or the file is saved, the error may be overwritten
again.
• dbs/ada/sql_trace = 1
short trace – this is not usually used.
To switch off the trace again, the parameters must be deleted or have comments removed,
and the system/application server must be restarted again.
- Database kernel versions as of 7.2.5 or Precompiler versions as of 7.2.4:
As in the earlier versions, precompiler traces can also be switched on by setting the profile
parameter. However you can also use irtrace to switch on the trace WITHOUT needing to
restart the system/application server.
Here, communication is made with the interface runtime via a shared memory segment. If
irtrace is used to make changes to an interface runtime’s trace behavior, an entry will be
made in the shared memory segment corresponding to this. The interface runtime
regularly checks the entries in the shared memory and changes its trace behavior
accordingly. Assignment is made using the process ID. As long as the corresponding
process is active, the entry remains in the shared memory, and can be read.
To use a shared memory segment, a synchronization file must be created. The processes
use this file to access the shared memory. Regardless of release, the file is stored in the
Page 10 of 38
independent data path (<INDEPDATAPATH>/wrk) with the name irtrace.shm. There

must be a wrk subdirectory. Read/write authorization must be available for both irtrace
and the interface runtime.
The tool offers the following trace behavior alteration options:
• Switch trace on/off/over for a specific process:
irtrace –p <process ID> –t <Type of trace>
The following trace types are available here:
• long: a long trace
• short: a short trace, and
• off:switch off trace.
• Switch trace on/off for all interface processes (and we mean all!!!) on the application
server:
irtrace –p all –t <type of trace>
• Display the current interface runtime trace behavior:
irtrace –p <process ID>
• Display an overview of the trace behavior from all interface runtimes for those that
have had irtrace changes:
irtrace –p all
• If irtrace can not find the shared memory due to a faulty installation or other error, the
path can also be specified explicitly (-f <path>). This path however is only valid for
irtrace, the interface runtime is still determined via Environment.
• Provide the entire contents of the shared memory for support purposes:
irtrace -s
- All database versions:

The environment variable SQLOPT can be used to switch on a precompiler trace for the
shell (UNIX) or opened CMD window (NT) that has just been used. This is useful if you
want to find out why, for example, the R3trans can not connect to the database.
To switch on:
• Set the variable to value '-X –F <file name>.pct'. Files containing information
on the cause of the error will then be written in the current directory *.pct.
• Another possible option is '–X –F PID'. With this option, the process ID of the
respective process is included in the file name.
To switch off:
• Reset the variables.
5.4 Developer Trace

The developer trace (dev_w* files) is always written. In trace files you can find information
on work process attempts to connect to the database, for example. You can set different trace
levels for this trace, depending on how much information you want to log.
Procedure (transaction SM66 or SM50):
Page 11 of 38
• select the work process,

• choose menu option Process -> Trace -> Active components,
• choose trace level (0: No trace, 1: Only trace errors, 2: A full trace, or 3. A full trace using
buffers), and
• the components to be traced.
The database, and DBSL components are of particular interest when database problems
are suspected.
For more information on this, see note 16665.
To display the trace information:
As the trace information is written in a readable format in the dev_w* files, you can read this
information by displaying these files. There are various ways of doing this:
• at operating system level using an editor (directory
/usr/sap/<SID>/DVEBMG<SID>/work)
• via transaction AL11 (directory <DIR_HOME>)
• via transaction SM50:
- Select process
- Process -> Trace -> Display file
6 Important Message Numbers

The following chapters describe errors with the numbers 9xxx. These errors can be mapped to
error -602 in the R/3 system log (transaction SM21), and possibly also in a short dump
(transaction ST22). It is important that the correct message number be determined for error
analysis. The specific error hiding behind number -602 is cited in either knldiag or
knldiag.err – there are however also occasional database versions where the knldiag* file
only has error –602 logged.
If it is not possible to clearly identify the error, the problem message should be forwarded to
development support. Please refer to section 13.
6.1 Error category 1:

Category 1 errors affect either basis tables or indexes.
In almost all cases, it is due to a hardware error. After one of these errors has occurred, it is
absolutely necessary to check the hardware (hard disk, and controller).
Message number Error message Analysis + Solution
-9001 e_invalid_root
-9002 e_illegal_branchlength
with index: section 6.1, 4.
-9003 e_illegal_entrylength
step, paragraph I
with table: section 6.1, 4.
-9005 e_illegal_key
step, paragraph III
-9006 e_illegal_keylength
-9008 e_illegal_record
Page 12 of 38
Message number Error message Analysis + Solution
-9010 e_invalid_invlistpos
-9013 e_invalid_index_structure
-9014 e_invalid_leaves_structure
-9018 e_page_in_wrong_tree
-9021 e_no_statistic
-9023 e_illegal_entrypos
-9024 e_invalid_entrypos
-9025 e_illegal_invlistpos
with index: section 6.1, 4.
-9026 e_bad_datapage
step, paragraph I
with table: section 6.1, 4.
-9028 e_bad_file
Step, paragraph II
-9029 e_bad_invfile
-9041 e_file_not_accessible
With index: section 6.1, 4.
Step, paragraph I
-9044 e_inconsistent_nodetype
With table: section 6.1, 4.
Step, paragraph III
-9045 e_root_check
-9053 e_data_page_corrupt
Analysis:
Before the analysis begins, all the files in the run directory must be saved (see paragraph
Error: Reference source not found for version dependencies), as development support may
need them for the analysis.
The analysis tools and files analyze whether it is an object, index, or table error.
1. Step: is there reference to a root page number in the knldiag/knldiag.err?

This reference could look like this:
Example:
10-09 16:56:28 16 ERR 53132 DATACACH Illeg PNO 3951285 PTR 00AEA70000000000
10-09 16:56:28 16 ERR 53000 B*TREE 00000000000000000000000000000000
10-09 16:56:28 16 ERR 53000 B*TREE ROOT 978858
- YES,  there is a comparable entry
Continue troubleshooting from step 2
Page 13 of 38
- NO 
The problem should be forwarded to development support (please refer to section 13).
2. Step: is the database state WARM ?

The database status can be determined using command x_cons <DBNAME> show state or
command dbmcli –d <DBNAME> -u <control user>,<control password> db_state.
- YES  the database state isWARM
Continue troubleshooting with step 3
- NO – the database is OFFLINE or COLD
Start database
Recheck database status (repeat step 2)
-  Starting the database was unsuccessful
All diagnosis files must be resaved (see paragraph 4 for version

dependencies).
Check Knldiag to see if an error can be recognized
Analyze, and remove errors
Start database, and continue with step 3 in WARM
-  the error could not be classified or removed during the start, the database is still
OFFLINE, or COLD
The problem should be forwarded to development support (please refer to section

13).
3. Step: what is the object type?
The roots table can be accessed using the root page number specified in the
knldiag/knldiag.err using xquery, SQLSTUDIO or DBMCLI with the following SELECT:
Example:
SELECT * FROM ROOTS WHERE ROOT = 978858
Result:
TABLEID │ OWNER │ TABLENAME │ INDEXNAME │ TYPE │ ROOT
─────────────────┼───────┼───────────┼────────────┼─────────────┼──────────
00000000000010F5 │ SAPR3 │ TCESYSTT │ TCESYSTT~1 │ NAMED INDEX │ 978858
│ │ │ │ │
Die Spalte TYPE bestimmt den Typ des Datenbankobjektes. Je nachdem, um welchen
Typ es sich bei dem fehlerhaften Objekt handelt, erfolgt die Lösung des Problems.
4. Step: solution
Page 14 of 38
Type : Named Index Solution in I

Type : Table Solution in II and III
Type : Short String Column Solution in IV
I. Solution: NAMED INDEX

As the object with the error is an index, and as this can be reconstructed at any point using
basis table data, the problem can be solved without any help from development support.
The problem is solved like this:
The name of the affected index is specified in the INDEXNAME column.

The name of the table containing the index is specified in the TABLENAME column.
Is the table contained in the R/3 data dictionary (transaction SE11)?
 YES
The affected index can be deleted and recreated using the data dictionary at a time of
minimal workload.
After the index has been successfully deleted and recreated, go to step 5
 NO, the table is not contained in the R/3 data dictionary
Determine the index structure using SQLSTUDIO or xquery:

SELECT * FROM sysodbcindexes WHERE TABLE_NAME = '<tablename>'
Example:
SELECT * FROM sysodbcindexes WHERE TABLE_NAME = 'MSEG'
Result:
INDEX_NAME | TYPE | SEQ_IN_INDEX | COLUMN_NAME
-----------+------+--------------+-------------
MSEG~M | 3 | 1 | MANDT
MSEG~M | 3 | 2 | MATNR
MSEG~M | 3 | 3 | WERKS
MSEG~M | 3 | 4 | LGORT
MSEG~M | 3 | 5 | BWART
MSEG~M | 3 | 6 | SOBKZ
MSEG~R | 3 | 1 | MANDT
MSEG~R | 3 | 2 | RSNUM
MSEG~S | 3 | 1 | SMBLN
MSEG~S | 3 | 2 | SJAHR
MSEG~S | 3 | 3 | SMBLP
Note down the results as the index structure is needed later for recreating the index.
Page 15 of 38
The index is deleted and recreated with the SQLSTUDIO, or xquery database tool.
To delete the index using SQLSTUDIO or xquery:
Command: DROP Index <Indexname>on <tablename>

Example: Drop Index "MSEG~R" on MSEG
To create the index:
Command: Create index <indexname> on <tablename> ( <column>,

<column>.....)
Example: CREATE INDEX "MSEG~R" on MSEG (MANDT, RSNUM)
After the index has been successfully deleted and recreated, go to step 5
II. Solution: Table, exceptional cases -9026, and -9028:
If one of these two errors has occurred in a table, you can try to remove the error using the
CHECK TABLE command. The Check Table command can be executed via the database
tools xquery, or SQLSTUDIO.
Command: check table <tablename>

Example: check table MSEG
- If Check Table command runs to the end with no errors -> Go to step 5
- If the Check Table terminates due to a new error -> Go to III.
III.Solution: Table for all other category 1 errors
If the object with an error is a table, the table data will be lost. There are two ways of
solving this problem depending on whether:
a) the table contains data that can be generated from another table, or
b) the table contains data that can not be reconstructed from another table
Application development must be consulted to decide which of the above is true. The
individual responsible for the table should be found as quickly as possible. This
individual will then be able to decide whether data can be generated (case a).
- If data can be generated, there are application development instructions describing the
procedure to follow. Then go to step 5.
- If data can not be generated, a recovery must be made of the entire database.
- If no reply is received, a database recovery must be made.
IV. Solution: Short String Column

If the object with an error is a BLOB short column, the BLOB data will be destroyed.
There are two ways of solving this problem depending on whether:
a) the table belonging to the BLOB contains data that can be generated
b) the table belonging to the BLOB does not contain data that can be generated
Page 16 of 38
Deciding which of the above is true for the affected table can only be done with the help
of application development. The individual in application responsible for the table ( - the
individual who is able to decide whether data can be generated - case a)) should be found
as quickly as possible.
- If data can be generated, there are application development instructions describing the
procedure to follow. Then go to step 5.
- If data can not be generated, a recovery must be made of the entire database.
- If no reply is received, a database recovery must be made.
5. Step: Follow up
After removing the errors, you should use the system to verify that there are no other
problems in the system. When the database state is WARM, this can be done using
transaction DB13 (check database structure (all objects). If this action is not available,
verification must be made using the xcontrol tool (Backup -> Save -> Verify Devspaces),
or the DBMGUI tool (Check -> Database).
The system can only be released again for R/3 operation after verification has
completed successfully.

All category 2 errors are problems that may no longer occur once the database has been
restarted.
Number Error message Analysis + Solution
-9004 e_illegal_filename
-9007 e_illegal_page_no
Can error be reproduced after
-9050 e_illegal_page_address DB restart?
 Generate Vtrace
-9051 e_invalid_fbm_mark  Forward problem to
development support
-9052 e_multiple_converter_entry
-9111 e_move_error
Analysis:
Before the analysis begins, all the files in the run directory must be saved (see paragraph 4 for
version dependencies), as development support may need them for the analysis.
1. Step: What action has the error triggered?

In the first step of the analysis, the problem’s initiating object must be determined. This
trigger will be needed later to determine whether attempts to solve the problem have been
successful. The following R/3 analysis tools can be used for this:
- Transaction SM21: System log

Checking the system log (on all application servers) from the time the error occurred
can point to the problem message trigger.
Page 17 of 38
Example:
11:23:50 DIA 9 000 TEST /SAP BY2 Datenbankfehler -602 has occurred
11:23:50 DIA 9 000 Laufzeitfehler ".................." has occurred.
> short dump "010322 111907 pwdf0221 TEST " created.
A category 2 error may also be stored here as a –602 error.
- Transaction ST22: ABAP short dumps

If there is an ABAP short dump, the trigger of the problem is declared.
Example:
Termination point information
The termination occurred in ABAP program "/SAPAPO/SAPLOM_PLANNING ",
in "/SAPAPO/OM_ORDER_CHANGE".
The main program was "/SAPAPO/SAPRRP_PT_ENTRY ".
2. Step : Stopping and starting the database

- The database or liveCache is stopped.
- Then the database or liveCache is restarted.
- The database was started successfully -> go to step 3
- The database state can not be returned to WARM -> forward problem message to
development support (see section 13).
3. Step: Reproducing the problem
An attempt is made to reproduce the problem using the trigger identified in step 1.
- No –  the error could not be reproduced

 Problem closed
- Yes -  the error occurred again
Reproduce the problem using Vtrace that has been switched on

The problem should be forwarded to development support (please refer to section
13).

A recovery must be made for Category 3 errors.
-9020 e_init_missing
-9027 e_bad_fdir
-9033 e_bad_syspage Recovery
-9034 e_bad_usmpage
-9046 e_no_converter_entry
Page 18 of 38
EXCEPTION:
Error –9046 can occur in the liveCache environment, if an ‘Init liveCache’ is terminated and a
restart then attempted. This can be checked using file lcinit.his. The liveCache must then be
reinitialized.

Category 4 errors usually point to an inconsistency at the log device.
-9030 e_bad_logpage
Restore devspace
-9209 e_log_error
Analysis:
1. Step: which log mode has been configured by the customer?

The log configuration can be determined as follows:
1. Version 6.2:
xcontrol -> Info -> Configuration
or UNIX:
$DBROOT/pgm/getparam <DB_NAME> LOG_MODE
bzw. NT:
getparam <DB_NAME> LOG_MODE
2. Version 7.2:
DBMGUI -> Information -> Log
or
dbmcli –d <DB_NAME> -u <dba_user>,<password> param_directget LOG_MODE
2. Step: troubleshooting
a) Log mode SINGLE:
In SINGLE log mode there is no mirrored log at database level. A restore Devspace can
not be made with this configuration.
Using RAID:
If the customer is using a RAID system to mirror the log, the log errors must be cleared
using RAID administration.
No mirroring of the log device:
Note: this should not occur in live operations.
In this instance, a recovery can only be made using existing backups. As yet unsaved data
is lost.
b) Log mode DUAL:

In DUAL log mode the second (mirrored) log device can be used to copy the log-
devspace with the error. A recovery does not have to be executed. Note 116044 (version
6.2) describes the procedure. In version 7.2, the DBMGUI is used for this. Note 330525
provides the menu path.
Page 19 of 38
6.5 Miscellaneous -9xxx errors

If errors occur with the number -9xxx, and they can not be assigned to any of the previous
categories mentioned, the problem should be forwarded to development support immediately
(please refer to section 13).
7 Directory Structure
For documentation on directory structure, go to the internet site;
http://www.sapdb.org/solutions/technology/sapdb/pdf/directorydistrib_72eng.pdf
(www.sapdb.org -> Documentation -> Distribution of the SAP DB Directories). This chapter
is intended to provide a brief overview.
7.1 Installations using DBROOT

In versions prior to 7.2.4, database software is installed in the DBROOT directory. The
RUNDIRECTORY is usually found in directory $DBROOT/wrk/<DB_NAME> (UNIX) or
%DBROOT%\wrk\<DB_NAME> (NT).
7.2 Installations not using DBROOT

As of version 7.2.4 Build 4, the environment variable DBROOT no longer exists. This new
structure (not using DBROOT) makes it possible to operate several databases on the same
application server with different versions. This is not recommended in live system
environments however, due to its influence on performance (an exception to this is the 64bit
UNIX).
See notes 0336470 and 327578 for further information
Definition of new terms:

• INSTROOT:
Version-dependent database software can be found in the INSTROOT directory. The
following dbmcli command is used to determine whereabouts the INSTROOT directory is
at the customer:
dbmcli –d <DBNAME> db_enum
Example:
dbmcli –d E20 db_enum
Result:
OK
E20 /sapdb/E20/db 7.2.4.0 fast running
E20 /sapdb/E20/db 7.2.4.0 slow offline
In this Unix system the INSTROOT directory is in /sapdb/E20/db
• INDEPDATAPATH:
Version-independent data (such as the RUNDIRECTORY) is located in the directory called
INDEPDATAPATH (Independent Data Path). The following dbmcli command can be used
to determine which directory has been defined as INDEPDATAPATH at the customer:
dbmcli –d <DBNAME> -u <controluser,controlpasswort> dbm_getpath INDEPDATAPATH
Example:
dbmcli –d E20 –u control,control dbm_getpath INDEPDATAPATH
Result:
OK
/sapdb/data
Page 20 of 38
In this Unix system the IndepDataPath directory is in /sapdb/data.
• INDEPPROGPATH:
Version-independent database programs are located in the directory called
INDEPPROGPATH (Independent Program Path). The following dbmcli command can be
used to determine which directory has been defined as INDEPPROGPATH at the
customer:
dbmcli –d <DBNAME> -u <controluser,controlpasswort> dbm_getpath INDEPPROGPATH
Example:
dbmcli –d E20 –u control,control dbm_getpath INDEPPROGPATH
Result:
OK
/sapdb/programs
In this Unix system the IndepProgPath directory is in /sapdb/programs.
How must the path variable be set?

• Versions 6.2, 7.1, 7.2.2, 7.2.3 and 7.2.4 prior to B15:
NT: %DBROOT%\bin, %DBROOT%\sap, and %DBROOT%\pgm
UNIX: $DBROOT/bin, $DBROOT/sap
The variable DBROOT has been set. In versions 7.2.4 B4 to 7.2.4 B14 the variable
DBROOT is still required to call programs from the CCMS.
• As of version 7.2.4 build 15:
NT: <INDEPPROGPATH>\bin and <INDEPPROGPATH>\pgm
UNIX: <INDEPPROGPATH>/bin
The variable DBROOT has not been set.
Notes: 327578, 336470, and 383098
8 Problems Independent of Instance Type
8.1 Database crash

For analysis purposes, the files mentioned in note 353158 should be saved immediately before
the first restart attempt after the crash (see paragraph Error: Reference source not found for
version dependencies).
The stack back trace on the crash can be found in the core (UNIX), or in the DrWtsn32.log
(NT). In NT if no DrWtsn32.log has been written, the function with the error can also be
determined as follows:
• If the crash was caused by an exception, a message will appear in the knldiag file or the
knldiag.err file similar to the one below.
EXCEPT EXCEPTION:0xc0000005 Addr:0x57fe7d ( 0:0x1529cd4c:0:0 )
• The MAPFILES from the respective database state can be found in the directory
%DBROOT%\support\mapfiles (version 6.2), or <INSTROOT>\support\mapfiles
(version 7.2). The crash address is usually a function from the kernel.map file:
kernel
Timestamp is 3829a5c3 (Wed Nov 10 18:05:07 1999)
Preferred load address is 00400000
Page 21 of 38
Start Length Name Class

0001:00000000 00342810H .text CODE
0002:00000000 00000139H CODE32 CODE
0003:00000000 00001378H .rdata DATA
0003:00001378 00000000H .edata DATA
0004:00000000 00000004H .CRT$XCA DATA
0004:00000004 00000004H .CRT$XCZ DATA
0004:00000008 00000004H .CRT$XIA DATA
0004:0000000c 00000008H .CRT$XIC DATA
0004:00000014 00000004H .CRT$XIZ DATA
0004:00000018 00000004H .CRT$XPA DATA
0004:0000001c 00000004H .CRT$XPX DATA
0004:00000020 00000004H .CRT$XPZ DATA
0004:00000024 00000004H .CRT$XTA DATA
0004:00000028 00000004H .CRT$XTZ DATA
0004:00000030 000507f9H .data DATA
0004:00050830 000315a0H .bss DATA
0005:00000000 00000064H .idata$2 DATA
0005:00000064 00000014H .idata$3 DATA
0005:00000078 00000318H .idata$4 DATA
0005:00000390 00000318H .idata$5 DATA
0005:000006a8 00000db4H .idata$6 DATA
0006:00000000 00000400H .rsrc$01 DATA
0006:00000400 000019a4H .rsrc$02 DATA
Address Publics by Value Rva+Base Lib:Object
0001:00000000 _sql80k_NewSrvState 00412000 f vos80kc.o

0001:00000130 _sql80k_CtrlHandler@4 00412130 f vos80kc.o
0001:00000200 _sql80k_ServiceMain@8 00412200 f vos80kc.o
0001:00000350 _WinMain@16 00412350 f vos80kc.o
0001:000004b0 _sql80kn_main 004124b0 f vos80knc.o
0001:000005b0 _sql80kn_write_msg 004125b0 f vos80knc.o
0001:000006f0 _sql80kn_set_db_state 004126f0 f vos80knc.o
0001:000007b0 _sql80kn_dlg_proc@16 004127b0 f vos80knc.o
0001:00001820 _ak91set_copyright 00413820 f vak91.o
0001:00001880 _ak91connect 00413880 f vak91.o
0001:00001a80 _ak91free_mem 00413a80 f vak91.o
0001:00001b40 _ak91init_acv 00413b40 f vak91.o
...
0001:0016b340 _a720prepare_two_qual 0057d340 f ak4lib:vak720.o
0001:0016bf10 _a720qual_eval_check 0057df10 f ak4lib:vak720.o
0001:0016c060 _a720trace_eval 0057e060 f ak4lib:vak720.o
0001:0016c180 _a720glob_init_eval_stat 0057e180 f ak4lib:vak720.o
0001:0016c360 _ak70all_ands 0057e360 f ak4lib:vak70.o
0001:0016c8b0 _ak70analyze_condition 0057e8b0 f ak4lib:vak70.o
0001:0016d2c0 _ak70build_allo 0057f2c0 f ak4lib:vak70.o
0001:0016d610 _ak70check_level 0057f610 f ak4lib:vak70.o
0001:0016db80 _ak70one_and 0057fb80 f ak4lib:vak70.o
0001:0016e100 _ak70or_qual 00580100 f ak4lib:vak70.o
0001:0016e3f0 _ak70order_multi 005803f0 f ak4lib:vak70.o
0001:0016ed10 _ak70_test_order_multi 00580d10 f ak4lib:vak70.o
0001:0016f120 _ak70qual_evaluation_rec 00581120 f ak4lib:vak70.o
0001:0016f730 _ak70skip_stack_entries 00581730 f ak4lib:vak70.o
0001:0016f8a0 _ak70more_index_strat 005818a0 f ak4lib:vak70.o
0001:00170160 _ak70only_index_strat 00582160 f ak4lib:vak70.o
0001:001726d0 _ak70expl_inv 005846d0 f ak4lib:vak70.o
...
• You can search for the address in this file. It should be noted that the exact address can
seldom be found. The address in the map file is the start address of a function, however
the crash happens during a function.
You should always look for the first digits of the address. In this example you should
search for 57f. The address is found in the column after the function name. The function
looked for is the one with the address directly smaller than the crash address – in this
example, it is the function _ak70one_and.
• You must always search within the map file of the corresponding database patch (exact
version including build number). In another patch, the function looked for may be at
another address.
Page 22 of 38
8.2 Problems with database migrations/installations using R3Setup or LCSETUP

The customer can freely specify the installation directory for storing the log files. The
INSTDIR is the easiest to find when looking for the XCMDOUT.LOG file.
The <TEMPLATE>3.log file has information on the migration tool termination point. Both
the phase where the error occurred, and the error type are logged here.
The XCMDOUT.LOG file also contains information on the error , if it occurred during
execution of a database tool (for example, during command 'dbmcli –d <DB-Name> -u
<user>,<password> db_state').
If it is a database problem, there are additional notes on causes in the section 2 analysis files.
All the migration/installation phases are listed in alphabetical order in the <TEMPLATE>.tpl
file, or <TEMPLATE>.r3s file. STATUS=ERROR indicates the phase where the error
occurred. For example, you can see here which options should be used to execute which
command.
8.3 Problems with the SAPDBINSTALL tool or SDBINST tool

The tool provides lots of useful information at the command prompt (or in the UNIX shell). If
this information is not sufficient, you can search for the cause of the error in the tool log,
'SAPDB*<date><time>.LOG'. It can be found in the <INDEPDATAPATH>/wrk directory.
Installing an SAP DB patch using the SAPDBINSTALL tool or SDBINST tool (as of version
7.2.4 B15), often leads to DLL overwriting problems in NT. The x_server has often not been
stopped. The task manager can be used to check this, for example.
Note 386571 also gives tips on how to find out why the faulty DLL can not be overwritten.
8.4 Uninstalling
8.4.1 Database software

There is currently no tool that can uninstall the database software. This can cause problems if
there SAP DB software already exists on an application server, and the system needs to be
reconfigured, with the database software needing to be installed in another directory. The
SDBINST tool will not authorize an independent path different to the already existing one to
be specified.
Until there is an uninstall tool, forward all such problems to development support. They will
then uninstall manually.
8.4.2 Database instance

Database instances can be uninstalled.
• Version 6.2:
Tool xcontrol, menu option Configuration -> Clear Serverdb
The database state must be OFFLINE.
• Version 7.2:
Tool DBMGUI, menu option Instance -> Drop
Or tool dbmcli, command
dbmcli –d <DB_NAME> -u <controluser>,<password> db_drop [WITHOUTFILES]
The database state must be OFFLINE here too.
3
such as the DBUPDATE.log or LCINST.log
Page 23 of 38
9 Problems with OLTP Databases (BC-DB-ADA*)
9.1 Performance problems

• Performance problems when executing special transactions:
An SQL trace (see section 5.2) should be created for this/these transaction(s). The SQL
trace can be used to look for database commands running over a long period of time.
- Explain outputs,
- Information on the executed statement,
- Information on basic tables/views, and
- Optimizer statistics
All of the above can be used to decide whether an additional index would accelerate
processing. Indexes should only be created here after consulting with the TCC, or
development support.
• general performance problems:
- Transaction ST04 (the transaction description is in CCMS documentation):
The Cache hit rates should first be checked:
the DATA CACHE HITRATE should amount to 99% at least,
the CONVERTER CACHE HITRATE 100%.
- XWIZARD:
This tool can provide additional information on causes of performance problems. It
can be started and evaluated from transaction ST04 -> Detail Analysis Menu ->
Bottleneck Analysis.
- DB Analyzer:
A BETA version of the tool will soon be available that is to replace the xwizard tool
function as of version 7.3.
- Diagnosis monitor:
This tool records all the long-running/non-selective statements. It can also be switched
on from transaction ST04 (Detail Analysis Menu -> Diagnois monitor).
ATTENTION: if a version 7.x precompiler is used in versions 6.2.10 prior to B29, the
Diagnosis Monitor can cause the database to crash. Do NOT switch on here!
9.2 Connection problems

If there are problems with the R/3 system’s connection to the database, the DEV log should
definitely be checked (the dev_w* files from the R/3 system work directory). If the
information found there is not sufficient for troubleshooting, testing the following tool (if
necessary with precompiler trace via SQLOPT - see section 5.3) should be useful:
- R3trans –d
- tp connect <DB_NAME> [<TPPARAM file>]
XUSER data should also be checked. For information on this, see note 39439.
10 Problems with the liveCache (BC-DB-LVC*)
10.1 Administration
liveCache administration documents are available on the internet:
http://pal100075.pal.sap-ag.de/ -> liveCache -> Functionality -> LC Administration
There is also a document on liveCache recovery:
Page 24 of 38
http://pal100075.pal.sap-ag.de/ -> liveCache -> Technical Tips & Tricks -> APO 3.0 Backup
& Recovery
10.2 Performance problems

Performance analysis tips are available on the internet:
http://pal100075.pal.sap-ag.de/ -> liveCache -> Technical Tips & Tricks -> LC Workshop
The following performance analysis information has been taken from a document written by
Jochen Hartmann.
As its name suggests, the liveCache is based upon the term Cache, or in other words, data
stored in the main memory of an application server. The liveCache provides the COM
routines with functions4 that enable very large quantities of data to be worked with very
quickly. The desired performance however is only achieved when the data is actually located
in the main memory of the liveCache server, and does not have to be read from hard disks. If
the liveCache constantly has to load data from disks, its performance is quickly reduced to
that of a normal database. Therefore every liveCache performance analysis should always
begin with a memory management analysis.
The liveCache manages data in two areas – in the Data Cache and at the Heap. The
adjustment of both memory areas to the scope of data to be managed, the number of users
working parallel to one another, and to the operating system, and hardware restrictions, is
critical to the stability and performance of the APO applications.
Not all the data required for a performance analysis can be found in transaction LC10. It is
therefore more usual to have to access liveCache system tables directly. The best way of
doing this is to use SQLStudio (see section 3.4). It can be installed on every Windows PC
independently of the liveCache.
The CLASSCONTAINERS system table documentation will (shortly) be available on the
internet: http://pal100075.pal.sap-ag.de/
Other tables are described below.
10.2.1 The Data Cache

The Data Cache contains global data from the APO system. Its size is determined via the
liveCache parameter DATA_CACHE. This global memory area is created with the configured
size when the liveCache is started. This size remains constant until the liveCache is stopped.
If the Data Cache is not large enough to include all data, the data is read by the hard disks,
and stored there.
4
Classes and methods to be exact
Page 25 of 38
The most important data regarding the global Data Cache capacity being used can be seen in
the LC10 main screen (liveCache hit rates) by pushing the ‘liveCache performance’ button.
UNIX, Windows NT without PSE36, Windows 2000 without AWE

In a stable system, both the OMS data cache, and Converter Cache should always amount to
100%. Smaller values indicate that disks will have to be accessed physically. The refresh
button should be pressed several times, to monitor whether the number of Read Accesses
changes.
Windows NT with PSE36, Windows 2000 with AWE (note 398665)

Restricting Windows systems to a 32Bit address space, and therefore to a memory of approx.
3 gigabytes usable by liveCache, has serious consequences for APO applications. Experience
shows that a 3 gigabyte memory is insufficient for the large number of APO live systems. The
liveCache therefore provides extended memories (PSE36 in Windows NT, AWE in Windows
2000, see note 384680). Depending on the version of Windows, they will achieve a usable
memory of between 8 and 64 gigabytes, provided that users are equipped with the appropriate
hardware. In this current liveCache implementation stage however, the extended memory can
not be used directly for the Data Cache. To put in simplistic terms, an additional memory has
been implemented instead as a kind of RAM disk. If data can not be found in the data cache, it
will first be searched for in the AWE, or PSE36 memory area, before hard disks are accessed.
An extended memory can be accessed much faster than a physical storage medium.
When PSE36 or AWE are used, the Data Cache hit rate is not suitable for assessing a
sufficiently large memory. Data that is not in the Data Cache, but is found in the AWE or
PSE36 area of the liveCache, is displayed in LC10 as ‘Read accesses’ although no disks are
accessed. Because of this, a Data Cache hit rate of below 100% does not necessarily indicate
that the available memory is insufficient. The disks will only need to actually be read if the
data does not exist in the PSE36/AWE area. This should be avoided at all costs. It may be
necessary to provide additional backup for the liveCache server, if the Windows version used
will allow it (see note 313347).
Page 26 of 38
The dbmcli command show pse_status determines whether or not the extended memory is too
small. This command is either executed at operating system level or from transaction SM49. If
both the ‘writes out of range’, and ‘reads out of range’ values stand at zero, it can be assumed
that the extended memory is sufficiently large. As of APO version 3.0, this information can be
displayed via transaction LC10 -> liveCache Console.
All systems
Cache capacity details can be displayed by pressing the ‘Data Cache’ button (in APO 2.0, in
the ‘liveCache detail analysis’ area). The actual user data consist primarily of OMS data, and
partly of SQL data.
All APO liveCache application data is stored in OMS pages as persistent objects. These 8KB
file pages are linked together and assigned to class containers. See ‘OMS data’ for the
number of pages located in the cache.
Information is also saved from the liveCache in B*-Tree format. Objects saved in this format
are liveCache system tables, some SQL tables required by APO, indexes on persistent objects
(simplified model), and versions stored because of memory shortage. The term ‘SQL data’ is
used to refer to all the data in B*-Trees.
The Data Cache should consist mainly of ‘OMS data’, followed by ‘OMS history’, and ‘SQL
data’. The changed data is saved in the History5 and will later be deleted by Garbage
collectors. This temporary storage of changed data is necessary as the liveCache is observes
the consistent view concept. This means that an APO application always wants to see the data,
as it was at the start of the application6 – regardless of whether the data has been changed by
another application in the mean time. The origin data must therefore be kept until no more
applications need to access it. The history consists of this (in effect) obsolete data. A high
‘OMS history’ percentage in the data cache (data cache usage) can indicate application
problems, and must be investigated.
5
For those familiar with Oracle: History corresponds approximately to the rollback segments in Oracle
6
at transaction start or at the start of a transactional simulation to be exact
Page 27 of 38
The ‘used data cache’ is a good indicator of whether the data cache is large enough as it
shows what capacity of the data cache is being used. If this value remains below 100% for a
long time, you can assume that the data cache is large enough. Single observation on the other
hand is not sufficient. Releasing the history data causes lots of space to be created in the data
cache. However this is quickly refilled with subsequent data.
You can get an approximate idea of how much application data is currently available in the
system via the command SELECT SUM(PAGECOUNT + KEY_LEAF_PAGES)FROM

CLASSCONTAINERS that must be executed on the liveCache using SqlStudio. You are then
told the number of pages containing application data (this is provided in the document for the
class container table). If this value falls well below the available cache (data cache, and if
necessary PSE36/AWE), you can assume that the dimensioning is sufficient.
List of the most important Data Cache indicators

Windows with no extended memory and UNIX
Sufficient data cache can be assumed if:
• the ‘Used data cache’ is below100%, and
• the hit rate is 100%, according to the ‘OMS data cache’.
An even better indication of this is if the read access count to the disk is smaller than the data
cache size (in pages):
• Read accesses: SELECT USERTASKREADCNT FROM SYSMON_TOTALCOUNT
• Read accesses smaller than the ‘data cache size’ in pages
Windows with extended memory
A good indication that the entire cache (data cache + extended memory) has sufficient
dimensions is if the read access count to the disk is smaller than the sum of the data cache
plus the extended memory
• Read accesses: SELECT USERTASKREADCNT FROM SYSMON_TOTALCOUNT
• Read accesses smaller than the ‘data cache size’ in pages + usable extended memory
in pages
The command
Page 28 of 38
dbmcli –u control,control –d <LCNAME> -n <LCHOST> show pse_status

should still show zero for both ‘reads out of range’, and ‘writes out of range’.
When using AWE, or PSE36 an attempt should be made to keep all the liveCache data in the
main memory at all costs. If necessary additional extended memories should be used to
support the hardware.
10.2.2 The Heap

If data is read by a COM routine for the first time, this data will be copied from the data cache
to the liveCache heap7. All additional operations will then only take place on these copies.
Data changes will only be written back to the data cache, and the memory space released to
the liveCache heap at the end of a transaction8. The physical memory is not released here. One
of the reasons for introducing the heap is to provide further improvement in performance.
Data in the data cache can be accessed by all applications, and suitable methods (semaphores)
must be used to protect against changes being made in at the same time. This protection
however is unnecessary if the data has been assigned to a specific APO application after it has
been copied to the heap. The internal liveCache access strategy is speeded up during data
access, if data is managed in the private heap area. These optimizations mean that overall, a
heap access is between two and five times faster than a data cache access.
Configuration of the heap
At liveCache start, the size of the heap is not fixed, in contrast to that of the data cache. The
heap grows dynamically if the existing one is not large enough to include more data copies. A
maximum heap size value can be set via liveCache parameter OMS_HEAP_LIMIT. When
OMS_HEAP_LIMIT=0 the heap can theoretically grow at an unlimited rate, until either the
operating system address space (Windows operating systems), or the entire physical memory
(main memory + swap) has been used up. A limit should therefore be set at all costs, or even
preset (see note 337445).
The heap can not use Windows extended memories (PSE36/AWE).
Problems observed in the heap environment up to this point have usually been caused by
COM routines terminations on reaching the maximum heap value.
10.3 COM routine problems

Symptom: Error -4016
Various transactions in APO terminate with error ‘–4016: unknown procedure’. You can see
which procedures could not be found in the short dumps for these errors (transaction ST22).
Analysis: the log from the last initialization/restart can be viewed in transaction LC10 ->
Administration -> System messages -> Initialization Log. A COM object list should be
located here. There should also be a sapapo.dll file in the sap subdirectory of the liveCache
installation directory. If no such file exists, the COM objects have not been imported correctly
for the liveCache.
In transaction /SAPAPO/OM04 (APO 3.0) you can see the change list number of the most
recently imported SAPAPO COM Object Build (note 326494).
The following are notes on COM Objects:
- 157265: exchanging COM objects for liveCache in APO 3.0
- 324871: SAPAPO 2.0 How to install a new COM object build
7
Babylon translation: free area in memory, available for important system resources
8
or more exactly: during commit, transactional simulations also copy data to the heap but the data is not then
stored in the data cache after the transactional simulation is complete. This means that changes in transactional
simulations are not persistent.
Page 29 of 38
- 315758: List of SAPAPO COM object builds for APO 2.0

- 326494: List of SAPAPO COM object builds for APO 3.0
10.4 Problems with connection to liveCache

Symptom: Symptom: liveCache administration (transaction LC10) results in DBMCLI
errors.
Background information: in order to administer the liveCache using transaction LC10, user
and password must be stored on the APO application server (in both APO 2.0 and APO 3.0).
If stored entries are incorrect or missing, the tool dbmcli can not connect to the liveCache
server. Administration will not be possible.
Analysis: execute report RSLVCMON06, as described in note 332075. This report reads the
information required by support from the APO system, and creates a list of this information.
This list should be given to support.
Example: RSLVCMON06 list, where there is a recognizable error:
08.03.2001 Display important liveCache connection information 1
------------------------------------------------------------------------
1. DBCON table entries:
------------------------------------------------------------------------
Connection name Connection information
LCA pwdf0221-LCA
LDA pwdf0221-LCA
------------------------------------------------------------------------
2. DBCONUSR table entries:
------------------------------------------------------------------------
The table does not exist.
------------------------------------------------------------------------
3. LCINIT table entries:
------------------------------------------------------------------------
Connection name Report name Variant name INIT Start Stop
PB PA PB PA PB PA
LCA /SAPAPO/DELETE_LC_ANCHORS X
------------------------------------------------------------------------
4. Created XUSER entries:
------------------------------------------------------------------------
Server: pwdf0236_AP3_21
Key User
DEFAULT SAPR3
1LCAPWDF0221 CONTROL
------------------------------------------------------------------------
5. DBMCLI Client Version:
------------------------------------------------------------------------
Server: pwdf0236_AP3_21
VERSION = 7.2.3
BUILD = DBMServer 7.2.3 Build 006-000-198-647
OS = WIN32
INSTROOT = D:\usr\sap\AP3\SYS\livecache
LOGON = True
CODE = ASCII
SWAP = full
------------------------------------------------------------------------
Analysis:
In 1., the entries are displayed in the table DBCON. The liveCache Server pwdf0221, and
physical liveCache name LCA are specified in the logic liveCache connection names LCA and
LDA. If there are no entries for LCA, and LDA in 1, they must be entered using transaction
LC10, (see note 136153).
If you now look at point 4, you will see that the Xuser entries for the dbmcli tool are stored
here. In addition to the DEFAULT entry there must be an entry stating the control user. If
there is no such entry, it can be fetched using transaction SM49, choosing the dbmcli
command like this:
-d <phys. LC> -n <lc-Server> -us <controluser, controlpassword>
Example: -d LCA –n pwdf0221 –us control,control
Page 30 of 38
Xuser entries are case sensitive. In the above example, an error was made during creation of
the Xuser Control User entry, as the liveCache server name must be specified in capitals, in
contrast to the entry in the DBCON table (see 1.). This would also cause a dbmcli error. To
solve this problem, an additional entry must be made for the control user, as described above.
The incorrect entry can be deleted in transaction SM49 as follows:
-d <phys. LC> -n <incorrect lc_servername> -ud -ux SAPR3,SAP
Example: -d LCA –n PWDF0221 –ud –ux SAPR3,SAP
10.5 HRESULT error

When problems occur in the liveCache environment during system table load, they are often
DCOM-HRESULT errors. These errors are logged in the knldiag, and knldiag.err files:
05-04 09:20:29 0x158 ERR 18262 DCOM CoGetClassObject - HRESULT: -2147221164, Context:
INPROC
05-04 09:20:29 0x158 ERR 18263 DCOM COCLSID: {FC2F8866-6983-11D2-A97F-00A0C94311A5}
05-04 09:20:29 0x158 ERR 51260 HRESULT 80040154
The cause of these errors is usually the fact that the file dbpinstall was incorrectly registered.
To determine the meaning of the error do this (if you have MS Developer Studio installed):
- Select menu option Tools -> Error Lookup
- Enter the HRESULT number (for example, 0x80040154)
- Press the Look Up button:
- In this example, the message number signifies that one of the classes has not been
registered, which means for example, that the registration of dbpinstall should be checked.
There are also some message numbers that can not be determined using Error Lookup. They
are listed in the table below:
Message number Error text

0x80040200L GEO00D_DCOM_WRONG_FIRST_PARAM
0x80040201L GEO00D_DCOM_TOO_MANY_OUT_PARAM
0x80040202L GEO00D_DCOM_UNSUPPORTED_PARAM_TYPE
0x80040203L GEO00D_DCOM_MISSING_USERTYPE_GUID
0x80040204L GEO00D_DCOM_TOO_MANY_INTERFACES
0x80040205L GEO00D_DCOM_PROGID_NOT_FOUND
0x80040206L GEO00D_DCOM_INPROCSERVER_NOT_FOUND
0x80040207L GEO00D_DCOM_LOCALSERVER_NOT_FOUND
0x80040208L GEO00D_DCOM_METHOD_NOT_FOUND
Page 31 of 38
Message number Error text

0x80040209L GEO00D_DCOM_COGUID_NOT_FOUND_IN_TYPELIB
0x8004020AL GEO00D_DCOM_INSPEC_ROUTINE_NOT_FOUND
0x8004020BL GEO00D_DCOM_COCLASS_IN_REGISTRY_NOT_FOUND
0x8004020CL GEO00D_DCOM_ONLY_INPROC_SUPPORTED
0x8004020DL GEO00D_DCOM_LIBRARY_NOT_LOADABLE
0x8004020EL GEO00D_DCOM_DLL_MAIN_MISSING
0x8004020FL GEO00D_DCOM_DLL_MAIN_ERROR
0x80040210L GEO00D_DCOM_NO_COCLASS_OBJECT_FOUND
0x80040211L GEO00D_DCOM_DBPROC_CRASHED
0x80040212L GEO00D_DCOM_BUFFER_LIMIT
0x80040313L GEO00D_DCOM_UNEXPECTED_TYPELIB_STRUCTURE
0x80040314L GEO00D_DCOM_TRANSEND_FAILED
0x80040315L GEO00D_DCOM_INSTALLATION_PATH_NOT_FOUND
0x80040316L GEO00D_DCOM_INSTALLATION_NOT_REGISTERED
0x80040317L GEO00D_DCOM_COULD_NOT_RETRIEVE_PATH_VAL
10.6 Memory problems

If memory problems occur in NT or Windows2000, a fundamental check should be made to
see whether the 3GB option has been switched on. The liveCache can not operate properly
without this option. See note 112403 for information on switching on and checking this
option.
11 Problems with the Content Server (KM-KW-CDB)
11.1 Log mode

The content server should NEVER be operated in DEMO log mode. Only the Content Server
Cache may run in this mode.
After a Knowledge Warehouse version upgrade the log mode automatically goes to DEMO
mode (temporarily only). This can be checked via the DBMGUI: menu option Information ->
Log. The log mode will either be DUAL/DEMO or SINGLE/DEMO. To reset the log mode to
DUAL or SINGLE, a save must be made when the database state is COLD. For more
information on this, see note 337733.
11.2 Backup and Recovery

See note 319332 for content server backup strategies. This note also describes a database
recovery which is similar to an OLTP database recovery. In the event of problems, files from
section Error: Reference source not found should be searched through for causes of errors.
Page 32 of 38
However, if the problem is due to consistency between the content server database, and the
R/3 system, then application development should be consulted.
12 Maintenance of XUSER Data

XUSER data should also be checked in the event of connect problems.
In version 6.2 the xuser tool should be used to maintain XUSER data. See note 39439 for
information on what the XUSER entries should look like. This tool should be used to
maintain XUSER data in the OLTP environment (even in the later versions) in accordance
with the note.
In the liveCache environment, the dbmcli tool is used to maintain XUSER data.
Section 10.4 describes how it does this.
13 Contacting Development Support

The individual chapters have already indicated when to contact development support. The
following prerequisites must be fulfilled when forwarding a problem:
1. The required files have been saved and can be accessed (from sapserv3 for example).
2. Version 7.2: an SAP DB connection can be made and is working (note 202344).
3. An operating system connection can be made to the system and is working (UNIX:
Telnet, NT: PCAnywhere).
4. An R/3 connection can be made to the system and is working.
5. The logon data for the respective connection has been stored in the message (Goto ->
Customer logon data), or noted as an internal note.
6. The exact database version has been determined, and noted in the message. The same goes
for the R/3, or APO version.
Page 33 of 38
Appendix
I. List of the notes quoted in this guide
Note number Short text
16665 Method for troubleshooting, trace level
25099 Activate SQL trace
28577 SAP DB (ADABAS for R/3) function key setting
31511 Program runs very long: performance analysis
37282 What should be saved if the database crashes?
38037 Extracting C-stack from core file: Procedure
39439 XUSER entries for SAP DB 6.1 and 6.2
49776 Evaluating Dr. Watson log file
112403 Addressing 3GB mem. under Wind./NT f. SAPDB (ADABAS)
115059 SAP DB writes no back trace when crashing
116044 Log modes SAP DB (ADABAS) version 6.2
136153 Connection identifier "LCA" not known
157265 Exchanging COM objects for liveCache in APO 3.0
202344 Setting up DB connection in OSS
313347 NT: Questions on memory usage of an R/3 instance
315758 List of SAPAPO COM object builds for APO 2.0
319332 Content server backup strategies
324871 SAPAPO 2.0 How to install a new COM object build
326494 List of SAPAPO COM object builds for APO 3.0
327578 New software structure as of SAP DB version 7.2.4
Page 34 of 38
Note number Short text
330525 Overview menu options xcontrol -> DBMGUI
332075 Display important liveCache connection information
336470 Environment var. DBROOT no longer exists
337445 liveCache and AIX storage management
337733 Reset 7.2 temp. LOG MODE 'DEMO'
353158 What do I have to save if the DB has crashed?
383098 Error when starting external programs from R/3
384680 liveCache: AWE use on Windows 2000
386571 DLLS can not be overwritten
386714 SQLSTUDIO + DBMGUI installation from sapserv
393048 Error message documentation in KNLDIAG.ERR
398665 How PSE36/AWE will be used by the liveCache
II. List of important transactions

Special characters:
Character Meaning
/n Exit current transaction

Exit current transaction, and start transaction <trcode> in the same
/n<trcode>
mode.
/o Overview of terminal session modes (windows).
/o<trcode> Open a new mode, and in this mode start transaction <trcode>.
/i Delete a mode
/nend Exit terminal session with confirmation dialog box
/next Exit the terminal session without query
Page 35 of 38
Character Meaning
%pri Print current page
%sc Search current page
R/3 transactions, that are regularly used in support:
Transaction Meaning
AL08 Overview of users (all application servers)
AL11 Navigate in the file system from R/3
DB12 Log display (saves, update statistics)
DB13 DB administration in the SAP environment
DB50 Console
RZ10 Profile parameters
SE11 Data dictionary (table definitions, view definitions, ...)
SE80 Repository browser (programs, development classes,...)
SM04 Overview of users (individual application servers)
SM21 System log analysis
SM35 To select jobs
SM37 Job overview
SM39 Start reports
SM49 Execute external program (such as xsql, dbmcli)
SM50 Current processes
SM51 Server info. (patch level, ...) and to change application servers
ST02 Performance analysis
ST03 Long-running programs
Page 36 of 38
Transaction Meaning
ST04 Performance analysis
ST05 SQL Trace
ST11 Error log files (dev. log files)
ST22 Short dumps

/SAPAPO/LC10 bzw.
LiveCache administration and monitoring
LC10 (ab APO 2.0)
Page 37 of 38

Live Caches Supported

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Live Caches Supported

Diunggah oleh

Hak Cipta:

Format Tersedia

Support Guide SAP DB and liveCache

Melanie Handreck (SAP AG)

Status: 24. April 2001

9.1 PERFORMANCE PROBLEMS...............................................................................................24

13 CONTACTING DEVELOPMENT SUPPORT..............................................................33

3.2 DBMGUI, dbmcli and WebDBM

Information on these tools can be found in the SAP Help Portal:

3.4 SQLStudio and WebSQL

Or in www.sapdb.org -> Documentation and

4 Important Analysis Files

4.1 knldiag, knldiag.old and knldiag.err

4.2 dbm.* bzw. control.*

*.knl Backup history

dbm.mmm bzw. control.med Definition of the backup media

4.7 lcinit.log und lcinit.his

INIT LIVECACHE lca (INIT)

The database state is WARM

regLCCom ended successfully!

COM-DLL 'L:\ADABAS\LCA\sap\sapapo.dll' successfully registered

regLCCom ended successfully!

COM-DLL 'L:\ADABAS\LCA\sap\sapatp.dll' successfully registered

regLCCom ended successfully!

Read Config-File L:\ADABAS\LCA\sap\sapapo.lst :

regLCCom ended successfully!

Read Config-File L:\ADABAS\LCA\sap\sapatp.lst :

regLCCom ended successfully!

5 Different Types of Trace

5.2 SQL Trace

5.3 Precompiler Trace

independent data path (<INDEPDATAPATH>/wrk) with the name irtrace.shm. There

- All database versions:

5.4 Developer Trace

• select the work process,

6 Important Message Numbers

6.1 Error category 1:

Message number Error message Analysis + Solution

Message number Error message Analysis + Solution

1. Step: is there reference to a root page number in the knldiag/knldiag.err?

- YES,  there is a comparable entry

Continue troubleshooting from step 2

2. Step: is the database state WARM ?

- YES  the database state isWARM

Continue troubleshooting with step 3

- NO – the database is OFFLINE or COLD

-  Starting the database was unsuccessful

All diagnosis files must be resaved (see paragraph 4 for version

The problem should be forwarded to development support (please refer to section

3. Step: what is the object type?

Type : Named Index Solution in I

I. Solution: NAMED INDEX

The name of the affected index is specified in the INDEXNAME column.

Is the table contained in the R/3 data dictionary (transaction SE11)?

 NO, the table is not contained in the R/3 data dictionary

Determine the index structure using SQLSTUDIO or xquery:

Command: DROP Index <Indexname>on <tablename>

Command: Create index <indexname> on <tablename> ( <column>,

II. Solution: Table, exceptional cases -9026, and -9028:

Command: check table <tablename>

III.Solution: Table for all other category 1 errors

IV. Solution: Short String Column

6.2 Error category 2:

Number Error message Analysis + Solution

1. Step: What action has the error triggered?