DR Agent Configuration and Users Guide

Configuration and Users Guide
Disaster Recovery (DR) Agent

15.7.1
DOCUMENT ID: DC00000-01-1571110-01

LAST REVISED: September 2013
Copyright 2013 by Sybase, Inc. All rights reserved.
This publication pertains to Sybase software and to any subsequent release until otherwise indicated in new editions or
technical notes. Information in this document is subject to change without notice. The software described herein is furnished
under a license agreement, and it may be used or copied only in accordance with the terms of that agreement.
Upgrades are provided only at regularly scheduled software release dates. No part of this publication may be reproduced,
transmitted, or translated in any form or by any means, electronic, mechanical, manual, optical, or otherwise, without the prior
written permission of Sybase, Inc.
Sybase trademarks can be viewed at the Sybase trademarks page at http://www.sybase.com/detail?id=1011207. Sybase and
the marks listed are trademarks of Sybase, Inc. indicates registration in the United States of America.
SAP 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 in several other countries all over the world.
Java and all Java-based marks are trademarks or registered trademarks of Oracle and/or its affiliates in the U.S. and other
countries.
Unicode and the Unicode Logo are registered trademarks of Unicode, Inc.
All other company and product names mentioned may be trademarks of the respective companies with which they are
associated.
Use, duplication, or disclosure by the government is subject to the restrictions set forth in subparagraph (c)(1)(ii) of DFARS
52.227-7013 for the DOD and as set forth in FAR 52.227-19(a)-(d) for civilian agencies.
Sybase, Inc., One Sybase Drive, Dublin, CA 94568.
Contents
Introduction to DR Agent ......................................................1
Disaster Recovery Environment Architecture .................2
Adaptive Server High Availability Disaster Recovery
System .......................................................................2
Before You Begin ...................................................................5
SAP Prerequisites ...........................................................5
Standby System Administration ......................................5
Technical Prerequisites and Limitations ..........................6
Sybase Replication Software Versions and
Downloads ..................................................................7
Sybase Replication Software Installation ............................9
Preinstallation Tasks ......................................................9
Changing the DR Agent Port ..........................................9
Validating Adaptive Server Configuration .....................10
Add Additional Adaptive Server Users ..........................11
Maintenance User ................................................11
Creating the Maintenance User ...........................12
DR Agent Administration User .............................13
Creating DR Agent Administration Login .............13
Installing Replication Server .........................................14
Installing Replication Server on Windows ............15
Running the DR Agent ........................................................17
Starting and Stopping DR Agent in UNIX .....................17
Starting and Stopping DR Agent in Windows ...............20
Verifying the DR Agent .................................................21
Viewing the Log Files ....................................................22
Connecting to DR Agent ...............................................22
Setting Up the Disaster Recovery Solution .......................23
DR Agent Security ........................................................23
DR Agent Error Handling ..............................................24
Defining a Logical Host .................................................24
iii
Contents
Defining the Primary Host ....................................25

Defining the Standby Host ...................................25
Defining the Replication Server on a Separate
Computer ........................................................25
Defining the DR Agent Server Port on a
Separate Computer .........................................25
Dropping a Host ...................................................26
Setting Databases Names ............................................26
Defining the SAP SID ...................................................26
Identifying the Maintenance User .................................26
Specifying the Database Dump Location ......................27
Specifying the Replication Server Device Location ......27
Reviewing the SAP Environment Properties ................27
Calculating the Replication Disk Buffer Requirements
..................................................................................27
Replication Disk Buffer Size ..........................................28
Adjusting the Default Replication Disk Buffer
Size .................................................................29
Replication Server Properties Tuning ...........................29
Replication Server Database Properties Tuning ...........29
Validating the Environment Before Running Setup .......30
Marking the Database for Replication ...........................30
Running Setup ..............................................................31
Monitoring the Setup Progress .....................................32
Cancelling the Setup Process .......................................33
Starting the Replication Server as a Windows Service
..................................................................................33
Database Materialization .....................................................35
Identifying the Database Dump Directory .....................36
Materializing with a Different User ................................37
Materializing the Master Database ...............................37
Materializing the SAP Tools Database ..........................38
Materializing the SAP Database ...................................39
Materializing Using Database Dump and Load . . .39
iv
Contents
Materializing Using Transaction Dump and Load

.........................................................................40
Materializing the Standby Database Using the
External Method .......................................................41
Cancelling Materialization .............................................42
Verifying Materialization for External Method ............... 42
Setting Up Adaptive Server HADR ...............................43
Rematerializing the ERP or SAP Tools Database ........ 43
Recovering from a Failed Materialization ......................43
Monitoring the Replication Environment ...........................45
sap_status Returned Information ................................. 45
Tracing Latency .............................................................45
Monitoring Resource Usage .........................................46
Scenarios That May Require Additional Device Space
..................................................................................46
Adding Replication Server Device Space .....................47
Replication Commands .......................................................49
Other DR Agent Commands ...............................................51
Failover .................................................................................55
Performing Planned Failover .........................................56
Unplanned Failover .......................................................56
Failback .........................................................................57
Upgrading DR Agent ...........................................................59
Upgrading Replication Servers and Adaptive Servers ....61
Upgrading the Standby Replication Server ...................61
Suspending Replication to the Standby Adaptive
Server Database ............................................. 61
Verifying Replication is Complete ........................61
Shutting Down the Standby Replication Server ...62
Shutting Down the Standby DR Agent .................63
Performing the Standby Replication Server
Upgrade ...........................................................63
Starting the Standby DR Agent ........................... 63
Restoring Replication to the Standby Adaptive
Server Database ............................................. 63
Contents
Upgrading the Standby Adaptive Server .......................63

Suspending Replication to the Standby Adaptive
Server Database .............................................64
Verifying Privileges for User sapsso ....................64
Performing Adaptive Server Upgrade ..................64
Removing User sapsso Privilege .........................64
Restoring Replication to the Standby Adaptive
Server Database .............................................64
Upgrading the Primary Adaptive Server and
Replication Servers ..................................................65
Tearing Down a Replication Environment .........................67
Replication-Related Servers ...............................................69
Starting DR Agent .........................................................69
Starting Replication Server ...........................................69
Replication-Related Log Files ............................................71
Index ..................................................................................73
vi
Introduction to DR Agent
Disaster Recovery (DR) Agent supports automated setup and configuration, monitoring, and
administration for an SAP Business Suite for Adaptive Server disaster recovery solution.
Note: The commands described in this guide are for reference only. SAP recommends that
you use the SAP tools for administering and configuring the high availability disaster recovery
(HADR) sytem. SAP tools are wrappers around DR Administration tools, which are wrappers
around the sp_hadr_admin system procedure.
Traditionally, setting up and configuring replication with a goal of disaster recovery requires
multiple steps that must be performed in the correct order across multiple servers. Failed
processes lead to a system that does not function, which results to tearing down the
environment, and hours of lost work. The DR Agent consolidates many complex steps into a
few abstracted actions that reduce the manual effort or set of commands required to establish a
basic replication setup for disaster recovery.
Note: DR Agent supports only SAP Business Suite environments.
Replication in a Disaster Recovery Environment
In a typical replication scenario, the SAP application connects to and updates data on the
primary site. The replication software captures transactions from the primary site and
replicates them to the standby site. When integrated with SAP tooling in a planned or
unplanned failover scenario, SAP application connections are switched to the standby site.
The direction of replication is switched, and Replication Servers save the transactions
generated at the standby site until the primary database comes back online. When the primary
site returns to service, the saved transactions at the standby site are released and applied to the
primary, allowing the two sites to resynchronize.
If you are using DR Agent as a standalone tool (not integrated or combined with SAP tooling),
you must provide your own processes for switching the connectivity of the SAP applications
and other database clients to the active database instance. The disaster recovery configuration
created by the DR Agent supports only one active server at a time. Database activity may occur
at either the primary database, or the standby, but not both at the same time.
For initial setup and configuration, connect to the DR Agent on the primary site, and issue the
appropriate commands to define the environment and set up replication. Once you have set up
the environment, connect to the DR Agent on either site to monitor and administer the
replication environment. The DR Agent provides its own copies of the Sybase JDBC driver
and other libraries required for its execution. To avoid coexistence or migration issues, the DR
Agent does not share libraries with Adaptive Server or Replication Server installations. The
DR Agent uses JDBC connectivity for all outbound TCP/IP connections. Target servers
include Adaptive Server, Replication Server, and other DR Agent instances.
The DR Agent is a Sybase Control Center (SCC) plug-in that runs inside the SCC server
framework. Client applications connect to the DR Agent through its TDS interface (ODBC,
JDBC, or Open Client). The DR Agent uses JDBC to communicate with the servers on either
host, and to the other DR Agent.
Disaster Recovery Environment Architecture

A disaster recovery environment consists of two sites, the primary and the standby. Both sites
contain the Adaptive Server data server that supports the same single SAP Business Suite
installation. Each site contains a Replication Server and a DR Agent.
Replication is set up to support replication in both directions between the primary and standby
sites, although only one direction is available at any time. Three databases are replicated
between the primary and standby sites; the SAP ERP database named using the SAP SID, the
saptools database, and the Adaptive Server master database.
Adaptive Server High Availability Disaster Recovery System

A high availability disaster recovery (HADR) configuration consists of two or more servers,
one of which is designated as the primary (on which all transaction processing by user
applications occurs), and the others as standby servers, which act as warm standbys for the
primary server and contain copies of designated databases from the primary server.
An Adaptive Server HADR is integrated into the DR Agent setup, materialization, failover,
and teardown processes. Only privileged users can access the standby Adaptive Server,
application users are either rejected or automatically rerouted to the primary Adaptive Server.
In an HADR system, data is replicated from the primary server to the standby server. If the
primary server fails, a standby server is promoted to the role of primary server.
The user identifies the primary and standby Adaptive Server during the setup process. As the
last step in Enterprise Resource Planning (ERP) database materialization, DR Agent
configures the Adaptive Servers as a primary and a standby server. During failover, the DR
Agent deactivates the primary Adaptive Server, reverses the flow of replication, then promotes
the standby Adaptive Server to become the active primary server. Users can no longer connect
to the old primary Adaptive Server and are re-routed to the new primary Adaptive Server.
See the SAP Adaptive Server High Availability Disaster Recovery Users Guide for more
information.
Before You Begin
Before You Begin

Meet hardware and software requirements and perform all prerequisites before setting up your
disaster recovery environment.
SAP Prerequisites
Before you can set up a disaster recovery solution, you must meet the SAP Business Suite
environment hardware and software requirements.
Two host systems each system can comprise virtual machines, physical machines, or a
mix. Both hosts must be for the same operating system and hardware architecture,
although the exact version of the operating systems may vary, as well as the size of the
machines.
DR Agent refers to a site as a "logical host". One logical host is referred to as the "primary";
the other is the "standby". A site can host the Adaptive Server and the Replication Server
on the same machine, or on separate machines. It does not support using the same host for
both primary and standby hosts.
The SAP Business Suite for Adaptive Server must be installed with the Adaptive Server
database hosted by the primary site. The SAP Application Server (NetWeaver) is not
required; however, you may want to install on the same primary host or a separate host.
The SAP Business Suite for Adaptive Server must have a copy of the Adaptive Server
database on the standby site. The standby site must be a copy of the database instance of the
primary SAP system.
Execute the SAP installer creating only the database without the NetWeaver application
server. For example, you can use the SAPinst options for Global Host Preparation and
Database Instance installation on the standby site.
Standby System Administration

The standby site contains a self-contained instance of Adaptive Server and its related
databases.
The standby server requires the same levels of protection and scheduled maintenance as any
other instance. Specifically:
Periodic reorganizations and statistics generation, and other housekeeping.

Its own backup and recovery processes, which includes disk-based file backup and
recovery, as well as database-level dump creation and archiving.
Before You Begin

Note: You cannot use dump files from the primary site to recover the standby site. Once
replication begins, the physical attributes of the primary and standby databases are no longer
equivalent and they may not share the same dump and load files for recovery.
Technical Prerequisites and Limitations

Meet additional technical limitations and prerequisites before setting up the disaster recovery
environment.
The master and saptools databases are always replicated. You cannot exclude them from
replication.
The Adaptive Server name is based on the SAP_SID values and must be the same on both
the primary and standby sites.
The sapsa and sapsso logins and passwords must be identical on both hosts.
Note: Logins, users, and roles at the standby site must be a subset of those at the primary
site. When the login data from the primary Adaptive Server master database is
materialized to the standby, any unique logins at the standby site are lost.
The sa and sso role must have same permissions on the primary and standby Adaptive
Server for materializing the master database.
Note: The permissions for sa and sso users and roles are not copied from the primary to the
standby database during master database materialization. These users and roles are
excluded from materialization in order to ensure that any failure of the materialization
process does not result in an inaccessible standby database. The sa and sso users are not
corrupted at the standby. As the standby database may only have the "default" permissions
assigned to sa and sso users and roles, any customizations or additional permissions
granted to these users and roles at the primary database must be duplicated at the standby
database before materialization.
The SAP database name must be the same on both primary and standby sites.
The same hardware platform and operating system must be used for both sites. Machine
sizes and speeds may vary, as long as the standby site has sufficient resources to host the
SAP application activity and database sizes. The operating system version may vary, as
long as the version supports the SAP application.
A unique additional Adaptive Server maintenance user must be defined for the master,
SAP_SID, and saptools databases at both the primary and standby sites.
As a result of enabling replication, additional information is written to the Adaptive Server
transaction log for each database. This increase may be 40 50 percent greater than before.
Therefore, to ensure that sufficient log space is available to the SAP application, either
increase the transaction log space allocation, or schedule transaction log dumps more
frequently.
In an SAP environment with replication enabled, these ports are allocated based on the
Adaptive Server port specified when setting up replication:
Before You Begin
4901 Adaptive Server port

4902 Adaptive Server backup server
4903 Adaptive Server Job Scheduler
4904 Replication Server
4905 Replication Server System Database
4906 Replication Server System Database Replication Agent
4909 DR Agent
Note: You can change these default port assignments, before the replication environment
is created. However, you cannot change the total number of required ports.
See also
Changing the DR Agent Port on page 9
Sybase Replication Software Versions and Downloads

Minimum replication related software versions and downloads required for the disaster
recovery environment.
Software
Version
Adaptive Server Enterprise
HPIA 15.7.0/EBF 20654 SMP ESD#03 /P/ia64/HP-UX B.11.31

IBM AIX 15.7.0/EBF 20651 SMP ESD#03 /P/RS6000/AIX 6.1
Linux AMD 15.7.0/EBF 20655 SMP ESD#03 /P/x86_64/Enterprise Linux
Sun Sparc 15.7.0/EBF 20650 SMP ESD#03 /P/Sun_svr4/OS
5.10
Windows 64-bit 15.7.0/EBF 20653 SMP ESD#03 /P/X64/Windows Server
Before You Begin

Software
Version
Replication Server
DR Agent
HPIA 15.7.1/EBF 20680 ESD#2 Intel Itanium/HP-UX B.11.31

IBM AIX 15.7.1/EBF 20684 ESD#2 RS6000/AIX 5.3
IBM pSeries Linux 15.7.1/EBF 20685 ESD#2 Linux IBM pSeries/Linux 2.6.18-128.el5 ppc64
Linux AMD 15.7.1/EBF 20683 ESD#2 Linux AMD64/Linux
2.6.18-128.el5 x86_64
Sun 15.7.1/EBF 20678 ESD#2 Sun_svr4/OS 5.8
Sun Sparc 15.7.1/EBF 20679 ESD#2 Solaris AMD64/Solaris
5.10
Windows 32-bit 15.7.1/EBF 20681 ESD#2 NT (IX86)/Windows
2008 R2
Windows 64-bit 15.7.1/EBF 20682 ESD#2 X64/Windows 2008
R2/1
Sybase Control Center 3.2.6 (build 4729)
DR Agent 15.7.1.100.2494/A/JDK 1.6/Thu Apr 25 14:28:23
MDT 2013
Sybase Replication Software Installation

Replication software installation involves preinstallation tasks, changing the DR Agent port,
validating Adaptive Server configuration, and installing the Replication Server.
Preinstallation Tasks
The preinstallation tasks to be performed before installing the Sybase replication software.
1. Verify that the prerequisites have been completed.
2. Verify that the Adaptive Server database has been properly configured.
3. Add additional Adaptive Server users required to support replication.
Note: The SAP SID is D01 in the examples. This is the name of the Adaptive Server and the
ERP database. If your SID differs, replace D01 with your SID.
Changing the DR Agent Port

To change the DR Agent port, modify the agent-plugin.xml file and restart the DR
Agent. By default, the DR Agent listens on port 8899 and assumes all other DR Agents are
listening on the same port that is configured in the agent-plugin.xml.
The agent-plugin.xml file is located in the /sybase/<SAP_SID>_REP/
SCC-3_2/plugins/DR directory. The agent-plugin.xml represents start-up
information needed by the DR Agent and Sybase Control Center (SCC). It determines the
TCP/IP port to be used by the local DR Agent.
1. Shutdown the DR Agent, if it is running
2. Modify the line in the agent-plugin.xml that holds the port number. For example, to
change the default port 8899 to 7777, enter:
<set-property property="com.sybase.ua.plugins.dr.tdsPort"
value="7777" />
3. Start the DR Agent.
When establishing connectivity with other DR Agent processes, the commands
sap_set_host and sap_set are used. The DR Agent process will run on the same hostname
that the Replication Server is specified to run on. The port number for the remote DR
Agent defaults to the port this DR Agent started with.
For example:

a) On the physical host computer1, modify agent-plugin.xml to set the default port
of DR Agent to 7777.
b) Start or restart DR Agent on computer1.
c) Using isql or equivalent client, execute the command:
sap_set_host host2, computer2, 4901, computer3, 8000
This command creates a new logical host named host2 with the Adaptive Server at
host computer2 with port 4901. The Replication Server is on host computer3 with port
8000. The DR Agent for the logical host host2 is on computer3 (the Replication
Server host) and port 7777 is the port DR Agent started with on computer1.
4. To override the default port for communicating with the remote DR Agent port on host2',
the sap_set command is used.
For example:
a) Connect to DR Agent on computer1 using isql or equivalent client.
b) Execute:
sap_set newHost, dr_plugin_port, 8000
This command indicates to the DR Agent on computer1 that to reach the DR Agent for
the logical host host2, to use the port 8000.
Validating Adaptive Server Configuration

Before installing the replication software, verify that the Adaptive Servers are properly
configured.
1. Verify that the Adaptive Server configuration for the databases to be dumped is set to
disable 'trunc log on chkpt' to execute the Adaptive Server dump transaction command. To
do this, connect to the Adaptive Server at both the primary and the standby sites and
execute these commands to verify this property has been set for both the SAP SID database
and saptools:
isql -Usapsa -PSybase123 -SD01
use master
go
sp_dboption D01, 'trunc log on chkpt', false
go
Database option 'trunc log on chkpt' turned OFF for database
'D01'.
Running CHECKPOINT on database 'D01' for option 'trunc log on
chkpt' to take
effect.
(return status = 0)
sp_dboption saptools, 'trunc log on chkpt', false
go
Database option 'trunc log on chkpt' turned OFF for database
'saptools'.
10

Running CHECKPOINT on database 'saptools' for option 'trunc log on
chkpt' to take effect.
(return status = 0)
2. An SAP installation requires password encryption. If necessary, execute this command at

both the primary and standby Adaptive Server to enable FIPS storage of passwords:
isql -Usapsa PSybase123 -SD01
sp_configure FIPS login password encryption, 1
go
You must restart Adaptive Server for this change to take effect. Use the SAP commands
stopdb and startdb to start and stop the Adaptive Server.
3. An SAP installation also requires all Adaptive Server connections to send encrypted
passwords. If necessary, execute this command at both the primary and standby Adaptive
Server:
isql -Usapsso PSybase123 -SD01
sp_configure 'net password encryption reqd', 1
go
Adaptive Server refuses all connection requests that do not encrypt passwords after setting
net password encryption reqd. The isql option that can connect to an Adaptive Server,
which requires password encryptions is -X. For example:
isql -Usapsa -PSybase -SD01 X
Add Additional Adaptive Server Users

For a disaster recovery environment, you must set up a maintenance user and a DR Agent
administration user to support replication.
Maintenance User
Replication requires a unique Adaptive Server login name that is used explicitly and
exclusively when applying activity to the standby database. This unique user is referred to as
the maintenance user, for its role in maintaining a replication system.
Create the maintenance user logins in the Adaptive Server on both the primary and standby
sites. You cannot use an existing Adaptive Server or SAP user. Replication applies operations
to the standby database using this unique maintenance user login. To prevent those operations
from being replicated back to the primary, replication ignores all activity performed by this
maintenance user. Thus, using this user for any activity other than replication, the activity by
the user is ignored by replication may create a loss or inaccuracy between the primary and
standby databases.
11
Creating the Maintenance User

Create a maintenance user that must be identical on both the primary and the replicate
databases.
1. Grant the maintenance login replication_role so it can replicate the truncate table
command.
2. Alias the maintenance user to the dbo on the master, SAP_SID, and saptools databases so
that this user has the authority to update tables that use identity columns.
3. Grant the maintenance login sa_role so it can replicate insert, update, and delete
operations against all tables.
4. Grant the maintenance user set session authorization permissions.
This allows the maintenance user to become another user when applying DDL to the
replicate database. The permission must be granted to either a user (not the login) or to a
role. Since the current solution is to alias the maintenance login to dbo, there is not actually
a user. Therefore the set session authorization must be assigned to a role.
Example 1: Create the <SAP_SID>_maint user on both hosts. D01 is used in these examples:
isql -Usapsso -PSybase123 -SD01
use master
go
create login D01_maint with password Sybase123
go
sp_role "grant", replication_role, D01_maint
go
Authorization updated.
(return status = 0)
Example 2: Grant sa_role to D01_maint, so it can send DML in database D01 on all tables.You
must log in as an sa user to grant sa_role.
sp_role "grant", sa_role, D01_maint
go
(return status = 0)
Example 3: Create a new role named sap_maint_user_role and grant it set session
authorization permissions. Grant the sap_maint_user_role to the maintenance user.
create role sap_maint_user_role
go
grant set session authorization to sap_maint_user_role
go
sp_role "grant", sap_maint_user_role, D01_maint
go
12
alter login D01_maint add auto activated roles sap_maint_user_role

go
(return status = 0)
Example 4: Alias the D01_maint to DBO in the master, SAP_SID, and saptools databases.
isql -Usapsa -PSybase123 -S D01
use master
go
sp_addalias D01_maint, dbo
go
Alias user added.
(return status = 0)
use D01
go
go
Alias user added.
(return status = 0)
use saptools
go
go
Alias user added.
(return status = 0)
Execute all of these commands at both the primary and standby sites.
DR Agent Administration User

A new DR Agent administrator login in both the primary and standby Adaptive Servers must
be created. This Adaptive Server login, which connects to the DR Agent, must have sa, sso,
and replication roles.
sa and sso allow the DR Agent to materialize the master database. sa updates the tables and sso
configures the Adaptive Server to allow system table updates. No permission from the
replication role is used; it is required only to distinguish from other administrative users.
Creating DR Agent Administration Login

Create the DR Agent administrator.
Prerequisites
Log in as a user with sso role.
13

Task
1. Create the DR_admin user on both hosts. For example:
use master
go
create login DR_admin with password Sybase123
go
sp_role "grant", sso_role, DR_admin
go
sp_role "grant", replication_role, DR_admin
go
(return status = 0)
2. Log in as an sa user, and grant sa_role to DR_admin so it can assist with materialization
tasks. For example:
sp_role "grant", sa_role, DR_admin
go
(return status = 0)
3. Grant sybase_ts_role to DR_admin so it can perform analysis on the Adaptive Server

transaction log. For example:
sp_role "grant", sybase_ts_role, DR_admin
go
(return status = 0)
Installing Replication Server

Install Replication Server on both the primary and standby sites. The Sybase Control Center
and DR Agent plug-in are included in the Replication Server installer.
1. Copy the compressed image for the Replication Server software to a location reachable
from your host. The installer must execute on the local host; remote execution is not
supported.
2. Extract the compressed image to a temporary location and start the Sybase installer.
./setup.bin -DDR=true
3. Provide these responses:

a) For an SAP installation, install the Replication Server in /sybase/
<SAP_SID>_REP.
For example, /sybase/D01_REP.
14

Note: Adaptive Server is installed at /sybase/<SAP_SID>. Replication Server is
installed at /sybase/<SAP_SID>_REP. A unique directory for the Replication
software is required to enable independent software updates of the Adaptive Server and
Replication Server software products.
b) Do not start the sample Replication Server if prompted. The DR Agent creates, starts,
and configures the servers.
c) Do not install a license file.
d) Do not request e-mail alerts.
Installing Replication Server on Windows

To prevent the Replication Server installer from creating Windows registry entries, execute
the Replication Server installer using a response file.
Replication Server installer must not replace or overwrite the Windows registry entries created
by the Adaptive Server installation.
1. Use a response file containing these entries:
DR=TRUE
DO_NOT_SETENV_AND_REGISTRY=TRUE
DO_NOT_CREATE_SHORTCUT=true
REGISTER_UNINSTALLER_WINDOWS=false
2. Start the installer pointing to response file; for example:

.\setup.exe -f C:\response.txt
where c:\response.txt is the response file.
15
16
Running the DR Agent

The DR Agent runs inside Sybase Control Center (SCC) so start it using the same commands
as for any SCC instance.
Starting and Stopping DR Agent in UNIX

Start the DR Agent manually, which is useful for testing and troubleshooting, or set up a
service to start automatically and to restart in case of failure.
Prerequisites
1. Log in to the host machine using the same operating system user that was used to install the
Replication Server.
2. Run the /sybase/<SAP_SID>_REP/SYBASE script to set the necessary environment
variables.
a. Change to the Sybase directory (the parent of the DR Agent installation directory).
b. Execute one of the following to set environment variables:
Bourne shell:
. SYBASE.sh
C shell:
source SYBASE.csh
Task
If you start the DR Agent manually, you must issue a command every time you start or shut
down. If you run as a service (which is recommended), you can configure the service to start
and restart automatically. These are the options:
Use the scc.sh script to start the DR Agent manually. You can either:
Run scc.sh in the foreground to get access to the DR Agent console, which you can use
to shut down and to display information about services, ports, system properties, and
environment variables.
Run scc.sh in the background to suppress the console.
You can use scc.sh to run the DR Agent at a nondefault logging level for troubleshooting.
When you start manually with scc.sh, you cannot take advantage of the automatic start
and restart features available to the services.
Use the sccd script to configure a service that starts DR Agent automatically.
Here are the steps for each starting and stopping option:
17
Run DR Agent in the foreground.

Running in the foreground is a method of manually starting; you must issue commands to
stop and restart DR Agent.
a) To start DR Agent and go ot the console when the start-up sequence is finished, enter:
$SYBASE/SCC-3_2/bin/scc.sh
Run DR Agent in the background.
You can use nohup, &, and > to run DR Agent in the background, redirect output and
system errors to a file, and suppress the DR Agent console. Running in the background is a
method of manually starting; you must issue commands to stop and restart DR Agent.
a) Execute a command similar to the sample below that matches your shell. Both sample
commands direct output to the file scc-console.out. If the output file already
exists, you might need to use additional shell operators to append to or truncate the
file.
Bourne shell (sh) or Bash
nohup ./scc.sh 2>&1 > scc-console.out &
C shell
nohup ./scc.sh >& scc-console.out &
Shut down DR Agent.

a) To shut down from the scc-console> prompt, enter:
shutdown
Warning! Do not enter shutdown at a UNIX prompt, as doing so shuts down the
operating system.
To shut down from the UNIX command line, enter:
$SYBASE/SCC-3_2/bin/scc.sh stop
Configure DR Agent to run as a service.
A UNIX service is a daemon process that starts automatically after the machine is started
and runs in the background. UNIX installations of DR Agent include a shell script, sccd,
which you can use to configure the DR Agent service. (Some UNIX platforms supply tools
that make service configuration easier; Linux chkconfig is an example.)
Note: Sybase recommends that, if you are unfamiliar with setting up services in UNIX,
you delegate this task to a system administrator or consult the system administration
documentation for your UNIX platform.
a) Copy $SYBASE/SCC-3_2/bin/sccd into this directory:
18
AIX: /etc/rc.d/init.d
HP-UX: /sbin/init.d
All other platforms: /etc/init.d

b) Open sccd and change the line that sets the SYBASE variable to the location of your
Sybase installation (that is, the parent of SCC-3_2 , the DR Agent installation
directory). By default, this directory is called Sybase.
c) In Linux, configure the service to run in levels 2, 3, 4, and 5:
/usr/sbin/chkconfig --add sccd
/usr/sbin/chkconfig --level 2345 sccd
You can test the sccd script with /usr/sbin/service sccd status. (The
service command accepts these options: start | stop | status | restart.)
d) On non-Linux platforms, locate this directory:
AIX: /etc/rc.d/rc<X>.d
HP-UX: /sbin/rc<X>.d
Solaris: /etc/rc<X>.d
where <X> is the run level (for example, 3). Make two soft links in the directory for
your platform and set the links to point to:
AIX:
/etc/rc.d/init.d/sccd: S90sccd and
/etc/rc.d/init.d/sccd: K10sccd
HP-UX:
/sbin/init.d/sccd: S90sccd and
/sbin/init.d/sccd: K10sccd
Solaris:
/etc/init.d/sccd: S90sccd and
/etc/init.d/sccd: K10sccd
The S90sccd link starts the service and the K10sccd link stops the service. The
two-digit numbers in the links indicate the start and stop priorities of the service.
e) Use the S90sccd and K10sccd links to test starting and stopping the service. The
links are called automatically when the machine is started or shut down.
See also
Starting and Stopping DR Agent in Windows on page 20
19
Starting and Stopping DR Agent in Windows

Start DR Agent manually, which is useful for testing and troubleshooting, or set the service to
start automatically and to restart in case of failure.
Prerequisites
1. Log in to the host using the same operating system user that was used to install the DR
Agent and Replication Server.
2. Execute the SYBASE.bat file in the Replication Server installation directory to set the
required environment variables.
Task
If you run DR Agent manually, you must issue a command every time you start or shut down.
If you run as a service, you can configure the service to start and restart automatically.
Start or stop DR Agent Windows service from the command line

a) Add the user to the administrator group and grant the user "logon as service" privilege.
The Windows user who will start the DR Agent service must have the correct
permissions.
b) Log in to Windows with the new user.
c) Create the Windows service for the DR Agent. The utility creates a service named
SybaseDRAgent_<SID>.
C:> cd %SYBASE%\SCC-3_2\plugins\DR\bin\amd64 (or .. bin\win32
on 32bit Windows)
C:> drservice.exe install <SID>
Sybase DR Agent - <SID> installed.
d) Start DR Agent as a Windows service:

C:> sc start SybaseDRAgent_<SID>
SERVICE_NAME: SybaseDRAgent_<SID>
TYPE
: 10 WIN32_OWN_PROCESS
STATE
: 2 START_PENDING
(NOT_STOPPABLE, NOT_PAUSABLE,
IGNORES_SHUTDOWN)
WIN32_EXIT_CODE
: 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT
: 0x1
WAIT_HINT
: 0xea60
PID
: 8036
FLAGS
:
e) Configure the service to use the Windows user when starting DR Agent:
C:> sc config SybaseDRAgent_<SID> obj= <WindowsUser> password=
<Password>
f) Stop DR Agent Windows Service:
20

C:> sc stop SybaseDRAgent_<SID>
SERVICE_NAME: SybaseDRAgent_<SID>
TYPE
: 10 WIN32_OWN_PROCESS
STATE
: 3 STOP_PENDING
(STOPPABLE, NOT_PAUSABLE,
IGNORES_SHUTDOWN)
WIN32_EXIT_CODE
: 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT
: 0x1
WAIT_HINT
: 0xea60
g) Drop the DR Agent Windows service:

C:> drservice.exe remove <SID>
Sybase DR Agent - D01 removed.
Start or stop from the Windows Control Panel; configure automatic start and restart:
a) Open the Windows Control Panel.
b) Select Administrative Tools > Services.
c) Locate SybaseDRAgent_<SID> in the Services list. If the service is running, the
Status column displays Started.
d) To start or stop the service, right-click the entry in the Services list and choose Start or
Stop.
e) To configure automatic starting, double-click the service.
f) To set the service to automatically start when the machine starts, change the Startup
type to Automatic.
g) To restart the service in case of failure, choose the Recovery tab and change the First,
Second, and Subsequent failures to Restart Service.
h) Click Apply to save the modifications and close the dialog.
Verifying the DR Agent

SCC has a console mode, which allows access to additional SCC informational commands,
including a command to identify which plug-ins are loaded. You can use the console mode to
see the DR Agent process running.
1. Start SCC in the foreground:
/sybase/<SID>_REP/SCC-3_2/bin/scc.sh
The SCC console is disabled when SCC is executed in the background. If SCC is already
running in the background, you must stop SCC and restart it in the foreground. Once the
DR Agent is started, the operating system session is presented with a prompt for additional
command execution.
2. Check the status of the DR Agent by running the status command at the SCC console:
scc-console> status
21

The output from the command displays a list of services and plug-ins that are loaded into
the SCC framework. Review the list to make sure that the DR Agent is loaded successfully.
Viewing the Log Files

View errors, information, and trace messages in the SCC and DR Agent log files.
The SCC log file is located in the log directory of the DR Agent installation, for example,
in /sybase/<SID>_REP/SCC-3_2/logs/agent.log. The DR Agent plug-in
writes to its own log file, which is located in the Replication Server directory structure in the
SCC plugins directory, for example, /sybase/<SID>_REP/SCC-3_2/plugins/
DR/log/dr.log. The DR Agent rotates the log file each day. Logs from prior days are in
the same directory, named dr.log.yyyy-MM-dd.
You can customize the level of logging information by changing the log level in the
$SYBASE/SCC-3_2/plugins/DR/agent-plugin.xml, in this line:
<logger name="com.sybase.ua.plugins.dr" level="TRACE">
Valid values include ERROR, WARN, INFO, DEBUG, or TRACE. The default log level for
the DR Agent is TRACE, which includes INFO, WARN (warning), ERROR, and DEBUG
messages. You must restart DR Agent for a change in log level to take effect. .
Connecting to DR Agent
Connect to the DR Agent plug-in using the isql utility.
Although each host includes a DR Agent, you need to enter commands at only one of them.
The DR Agents connect to each other to share configuration information or run any activity
that requires local access to the host.
To set up and monitor replication, log in to the DR Agent on the primary host. Use the DR
Agent host and port and the DR Agent administrators security credentials to establish a
connection to the DR Agent. The default port for the DR Agent is port 8899. For example:
isql UDR_admin PSybase123 Shost1:8899
22
Setting Up the Disaster Recovery Solution

After setting up SAP and installing Sybase replication software components, use the DR
Agent to set up the environment for SAP disaster recovery support.
During the DR Agent setup process:
Replication servers are installed and configured on both the primary and standby sites.
The master, SAP SID, and saptools databases at both sites are configured to support
replication.
The primary and standby Adaptive Servers are configured to support high availability
disaster recovery (HADR).
The primary databases start sending data to the Replication Server on the same host;
however, these initial updates are discarded by the local Replication Server until
materialization takes place.
The data for each database must be materialized (copied) from the primary site to the standby
site to create an initial synchronization point between the two copies of a database.
Subsequently, replication of the database updates ensures that the databases remain
synchronized.
DR Agent Security
The DR Agent does not store its own security credentials, but enforces authentication by passthrough authentication to the primary or standby Adaptive Server, or primary or standby
Replication Server.
Users must log in to the DR Agent using the host Adaptive Server credentials. The DR_admin
user is designed to be the Adaptive Server user whose credentials are validated by Adaptive
Server when logging in to the DR Agent. To enforce authentication, the DR Agent imposes
these limitations:
1. At least one Adaptive Server host (primary or standby) must be configured in the DR
Agent before pass-through authentication can be performed. Any command that is
executed before an initial sap_set_host command takes place is rejected.
2. Once you run sap_set_host, any DR Agent command execution is first authenticated
against the logical host that has been set. Any attempt to connect to the DR Agent without
authenticated credentials is rejected.
3. Once authentication has occurred, the DR Agent allows only that single administrative
user to issue commands against the DR Agent. You cannot log in to the DR Agent with any
other user name.
23

4. All subsequent DR Agent commands are authenticated prior to execution, except
sap_help.
5. The DR Agent administrator is also used to define the Replication Server administrative
user. If you use the DR_admin user to administer the DR Agent, the DR Agent creates the
Replication Servers, configured to also accept the DR_admin user and credentials.
The Replication Server credentials match the Adaptive Server credentials when the
Replication Server is created. Any change to the Adaptive Server credentials for the DR Agent
administrative user (DR_admin) must also be changed in the Replication Servers. The DR
Agent assumes the Adaptive Server and Replication Server credentials for the DR Agent
administrative user are always the same. You can change the existing password for the DR
Admin user in both the Adaptive Servers and Replication Servers by using the DR Agent
command sap_set_password.
See also
Other DR Agent Commands on page 51
DR Agent Error Handling

At times a DR Agent command may fail because of various environment conditions.
For example, the setup command may fail if the host computer does not have enough disk
space to create a replication device. The DR Agent is implemented so that when an error
occurs, the user can make any necessary changes, then rerun the command. The DR Agent
starts executing where the failure occurred.
Errors, information, and trace messages are written to the DR Agent log file, which is located
under the Replication Server directory structure, for example, /sybase/<SID>_REP/
SCC-3_2/plugins/DR/log/dr.log.
Defining a Logical Host

The logical host name is provided by the user when setting up the Disaster Recovery
environment. A logical host name identifies a logical site name that contains an Adaptive
Server and Replication Server pair.
The name can be of any length, which contains letters, numbers, and hyphens.
The logical host name is used internally for naming Replication Server objects. To meet the
Replication Server rules for naming identifiers, a unique ten character server name is derived
from the logical host name. The derived server name must start with a letter, be less than 10
characters long, and must be unique in the disaster recovery environment. The internal name is
used when defining:
24
Instance directory
Routes
Connections
Subscriptions
Defining the Primary Host

Define the primary logical host so the DR Agent can connect to the Adaptive Server and
validate its credentials.
sap_set_host logical_host_name, host1, 4901
go
The logical host name is used to reference the site.
Defining the Standby Host

Define the standby logical host.
sap_set_host logical_host_name, host2, 4901
go
The logical host name is used to reference the site.
Defining the Replication Server on a Separate Computer

Use the sap_set_host command to define a separate host and port for the Replication Server.
sap_set_host logical_host_name, ase_host_name, ase_port_num,
rs_host_name, rs_port_num
go
This can be used when defining either the primary or the standby site.
Defining the DR Agent Server Port on a Separate Computer

Use the sap_set_host command to override the default DR Agent port on a separate
computer.
Note: This requires specifying the RS host and RS port parameters.
sap_set_host logical_host_name, ase_host_name, ase_port_num,
rs_host_name, rs_port_num, dr_agent_port_num
go
This can be used when defining either the primary or the standby site.
25
Dropping a Host
Drop a host that was previously defined using the sap_set_host command.
sap_drop_host logical_host_name
go
Setting Databases Names

Set a list of database names for setting up a new replication environment. The database list is
verified, persisted, and used to validate any sap commands specifying a database name. If a
commands database name does not exist in the database list, the command is rejected.
If database names are not set, the default database names master, <SID>, and, saptools are
used when setting up a new replication environment. When a replication environment is
already setup, its database list is permanent. Tearing down a replication environment makes
the database list changeable.
Execute:
sap_set_databases database_name [, additional_database_name ]
go
where:
database_name is the name of the database to replicate.
additional_database_name is a comma-separated list of additional databases to
replicate.
Defining the SAP SID

Define the SAP_SID that DR Agent uses to identify servers and SAP databases, and when
creating connections, replication definitions, and subscriptions within the Replication
Servers.
To define the SID in the DR Agent, enter:
1> sap_set sap_sid, D01
2> go
Identifying the Maintenance User

In the replicate database, all replicated transactions are applied by the maintenance user,
which must already been created as defined in the prerequisites information.
To define the maintenance user name and password in the DR Agent, enter:
1> sap_set maintenance_user, D01_maint, Sybase123
2> go
26
Specifying the Database Dump Location

(Optional) Change the database dump location.
By default, the dump file location is: $SYBASE/<SID>_REP. The DR Agent uses the dump
location, for storing dump files, when materializing the SAP database using database dump
and load, or transaction dump and load.
To change the dump file location, enter:
sap_set logical_host_name, db_dump_dir, dump_directory_path
go
See also
Materializing the SAP Database on page 39
Specifying the Replication Server Device Location

(Optional) Change the Replication Server device location.
By default, the device location is: $SYBASE/<SID>_REP. Replication Server uses this
device location to store transactions in stable devices.
To change the device location, enter:
sap_set logical_host_name, device_buffer_dir, device_directory_path
go
See also
Adding Replication Server Device Space on page 47
Reviewing the SAP Environment Properties

Review all remaining properties used by the DR Agent, which are defined with default values
that are based on the logical hosts defined.
Execute the sap_set command with no arguments to display a list of all the DR Agent
properties and their values. Use the sap_set command to change any of the listed property
values.
sap_set logical_host_name, property_name, new_value
go
Calculating the Replication Disk Buffer Requirements

Calculate the increase in Replication Disk Buffer Requirements for the Replication Server to
hold the delayed content, if the delay replication feature is configured or the
27

delay_time_minutesis set in sap_set variable. To calculate log volume, it is recommended
that you examine your transaction log dumps. Based on the number and size of transactions
log dumps over time, you can calculate an approximation of volume.
For example, if x transaction log dump files are created over the last y hours, and the total space
on disk for those x files is z MB, the approximate log generation per hour is z/y MB. Make this
calculation during your busiest time. If the volume is greatest at the end of the month, or during
nightly batch processing, use the transaction logs generated during these busy times to
perform the initial calculation.
Generally, the partition space required by the Replication Server is larger than the actual log
volume size. Replication Server contains the metadata (table and column names) for each row,
in addition to the raw row data from the log. While the approximate transaction log volume is
helpful, add in additional buffer space to accommodate spikes in volume not anticipated by the
initial transaction dump based calculation. The recommended device buffer allocation for
Replication Server is:
z/y MB (approximate hourly log generation) * H (hours of delay
desired) * B (buffer - a value of 2-10)
The buffer range of 2 10 represents a low disk usage (versus higher risk), to high disk usage
(versus lower risk), decision. The risk is a failure to allocate enough space to hold all delayed
data. Once replication queues are full, the primary database cannot truncate its transaction log
as frequently, which may cause the database system to run out of transaction log space, and
stop the primary system. An allocation that is too high reduces the risk, but allocates disk
resources that may go unused.
In all cases, any choice is an approximation. Monitor the allocation over time and add
additional space allocation if the usage percentage is consistently above 80%.
Replication Disk Buffer Size

The replication processes buffer the data that is sent between the primary and standby logical
hosts. This buffering is maintained on disk file systems, and allows replication to quickly
accept data from the primary server, even during times of high volume or standby site
unavailability.
The data in the buffers persists when Replication Servers are restarted, guaranteeing delivery
of all data that has been received. The default allocation during replication setup is 1GB per
site, located in the Replication Server instance directory. If the size or location of the buffer is
inadequate, you can change both the size and location using these DR Agent properties:
28
primary, device_buffer identifies the directory location for the primary server.
primary, device_buffer_size identifies the size (in megabytes) of the disk allocation.
standby, device_buffer identifies the directory location for the standby server .
standby, device_buffer_size identifies the size (in megabytes) of the disk allocation.
Adjusting the Default Replication Disk Buffer Size

Adjust DR Agent disk buffer properties before creating the replication environment. Once you
have defined the environment, adjusting the properties has no effect.
To view and adjust the disk buffer size properties, enter:
sap_set property_name, desired_value
go
For example, to change the allocation size to 5GB on the primary host, enter:
sap_set primary, device_buffer_size, 5000
go
Note: Each Replication Server is created with exactly one partition of the size specific by
device_buffer_size and at the location of directory device_buffer.
See also
Adding Replication Server Device Space on page 47
Replication Server Properties Tuning

The file RS.properties contains replication property settings that are applied when you
create a new Replication Server.
The file is read during sap_setup_replication execution. The configure replication server
command is executed for each of the properties. See the Replication Server Reference
Manual.
Note: Any changes to RS_DB.properties files are applied when sap_setup_replication
is run and the Replication Server is created. The values in this file are read only by
sap_setup_replication. Once you have set up replication, changing the contents of
RS_DB.properties files does not affect your existing environment. Additional changes
can be made by logging into to the Replication Server and configuring it directly. See
Replication Server Reference Manual for more information on configuring Replication
Server connections.
Replication Server Database Properties Tuning

The Replication Server database properties can be tuned per database; each database has a
separate configuration file.
The files are located in $SYBASE/SCC-3_2/plugins/DR/DR:
RS_DB.properties holds settings for the SAP_SID database.
29
RS_DB_master.properties holds settings for the master database.

RS_DB_saptools.properties holds settings for the saptools database.
The file contains database connection property settings that are applied when a new
Replication Server is created using sap_setup_replication. The files are read during
sap_setup_replication execution. alter connection is the specific Replication Server
command that is run for each of these properties.
Note: Any changes to RS_DB.properties files are applied when sap_setup_replication
is run and the Replication Server is created. The values in this file are read only by
sap_setup_replication. Once you have set up replication, changing the contents of
RS_DB.properties files does not affect your existing environment. Additional changes
can be made by logging into to the Replication Server and configuring it directly. See
Replication Server Reference Manual for more information on configuring Replication
Server connections.
Validating the Environment Before Running Setup

(Optional) Test operating system permissions, database user roles and privileges, and host
network port availability.
Before running the sap_setup_replication command, review the output from:
sap_pre_setup_check, env_type, primary_logical_host_name,
standby_logical_host_name
go
where:
env_type is the type of environment the pre-setup check process validates. DR Agent
supports the disaster recovery "dr" option, which configures the environment using the
Adaptive Server HADR.
primary_logical_host_name is the name of the logical host that identifies the primary
site.
standby_logical_host_name is the name of the logical host that identifies the standby
site.
Before executing the replication setup command, correct any errors returned by
sap_pre_setup_check. sap_setup_replication executes the same set of tests as part of the
setup process.
Marking the Database for Replication

(Optional) Mark the database for replication before you start the setup process.
The command to mark an Adaptive Server database for replication can take a long time to
execute, depending on the size of the database. For example, it may take an hour or more to
mark the main SAP database for replication.
30

Marking the databases for replication separately allows you to perform the task at your
convenience, and without adding delay to the Replication Server setup and configuration
process.
To mark a database separately from the setup command, enter:
1> sap_mark_for_replication primary, D01
2> go
You must execute this command separately for each database you want to mark for replication,
at both the primary and standby sites.
If you do not separately mark the databases for replication, as described here,
sap_setup_replication automatically executes the same marking command for all databases.
sap_setup_replication is available solely as a timing convenience for updating the SAP
database.
Running Setup
Create the disaster recovery replication environment.
Prerequisites
Verify that all required properties have been set.
Task
Execute:
sap_setup_replication, env_type, primary_logical_host_name,
standby_logical_host_name
go
where:
env_type is the type of environment the pre-setup check process validates. DR Agent
supports the disaster recovery "dr" option, which configures the environment using the
Adaptive Server HADR.
primary_logical_host_name is the name of the logical host that identifies the primary
site.
standby_logical_host_name is the name of the logical host that identifies the standby
site.
This command is executed asynchronously (in the background) and may take 30 or more
minutes to complete, depending whether you have already executed
sap_mark_for_replication, which significantly reduces the time for sap_setup_replication
execution. The order of the logical host names dictates the direction of replication (from
primary to standby). The setup command returns immediately, indicating the setup task has
been successfully started and is running asynchronously.
31
Monitoring the Setup Progress

Monitor the status of the primary setup tasks, including the status of child tasks running
underneath the main task.
Execute:
sap_status
go
If the return from the sap_status command is "running", the background task is still
executing. The remaining results show the current state of the task and all child tasks. You can
reexecute the sap_status command periodically to monitor the task as you wait for its
completion.
A return status of "complete" indicates that, the background task has finished:
One Replication Server instance for each logical host is installedone server on each
host. A route is created between the two servers.
The Replication Server administrative user is the same one used to connect to the DR
Agent.
All three databasesSAP_SID, master, and saptoolsare defined to the Replication
Server.
All three databases are sending data from the primary database to the primary Replication
Server. Replication Server discards these updates; no data is applied to the standby
databases.
Both Replication Servers have connections defined for all three "local" databases.
Both Replication Servers are each using their own embedded RSSD.
Routes exist (both directions).
Database-level replication definitions exist for all databases (both directions).
Replication Agents at the primary site are up and running. Replication Agents at the
standby site are disabled, as is the secondary truncation point. Log transfer is disabled at
the standby Replication Server connection, so that no standby Replication Agent can
connect.
Subscriptions from standby to primary do not yet existthey are created as part of
materialization. Subscriptions do exist from primary to standby, in preparation for future
failover.
The Replication Server administrative user is the same one used to connect to the DR
Agent.
RSSD primary user is configured using the same password as the DR_admin.
Note: Because of a limitation in SQL Anywhere, the RSSD primary users password will
be truncated to 29 characters.
If the sap_status command returns an error, the background task fails. Review the remaining
task information to obtain an error description. Correct the error condition and rerun
32

sap_setup_replication. All steps that executed successfully up to the error point are bypassed
if they were successful. Use sap_status to monitor the task until it successfully completes.
If the information from the sap_status command is insufficient to fully understand or

diagnose the error, review the DR Agent log file for additional information. All steps executed
by the setup task are written to this log file.
Cancelling the Setup Process

You can cancel any asynchronous or background command, if necessary.
1. Execute:
sap_cancel
go
sap_setup_replication stops at its next logical point.
2. (Optional) Execute the sap_teardown command to remove the results, or reexecute

sap_setup_replication.
Note: A typical reason for cancelling the setup command is to change DR Agent properties.
To ensure that property changes take effect, first execute sap_teardown to remove any items
based on the earlier property settings.
Starting the Replication Server as a Windows Service

To utilize the Windows services, you must define a Windows user that has the correct
permissions to start the Replication Server. Create a new user then add the user to the
administrator group and grant the user the "logon as service" privilege.
During setup replication, the DR Agent creates a Windows service for the Replication Server,
but will not automatically start the Replication Server as a service.
The Windows login that is used to start the Replication Server service is defined in the DR
Agent by executing the sap_set_replication_service API. The optional restart
parameter can be used to restart the Replication Server as a Windows service.
To restart the Replication Server as a Windows service, execute:
sap_set_replication_service primary_logical_host_name,
windows_user_name, password, restart
go
33
34
Database Materialization
The materialization step of the setup process performs the initial copy of data from one site to
the other.
Once completed, the replication software maintains the accuracy of the target site by
continuously applying changes that occur after materialization. The procedure for
materialization depends on the type and size of database being materialized.
Before materializing the master database, verify that the sa and sso role have the same
permissions on the primary and standby Adaptive Server.
Note: The permissions for sa and sso users and roles are not copied from the primary to the
standby database during master database materialization. These users and roles are excluded
from materialization in order to ensure that any failure of the materialization process does not
result in an inaccessible standby database. The sa and sso users are not corrupted at the
standby. As the standby database may only have the "default" permissions assigned to sa and
sso users and roles, any customizations or additional permissions granted to these users and
roles at the primary database must be duplicated at the standby database before
materialization.
Dump Configurations
When materializing databases that are configured to use a dump configuration, you must use
sap_materialize start and sap_materialize finish commands.
Note: Dump configurations are not supported with DR Agent automatic materialization.
Dump configurations define options to create a database dump. Backup Server then uses the
configuration to perform a database dump. For more information on dump configurations, see
Adaptive Server Enterprise 15.7 ESD #2 > Reference Manual: Procedures > System
Procedures>sp_config_dump command.
Prior to Materialization
Before running any materialization task, verify that the database to be materialized is properly
set up for replication. Execute sap_status path to check the state of all the databases. The
current status for each database must be "defined". An "active" status indicates that the
database is already being replicated and must not be materialized.
If the status is "error", you must identify and resolve the error before attempting any additional
system changes. Review the Replication Server error logs to determine the reason for the error.
A status of "suspended" typically indicates an error, or that a materialization task is already in
progress. This is the expected state when materialization "start" has been issued, but not the
corresponding "finish" request.
35
After Materialization
After running any materialization task, verify the database you just materialized has reached
an "active" status. You can run the sap_status path command to check the state of all the
databases. The current status for the database after materialization must be "active". If the
status is "defined", this database has not been materialized.
If the status is "error", the error must be resolved before attempting any additional changes to
the system. Review the Replication Server error logs to determine the reason for the error. If
the status is "suspended", this typically indicates an error, or that the materialization task is
still running. This is the expected state when materialization "start" has been issued, but not
the corresponding "finish" request.
Materialization Verification
The materialization process performs an additional verification step by inserting a row in the
rs_ticket_history table at the primary database, then verifying that the materialization
process copied that row to the standby database.
Note: This verification process is part of all the materialization methods and is not a separate
task to be performed, unless you are using an external materialization.
This step ensures that the manual user steps such as dump and load or snapshot
materialization are performed between the sap_materialize start and sap_materialize finish
commands. It does not attempt to verify that the data in the primary and standby databases are
in sync.
If you are using the external materialization method, perform materialization verification
using the imprint command.
See also
Verifying Materialization for External Method on page 42
Monitoring the Replication Environment on page 45
Identifying the Database Dump Directory

Change the location where the DR Agent stores the database dump file.
The DR Agent materialization process uses dump and load to populate the standby database.
If a large database dump file is expected, change the location where the DR Agent stores the
file using:
1> sap_set primary, db_dump_dir, /sybase/D01_REP/temp_dmp_dir
36
Materializing with a Different User

(Optional) Specify a different user name and password to perform the materialization instead
of using user DR_admin
For security purposes user DR_admin may not have role sso_role. If this is the case, a
privileged user and password may be specified as part of the materialization command. The
privileged user must have roles sa_role and sso_role to perform materialization otherwise
it will fail.
Materializing the Master Database

The master database requires unique handling for materialization. Not all contents of the
database are copied from one site to the other, since some information in the master database is
site specific. The only master database changes that are replicated are those related to logins
and roles, to keep users and credentials synchronized between the two sites.
Prerequisites
Verify that no security-related changes are expected to be made in the source Adaptive Server
system during materialization.
Task
The DR Agent facilitates materialization of the master database by providing an automated
materialization function.
1. Execute:
sap_materialize auto, primary_logical_host_name,
standby_logical_host_name, master[,user_name ,password]
go
The order of logical host names in the command dictates the direction in which
materialization is occurring (from source system to target system). The auto option is the
only option available for the master database materialization to manage consistently
which tables are copied. Optionally specify user name and password. This command is
executed asynchronously.
2. Execute sap_status to verify the materialization step is completed.
Once complete, login-related data is synchronized between the two sites. Any subsequent
login changes are replicated, and normal security activity may continue.
During materialization of the master database:
37
BCP is called for each necessary master database table, one at a time. (This is why no
security updates should occur to the master database during this process).
The DR Agent administrator must have sa and sso roles to configure the standby master
database to allow the updates to the related system tables.
A subscription is created at the standby Replication Server from primary to standby for the
master database.
After materializing a database, you can use the monitoring command sap_status path to
check the status of replication for that database.
See also
Materializing the SAP Tools Database

Materialize the saptools database before materializing the SAP database. The small size of
saptools makes materialization relatively quick, and provides validation that all replication
processing is working correctly.
The saptools database is generally small enough to be materialized with an automatic dump
and load procedure.
Execute:
sap_materialize auto, primary_logical_host_name,
standby_logical_host_name, saptools[,user_name,password]
go
The order of logical host names in the command dictates the direction in which materialization
is occurring (from source system to target system). Optionally, specify user name and
password.
During materialization of saptools:
A subscription is created at the standby Replication Server from primary to standby for the
saptools database. The with dump marker option is used.
An Adaptive Server dump command is issued at the primary Adaptive Server. The dump
file location is the same as for the Replication Server stable storage.
When the dump completes at the primary, the load command is issued at the standby
Adaptive Server, using the remote backup server syntax. The dump file is transferred to the
standby by the backup servers. The standby dump file location is again the same as the
Replication Server stable storage.
When the load completes, the DSI thread in the standby Replication Server is resumed.
After materializing a database, use the monitoring command sap_status path to check the
status of replication for that database.
38
See also
Materializing the SAP Database

Materialize the SAP database using database dump and load, or transaction dump and load.
Do not automatically materialize large databases, such as the SAP ERP database. Their size
requires timing and control that is left to your discretion. The DR Agent provides commands
that synchronize the replication environment with your manual dump and load activities.
The replication process has unique interaction points with the Adaptive Server dump
processing. Specifically, each time an Adaptive Server dump command is executed, Adaptive
Server places a marker in the database transaction log that indicates the point when the dump
was complete. Replication, when configured to do so, uses the marker to separate the activity
that does not need to be replicated (is logged before the marker and is contained in the dump
file) from the activity that does need to be replicated (all activity after the dump marker is not
included in the dump file).
Configure replication to look for the marker before issuing the dump command. For dump
sequences that use multiple dump commands (combination of database and transaction log
dumps), you must configure and start materialization prior to only the last dump to be
executed.
Materializing Using Database Dump and Load

Use database dump and load if the SAP database is small enough to support materialization
using a single database dump file.
1. In the DR Agent, execute:
sap_materialize start, primary_logical_host_name,
standby_logical_host_name, D01
go
This instructs the replication components to anticipate the dump and load processing. The
order of logical host names in the command dictates in which direction the materialization
is occurring (from source system to target system).
The start keyword configures replication to anticipate the dump marker, generated by the
Adaptive Server dump command.
Note: A subscription is created at the standby Replication Server from primary to standby
for the SAP database. The with dump marker option is used.
2. Manually dump the entire SAP ERP D01 database by issuing the Adaptive Server
command dump database in the source Adaptive Server system.
39
3. Manually copy the dump file to the target site. Use shared storage, or a process such as FTP
to make a copy of the dump file available at the target site.
4. Manually load the dumped SAP ERP D01 database by issuing the Adaptive Server
command load database in the target Adaptive Server system.
5. Bring the database online by issuing the Adaptive Server command online database in the
target Adaptive Server system.
sap_materialize finish, primary_logical_host_name,
standby_logical_host_name, D01, [,user_name,password]
go
This instructs the replication components to recognize the completion of load processing,
and that new activity can now be applied to the target database. Optionally, specify user
name and password. It completes the materialization process.
Note: The Replication Server DSI threads are now resumed, and application of data to the
standby database can begin.
Materializing Using Transaction Dump and Load

For large databases, it may be impractical to create a new dump of the entire database. Or the
time required to dump the database may also take hours to days for the primary and standby
databases synchronize.
To facilitate materialization for large databases, you can defer replication-related activity until
a series of database dump and subsequent transaction dumps have been loaded to the target
database. This minimizes any replication delay and backlog.
The key difference in this technique is that the DR Agent is not involved until before you create
the last transaction dump, allowing replication products to address only activity that occurs
after the last transaction dump.
1. Manually dump the SAP ERP D01 database. This can be a new dump or an existing dump,
if your system is already configured to perform periodic dumps of the entire database. If
you are creating a new dump, use the dump database command in the source Adaptive
Server system to create a dump of the entire database.
2. Manually load the dumped SAP ERP D01 database. Use the Adaptive Server command
load database in the target Adaptive Server system.
3. Apply the transaction logs dumps to the target database using the Adaptive Server load
transaction command.
When all existing transaction logs dumps have been applied, prepare to create one last
transaction log dump.
sap_materialize start, primary_logical_host_name,
go
40
This instructs the replication components to anticipate the last dump and load process. The
order of logical host names in the command dictates in which direction the materialization
is occurring (from source system to target system).
5.
6.
7.
8.
The start keyword configures replication to anticipate the dump marker from the last
transaction log to be dumped. This must be executed only before the last dump to be loaded
into the standby database. If the start request is issued too soon (not just prior to the last
dump taken) the marker from the wrong dump can be used by replication. If the start
request is too late (after the last dump is taken), replication waits indefinitely for a marker
to appear that it has already read and ignored.
Manually dump the transaction log of SAP ERP D01 database. Use the Adaptive Server
command dump transaction in the source Adaptive Server system.
Manually load the last SAP ERP D01 transaction log dump.
Use the Adaptive Server command online database in the target Adaptive Server system
to bring the database online.
In the DR Agent, execute:
go
This instructs the replication components to recognize that load processing has completed
(the last transaction log dump has been applied and the database is not online). All new
activities that have occurred since the last transaction log dump are now applied to the
target database. It completes the materialization process.
Materializing the Standby Database Using the External

Method
DR Agent includes an external materialization feature that lets you materialize the standby
database without the dump and load solution.
You can use a hardware mirroring product, which DR Agent supports, to generate a snapshot
of the primary files. The feature creates a subscription using the without materialization
parameter. The Replication Server does not perform any processes, and no dump marker is
inserted into the transaction log.
1. Quiesce the Adaptive Server database.
2. Generate a snapshot of the database files.
3. Execute:
sap_materialize external, primary_logical_host_name,
standby_logical_host_name, database_name
go
4. Load the standby database with the snapshot files.
41
5. Bring the database online.
6. Execute:
go
Note: You cannot use the external materialization process on the master database. You can use
the external keyword to skip the materialization process. The DR Agent sets up an active
replication path between the primary and the standby databases when you execute the
sap_materialize external, followed by sap_materialize finish. However, the databases are not
synchronized, and any transactions that update or delete rows may fail.
See also
Verifying Materialization for External Method on page 42
Cancelling Materialization
Execute sap_cancel to cancel the materialization process if it is taking too long or must be
rescheduled. It stops at its next logical point. The cancel operation does not perform cleanup.
You can restart the process at any time.
Verifying Materialization for External Method

Validate materialization using the imprint command before starting the external
materialization process to add the verification row if the external process requires the database
to be offline.
The sap_materialize start, sap_materialize auto, and sap_materialize external commands
automatically insert the verification row into the rs_ticket_history table in the
primary database. However, some external materialization processes cannot guarantee that
the primary database is online, so you must manually imprint the database with the
verification row, then run the sap_materialize external command.
1. While the database is online, execute:
sap_materialize imprint, primary_logical_host_name,
Note: This extra verification step is not performed for the master database materialization
and must only be performed if the external materialization method is used.
2. Perform the initial part of the materialization process.
This would take the database offline.
42
3. Execute:
sap_materialize external, primary_logical_host_name,
4. Perform the remainder of the materialization process.

5. Bring the database online.
6. Execute:
sap_materialize finish, force, primary_logical_host_name,
The sap_materialize finish command verifies that the verification row exists in the
standby database. If for some reason the row does not exist, the DR Agent generates an
error and does not complete the finish command. The force parameter bypasses the
verification test and finishes the materialization process.
Setting Up Adaptive Server HADR

Set up the Adaptive Server high availability disaster recovery (HADR).
The last step performed by the DR Agent, when materializing the SAP database is to setup the
Adaptive Server HADR. This step is only executed if the environment type identified during
setup replication is "dr". DR Agent configures the Adaptive Server on the primary host as the
HADR primary server and the Adaptive Server on the standby host as the HADR standby
server.
See the Adaptive Server High Availability Disaster Recovery Users Guide for more
information.
Rematerializing the ERP or SAP Tools Database

To manually rematerialize the saptools or ERP database, replication must be disabled and
enabled before running sap_materialize again.
See the Recovering from a Failed Materialization section.
Recovering from a Failed Materialization

Unlike other DR Agent commands, materialization is not re-entrant. You cannot simply rerun
the sap_materialize command after fixing the reported problem; the replication environment
must be reset first.
A failed materialization can leave the subscription defined in the replication environment or
the marker inserted into the dump file can be out of date. If an error occurs when materializing
43
the saptools or ERP database using the auto materialization process or if the start or finish
process fails either when executing the sap_materialize command, or during the dump or load
commands, perform these steps:
1. Disable replication for the database.
sap_disable_replication primary_logical_host_name, database_name
2. Reset replication for the database.

sap_enable_replication primary_logical_host_name, database_name
3. Run the materialization command.

These commands are not needed when recovering from a master database materialization
failure, or materialization using the external process. In these instances after you have
fixed the reported problem simply rerun the materialize command.
44
Monitoring the Replication Environment

Check the health and latency status of the replication paths in the disaster recovery system.
Latency calculations are based on the most recent trace flag sent through the system.
1. Execute:
sap_status path
go
2. Issue a new sap_send_trace command to refresh the latency calculation time.
sap_status Returned Information

The results of sap_status with the path keyword display the replication state and other
information for the master, SAP, and saptools databases.
Table 1. Replication States
States
Description
Defined
The state expected after setup and before materialization.
Suspended
The state expected during materialization, when data flow is suspended while
waiting for load activities to complete.
Error
An unexpected error condition. Additional manual review of the Replication

Servers and Replication Server logs may be required to understand the error.
Active
The replication path is supporting replication.
Table 2. Other Database Information

Information
Description
Last Commit Time The local timestamp of a command applied to the target database.
Latency
The approximate length of time it takes for an update on the source system to
reach the target, based on the last trace command sent.
Latency Time
The timestamp of the most recent trace command that was applied to the
target database and used for the latency calculation.
Tracing Latency
Send a trace to initiate latency monitoring. You can initiate a trace from either the primary or
standby logical host. If you are replicating from the primary to standby, initiate the trace at the
45

primary. If you are replicating from the standby to the primary, initiate the trace from the
standby.
Execute the sap_send_trace command. You can specify a database name. If you do not, a
trace is sent to all databases for that host: master, ERP, and saptools (if it exists).
sap_send_trace primary_logical_host_name [,database_name]
go
This command inserts an rs_ticket into the source database or databases. Latency is calculated
from the most recent entry in the target databases rs_ticket_history table.
The DR Agent sap_status path command calculates latency based on the most recent trace
received at the standby database. But if there is a backlog of data, the trace element reflected by
sap_status path results may not be the most recent trace element requested. Verify that the
"Time latency last calculated" is the current time, and not reflective of trace element that was
executed earlier.
Monitoring Resource Usage

Monitor Replication Server device usage and queue backlog, as well as Adaptive Server
transaction log size and backlog. Backlog identifies the accumulated data yet to be processed
by either the Adaptive Server or the Replication Server. All values are reported in megabytes.
1. Execute:
sap_status resource
go
2. If device usage percentages returned from the command are high, consider adding device
space to the replication paths to allow for greater buffering and less risk to the primary
Adaptive server transaction log free space.
Scenarios That May Require Additional Device Space

Replication Servers are configured with file system space that buffer and forward replication
data between the primary and standby sites. In cases of high volume, or system outages, you
may need to increase the space used by replication.
Typical scenarios may include:
46
If the replication throughput cannot meet the current primary system demand, the
Adaptive Server transaction log may become full while waiting for replication. Adding
buffering space to the Replication Servers allows the Adaptive Server logs to truncate
more frequently, pushing the data out of the Adaptive Server transaction log and into
replication queue storage to remove the risk of a full log in the primary Adaptive Server.
Primary Adaptive Server transaction log space may fill if the standby site is unavailable
(due to either planned or unplanned downtime). The Adaptive Server transaction log may

become full while waiting for the standby to return to service. Adding buffering space to
the Replication Servers can allow the Adaptive Server logs to truncate more frequently,
pushing the data instead into Replication Server queues for storage until the standby server
returns to service and can accept the replication backlog.
Adding Replication Server Device Space

Add device space to the replication paths.
Execute:
sap_add_device primary_logical_host_name, part2, 1000
go
This adds 1GB of additional storage to replication on the primary site.

The sap_add_device command issues an add partition command to the underlying
Replication Server defined for the requested logical host.
47
48
Replication Commands
Use DR Agent replication commands to manipulate the replication environment when
working on disaster recovery.
Delay Replication
Delays replication to the ERP database. Delaying replication from the primary ERP database
provides time to recover from an undesirable event, such as a table or records dropped by
mistake.
To delay replication:
The standby Replication Server must be available. See the sap_setup_replication

command.
Set the number of minutes (maximum 1440, or 24 hours) for which to delay replication.
sap_set standby_logical_host_name, delay_time_minutes, 90
go
To enable delayed replication, enter:

sap_delay_replication standby_logical_host_name, on
go
To disable delayed replication, enter:

sap_delay_replication standby_logical_host_name, off
go
Disable Replication
Stops replication for all SAP databases or a specified database.
sap_disable_replication primary_logical_host_name [, database_name]
go
Enable Replication
Restarts replication for all SAP databases or a specified database.
sap_enable_replication primary_logical_host_name [, database_name]
go
After executing sap_enable_replication, you must materialize the database.

Resume Replication
Resumes replication to a specified database or all SAP databases (master, saptools, and ERP).
To resume replication to a specified database, enter:
sap_resume_replication standby_logical_host_name [, database_name]
go
To resume replication to all SAP databases, enter:
49
sap_resume_replication standby_logical_host_name, all
go
Suspend Replication
Suspends replication to a specified database or all SAP databases (master, saptools, and ERP).
To suspend replication to a specified database, enter:
sap_suspend_replication standby_logical_host_name [, database_name]
go
To suspend replication to all SAP databases, enter:

sap_suspend_replication standby_logical_host_name, all
go
See also
Running Setup on page 31
50
Other DR Agent Commands

Use these additional DR Agent commands to manipulate the DR Agent and how it interacts
with the replication environment.
sap_cancel
Cancels any asynchronous or background task.
sap_cancel
go
There is no cleanup performed as part of the sap_cancel command. It passes an instruction to

the background task to stop at its next logical point. Depending on the length of time the
current logical steps requires, the cancel request may not be applied immediately.
You must then execute sap_status to monitor the state of the background task and verify that it
has stopped before you make any new administrative requests.
The background task you are cancelling may be attached to a long-running request, such as an
internally requested dump or load command. As a result, the sap_cancel may not provide
immediate effect. The cancel command does not interrupt any connections or SQL commands
that are active in the DR Agent.
sap_configure_rs
Lists and configures Replication Server and Replication Server database connection
properties.
sap_configure_rs { logical_host_name | all } , { RS |
database_name | all } [, property_name, property_value ]
Either 'all' or a logical_host_name is required.
'all' all logical hosts must be configured.
logical_host_name only the specified logical host must be configured.
Either 'RS', 'all' or database_name is required.
'RS' the command refers to server-level properties.
database_name the command refers to the connection-level properties of the specified

database connection.
'all' the command refers to the connection-level properties of all the database
connections.
Optional values required for setting a property:
property_name name of the property to set.

property_value the new value for the property.
51

If property_name and property_value are set, the specified property is set to the provided
value. If property_name and property_value are not set, a list of all properties of the specified
servers or connections is returned.
Note: If a static property is set and a suspend or resume cycle has not been performed, the
Config Value is different from the Run Value and the Restart Required value is set to Yes. To
restart a connection, execute sap_suspend, then sap_resume.
Command Results
The command returns results in this format:
Logical Host, RS Name, DB Name, Property Name, Config Value,
Run Value, Default Value, Restart Required
Logical Host logical host of the Replication Server being configured.

RS Name name of the Replication Server being configured.
DB Name name of the database connection being configured. This column is not
populated when listing server properties.
Property Name the name of the property.
Config Value configured property value.
Run Value current property value used by the Replication Server.
Default Value default property value.
Restart Required Yes or No. If the value is Yes, then a restart is required for the property
change to take effect. When listing properties, this column is blank or Yes.
Examples
Example 1: List all Replication Server properties on the logical host HostA.
sap_configure_rs HostA, RS
Example 2: Set the Replication Server property min_password_len to 12 on all Replication

Servers in the DR environment.
sap_configure_rs all, RS, min_password_len, 12
Example 3: Set the Replication Server Database Connection property

dsi_row_count_validation to on for all database connections on all Replication Servers in
the DR environment.
sap_configure_rs all, all, dsi_row_count_validation, on
Example 4: Set the Replication Server Database Connection property

dsi_row_count_validation to on for all D01 database connections on all Replication
Servers in the DR environment.
sap_configure_rs all, D01, dsi_row_count_validation, on
sap_get_log
Retrieves log entries from the Replication Server log after a given timestamp.
52

sap_get_log logical_host_name, RS, timestamp
go
The logical name must have been defined using sap_set_host. The timestamp is in the
format of YYYY-MM-DD HH:MM:SS. An example timestamp is: '2013-08-13 14:55:00'
sap_help
Displays a list of available commands, or detailed information for the specified command.
sap_help [command]
go
sap_set_password
Both the primary Adaptive Server and Replication Server, and the standby Adaptive Server
and Replication Server contain the system administrator login DR_admin. The DR Agent
authenticates its login by attempting to log in to one of these servers. This requires the
DR_admin password to be the same on all servers. The sap_set_password command changes
the password on all four servers. After execution, the user must log out and then back in to the
DR Agent.
sap_set_password current_password, new_password, new_password
go
Additionally, this command resets the password for these users logins:
Rep Agent user in Replication Server and RepAgent configuration

RSSD primary user
RSSD maint user
HADR external logins
sap_set_replication_service
Allows you to update the Replication Server Windows Service credentials. It also allows you
to restart the Replication Server using the Windows Service. The Windows Service does not
exist until the rs_init utility is executed to create the Replication Server.
Windows Service details:
Name SYBREP_<SID>_REP
Display Name SYBREP <SID> Replication Server
Start Type manual
Relationship to sap_setup_replicationwhen sap_setup_replication is executed, the

windows service created by sap_set_replication_service is updated to reflect the correct
name and location of the Replication Server that is created. No other attributes of the windows
service that may are set or added by the SAP installer is modified.
Relationship to sap_teardownwhen the replication environment is removed using
sap_teardown command, the windows service created by sap_set_replication_service is
NOT removed. The anticipation is that a teardown will likely be followed by another setup
request. If the windows service is also deleted and recreated, the attributes set initially by the
53

SAP installer will have been lost. To prevent loss of the SAP installer settings, the windows
service is never deleted by the DR Agent. Removal could be made part of the SAP installer
process if the installer is used to physically remove the software from the machine.
Syntax:
sap_set_replication_service logical_host_name, [create | restart |,
domain_name\user_name, password]
Hidden:
sap_set_replication_service LOCAL, domain_name\\user_name, password
Prerequisites:
The SAP SID must be set using the sap_set command, otherwise the hidden LOCAL option
does not work.
This hidden option is only expected to be used by the SAP installer. Its syntax is not
displayed with the sap_help output of the sap_set_replication_service command.
This option can only create a Windows Service on the same machine the DR Agent is
running on
The logical_host_name must have been defined prior to all other options and the options that
accept a logical host can be executed from any DR Agent does not need to be local.
Examples:
Example 1: Defines a Windows Service on the local machine with the credentials provided:
sap_set_replication_service local, sapuser, sappassword
Example 2: Defines a Windows Service on 'myhost' logical host for the Replication Server
belonging to that logical host:
sap_set_replication_service myhost, create
By default, credentials default to the local system account login. You can change the login
credentials using subsequent call to change the credentials.
Example 3: Restarts Replication Server on 'myhost' logical host using the Windows Service
for the Replication Server belonging to that logical host:
sap_set_replication_service myhost, restart
Example 4: Sets or changes the login credentials for the Windows Service on 'myhost'
logical host to use SAP username and SAP password:
sap_set_replication_service myhost, sapuser, sappassword
sap_version
Displays the version of the DR Agent plug-in. With the option all keyword, displays a list of all
the servers known by the DR Agent in this replication environment and their versions.
sap_version [all]
go
54
Failover
Failover
Failover is switching activity to the standby site in the event of a failure on the primary site.
A planned failure occurs on a schedule. Typically as part of a test or other exercise, a planned
failure allows for an orderly sequence of steps to be performed to move processing to the
standby site. The failover includes changes in direction for replication, redirecting NetWeaver
and other applications to connect to the standby site, as well as redirecting other tools and
client applications that may run outside of SAP.
An unplanned failure is unscheduled, occurring unintentionally and without warning. Yet a
similar sequence of events must take place and the same entities are impacted as in a planned
failover. The DR Agent provides assistance for the replication part of failover. It does not assist
with redirecting SAP, NetWeaver or other client activities or connectivity. The DR Agent
changes the direction of replication from the current primary system to the current standby
system.
After the replication part of failover is executed, the direction of replication is reversed.
Activity captured from clients and applications that are redirected to the standby databases is
held to be applied to the primary site when it becomes available. The original primary site
becomes the disaster recovery location for the standby site, which is now performing primary
database support.
sap_failover:
Monitors replication to verify all paths from the primary database to the standby are
complete. No remaining in-flight data to be replicated exists for all three SAP databases,
master, SAP_SID, and saptools.
Suspends the Replication Server at the standby site from applying any additional data from
the primary.
Configures and starts Replication Agent threads for each database in the standby server.
Reconfigures the Replication Server to accept activity from the standby database.
The replication-related activities for failover are divided into two parts. The first part,
supported by sap_failover command processing, ensures clients and applications can
reconnect as soon as possible.
The second part reconfigures the primary database as the new backup for the activity
occurring at the standby site. This second part is fulfilled by using DR Agent command
sap_host_available. The sap_host_available, which:
Disables the Replication Agents on the requested site for the master, SAP_SID, and
saptools databases in an SAP environment so that no data is replicated out from this site.
Reconfigures the Replication Server to not accept activity from the requested site.
Purges the Replication Server queues of any possible in-flight data.
55
Failover
Resets the Replication Server at the current standby site to allow application of future
activity, in the event a subsequent failover back to the primary site is needed.
Performing Planned Failover

Use DR Agent to perform replication-related failover steps.
1. Suspend business activity.
With a planned failover, suspend business activity against your database, to ensure a clean
transition to the standby site without clients or applications needing to react to server
downtime.
2. Shut down the SAP system.
Even without business activity, the SAP system may generate activity internally. Shutting
down NetWeaver ensures no database activity occurs.
3. Log in to to the DR Agent and issue:
sap_failover primary_logical_host_name,
standby_logical_host_name, timeout [, force]
go
where:
timeout is the number of seconds the process will wait while draining the transaction
log and Replication Server queues. If the timeout is reached, the process terminates.
force (Optional) causes the failover process to continue if the timeout value is
reached.
The Replication Server is reconfigured to accept activity from the standby database.
sap_failover executes asynchronously in the background. Use sap_status to check for
successful completion of the sap_failover request.
4. Redirect clients and applications to the standby site.
Once sap_failover executes successfully, the standby databases contain the same content
as the primary.
5. Log in to the DR Agent and issue:
sap_host_available primary_logical_host_name
go
This command executes synchronously.

When you successfully executed both sap_failover and sap_host_available commands, all
replication related failover activities are complete.
Unplanned Failover
Unplanned failover steps are exactly the same as planned failover. The only difference is
timing and planning for the possibility of data loss. The database administrator (DBA) has to
56
Failover
make a conscious decision about failing over and how to deal with any lost transactions and
what happens to these transactions when an old primary site is online again.
The Replication Agent Thread (RAT) does not apply these transactions to Replication Server,
hence, there may be a need for rematerialization, before an old primary site can be designated
as the standby site. For sap_failover execution, there may be in-flight data that is still being
processed if there was a heavy load on the system at the time of failure. The time required to
ensure all in-flight data has been replicated can take longer than a planned failover that has had
all activity quiesced.
During an unplanned outage or disaster, the primary site may be down for hours or days.
Regardless of the duration, you cannot execute sap_host_available until the primary site is
available.
sap_failover primary_logical_host_name, standby_logical_host_name,
timeout [, force]
go
sap_host_available primary_logical_host_name
go
Failback
Failback is switching activity back to the original primary site after failing over to the standby
site.
The sequence of steps and commands is the same for failback as for failover, but switching the
order of the sites. The DR Agent commands are the same, except only the order of the sites is
reversed, to reflect the current direction of replication:
sap_failover standby_logical_host_name, primary_logical_host_name,
timeout [, force]
go
sap_host_available standby_logical_host_name
go
57
Failover
58
Upgrading DR Agent
Upgrading DR Agent
Run the upgrade command to move from an earlier version of DR Agent. The command
checks if an upgrade needs to be performed by verifying that the new DR Agent version is
greater than the previously persisted version. If yes, the upgrade is performed, otherwise no
action is taken.
Prerequisites
Verify both the primary and standby DR Agent versions:
sap_version all
go
Task
Note: Moving from a latest DR Agent version to an earlier version is not permitted.
Upgrade both DR Agents. Issue the upgrade command either on the primary or standby DR
Agent:
sap_upgrade
go
The upgrade command performs the following tasks necessary to move from an earlier
version to the latest version of DR Agent:
a. Connect to the primary and standby Replication Servers.
b. Check for existence of primary and standby replication connections to database saptools.
If no connections exist, remove saptools from the internal database list.
c. For all databases, alter their database replication definitions to allow DDL and stored
procedures to be replicated from the primary to the standby Replication Server.
d. Update and save the new version to the model.
59
Upgrading DR Agent
60
Upgrading Replication Servers and Adaptive Servers
Upgrading Replication Servers and Adaptive

Servers
See the respective product documentation for instructions on upgrading SAP / Adaptive
Servers and Replication Servers that are set up for replication and SAP notes.
In addition to the instructions in this document, also follow the upgrade instructions in the
SAP / Adaptive Server documentation, SAP note 1599814 for Installing ESDs for Sybase
Adaptive Server 15.7 (UNIX and Linux), and any other instructions that may be provided with
an SAP / Adaptive Server upgrade.
Upgrading the Standby Replication Server

Upgrade the standby Replication Server.
Prerequisites
1.
2.
3.
4.
Suspend replication flow from the primary to standby databases.

Verify that replication is complete.
Shutdown the standby Replication Server.
Shutdown the standby DR Agent.
Task
1. Perform the Replication Server upgrade.
2. Start the standby DR Agent.
3. Restore replication to the standby Adaptive Server.
Suspending Replication to the Standby Adaptive Server Database

Before upgrading the standby Replication Server database, suspend replication.
sap_suspend_replication standby_logical_host_name
go
Verifying Replication is Complete

Verify that any data to be replicated has reached the standby host by ensuring that the
Replication Agent has read everything in the transaction log. Additionally, verify that a trace
record is replicated immediately proving there is no backlog within the Replication Server.
1. Log in to the primary Adaptive Server from the primary host. For example, using D01 as
the SAP_SID:
61

isql Usapsa SD01
2. Check the status of the Replication Agent:

use D01
go
sp_help_rep_agent master, process
go
sp_help_rep_agent D01, process
go
sp_help_rep_agent saptools, process
go
The Replication Agent for the master, SAP_SID, and saptools databases must show a
status of "sleeping", and a sleep_status of "end of log". If the Replication Agent is not yet at
the end of the log, wait, then rerun these commands until all three databases reach the end
of log state.
3. Check that all data within the replication path has reached the standby database. Log in to
the DR Agent and execute:
sap_send_trace
go
4. (Optional) Issue the DR Agent sap_status path command to verify that the latency
calculation is low (less than one second) and that the value of "Time latency last
calculated" is equal to the current time in the environment for the master, SAP_SID, and
saptools databases.
If these values are not as expected, it indicates that the latest trace requested has not yet
reached the standby database due to a backlog of data to be replicated. Continue to run
sap_status path until the Time latency last calculated reaches the expected time of the
trace element you are waiting for.
sap_status path calculates latency based on the most recent trace received at the standby
database. But if there is a backlog of data, the trace element may not be the most recent one
sent. Validate that the Time latency last calculated is the current time, and not reflective
of some trace element executed earlier.
Shutting Down the Standby Replication Server

Before upgrading the standby Replication Server database, shut down the standby Replication
Server.
1. Log in to the standby Replication Server from the primary host.
2. Execute:
shutdown
go
62
Shutting Down the Standby DR Agent

Before upgrading the standby Replication Server database, shut down the standby DR Agent.
shutdown
go
Performing the Standby Replication Server Upgrade

Perform the normal Replication Server upgrade installation procedures. Do not start
Replication Server or attempt to upgrade the ERSSD and databases.
Starting the Standby DR Agent

Start the standby DR Agent as described in the Running the DR Agent section.
See also
Running the DR Agent on page 17
Restoring Replication to the Standby Adaptive Server Database

Complete the Replication Server upgrade and resume replication to the standby database.
Execute:
sap_upgrade_server SRS, finish, standby_logical_host_name
go
This completes the Replication upgrade procedures, including upgrading routes if necessary.
Upgrading the Standby Adaptive Server

Upgrade the standby Adaptive Server after upgrading the standby Replication Server.
Prerequisites
1. Complete the standby Replication Server upgrade.
2. Suspend replication flow from the primary to the standby databases.
3. Verify that user sapsso has the proper privileges for the Adaptive Server upgrade.
Task
1. Perform the Adaptive Server upgrade.
2. Restore replication to the standby Adaptive Server database.
3. Restore user sapsso privileges.
63
Suspending Replication to the Standby Adaptive Server Database

Before upgrading the standby Adaptive Server database, suspend replication.
Execute:
sap_upgrade_server ASE, start, standby_logical_host_name
go
Verifying Privileges for User sapsso

Before upgrading the standby Adaptive Server, verify the user sapsso privileges.
1. Log in to the standby Adaptive Server with user sapsa:
isql -Usapsa -Ppassword -Sstandby_host_name:port_num
2. Use database master:

Use master
go
3. Grant select for getting the Adaptive Server host name:

grant select on ase_host_name to sso_role
go
4. Verify the user privilege, execute:

select has_privilege("allow hadr login")
go
If the query result is:
One 1 (the privilege exists), no action is required.

Zero 0 (the privilege does not exist), grant the privilege by executing:
grant allow hadr login to sso_role
go
Performing Adaptive Server Upgrade

Perform the normal SAP or Adaptive Server upgrade procedure. This includes running any
provided scripts.
Removing User sapsso Privilege

If the privilege grant allow hadr login to sso_role is executed when verifying the privilege for
sapsso, then remove it.
Execute:
revoke allow hadr login to sso_role
go
Restoring Replication to the Standby Adaptive Server Database

Complete the Replication Server upgrade and resume replication to the standby database.
Execute:
64

sap_upgrade_server ASE, finish, standby_logical_host_name
go
Restoring replication completes the upgrade of the standby Adaptive Server database.
Upgrading the Primary Adaptive Server and Replication

Servers
To upgrade the primary database and Replication Servers, perform a planned failover, then
upgrade the standby servers (formerly the primary) as described in the previous sections.
See also
Performing Planned Failover on page 56
65
66
Tearing Down a Replication Environment

Tearing down a replication environment includes disabling replication in the Adaptive
Servers, stopping the Replication Servers, and deleting all directories and files created during
setup, including the Replication Server instances.
1. Log in to the DR Agent:
isql UDR_admin PSybase123 Shost1:8899
2. Issue:
sap_teardown
go
The teardown command does not modify any data that has been replicated to the standby
databases. Additionally, the databases on both the primary and standby hosts are not
unmarked for replication. It does not remove any software, but it does remove the
Replication Servers and configurations that support replication. When the teardown
process completes, you can immediately reexecute sap_setup_replication, to rebuild the
environment that was just removed. You must rematerialize the databases.
Directories deleted by Teardown:
Both the primary and standby Replication Server instance directories and their contents
are deleted.
Primary /sybase/<SID>_REP/
<SID>_REP_primary/,SID>_REP_primary.
Secondary /sybase/<SID>_REP/<SID>_REP_standby/
<SID>_REP_standby.
Directories not deleted by Teardown:
The primary and standby dump directories are not deleted during teardown. The dump
directories are defined using sap_set and setting property, db_dump_dir. These
directories can get very large depending on the amount of data materialized. It is the
reponsibility of the user to maintain these directories. Dump file name examples:
saptools.dmp, syslogin.out, sysuser.out
The primary and standby device directories are not deleted during teardown. The dump
directories are defined using sap_set and setting property, device_buffer_dir. Any
device files created by the Replication server will get deleted by teardown. Device file
name example: partition1.dat.
sap_teardown:
Disables Replication Agents and secondary truncation points.
67
Shuts down and deletes Replication Server instances, including their stable queue files.
Does nothing to the data in the standby database (the data remains current as of when
replication was last active).
The DR Agent supports the Replication Server hidden maintenance user password feature.
The Replication Server periodically changes the maintenance user password. After executing
sap_teardown, you may have to reset the Adaptive Server maintenance user password in both
Adaptive Servers before resetting up a new replication environment. Log in to each Adaptive
Server and execute the sp_password command, for example:
sp_password Sybase123, Sybase123, D01_maint
68
Replication-Related Servers
Replication Server and DR Agent are the replication-related servers in your disaster recovery
environment.
Starting DR Agent
The DR Agent must be running on both the primary and standby sites.
2. Start the DR Agent:
./sybase/<SID>_REP/SYBASE.sh
nohup /sybase/<SID>_REP/SCC-3_2/bin/scc.sh &
where /sybase/<SID>_REP is the Sybase home directory of your Replication Server

software installation.
Starting Replication Server

Start Replication Server on both the primary and standby sites.
2. Start the Replication Server on the primary logical host:
nohup /sybase/<SID>_REP/<SID>_REP_primary/D01_REP_primary.sh &
for the standby logical host:

nohup /sybase/<SID>_REP/<SID>_REP_standby/<SID>_REP_standby.sh &
where /sybase/<SID>_REP is the Sybase home directory of your Replication Server

software installation.
69
70
Replication-Related Log Files

Log files are created for DR Agent in the installation directory. Replication Server log files are
also available for both the primary and standby hosts.
DR Agent Log Files
The current DR Agent log file on each host is /sybase/<SID>_REP/SCC-3_2/
plugins/DR/log/dr.log.
Note: The DR Agent rotates the log file each day. Log files from earlier days are in the same
directory, named dr. log.yyyy-MM-dd.
Replication Server Log Files
The current Replication Server log file for the primary host is /sybase/<SID>_REP/
<SID>_REP_primary/<SID>_REP_primary.log. For the standby logical host, the
file is /sybase/<SID>_REP/<SID>_REP_standby/
<SID>_REP_standby.log.
71
72
Index
Index
A
Adaptive Server
HADR 2
high availability disaster recovery 2
restoring replicatation to standby 63
suspending replication to standby 64
suspending replication to standby database 61
upgrading 61
upgrading primary 65
upgrading standby 63
upgrading standby database 64
validating configuration 10
administration user
DR Agent 13
administration user 13
commands 49, 51
connecting 22
creating administrator 13
modifying port 9
other commands 49, 51
running 63
shuttong down standby 63
starting 63, 69
starting in UNIX 17
starting in UNIX as a service 17
starting in Windows 20
starting in Windows as a service 20
stopping in UNIX 17
stopping in Windows 20
verifying that it is running 21
viewing log files 22
dropping a host 26
background, running DR Agent in 17
C
cancelling
disaster recovery setup process 33
connecting to DR Agent 22
D
database
marking for replication 30
materialization 35
database dump directory
identifying 36
database name
setting 26
define the Replication Server on a separate computer
25
defining a logical host 24
defining the primary host 25
disaster recovery environment
architecture 2
disaster recovery setup
running 31
DR Agent
about 1
E
external materialize method 41, 42
F
failback 57
failover 55
planned 56
unplanned 56
foreground, running DR Agent in 17
I
installing
Replication Server 14
L
latency
tracing 45
log files
DR Agent 22
SCC 22
73
Index
M
materialization 35
cancelling progress 42
external method 41, 42
materializing with a different user 37
monitoring
replication environment 45
resource usage 46
P
planned failover 56
preinstallation tasks 9
prerequisites 6
SAP 5
primary Adaptive Server
upgrading 65
R
recovering
failed materilization 43
rematerializing
ERP 43
saptools 43
removing
privilege for user sapsso 64
replication disk buffer
adjusting the default size 29
calculating disk requirements 27
size 28
replication environment
monitoring 45
tearing down 67
Replication Server
installing 14
shutting down standby 62
starting 69
upgrading 61, 65
upgrading standby 61, 63
resource usage
monitoring 46
restarts
configuring in UNIX 17
configuring in Windows 20
running
disaster recovery setup 31
S
SAP
74
prerequisites 5
SAP_SID
defining 26
sapsso
removing privilege 64
scc.bat 20
scc.sh 17
sccd shell script 17
services, UNIX
running DR Agent as 17
services, Windows
running DR Agent as 20
set up
Adaptive Server 43
HADR 43
setup process
cancelling 33
shutting down
standby DR Agent 63
shutting down standby Replication Server 62
sofware versions
for Sybase replication 7
specifying the database dump location 27
Specifying the Replication Server device location
27
standby Adaptive Server
suspending replication 64
upgrading 63
standby Adaptive Server database
restoring replication 63, 64
resuming replication 63
suspending replication to 61
standby DR Agent
shutting down 63
standby logical host
defining 25
standby system administration 5
start up
automatic, configuring in UNIX 17
automatic, configuring in Windows 20
starting
DR Agent 69
starting DR Agent 63
starting the Replication Server
Windows service 33
suspending
replication to standby Adaptive Server 64
suspending replication
standby Adaptive Server 61
Index
Sybase Control Center
viewing log files 22
standby Replication Server 61

upgrading standby
T
tracing latency 45
U
UNIX
running DR Agent in the background 17
running DR Agent in the foreground 17
starting, stopping DR Agent 17
upgrading
Adaptive Server 61
DR Agent 59
primary Adaptive Server 65
Replication Server 61, 65
standby Adaptive Server 63
standby Adaptive Server database 64
V
validating the environment 30
verifying
replication 61
sapsso privileges 64
viewing log files
DR Agent 22
SCC 22
W
Windows
starting, stopping DR Agent 20
75
Index
76

DR Agent Configuration and Users Guide

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

DR Agent Configuration and Users Guide

Enviado por

Direitos autorais:

Formatos disponíveis

Configuration and Users Guide

Disaster Recovery (DR) Agent

DOCUMENT ID: DC00000-01-1571110-01

Configuration and Users Guide

Defining the Primary Host ....................................25

Disaster Recovery (DR) Agent

Materializing Using Transaction Dump and Load

Configuration and Users Guide

Upgrading the Standby Adaptive Server .......................63

Disaster Recovery (DR) Agent

Configuration and Users Guide

Disaster Recovery Environment Architecture

Adaptive Server High Availability Disaster Recovery System

Disaster Recovery (DR) Agent

Configuration and Users Guide

Disaster Recovery (DR) Agent

Before You Begin

Before You Begin

Standby System Administration

Periodic reorganizations and statistics generation, and other housekeeping.

Configuration and Users Guide

Before You Begin

Technical Prerequisites and Limitations

Disaster Recovery (DR) Agent

Before You Begin

4901 Adaptive Server port

Sybase Replication Software Versions and Downloads

Adaptive Server Enterprise

Configuration and Users Guide

HPIA 15.7.0/EBF 20654 SMP ESD#03 /P/ia64/HP-UX B.11.31

Before You Begin

HPIA 15.7.1/EBF 20680 ESD#2 Intel Itanium/HP-UX B.11.31

Disaster Recovery (DR) Agent

Sybase Replication Software Installation

Sybase Replication Software Installation

Changing the DR Agent Port

Configuration and Users Guide

Sybase Replication Software Installation

Validating Adaptive Server Configuration

Disaster Recovery (DR) Agent

Sybase Replication Software Installation

2. An SAP installation requires password encryption. If necessary, execute this command at

Add Additional Adaptive Server Users

Configuration and Users Guide

Sybase Replication Software Installation

Creating the Maintenance User

Disaster Recovery (DR) Agent

Sybase Replication Software Installation

alter login D01_maint add auto activated roles sap_maint_user_role

DR Agent Administration User

Creating DR Agent Administration Login

Configuration and Users Guide

Sybase Replication Software Installation

3. Grant sybase_ts_role to DR_admin so it can perform analysis on the Adaptive Server

Installing Replication Server

3. Provide these responses:

Disaster Recovery (DR) Agent

Sybase Replication Software Installation

Installing Replication Server on Windows

2. Start the installer pointing to response file; for example:

where c:\response.txt is the response file.

Configuration and Users Guide

Sybase Replication Software Installation

Disaster Recovery (DR) Agent