Using MaxDB

Contents:
◼ Sources of information in the new Database Studio tool
◼ Users in the MaxDB environment
◼ How MaxDB is used and how to respond to specific exceptions that may occur
◼ MaxDB database parameters

© SAP 2008

© SAP AG ADM515 3-1

 Using MaxDB: Objectives

After completing this unit, you will be able to:

◼ Use Database Studio and recognize important sources of information
◼ Resolve errors that occur when the database is used

© SAP 2008

© SAP AG ADM515 3-2

 Agenda I

1. First Contact 3. Inside MaxDB

1.1. Introduction 3.1. Processes
1.2. Tools and Interfaces 3.2. Locks
1.3. Architecture and Operational States 3.3. Memory Areas
1.4. MaxDB and SAP NetWeaver 3.4. Disk Areas
1.5. Integration with SAP NetWeaver 3.5 Logging
1.6. Server Landscape for This Course 4. Database Backup and
2. Using MaxDB Recovery
2.1. Overview of Database Studio 4.1. Complete Data Backups
2.2. Important Sources of Information in 4.2. Incremental Data Backups
Database Studio 4.3. MaxDB Snapshots
2.3. MaxDB Users in the SAP Environment 4.4. Log Backups
2.4. Disk Areas for Data and Logs 4.5. Automatic Log Backups
2.5. Configuration Changes 4.6. Checking Backups
2.6. DB FULL and LOG FULL Situations 4.7. Backup Strategy
2.7. Parameters 4.8. External Backup Tools
2.8. Tools for Exercises

© SAP 2008

© SAP AG ADM515 3-3

 Agenda II

5. Other Administrative Topics 7. Outlook for MaxDB 7.8

5.1. Checking Databases 7.1. Overview
5.2. Creating Database Instances 7.2. Changes to the Database Kernel
5.3. Reinitializing Database Instances 7.3. New Administrative Functions
5.4. Installing Patches (Release Upgrade) 7.4. Setup and Infrastructure
5.5. Migrating to MaxDB 7.5. Interface and Users
5.6. High Availability
5.7. MCOD
6. Performance Tuning and Troubleshooting
6.1. B* Trees
6.2. Optimization
6.3. SAP NetWeaver Monitoring Tools
6.4. Avoidable Problems
6.5. Diagnosis Files and Trace Options
6.6. Types of Errors and How to Analyze Them

© SAP 2008

© SAP AG ADM515 3-4

 Using MaxDB: Unit Overview Diagram

Using MaxDB
Topic 1: Overview of Database Studio
Topic 2: Important Sources of Information in Database Studio
Topic 3: MaxDB Users in the SAP Environment
Topic 4: Disk Areas for Data and Logs
Topic 5: Configuration Changes
Topic 6: DB FULL and LOG FULL Situations
Topic 7: Parameters
Topic 8: Tools for Exercises

© SAP 2008

© SAP AG ADM515 3-5

 Database Studio – Overview with Hyperlinks

© SAP 2008

◼ The icons in the header of the "Administration" tab page allow you to change the operational state of
the database managed directly.
◼ You can access many important Database Studio functions via the hyperlinks on the "Overview" tab
page.
◼ When important warning messages are output, they are also displayed here with a hyperlink to the
relevant Wizard.
• These messages indicate problems such as:
- Incomplete data backups
- Defective or missing indexes
- and so on
◼ To display detailed capacity information, extend the screen area containing the bars by choosing the
button on the right.
◼ To hide the left-hand tree structure listing the servers and databases and display information across
the entire screen, double-click the "Administration" tab page, for example.
◼ You can display many additional special screen areas from the status bar area at the bottom right of
the screen. The screenshot shows the small screen area from which you can open a console window
listing the dbmcli commands used in Database Studio. For more information about how to activate
these special screen areas, see Unit 5.
◼ The various tab pages in the administration area are explained on the following slides.

© SAP AG ADM515 3-6

 Database Studio – Task Manager

© SAP 2008

◼ The "Task Manager" tab page provides an overview of all tasks currently running and all operational
states currently active in the database.
◼ This task list can be restricted; here, only active tasks are displayed.
◼ You can also display detailed information about the internal processes of the tasks; this is explained
in more detail on the next slide.
◼ To update the list, choose Refresh in the upper screen area.
◼ You can also activate detailed time measurement for the different internal database processes.
• Note that activating this detailed time measurement increases the load on the database instance
since the times must be determined and calculated. Depending on the general database load, this
may have a negative effect on system performance. The higher the load on the instance, the more
performance is affected. For this reason, time measurement should be activated only if required,
and should be used for longer periods in test and development systems only. In general, larger
systems are barely affected.

© SAP AG ADM515 3-7

 Database Studio – Task Manager Details

© SAP 2008

◼ In this screenshot, we see the results of active time measurement in the "Details for Task 554": The
average write time is 1.5 ms, which is an excellent value. Values below 10 ms usually ensure good
database performance. It is therefore important to calculate these values, especially when
performance problems exist.
◼ You can also display the thread layout here, as well as thread statistics.

© SAP AG ADM515 3-8

 Database Studio – Activities

© SAP 2008

◼ The "Activities" tab page lists a wide range of statistical operating data for MaxDB. Much of this
data is recorded only for logging purposes.
◼ More useful to us, is the lock escalation and log queue overflow data (Log I/O Queue Overflow).
• The value for Log I/O Queue Overflow should be zero, if possible. If this is not the case, the log
disks may not be performing adequately or the log may have an extremely high load for a short
period. In response, you can try to expand the buffer by increasing the LogQueueSize parameter
value, but this will not improve the poor COMMIT times.

© SAP AG ADM515 3-9

 Database Studio – Caches

© SAP 2008

◼ The "Caches" tab page shows the important cache areas of MaxDB and the corresponding hit rates.
◼ The hit rate for the data cache should preferably exceed 98%. The higher the value, the better.
◼ For the catalog cache, the recommended hit rate is 85% or higher, even though lower values do not
mean that more I/O is required (as with the data cache, for example). For this reason, the catalog
cache does not have a major impact on the overall performance of the database.
◼ The underlying values are calculated as soon as the database is started. Once the database has been
running for some time, the values are strongly averaged and may no longer reflect any temporary
changes in the database. To detect these, you have to use DBAnalyzer (see Unit 6).

© SAP AG ADM515 3-10

 Database Studio – Command Line

© SAP 2008

◼ In Database Studio, you can also obtain more detailed information by executing the dbmcli console
commands directly.
◼ The INFO commands shown here provide additional information.
◼ You can also execute other dbmcli commands here, without having to enter passwords.

© SAP AG ADM515 3-11

 Using MaxDB: Unit Overview Diagram

Using MaxDB
Topic 1: Overview of Database Studio
Topic 2: Important Sources of Information in Database Studio
Topic 3: MaxDB Users in the SAP Environment
Topic 4: Disk Areas for Data and Logs
Topic 5: Configuration Changes
Topic 6: DB FULL and LOG FULL Situations
Topic 7: Parameters
Topic 8: Tools for Exercises

© SAP 2008

© SAP AG ADM515 3-12

 Database Studio – Database Server
Information

© SAP 2008

◼ In addition to the data generally displayed in the administration area, you can access the raw data
using the commands listed under "Database Server".
◼ These are the same commands that you can execute on the console using x_cons or dbmcli.
◼ The screenshot above shows the output of the x_cons <SID> show dev_io command. The AvgRead
and AvgWrite columns are of most interest. Using this data, you can calculate device-related I/O
times and thus identify hardware problems with individual disks or disk areas. As of MaxDB 7.7.04
and higher, this command is available for both Unix and Windows (in earlier versions, it was not
available for Windows).

© SAP AG ADM515 3-13

 Database Studio – Diagnosis Files

© SAP 2008

◼ All MaxDB diagnosis files are listed in the database tree below the administration user.
◼ The most important diagnosis file to point out here is "knlMsg", which is displayed under "Database
Messages".
◼ Errors are collected under "Database Errors".

© SAP AG ADM515 3-14

 Database Studio – SQL Content

© SAP 2008

◼ You can find SQL content of the database in the "Tables" folder under the respective owner of the
SQL table.

© SAP AG ADM515 3-15

 Using MaxDB: Unit Overview Diagram

Using MaxDB
Topic 1: Overview of Database Studio
Topic 2: Important Sources of Information in Database Studio
Topic 3: MaxDB Users in the SAP Environment
Topic 4: Disk Areas for Data and Logs
Topic 5: Configuration Changes
Topic 6: DB FULL and LOG FULL Situations
Topic 7: Parameters
Topic 8: Tools for Exercises

© SAP 2008

© SAP AG ADM515 3-16

 Operating System Users with MaxDB

Name Function Group Home Directory

root UNIX super user sys /

Unix

sdb Owner of all executable sdba /sapdb/<SID>/db

files and directory structures
of MaxDB
<sid>adm SAP NetWeaver administration sapsys,sdba Free selection
Windows

<sid>adm SAP NetWeaver administration Administrators Free selection

SAPservice<SID> Service administration Administrators -

© SAP 2008

◼ In an SAP NetWeaver system environment with MaxDB, the following operating system users are
important:
◼ The root user is required for SAP installation tools. Internally, these tools switch to the <sid>adm
or sdb users.
◼ The sdb user is the owner of the files in the "/sapdb" directory. This is not a logon user. In some
application areas (such as liveCache), the "<sid>adm" user has installation and administration rights.
◼ <sid>adm is the owner of all SAP NetWeaver program files. In the UNIX environment, all
activities at operating system level should be carried out with <sid>adm. Since this user is assigned
to the SDBA Unix group, MaxDB programs can executed by this user.
◼ In Windows, service administration starts the database and NetWeaver instances with the
SAPService<SID> user.
◼ The usual security guidelines apply for passwords.

© SAP AG ADM515 3-17

 MaxDB Users

User/password Function Group Mode

control/control Database Manager user, DBM ONLINE,

cannot execute SQL ADMIN,
statements OFFLINE

superdba/admin Database system administrator SYSDBA ONLINE

sap<sid>/sap Database user (SQL) DBA ONLINE

or sapr3/sap
domain/domain Database user (SQL) DBA ONLINE

© SAP 2008

◼ MaxDB distinguishes between the following user classes:

◼ Database Manager user (DBM user)
• Created when a database instance is installed
• Can perform all Database Manager functions in any operational state
• Can create additional Database Manager users and assign authorizations to them
• Not a database user, however, and so cannot execute SQL statements
• In the SAP environment, this is usually the control user (password: control)
◼ Database system administrator (SYSDBA database user)
• Created when a database instance is installed
• Owner of statistics and monitor system tables
• Can create additional DBA database users and grant them privileges
• In the SAP environment, this is usually the superdba user (password: admin)
◼ DBA user (DBA database user)
• Database user
• Can define data and database procedures
• Can grant other users privileges for these database objects
◼ The "sapr3" or "sap<sid>" DBA user (password: sap) is the owner of the application tables.
The work processes of the SAP system use this password to log on to the database instance.
◼ The DOMAIN user is a special DBA user and the owner of specific system tables.
© SAP AG ADM515 3-18
 Relationships Between User Types

Three important user areas and how they overlap

◼ Operating system users
◼ Administrative database users
◼ SQL users

Operating System
• root
• sdb
• <sid>adm
• SAPservice<SID>
Database Administration

• control
SQL User Area
• superdba • superdba
• domain • domain
Xuser • sap<sid>
data

© SAP 2008

◼ Users are required in three areas of MaxDB:

• Operating system
• Database administration
• To access SQL data
◼ The associated data is stored in different files and structures:
• Operating system users are managed by the OS, as usual. XUSER information is stored here in
files or Windows Registry entries. For more information, see the end of this unit.
• Information about database administrators is partly stored in the parameters
(CONTROLUSERID) and <SID>.upc files in the config directory, as well as in the "dbm.upc"
file in the RUNDIRECTORY of the database instance. The registration data for these
administrators is stored in the <SID>.cfg file in the config directory.
• Information about SQL users is stored within the database.
◼ Only the "superdba" and "domain" users are universally valid and recognized in both the
administrative and SQL areas.
◼ You must make sure that the user information in these different storage areas is kept consistent. In
contrast to earlier versions, Database Studio provides two settings areas for the different types of
user information (administrative and SQL users). You can normally rectify any inconsistencies
between these areas by reloading the system tables with the correct user options (dbmcli –U c
loadsystab –u superdba,<pwd> -ud <domain-pwd>), as far as this is possible. The SQL logon data is
then copied to the administrative area.

© SAP AG ADM515 3-19

 Automated Logon: XUSER

Parameter Set 1
USER SESSION
of the OS user USERKEY DEFAULT Set 2
USERID sap<sid> c Set 3 …
dbmcli –U w PASSWORD *** CONTROL w
Repeat password *** ******** SUPERDBA
SERVERDB E20 ******** *****
SERVERNODE ws0815 E20 *****
User Parameter Sets
SQLMODE SAPR3 ws0815 E20
CACHELIMIT -1 INTERNAL ws0815
TIMEOUT 0 -1 INTERNAL
ISOLATION 0 0 -1
XUSER Data ENCRYPTION NO 0 0
NO 0
NO

Client

Co
Connect using hidden logon data. nn
Command is as follows: ec
t
dbmcli –d E20 –u SUPERDBA,<PWD> MaxDB Server
© SAP 2008

◼ Using the XUSER tool, you can store user data as parameter sets by specifying a user key
(USERKEY). You can use this key to access the user data when calling up the Database Manager
CLI, SQL Database Connectivity (SQLDBC), or when starting the SAP system or old C/C++
precompiler.
◼ The XUSER program manages up to 32 parameter sets for each operating system user.
◼ The parameter sets are stored in the .XUSER.62 file in the home directory of the operating system
user. In Windows, they are stored in the Windows Registry.
◼ The first parameter set is called DEFAULT and cannot be renamed. If you do not specify a key
when logging on to the database, the system uses this parameter set by default in the XUSER tool.
◼ For an SAP NetWeaver database, DEFAULT denotes the sap<sid> user. This means that the work
processes can log on to the database without an operator.
◼ The Computing Center Management System (CCMS) within SAP NetWeaver also requires the "w"
and "c" keys.
◼ SERVERDB is the name of the database instance (<SID>).
◼ SERVERNODE indicates the server on which the database instance is installed.
◼ As of MaxDB 7.6 and higher, you can also encrypt the network connection between the client
(application server, dbmcli, and so on) and the X Server of the database. To do so, you currently still
require additional SAP encryption libraries.

© SAP AG ADM515 3-20

 Maintaining XUSER Data

Options Actions
◼ -U User key ◼ list List
◼ -u User name ◼ set Set changes
◼ -d Database name ◼ clear Delete entry
◼ -n Server name
◼ -S SQL mode
◼ -t Timeout
◼ -I Isolation level

Example:
xuser –U DEFAULT –u sap<sid>,passwd –d <SID> -n <host> -S SAPR3 set

© SAP 2008

◼ The most important options of the XUSER tool are listed here.
◼ The example shows how to gain access without a complete set of data.

© SAP AG ADM515 3-21

 SQL Mode Logon Option

The following SQL modes are possible:

◼ INTERNAL

◼ ORACLE

◼ (SAPR3)

© SAP 2008

◼ MaxDB recognizes different SQL dialects. This is especially useful for porting existing, internally
developed software since it reduces the work involved in switching to MaxDB.
◼ Users can select the SQL mode (example: MaxDB database tool, Database Studio).
◼ The default SQL mode is INTERNAL (internal system definition).
◼ Standard language SQL92 is supported with MaxDB-specific enhancements.
◼ Other SQL modes receive only limited support with regard to DDL statements.
◼ The "SAPR3" SQL mode is a copy of the Oracle SQL mode, which the SAP NetWeaver system
uses to access MaxDB in almost all cases.

© SAP AG ADM515 3-22

 Additional User Authentication as of 7.7

◼ As an alternative to the
traditional logon procedure, CREATE USER <sid>adm
an operating system user can IDENTIFIED EXTERNALLY AS ‘<sid>adm’
also be logged on to the sqlcli -d <SID> -u <sid>adm “select * from users”
database as a database user.
◼ In this way, users can log on
ALTER USER sap<sid>
to the database using the IDENTIFIED EXTERNALLY AS ‘<sid>adm’
operating system
authentication or the sqlcli -d <SID> -u sap<sid> “select * from users”
Kerberos and Secude
security protocols.
◼ Database users can also be
deactivated so that work in
the database is not disrupted.
ALTER USER sap<sid> DISABLE CONNECT

sqlcli -d <SID> -u sap<sid> “select * from users”

* -8026: Connect disabled for this user

© SAP 2008

© SAP AG ADM515 3-23

 Using MaxDB: Unit Overview Diagram

Using MaxDB
Topic 1: Overview of Database Studio
Topic 2: Important Sources of Information in Database Studio
Topic 3: MaxDB Users in the SAP Environment
Topic 4: Administration of Disk Areas for Data and Logs
Topic 5: Configuration Changes
Topic 6: DB FULL and LOG FULL Situations
Topic 7: Parameters
Topic 8: Tools for Exercises

© SAP 2008

© SAP AG ADM515 3-24

 Adding Data Volumes

© SAP 2008

◼ Before the database is next restarted, you can extend it by the number of data volumes displayed.
◼ The size of the data volumes is freely definable, but we recommend that you keep all volumes the
same size. If volume sizes vary, this can have a negative impact on the overall performance of the
database.
◼ You can extend the database by double-clicking the grayed-out entry in the volume list or choosing
"New".
◼ You can display the properties and settings of a volume by double-click it.

© SAP AG ADM515 3-25

 Adding Log Volumes

© SAP 2008

◼ You add log volumes in the same way as data volumes (double-click the grayed-out entry or choose
New).
◼ There are usually one or two log volumes. More volumes can be added but are not required.
◼ More information about the status of the log is listed on this screen. When you choose the
hyperlinks, you are often directed to the relevant Wizards for defining settings such as automatic log
backups.
◼ Be very careful when deactivating redo log management since business data can be lost
permanently.

© SAP AG ADM515 3-26

 Using MaxDB: Unit Overview Diagram

Using MaxDB
Topic 1: Overview of Database Studio
Topic 2: Important Sources of Information in Database Studio
Topic 3: MaxDB Users in the SAP Environment
Topic 4: Administration of Disk Areas for Data and Logs
Topic 5: Configuration Changes
Topic 6: DB FULL and LOG FULL Situations
Topic 7: Parameters
Topic 8: Tools for Exercises

© SAP 2008

© SAP AG ADM515 3-27

 Configuration Changes

Description Operational State Logged Action

Add a new data volume ADMIN ADD DATA VOLUME

ONLINE

Separate and delete a data ADMIN DEL DATA VOLUME

volume ONLINE

Add a new log volume ADMIN ADD LOG VOLUME

ONLINE

Change the path data for existing data and log OFFLINE
volumes

Change the log mode

Mirror log ONLINE -> ADMIN
Automatic overwriting ONLINE -> ADMIN
Deactivate log management (caution) ONLINE -> ADMIN

Rebuild the system tables after a kernel ONLINE

upgrade

© SAP 2008

◼ Increasing the size of the data or log area: the relevant actions are available in Database Studio:
• You can perform these actions in both the ONLINE and ADMIN operational states.
• In the ONLINE operational state, you can only add a specific number of volumes. Database
Studio displays all available volumes as grayed-out entries.
◼ Changing the properties of existing volumes:
• You can edit the definitions of existing volumes in the OFFLINE operational state.
• In this way, for example, you can adjust the path of a volume accordingly after moving it from
one directory to another.
• You cannot change the size of existing volumes. The only way you can do this indirectly is by
separating and deleting the data volume and then creating it again in the size required.

© SAP AG ADM515 3-28

 Reducing the Size of the Database

Reducing the size of the database

DATA
in the ONLINE operational state DATA
DATA
◼ The "db_deletevolume" command allows you DATA
to remove a data volume from the configuration in the
ONLINE operational state to reduce the size of the database.
◼ You can also use this function to change the size of data volumes indirectly (by deleting the
existing data volume and replacing it with a larger or smaller volume).
◼ The data of the volume to be deleted must first be distributed to the other volumes
automatically.
◼ In Database Studio, you can delete data volumes and replace them indirectly by choosing
"Administration" -> "Data Area" -> "Data Volumes".

dbmcli –U c …
db_deletevolume [DATA] [ NAME <vol_name> | [ID] <vol_no> ]

© SAP 2008

◼ This option enables you to change the size of data volumes indirectly: You first have to create the
larger data volumes required and then delete the existing smaller ones. In this way, you can
gradually adjust the size of all data volumes in the ONLINE operational state, by transferring the
data from the old volumes to the new volumes.
◼ Using the param_getvolsall and param_getvolume <vol_no> DATA commands, you can determine
the "vol_no" or "vol_name" of the volume to be deleted.

© SAP AG ADM515 3-29

 Separating and Deleting Data Volumes

© SAP 2008

◼ Before you can separate and delete a volume, there must be enough space for this data in the other
data volumes.
◼ Moving large datasets obviously affects system performance, the extent to which depends on how
the underlying hardware handles the data streams.
◼ Furthermore, the data is still transferred through the data cache of the database, which can lead to
displacements. There are plans to used different memory structures outside the data cache for such
transfers in future.
◼ For this reason, actions of this kind in production systems should be carried out at times of lower
workload if possible.

© SAP AG ADM515 3-30

 Moving Volumes

In the OFFLINE operational state:

© SAP 2008

◼ Setting the operational state of the database to OFFLINE enables you to move the data volumes.
◼ Before the database is next restarted from OFFLINE to ADMIN, the affected volumes must be
moved to their new positions manually.

© SAP AG ADM515 3-31

 Changing the Log Mode – Mirroring Logs

© SAP 2008

◼ When you change the log mode from non-mirrored to mirrored and vice versa, the process is
similar. The mirrored log volumes are defined or deleted.
◼ Changing the log mode from non-mirrored to mirrored or vice versa does not interrupt the backup
history.
◼ The database is restarted during this process.
◼ The subsequent process of mirroring the logs can take a while, depending on the size of the log
volume to be formatted.
◼ The general recommendation is that you use log mirroring for smaller systems only.

© SAP AG ADM515 3-32

 Changing the Log Mode – Overwriting Logs

© SAP 2008

◼ If installations are used for test purposes only, it is possible to set the log mode to overwrite mode.
In this mode, the log entries are not backed up before they are overwritten.
◼ You have to decide whether the loss of data in the development system is acceptable if logs are not
backed up. If not, you should also run these systems in normal log mode, with or without mirroring.
◼ Database instances that run in OVERWRITE log mode only use the entries in the log volume to roll
forward open transactions if a problem occurs and a restart is required.
◼ Therefore, the log area selected in OVERWRITE mode should also be large enough to
accommodate the log entries of open transactions. This applies especially to content server
installations for which the log area also has to log changes made to large (binary) objects. This
means that the log area must be at least the same size as the largest object to be changed in the
database. Otherwise, a LOG FULL situation occurs even though OVERWRITE mode is set. When
objects are changed, only the after images are written to the log area.
◼ You can change the log mode in Database Studio by choosing "Administration" and the Log Area
tab page. A Wizard helps you in this process.
◼ You can switch between overwrite mode and normal mode here. When you do this, the database is
restarted.
◼ This also affects the backup history since logs are no longer backed up in overwrite mode and the
only way to perform a recovery is a restore of an existing data backup.

© SAP AG ADM515 3-33

 Changing the Log Mode - Effect on Backup
History

© SAP 2008

◼ If you change the log mode to overwrite mode, logs can no longer be backed up and data can be
recovered up to the last completed transaction in exceptional cases only.
◼ For this reason, an additional line is entered in the backup history after every data backup to indicate
a break in the backup history (HISTLOST).
◼ Due to these HISTLOST entries, only complete backups are still possible when you start backups,
which ensures that a new backup history is started.
◼ For more information about the backup history, see Unit 4.

© SAP AG ADM515 3-34

 Changing the Log Mode – Deactivating Logs
-> Caution

© SAP 2008

◼ You also have the option of deactivating log management completely; however, this must be used
with caution.
◼ Log information is no longer written to the log volume; only a small amount of snychronization
information is logged.
◼ Furthermore, time-controlled SAVEPOINTs are no longer executed.
◼ Also take into account that when the database is restarted after a crash, it returns to the status it had
at the last SAVEPOINT and all open transactions are also rolled back.
• It is no longer possible to roll transactions forward.
• This means that you lose information from completed transactions since their results are only
stored in the I/O buffer cache between the SAVEPOINTs and lost when the database crashes.
• Normally, a final SAVEPOINT is written during the database is shut down.
• If db_stop is executed using dbmcli, a SAVEPOINT is not executed.
• You activate and deactivate log management in the ADMIN operational state.

© SAP AG ADM515 3-35

 Changing the Log Mode – Deactivating Logs
-> Caution

© SAP 2008

◼ After successful deactivation, the log status "Redo log management is deactivated" is displayed.
◼ Deactivating log management affects the backup history in the same way as automatically
overwriting the log. A Histlost entry is generated.
◼ Note the risks of deactivating log management, which are explained on the previous pages.

© SAP AG ADM515 3-36

 Loading System Tables on the Console

You can load system tables:

◼ On the console using dbmcli
◼ Using Database Studio

It is particularly important to do this after the database software is updated.

© SAP 2008

◼ The update tools of MaxDB (here SDBUPD) automatically carry out this important update of
system tables as a final activity. Only with SDBINST are the system tables not updated
automatically; in this case, a manual update is required.
◼ The system tables can be updated and loaded at any time when the database is ONLINE.

© SAP AG ADM515 3-37

 Loading System Tables in Database Studio

© SAP 2008

◼ You cannot transfer user information to the process using Database Studio. These entries are
determined internally.

© SAP AG ADM515 3-38

 Using MaxDB: Unit Overview Diagram

Using MaxDB
Topic 1: Overview of Database Studio
Topic 2: Important Sources of Information in Database Studio
Topic 3: MaxDB Users in the SAP Environment
Topic 4: Administration of Disk Areas for Data and Logs
Topic 5: Configuration Changes
Topic 6: DB FULL and LOG FULL Situations
Topic 7: Parameters
Topic 8: Tools for Exercises

© SAP 2008

© SAP AG ADM515 3-39

 FULL Situations

Data

Log
© SAP 2008

◼ FULL situations can occur in both the data and log areas.
◼ Important: With smaller database installations, DB FULL situations can already occur before
100% of the log is used since parts of the log and data areas are reserved and cannot be used by the
user tasks. The reserved areas ensure, for example, that the database can be still shut down if a LOG
FULL situation occurs.
◼ The tasks resume only after the DB FULL or LOG FULL situation has been rectified.
◼ The analysis is usually performed in Database Studio directly where the results are clearly
displayed. If this is not possible, the analysis can be performed using the process list and the
Database Messages file. These are shown on the following slide.

© SAP AG ADM515 3-40

 Analyzing DB FULL Situations – Task List

ACTIVE

TASKS
© SAP 2008

◼ In the process list of active tasks (ACTIVE), you can identify which tasks have stopped because the
log area is full and why.
◼ The process list (TASKS) shows which actions are being carried out in the database.
◼ In this example, the user process (T82: User) has stopped due to a DB FULL situation.
◼ Using APPL-pid, you can find out who caused this situation in the SAP NetWeaver system.
◼ It may have only been caused by the person who happened to request the last free database page.

© SAP AG ADM515 3-41

 Analyzing LOG FULL Situations – Task List

ACTIVE

TASKS
© SAP 2008

◼ You can also display this data on the database server directly using
x_cons <SID> show tasks
or
x_cons <SID> show active

◼ If you are working on a remote database server, use:

dbmcli –U c show tasks
or
dbmcli –U c show active
◼ Using the application PID, you can determine which process is responsible for this situation at
operating system level.

© SAP AG ADM515 3-42

 DB FULL Situation in the Database Messages

© SAP 2008

◼ You can also identify DB FULL and LOG FULL situations by searching for relevant messages in
Database Messages.
◼ Warnings of a DB FULL situation are already output here earlier.

© SAP AG ADM515 3-43

 LOG FULL Situation in the Database Messages

© SAP 2008

◼ Here, you see an example of a LOG FULL situation.

◼ Relevant messages are normally logged long before this situation occurs: Messages are already
generated when 50 percent of the log area is full.

© SAP AG ADM515 3-44

 Reasons for Suspend Situations

© SAP 2008

◼ In the same way, you can display a list of suspend reasons using x_cons <SID> show SUSPENDS.
◼ The analysis shows the situations in which the kernel was suspended since it started and for how
long. The data is converted into a percentage.
◼ The database spent almost 28% of its short operating time waiting for entries to be written to the log
The remaining time was spent waiting for work and writing data.

© SAP AG ADM515 3-45

 Rectifying DB FULL Situations

You resolve the problem by adding one or more data volumes.

You do not need to restart the database.

The database instance simply waits for new disk space to be added.

© SAP 2008

© SAP AG ADM515 3-46

 Rectifying LOG FULL Situations

LOG FULL situation has occurred

◼ Last log entry that was not backed up
Log 1 ◼ Current write position in log area

Log volume added

◼ Does not resolve the problem since the new log volume cannot
be added to the logic
Log 2 Log 1
Instead: back up the log

LOGSAVE.001
LOGSAVE.002
LOGSAVE.003
BACKUP
Log 2 Log 1
◼ Frees the position in the existing log volume of log entries for
the new volume

Integrate the new log volume in the log area

Log 1 & 2

© SAP 2008

◼ After learning about how you can add data volumes, you might think that adding an additional log
volume can rectify a LOG FULL situation.
◼ Unfortunately, this does not help: The current write position in the log volume is variable and
located anywhere in the used log volume when the LOG FULL occurs. The log entries are written
cyclically. This means that you cannot add the new log volume directly at the current write position
(physically or logically), but at the end or beginning of the cycle to continue writing seamlessly.
◼ The only way to rectify the LOG FULL situation is to perform an interactive log backup of the
entire log area. Only then can you integrate and use the new log volume.
◼ If no new log volume is to be integrated, you can also just reactivate the automatic log backup with
a functioning backup medium.
◼ To perform any of these backup actions, one prerequisite must be met: An intact backup history
is required with an initial, complete data backup and any subsequent incremental data backups.
◼ If you create a new database instance in test databases and fill the entire log area immediately, the
first solution described here may resolve the problem. In this case, the current write position is
exactly where the log volume is physically connected, which means the new log volume can be
integrated directly. However, this is a special case.

© SAP AG ADM515 3-47

 Using MaxDB: Unit Overview Diagram

Using MaxDB
Topic 1: Overview of Database Studio
Topic 2: Important Sources of Information in Database Studio
Topic 3: MaxDB Users in the SAP Environment
Topic 4: Disk Areas for Data and Logs
Topic 5: Configuration Changes
Topic 6: DB FULL and LOG FULL Situations
Topic 7: Database Parameters
Topic 8: Tools for Exercises

© SAP 2008

◼ For more information, see SAP Note 1139904 (FAQ: MaxDB/liveCache kernel parameters).
◼ See also SAP Note 1004886 (MaxDB Version 7.7 parameter recommendations)
◼ SAP Notes with similar parameter recommendations are available for all MaxDB database releases;
for example, MaxDB 7.6: SAP Note 814704 (MaxDB Version 7.6 parameter settings for
OLTP/BW).

© SAP AG ADM515 3-48

 Database Parameters

To reduce TCO, the number of parameters has been reduced and the related
functions automated.

Parameters are used for:

◼ System configuration settings
◼ Caches and other memory structures
◼ Threading, CPU load
◼ I/O, communication using SQL
◼ Logging strategies
◼ Optimizer functions (for SQL statements)

Database memory consumption is controlled using database parameters.

© SAP 2008

◼ The software is shipped with the optimal values for the respective operating system platform.
◼ Sizes are specified in data pages or kilobytes. For more information about these units, see the
parameter descriptions, for example.
◼ Many of the existing parameters are calculated automatically based on predefined dependencies and
relationships between parameters, which means they do not have to be set explicitly.

© SAP AG ADM515 3-49

 Parameter Classification

© SAP 2008

◼ Database parameters are divided into three classes:

• General Parameters
These parameters are set by the database administrator.
• Special Parameters (Extended)
These parameters are set in consultation with MaxDB Support or by the database administrator in
accordance with the instructions in SAP Notes.
• Support Parameters
These parameters are set by MaxDB Support or the developers.

© SAP AG ADM515 3-50

 Parameter History

© SAP 2008

◼ Database Studio also provides history data for the parameters.

◼ It allows you to trace all changes made to parameters since the database instance was created on this
server.
• For example, based on the history data for the "KernelVersion" parameter, you can determine
which database version was upgraded by a patch and when.

© SAP AG ADM515 3-51

 Searching for Parameters

© SAP 2008

◼ A useful way to find parameters is provided in the new View All area in combination with the Filter field. You
can enter fragments of parameter names and Database Studio then displays all parameters that contain this
fragment.
◼ Alternatively, you can obtain the new parameters names by executing the param_getfull dbmcli command with
the old parameter name from MaxDB <= 7.6:
dbmcli -U c param_getfull MAXLOCKS
OK
int
2500
4040
ID MaxSQLLocks
CHANGE OFFLINE
INTERN NO
MANDATORY YES
CLEAR NO
DYNAMIC NO
CASESENSITIVE NO
DEVSPACE NO
MODIFY YES
GROUP GENERAL
DISPLAYNAME
VALUESET
MAX
MIN
INSTANCES
SCOPE INSTANCE
DEPRECATEDID MAXLOCKS
USERDEFINED NO
CLASS GENERAL TRANSACTIONS SYNCHRONISATION
LASTKNOWNGOOD 4040
ACTIVEVALUE 4040
…
© SAP AG ADM515 3-52
 Changing Parameters

Database Studio Parameters Database Manager CLI

Example in the Database Manager CLI:

Call dbmcli –d <SID> –u user,password
Display all param_directgetall
Display param_directget CacheMemorySize
Change param_put CacheMemorySize 100000
Check (important) param_checkall

Take effect after restart from the OFFLINE operational state

© SAP 2008

◼ Database Studio allows you to read and change parameter values. Some changes take effect
immediately, while others are applied only after the database instance is restarted from the
OFFLINE operational state.
◼ With the Database Manager CLI, you can change parameters directly or in a parameter session. In a
parameter session, all changes are made valid with a COMMIT or invalid (reset) with an ABORT.
param_startsession Starts a parameter session
param_commitsession Ends the session and saves the new values
param_abortsession Terminates the session and discards the changes
param_getvalue Displays a parameter value
param_put Changes the value of a parameter
param_restore Resets the parameters to the previous values
help param Displays additional commands
• After making changes to parameters, you can check the new values using param_checkall. The
system recalculates dependent parameters at this point. If param_checkall was not executed, the
"Shareddynpool too small" error may be displayed when the database is next restarted.
◼ Database Studio performs this parameter check (param_checkall) automatically.
◼ The parameter file is stored in binary format: <independent_data_path>/config/<database>
◼ A backup is created every time a parameter is changed: <database>.<number>
◼ With the param_restore <generation number> dbmcli command, you can restore a parameter to
previous versions (generation numbers). Note that any volumes, for example, added in the meantime
must be then added manually.

© SAP AG ADM515 3-53

 New Parameter Names

UKT and Task Configuration

MaxCPUs MaxExclusiveLockCollisionLoops
UKT1
UKT1 UKTn
UKTn Console
Console
MaxUserTasks
SessionTimeout Requester
Requester Coordinator
Coordinator

Caches and Memory Sizes Lock Behavior

CacheMemorySize MaxSQLLocks
I/O
I/O Buffer
Buffer Cache
Cache
CAT_CACHE_SUPPLY RequestTimeout
UseSharedSQL Catalog
Catalog Cache
Cache DeadlockDetectionLevel
SharedSQL
SharedSQL &
& Hashing
Hashing
Volume Parameters
MaxLogVolumes MaxDataVolumes
AutoLogBackupSize LOG DATA n
.
.
LogQueues FormatDataVolume
LOG' DATA 1
LogQueueSize VolumeFormattingMode
Analysis Backup Media
RunDirectoryPath MaxBackupMedia
KernelMessageFileSize
DiagnoseHistoryPath

© SAP 2008

◼ The following parameters are especially important:

• MaxCPUs Number of CPUs to which the user tasks are distributed
• MaxUserTasks Maximum number of parallel user sessions
• SessionTimeOut Period of inactivity after which a session is ended
• CacheMemorySize Size of the data cache (in 8 KB pages)
• CAT_CACHE_SUPPLY Size of the catalog cache for all user tasks (in 8 KB pages)
• UseSharedSQL Whether SharedSQL is used
• HashedResultsetCacheSize Size of the memory area for the SQL hashing
• RequestTimeout Maximum wait time before a lock is released (in seconds)
• DeadlockDetectionLevel Analysis depth for deadlock detection
• MaxSQLLocks Maximum number of possible locks on tables and rows
• MaxDataVolumes Maximum number of data volumes
• MaxLogVolumes Maximum number of log volumes
• AutoLogBackupSize Maximum size of individual log backup files
• LogQueues Number of log queues used
• LogQueueSize Size of log queues
• UseLobClustering Stores binary data as clustered BLOBs in the data volumes
• MaxBackupMedia Maximum number of parallel backup media
• RunDirectoryPath Run directory of the database instance, storage location of
diagnosis files
• KernelMessageFileSize Size of the "knldiag" diagnosis file (in the run directory)
• DiagnoseHistoryPath Defines the location where extra diagnosis files are backed up after
a crash

© SAP AG ADM515 3-54

 Database Parameters That Can Be Changed
Online

◼ Many database parameters can be changed

while the database is running in ONLINE mode.
◼ This feature is generally conceivable for all
parameters that do not cause changes in the
memory layout, for example, Optimizer
behavior, trace or analysis settings, and so on.
◼ This option is possible if the "Running" option is
available for selection in the parameter settings.

◼ You can now also enter background information

about the parameter change in the parameter
settings directly.

dbmcli –U c …
param_put [<durability>] <parameter_name> <new_value> [<comment>]

<durability>::= -running | -permanent | -running –permanent

© SAP 2008

© SAP AG ADM515 3-55

 Database Parameters That Can Be Changed
Online
◼ You can display a list of all database parameters that can be changed online in
system table ACTIVECONFIGURATION.
◼ YES is entered in the CHANGEABLE column for parameters that can be changed
online.
◼ Old database parameters are indicated here by a YES entry in the DEPRECATED
column.

© SAP 2008

© SAP AG ADM515 3-56

 General MaxDB Parameter Check

◼ Ifrequired, you can check the current configuration of database parameters using
Database Analyzer.
◼ It displays a list of recommended parameter changes.
◼ For more information about checking parameters using DB Analyzer, see SAP Note
1111426.
◼ The "dbanalyzer.cfg" files in the SAP Note provide updated parameter
recommendations.
◼ The "param_getfull" dbmcli command displays the old and new parameter names.

© SAP 2008

◼ To display the old and new parameter names: dbmcli – U c param_getfull <parameter name>
◼ Example:
dbmcli – U c param_getfull CACHE_SIZE
…
ID CacheSizeMemory
…
DEPRECIATEDID CACHE_SIZE
…

© SAP AG ADM515 3-57

 Using MaxDB: Unit Overview Diagram

Using MaxDB
Topic 1: Overview of Database Studio
Topic 2: Important Sources of Information in Database Studio
Topic 3: MaxDB Users in the SAP Environment
Topic 4: Disk Areas for Data and Logs
Topic 5: Configuration Changes
Topic 6: DB FULL and LOG FULL Situations
Topic 7: Database Parameters
Topic 8: Tools for Exercises

© SAP 2008

© SAP AG ADM515 3-58

 Tools for Exercises

◼ Setting the shell environment (already predefined):

set PYTHONPATH=G:\sapdb\<SID>\db\lib\python2.3

◼ All Python commands (x_python) must be executed in the %PYTHONPATH% directory.

cd \d %PYTHONPATH%

◼ Filling the data and log volumes:

x_python filldb.py -d <SID>

-u <sql-user>,<password> -data

x_python filldb.py -d <SID>

-u <sql-user>,<password> -log

◼ Additional options:

x_python filldb.py -help

© SAP 2008

◼ The tool stores test data in the FILLTABLE table.

© SAP AG ADM515 3-59

 Using MaxDB: Summary

You are now able to:

◼ Use Database Studio and find important information
◼ Resolve exceptional situations when using the database

© SAP 2008

© SAP AG ADM515 3-60

 Exercises

Unit: 2
Topic: Using MaxDB

After completing these exercises, you will be able to:

• Change or extend the configuration of the <SID> database to meet the
requirements of database operations
• Handle the first few exceptional situations that occur

In normal database operation, you need to adjust the configuration of the

database to meet the growing requirements of the applications. How you
can do this using MaxDB is presented and demonstrated here.

2-1 Set up automatic logon with the XUSER tool.

2-1-1 Log on to the database server using the console (telnet).
2-1-2 Run the XUSER tool and check the user keys defined.
2-1-3 Enter the following standard entries in the XUSER tool if they do not yet
exist (SAP Note 39439):

Passwor ServerD Serverno

Userkey UserID SQLmode
d B de
DEFAU SAP<SID <hostname
sap T<xx> SAPR3
LT > >
CONTRO <hostname INTERNA
c control T<xx>
L > L
SUPERD <hostname INTERNA
w admin T<xx>
BA > L
<hostname INTERNA
domain DOMAIN domain T<xx>
> L
SAP<SID <hostname INTERNA
<SID> sap T<xx>
> > L
Refer to the syntax of the XUSER tool provided in Unit 2.
2-1-4 Test the data entered by executing the following commands:
dbmcli -U c db_state
and
dbmcli -U c –USQL DEFAULT sql_execute “select * from users“
or
sqlcli -U DEFAULT “select * from users“.
What data is output when you execute these commands?
© SAP AG ADM515 3-61
 2-2 Start Database Studio and determine table data.
2-2-1 Start Database Studio.
2-2-2 On the <hostname> database server, connect to your <SID> database and
open an SQL Editor from the context menu. When you execute the
command using the exclamation point (!), use the “SAP<SID>” user and
the corresponding default password.
2-2-3 Execute the select * from users SQL command and check the users in the
database.

2-3 Rename a database user.

2-3-1 In Database Studio, use the SQL Editor to rename the “SAP<SID>”
database user. To do so, log on with the “superdba” user.
2-3-2 First, rename the “SAP<SID>” user with the command: rename user
sapt<xx> to sapr3
2-3-3 Alternatively, rename the user using dbmcli:
dbmcli -U c –USQL w sql_execute “<SQL statement>“.
2-3-4 Undo your changes using
rename user sapr3 to sapt<xx>
dbmcli -U c –USQL w sql_execute “<SQL statement>“
to send the SQL commands from the previous exercise to the database.

2-4 Test the XUSER function after changing the password of the “SAP<SID>” user.
2-4-1 In Database Studio, log on to the SQL Editor as the “SAP<SID>” user.
Change the password of the “SAP<SID>” user with the SQL command
alter password <current> to <new>.
2-4-2 Retest the automated logon procedure using
dbmcli -U c –USQL DEFAULT sql_execute “select * from users“.
2-4-3 Adjust the XUSER data to match the new password and test again.

2-5 Restore the original setting for the other exercises.

2-5-1 Use dbmcli, for example, to change the password for the “SAP<SID>” user
back to the default password (sap) so that the other exercises can be carried
out as prepared.

2-6 Using Database Studio, check the configuration of the <SID> database.
2-6-1 Where are the data and log volumes located?
2-6-2 Where are the instance-dependent software for your instance and the
instance-independent software stored?
2-6-3 Where are the configuration and log files located?

© SAP AG ADM515 3-62

 2-7 Obtain a list of the database tasks.
2-7-1 To obtain an overview of the tasks in the database, display the list of all
tasks (TASKS) or, alternatively, only the active tasks (ACTIVE) in
Database Studio.
2-7-2 You can also display these lists on the console using
dbmcli -U c show tasks
or
dbmcli -U c show active.

2-8 Obtain the list of parameters.

2-8-1 Using Database Studio, obtain a list of all parameters.
2-8-2 Execute the relevant dbmcli command to obtain the list of parameters.
2-8-3 Are all parameters output by the dbmcli command displayed in the
parameter management area of Database Studio?

2-9 Adjust and activate parameters.

2-9-1 Note the current value for the “MaxUserTasks” parameter and change it to
2 to simulate a lack of free user tasks, for example.
2-9-2 Restart the database so that the changes take effect.
2-9-3 Start multiple dbmcli sessions to determine the point at which it is no
longer possible to connect to the database:
dbmcli –U c –USQL DEFAULT [ENTER]
2-9-4 Using dbmcli, restore the parameter to its original setting. What do you
have to consider to ensure that the parameter is fully converted?

2-10 Determine important installation data for the database instance using dbmcli.
2-10-1 Use dbmcli to determine the IndepDataPath and IndepProgPath paths.
2-10-2 What is the INSTROOT for your database instance (determine using
dbmcli)?

2-11 Obtain information about the data and log areas.

2-11-1 Some information in the database is already prepared in clearly arranged
lists. You can obtain a list of the available information using
dbmcli –U c info infos.
2-11-2 Check the data output by the following commands:
dbmcli -U c info data
and
dbmcli –U c info log.
Can you also find this information in Database Studio?

© SAP AG ADM515 3-63

 2-12 Add volumes.
2-12-1 Using Database Studio, increase the size of the database by 100% while it
is running.
2-12-2 Create the data volume in the same location as the previous volume.
2-12-3 What can slow down the extension of the database?
2-12-4 Delete the volume you just created.

2-13 Fill the database and simulate a DB FULL situation.

You can fill the database using the command
cd /d %PYTHONPATH%
x_python filldb.py –d <SID> -u sarp<sid>,sap –data You can increase the size of
the packages added to the database using the –R <number> option. Keep executing
this command until it hangs. You can also use “filldb.py” to view the available
database capacity.
2-13-1 In the meantime, you can use Database Studio to monitor the status of the
data area.
Analyze the DB FULL situation using the methods described in the
training materials.

2-14 Resolve the DB FULL situation by extending the database.

2-14-1 While the database is running, add another data volume to it as described in
the training materials. Monitor both the command line and Database
Studio.

2-15 Generate a LOG FULL situation and then rectify it.

Important: Before you can simulate a LOG FULL situation, you have to deactivate
the automatic log backup.
You can fill the database log using the command
x_python filldb.py –d <SID> -u sarp<sid>,sap –log You can increase the size of the
packages using the –R <number> option. Execute this command repeatedly until it
hangs. You can monitor the status of the log area at the same time in Database
Studio.
2-15-1 Extend the database by an additional volume while it is running, as
described in the training materials. Monitor both the command line and
Database Studio. Does extending the database resolve the problem?
2-15-2 If this does not rectify the situation (this only works in special cases),
activate the automatic log backup. The fill tool on the console should now
be able to write to the database again.

2-16 Optional: change the log mode.

2-16-1Change the log mode to overwrite mode and then back, as described in the
training materials.
2-16-2 How does this affect the backup history?

© SAP AG ADM515 3-64

 Solutions

Unit: 2
Topic: Using MaxDB

2-1 Set up automatic logon with the XUSER tool.

2-1-1 Connect the console (telnet) to the database server.
2-1-2 The passwords of all users who want to log on to the database using this
automated procedure must be maintained in the XUSER area as follows. If
a different user was used for the initial logon, you can correct this by
adjusting the initial (DEFAULT) user key. You can obtain a list of
currently available XUSER entries using xuser list. For detailed help, use
xuser –h.
2-1-3 SAP applications generally use the XUSER function to log on to the
database. Normally, the DEFAULT user key is used. However, additional
(c-, w-) user keys are required in the CCMS environment to obtain detailed
information from the database. Note that user keys are case sensitive.
2-1-4 When commands are executed, the “c” user key is used to log on. With the
second command, an implicit logon is also carried out using the DEFAULT
user key to send the SQL statement to the database.

2-2 Start Database Studio and determine table data.

2-2-1 Database Studio is installed on the terminal server. Call it by choosing
Start → Training → MaxDB → Database Studio.
2-2-2 Open an SQL editor for the database from the context menu. When you
execute the command using the exclamation point (!), use the “SAP<SID>”
user and the corresponding default password. The control administration
user is not authorized to execute SQL statements in the database.
2-2-3 The users object displays internal structures. This means that this data can
only be viewed and not changed. You can view additional MaxDB system
tables using the Database Studio tree structure.

2-3 Rename a database user.

2-3-1 In Database Studio, open an SQL Editor from the context menu of your
instance.
Use the “superdba” user and default password “admin” to execute the
following SQL commands.
2-3-2 Using the SQL Editor, enter the following SQL statement:
rename user sap<sid> to sapr3. Execute this statement by choosing the red
exclamation point.
2-3-3 The complete dbmcli command is:
dbmcli -U c –USQL w sql_execute “rename user sap<sid> to sapr3“.
© SAP AG ADM515 3-65
 2-3-4 Undo your changes with the command: rename user sapr3 to sap<sid>

2-4 Test the XUSER function after changing the password of the “SAP<SID>” user.
2-4-1 In Database Studio, open a new SQL Editor. With the new SQL Editor, you
can also specify a new connect user for logging on later. Use the
“sap<sid>” user here. With the SAP<SID> user, execute the command
alter password <current> to <new> SQL . Alternatively, you can also use
the dbmcli command:
dbmcli -U c –USQL DEFAULT sql_execute “alter password <current> to
<new>“.
2-4-2 It should no longer be possible to connect using the old XUSER data.
2-4-3 After you have made the modifications with the XUSER tool, as described
previously, the automated connection to the database functions again. You
have to adjust the XUSER data using the XUSER tool, so that the
DEFAULT entry includes the new “SAP<SID>” password.

2-5 Restore the original setting for the other exercises.

2-5-1 Use the same syntax to restore the original passwords in the database and
the XUSER data.

2-6 Using Database Studio, check the configuration of the <SID> database.
2-6-1 Data volumes: G:\sapdb\<SID>\sapdata\...
Log volumes: G:\sapdb\<SID>\saplog\...
2-6-2 Instance-dependent software: G:\sapdb\<SID>\db\...
Instance-independent software: G:\sapdb\programs\...
2-6-3 Configuration files: G:\sapdb\data\config\...
Cross-instance logs: G:\sapdb\data\wrk\...
Instance-dependent logs: G:\sapdb\data\wrk\<SID>\...

2-7 Obtain a list of the database tasks.

2-7-1 In the menu tree, select the CONTROL user for your database instance and
find the following entries:
Database Server → TASKS
and
Database Server → ACTIVE
2-7-2 The same data is output as for x_cons <SID> show tasks or show active.

2-8 Obtain the list of parameters.

2-8-1 In Database Studio, go to the “Administration” tab page for your instance
and choose Parameter → View All.
2-8-2 The relevant dbmcli command is:
dbmcli -U c param_directgetall.

© SAP AG ADM515 3-66

 2-8-3 When you first call up the parameters in Database Studio, only a list of
general parameters is initially displayed. You have to choose additional
menu options to display the remaining parameters or a complete list. The
special feature of Database Studio is that you can now filter the complete
list by name fragments.

2-9 Adjust and activate parameters.

2-9-1 Go to the “Administration” tab page for your instance and edit the
MaxUserTasks parameter as described in the exercise.
2-9-2 After changing the parameter, save it and restart the database in the
ONLINE operational state by choosing Set State → Offline followed by
Set State → Online. You can also use the following dbmcli commands:
dbmcli -U c db_offline
and
dbmcli -U c db_online.
2-9-3 Open multiple consoles to the database server and connect to the database
in each case using the following command:
dbmcli -U c –USQL DEFAULT [Enter]. You can establish only as many
database connections as you have configured.
2-9-4 End all dbmcli sessions by entering exit when prompted by the dbmcli and
execute the following command:
dbmcli -U c param_put MaxUserTasks <previously determined value>. If
you use dbmcli, you must check the parameter dependencies after changing
the parameter values. This check also collects the memory required
internally and requests the appropriate amount of memory when you restart
the database and the parameter change takes effect. Execute the parameter
check using
dbmcli -U c param_checkall
(Database Studio performs this check automatically).
Then restart the database:
dbmcli -U c db_offline
and
dbmcli -U c db_online.

2-10 Using dbmcli, collect important installation data for the database instance.
2-10-1 Use the following dbmcli commands:
dbmcli dbm_getpath IndepDataPath
and
dbmcli dbm_getpath IndepProgPath.
2-10-2 Command for collecting information:
dbmcli -U c dbm_version INSTROOT.

2-11 Obtain information about the data and log areas.

2-11-1 The “–c” option of this dbmcli command indicates that the actual command
that dbmcli has to process begins next.

© SAP AG ADM515 3-67

 2-11-2 You can also find this information in Database Studio on the
“Administration” tab page by choosing
→ Data Area
or → Log Area.
2-12 Add volumes.
2-12-1 In Database Studio, go to the “Administration” tab page for your instance
and choose Parameter → View All.
Display the following parameters:
MaxDataVolumes
MaxLogVolumes.
Note the current values for these parameters.

2-12-2 In Database Studio, go to the “Administration” tab page for your instance
and choose Data Area. Select an unused but prepared volume entry and
choose New. Set up this volume in the G:\sapdb\<SID>\sapdata\
subdirectory.
2-12-3 After the last reserved volume has been used, the value of the
MaxDataVolumes parameter automatically increases by one when the
volume is set up. However, this parameter change only takes effect when
the database is restarted. The same applies to MaxLogVolumes.
With MaxDB 7.7.04, however, memory performance is no longer affected
if a high value or the maximum value of 255 is set for this parameter.
2-12-4 To delete a volume, select it and choose Delete.
2-13 Fill the database and simulate a DB FULL situation.
To display additional options, use the x_python filldb.py –help command.
2-13-1 Perform the analysis in the instance tree of Database Studio by selecting
the CONTROL user and choosing
Database Server → ACTIVE.
Alternatively, you can use the console with
dbmcli -U c show active.

2-14 Resolve the DB FULL situation by extending the database.

2-14-1 Proceed as described under 2-13. The fill tool remains inactive in the
console until you notice that the volume in the Database Manager GUI has
been completely integrated into the volume administration.

2-15 Generate a LOG FULL situation and then rectify it.

Before you can simulate a LOG FULL situation, you have to deactivate the
automatic log backup.
In Database Studio, go to the “Administration” tab page for your instance, choose
Overview → Settings, and double-click Automatic Log Backup. Select Deactivate
automatic log backup and choose Deactivate.
2-15-1 This procedure normally does not resolve the situation, as explained in the
training materials. It only works in special cases.

© SAP AG ADM515 3-68

 2-15-2 Activate automatic log backup:
In Database Studio, go to the “Administration” tab page for your instance,
choose Overview → Settings, and double-click Automatic Log Backup.
Select Activate automatic log backup and choose Activate.
If the backup history was lost when you previously reconfigured the
database, you do not have an initial complete data backup to use as a basis
for the log backup. This means that you cannot start a log backup and have
no option but to stop the database with db_offline (dbmcli -U c db_offline).
Then start the database in the ADMIN operational state (dbmcli -U c
db_admin) and back up the data and log. You can then restart the database
in the ONLINE operational state (dbmcli -U c db_online).

2-16 Optional: change the log mode.

2-16-1 Go to the “Administration” tab page for your database instance and choose
Log Area. Click the Overwrite Mode: hyperlink and follow the instructions
given in the Wizard (as described in the training materials). The database
instance is restarted when the log mode is changed.
To reset the log mode, follow the instructions in the Wizard again. It is
essential that you then take into account the backup history.

© SAP AG ADM515 3-69

© SAP AG ADM515 3-70