Inside MaxDB

Contents:
◼ Deeper insight into the technical background of MaxDB

© SAP 2008

© SAP AG ADM515 4-1

 Inside MaxDB: Learning Objectives

At the conclusion of this unit, you will be able to:

◼ Explain the technical background of MaxDB

© SAP 2008

© SAP AG ADM515 4-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 4-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 4-4

 Inside MaxDB: Course Overview Diagram

Inside MaxDB
Topic 1: Processes
Topic 2: Locks
Topic 3: Memory Areas
Topic 4: Disk Areas
Topic 5: Logging

© SAP 2008

© SAP AG ADM515 4-5

 Processes

Runtime User Kernel Thread (UKT) Coordinator

Environment
Processes

User Kernel Thread (UKT) – Tasks: Console

(RTE)
(Clock)

Trace Writer
Log Writer
Requester

Garbage
Server

Pager
User

Server

Utility
Pager

Timer
User
IO Threads

I/O Buffer Cache

Caches

Catalog Cache

SharedSQL

Hash Memory Log Queue

Hard Disks

/sapdb -
DATA LOG programs
LOG
etc.

© SAP 2008

© SAP AG ADM515 4-6

 Process Overview

Coordinator
User Kernel Thread (UKT)
Requester Tasks
Console User
User Timer Trace Writer
(Clock)
Server
Server Garbage Log Writer
(IO Threads<i>)
Pager
(IO Worker<i>) Pager Utility

© SAP 2008

◼ The MaxDB database kernel runs as a process that is divided into threads. Threads can be active in
parallel on multiple processors within the operating system.
◼ A distinction is made between user kernel threads (UKTs) and special threads.
◼ User kernel threads (UKTs) each consist of multiple tasks (internal tasking) that fulfill different
requirements. Tasks can be coordinated more effectively than in operating system tasking since
individual threads are used.
◼ The runtime environment (RTE) defines the structure of the process and user kernel threads.

© SAP AG ADM515 4-7

 Special Threads

Coordinator Studio

Client Restart
Requester
Connect

Console knlMSg

Clock / Timer SELECT * FROM ..0.0005 sec.

IO Threads<i> User Kernel Process (UKT)

User Kernel ThreadTasks
(UKT)
Tasks
(IO Worker<i>)
User Timer Trace Writer Pager

Server Garbage Log Writer Utility

© SAP 2008

◼ When the runtime environment is started (that is, when the database instance is started in ADMIN
state), the coordinator thread is generated first. This is especially important.
• When it starts, the coordinator thread uses database parameters to determine the memory and
process configuration of the database instance.
• The coordinator thread also coordinates the start processes of the other threads and monitors
these while the database instance is running.
• If operating errors occur, the coordinator thread can stop other database threads.
◼ The requester thread receives user process logons to the database and assigns them to a task within a
user kernel thread.
◼ The console thread collects important messages from the other threads for the administrator and
places them in the knlMsg file, which is stored in the run directory of the database instance.
◼ The clock or timer thread is used to calculate times internally, for example, to determine how long it
took to execute an SQL statement.

© SAP AG ADM515 4-8

◼ Multiple IO threads are responsible for processing the read and write requests for data and log
volumes that are submitted by the tasks. MaxDB supports asynchronous I/O requests. The IO
system in 7.7.04 is much more flexible and also enables asynchronous IO to be used with UNIX and
the various UNIX derivatives. On Microsoft Windows, asynchronous I/O of the operating system
has been used for some time.
◼ With the restructured IO system of 7.7.04, the number of IO threads is no longer dependent on the
number of volumes in the database instance. A flexible pool of IO threads is usually activated for
the data volumes and every log volume, and these threads are managed by means of a ticket system.
In this way, queues can also be assigned different priorities. When the asynchronous I/O of the
operating system is used, only one IO thread is started in each case, since the asynchronous I/O calls
of the operating system take over the remaining work.
◼ The IO worker processes on Windows then assume the task of transmitting a signal when the
operating system reports an IO order as complete.
◼ The new implementation includes some new internal parameters that provide access to the
automatic control of IO management.

© SAP AG ADM515 4-9

 User Kernel Threads: User Tasks

User Kernel Thread UKT 2 90-95% of the load in

Coordinator
the database instance is
User User
User User generated here
Requester User User
Tasks
Console

Clock / Timer
SELECT * FROM tab
WHERE col1 = 5

IO Threads<i>

(IO Worker<i>) Parameter: MaxCPUs

(in this example =2)

Parameter: MaxUserTasks
(in this example =6)

Parameter: MaxUserTaskStackSize
(usually =1024)
© SAP 2008

◼ Exactly one user task is assigned permanently to every user or application process at logon.
The maximum number of available user tasks depends on the MaxUserTasks database parameter.
This parameter therefore also limits the number of user sessions that can be active simultaneously in
the database system.
◼ The MaxCPUs database parameter specifies the number of user kernel threads across which the user
tasks are distributed. The user tasks generate the main workload. Other tasks and the global threads
use very little CPU time. You can therefore limit the number of processors used in parallel by the
database instance using the MaxCPUs parameter.
◼ However, the CPU load is usually about 10-30% of the overall load.
◼ With the MaxTaskStackSize database parameter (default: 1024 KB), you can estimate the memory
consumption based on the number of user tasks. If the address space or available memory is
restricted, the number of user tasks should therefore not exceed the recommendations of double the
number of work processes in the connected application instances.

© SAP AG ADM515 4-10

 User Kernel Threads: Task Sequence

User Kernel Thread UKT 2 UKT 3

Coordinator
User User Server
User User Server
Requester User User Server
Tasks
Console
UKT 4 User Kernel Thread 1 IO System

Clock / Timer Pager Task1 Task2 Task3

Pager
Pager I/O Query 1 1

IO Thread
I/O Query 2 2

UKT 5

IO Thread
IO Threads<i> I/O Answer 1 3
Floating
FloatingService
(IO Worker<i>) FloatingService
Service I/O Query 3 4
I/O Answer 2 5

IO Thread
I/O Query 1 6

IO Thread
Task running
Task runable
Task waiting t

© SAP 2008

◼ Cooperative multitasking is carried out within the user kernel thread, while the operating system
executes preemptive multitasking between the threads.
◼ This means that only one process can ever be active in the threads and so one or more user tasks
within the same UKT have to wait until a process has ended before the task can take control.
◼ With MaxDB 7.5.0, a new parameter has been introduced that can change this behavior and also
switch to preemptive multitasking within the UKTs. However, this parameter
(UseCoroutineForUserTask) should only be set to NO on liveCache instances or databases that also
perform liveCache functions (see also SAP Note 1038709 - FAQ: SAP MaxDB/liveCache OneDB).
• Advantage: Allows forced interruption of long-running user tasks with liveCache application
functions (LCApps).
• Disadvantage: Stripes (regions) in the database can experience higher collision rates when user
tasks are accessed (other databases also refer to these regions as latches).

© SAP AG ADM515 4-11

 Load Balancing for liveCache

User Kernel Thread UKT 2 Task active

Task ready to start
Task waiting, e.g. for IO
User User Task not used
User User
User User
User User User Kernel Thread UKT 2
User User
User User
User
User User
User User
User User
The entire context of the user task
is transferred User

One usertask is migrated with each action

For MaxDB (OLTP), this function is too slow

◼ SQL statements are usually processed faster than required by the switch
process.
◼ SQL statements often need to access disks, which automatically causes a
switch in the UKT.

© SAP 2008

◼ In the liveCache environment, this function is often used to move user tasks between UKTs. The
liveCache application routines (LCApps) can run for hours and process a lot of data from the cache.
It is worth thinking here about moving to UKTs with no load and thus CPUs.
◼ After the switch process, the entire context (memory and so on) of the user task belongs to the
environment of the new user kernel thread.
◼ Database parameters that are used here:
• LoadBalancingCheckLevel – Load balancing is activated with values from 4 to 600 seconds. The
value is the wait time between measurement points.
• LoadBalancingWorkloadDeviation – Describes the required difference (percentage) in the
internal runtime of UKTs, below which the UKTs are considered equal (default 5%).
• LoadBalancingWorkloadThreshold – Load difference (percentage) between UKTs before load
balancing is even considered (default 10%).
◼ More information about this topic is covered in TEWA60 (liveCache Monitoring and Performance
Optimization).

© SAP AG ADM515 4-12

 User Kernel Threads: Server Tasks

Coordinator User Kernel Thread UKT 2 UKT 3

User User Server

User User Server
Requester User User Server

Console

Clock / Timer

Drop
Table/Index
IO Threads<i>

(IO Worker<i>) DATA

Create Check Data
Index (Verify)

© SAP 2008

◼ Server tasks are used to carry out administrative tasks in the MaxDB instance. Some server tasks
control how data is read from the data volumes, while others control how data is written to the
backup medium.
◼ When the CREATE INDEX statement and asynchronous DROP INDEX or DROP TABLE
statements are executed, the server tasks receive a request to read the table data in parallel from the
data volumes or to delete it asynchronously The server task also handles the statements executed to
check data (Verify).
◼ As of MaxDB Version 7.6.05, the server tasks were also responsible for PreFetching. This function
will also soon be made available in MaxDB 7.7 (MaxDB 7.7.06).
◼ The system automatically calculates the number of server tasks when the database instance is
configured based on the number of data volumes and anticipated number of backup devices.
You can set a higher number using the MaxServerTasks parameter.
◼ As usual, the read and write actions are not completed by the server task itself. Instead, they are
transferred to the IO threads.
◼ With MaxDB 7.5, the server tasks can also be distributed to more UKTs (that is, more CPUs) in
special situations where the server tasks only block each other. The MaxDB parameter used here is
EnableMultipleServerTaskUKT. This option is mainly used for migrations.

© SAP AG ADM515 4-13

 Appendix: New Server Task Types

Display Long Name Description

"PrefBlb" "Prefetch Blob" Prefetch of BLOB when returning last part to appl.

"PrefSel" "Prefetch Select" Prefetching records when scanning

"PrefPag" "Prefetch Pages"

"PrefOCo" "Prefetch Objects Coordinator"

"AutoLgW" "Autosave Log Writer" Writes Log pages to the backup medium

"AutoLgW" "Autosave Log Reader" Reads Log pages from the log volumes

"BUPmed" "Backup / Restore Medium Task" Reads/Writes from/to a data backup medium

"BUPvol" "Backup / Restore Volume Task" Reads/Writes from/to data volumes for backup

"ChkData" "Check Data" Checks a B*Tree

"CrIndex" "Create Index" Parallel Create Index

"DropAux" "Drop Auxiliary Files" Performs Drop Table in background

"PrefObj" "Prefetch Objects" Prefetch liveCache objects after restart

© SAP 2008

◼ List of possible server task statuses in the task list of MaxDB task manager.
◼ You can see the numerous prefetch task types for preparing diverse processes within the database.

© SAP AG ADM515 4-14

 Appendix: New Server Task Types (Continued)

Display Long Name Description

"RedoRea" "RedoLog Reader" Reads from log volume or log file during restore

"RedoExe" "RedoLog Execution Task" Executes redo of log entries

"StdbyRC" "Standby Restart Coordinator" Coordinates a takeover in a Hot Standby system

"StdbySy" "Standby Synchronize Server" Waits for sync calls from a Hot Standby master

"Savepnt" "Savepoint Coordinator" Coordinates the phases of a savepoint

"JoinInS" "Join Index Select" Perform parallel join via index

"UpdStat" "Update Statistics" Perform parallel update statistics

"DropVol" "Drop Volume" Drops a volume

"UpdCnt" "Update Counter" Scans tables to read counters.

© SAP 2008

◼ Continuation of list.

© SAP AG ADM515 4-15

 Pager and Timer Task

Coordinator User Kernel Thread UKT 2 UKT 3

User User Server

User User Server
Requester User User Server

Console
UKT 4
Session
Clock / Timer Timer
Timeout
Pager
Pager
Pager

IO Threads<i>

(IO Worker<i>)

DATA

© SAP 2008

◼ Pager tasks are responsible for writing data from the IO buffer cache to the data volumes. They
become active when a savepoint is declared.
The number of pagers is calculated by the system. The number depends primarily on the size of the
IO buffer cache and the number of data volumes.
◼ The timer task is used to manage all kinds of timeout situations (such as a session timeout for
connections, request timeout for locks, and so on).

© SAP AG ADM515 4-16

 Analyzer, Log Writer

User Kernel Thread UKT 2 UKT 3

Coordinator
User User Server
User User Server
Requester User User Server

Console
UKT 4 UKT 5 UKT 6
Clock / Timer Timer Floating Service
Floating
Floating Service
Service Log Writer
Pager
Pager
Pager

IO Threads<i>

(IO Worker<i>)
LOG‘

© SAP 2008

◼ Floating services can assume many different functions in the database. The two most important
functions are:
• DBAnalyzer – This enables the database to be monitored extensively and the results to be logged.
• Event management – Enables management functions for operating the database to be triggered
automatically and autonomously, for example, database extension functions and update table
statistics can be executed automatically. However, these functions have not been used to date in
the SAP environment.
◼ The log writer is responsible for writing the after images to the log volumes. It also uses the IO
threads to execute the actual write operations.

© SAP AG ADM515 4-17

 Garbage Collector and Floating Service Task

Coordinator User Kernel Thread UKT 2 UKT 3

User User Server

User User Server
Requester User User Server

Console
UKT 4 UKT 5 UKT 6
Clock / Timer Timer Floating
FloatingService Log Writer
FloatingService
Service
Pager
Pager
Pager

UKT 7
IO Threads<i>

Garbage Collector
(IO Worker<i>)

DATA
© SAP 2008

◼ The familiar garbage collector from liveCache has now been introduced as of MaxDB 7.6 and is
responsible for cleanup actions within the database. It removes superfluous data (history, that is,
before images of transaction logic) from the database. In earlier versions, the user task was
responsible for this, but it can now be executed asynchronously.
◼ See also SAP Note 1247666 – (FAQ: MaxDB/liveCache history pages)

© SAP AG ADM515 4-18

 Trace Writer Task and Utility Task

Coordinator User Kernel Thread UKT 2 UKT 3

User User Server

User User Server
Requester User User Server

Console
UKT 4 UKT 5 UKT 6
Clock / Timer Timer Floating
FloatingService Log Writer
FloatingService
Service
Pager
Pager
Pager

UKT 7 UKT 8 UKT 9

IO Threads<i>

Garbage Collector Trace Writer Utility Task

(IO Worker<i>)

CREATE INSTANCE ...

knltrace ADD VOLUME ...

© SAP 2008

◼ MaxDB provides the option of writing a special log (called the kernel trace) for diagnosis purposes.
If you activate this function, the trace writer task becomes active.
The log data is written to a buffer by the active tasks. The trace writer task writes the data from this
buffer to the knltrace file.
◼ The utility task is reserved exclusively for managing the database instance.
Since only one utility task exists for each database instance, administrative tasks cannot be carried
out in parallel. This prevents conflicts from occurring.
This does not include automatic log backups, which can be performed in parallel to other
administrative tasks. The utility task is used only to activate and deactivate the function for backing
up logs automatically.
◼ In MaxDB 7.5.0 and later, the utility task becomes less and less important and is provided only for
backwards compatibility purposes. The actions previously performed with the utility task can also
be coordinated directly via the DBMServer process by means of db_execute commands. This
process has an internal table that defines which action can be run in parallel with which other
activity.

© SAP AG ADM515 4-19

 Example of a Thread Layout in UNIX

Here is an example of
how tasks are arranged for
a small database instance
in Linux:

© SAP 2008

◼ Here, you see a minimum configuration on Linux, as created without any intervention from the
administrator.
◼ The output can also be determined with the following console command:
x_cons <SID> show rte
or dbmcli –d <SID> -u <controluser, password> show rte

© SAP AG ADM515 4-20

 Example of a Thread Layout in Windows

Here is an example of how

tasks are arranged for the SAP
NetWeaver database DEV in
Windows:

© SAP 2008

◼ Here, SAP NetWeaver is set up for training purposes.

◼ The special threads are listed first. Since this is a Windows system, these threads are followed by the
IO worker processes that support and monitor the asynchronous IO of the operating system. The
layout of the UKTs is shown next.
◼ The following abbreviations are used:
• TW Trace writer
• LW Log writer
• UT Utility task
• SV Server tasks
• FS Floating service
• GC Garbage collector
• TI Timer task
• PG Pager tasks
• US User task
• IDL Idle tasks (preparation for more flexible task management)
◼ Information about how a database instance is used is recorded by DB Analyzer (unit 6) in a time-
based log or can be viewed as a summary in table MACHINEUTILIZATION .

© SAP AG ADM515 4-21

 X Server

User Kernel Thread Thread/Process Layout

Coordinator
User
User Windows
Requester User
◼ serv.exe
Tasks
Console Linux
◼ vserver (watchdog)
Clock / Timer ◼ vserver

UNIX
◼ vserver (watchdog)
xserver
xserver ◼ vserver
X Server
◼ vserver
IO Threads<i>
◼ …
◼ vserver (n+1)
(IO Worker<i>)
x_show
◼ Shows the status of X
Server at the end

© SAP 2008

◼ Access to the database via the network is handled by the vserver (UNIX) or serv.exe (Microsoft
Windows) processes. You can start these server processes manually using the x_server command.
However, they are normally started automatically when the system is started. X server runs as a
service on Windows.
◼ A new X server process is created for every user process that logs on to the database remotely. The
generating process serves the user; the new process waits for the next user logon. These processes
are identified based on the implementation (UNIX), or threading is used and the processes are
implemented as a thread within the process (Linux, Microsoft Windows).
◼ By default, remote accesses are allowed as soon as X server is started. With the xtcpupd program,
however, you can activate or deactivate "remote SQL" access on Windows, that is, allow or deny
access to the database instances via a network.
◼ You can determine the status of X server using the x_show tool. The status information is displayed
at the end of the output.
◼ With the –r and –v options of x_show, you can obtain more information about X server on
Windows.
◼ For analysis purposes, you can also activate a trace level for X server while it is running: x_server –
N <Tracelevel 0…9>
In this way, for example, you can check which accesses are made to the database instance. This
information is logged in the file /sapdb/data/wrk/xserver_<hostname>.prt.

© SAP AG ADM515 4-22

 SSL-Secured Connections

The client can be connected to the server

with SSL encryption (optional).

The encrypted tunnel is established on the

database server between the client programs
(Database Studio, dbmcli, SQLDBC, and so
on) and the X server on the database server.

Additional libraries are required to use the

strong encryption.

The encryption is activated:

◼ During the logon process in the client tool
settings
◼ With the dbmcli option –e SSL.
◼
With Database Studio in the login window
◼ For SAP NetWeaver (SQLDBC), with the X user
function

© SAP 2008

◼ To use the SSL tunnel, additional encryption libraries from SAP are required. These are delivered
on special media. The usual export restrictions with regard to “strong encryption” apply. The
libraries can be found on SAP Service Marketplace at http://service.sap.com/swdc → Downloads →
SAP Cryptographic Software (SAP Note 455033).
◼ If the libraries are not found, the X server still works but a warning message is displayed (WNG
12453 NISSLSRV NISSL Init: SSL: Could not locate licence file). For more information, see SAP
Note 1032643.
◼ Activating encryption affects performance (about 20% more workload).

© SAP AG ADM515 4-23

 Inside MaxDB: Course Overview Diagram

Inside MaxDB
Topic 1: Processes
Topic 2: Locks
Topic 3: Memory Areas
Topic 4: Disk Areas
Topic 5: Logging

© SAP 2008

◼ See also SAP Note 1243937 - (FAQ: MaxDB SQL locks)

© SAP AG ADM515 4-24

 Locking Data Records with MaxDB

Every lock request to change a data record MaxDB parameter

in any table is stored in the lock list. MaxSQLLocks

In the administration, locks appear as:

Lock list
◼ Row locks (row_exclusive)
◼ Table locks (tab_exclusive) Processes
◼ Catalog locks (sys_exclusive)

The size of the lock list is controlled by the

20%
MaxDB parameter MaxSQLLocks. Table

◼ A typical value is 300,000 to 500,000 for SAP 10%

NetWeaver installations.
◼ Larger values are possible
0
◼ A lock entry comprises approximately 200 bytes
in the main memory.
Process

© SAP 2008

◼ With the SQL command select * from lockliststatistics, you can determine more information from lock
management:
DESCRIPTION VALUE
MAX LOCKS 300000
TRANS LIST REGIONS 8
TABLE LIST REGIONS 8
ROW LIST REGIONS 8
ENTRIES 902400
USED ENTRIES 0
USED ENTRIES (%) 0
AVG USED ENTRIES 15
AVG USED ENTRIES (%) 0
MAX USED ENTRIES 25500
MAX USED ENTRIES (%) 3
OMS SHARE LOCK CONTROL ENTRIES 0
OMS SHARE LOCK CONTROL ENTRIES USED 0
OMS SHARE LOCK ENTRIES 0
OMS SHARE LOCK ENTRIES USED 0
OMS SHARE LOCK COLLISION ENTRIES USED 0
CONSIST VIEW ENTRIES 0
OPEN TRANS ENTRIES 0
LOCK ESCALATION VALUE 60000
LOCK ESCALATIONS 0
SQL LOCK COLLISIONS 63
OMS LOCK COLLISIONS 0
DEADLOCKS 0
SQL REQUEST TIMEOUTS 0
OMS REQUEST TIMEOUTS 0
TRANSACTIONS HOLDING LOCKS 0
TRANSACTIONS REQUESTING LOCKS 0
TRANSACTIONS HOLDING OMS LOCKS 0
CHECKPOINT WANTED FALSE
SHUTDOWN WANTED FALSE

© SAP AG ADM515 4-25

 Locks and Lock Types

SHARED lock
◼ Other transactions can read objects with a SHARED lock but cannot change them.

EXCLUSIVE lock
◼ Other transactions can read the data records but there is a risk that the data records could be changed.

A transaction has set the following ...

Table lock Row lock Catalog locks

Can another transaction … EXCLUSIVE SHARED EXCLUSIVE SHARED EXCLUSIVE SHARED

… lock this table EXCLUSIVELY? No No No No No Yes

… set a SHARED lock for this table? No Yes No Yes No Yes

… lock any row in this table EXCLUSIVELY? No No No Yes

… lock an already locked row EXCLUSIVELY? No No

… lock a different row EXCLUSIVELY? Yes Yes

… set a SHARED lock for any row in this table? Yes Yes Yes Yes

… set a SHARED lock for one single row? No Yes

… set a SHARED lock for a different row? Yes Yes

… change the definition of the table in the catalog? No No No No No No

… read the table definition from the catalog? Yes Yes Yes Yes Yes Yes

© SAP 2008

◼ The different combinations of lock types are listed here.

© SAP AG ADM515 4-26

 Lock Escalation with MaxDB

Lock escalation (LockListEscalation) MaxDB parameter

◼ If 20% of the lock list is used by MaxSQLLocks
one process that is accessing
one table, a lock escalation is triggered.

Lock list
◼ The table is then locked completely and
exclusively for the process. Processes

One tab_exclusive results from several

row_exclusive.

Other databases allow lock lists to grow 20%

considerably, thus threatening overall Table
performance.
10%
With MaxDB, the problems occur only if
one table is accessed; high-performance
can be maintained in the rest of the DB. 0
Process

© SAP 2008

◼ The LOCK ESCALATION VALUE in the LOCKLISTESCALATION system table defines the
point at which a lock is escalated. Here, this value corresponds to 60,000 (20% of the MAX
LOCKS, which is 300,000).

© SAP AG ADM515 4-27

 Lock Escalation with MaxDB – Solutions

Lock behavior for certain tables cannot be MaxDB parameter

changed. MaxSQLLocks

The only option is to:

Lock list
◼ Increase the size of the lock list; up to 5
million entries are common. Processes
◼ Integrate COMMITs into the batch input or
report

20%
Table

10%

0
Process

© SAP 2008

◼ Very long lock lists slow down processes involving data records since these lists have to be checked
every time a data record is accessed to determine whether a record is locked. However, if the lock
list does not contain any locks, it is not a problem.

© SAP AG ADM515 4-28

 Lock-Free Index Creation

Output in the knlMsg diagnosis file:

© SAP 2008

◼ As of MaxDB 7.7.04, table indexes can be created without the previous lock situations on the base
table.
◼ This procedure applies to larger tables only. In the case of smaller base tables, only a short time is
usually needed to create the indexes and so the temporary catalog lock does not affect them.
◼ In the case of larger tables, the change requests for the base tables are written to temporary
structures while the indexes are created and then finally processed when the indexes have been
created.
◼ In the knlMsg diagnosis file, this procedure can be followed as shown above.

© SAP AG ADM515 4-29

 Inside MaxDB: Course Overview Diagram

Inside MaxDB
Topic 1: Processes
Topic 2: Locks
Topic 3: Memory Areas
Topic 4: Disk Areas
Topic 5: Logging

© SAP 2008

© SAP AG ADM515 4-30

 Cache Areas

Runtime User Kernel Thread (UKT) Coordinator

Environment
Processes

User Kernel Thread (UKT) – Tasks: Console

(RTE)
(Clock)

Trace Writer
Log Writer
Requester

Garbage
Server

Pager
User

Server

Utility
Pager

Timer
User
IO Threads

I/O Buffer Cache

Caches

Catalog Cache

SharedSQL

Hash Memory Log Queue

Hard Disks

/sapdb -
DATA LOG programs
LOG
etc.

© SAP 2008

◼ The database has buffers to keep the number of read and write operations on the disks as low as
possible.
• The IO buffer cache contains the data most recently requested from the data volumes (LRU
mechanism). This data contains:
- Data pages from the tables
- Converter information with logical positions of data pages in the data volumes
- Before images (history data) for the transactions that are currently running
• Log entries are written to the log volumes via the log queue.
• The catalog cache contains information about the structure of tables. The catalog cache is
assigned dynamically to every session by UKTs and is a process-local memory.
◼ Cache sizes can set according to user requirements.
◼ The memory requirement of a MaxDB instance can be determined from the
ALLOCATORSTATISTIC table. This table stores information about different memory structures of
MaxDB. The overall size including the IO buffer cache, other caches, task stacks, and so on (but not
executables) can be found in the SystemHeap row and the USED_BYTES column. The
corresponding SQL statement is (ensure that 'SystemHeap' is written correctly):
select USED_BYTES from ALLOCATORSTATISTIC where ALLOCATOR = 'SystemHeap'

© SAP AG ADM515 4-31

 Caches and Related Disk Areas

Catalog SharedSQL
IO Buffer Cache Cache Cache Log Queue
Converter pages

Data pages

Undo pages
Free pages

Data Volumes Log Volumes

LOG
Undo Undo Undo

The IO buffer cache contains different types of data pages.

The IO buffer cache is sychronized with the data volumes by means of SAVEPOINTs.

In contrast, the log is written continuously and even synchronously in the case of a COMMIT.

The catalog cache and shared SQL cache are process buffers and so do not have any
corresponding disk areas.

© SAP 2008

◼ All data is organized here in 8 KB pages.

◼ The IO buffer cache and log queue are both static memories and fully configured when the database
is started.
◼ The catalog cache and shared SQL cache are dynamic memories that are initially configured at 50%
and then grow to the maximum size permitted, if needed. Once memory has been requested, it is not
returned to the operating system.
◼ The catalog cache contains data from formatted SQL statements, including parse information, input
parameters, and so on. It does not contain the initial SQL statement in a readable form.
◼ This information (readable SQL statement) is assigned to the information record from the catalog
cache when the formatted SQL statement is finally stored in the shared SQL cache. It is then
possible to determine the readable SQL statements.
◼ If the SQL statement is to be analyzed, the analysis is not carried out from this cache, which is the
case with other databases. Instead, SQL monitors are started that deliver much more usage data.

© SAP AG ADM515 4-32

 Rule of Thumb for Size of IO Buffer Cache

Experience from several customer systems has ASCII UNICODE

shown that the initial size of the IO buffer cache
should be set based on the following rule of OLTP 1% 2%
thumb.

The size of the IO buffer cache is determined as a OLAP 2% 4%

percentage based on the quantity of data in the
database, as shown in the table.

Of course, more memory can be used and acts as

a safety buffer.

UNICODE doubles the required IO buffer cache,

which is necessary.

For OLAP(BI), the same applies due to the large

amount of data processed.

© SAP 2008

◼ Experience has shown that a database can function well with these memory provisions for MaxDB.
This does not apply to applications with functions that read a lot of data since the data has to be
evaluated differently in this case.

© SAP AG ADM515 4-33

 Central Importance of the Converter

Pages in the
I/O buffer Page 1 Page 2 Page 3 Page 4 Page 5 Page 6 Page 7
cache

I/O Buffer Cache

Restart
Address
DATA
conversion
Catalog Cache using the
Start of
converter
the Shared SQL Cache
database
instance Hash Memory File Dir Log Queue

Physical Page 5 Page 1 Page 2

position DATA DATA DATA DATA DATA
of the pages Page 4
Page 6 Page 7 Page 3

© SAP 2008

◼ In the data volume (that is, in the converter), logical page numbers are mapped to physical page
addresses. The I/O buffer cache contains the last read or write-accessed pages of the converter. It
is used by all concurrently active users.
◼ The size of the converter is 1/1861 of the database size, since one converter page can contain the
administrative data (references) for 1861 data pages. A database with 500 GB of data requires a
converter of roughly 278 MB.

© SAP AG ADM515 4-34

 Flexible Design of the Converter

Data Volumes Converter Page

Restart

Definition of the root of the converter in the restart page

Converter is distributed as a B* tree across all data volumes

◼ Faster restart since the converter is read by multiple devices
◼ No hotspot when converter data is written
◼ Converter is split into smaller areas in the memory to also avoid hotspots

Converter can grow and shrink

© SAP 2008

◼ As of Version 7.4, the converter can grow and shrink dynamically. The converter pages are
distributed across all data volumes. Upon restart, the converter pages are read via a tree structure.
◼ The tree has three levels: a root level, an index level, and a leaf level. When restarted, the database
finds the root page of the converter via the restart page at the beginning of the first data volume. It
contains the positions of the index pages. In turn, the index pages contain positions of the leaf pages.
The leaf pages are not necessarily sorted. When started, the database reads the converter in parallel.

© SAP AG ADM515 4-35

 Converter and How it Affects Data Volumes

Converter Page Header: Version #

log. DATA Offset DATA Save Saved
Converter Page Header: Version #
data Device on DATA page DATA
log. DATA Offset DATA Save Saved
page Number device type pages
data device on DATA page DATA
Restart 4711 1 240 f 0 0
Undo page number device type page
4712 3 219 t 1 0
4711 3 140 p 0 0
Undo DISKD0003
4712 2 191 t 1 0
DISKD0002
Undo
Converter Content
DISKD0001

Page addressing:

0 ... 6 7 8 9 10 11 12 ... 30 31 32 TB can be addressed

Device number Offset on device

Standard:
8 Bit 24 Bit 256 * 128 GB = 32 TB
Large volumes:
6 Bit 26 Bit
64 * 512 GB = 32 TB
Small volumes:
12 Bit 20 Bit
4096 * 8 GB = 32 TB
© SAP 2008

◼ MaxDB numbers the data pages and assigns a physical page address to them in the data volume.
This assignment is managed in the converter. The converter is part of the I/O buffer cache.
◼ Through the use of shadow memory technology, a current version of each data page can exist as
well as an old version that is required for a possible restart. This means that two converter entries
can also exist for each data page: the address of the old and new version. There is a 35-bit converter
entry with the following information for each of the versions of a logical page:
• Device number (8 bit): Data volume number
• Device offset (24 bit):Position in the relevant data volume
• Page type (1 bit): Permanently (p) or temporarily (t) required
• Save pages (1 bit): This indicator is set if the data page is to be backed up during an
incremental data backup (SAVEPAGES).
• Saved (1 bit): This indicator is set during the backup.
◼ At a savepoint, the converter "notes" the address of the current page version; the address of the old
version is released again for overwriting after the savepoint.
◼ 1861 pages of the data volume can be managed with a converter page of 8 KB. The size of the
converter is therefore approximately 1/1861 of the database size.

© SAP AG ADM515 4-36

 Shadow Memory Concept

I/O concept according to the principle of

shadow memory management: Time

Memory
◼ Shifting of synchronous operations to Change to page 4711
asynchronous execution; user tasks do not
have to wait for the end of I/O operations
◼ Increased use of cache technologies
(Converter) No change to page 4711
◼ Reduction of write load; changed data Two versions
of one page
pages are written from the cache to the

Disk
hard disks only at savepoints Instead, one new page 4711’
◼ The database status is always structurally
consistent (restartable) on the hard disks; if Page DATA‘
errors occur, you can return to this status 4711 DATA Page
4711’

Write load

Savepoint
© SAP 2008

◼ I/O database concept functions according to the principle of shadow memory management. The key
points are: optimized support of symmetrical multiprocessor systems, shifting as much I/O to
asynchronous execution, and optimizing data backup performance to a level that can handle today's
database sizes.
◼ A user task should not have to wait until I/O operations have ended. All change operations are
carried out in the main memory. The I/O subsystem must ensure that a full restart is possible at any
time.
◼ Shadow memory management distinguishes between original and copied data pages. When the
system is restarted, the respective statuses of the data pages are identified. The concept is based on
savepoint cycles that are completed by means of savepoints. A completed cycle is specified by the
version number of its savepoint. This number is referred to as the "savepoint version" or "converter
version".
◼ The different versions of the data pages created by these savepoint cycles are managed in the
"converter". The converter assigns physical blocks to the original and copied logical data pages. The
location in which a logical data page is saved can therefore change from one savepoint cycle to the
next.
◼ The data cache has been optimized to support symmetrical multiprocessor architectures (SMP)
through the use of pager tasks and server tasks working in parallel.

© SAP AG ADM515 4-37

 Savepoint Features

Transaction 1
Savepoint
Transaction 2
Time-controlled
Transaction 3
Startup / Shutdown

Backups 0 Time

CREATE INDEX
IO Buffer Cache
LOG FULL

DB FULL
Restart

DATA
Undo

© SAP 2008

◼ The savepoint is time-controlled. By default, it is triggered every 10 minutes.

◼ A savepoint is also written when you start and stop the database.
◼ A savepoint is also written if a CREATE INDEX command is executed or a LOG FULL and DB
FULL situation arises.
◼ In MaxDB, backups are always created on the basis of a SAVEPOINT. Since the before images of
transactions remain in the data area until the COMMIT, the backups created on the basis of these
transactions are always consistent.
◼ When the log writer is deactivated, the time control function of the SAVEPOINT is disabled.
Therefore, be careful when deactivating the redo log management.

© SAP AG ADM515 4-38

 Savepoint Cycle

x25 x25: Page in I/O buffer cache x26

x26: Page in I/O buffer cache
changed before savepoint 25 changed before savepoint 26

X X X X X
25 25 25 26 26

X
I/O
I/O Buffer
Buffer
X X
Cache
Cache
X X
I/O
I/O
X
Buffer
Buffer
X
Cache
Cache
X X
25 25 25 25 25 26 26 26 26

X X X
25 25 25

X
I/O Buffer
X X
Cache
X X
25 25 25 25 25

Restart Restart

DATA I/O buffer cache after savepoint 25 DATA

Undo Undo

Savepoint 25 Savepoint 26
10 minutes or longer t

© SAP 2008

◼ You can also start savepoints manually with the command:

dbmcli –U c db_execute force savepoint

© SAP AG ADM515 4-39

 Savepoint Phases

◼ Write changed data pages (in parallel) Data Cache

Phase 1

dc0 dc1 dc2 dc3 .... .... dcn

◼ Stop B* tree operations

Phase 2

◼ Reserve transaction regions

Short

◼ Write log entry

Restart Undo
◼ Flag open transactions
Undo DISKD0003
◼ Release all areas again
DISKD0002
Undo
◼ Write the data pages changed in phase
DISKD0001
1 (in parallel)
◼ Write converter pages (in parallel)
Phase 3

◼ Write log info and restart page

c1 c2 … cn
◼ Increase savepoint version

Converter Cache
© SAP 2008

◼ The savepoint can be considered a core function of the I/O concept. The illustration shows what
happens during a savepoint.
◼ The savepoint has to flush the data cache and converter cache to the corresponding data volumes.
Due to the size of the two caches, this cannot be carried out as a synchronous action since the
system would be blocked for too long. However, there must be a phase (as short as possible) during
which the caches can be securely synchronized.
◼ Savepoints are time based and occur every 10 minutes by default. To minimize the amount of data
to be flushed in the protected section (phase 2), the savepoint begins by flushing the data cache in
parallel to ongoing operations. In this process, the data cache is processed by multiple pager tasks
simultaneously. Most of the pages are flushed in this phase.
◼ In the second phase, an indicator is set that prevents clearing operations on B* trees. It also prevents
new transactions from being opened during this phase. All pages that were changed during the first
phase are marked as savepoint relevant. An open trans file is created for the open transactions.
◼ In the last phase, all pages that were marked during the second phase are flushed. The markings are
reset. Finally, all changed converter pages are written in parallel to the data volumes. The savepoint
itself is complete when the restart page is written. Afterwards, the savepoint version (number) is
updated.
◼ The protected phase of the savepoint is generally quite short and goes unnoticed by the end user.

© SAP AG ADM515 4-40

 Savepoint Phases in the Database Messages
(knlMsg)

02:00:36 Savepoint 1: Savepoint (Time) started by T1

02:00:36 Pager 20004: SVP(1) Start Write Data
02:00:36 Pager 20005: SVP(1) Stop Data IO, Pages: 3051 IO: 501
02:00:36 Pager 20006: SVP(2) Wait for last synchronizing task: 557
02:00:36 Pager 20007: SVP(2) Stop Wait for last synchronizing task, Pages: 0 IO: 0
02:00:36 SAVPOINT 53070: B20PREPARE_SVP: 13082
02:00:36 Pager 20008: SVP(3) Start Write Data
02:00:36 Pager 20009: SVP(3) Stop Data IO, Pages: 4 IO: 4
02:00:36 Pager 20010: SVP(3) Start Write Converter
02:00:36 Pager 20012: SVP(3) Stop Converter IO, Pages: 502 IO: 502
02:00:36 SAVPOINT 53071: B20SVP_COMPLETED: 13082

For performance reasons, it is important to have a large ratio of written pages to the
number of IOs executed for these pages in the first phase of the savepoint.

The savepoint number is output (here: 13082).

An additional criterion for performance is the runtime of the savepoint, which is

under a second here.

© SAP 2008

© SAP AG ADM515 4-41

 File Directory – Table Counter

Restructured file directory

◼ The global file directory (a storage area of the database that allows data structures of tables,
indexes, and LOBs to be accessed) is now stored entirely in the memory. The flat structures
are managed by means of a hash algorithm and enable faster access.
◼ Important statistics such as "SELECT COUNT(*)" are also stored here and can be determined
very quickly using the file directory when the number of data records in the table is
determined. This accelerates the "SELECT COUNT (*)" executions considerably.

© SAP 2008

◼ Determine the number of data records in a table:

select roots.tablenaname, files.* from files, roots where files.root=roots.root order by files.fileid
The number of data records is specified in the ENTRYCOUNT column.
◼ These values for ENTRYCOUNT are maintained automatically if the database instance was rebuilt
with MaxDB 7.6.
◼ If the database instance was created based on an update to an older release, the values in these
columns are 0 (initial).
◼ These figures are then updated automatically in the background when the workload is low. If this
does not occur often enough because the DB is operating at fully capacity around the clock, you can
still determine these absolute figures in a single step by checking the data in the ADMIN operating
state.

© SAP AG ADM515 4-42

◼ When shared SQL is activated, the SQL monitors in DB50 (resource monitor) display the SQL
statements found in the shared SQL cache but not information such as costs, although SQL monitors
are known to display such information.
◼ After the SQL monitors have been activated, this data is displayed for the subsequent statements
collected.
◼ However, the shared SQL function can generally provide accurate information about which
statements have run or are running, without using special SQL monitors. In earlier releases, this was
only possible after the SQL monitors were started.
◼ This function has been available since earlier Support Packages of SAP NetWeaver 6.40 and SAP
NetWeaver 7.00.
◼ The catalog cache is only a temporary storage location that is used before the parsed statements are
finally saved in the shared SQL cache together with the complete SQL statement. The user sessions
in the catalog cache still have private areas in which the parsing function takes place.
◼ The shared SQL cache is a growing cache that is initially generated in half its size and then grows to
the value of SharedSQLCommandCacheSize as required.
◼ Information about operating the shared SQL is available in the system tables displayed.

© SAP AG ADM515 4-43

 Appendix: Stripes (Regions)

For example, in the data cache.

Reserved

User Kernel Thread

Stripes (regions) are used to synchronize User
processes that run in parallel to memory User
User
structures and other resources in the database. User Kernel Thread
Tasks
◼ DataCache User
◼ ConverterCache User
User
◼ and so on
Tasks

© SAP 2008

◼ Stripes (regions) can be found in all areas where resources are used in parallel in the database.
◼ For example, the data cache is split into multiple segments in the main memory.
◼ Definable allocation of stripes in the data cache (8 – 1024, default setting depends on the size of the
data cache)
◼ MaxDB parameters: DataCacheStripes, ConverterStripes, and so on.
◼ Multiplying the stripes results in a higher parallelism (MaxDB-internal synchronization
mechanism). However, this higher number of stripes also means more administration. Both aspects
must be weighed up against each other.
◼ In a multiprocessor system (MaxCPUs parameter > 1), collisions between processes of different
UKTs are unavoidable. The deciding factor is how fast the switch takes place on the stripes, that is,
how long the colliding task has to wait to reach the stripe (region) and start working. This means
that the Waits percentage is very important since it indicates how often a task had to wait for a stripe
on average.
◼ The DBA Cockpit and DBAnalyzer offer a lot of information here in various forms (split according
to time or summarized).
◼ There are many different types of stripes that are related to the various divided functions within the
database. The UMEW60 training course (MaxDB Performance Optimization) lists these according
to version.

© SAP AG ADM515 4-44

 Page Clustering

Offered as of MaxDB 7.7.04

This function is available automatically since the MaxDB parameter

DataIOClusterSize is usually set to 64.

You can initially activate this function by converting the table with
◼ ALTER TABLE <table name> CLUSTER

You can deactivate it with

◼ ALTER TABLE <table name> NOT CLUSTER

Initial feedback from customers is collected

◼ Data throughput on the hard disks is increasing dramatically
◼ Average IO times are falling below 1 ms

Further development in 7.7 and 7.8

◼ In the future, automatic activation without the need for conversion (conversion then carried out
while the database is running)

© SAP 2008

◼ This function is available as of MaxDB 7.6.05.

◼ In 7.6, the parameter is DATA_IO_BLOCK_COUNT, which is also set to 64 in the release.
◼ In newer versions of DB50, information contained in tables is specified in clusters. You can find this
information under DB50 -> Tables, View & Synonyms -> Enter Table -> Data Store -> Factor
◼ Many system tables have been extended or created to include the status information of the cluster.
◼ The conversion time of the tables to be converted into page clusters must be compared with a simple
table scan. Afterwards, the garbage collector runs and deletes the pages of the old table structure.
◼ Indexes can also be stored in clusters in the following enhancements of the function as soon as the
base table is converted to a cluster.
◼ See SAP Note 1162332 on page clustering. It contains further tips and tricks on this topic.

© SAP AG ADM515 4-45

 Prefetch

Available in MaxDB 7.7, Version 7.7.06 and higher

Activation
◼ Set the "ReadAHeadTableThreshold" MaxDB parameter to a value greater than 0: 100
◼ Table range scans with more than 100 pages are delegated to server tasks.
◼ Optimizer determines the number of pages to be read and thus controls the decision.
◼ Can be controlled (activated and deactivated) in ONLINE operating mode through a
parameter change

First results in a customer environment with this function in 7.6.05

◼ Background job with several disk accesses could be reduced from 40 to 2 hours.
◼ Initial startup of SAP NetWeaver can be reduced from minutes to seconds in some cases.

Restrictions in the first implementation phase

◼ Initially, this technology is not used with JOINs.
◼ The number of server tasks is limited and these must be distributed when used in parallel.
◼ Page clustering and prefetch cannot be combined: The server tasks do not know how to read
clusters yet.

© SAP 2008

◼ Prefetching will be available in MaxDB 7.7 from Version 7.7.06 onwards.

◼ It is initially implemented as in MaxDB 7.6, as of Version 7.6.05.
• The relevant MaxDB parameter is called READAHEAD_TABLE_THRESHOLD and should be
set as for MaxDB 7.7.06.
◼ SAP Note 1255050 covers the "Prefetch" topic. It contains further tips and tricks on this topic.

© SAP AG ADM515 4-46

 Cache and Table Pinning

Offered with MaxDB 7.7.06

In the IO buffer cache, tables can be managed in two ways:
◼ Tables are kept in the cache
◼ Tables are removed from the cache (for example, in logs)

Activation
◼ ALTER TABLE <table name> CACHE
◼ Tables to be kept in the cache
◼ ALTER TABLE <table name> NOCACHE
◼ Tables to be removed from the cache
◼ These additions are also available for the CREATE TABLE statement.
◼ You can reset the default behavior with
◼ NOT CACHE
◼ NOT NOCACHE

You can determine the current setting for every table by checking the FILES system
table.

© SAP 2008

◼ This function is offered for the first time with MaxDB 7.7.06.

© SAP AG ADM515 4-47

 Inside MaxDB: Course Overview Diagram

Inside MaxDB
Topic 1: Processes
Topic 2: Locks
Topic 3: Memory Areas
Topic 4: Disk Areas
Topic 5: Logging

© SAP 2008

© SAP AG ADM515 4-48

 Hard Disk Areas and IO

Runtime User Kernel Thread (UKT) Coordinator

Environment
Processes

User Kernel Thread (UKT) – Tasks: Console

(RTE)
(Clock)

Trace Writer
Log Writer
Requester

Garbage
Server

Pager
User

Server

Utility
Pager

Timer
User
IO Threads

I/O Buffer Cache

Caches

Catalog Cache

SharedSQL

Hash Memory Log Queue

Hard Disks

Restart
/sapdb -
LOG programs
DATA LOG
etc.
Undo
© SAP 2008

◼ The term "volume" (also referred to as "devspace" in versions before 7.4) denotes a physical disk or
part of a physical disk.
◼ There are two types of volumes:
• Data volumes mainly contain the user data (tables, indexes, and so on) and the database catalog,
but also store the converter as well as history pages with before images of the current
transactions. Through internal database striping, the data for a table is equally distributed across
all data volumes.
• In the log volumes, all changes to database content are recorded as after images to allow changes
that are not contained in the last complete data backup to be reloaded when a database instance is
restored.
To ensure that a database in a small system without RAID1 drives can run smoothly, you can
mirror the log volumes. In unmirrored log mode, the disk must be mirrored either physically or
by the operating system for at least production systems.

© SAP AG ADM515 4-49

 Directory Structure as of SAP DB Version 7.2.4

/sapdb LVC db INSTROOT for the liveCache instance LVC

SDB db INSTROOT for the content server SDB
P01 db INSTROOT for the production SAP system P01
bin
pgm
Example:
sap
Three instances on
...
one server

sapdata
saplog

programs Instance and release-independent programs

IndepProgPath
bin -> x_server
pgm -> dbmcli

IndepDataPath data LVC Run directory for LVC

wrk SDB Run directory for SDB
P01 Run directory for P01
config Parameter files for all instances
© SAP 2008

◼ As of Version 7.2.04, the directory for the database software is registered based on the database
instance. In the Database Manager CLI, you can use the command db_enum to call up information
about which database instances are installed on the server and the directory in which the associated
software is stored. The information fast and slow describes the database kernels that are active. The
slow kernel is a special diagnosis and trace kernel.
Example: dbmcli –n <server name> db_enum
• P01 /sapdb/P01/db 7.7.04.29 fast running
• P01 /sapdb/P01/db 7.7.04.29 slow offline
◼ Backwards compatible database programs are stored in the directory /sapdb/programs (dbmcli
dbm_getpath IndepProgPath). Configuration data and diagnosis files are stored in the directory
/sapdb/data (dbmcli dbm_getpath IndepDataPath).
◼ The following directories should be accessible in the environment (SAP Note 327578):
• PATH variable in the SYSTEM environment:
Drive:\sapdb\programs\bin
Drive:\sapdb\programs\pgm
• PATH variable in the USER environment:
Drive:\sapdb\<SID>\db\bin
Drive:\sapdb\<SID>\db\pgm
Drive:\sapdb\<SID>\db\sap
◼ On UNIX, the path information should be adjusted and entered in dbenv_<server name>.<shell> of
the database administrator <sid>adm.
◼ As of MaxDB 7.8, an ”isolated installation“ will also be possible.

© SAP AG ADM515 4-50

 Directory Structure in the SAP Environment

sapdb

programs <SID> data

bin pgm env etc lib runtime Support symbols wrk

config wrk

SID SID

db
sapdata saplog
bin pgm env etc lib incl misc symbols sap

DISKD0001 DISKD0002 … DISKD0255 DISKL001 … DISKL0xx

M_DISKL001 … M_DISKL0xx

With mirrored log volumes

© SAP 2008

◼ When a MaxDB database is installed for SAP applications, certain naming conventions apply to the
required directories.
◼ The sapdata directory includes all the data volumes. You can set up a maximum of 256 data
volumes.
◼ The saplog directory includes the log volumes. If you are using the mirrored log mode, the log
volumes are mirrored by the database. You can set up any number of log volumes.
◼ Usually, only one sapdata and one saplog directory are created. However, more can be created.
◼ In these directories, you can also insert links to file names in file systems where there is capacity to
create volumes.
◼ You can also create mount points for different sapdata or saplog directories to make space for the
volumes. For a large number of data volumes, we recommend that you create between five and ten
data volumes for each file system. Reason: There is no way to inform the operating system of how
many parallel write/read devices are behind one mount point.
◼ The previous DBROOT directory is now comparable to INSTROOT and is available under
/sapdb/<SID>/db.
◼ If your system offers hardware-based mirroring (RAID1 systems), we recommend that you use this
to mirror the log volumes.

© SAP AG ADM515 4-51

 Rules of Thumb for Database Structure

Restart Undo

Undo
DISKD0003
DISKD0002
Undo

DISKD0001

Recommendations for storage systems:

◼ We recommend using the following formula to calculate the size of the MaxDB data volumes:
square root of the system size in GB, rounded up.
◼ This empirical value represents neither too many nor too few data volumes.
◼ It provides a buffer for more volumes so that the number of volumes in the database can still
grow.

© SAP 2008

◼ The database system distributes the data pages across the available data volumes to ensure a fill
level and I/O load that are as even as possible.
Here, the data volumes are filled based on the absolute fill level, and not relatively.
◼ If you are using a RAID controller with local disks, we recommend that you configure the same
number of data volumes as available disk drives. Data volumes are normally stored on RAID5 disk
systems due to the lower security overhead (parity information).
◼ Database-independent files such as the OS swap or page areas and SAP system files should be
stored on separate disks.
◼ Examples based on the square root formula:
• Total size of database Number of data volumes to be created
10 GB 4 volumes
50 GB 8 volumes
100 GB 10 volumes
200 GB 15 volumes
500 GB 23 volumes
1 TB 32 volumes
• More recent installation routines of SAPinst already use this formula.

© SAP AG ADM515 4-52

 Volumes in RAW Devices or File System?

For UNIX, we recommend that you store all volumes

on RAW devices.
◼ Security
◼ Performance I/O Buffer Cache

Parameters: UseFilesystemCacheForVolume and

UseFilesystemCacheForBackup

T C
IO Thread

IRE
◼ Uses the O_DIRECT operating system function to write DB

_D
data to volumes and backups in the file system directly
OS

EN
without a file system cache

OP
File System
◼ Since internal file system caches are used when RAW

E_
devices are implemented on Linux, you should also set
Cache

US
the parameter here.
◼ When mounting file systems from third-party
manufacturers on UNIX, use O_DIRECT or similar
Restart
options.
DATA
Undo

© SAP 2008

◼ In UNIX systems, we recommend that you configure log and data volumes as RAW devices. This
avoids an additional administration level (in this case, particularly the records kept in modern file
systems).
◼ If a file system is actually faster than a RAW device, internal caches are used in file management,
which can jeopardize the operation of the database in the event of abrupt system failures (power loss
and so on). This means that administrators cannot assume that data regarded as written was in fact
written immediately. File system management usually confirms receipt of pages immediately and
may not execute the write action until some time later, after several write commands have
accumulated.
◼ During subsequent database operation or at the latest when the database is next backed up or
checked, page errors occur when you try to access pages that were not previously saved. In this
situation, a database recovery is then usually required.
◼ When using file systems with MaxDB, you should set the parameters
UseFilesystemCacheForVolume (USE_OPEN_DIRECT) and UseFilesystemCacheForBackup
(USE_OPEN_DIRECT_FOR_BACKUP) for security reasons to make absolutely sure that all pages
were written prior to reconfirmation. The database kernel then opens the volumes with the
O_DIRECT operating system option.
◼ Since operating system caches are also used to store data temporarily when RAW devices are
implemented on older Linux releases, we also recommend that you use this parameter for security
reasons.
◼ In other versions of UNIX and Windows systems, this parameter is not used even if it can be set. In
Windows, files are always accessed with corresponding options for writing directly to the disks,
whereas UNIX usually offers the O_DIRECT mount option.

© SAP AG ADM515 4-53

 Equal Distribution After a Configuration
Change

DATA DATA
◼ Data volume filled

◼ New data volume added

◼ There is only space for new data

DATA DATA DATA in the new volume:
Danger of a hotspot.

◼ Equal distribution of the data

volume at times of low workload.

◼ Equal distribution achieved,

DATA DATA DATA hotspot avoided.

© SAP 2008

◼ This topic is also addressed in conjunction with the automation of page clustering:
◼ Data is equally distributed only when the workload is low.
◼ However, it can still take a while for the database to interrupt the distribution process if the
workload increases again. Equal distribution is then continued later.
◼ This function is implemented as of MaxDB 7.7.06.
◼ Until now, this was carried out via the data cache and caused long-term cache displacement, thus
affecting day-to-day business significantly.
◼ In the final implementation, memory structures outside of the data cache are used, which still have
to be provided.

© SAP AG ADM515 4-54

 Data Volumes – Parallel Formatting

Parallel formatting of the data volumes during activation

◼ The database is structured more quickly if the data volumes are stored as files in the file
systems
◼ Parameter: VolumeFormattingMode (default: PARALLEL)

Database
DatabaseKernel
Kernel

db_activate
db_activate

DATA
DATA
DATA

© SAP 2008

◼ Since the sequential formatting process required very few system resources in the past, this
installation step could not easily be identified. For this reason, users often canceled the installation
process because there was no activity on the server and the installation process involved long wait
periods. Through parallel formatting, this process should be much faster.

© SAP AG ADM515 4-55

 Inside MaxDB: Course Overview Diagram

Inside MaxDB
Topic 1: Processes
Topic 2: Locks
Topic 3: Memory Areas
Topic 4: Disk Areas
Topic 5: Logging

© SAP 2008

◼ See also SAP Note 869267 (FAQ: MaxDB LOG area)

© SAP AG ADM515 4-56

 Log Volumes

Usual size of log volumes: 2 to 8 GB

Usual number of log volumes: 1-2 volumes

Mirrored
Log
Mirrored
M_DISKL001 Log

M_DISKL002
Log

DISKL001
Log

DISKL002
© SAP 2008

◼ The log area can consist of any number of log volumes and mirrored log volumes. MaxDB handles
these as one continuous area and writes to it cyclically. For this reason, the administration is only
made more complicated through several log volumes and results in no additional advantages. It is
better to keep the number of log volumes low. One or two log volumes are recommended. A typical
volume is 2 to 8 GB, but can also be up to 64 GB in some cases.
◼ All log volumes should be on separate disks, physically separated from the data areas. This is
necessary for data security, availability, and performance reasons.
◼ You can set up software mirroring of the log volumes through the database kernel, but we
recommend using hardware mirroring (RAID1) to achieve this.
◼ Log information is released for rewriting only once the log has been backed up successfully.
◼ For performance reasons, we recommend that you do not store log volumes on RAID5 disk drives.
• Log information is usually written asynchronously in small portions (between one and two 8 KB
pages for each action). Only when a transaction is completed (COMMIT) does the process that
triggered the COMMIT have to wait for the log data to be written successfully for this transaction
in a synchronous action.
For this reason, the disks on which the log data is stored should be as fast as possible so that wait
times can be avoided when the COMMIT is executed. Ideally, log write times should be under
one millisecond. Exceptions here are distributed and mirrored drives in different data centers.
Due to signal runtimes between the drives, it can take 2-3 ms in this case.
• Since the read/write effort for small write operations of this kind in simple RAID5-based disk
systems is considerably higher than for RAID1 disks, the latter should be used. In large disk
storage systems with advanced cache technology, the difference in technology between RAID1
and RAID5 does not affect performance significantly, so RAID5 could also be used for the log
area in this case. Definitive conclusions can be made only after performance has been measured.

© SAP AG ADM515 4-57

◼ The size of the log area is equal to the total size of all log volumes.
◼ There are no physical log segments, as found in other databases.
◼ Only automatic log backups can be configured with the AutoLogBackupSize parameter. In the past,
these sizes were often incorrectly referred to as segments. However, this is actually a countdown
that triggers an automatic log backup when reached.
◼ Logs are usually backed up in packages that are the size of the AutoLogBackupSize parameter or
smaller.
◼ MaxDB also offers a time-based function for backing up logs.

© SAP AG ADM515 4-58

 Managing Log Information

Contents of the First Log Pages

Hardware Log Log Log Log Act. Free Free log Free
info block info page page 1 page 2 page n log page log page Log page log

Reserved for LOG FULL

Change to table content

Before images After images

Restart Pager
Pager History Log Log Writer
DATA Pager
pages queue Log
Undo

© SAP 2008

◼ The log volumes start with three pages of administration information:

• The hardware info block of each volume contains information about its configuration.
• The log info page contains information that is required during a restart and information about the
location of important entries in the log area, such as the first log page that contains log
information about transactions that are still open.
◼ The log pages immediately after the page currently used are reserved for LOG FULL situations to
allow the next restart to take place.
◼ The system assigns a unique sequence number to every log entry.
◼ The changes to table content are logged in two ways:
• The before images and statuses of pages before changes are carried out are kept in history pages
within the data area of the database. If necessary, this data can also be moved to the data
volumes. This is only rarely required with OLTP installations. The history pages are usually
deleted in the data cache long before any archiving since the corresponding transaction has been
completed.
• The after images (the change rules) are instead written to the log volume and saved permanently.

© SAP AG ADM515 4-59

 Logging Changes

When transactions change data:

◼ The data statuses before the changes
are made remain in the data area from
where they are copied to the history
s=1 (before image)
Log Queue update table set s = 3
◼ The changed data is saved in the form
Upd of a change instruction in the log
queue (after image)
s (3)

Data Cache

Table
History
s (1)

ss (15)
(3)

© SAP 2008

◼ The process of separating short-term log data (before images) and log data to be backed up
permanently is illustrated again here in a detailed example.

© SAP AG ADM515 4-60

 Writing Log Information

The log writer writes the filled log pages

Log Writer
from the log queue to the log volume
Log (asynchronous).

When a transaction is completed

Log Queue (COMMIT), the data must be written
synchronously from the log queue to the
Upd
log volume.
s (3)
The data in the history pages that
commit belongs to the transaction is then
Data Cache deleted asynchronously by the garbage
collector.
Table
History
s (1)

ss (15)
(3)

© SAP 2008

◼ Experience has shown that the history pages are almost never archived from the data cache to the
data volumes. In the liveCache environment, this is already the case if many consistent views are
used.

© SAP AG ADM515 4-61

 Multiple Log Queues

To achieve better scalability when writing the log, UKT UKT

user 1 user 3
you can now use multiple log queues.
user 2 user 4
◼ The number of queues is determined by the UKTs, but
should not exceed the number of UKTs, which means
that every UKT writes to a separate queue.
Log Queue Log Queue
Disadvantage: Increased volume of data in the log Upd Ins
since incomplete pages have to be written when a K1,Y R1,X
COMMIT is carried out to ensure that the queues C C
can be synchronized.
◼ Parameter: LogQueues
UKT
(default = MaxCPUs)
log writer
This function is recommended for liveCache
instances since the log data volume is transferred
to the log writer in larger packages.

Log

© SAP 2008

◼ Each log queue (for each UKT) can be extended to include the LogQueueSize parameter.

© SAP AG ADM515 4-62

 Deactivating the Log Writer  Caution

The log writer can be deactivated. UKT

user 3
However, this can have serious disadvantages: user 4
◼ Changes to business transactions are no longer logged
◼ Shutdown SAVEPOINTs can fail if database problems occur (final
Log Queue
synchronization is missing)
◼ Time-based SAVEPOINTs are no longer executed Ins
R1,X
All of these factors present a huge risk and can result in a C
costly loss of business information.

If a problem occurs, the database starts as normal with data UKT

from the last SAVEPOINT, which may be days old in some log writer
cases.
All transaction data is lost.
STOP

Log
© SAP 2008

◼ In the future, this option will not be as easy to use on the graphical front ends.

© SAP AG ADM515 4-63

 Log Mirroring

Log mirroring deactivated Log mirroring activated

Mirrored Mirrored
Log log Log log

DISKL001 RAID1 DISKL001 M_DISKL001

◼ Example of a configuration without ◼ Example of a configuration with

mirrored volumes and RAID1 support mirrored volumes but without
RAID1 support
◼ Disk errors are displayed in the
administration tool of the RAID ◼ Disk errors are logged in MaxDB
diagnosis files

© SAP 2008

◼ The log can be operated with MaxDB as follows:

• Log mirroring deactivated (UseMirroredLog parameter = NO):
Log entries are saved to one log volume. Data and downtime security is ensured by means of
hardware-based mirroring (for example, with RAID1 or RAID5 systems). If an error occurs on
the disks used, the RAID system tools are used to rectify the error. The database instance should
not be affected since the RAID administration software cleans up the defects online. RAID errors
can be identified only with the administration tools. If errors are still relayed to the database, this
will inevitably cause an emergency shutdown because the database can no longer guarantee log
integrity on the disks.
• Log mirroring activated (UseMirroredLog parameter = YES):
Log entries are saved (mirrored) to two log volumes simultaneously. If an error occurs in one of
the log areas, the second log area is available. Since the database is responsible for this mirroring,
it can also identify and log the errors on the disk in this case. If an error occurs on the original or
on the mirror, the database is immediately stopped via an emergency shutdown to eliminate the
risk of the database continuing to run with a defective log. The software mirror can then be used
to rectify the error.
• Overwrite mode (no MaxDB parameter):
Log areas are overwritten without being backed up beforehand. In an SAP environment, this log
mode is used only during upgrades or implementation operations. In production operation, you
should not use this overwrite mode. Changing the log mode and activating the overwrite mode
interrupts the backup history.

© SAP AG ADM515 4-64

 Inside MaxDB: Summary

You are now able to:

◼ Explain the technical background of MaxDB

© SAP 2008

© SAP AG ADM515 4-65

© SAP AG ADM515 4-66
 Exercises

Unit: 3
Topic: Inside MaxDB

After completing these exercises, you will be able to:

• Describe the internal structures in more detail

D.

3-1 Complete the exercises in the previous unit.

3-2 Analyze the savepoint

3-2-1 Use Database Studio for your instance to monitor the activities of the
exercises in unit 2. During the exercises, countless savepoints were
generated for which information was logged in the knlMsg file. Compare
the result with the information in the training materials.
Search for entries in knlMSg that contain the string “SAV”.

3-3 Analyze the runtime environment of the database

3-3-1 In the Database Studio tree, open the current runtime environment of your
database by choosing CONTROL-User -> Database Server -> RTE and
compare the result with the information in the training materials.

3-4 Use page clustering to fill the database

3-4-1 For this purpose, an additional Filldb.py is available with the name Filldb-
cluster.py, which is controlled in the same way.

© SAP AG ADM515 4-67

© SAP AG ADM515 4-68
 Solutions

Unit: 3
Topic: Inside MaxDB

3-1 Complete the exercises in the previous unit.

3-2 Analyze the savepoint

3-2-1 Use Database Studio for your instance to monitor the activities of the
exercises in unit 2. During the exercises, countless savepoints were
generated for which information was logged in the knlMsg file.
Search for entries in knlMSg that contain the string “SAV”.

3-3 Analyze the runtime environment of the database

3-3-1 In the Database Studio tree, open the current runtime environment of your
database by choosing CONTROL-User -> Database Server -> RTE and
compare the result with the information in the training materials.

3-4 Use page clustering to fill the database

3-4-1 For this purpose, an additional Filldb.py is available with the name Filldb-
cluster.py, which is controlled in the same way.
Filling the database and the "clear" option should show improved
performance.
The I/O times in Database Server -> DEV_IO should be shorter. However,
you first have to activate detailed time measurement so that all columns in
the output of DEV_IO are also filled.

© SAP AG ADM515 4-69

© SAP AG ADM515 4-70