LogShipping(SYBASE)

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


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:


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.


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.


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


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:


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.


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.


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


11

DUMP_ARCH Location of dump archives on source c:\logship\dump\archive

REM_DMP_LOC

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_LOC

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_LOC

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.


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


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.


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.


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


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.


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

Documents

LogShipping(SYBASE)