Standby DB MaxDB Eng

SAP
Author: Werner Thesing

Topic: Standby Databases with SAP DB/MaxDB or liveCache
Date 03.08.2004
Standby Databases with SAP DB/MaxDB or liveCache
Standby databases serve to accelerate recovery processes if the master instance of the database is
not available any more. Log shipping allows an asynchronous replication of the modifications in a
master instance to a standby instance.
This document gives references and hints, how with SAP DB/MaxDB and liveCache standby
databases can be set up. The procedure works with
SAP DB version >= 7.3.00 Build 50,
SAP DB / liveCache version >= 7.4.03 Build 34,
MaxDB / liveCache version >= 7.5.00 Build 31 and
all higher version numbers.
DBMCLI commands clarify the proceeding. Also the DBMGUI and/or WebDBM can be used. More
information about the DBMCLI Commands can be taken from the documentation “Database Manager
CLI: SAP DB...”.
Through log recovery the standby database with a time delay receives/reaches the same status of
data as the master database. In our example 2 instances are used, the master instance SRC and the
standby instance TRG. Usually SRC and TRG run on different servers.
Copyright SAP AG 2004, Standby Databases with SAP DB/MaxDB or liveCache Page 1 of 16
Prerequisites
Database version
The master instance and the standby instance must use the same database version.
Terms
Some Terms have changed with version 7.4.03:
Term if version < 7.4.03 Term if Verison >= 7.4.03

DB - Status Cold DB - Status Admin
DB - Status Warm DB - Status Online
Devspace Volume
This document always uses the new terms. The command examples still use the older
terminology as this still works with the new database versions.
Initial data load to the standby database

The standby instance will be initialized. Afterwards a complete backup taken from the master
instance will be restored. Subsequently log backups, also taken from the master instance, will
be restored.
Sizing of the standby instance with version 7.3

The standby instance can either be smaller or larger than the master instance. At least the
size of the standby instance will be defined by the highest page number used for persistent
data of the master instance (LAST DATA PNO). This number can be determined:
dbmcli -d SRC -u <dbm-user>,<password> -n <masterserver>

-uSQL <sap-user>,<password>
sql_execute "select maxdatapageno from sysdba.serverdbstatistics"
Sizing of the standby instance with version >= 7.4

The standby instance at least has to have the same size as the number of used persistent
data pages of the master instance.
Space to restore the log backups

The standby instance must provide enough space to restore the log backups of the master
instance. All logentries of transactions are intermediately stored in the data areas until the
transaction end commands are encountered. All modifications of transactions are redone only
if the COMMIT has been read. If a transaction is finished with a ROLLBACK all log entries are
deleted without further actions.
Naming Data Volumes and Log Volumes

The names and the sizes of the volumes belonging to the standby instance can be different to
those of the master instance.
Shared Files
The standby instance and the master instance do not access shared files. The
RUNDIRECTORY has to be different.
Moving the backups
To accelerate the Backup/Restore process data backups can be moved through remote pipes.
OSS note 489615 describes this process.
Log backups have to be written to versioned files. As an example, they can be moved through
ftp, copied via a shared file system or written to mirrored file systems.
Direct access to shared files by the database is slow and risky. Thus this access method
should be avoided.
Status ‚Online’
The standby instance must stay in admin or offline mode. It must not be set online unless the
instance should take over the work of the master instance because of a system failure. If once
online the standby instance cannot work as standby any longer. It would have to be initialized
and provided with a complete backup again to resume its work as standby instance.
Switching options for master and standby

If the standby instance should take over the role as master instance it has to be set online.
Now the former master instance can be set up as standby instance.
Indexes (Secondary Keys)

If CREATE INDEX commands are found in the log these indexes will not be created during log
recovery. Only the repository entries for such indexes will be created. The index will be
marked as ‘bad’ and can be created when the database instance is online.
Savepoints and Checkpoints

A savepoint as well as a checkpoint flushes all modified data found in the caches to the
volumes.
The checkpoint ensures the consistency of the database, i.e. at the point when a checkpoint is
carried out all write transactions have to be completed. Checkpoints became obsolete as with
database versions from 7.4 onwards the before images of modified data are kept in the data
area (and are no longer part of the log). Thus they are flushed to the volumes by savepoints
instead. As consequence beginning with version 7.4 even with a savepoint all data is
consistent.
A savepoint or checkpoint is executed along with each backup. Each backup contains exactly
all data belonging to this corresponding savepoint/checkpoint. Subsequent changes are not
part of the backup.
Now we will show the process with DBMCLI command examples:

Master instance:
dbmcli –n <masterserver> –d SRC –u <dbm-user>,<password> [-nohold] [-i Input script]
Standby instance:
dbmcli –n <standbyserver> -d TRG –u <dbm-user>,<password> [-nohold] [-i Input script]
The DBMCLI commands can be entered at the command prompt. Alternatively the commands can be
entered via an input script using the option ‘-i’. The input script also can be a pipe. Some commands
(command sequences) require a DBMCLI session and thus cannot be entered at the command
prompt of a shell or DOS box.
DBMCLI can work remote by using the option ‘-n’ to specify the node of the database. It has not
necessarily to be started on the database server.
This document will use the representation for the input script of the master and standby instance as
follows:
SRC > <command>

TRG > <command>
Proceeding
The major steps to run a standby instance are :
Create the standby instance
Create the data backup (of the master instance)

Initialize the standby instance
Restore the backup to the standby instance
Create the log backups of the master instance
Restore the log backups to the standby instance
Set the standby instance online
Start of the standby instance to a certain point of time by restoring the logs
Start of the standby instance without loosing committed data (point of failure/takeover)
Recreate Indexes
If by mistake the log history is broken or the standby instance has been set online the process can be
reentered with initializing the standby instance.
Now the steps will be explained one-by-one.
Create a standby instance
The standby instance will be set up with the common installation and administration tools.
During use of the Database Wizard of the DBMGUI version 7.3 or 7.4 at the last step
‚Restore’ has to be chosen. The steps ‘Activate ServerDB’ and ‘Load Systemtables’ are
obsolete.
Select „Create instance for recovery“ in the installation wizard of DBMGUI version 7.5.
Create the data backup (of the master instance)

The data backup requires a medium. Example:
SRC > medium_put FULL_STANDBY \\.\pipe\standbypipe PIPE DATA
Starting of the data backup in status Admin or Online:
SRC > util_connect <dbm-user>,<password>

SRC > backup_start FULL_STANDBY DATA
SRC > util_release
With version 7.3 the backup can be created without a checkpoint (for recovery) because in
the target system (standby instance) always matching log backups will be restored. As of
version 7.4 backups are always created without checkpoints.
Initialize the standby instance and restore the backup with version 7.3 and 7.4
The standby instance must be initialized before a data backup should be restored to the
instance with version 7.3 and 7.4.
TRG > db_offline

TRG > db_cold
TRG > medium_put FULL_SHADOW \\<masterserver>\pipe\shadowpipe PIPE DATA
TRG > util_connect <dbm-user>,<passwort>
TRG > util_execute init config
TRG > recover_start FULL_SHADOW DATA
TRG > util_release
Attention: The ‚init config’ command completely deletes all data content of the instance.
Initialize the standby instance and restore the backup with version 7.5
Version 7.5 and above perform both, the initialization and the restore within one step.
TRG > db_offline

TRG > db_cold
TRG > medium_put FULL_SHADOW \\<masterserver>\pipe\shadowpipe PIPE DATA
TRG > db_activate RECOVER FULL_SHADOW DATA
TRG > util_release
This picture shows how a backup is transferred and restored to the target system using a
remote pipe:
Backup Media for log backups on both master and standby instance
The standby instance requires a medium to restore the log backup. Example :
SRC: medium_put LOG_SAVE d:\sapdb\SRC\saparch\save.log FILE LOG

TRG: medium_put LOG_SAVE d:\sapdb\TRG\saparch\save.log FILE LOG
The log backup will be stored in file d:\sapdb\SRC\saparch\save.log.<nnn>. Each completed

log segment will be stored in a new file. These filenames can be different between master and
standby instance. It is strongly recommended to keep the <nnn> extensions when copying the
backups to the standby system. Beginning with 1000 the number extension has more than 3
digits.
Create the log backups of the master instance :

Depending on your requirements the log now can be backed up in certain intervals:

SRC > backup_start LOG_SAVE
SRC > util_release
To avoid log full situations between two log backups it is recommended to enable automatic
log backup:
SRC > autolog_on LOG_SAVE
The current setting of the automatic log backup can be determined as follows:
SRC > autolog_show
Autosave Log must be switched of if a ‘manual’ log backup should be started.
Example:

SRC > autolog_off
SRC > backup_start LOG_SAVE
SRC > autolog_on
SRC > util_release
The backup history shows all backups with their execution dates.
SRC > backup_history_open

SRC > backup_history_list
If the output does not fit into the buffer of DBMCLI the continuation output can be received by:
SRC > backup_history_listnext
The output of backup_history_list can be configured through options.

With option -nohold for dbmcli the DBM Server will automatically run backup_history_listnext if
the list returned needs more than one buffer.
Restore the log backups to the standby instance:

If multiple log backups are restored to the standby instance a restore session has to be set up:
TRG > util_connect

TRG > recover_start LOG_SAVE LOG 001
Subsequent log backup will then be restored within this session:
TRG > recover_replace LOG_SAVE d:\sapdb\SRC\saparch\src.log 002

The return code will be –8020 „Next medium required“.

The session can be cancelled:
TRG > recover_cancel

TRG > util_release
As of version 7.4.3 the command ‘recover_cancel’ sets the database offline. For further
actions the database has to be set to the status admin (with command db_cold). To restore
further log backups, a new restore session will be opened with recover_start.
Entrypoints during log restore

During restore of the log savepoints are written. After having cancelled a restore session
recover_start allows to continue the restore using the last successful savepoint. It might
become necessary to restore some log backups, which already had been restored during the
last session.
The database provides the last log page of which the data has been made persistent in the
data area:
TRG > db_cold

TRG > db_restartinfo
Used LOG Page 5089
First LOG Page 2147483647
Restartable 1
Id Restart Record P59954:SRC_20020304_144629
Id LOG Info P59954:SRC_20020304_144629
Consistent 1
The line „Used LOG Page“ displays from which log page the next entries are to be taken.
The (log) backup history of the master instance shows, which log pages are part of which
backup:
SRC > backup_history_open

SRC > backup_history_list –c LABEL,FIRSTLOG,LASTLOG –l LOG
END
LOG_00001| 0| 995|
LOG_00002| 996| 1914|
LOG_00003| 1915| 3274|
LOG_00004| 3275| 3728|
LOG_00005| 3729| 4181|
LOG_00006| 4182| 4634|
LOG_00007| 4635| 4828|
LOG_00008| 4829| 5086|
LOG_00009| 5087| 5542|
LOG_00010| 5543| 5995|
SRC > backup_history_close
In this example recover_start has to be provided with log backup LOG_00009.
Alternatively the information about which log pages are part of a log backup can be received
directly out of the log backup:
TRG > medium_labeloffline LOG_SAVE 009

Returncode 0
Date 20020307
Time 00160225
Server hostname
Database SRC
Kernel Version Kernel 7.4.2 Build 003-000-000-000
Pages Transferred 0
Pages Left 0
Volumes
Medianame
Location d:\sapdb\SRC\saparch\src.log.009
Errortext
Label LOG_00009
Is Consistent
First LOG Page 5087
Last LOG Page
DB Stamp 1 Date 20020307
DB Stamp 1 Time 00160213
DB Stamp 2 Date
DB Stamp 2 Time
Page Count 455
Devices Used 1
Database ID hostname:SRC_20020304_144629
Max Used Data Page
Log backup 009 contains logpages 5087 to 5542 (“First LOG Page” + “Page Count”).
If a wrong log backup is specified, the restore command will return –7075. Afterwards a new
restore session has to be opened with recover_start.
Set the standby instance online

The standby instance now shall be used for online operation and thus will be set to the status
online:
TRG > db_cold

TRG > util_connect <dbm-user>,<password>
TRG > recover_ignore
The instance will be set ‚online’ directly. That means that all data that has been cached during
the restore process will stay cached and does not have to be read from the volumes again.
The instance TRG now does not contain all modifications, which have not yet been transferred
from the instance SRC via log backups.
Start of the standby instance to a certain point in time by restoring the logs
Log backups can be restored to a certain point in time (restore log until). This time
specification can be provided with recover_start.

TRG > db_cold
TRG > recover_start LOG_SAVE LOG 009 UNTIL 20020308 173500
If recover_start or recover_replace do not return –8020 but 0 the database has reached the
status online. The ‘UNTIL’ specification can be given only once during a restore session.
Start of the standby instance without loosing committed data (point of failure/failover)
Often the switch from the master instance to the standby instance happens because of a
server failure on the master instance. So if the standby instance will only be provided with log
backups some data will be lost because the recently written log has not been saved yet.
If the log volumes are based on an external disk, the standby server might be able to access
these volumes too.
If the number of log volumes and their sizes are equal in both master and standby instance
the log volumes of the master instance can be copied on the log volumes of the standby
instance.

TRG > db_offline
At this point the log volumes should be copied
TRG > db_warm
An ‚until’ point in time can be specified. This works if the until time has not been applied to the
standby instance, yet:
TRG > db_warm –u 20020309 201300
Recreate Indexes
If CREATE INDEX commands are found in the log these indexes will not be created during log
recovery. Only the repository entries for such indexes will be created. The index will be
marked as ‘bad’ and can be created when the database instance is online.
Those indexes can be determined as follows:
TRG > sql_execute select * from info_bad_indexes
A returncode of 100 ‘Row Not Found’ indicates that there are no ‘bad’ indexes. Otherwise if
indexes are listed they can be built:
TRG > sql_recreateindex
As of version 7.5.00 Build 11 indexes are created automatically after the restart of the
instance with the parameter setting AUTO_RECREATE_BAD_INDEXES=YES. This may
delay the restart of the database.
Previous master instance becomes standby instance

Generally the previous master instance becomes the standby instance by an initialization and
a restore of a data backup from the new master. As of version 7.5.00 Build 17 the database
can clear the log of the new standby instance and immediately restore log backups. The next
example shows the name SRC because this instance now is the standby instance.
SRC > db_cold

SRC > util_connect <dbm-user>,<passwort>
SRC > util_execute clear log
SRC > db_offline
SRC > db_cold
SRC > recover_start LOG_SAVE LOG 013
Special Actions
The recovery process on the standby instance is finished, if the instance has reached the status
online. During the recovery process further action on the standby instance are possible.
Verify
Within the standby instance the internal structure of trees and data pages can be checked
with the verify command. With version 7.3 and 7.4 the recovery has to be interrupted. The
instance has to be set offline before and after the verification. Example:

TRG > db_offline
TRG > db_cold
TRG > util_execute verify
TRG > db_offline
TRG > db_cold
TRG > recover_start LOG_SAVE 014
As of version 7.5 the verify can run in parallel to the log recovery. Start the action either inside
an open dbmcli session with running recovery session or in a separate dbmcli session. The
command db_execute does not need a utilty session.
TRG > recover_start LOG LOG_SAVE 014

TRG > db_execute check data
The check data was not able to check non-rebuild indexes if it returns error –9041. The error
does not indicate corrupt data.
Set the standby instance temporarily online and later continue the standby proceeding
Database Snapshots help setting the standby instance temporarily online. The instance can
return to the snapshot and continue with the log recovery process.

TRG > db_offline
TRG > db_cold
TRG > util_execute create snapshot
TRG > db_warm
…
TRG > db_cold
TRG > util_execute restore snapshot
TRG > util_execute drop snapshot
TRG > util_execute clear log
Further use case for Snapshots

Database snapshots are useful for restoring the instance to a defined point in time. A shadow
instance can proceed with a short delay behind the master instance, but return back to an
older point in time and go online temporarily. The following example script crates a snapshot
at 8:00 a.m., continues the log recovery until 4:00 p.m., returns to 8:00 a.m., repeats the
recovery until 10:00 a.m. and sets the database online. The script sets the instance back to
8:00 a.m. after the online tasks have finished and continues with the log recovery procedure.

TRG > db_offline
TRG > db_cold
TRG > # Create a snapshot at 8:00 a.m.
TRG > util_execute create snapshot
TRG > db_offline
TRG > db_cold
TRG > # At 4:00 p.m. restore to 8:00 a.m.
TRG > db_offline
TRG > db_cold
TRG > db_offline
TRG > db_cold
TRG > # Recovery until 10:00 a.m.
TRG > recover_start LOG_SAVE LOG 014 UNTIL 20020309 100000
TRG > # Online operation
TRG > # Set the instance back to 8:00 a.m. and roll forward
TRG > db_offline
TRG > db_cold
MaxDB supports multiple snapshots simultaneously as of version 7.7.03. The command

“create snapshot” works in online mode as well as in admin mode. Create snapshot doesn’t
delete an existing snapshot, anymore.
Data Backup
If a data backup of the standby instance was created after a cancellation of the recovery, the
recovery process cannot be continued. The standby instance can be set online (without
copying the log volumes from the master instance).

TRG > db_offline
TRG > db_cold
TRG > util_connect
TRG > backup_start FULL DATA
TRG > db_offline
TRG > db_cold
RETURNCODE –8003
TRG > db_warm
The instance gets a new identification with the data backup. Log backups from the master
instance still have the identification of the master instance. The recovery procedure checks if
the log backup fits to the instance. The check fails with error –8003.
Errors / Malfunctions
Returncodes
- 8020 „Next Medium required
A log backup has been restored. Either a subsequent log backup or the restart of the
instance is expected.
- 8003 „Log and data must be compatible“

No more log backup can be restored or the instance cannot be set online. Possible
causes are
The sequence of the log backups does not match during recovery.
The database has been set online in the meantime.
The recovery process has been cancelled and a data backup has been created
- 7075 „Current save skipped... “

The log entries of the log backup specified already have been restored. If available,
the next log backup can be restored.
- 3004 „Invalid host file sequence“

The content of the log backup specified does not match the requirements of the
sequence. If available, the next matching log backup should be restored.
Instance full (DB-full)

Standby instances can run into ‚full’ situation if the data area of the standby instance has been
configured smaller than the one of the master instance. Depending on the database version
the behaviour in such situations is different.
o Version 7.3
The instance executes an ‚emergency shutdown’. The file ‘knldiag’ contains messages as
follows:
...
… WRN 53025 DATA PAGES USED 99(9 PAGES LEFT)
… WRN 53025 DATA PAGES USED 99(1 PAGES LEFT)
…
o Version 7.4
The instance executes an ‚emergency shutdown’. The file ‘knldiag’ contains messages as
follows:
...
… WRN 6 Kernel_E 97 % of data base occupied, 312 pages free
… WRN 6 Kernel_E 98 % of data base occupied, 208 pages free
o Version 7.5
the instance stops but stays in mode admin. The file ‘knldiag’ contains messages as
follows:
... WNG 42 Converte DB FULL(FBM): …
The instance size has to be increased. Then the restore of the log backups can continue:
TRG > db_stop

TRG > db_cold
TRG > db_adddevice DATA <Volumename> <Type (F,R) > <Size in Pages>
…
In future versions db_adddevice will be able to add a new data volume without using a utility
session. The database can be increased during the running recovery with this feature.
Accessing protocol files

The application dbmgetf allows (remote) access to all protcol files of the database. The files
available can be listed with the command
dbmgetf –n <server> -d <Instanz> –u <dbm-user>,<password> -l
Example:
The file knldiag of the standby instance can be shown with the command
dbmgetf –n <standbyserver> -d TRG –u <dbm-user>,<password> -k KNLDIAG

Standby DB MaxDB Eng

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Standby DB MaxDB Eng

Загружено:

Авторское право:

Доступные форматы

SAP

Author: Werner Thesing

Standby Databases with SAP DB/MaxDB or liveCache

Term if version < 7.4.03 Term if Verison >= 7.4.03

Initial data load to the standby database

Sizing of the standby instance with version 7.3

dbmcli -d SRC -u <dbm-user>,<password> -n <masterserver>

Sizing of the standby instance with version >= 7.4

Space to restore the log backups

Naming Data Volumes and Log Volumes

Switching options for master and standby

Indexes (Secondary Keys)

Savepoints and Checkpoints

Now we will show the process with DBMCLI command examples:

SRC > <command>

The major steps to run a standby instance are :

Create the standby instance

Create the data backup (of the master instance)

Now the steps will be explained one-by-one.

Create a standby instance

Create the data backup (of the master instance)

SRC > medium_put FULL_STANDBY \\.\pipe\standbypipe PIPE DATA

Starting of the data backup in status Admin or Online:

SRC > util_connect <dbm-user>,<password>

TRG > db_offline

TRG > db_offline

SRC: medium_put LOG_SAVE d:\sapdb\SRC\saparch\save.log FILE LOG

The log backup will be stored in file d:\sapdb\SRC\saparch\save.log.<nnn>. Each completed

Create the log backups of the master instance :

SRC > util_connect <dbm-user>,<password>

SRC > autolog_on LOG_SAVE

Autosave Log must be switched of if a ‘manual’ log backup should be started.

SRC > util_connect <dbm-user>,<password>

SRC > backup_history_open

SRC > backup_history_listnext

The output of backup_history_list can be configured through options.

Restore the log backups to the standby instance:

TRG > util_connect

Subsequent log backup will then be restored within this session:

TRG > recover_replace LOG_SAVE d:\sapdb\SRC\saparch\src.log 002

The return code will be –8020 „Next medium required“.

TRG > recover_cancel

Entrypoints during log restore

TRG > db_cold

SRC > backup_history_open

In this example recover_start has to be provided with log backup LOG_00009.

TRG > medium_labeloffline LOG_SAVE 009

Set the standby instance online

TRG > db_cold

TRG > recover_cancel

TRG > util_connect <dbm-user>,<password>

TRG > db_warm –u 20020309 201300

Those indexes can be determined as follows:

TRG > sql_execute select * from info_bad_indexes

TRG > sql_recreateindex

Previous master instance becomes standby instance

SRC > db_cold

TRG > recover_replace LOG_SAVE d:\sapdb\SRC\saparch\src.log 014

TRG > recover_start LOG LOG_SAVE 014

TRG > recover_replace LOG_SAVE d:\sapdb\SRC\saparch\src.log 014

Further use case for Snapshots

TRG > recover_replace LOG_SAVE d:\sapdb\SRC\saparch\src.log 014

MaxDB supports multiple snapshots simultaneously as of version 7.7.03. The command

TRG > recover_replace LOG_SAVE d:\sapdb\SRC\saparch\src.log 014