Log Shipping

SAP on Sybase Adaptive Server Enterprise (Sybase ASE)

Log Shipping SAP on Sybase ASE

2

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
Log Shipping SAP on Sybase ASE

3

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.

2 LOG SHIPPING PROCESS
The basic process for log shipping is as follows:
Log shipping is performed by triggering occasional database dumps on the primary database and, in
between these database dumps, by generating periodic transaction log dumps.
The standby system is maintained by loading a database dump (to initially populate the database), and as
each transaction log is generated on the primary system, it is copied to the standby system, where it is
applied using LOAD TRAN.
The final transaction logs dumped on the primary system will be loaded onto the standby system, if the
standby system is needed. The ONLINE DATABASE command ends the load sequence and brings the
database online on the standby system.

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.

The following example illustrates this.

Primary database:

DUMP DATABASE dump1
DUMP TRAN tran1
DUMP TRAN tran2
...
DUMP TRAN tran100
DUMP DATABASE dump2
DUMP TRAN tran101
DUMP TRAN tran102
DUMP TRAN tran103

Standby system:

LOAD DATABASE dump1
LOAD TRAN tran1
LOAD TRAN tran2
...
LOAD TRAN tran100
LOAD TRAN tran101
LOAD TRAN tran102
LOAD TRAN tran103

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:
Log Shipping SAP on Sybase ASE

4

LOAD DATABASE dump2
LOAD TRAN tran101
LOAD TRAN tran102
LOAD TRAN tran103

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

3.1 Disaster Recovery
In a disaster recovery scenario a standby database is kept up to date with regular log shipping. It is brought
online if the primary database fails and is not recoverable. In this case, two possible scenarios or setup
configurations are possible:
Dual Network configuration
Manual Reconfiguration

3.1.1 Dual Network Configuration
This setup is recommended for environments where the servers are part of a local LAN. This would ensure
that the database instance is local as far as the SAP applications are concerned, which means that slow
network transfer rates are avoided.
This setup requires the following configuration (see Figure 1):
1. Perform the primary and standby installations using a virtual host name that represents both
database instances. This requires that both systems have the same SID, virtual host name, and port.
2. Configure two separate networks between the database instances.
One network is used for communication between the database instances only that is, they will be
used for log shipping (for example, y.y.y.y).
The secondary network is used for communication with the central instance server (for example,
x.x.x.x).
3. Set up a virtual host name that points to the IP address of the database instance currently running
(for example, x.x.x.2).
4. Proceed as follows if permanent failure of the primary database instance occurs:
a. Shut down the central instance.
b. Perform a transaction dump on the primary database and load it into the secondary
database. If this is not possible, there will be a loss of data between the time the last log
dump was performed and the time of failure.
c. Bring the secondary database online in accordance with the steps outlined later in this
document.
d. Switch the host name so that it points to the IP (x.x.x.3) of the standby database instance.
e. Bring the central instance back online if it was shut down in step a.
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.
Log Shipping SAP on Sybase ASE

5

Figure 1 : Dual Network Configuration (Disaster Recovery)
3.1.2 Manual Reconfiguration
If it is not possible to set up a dual network configuration with virtual host names as mentioned above, you
can also perform this task manually. This situation can arise due to the distant location of the system. This
setup requires manual intervention and reconfiguration by the administrator at the time of recovery. The
manual setup procedure is as follows:
1. Perform the primary and standby installation using separate host names.
2. Configure a single network that will provide communication between the database instances as well
as communication with the central instance.
3. Proceed as follows in the case of failure of the primary database instance:
a. Shut down all SAP applications.
b. Bring the secondary database online in accordance with the steps outlined later in this
document.
c. Manually update the environment variables on the central instance that point to the database
instance. The required steps are outlined later in this document.
d. Update the default profile so that it points to the standby database instance. The required
steps are outlined later in this document.
e. Set all SAP applications so that they point to the host name / IP of the standby database
instead of the primary database. This can be done in the Solution Manager, for example.
f. Bring All SAP applications back online.

3.2 Delayed Replication / Recreating the SAP System
This use case is defined for scenarios where a duplicate system (for example, a test system) that is close to
the setup of the production system is required for use. This scenario is also useful for a setup where it is
required that you have an SAP system in a delayed replication state that is, it is lagging behind in the log
updates and thus not able to recover to a specific time in the past.
Log Shipping SAP on Sybase ASE

6
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.


Figure 2 : Delayed Replication / Recreating the SAP System
Log Shipping SAP on Sybase ASE

7

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.

Database user: sa_role or oper_role
OS user: authorization to read, write, and execute scripts at OS level

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.

5 SAP INSTALLATION SCENARIOS
In order to set up log shipping, choose one of the following installation scenarios:
Central System Installation
Distributed System Installation
These installation scenarios will enable customers to connect to a second standby system.

5.1 Central System Installation
This scenario represents the installation of two separate central system installations with the same SID. It is
recommended as a disaster recovery setup for servers across large distances that is, where a high-speed
LAN is not feasible.
5.1.1 Architecture
Below you see a general architecture diagram that explains this scenario:
Log Shipping SAP on Sybase ASE

8

Figure 3 : Central System Installation
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.
Log Shipping SAP on Sybase ASE

9
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.

5.2 Distributed System Installation
This scenario represents an installation of a single host with global host and central instances. Additionally,
two separate hosts are set up with the database instances using the same central instance. Log shipping is
implemented between these two database instances.
This scenario is recommended for the disaster recovery use case where you have all the servers in the same
LAN.
5.2.1 Architecture

Figure 4 : Distribute System Installation
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.
Log Shipping SAP on Sybase ASE

10
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:

- dump (database and transaction dumps)
- sql (SQL scripts required for the dump/load)
- scripts (batch/shell scripts required for this process)
- log (output logs for each step in this process)

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:

Variable: Description: Example Value:
USER Source database user name sa
PASS Source database user password password
SERVER Source server host name source
SRC_PORT Database server port on source
system

REM_SERVER Destination server host name destination
REM_USER Destination server user name root
REM_PASS Destination server user password
(only needed if private key
authentication is not set up)

DMP_LOC Location of database dumps on source c:\logship\dump
TRANS_LOC Location of transaction dumps on
source
c:\logship\dump
Log Shipping SAP on Sybase ASE

11
DUMP_ARCH Location of dump archives on source c:\logship\dump\archi
ve
REM_DMP_LO
C
Location of DB dumps on destination c:\logship\dump
REM_TRANS_
LOC
Location of transaction dumps on
destination
c:\logship\dump
SCRPT_LOC Location of shell scripts c:\logship\scripts
SQL_SCRPT_L
OC
Location of sql scripts c:\logship\sql
LOG_LOC Location of logs c:\logship\log
LOG_ARCH Location of log archives c:\logship\log\archive


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)
Variables : Description : Example Value:
USER Destination DB user name sa
PASS Destination DB user password password
ASESERVER Destination ASE server name (not the
host name)
SYBASE
SQL_SCRPT_L
OC
Location of the SQL scripts on
destination
c:\logship\sql
LOG_LOC Location of the log files on destination c:\logship\log

o Adapt the following sql scripts in accordance with your environment:
- load_db.sql
- load_log.sql
- dump_db.sql
- dump_log.sql
7 LOG SHIPPING PROCESS
7.1 Initial Database Dump / Load
An initial dump was performed at the time of system copy to the secondary node. If changes have been
made to the destination database after this system copy process, perform a database dump using the script
run.bat. This will dump the complete source database, transfer the file to the destination server, and perform
a 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 db for example, run.bat db (run.sh db).
a. This script will first make a full dump of your source database. If a current dump is available,
it will archive it in a subfolder before performing a fresh 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.
Log Shipping SAP on Sybase ASE

12
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.
isql U[DB User] P[DB User Password] S[DB Server Name]
for example, isql Usa Pp@$$w0rd SSYBASE

3. Issue the following SQL command to bring the database online:

online database [DB NAME]
go
Log Shipping SAP on Sybase ASE

13
Your destination database is now ready for read/write transactions.
Note: After the database has been brought online, you will not be able to load further incremental transaction
dumps into this database unless you perform a full database dump/load sequence.
8.2 User Profile update

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.
8.3 SAP Default Profile Update
Use the following process to update the default profile so that it points to the correct database instance:
1. Log on to the machine that has the global host role.
2. Stop all SAP applications.
3. Go to the folder where the DEFAULT profile is stored (for example,
c:\usr\sap\<SID>\SYS\profile\DEFAULT.PFL).
4. Modify the following parameters so that they point to the host name of the correct database instance:
j2ee/dbhost
dbs/syb/server
SAPDBHOST
5. Restart all SAP applications.
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.

9.2 Database / Log Dump Transfer Errors
During the transfer of dumps from the source system to the destination system, any error captured is logged
in the file dbtrsfr.log stored in the log directory. The script run.bat (run.sh) raises an error if this file is not
empty. See the log file for the description of the problem and fix the problem before running the script again.

9.3 Database / Log Dump Load Errors
During the load of the database dump or transaction dumps, the errors are captured in the files logload.log
and dbload.log for transaction load and database load, respectively, and stored in the log directory.
The following errors are captured during the database/log dump process:
- MSG 3101
The database is in use. A user with system administrator role SA must have exclusive use of the
database to run the load.
- MSG 4002
Login failed on the database. Check the user name and password, and try again.
Log Shipping SAP on Sybase ASE

14
- 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.
Log Shipping SAP on Sybase ASE

15

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.

On the primary system:
DUMP DATABASE dump1
DUMP TRAN tran1
DUMP TRAN tran2
...
DUMP TRAN tran100

ALTER DATABASE ON datadev=10G LOG ON logdev=1GB (increase the database by 10GB data and
1GB log)

DUMP TRAN tran101

On the standby system:
LOAD DATABASE dump1
LOAD TRAN tran1
LOAD TRAN tran2
LOAD TRAN tran100
LOAD TRAN tran101 <-- fails because the database is not large enough to accommodate the load, so:

ALTER DATABASE ON datadev=10G LOG ON logdev=1GB (increase the database by 10GB data and
1GB log)

LOAD TRAN tran101 <-- succeeds

- 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
Log Shipping SAP on Sybase ASE

16
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.

Log Shipping SAP on Sybase ASE

17

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:

dump transaction <Database Name>to <Dump File>with standby_access

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:

online database <Database Name>for standby_access

In order to bring the database online for read/write operations, the following command can be used:

online database <Database Name>








2011 SAP AG. All rights reserved.
SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign,
SAP BusinessObjects Explorer, StreamWork, SAP HANA, and other
SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP AG
in Germany and other countries.

Business Objects and the Business Objects logo, BusinessObjects,
Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and
other Business Objects products and services mentioned herein as
well as their respective logos are trademarks or registered trademarks
of Business Objects Software Ltd. Business Objects is an SAP
company.

Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL
Anywhere, and other Sybase products and services mentioned herein
as well as their respective logos are trademarks or registered
trademarks of Sybase, Inc. Sybase is an SAP company.

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.

These materials are subject to change without notice. These materials
are provided by SAP AG and its affiliated companies ("SAP Group")
for informational purposes only, without representation or warranty of
any kind, and SAP Group shall not be liable for errors or omissions
with respect to the materials. The only warranties for SAP Group
products and services are those that are set forth in the express
warranty statements accompanying such products and services, if
any. Nothing herein should be construed as constituting an additional
warranty.
www.sap.com