DR Agent Configuration and Users Guide

8/21/2019 DR Agent Configuration and Users Guide

1/82

Configuration and Users Guide

Disaster Recovery (DR) Agent

15.7.1


2/82

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 furnishedunder 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.
http://www.sybase.com/detail?id=1011207http://www.sybase.com/detail?id=1011207


3/82

Contents

Introduction to DR Agent ......................................................1Disaster 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

DRAgent Administration User .............................13Creating 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 ....................................................22Connecting to DR Agent ...............................................22

Setting Up the Disaster Recovery Solution .......................23

DRAgent Security ........................................................23

DRAgent Error Handling ..............................................24

Defining a Logical Host .................................................24

Configuration and Users Guide iii


4/82

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 aSeparate 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 ...........................30Running 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 ................................37Materializing the Master Database ...............................37

Materializing the SAP Tools Database ..........................38

Materializing the SAP Database ...................................39

Materializing Using Database Dump and Load . . .39

Contents

iv Disaster Recovery (DR) Agent


5/82

Materializing Using Transaction Dump and Load

.........................................................................40

Materializing the Standby Database Using the

External Method .......................................................41

Cancelling Materialization .............................................42Verifying 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 .........................................................................57Upgrading 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 .................63Performing the Standby Replication Server

Upgrade ...........................................................63

Starting the Standby DR Agent ........................... 63

Restoring Replication to the Standby Adaptive

Server Database ............................................. 63

Contents

Configuration and Users Guide v


6/82

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..................64Removing 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

Contents

vi Disaster Recovery (DR) Agent


7/82

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_adminsystem 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 abasic replication setup for disaster recovery.

Note:DR Agent supports only SAP Business Suite environments.

Replication in a Disaster Recovery EnvironmentIn 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 primarysite 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.


Configuration and Users Guide 1


8/82

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.


2 Disaster Recovery (DR) Agent


9/82

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 thelast 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 Guidefor more

information.




10/82




11/82

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 SAPinstoptions 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



12/82

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 LimitationsMeet 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 primarysite. 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 permissionsgranted 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 Servertransaction 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



13/82

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 Porton 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/En-

terprise 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/Win-

dows Server

Before You Begin



14/82

Software Version

Replication Server 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 pSer-

ies/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

DR Agent 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

Before You Begin



15/82

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.xmlfile 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.xmlfile is located in the /sybase/_REP/SCC-3_2/plugins/DRdirectory. The agent-plugin.xmlrepresents 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 theagent-plugin.xmlthat holds the port number. For example, to

change the default port 8899 to 7777, enter:

3. Start the DR Agent.

When establishing connectivity with other DR Agent processes, the commands

sap_set_hostand sap_setare 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:




16/82

a) On the physical host computer1, modifyagent-plugin.xmlto set the default port

of DR Agent to 7777.

b) Start or restart DR Agent on computer1.

c) Using isqlor 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_setcommand is used.

For example:

a) Connect to DR Agent on computer1 using isqlor 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 -SD01use mastergo

sp_dboption D01, 'trunc log on chkpt', falsegoDatabase option 'trunc log on chkpt' turned OFF for database

'D01'.Running CHECKPOINT on database 'D01' for option 'trunc log onchkpt' to takeeffect.(return status = 0)

sp_dboption saptools, 'trunc log on chkpt', falsegoDatabase option 'trunc log on chkpt' turned OFF for database'saptools'.




17/82

Running CHECKPOINT on database 'saptools' for option 'trunc log onchkpt' 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 -SD01sp_configure FIPS login password encryption, 1go

You must restart Adaptive Server for this change to take effect. Use the SAP commands

stopdband startdbto 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 -SD01sp_configure 'net password encryption reqd', 1go

Adaptive Server refuses all connection requests that do not encrypt passwords after setting

net password encryption reqd. The isqloption 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 UserReplication 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 bythe user is ignored by replication may create a loss or inaccuracy between the primary and

standby databases.




18/82

Creating the Maintenance UserCreate 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 tablecommand.

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

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 authorizationmust be assigned to a role.

Example 1: Create the _maint user on both hosts. D01 is used in these examples:

isql -Usapsso -PSybase123 -SD01use mastergo

create login D01_maint with password Sybase123go

sp_role "grant", replication_role, D01_maintgo

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.

isql -Usapsa -PSybase123 -SD01sp_role "grant", sa_role, D01_maintgoAuthorization updated.(return status = 0)

Example 3: Create a new role named sap_maint_user_role and grant it set session

authorizationpermissions. Grant the sap_maint_user_role to the maintenance user.

isql -Usapsso -PSybase123 -SD01create role sap_maint_user_rolego

grant set session authorization to sap_maint_user_rolego

sp_role "grant", sap_maint_user_role, D01_maintgo




19/82

alter login D01_maint add auto activated roles sap_maint_user_rolegoAuthorization updated.(return status = 0)

Example 4: Alias the D01_maint to DBO in the master, SAP_SID, and saptools databases.

isql -Usapsa -PSybase123 -S D01use mastergo

sp_addalias D01_maint, dbogoAlias user added.(return status = 0)

use D01go

sp_addalias D01_maint, dbo

goAlias user added.(return status = 0)

use saptoolsgo

sp_addalias D01_maint, dbogoAlias user added.(return status = 0)

Execute all of these commands at both the primary and standby sites.

DR Agent Administration UserA 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 LoginCreate the DR Agent administrator.

PrerequisitesLog in as a user with sso role.




20/82

Task

1. Create the DR_admin user on both hosts. For example:

isql -Usapsso -PSybase123 -SD01use mastergo

create login DR_admin with password Sybase123go

sp_role "grant", sso_role, DR_admingo

sp_role "grant", replication_role, DR_admingoAuthorization updated.(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:isql -Usapsa -PSybase123 -SD01sp_role "grant", sa_role, DR_admingoAuthorization updated.(return status = 0)

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

transaction log. For example:

isql -Usapsso -PSybase123 -SD01sp_role "grant", sybase_ts_role, DR_admingoAuthorization updated.

(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/

_REP.

For example, /sybase/D01_REP.




21/82

Note:Adaptive Server is installed at /sybase/. Replication Server is

installed at /sybase/_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 WindowsTo 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=TRUEDO_NOT_SETENV_AND_REGISTRY=TRUEDO_NOT_CREATE_SHORTCUT=trueREGISTER_UNINSTALLER_WINDOWS=false

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

.\setup.exe -f C:\response.txt

where c:\response.txtis the response file.




22/82




23/82

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/_REP/SYBASEscript to set the necessary environment

variables.

a. Change to the Sybasedirectory (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.shscript to start the DR Agent manually. You can either:

Run scc.shin 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.shin the background to suppress the console.You can use scc.shto 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 sccdscript to configure a service that starts DR Agent automatically.

Here are the steps for each starting and stopping option:




24/82

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 shutdownat 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 chkconfigis 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/sccdinto this directory:

AIX: /etc/rc.d/init.d

HP-UX: /sbin/init.d

All other platforms: /etc/init.d




25/82

b) Open sccdand 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 sccdscript with /usr/sbin/service sccd status. (The

servicecommand accepts these options: start| stop| status| restart.)

d) On non-Linux platforms, locate this directory:

AIX: /etc/rc.d/rc.d

HP-UX: /sbin/rc.d

Solaris: /etc/rc.d

where 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: S90sccdand

/etc/rc.d/init.d/sccd: K10sccd

HP-UX:

/sbin/init.d/sccd: S90sccdand

/sbin/init.d/sccd: K10sccd

Solaris:

/etc/init.d/sccd: S90sccdand

/etc/init.d/sccd: K10sccd

The S90sccdlink starts the service and the K10sccdlink stops the service. The

two-digit numbers in the links indicate the start and stop priorities of the service.

e) Use the S90sccdand K10sccdlinks 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 Windowson page 20




26/82

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 theSYBASE.batfile 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_.

C:> cd %SYBASE%\SCC-3_2\plugins\DR\bin\amd64 (or .. bin\win32on 32bit Windows)C:> drservice.exe install Sybase DR Agent - installed.

d) Start DR Agent as a Windows service:

C:> sc start SybaseDRAgent_SERVICE_NAME: SybaseDRAgent_ 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_ obj= password=

f) Stop DR Agent Windows Service:




27/82

C:> sc stop SybaseDRAgent_SERVICE_NAME: SybaseDRAgent_ 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 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_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 Startor

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

typeto Automatic.

g) To restart the service in case of failure, choose the Recoverytab and change the First,

Second, and Subsequent failures to Restart Service.

h) Click Applyto 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/_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 theDR 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 statuscommand at the SCC console:

scc-console> status




28/82

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/_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 pluginsdirectory, for example, /sybase/_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:

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

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




29/82

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 pass-

through 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_hostcommand 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.




30/82

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 Commandson 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 locatedunder the Replication Server directory structure, for example, /sybase/_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:




31/82

Instance directory

Routes

Connections

Subscriptions

Defining the Primary HostDefine 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, 4901go

The logical host name is used to reference the site.

Defining the Standby HostDefine the standby logical host.

sap_set_host logical_host_name, host2, 4901go

The logical host name is used to reference the site.

Defining the Replication Server on a Separate ComputerUse the sap_set_hostcommand 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_numgo

This can be used when defining either the primary or the standby site.

Defining the DR Agent Server Port on a Separate ComputerUse the sap_set_hostcommand 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_numgo

This can be used when defining either the primary or the standby site.




32/82

Dropping a HostDrop a host that was previously defined using the sap_set_hostcommand.

sap_drop_host logical_host_namego

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, , and, saptools are

used when setting up a new replication environment. When a replication environment isalready 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, D012> 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, Sybase1232> go




33/82

Specifying the Database Dump Location

(Optional) Change the database dump location.

By default, the dump file location is: $SYBASE/_REP. The DR Agent uses the dumplocation, 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_pathgo

See also

Materializing the SAP Databaseon page 39

Specifying the Replication Server Device Location

(Optional) Change the Replication Server device location.

By default, the device location is: $SYBASE/_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_pathgo

See also Adding Replication Server Device Spaceon 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_setcommand with no arguments to display a list of all the DR Agent

properties and their values. Use the sap_setcommand to change any of the listed property

values.

sap_set logical_host_name,property_name, new_valuego

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 replicationfeature is configured or the




34/82

delay_time_minutesis set in sap_setvariable. 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 duringnightly 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 delaydesired) * 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 persite, 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:

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 .




35/82

standby, device_buffer_size identifies the size (in megabytes) of the disk allocation.

Adjusting the Default Replication Disk Buffer SizeAdjust 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_setproperty_name, desired_valuego

For example, to change the allocation size to 5GB on the primary host, enter:

sap_set primary, device_buffer_size, 5000go

Note:Each Replication Server is created with exactly one partition of the size specific by

device_buffer_sizeand at the location of directory device_buffer.

See also Adding Replication Server Device Spaceon page 47

Replication Server Properties Tuning

The file RS.propertiescontains replication property settings that are applied when you

create a new Replication Server.

The file is read during sap_setup_replicationexecution. The configure replication server

command is executed for each of the properties. See the Replication Server Reference

Manual.

Note:Any changes to RS_DB.propertiesfiles 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.propertiesfiles 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 Manualfor 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.




36/82

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_replicationexecution. alter connectionis the specific Replication Server

command that is run for each of these properties.

Note:Any changes to RS_DB.propertiesfiles 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.propertiesfiles 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 Manualfor 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_replicationcommand, review the output from:

sap_pre_setup_check, env_type,primary_logical_host_name,standby_logical_host_namego

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




37/82

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_replicationautomatically executes the same marking command for all databases.

sap_setup_replicationis available solely as a timing convenience for updating the SAP

database.

Running SetupCreate the disaster recovery replication environment.

PrerequisitesVerify that all required properties have been set.

TaskExecute:

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




38/82

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_statusgo

If the return from the sap_statuscommand 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_statuscommand 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_statuscommand returns an error, the background task fails. Review the remaining

task information to obtain an error description. Correct the error condition and rerun




39/82

sap_setup_replication. All steps that executed successfully up to the error point are bypassed

if they were successful. Use sap_statusto monitor the task until it successfully completes.

If the information from the sap_statuscommand 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_cancelgo

sap_setup_replicationstops at its next logical point.

2. (Optional) Execute the sap_teardowncommand to remove the results, or reexecutesap_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_teardownto 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_serviceAPI. 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_serviceprimary_logical_host_name,windows_user_name,password, restartgo




40/82




41/82

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 thestandby. 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 ConfigurationsWhen materializing databases that are configured to use a dump configuration, you must use

sap_materialize startand sap_materialize finishcommands.

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

Prior to MaterializationBefore running any materialization task, verify that the database to be materialized is properly

set up for replication. Execute sap_status pathto 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.




42/82

After MaterializationAfter running any materialization task, verify the database you just materialized has reached

an "active" status. You can run the sap_status pathcommand 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 VerificationThe materialization process performs an additional verification step by inserting a row in the

rs_ticket_historytable 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 dumpand loador snapshot

materialization are performed between the sap_materialize startand 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 imprintcommand.

See also

Verifying Materialization for External Methodon page 42

Monitoring the Replication Environmenton 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 dumpand loadto 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




43/82

Materializing with a Different User

(Optional) Specify a different user name and password to perform the materialization instead

of using user DR_adminFor 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 thedatabase 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.

PrerequisitesVerify 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 autooption 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 isexecuted asynchronously.

2. Execute sap_statusto 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:




44/82

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 pathto

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 materializationis 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 markeroption is used.

An Adaptive Server dumpcommand is issued at the primary Adaptive Server. The dump

file location is the same as for the Replication Server stable storage.

When the dumpcompletes at the primary, the loadcommand is issued at the standby

Adaptive Server, using the remote backup server syntax. The dump file is transferred to thestandby 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 pathto check the

status of replication for that database.




45/82

See also


Materializing the SAP Database

Materialize the SAP database using database dumpand load, or transaction dumpand 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 dumpand loadactivities.

The replication process has unique interaction points with the Adaptive Server dump

processing. Specifically, each time an Adaptive Server dumpcommand 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 notincluded in the dump file).

Configure replication to look for the marker before issuing the dumpcommand. For dump

sequences that use multiple dumpcommands (combination of database and transaction log

dumps), you must configure and start materialization prior to only the last dumpto be

executed.

Materializing Using Database Dump and LoadUse 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, D01go

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 startkeyword configures replication to anticipate the dump marker, generated by the

Adaptive Server dumpcommand.

Note:A subscription is created at the standby Replication Server from primary to standby

for the SAP database. The with dump markeroption is used.

2. Manually dump the entire SAP ERP D01 database by issuing the Adaptive Server

command dump databasein the source Adaptive Server system.




46/82

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 databasein the target Adaptive Server system.

5. Bring the database online by issuing the Adaptive Server commandonline databasein the

target Adaptive Server system.

6. In the DR Agent, execute:

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 LoadFor 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 createthe 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 databasecommand in the source Adaptive

Server system to create a dump of the

Documents

DR Agent Configuration and Users Guide