SAP MaxDB DBM Server
SAP MaxDB DBM Server
2
3
The DBM server establishes the connection from the database clients to the database kernel.
As a prerequisite you have to be logged on to the database as a database system administrator
or DBM operator.
If administrative commands are sent remotely to the database host, a connection is first
established via the remote SQL server which in turn starts a DBM server.
Usually SQL statements do not communicate via the DBM server, in case of a remote
connection they use the x_server.
If an SQL statement is sent via sql_execute or db_execute then it will also communicate via a
DBM server session.
4
DBM Server
The DBM server is the server via which administration commands are executed. The database
tools Database Studio, Database Manager, and Event Dispatcher use the DBM server. The
DBM server always resides on the same computer as the database.
Database Manager
Database Manager consists of a client part and a server part (DBM Server).
The client part of Database Manager is available in the following variants:
Database Studio (see above)
Database Manager CLI (DBMCLI): Command line interface
Database Manager RFC (DBMRFC): Only in SAP systems, interface to the SAP system
(Another mechanism without dbmrfc is used as of Netweaver 7.30, 7.03 and 8.0 in combination
with MaxDB 7.9.04 or higher.)
If the client part of Database Manager is located on another computer than the database, it
connects to the database on the remote computer via an X Server.
Database Manager CLI is the client program of Database Manager. With this program you
connect to the DBM server on the computer on which you want to create a new database or
manage an existing database.
The Database Manager CLI database tool is used to administer database. The tool allows you
to create, monitor, back up, and restore databases.
Database Manager CLI is a command line tool and is suited to both interactive operation and
batch operation. It can be used on all operating systems supported by the database system.
5
Under UNIX the processes can be identified in the process list as dbmsrv (use: ps –ef | grep
dbmsrv).
Under Windows you will find it as dbmsrv.exe.
6
7
This picture is not complete but gives an impression how powerful the functionality of the DBM
server is.
If you are not sure about the exact names and options of a command the following commands
help to identify the command names and how they are used.
8
The dbm.prt is the main logfile which is written by the DBM server. You will find all actions taken
by the DBM server within this file. The file has a restricted size and if there are a lot of
messages parts of the content will get lost as the file is overwritten cyclically.
SAVE statements (== backup creation)
This log has a default size of maximum 1 GB and is overwritten cyclically. You can use the
following DBM command to change the
size of the file:
If no unit of measure (<size_unit>) is specified, the specification is in MB. You can use this
DBM command to configure a maximum size of 2 GB. Change the size of the log dbm.prt only if
requested to do so by SAP Support.
9
The synchronization of the different DBM servers of a database takes place using the shared
memory segments <DB_name>.dbm.shm and <DB_name>.dbm.shi.
Furthermore the communication between the DBM servers is done via the shared memory
segments. They are implemented in the system as a memory-mapped file (mmap). Make sure
that the path for the shared memory is located on a local filesystem. If this file is located on a
Network Share (NFS), deadlock situations might occur.
You can use the DBM command dbm_version to determine the directory in which the shared
memory segments (<database_name>.dbm.shm and <database_name>.dbm.shi) are stored.
10
<DB_name>.dbm.shi
<DB_name>.dbm.shm
dbmsrv_<server name>.dmp
dbmsrv_<server name>.err
.M790802.dbm.shi
.M790802.dbm.shm
11
Use the DBM command dbm_version to determine the directory in which the shared memory
segments (<database_name>.dbm.shm and
<database_name>.dbm.shi) that the DBM server uses for the synchronization are stored.
The entry SDBDBM_IPCLOCATION shows the directory (for example, /var/lib/sdb/dbm/ipc for
UNIX, /sapdb/data/wrk).
12
13
14
15
16
17
The SDB user (usually sdb:sdba) must always be able to read and write in the target directory
(usually /var/lib/sdb). No DBM server can run if this is not the case. They then terminate with
the above error message.
18
Most likely this issue happens when the system is abnormally shutdown/restarted or after a
crash (due to power outage, for example) while the database is running.
If the database is in ONLINE state and a OS restart is not properly done, the MaxDB cannot
perform a 'clean' shutdown so the shared memory files of the DBM server reside in an
inconsistent state, causing the old runtime to be present at the new database startup.
At OS level (process list), check whether any MaxDB/LiveCache processes are running. If any
process is found, terminate it.
Locate the runtime files in the filesystem. These files are named as <DB name>*.dbm.shi and
<DB name>*.dbm.shm, and are usually located under /sapdb/data/wrk folders (Windows)
and '/var/lib/sdb/dbm/ipc (UNIX).
Rename the files. I.e: LCA.dbm.shi_old, LCA.dbm.shm_old.
If the shared memory is not available any longer it is newly generated.
Another action might be necessary for cleanup but this is not related to DBM server:
Rename the pipe files (if existent) <SID> to <SID>.old in folders /sapdb/data/ppid,
/sapdb/data/fifo and file db:<sid> to db<sid>.old in folder /sapdb/data/ipc.
19
Information that is independent of a special database or liveCache instance is written into
dbmsrv_<host>.prt. F.e. commands like inst_reg will appear in this logfile.
Additionally the DBM server protocols its messages here in the start situation as long it is not
related to a special instance. You will find a line indicating the position when it skips to the
dbm.prt (and vice versa).
20
GlobalDataPath can be identified with the command:
dbmcli –u <dbm>,<pw> -d <DB name> dbm_getpath
21
Under Windows there is an additional way that can be used by developers to identify errors
from crash situations. If the backtrace from dbmsrv_<host>.err does not deliver enough
information the Visual Studio can be used for further post mortem analysis. A debugger can be
used and information about the values of variables can be identified.
22
23
24
Reason for the invention of this feature:
databases may only be dropped if no other DBM Server exists
upgrade
25
This functionality is implemented with an extra checker. This is a thread that does nothing but
checking stop requests in shared memory every 10 seconds.
26
With version 7.7 the concept of background servers was introduced.
27
The following two slides desribe a use case for the background server. A supporter has started
dbmcli on a remote host and thus also a DBM server on the database server. The DBM server
uses the Shared Memory for the database.
If a long running command is issued (like f.e. a backup) the connection may not be interrupted
in the meantime. If the connections gets lost also the command stops operation.
The customer could start the command locally but is not familiar with the correct use.
28
The supporter can start a backgound DBM server which executes the backup. The operation
can continue even if the supporter disconnects from the database server because the
background server is still active. The dbmcli session can be stopped and no other DBM server
process is necessary any longer.
29
Firstly the background server has to be started with the background_server_start command.
dbm_shm_info shows the newly generated background server in „idle“ state (waiting for command). With
background_server_execute a command can be started and the state „ready“ is reached. Before the
next command can be started the reply has to be fetched with background_server_get_reply.
Now the next command can be issued with background_server_execute. Another dbmcli session wants
to request the reply. This can be done with the commands background_server_takeover (which gives
control over the command to the other session) and afterwards background_server_get_reply .
Most likely you will see one of the states idle, ready, running.
30
31
scheduler_create_job
In a scheduler job, you define which DBM command is to be executed and when by Database
Manager in the current database.
You can specify when the new job is to be scheduled, and how often or after which job. If you
do not specify how often the new job is to be scheduled, the job is scheduled daily at the
defined time or every time the job defined as its predecessor is executed.
The DBM operator who created the job is the owner of the job. The system assigns a sequential
number for every job created per database.
For creating a job, the operational state of the database is irrelevant. Likewise, it is irrelevant
whether the scheduler is on or off.
The new job, however, is only actually executed if the job is active (scheduler_activate_job), if
the scheduler is on (scheduler_start), and if you have the server permission to execute the DBM
command defined in the job.
scheduler_delete_job
Use this DBM command to delete a scheduler job.
You can delete both active and inactive jobs. Before you do so, however, make sure that the job
to be deleted does not have any successors. Otherwise, the DBM command is aborted with an
error message. For deleting a job, the operational state of the database is irrelevant. Likewise, it
is irrelevant whether the scheduler is on or off.
scheduler_list_jobs
With this command you can display the list of all scheduler jobs.
The job ID, owner, status, time at which the job is to be executed, time at which it was last
executed, and the DBM command to be executed are displayed for each job created.
32
33
In this picture you see an example output of command scheduler_list_jobs for the job definitions
of the previous slide.
34
Additional info:
Email sending is done via SMTP (RFC 822). The user must provide an SMTP server that
„speaks“ this protocol. SAP‘s internal SMTP server is mail.sap.corp (on standard port 25).
The DBM Server talks directly to the SMTP server, no JavaMail or other layer is in between,
just the network.
35
36
37
In the configuration file directory (directory where configuration file dbm_whitelist.cfg is located)
you can check file dbm_ed_user.cfg to get information about your user defined event
configuration. The eventing itself is logged in the file dbm.prt.
dbm_whitelist.cfg lists all external programs that may be mapped to events. The file must exist
but may be empty.
You can test the procedure of defining events using the event DBM:Test. An event of category
ThrowDBM:TestEvent is transmitted, when the DBM command event_create_testevent is
executed.
38
List of commands for event dispatcher:
event_available: displays whether events were triggered and can be fetched with
event_receive or event_wait.
event_delete: specifies that an event should cease to be active
event_dispatcher: manages the event dispatcher function for a database
event_list: displays the list of all active events
event_list_categories: displays a list of all event categories for which events can be set
event_receive: fetches an event that has been triggered; repeat this DBM command to fetch
additional events.
event_release: ends the event session
event_set: specifies that the database system should trigger an event as soon as a defined
situation occurs
event_wait: fetches a message about the occurrence of an event as well as its data. This is
then deleted.
39
Firstly you have to start the event dispatcher.
40
If already events are defined you get a list of it. In the first shown window there is a „New“
Button to define new events.
In the list of possible events you can choose the wished event.
Some examples:
- DBFillingAboveLimit
- DBFillingBelowLimit
- DataCacheAboveLimit
- CheckTableProgress
- UpdateStatWanted
- Systemerror
41
On this slide the kernel parameters are listed that influence the eventing mechanism.
For error diagnosis it is useful to activate the writing of the file knldiag.evt which lists all “fired”
events.
The lower limit of 0 disables the caching of any event. It is not recommended to disable the
caching of events, if not for minimizing memory consumption since the database manager can
only process cached events. If no events are cache the database manager cannot report any
events.
A pool of floating service tasks is used to serve event handler- and DBAnalyzer-requests. This
parameter preserves some of these service tasks for service requests different from event
handling. This way, the available number of service tasks cannot be used up by a single service
type.
42
43
44
45
46
47
48