Live cache support guide

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..........................................................................................................................13.2 DBMGUI, DBMCLI AND WEBDBM...................................................................................13.3 XQUERY..............................................................................................................................23.4 SQLSTUDIO AND WEBSQL...............................................................................................23.5 IREPORT.PY.........................................................................................................................33.6 X_CONS..............................................................................................................................33.7 X_DIAG(NOSIS)...................................................................................................................33.8 XINSTINFO..........................................................................................................................3

4 IMPORTANT ANALYSIS FILES.......................................................................................4

4.1 KNLDIAG, KNLDIAG.OLD AND KNLDIAG.ERR......................................................................44.2 DBM.* BZW. CONTROL.*.....................................................................................................64.3 KNLTRACE..........................................................................................................................64.4 CORE...................................................................................................................................74.5 DRWTSN32.LOG.................................................................................................................74.6 APPLDIAG...........................................................................................................................74.7 LCINIT.LOG UND LCINIT.HIS................................................................................................7

5 DIFFERENT TYPES OF TRACE.......................................................................................9

5.1 VTRACE..............................................................................................................................95.2 SQL TRACE......................................................................................................................105.3 PRECOMPILER TRACE.......................................................................................................105.4 DEVELOPER TRACE..........................................................................................................11

6 IMPORTANT MESSAGE NUMBERS.............................................................................12

6.1 ERROR CATEGORY 1:........................................................................................................126.2 ERROR CATEGORY 2:........................................................................................................176.3 ERROR CATEGORY 3:........................................................................................................186.4 ERROR CATEGORY 4:........................................................................................................196.5 MISCELLANEOUS -9XXX ERRORS.....................................................................................20

7 DIRECTORY STRUCTURE.............................................................................................20

7.1 INSTALLATIONS USING DBROOT....................................................................................207.2 INSTALLATIONS NOT USING DBROOT............................................................................20

8 PROBLEMS INDEPENDENT OF INSTANCE TYPE...................................................21

8.1 DATABASE CRASH............................................................................................................218.2 PROBLEMS WITH DATABASE MIGRATIONS/INSTALLATIONS USING R3SETUP OR

LCSETUP........................................................................................................................238.3 PROBLEMS WITH THE SAPDBINSTALL TOOL OR SDBINST TOOL...............................238.4 UNINSTALLING.................................................................................................................23

8.4.1 Database software.....................................................................................................238.4.2 Database instance.....................................................................................................23

9 PROBLEMS WITH OLTP DATABASES (BC-DB-ADA*)............................................24


9.1 PERFORMANCE PROBLEMS...............................................................................................249.2 CONNECTION PROBLEMS..................................................................................................24

10 PROBLEMS WITH THE LIVECACHE (BC-DB-LVC*)............................................24

10.1 ADMINISTRATION...........................................................................................................2410.2 PERFORMANCE PROBLEMS.............................................................................................25

10.2.1 The Data Cache......................................................................................................2510.2.2 The Heap.................................................................................................................29

10.3 COM ROUTINE PROBLEMS.............................................................................................2910.4 PROBLEMS WITH CONNECTION TO LIVECACHE..............................................................3010.5 HRESULT ERROR..........................................................................................................3110.6 MEMORY PROBLEMS......................................................................................................32

11 PROBLEMS WITH THE CONTENT SERVER (KM-KW-CDB)...............................32

11.1 LOG MODE......................................................................................................................3211.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.................................................................................34II. List of important transactions..........................................................................................35


1 Guide ObjectivesThis 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 InformationFor information on the liveCache, and general SAP DB info, access the internet, and go to:

1. BIS: Database Technology -> SAP DB/LiveCachehttp://bis.wdf.sap-ag.de:1080/sapdb/

2. The Open Source pagewww.sapdb.org

3. The SAP Help Portalhttp://help.sap.com

4. The APO Development Support pagehttp://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

http://www.sapdb.org/

http://help.sap.com/saphelp_46b/helpdata/de/07/ab533628fbac21e10000009b38f889/frameset.htm

http://help.sap.com/

http://pal100075.pal.sap-ag.de/



http://bis.wdf.sap-ag.de:1080/sapdb/


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 HTML English or German


R/3 database guide: SAP DB 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-RRun a command: RunReturn to last screen: EndGoto 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 HTML English or German


R/3 database guide: SAP DB SQL Studio (BC)

or http://help.sap.com/saphelp_46csr1/helpdata/de/07/ab533628fbac21e10000009b38f889/frameset.htm

Page 2 of 38

http://help.sap.com/saphelp_46csr1/helpdata/de/07/ab533628fbac21e10000009b38f889/frameset.htm



http://www.sapdb.org/sap_db_documentation.htm


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.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/IndepDataIndepPrograms : /sapdb/IndepPrograms

- Call with database name:xinstinfo <DB_NAME>

1 Refer to section 7.2

Page 3 of 38

http://www.sapdb.org/sap_db_documentation.htm



Example output:IndepData : /sapdb/DataIndepPrograms : /sapdb/ProgramsInstallationPath : /sapdb/MUT/dbKernelversion : KERNEL 7.2.5 BUILD 004-000-240-291Rundirectory : /sapdb/Data/wrk/MUT

4 Important Analysis FilesCSN 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;compress10-19 10:01:43 0xFC 50001 TCLUSTER number of ' DW': 810-19 10:01:43 0xFC 50001 TCLUSTER number of ' EV': 010-19 10:01:43 0xFC 50001 TCLUSTER number of ' US': 510-19 10:01:43 0xFC 50001 TCLUSTER number of ' SV': 1310-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: 0xe410-19 10:01:43 0xFC 18317 INFO Date: 00-10-1910-19 10:01:43 0xFC 18316 INFO Owner: 'SYSTEM'10-19 10:01:43 0xFC 18319 INFO Number of Processors: 110-19 10:01:43 0xFC 18320 INFO Max virtual memory: 2047 MB10-19 10:01:43 0xFC 18321 INFO Total physical memory: 159 MB10-19 10:01:43 0xFC 18322 INFO Available physical memory: 72 MB10-19 10:01:43 0xFC 18323 INFO Kernel shared memory size: 7 MB10-19 10:01:43 0x112 18257 TASKING UKT started, TID:0x11210-19 10:01:43 0x1F1 18257 TASKING UKT started, TID:0x1F110-19 10:01:43 0x106 18257 TASKING UKT started, TID:0x10610-19 10:01:43 0x1FB 18257 TASKING UKT started, TID:0x1FB10-19 10:01:43 0x130 18257 TASKING UKT started, TID:0x13010-19 10:01:43 0x144 18257 TASKING UKT started, TID:0x14410-19 10:01:43 0x144 54003 dynpool NUM DATAWRITER : 8...10-19 10:01:43 0x144 54003 DYNPOOL DYNP_B11_FBM_STRUC : 321210-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: 710-19 10:01:44 0x112 18245 DEVIO Attaching devspace 'knltrace'10-19 10:01:46 0x16F 18243 DBSTATE I/O thread for 'knltrace' started10-19 10:01:46 0x112 54003 dynDATA DYND_B12_VTRACE : 210-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' started10-19 10:02:26 0x106 18247 DEVIO Single I/O attach, 'SYS_001', UKT:310-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' stopped10-19 10:02:26 0x20E 18248 DEVIO Single I/O detach, 'SYS_001', UKT:310-19 10:02:26 0x106 18245 DEVIO Attaching devspace 'diskl01'10-19 10:02:26 0x113 18243 DBSTATE I/O thread for 'diskl01' started10-19 10:02:26 0x106 18247 DEVIO Single I/O attach, 'diskl01', UKT:310-19 10:02:26 0x106 18246 DEVIO Detaching devspace 'diskl01'10-19 10:02:26 0x113 18244 DBSTATE I/O thread for 'diskl01' stopped10-19 10:02:26 0x20E 18248 DEVIO Single I/O detach, 'diskl01', UKT:310-19 10:02:26 0x106 18282 CONNECT Connection released, T710-19 11:28:25 0xFC 18241 DBSTATE SERVERDB is being stopped10-19 11:28:25 0x112 18247 DEVIO Single I/O attach, 'knltrace', UKT:110-19 11:28:26 0x112 18249 TASKING Releasing tracewriter10-19 11:28:26 0xFC 18320 TASKING Tracewriter termination timeout: 1200 sec10-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:209-27 14:43:58 0x175 ERR 18088 DBCRASH Emergency Shutdown09-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:209-27 14:44:09 0x182 ERR 18088 DBCRASH Emergency Shutdown09-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:209-27 14:44:18 0x1B3 ERR 18088 DBCRASH Emergency Shutdown09-27 14:48:48 --- Starting ---09-27 14:48:52 0x1A5 ERR 53007 CONFIG ILLEGAL DATA DEV SIZES09-27 14:48:52 0x1A5 ERR 53007 CONFIG RestartRec: Max Data Pno: 599909-27 14:48:52 0x1A5 ERR 53007 CONFIG XParam: Max Data Pno: 299909-27 14:48:52 0x1A5 ERR 18089 DBCRASH Emergency Shutdown, vbd15.c: 566009-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

*.utlAdministration commands that have been sent to the database kernel, such as save, and restart commands

*.ins The system table load log

dbm.prtCommands that have been sent to the DBM server from the 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 file02-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 successfullystarting lca into COLD 19849 INFO: 'LCA' started successfullystarting INIT CONFIG starting ACTIVATE SERVERDB loading SYSTEM TABLES Returncode: 0liveCache DCOM registration creating system COM routines DBPROC 'COPY_AND_REG_DLL' (INPROC) createdDBPROC 'ACTIVATE_DLL' (INPROC) createdDBPROC 'REG_DLL' (INPROC) created

regLCCom ended successfully!SET MONITOR ON

registration of sapapo.dll

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

regLCCom ended successfully!registration of sapatp.dll

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

regLCCom ended successfully!creating COM routines of sapapo.dll

Read Config-File L:\ADABAS\LCA\sap\sapapo.lst :DBPROC 'SAPAPO_CHANGE_PROP_AREAS' (INPROC) createdDBPROC 'SAPAPO_GET_PROP_AREAS' (INPROC) created...DBPROC 'SAPAPO_GET_DRP_AGGREGATE_AMNTS' (INPROC) createdDBPROC 'SAPAPO_GET_DRP_IOS' (INPROC) created

regLCCom ended successfully!creating COM routines of sapatp.dll

Read Config-File L:\ADABAS\LCA\sap\sapatp.lst :DBPROC 'SAPATP_CREATE_ANCHOR_OBJECT' (INPROC) createdDBPROC 'SAPATP_DELETE_ANCHOR_OBJECT' (INPROC) created...DBPROC 'SAPATP_ALLOC_READ_ALL' (INPROC) createdDBPROC 'SAPATP_ALLOC_GET_ALL_ID' (INPROC) created

regLCCom ended successfully!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 TraceThe 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 = 2detailed 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 = 1short 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 NumbersThe 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

with index: section 6.1, 4. step, paragraph Iwith table: section 6.1, 4.step, paragraph III

-9002 e_illegal_branchlength

-9003 e_illegal_entrylength

-9005 e_illegal_key

-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

-9026 e_bad_datapagewith index: section 6.1, 4. step, paragraph Iwith table: section 6.1, 4. Step, paragraph II

-9028 e_bad_file

-9029 e_bad_invfile

With index: section 6.1, 4. Step, paragraph IWith table: section 6.1, 4. Step, paragraph III

-9041 e_file_not_accessible

-9044 e_inconsistent_nodetype

-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 00AEA7000000000010-09 16:56:28 16 ERR 53000 B*TREE 0000000000000000000000000000000010-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 databaseRecheck 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 recognizedAnalyze, and remove errorsStart 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 IType : Table Solution in II and IIIType : 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, orb) 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 generatedb) 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

Can error be reproduced after DB restart? Generate Vtrace Forward problem to

development support

-9007 e_illegal_page_no

-9050 e_illegal_page_address

-9051 e_invalid_fbm_mark

-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 logChecking 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 dumpsIf 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 onThe 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

Recovery

-9027 e_bad_fdir

-9033 e_bad_syspage

-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_logpageRestore 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 -> Configurationor UNIX:$DBROOT/pgm/getparam <DB_NAME> LOG_MODE bzw. NT:getparam <DB_NAME> LOG_MODE

2. Version 7.2: DBMGUI -> Information -> Logordbmcli –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 StructureFor 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:OKE20 /sapdb/E20/db 7.2.4.0 fast runningE20 /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


http://wwwint01.wdf.sap-ag.de/solutions/technology/sapdb/pdf/directorydistrib_72eng.pdf


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%\pgmUNIX: $DBROOT/bin, $DBROOT/sapThe 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>\pgmUNIX: <INDEPPROGPATH>/binThe 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 -> DropOr 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 statisticsAll 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 AdministrationThere 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 CacheThe 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 AWEIn 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 systemsCache 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 Oracle6 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 UNIXSufficient 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_statusshould 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 HeapIf 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 heapAt 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 -4016Various 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 resources8 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 informationLCA pwdf0221-LCALDA 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 PALCA /SAPAPO/DELETE_LC_ANCHORS X------------------------------------------------------------------------4. Created XUSER entries:------------------------------------------------------------------------Server: pwdf0236_AP3_21Key UserDEFAULT SAPR31LCAPWDF0221 CONTROL------------------------------------------------------------------------5. DBMCLI Client Version:------------------------------------------------------------------------Server: pwdf0236_AP3_21VERSION = 7.2.3BUILD = DBMServer 7.2.3 Build 006-000-198-647OS = WIN32INSTROOT = D:\usr\sap\AP3\SYS\livecacheLOGON = TrueCODE = ASCIISWAP = 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 DataXUSER 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 SupportThe 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

/n<trcode>Exit current transaction, and start transaction <trcode> in the same 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.

LC10 (ab APO 2.0)LiveCache administration and monitoring

Page 37 of 38