Professional Documents
Culture Documents
Log Shipping: SAP On Sybase Adaptive Server Enterprise (Sybase ASE)
Log Shipping: SAP On Sybase Adaptive Server Enterprise (Sybase ASE)
TABLE OF CONTENTS
1 SUMMARY ........................................................................................................................................ 3
2 LOG SHIPPING PROCESS .............................................................................................................. 3
3 USE CASES ...................................................................................................................................... 4
3.1 Disaster Recovery ........................................................................................................................... 4
3.1.1 Dual Network Configuration ............................................................................................................... 4
3.1.2 Manual Reconfiguration ..................................................................................................................... 5
3.2 Delayed Replication / Recreating the SAP System ...................................................................... 5
3.2.1 Configuration ..................................................................................................................................... 6
4 PREREQUISITES .............................................................................................................................. 7
5 SAP INSTALLATION SCENARIOS ................................................................................................. 7
5.1 Central System Installation............................................................................................................. 7
5.1.1 Architecture ........................................................................................................................................ 7
5.1.2 Recovery ............................................................................................................................................ 8
5.2 Distributed System Installation ...................................................................................................... 9
5.2.1 Architecture ........................................................................................................................................ 9
5.2.2 Recovery .......................................................................................................................................... 10
6 SCRIPT CONFIGURATION ............................................................................................................ 10
7 LOG SHIPPING PROCESS ............................................................................................................ 11
7.1 Initial Database Dump / Load........................................................................................................ 11
7.2 Incremental Transaction Dump .................................................................................................... 12
8 RECOVERY ..................................................................................................................................... 12
8.1 Database ......................................................................................................................................... 12
8.2 User Profile update ........................................................................................................................ 13
8.3 SAP Default Profile Update ........................................................................................................... 13
9 ERROR LOGGING .......................................................................................................................... 13
9.1 Database / Log Dump Errors ........................................................................................................ 13
9.2 Database / Log Dump Transfer Errors ......................................................................................... 13
9.3 Database / Log Dump Load Errors .............................................................................................. 13
10 ADDITIONAL INFORMATION ........................................................................................................ 15
11 ADDITIONAL OPTIONS ................................................................................................................. 17
11.1 Standby Read-Only Access .......................................................................................................... 17
2
Log Shipping SAP on Sybase ASE
1 SUMMARY
This document describes the concepts and implementation of log shipping when using SAP on Sybase ASE
15.7. Log shipping is the process of automating the backup of database and transaction log on a primary
database server, and then restoring them on a standby server.
The purpose of this document is to provide a guide with step-by-step instructions on how to reproduce this
kind of setup. The scenario illustrated here is intended as a template for setting up log shipping in a
customer environment. It describes a very specific setup and thus requires detailed review in order to fit the
specific customer needs. It is not the purpose of this guide to replace any installation documentation or
provide a strict scenario to be followed in a customer production environment.
While it is only necessary to have just one database dump and then only subsequent transaction dumps at
regular intervals, it is recommended that you perform database dumps at less frequent intervals (for
example, once weekly) than regular transaction dumps (for example, hourly or daily) to avoid running a long
list of transaction loads in case a full system rebuild is required.
Primary database:
Standby system:
If the primary database needs to be recreated from the dumps, only the following loads have to be performed
in order to get the system up and running:
3
Log Shipping SAP on Sybase ASE
Note: This setup involves log shipping and recovery of the Sybase database only. It does not take into
account the changes made to the master or any other database. This means that if changes are made to
these devices, they have to be performed manually on the standby server. Users created on the database
server and changes to these users are not captured either. This should be taken into account when setting
up a backup or recovery strategy.
3 USE CASES
The following use cases are provided for this setup and explained below:
Disaster Recovery
Delayed Replication / Recreating the SAP System
Note: If logs were not recoverable after the database crash on the primary database, there will be a loss of
data since the time the last log dumps were performed.
4
Log Shipping SAP on Sybase ASE
5
Log Shipping SAP on Sybase ASE
3.2.1 Configuration
This setup is configured as follows (see Figure 2):
1. Perform the primary and the standby installation using separate host names. Follow the steps
outlined in the SAP documentation to perform a complete installation.
2. Configure a single network that provides communication between database instances as well as
communication with the central instance.
3. The preparatory steps on the duplicate system after performing the initial installations are as follows:
a. Shut down all the SAP applications on the standby server, except the standby database
server.
b. Load the database dump from the original system into the secondary system. This will bring
the database into rollforward state until such time as an explicit online database command is
issued.
c. Load all the transaction dumps performed after the database dump into the secondary
system. This is a continual process; transaction dumps are regularly dumped and loaded
into the standby system.
d. Bring the secondary database online in case if failure of the primary system occurs or if there
is some user error that requires a point-in-time status of the database.
e. Bring the central instance online on the secondary system.
6
Log Shipping SAP on Sybase ASE
4 PREREQUISITES
The following are the prerequisites and preliminary steps for setting up log shipping.
1. Define the systems that will act as log shipping partners. Also make sure that there is an appropriate
network communication defined between the systems in question.
2. Set up an SSH server on the destination system and an SCP utility on the source system in order to
ensure secure transfer between systems.
Note: You may also choose any other form of transfer for example, FTP, SFTP, and File Sharing.
3. Install appropriate software for issuing remote commands from the source system. This is needed in
order to facilitate the issuing of LOAD DATABASE / LOAD TRANSACTION commands remotely. For
a setup with Windows or UNIX, you can use the SSH server and an SSH client.
4. Grant user authorizations.
A user is required at OS level with authorizations to read, write, and execute scripts on the directory
where the scripts and dumps are located and another user that has OS level authorization to read,
write, and execute scripts on the destination system.
Note: This communication can be secured by exchanging private keys for authentication in order to
avoid passing passwords over the network.
5. Synchronize Time
This is important to ensure that both log shipping partners are synchronous in time. A different time
zone does not affect this process.
7
Log Shipping SAP on Sybase ASE
In this scenario, two machines are installed with the SAPinst option Central System for an SAP NetWeaver
installation. Both installations have the same System ID (SID). Here, the secondary SAP system is not
online. It should remain offline since it would otherwise break the log sequence. It is only brought online if
there is a failure on the primary SAP system.
After the installation, the following tasks must be performed:
1. Shut down the standby instance LS1 and keep the Sybase ASE database running.
2. Modify the primary and standby database options, as specified in SAP Note 1585981.
Note: DUMP TRAN automatically truncates the log of the primary database as part of its work. This
takes place within a transaction that is itself logged. Therefore, this same truncation is applied on the
standby database when the transaction log that contains the transaction is loaded and replayed. As
a result, there is no need to maintain the log for the standby since this is done automatically by the
process of loading it. In addition, provided the standby database is big enough, there is no chance of
space running out in the standby database log.
3. Install the license for the primary and standby systems on the central instance. This will ensure that
the license information is also copied to the standby machine when the database dump/load is
performed.
4. Perform a dump on the database from the primary instance database LS1 .
5. Load the database dump onto the standby database. This will put the standby database in a
quiescent state, thus allowing the transaction logs from the primary database to be loaded.
6. Regular transaction dumps are performed and transported to the standby system.
7. Transaction dumps are loaded into the standby system in order to keep the standby system updated.
5.1.2 Recovery
If the primary system goes offline, bringing the standby system online will require the following steps:
1. Make sure all transaction dumps have been loaded into the standby system.
8
Log Shipping SAP on Sybase ASE
2. Bring the standby database online on the standby Sybase ASE server as described later in this
document.
3. Start the SAP applications.
4. Notify users that the system is online.
Note: Log shipping does not fully safeguard against data loss. It is possible that a failure on the primary
database can result in the loss of data that has not yet been backed up.
In this scenario, one machine has the central instance and the global host installed. Two other machines are
installed as database instances. Initially, the default profile is configured for the primary database instance.
After the installation, the following steps are performed:
1. Shut down the standby instance LS2 and keep the Sybase ASE database running.
2. Modify the primary and standby database options, as specified in SAP Note 1585981.
Note: DUMP TRAN automatically truncates the log of the primary database as part of its work. This
takes place within a transaction that is itself logged. Therefore, this same truncation is applied on the
standby database when the transaction log that contains the transaction is loaded and replayed. As
a result, there is no need to maintain the log of the standby since this is done automatically by the
process of loading it. In addition, provided the standby database is big enough, there is no chance of
space running out in the standby database log.
3. Perform a dump on the database from the primary instance database LS1.
9
Log Shipping SAP on Sybase ASE
4. Load the database dump onto the standby database. This will put the standby database in a
quiescent state, thus allowing the transaction log from the primary database to be loaded.
5. Regular transaction dumps are performed and transported to the standby system.
6. Transaction dumps are loaded into the standby system in order to keep the standby system updated.
5.2.2 Recovery
If the primary system goes offline, bringing the standby system online will require the following steps:
1. Stop all SAP applications.
2. Make sure all transaction dumps have been loaded into the standby system.
3. Bring the standby database online, as described later in this document.
4. Modify the default profile so that it points to the standby system, as described later in this document.
5. Modify the user profile of <SID>adm, and also modify the user environment variable so that it points
to the secondary database instance.
6. Start the SAP applications.
7. Notify users that the system is online.
6 SCRIPT CONFIGURATION
The log shipping process is controlled with the help of scripts, some of which are located on the source
machine. Others should be on the destination machine. Perform the following steps on both machines to
prepare the scripts:
1. Unzip/untar the zip/tar file attached to this SAP Note to the root of the drive. This action will result in
a folder called logship for example, c:\logship for Windows and /logship for Unix:
A folder with the name logship is created on the root directory of the drive. The following subfolders
are created under the logship root folder:
2. Adjust the paths and users defined in the scripts to match your scenario. This has to be done for all
batch and shell scripts as well as for sql scripts.
o Adapt the following variables in the run.bat / run.sh files in accordance with your
environment:
10
Log Shipping SAP on Sybase ASE
o Adapt the following batch scripts and adjust the variables listed below in accordance with
your environment:
- load_db.bat (load_db.sh for UNIX)
- load_log.bat (load_db.sh for UNIX)
11
Log Shipping SAP on Sybase ASE
c. If no error is found, the script will copy the dump file to the destination system using the SCP
command.
d. Upon successful completion of the SCP, the script will execute a shell script (load_db.bat /
load_db.sh) that will perform the load into the remote system using SSH commands.
e. After successful completion of the load, you will have the remote database in a quiescent
state.
Note: It is recommended that you perform database dumps on a less frequent basis than transaction
dumps. This will facilitate faster recovery if the source or destination database needs to be created
from scratch due to disk or device failures. (In this setup, we used daily dumps for the database; see
the scripts attached to this SAP Note.)
7.2 Incremental Transaction Dump
In order to perform incremental dumps of transactions, schedule a job using the script run.bat (or run.sh) with
switch db. This will dump the transactions performed since the last transaction dump, and it will also transfer
the file to the destination server and perform a transaction load into the destination database.
1. Log on to the source machine with a user that has the appropriate authorization to perform the
database dump.
2. Navigate to the location where you created the log shipping folder structure for example,
c:\logship.
3. Execute run.bat (run.sh) with parameter log for example, run.bat log (run.sh log).
a. This script will first perform a transaction dump of your source database. If a current dump is
available, it will archive it in a subfolder before performing a new transaction dump.
b. The script will monitor the logs for any errors. If such exist, the script will exit with either an
error message or a generic error message. In this case, check the appropriate logs and
correct the error before performing a fresh dump.
c. If no error is found, the script will copy the dump file to the destination system using the SCP
command.
d. Upon successful completion of the SCP, the script will execute a shell script (load_log.bat /
load_log.sh) that will perform the load into the remote system using SSH commands.
e. After successful completion of the load, you will have the remote database in a quiescent
state.
Note: This task can also be scheduled using any OS level task scheduler, such as a job scheduler. The
timings of such dumps can depend on the individual scenario and on the requirements of the customer. This
setup requires 5 minutes as a standard time for such transaction dumps.
8 RECOVERY
The following steps are required for the recovery process.
8.1 Database
After successful load of the database dump or subsequent transaction dumps, the database is placed in a
quiescent state that is, no read/write actions are possible. In order to enable the database for read/write
actions, you need to perform the following steps:
1. Log on to the destination machine with a user that has appropriate authorization to run isql.
2. Log on to the database server using the following command.
12
Log Shipping SAP on Sybase ASE
To update the user environment variable so that it points to the database server in the <SID>adm user
profile, proceed as follows:
1. Log on with user <SID>adm.
2. Update the user environment variable dbs_syb_server so that it points to the host name of the
standby system.
9 ERROR LOGGING
Some error checks were also performed during the setup of this scenario. These can be enhanced in a real
implementation scenario. The errors captured are grouped into three categories:
9.1 Database / Log Dump Errors
Errors pertaining to database dumps are captured in the file dmpdbout.log, which is stored in the log
directory. Errors pertaining to log dumps are captured in the file dmplgout.log, which is also stored in the
log directory.
The following errors are captured during the database/log dump process:
- MSG_4002
This is a generic error indicating that the script was unable to log on to the server. Check the credentials
and/or server to see if it is online and accessible.
- MSG_7205
This is a generic error indicating that a connection with the backup server could not be achieved. Check
the server to see if it is online and accessible.
13
Log Shipping SAP on Sybase ASE
- MSG 4305
The specified log dump file is out of sequence. Run a complete database dump or load the transaction
dumps in the correct sequence before trying this transaction load again.
- Unknown Error
All other errors are captured in the log files mentioned above. Review the log files and correct the errors
before starting the process again.
14
Log Shipping SAP on Sybase ASE
10 ADDITIONAL INFORMATION
- DDL changes are copied to the standby database as part of log shipping.
- The log dump cannot be performed if both the log and the data are maintained in the same device.
- You cannot run a dump transaction on a new database until you have run the dump database.
- A cross-platform dump and load (XPDL) that allows dumping on a small endian platform and loading on
a big endian platform (or vice versa) must not be used.
- The receiving database must be as large as or larger than the database to be loaded. If the receiving
database is too small, the Adaptive Server displays an error message that gives the required size.
- The dumped database must have the same page size as that used by the server that is hosting the
archive database. With SAP installations on Sybase ASE, 16k page size is used.
- The primary or the standby system can be rebooted at any time without affecting the dump and load
sequences on either system.
- The size of a database on the primary system can be increased at any time without affecting the standby
system. The only requirement is that the database on the standby system is large enough to
accommodate the change. If not, the standby database can be increased in size (to match that of the
primary system), without affecting the load sequence (with one exception described below).
- As an example, let us suppose the primary and standby databases have 100 GB data and 10 GB log.
ALTER DATABASE ON datadev=10G LOG ON logdev=1GB (increase the database by 10GB data and
1GB log)
ALTER DATABASE ON datadev=10G LOG ON logdev=1GB (increase the database by 10GB data and
1GB log)
- The load sequence is affected in one case. This occurs when the Sysgams table in the database needs
to be extended by the ALTER DATABASE command. This system catalog is used to map space in the
database. Sysgams must be extended when the database size exceeds a multiple of (16384 * (pgsize -
32)) pages. For a database with 16K page size, this amounts to 4088 GB. Whenever the ALTER
DATABASE command makes the database bigger than 4088 GB, 8176 GB, 12264 GB, the ALTER
DATABASE is not allowed on the standby system unless the WITH OVERRIDE option is used with the
command. If ALTER DATABASE ... WITH OVERRIDE is specified, the space will be added to the
15
Log Shipping SAP on Sybase ASE
database, but the next load will not be possible as the load sequence will have been broken. A database
dump will need to be loaded to restart the sequence.
- The load sequence is also affected if a log dump is performed on the standby database. At that point, it
is necessary to load a complete database to bring it back in sequence.
- It is important to note that it is only possible to perform a transaction dump while a database dump is in
progress with Sybase ASE 15.7 ESD 1.
- This setup only considers a single system installation per machine. If you need to have two systems
installed on the same machine, make sure that you separate the scripts for each of the setups in order to
avoid any conflict and that you adapt the scripts accordingly for example, c:\logship\<sid>.
- Scheduling of jobs should be run under the SYB<SID> user so as to avoid any environment variable
problems.
16
Log Shipping SAP on Sybase ASE
11 ADDITIONAL OPTIONS
11.1 Standby Read-Only Access
Only at database level is it possible to have access to the standby database in a read-only state. This option
is not supported for SAP applications that is, a database cannot be in read-only mode while SAP
applications are running.
In order to achieve this, the SQL scripts need to be adapted to add the option with standby_access at the
time of the transaction dump. For example:
Note that this option only dumps the transaction up to a consistent state. This means that some of the
transactions may be lost in order to keep the database consistent. More information about this option can be
found in the Sybase ASE documentation.
After each transaction load, the destination database can be brought online in read-only mode with the
following command:
In order to bring the database online for read/write operations, the following command can be used:
17
www.sap.com
All other product and service names mentioned are the trademarks of
their respective companies. Data contained in this document serves
informational purposes only. National product specifications may vary.