Skip navigation.
Downloads | Product Documentation | Support

Administration Application Guide

# Failover and System Reliability

This section describes WebLogic Enterprise Security features that support recovery from failure. It covers the following topics:

- Understanding Failover
- WebLogic Enterprise Security Failover Considerations
- Understanding Database Replication
- Database Replication in an Oracle Environment
- Database Replication in a Sybase Environment

# Understanding Failover

Figure 2-1 shows how WebLogic Enterprise Security System supports failover, through the use of a redundant component architecture. The Administration Console, external data sources (used by the LDAP providers), and the database server, all support failover through configuration in the Administration Console. To ensure reliable operations, you must consider the ramifications of the failure of each component.

To accommodate your basic needs, you can install two Administration Servers: a primary and a secondary. The number of redundant database servers you configure is totally up to you, although a minimum of two is recommended to maintain reliable services. The secondary Administration Server is only used when the primary becomes unavailable; likewise with the database server.

Figure 2-1 WebLogic Enterprise Security System Failover

# WebLogic Enterprise Security Failover Considerations

The following sections discuss the failover considerations for the various WebLogic Enterprise Security components:

- Failover Considerations for the Administration Server
- Failover Considerations for the Database Server
- Failover Considerations for a Security Service Module
- Failover Considerations for a Service Control Manager

## Failover Considerations for the Administration Server

Figure 2-2 shows how failover works when the primary Administration Server fails. One benefit of the WebLogic Enterprise Security architecture is that even if all the Administration Servers go down (either for maintenance or due to failure), including the secondary Administration Servers, there is no impact on the applications in production or on the security services provided by those Security Service Modules and providers that you have configured. As long as you have back up instances of your policy database, external data sources, and back ups of application files, you can safely restart the Administration Server on another machine without interrupting services. However, you cannot install or enroll new Security Service Modules until the primary Administration Server is running or you have reconfigured the secondary server as the primary. You can only enroll Security Service Modules using a primary Administration Server.

For information on how to configure the Administration Server, see your Console Help: Configuring the Administration Server for Failover.

Figure 2-2 Administration Server Failover

## Failover Considerations for the Database Server

Figure 2-3 shows how failover works when the primary Database Server fails. The number of redundant database servers you configure is totally up to you. A minimum of two is recommended to maintain reliable services: a primary database is read/write, while the secondary provides read-only access. The secondary database, created by using the database replication procedures, contains only the data that is needed for the Security Service Modules, rather than a complete set of the configuration and security data. The secondary database is primarily used for failover in Security Service Modules and not the Administration Server.

Because the Database Server contains all of the configuration and security data used by the Administration Application, to protect your applications and resources, you want to make sure it is highly available and reliable. This can be accomplished by implementing recommendations from your database manufacturer (for example, through the use of clustering architecture; hot standby).

Figure 2-3 Database Failover

Common methods of archiving high availability include periodic back-ups, fault tolerant disks, and copying files manually whenever they are changed. This is also the case for any optional external data sources you have configured. Both Sybase and Oracle offer database backup methods. Refer to Sybase and Oracle documentation for details. The backup can be used for database recovery in the case of disk failure. To provide high availability for the Security Service Modules when using the security providers supplied with the product, you must perform certain database replication procedures as described in the Database Replication in an Oracle Environment and Database Replication in a Sybase Environment.

## Failover Considerations for a Security Service Module

Failover support through the Administration Console is provided for database-related providers and LDAP authentication providers. Configuration for database related providers includes the specification of the secondary (backup database) and support for LDAP authenticators includes the specification of the secondary LDAP server.

The following providers support configuration of a secondary database:

- Database Credential Mapping provider
- Database Authentication provider
- ASI Authorization provider
- ASI Role Mapper provider

Note: The ASI Authorization Provider contacts an external process to evaluate its authorization queries. If that process dies, the ASI Authorization provider denies access to all resources. The ASI Authorization provider may contact an external metadirectory database to retrieve subject attributes and group membership for use in authorization and delegation decisions. If the database connection fails, the provider connects to the configured failover replicated metadirectory. The provider tries to reconnect to the failed database after a configurable timeout. If all metadirectory connections fail and the policy evaluation is configured to require user attributes and group membership, all access is denied. For additional information on starting and stopping services, see Starting and Stopping Services.

The following providers support configuration of a secondary LDAP server:

- Novell LDAP Authenticator
- Active Directory Authenticator
- iPlanet Authenticator
- Open LDAP Authenticator

For additional information on how to configure the provider for failover, see Security Configuration or the Console Help for the specific provider.

Note: The NT Authenticator already supports multiple domain controllers. The WebLogic Authenticator, WebLogic Authorizer and WebLogic Role Mapper use the internal LDAP server for WebLogic server as its data store. No support for a redundant source is required.

## Failover Considerations for a Service Control Manager

The Service Control Manager has a mechanism for enrolling with multiple Administration Servers so that configuration can be administered from multiple Administration Consoles. A process manager is used to monitor the status of the Service Control Manager process and, if it stops responding or fails, the process manager restarts the Service Control Manager. The process manager runs as a Windows NT Service or UNIX daemon. This allows the Service Control Manager to be automatically restarted on machine reboots.

Note: If a Service Control Manager fails, all Security Service Modules controlled by the manager continue to run, but any new Security Service Module instances will not be able to start, because they cannot retrieve their configuration. However, a Security Service Module can still enroll with the Administration Server, even if the Service Control Manager fails.

# Understanding Database Replication

To provide reliability and high availability of Security Service Modules, replication of part of the policy database is necessary. The replicated database objects needed for this replication process include tables and indices that are required by the Security Service Modules. They contain the data that are used by the following providers:

- Database Authentication provider
- Database Credential Mapper provider
- ASI Authorization and ASI Role Mapper providers

Note: The ASI Authorization and ASI Role Mapper providers are implemented using an out-of-process evaluation engine (the ARME process). If this process fails, access for all resources is denied. This process is monitored and restarted if an error occurs.

Most of the policy database used for security policy and for configuration administration and management is not replicated. The administration and management functions are performed against one and only one database. This means that the components such as the Administration Application, the Policy Distributor, and the Metadirectory Synchronization process are only connected to one database.

Warning: Your administrator needs to ensure that the primary database is backed up regularly using a database backup tool or using a hardware backup strategy to protect the database against fatal systematic errors, should one ever occur.

The steps included in following sections describe how to create a read-only database replica. While some scripts automate this process, to complete the replication, you need to perform certain steps manually. For instructions on how to replicate databases in the Oracle and Sybase environments, see the following sections:

- Database Replication in an Oracle Environment
- Database Replication in a Sybase Environment

# Database Replication in an Oracle Environment

WebLogic Enterprise Security uses the Materialized View (MV) Replication method to replicate the database objects from a master database (also called the master site) to one or more materialized view databases (also called the materialized view sites). In an earlier version of Oracle, such as Oracle 8i, a materialized view replication was called a snapshot replication, and a materialized view site was called a snapshot site. The master database is the database that is administered through the Administration Application. The database schema of the master database is installed and set up during the Administration Application installation. The materialized view database provides failover and availability for the Security Service Modules. You can set up the Security Service Modules at a later time, according to your business needs.

The following sections describe the replication tasks:

- Preparing for Oracle Database Replication
- Setting Up Oracle Database Replication

## Preparing for Oracle Database Replication

Use the following items as a checklist to prepare your replication environment.

- Master and Materialized View Site Requirements
- Master Site Requirements
- Materialized View Site Requirements
- Requirements for the Machine Running the Replication Setup Scripts
- Setting the Required Replication Setup Parameters

Warning: If you are concerned with the database password being used in the scripts, you can run the replication setup manually. All passwords are designated as clear text in the `set_repl_env_oracle.sh` and`set_repl_env_oracle.bat` scripts. When you are through, you can either delete the script or remove the password from the script.

### Master and Materialized View Site Requirements

Requirements for the master site and the materialized view site include the following:

- You are able to login to the database as database administrator (DBA) and you have the privileges to restart the database.
- Ensure that the database name is in the form of `DB_NAME.DB_DOMAIN`. This ensures that the database links can be set up correctly. You can check this by running this SQL statement after logging into the database:

>     select * from global_name;

If the `DB_DOMAIN` is missing, correct it. This task requires DBA privileges.

- Change the initialization parameters for both databases (the master database and the materialized view database) according to Table 2-1. The value for each initialization parameter depends on your use of the database. Refer to Table 2-1, and set the parameters as follows:

- If the default values for the parameters that are defined as "Required" in the Comment field do not suit your needs, change them.
- Set the parameters that are defined as "Optional" in the Comment field according to the use of your database.

For detailed information on these parameters, refer to your Oracle Documentation. For Oracle 9i, see Chapter 6: "Planning Your Replication Environment" in Advanced Replication (for Oracle 9.2) or Oracle9i Replication (for Oracle 9.0). For Oracle 8i, see Chapter 7: "Planning Your Replication Environment" of Oracle8i Replication. Also check the Oracle documentation for details on how to set the initialization parameters.

####

Table 2-1 Initialization Parameters

Parameter | Recommended Value | Comment
--- | --- | ---
`GLOBAL_NAMES` | true | Required
`JOB_QUEUE_PROCESSES` | at least 1 | Required
`OPEN_LINKS` | at least 4 | Required
`PROCESSES` | at least 40 | Required
`REPLICATION_DEPENDENCY_TRACKING` | true | Required
`COMPATIBLE` |  | Optional
`PARALLEL_MAX_SERVERS` |  | Optional
`PARALLEL_MIN_SERVERS` |  | Optional
`SHARED_POOL_SIZE` |  | Optional
Oracle 9i only |  |
`PARALLEL_AUTOMATIC_TUNING` |  | Optional
`UTL_FILE_DIR` | A valid directory in the host machine of the database | Required: the directory must be created
Oracle 8i only |  |
`ENQUEUE_RESOURCES` |  | Optional
`JAVA_POOL_SIZE` |  | Optional
`JOB_QUEUE_INTERVAL` |  | Optional
`MAX_ENABLED_ROLES` |  | Optional
`MTS_DISPATCHERS` | PROTOCOL=TCP)(PRE=oracle.aurora.server.SGiopServer) | Required
`OPEN_CURSORS` |  | Required

### Master Site Requirements

Requirements for the master site include the following:

- Your master database must be either an Oracle Enterprise edition or an Oracle Standard edition.
- Ensure that the replication administrator `REPADMIN` and `PROXY_ADMIN` does not already exist in this database. If either one already exists, you cannot automate the replication setup using the scripts because the scripts will fail to create them. You need to set up the master site manually. You can use SQL `select * from all_users` to check for its existence.
- Ensure that the policy database schema is already installed. You need to know the schema owner (`WLES` user) and login password.
- Ensure that the size of the `TABLESPACE` used by the `WLES` user is large enough to accommodate the extra storage needed by replication.

### Materialized View Site Requirements

Requirements for the materialized view site include the following:

- In this host machine, set up an Oracle Local Service Name for the master database using the same name as the master database name, in the form of `DB_NAME`.`DB_DOMAIN`.
- Ensure that the replication administrator `MVADMIN` does not already exist in this database. If it already exists, you cannot automate the replication setup using the scripts because the scripts will fail to create it. You need to set up the materialized view site manually.
- Ensure that the same `WLES` user as in master database does not exist in this database as this user is created. However, you need to locate a `TABLESPACE` for this `WLES` user before the setup using the scripts. By default, the temporary `TABLESPACE` for this user is set to `TEMP`.
- Decide how frequently you want the replicated objects refreshed in this database. Set the refresh time interval to a multiple of one minute.

### Requirements for the Machine Running the Replication Setup Scripts

On this machine, set up Oracle Local Service Names for the master database and materialized view database, using the same names as their database names, in the form of:

`DB_NAME`.`DB_DOMAIN`

### Setting the Required Replication Setup Parameters

Table 2-2 lists and describes the parameters that you must set before you can set up the replication. You must set these parameters in the setup script:

>     set_repl_env_oracle.bat (Windows)

or

>     set_repl_env_oracle.sh (Unix/Linux)

In addition to the parameters listed in Table 2-2, you need to set `ORACLE_HOME`, if it is not yet set in your environment, and the `__REPL_SETUP_TYPE__` parameter, depending on what kind of replication setup you choose.

Table 2-2 Oracle Replication Setup Parameters

Parameter Name | Description | Example
--- | --- | ---
`__MASTER_SERVICE_NAME__` | Service name of master database (`DB_NAME.DB_DOMAIN`). | mstrdb.bea.com
`__MASTER_SYSTEM_PASSWD__` | Password for `SYSTEM` user (`DBA`) in master database. | Pswd000
`__REPADMIN_PASSWD__` | Password for `REPADMIN` (to be created/dropped, replication admin) in master database. | Pswd111
`__PROXY_MVADMIN_PASSWD__` | Password for `PROXY_MVADMIN` (to be created/dropped) in master database. | Pswd222
`__MASTER_PURGE_INTEVAL__` | Time interval in minutes to purge completed deferred transactions at master site. | 60
`__MV_SERVICE_NAME__` | Service name of materialized view (`MV`) database (`DB_NAME.DB_DOMAIN`). | `mvdb.bea.com`
`__MV_SYSTEM_PASSWD__` | Password for `SYSTEM` user (`DBA`) in materialized view database. | Pswd333
`__MVADMIN_PASSWD__` | Password for `MVADMIN` (to be created/dropped, replication admin) in MV database. | Pswd444
`__TBLSPACE_DBUSER_WLES__` | Tablespace for WLES database user (__`DBUSER_WLES_UPPERCASE`__) in MV database. | USERS
`__MV_PURGE_INTEVAL__` | Time interval in minutes to purge completed deferred transactions at `MV` site. | 60
`__MV_PUSH_INTEVAL__` | Time interval in minutes to push deferred transactions to master at `MV` site. | 60
`__REFRESH_INTEVAL__` | Time interval in minutes to refresh the refresh group at `MV` site. | 2
`__DBUSER_WLES_UPPERCASE__` | The policy database user name in both the master and materialized view databases; must be in UPPER CASE. It cannot exist in the materialized view database before setting up replication. This user is created to use tablespace: __`TBLSPACE_DBUSER_WLES`__ | WLES_USER
`__DBUSER_PASSWD_WLES__` | The database user password in both master and materialized view databases. | Pswd555

## Setting Up Oracle Database Replication

Use the following procedures to set up the Oracle database replication using scripts or manually.

- Using Scripts to Set Up Oracle Database Replication
- Setting Up Oracle Database Replication Manually
- Using Scripts to Clean Up Oracle Database Replication
- Cleaning Up the Oracle Database Replication Manually
- Miscellaneous Oracle Database Replication Tasks

Warning: You must set up the master site before replication setup can be performed for a materialized view site.

### Using Scripts to Set Up Oracle Database Replication

To use scripts to set up replication, perform the following steps:

1. Change to the directory:

>     WLES_HOME/bin

2. To set up the environment and input parameters, edit the following file:

`set_repl_env_oracle.bat` (Windows)

or

`set_repl_env_oracle.sh` (Unix/Linux)

Save a copy of this file before editing. The parameter `__REPL_SETUP_TYPE__` gives you the option to set up either a master site, a materialized site or both.

3. Run the following script:

`replicate_oracle.bat` (Windows)

or

`replicate_oracle.sh` (Unix/Linux)

You are prompted to continue. A message is displayed when the script completes, indicating whether the execution was successful or if it failed. The following log file shows the status of the execution:

>     WLES_HOME/log/replicate_oracle.log

4. After the setup completes, edit or delete the following file and close the window:

`set_repl_env.oracle.bat` (Windows)

or

`set_repl_env_oracle.sh` (Unix/Linux)

### Setting Up Oracle Database Replication Manually

To set up replication manually, perform the following steps:

1. In the `WLES_HOME/data/oracle/` directory, locate these SQL files:

>     rep_mastersite.sql

>     rep_mvsite.sql

2. Save a copy of each one.
3. Edit them by globally replacing the variables with your settings, as instructed at the beginning of each file.
4. Manually execute the step-by-step SQL statements using the SQLPLUS tool. The comments in these SQL files describe what each step does.

### Using Scripts to Clean Up Oracle Database Replication

Warning: Replication clean up must be performed for all materialized view sites before the master site can be cleaned up.

To use scripts to clean up the replication, perform the following steps:

1. Change to the directory:

>     WLES_HOME/bin

2. Set the environment and input parameters in the following file:

`set_repl_env_oracle.bat` (Windows)

or

`set_repl_env_oracle.sh` (Unix/Linux)

Save a copy of this file before editing it. The parameter `__REPL_SETUP_TYPE__` gives you the option to clean up either a master site, a materialized site or both.

3. Run the following script:

`clean_repl_oracle.bat` (Windows)

or

`clean_repl_oracle.sh` (Unix/Linux)

You are prompted to continue. A message is displayed when the script completes, indicating whether the script was successful or if it failed. The following log file shows the status of the execution:

>     WLES_HOME/log/clean_repl_oracle.log

4. After the cleanup completes, edit or delete following file and close the window:

`set_repl_env_oracle.bat` (Windows)

or

`set_repl_env_oracle.sh` (Unix/Linux)

### Cleaning Up the Oracle Database Replication Manually

To clean up the replication manually, perform the following steps:

1. In the `WLES_HOME/data/oracle/` directory, locate the following SQL files:

>     rep_clean_master.sql

>     rep_clean_mv.sql

2. Save a copy of each one.
3. Edit the files by globally replacing the variables with your settings, as instructed at the beginning of each file.
4. Manually execute the SQL statements step-by-step using the SQLPLUS tool. The comments in these SQL files describe what each step does.

### Miscellaneous Oracle Database Replication Tasks

To complete the replication of the Oracle database, perform the following steps:

1. The database name must be in the form of `DB_NAME.DB_DOMAIN`. If the database name is not in this form, login to the database as DBA and run the following SQL command to change it:

>     alter database rename global_name to DB_NAME.DB_DOMAIN;

2. Change the initialization parameters (refer to Oracle documentation on how change the initialization parameters):

>     db_name: to DB_NAME

>     db_domain: to DB_DOMAIN

>     service_name: to DB_NAME.DB_DOMAIN

3. Change the listener for the new `global_name`.
4. If you change the`global_name`, update the Oracle listener setting, and then restart the listener. The `GLOBAL_NAME` is recorded in the Oracle configuration file called `listener.ora` in the `ORACLE_HOME/network/admin/` directory.
5. Change the setting for the Local Service Name in all Oracle clients.

If you change the local service name that points to this database, you must update it on all applicable client machines. Change the `SERVICE_NAME` of the `CONNECT_DATA` to the new `service_name` in client configuration file `tnsnames.ora`, usually in the `ORACLE_HOME/network/admin/` directory. If your system uses Directory Naming or Oracle Naming methods, update them instead of `tnsnames.ora`. Refer to your Oracle documentation for details.

# Database Replication in a Sybase Environment

WebLogic Enterprise Security uses the Sybase ASE Replicator to replicate the database objects from a primary database in primary Adaptive (ASE) server to one or more replicate databases in the replicate ASE servers. The ASE Replicator process is an external application that connects to and interacts with the ASE server, and coordinates all replication processing. The policy in the primary database is administered though the Administration Server. The database schema in the primary database is installed and set up during the Administration Application installation. The replicate databases provide failover and availability for the WebLogic Enterprise Security Security Service Modules. They can be set up according to your business needs at a later time. For more information, see the ASE Replicator User's Guide from Sybase.

The following sections describe the replication tasks:

- Preparing for Sybase Database Replication
- Setting Up Sybase Database Replication
- Cleaning Up Sybase Database Replication

## Preparing for Sybase Database Replication

The following sections provide checklists so you can prepare your replication environment:

- Privileges for the Primary and the Replicate ASE Servers
- Primary ASE Server and Primary Database Requirements
- Replicate ASE Server and Replicate Database Requirements
- Requirements for the Machine Used to Run Sybase Database Replication Setup Scripts
- Parameters Needed for Sybase Database Replication Setup

Warning: If you are concerned with the database password being used in the scripts, BEA recommends that you run the replication setup manually. All passwords are designated in clear text in the `set_repl_env_sybase.sh` and`set_repl_env_sybase.bat` scripts. When you are through, you can either delete the script or remove the password from the script.

### Privileges for the Primary and the Replicate ASE Servers

Make sure you are able to login to the servers as DBA (sa) and you have the privilege to restart the servers.

### Primary ASE Server and Primary Database Requirements

The primary ASE server and primary database requirements are as follows:

- Your server must be of ASE version 12.5.0.3 or later. This version includes the ASE Replicator software. You need to patch it if the server is of earlier version of 12.5.
- The ASE Replicator is started and is running in this machine, even though if can be run from other machines that has ASE Replicator software installed.
- Ensure the ASE Replicator system user login does not already exist in this server. You can specify the name of this login in the setup scripts. If the system user login already exists, you cannot automate the replication setup using the scripts because the scripts will fail to create it, and you will need to set up the replication manually. You can use SQL select name from syslogins to check its existence.
- Ensure that the policy database schema is already installed. You need to know the schema owner (`WLES` user) and login password.
- Ensure that you (sa) have created the database for the replication process to use as the distribution database. Before creating the database, you may need to create two database devices, one used for data and another used for transaction log. Allocate sufficient database storage. You can use the `disk init` and `create database` isql commands, or use another GUI tool to set these up. Also, while this database is dropped when running the replication cleanup scripts, the database devices are not. See the Administration Application Installation Guide for instructions on how to set up the database.
- In this host machine, set up the following server entries in Sybase configuration file using either the Sybase tool Dsedit or using a text editor. The configuration file is:

`sql.ini` (Windows)

or

`interfaces` (Unix/Linux).

- Primary ASE server—the same name as the primary database server.
- ASE Replicator—the name and port number you choose here is used later when you start the ASE Replicator.
- Replicate ASE server—the same name as the replicate server.

### Replicate ASE Server and Replicate Database Requirements

The replicate ASE server and replicate database requirements are as follows:

- Ensure that this ASE server is installed and configured with logical page size equal to or larger than the logical page size of the primary ASE server. Use SQL statement:
  `select @@maxpagesize` to check them out.
- Ensure the replication Maintenance user login does not already exist in this server. The same ASE Replicator system user login is used. If it already exists, you cannot automate the replication setup using the scripts because the scripts will fail to create it, and you will need to set up the replicate database manually.
- Ensure the same WLES user login as in primary ASE server does not exist in this server, as it is created. If it already exists, you cannot automate the replication setup using the scripts because the scripts will fail to create it, and you will need to set up the replication manually.
- Ensure that you (sa) have created a new database to use as the replicate database. This database is used to store replicated policy data. Before creating the database, you may need to create two database devices, one used for data and another used for transaction log. Allocate sufficient database storage. Transaction log size can be much smaller than that in policy database in the primary ASE server. Also, while this database and the database devices are not be dropped when running the replication cleanup scripts, the schema for WLES user is dropped.

### Requirements for the Machine Used to Run Sybase Database Replication Setup Scripts

The requirements for the machine used to run the Sybase database replication setup Scripts are as follows:

Note: If you use the primary ASE server machine to run the Sybase database replication setup scripts, you do not have to do anything and you can skip this section.

- In this host machine, set up the following server entries in the Sybase configuration file using Sybase tool Dsedit or using text editor. The configuration file is:

`sql.ini` (Windows)

or

`interfaces` (Unix/Linux)

You can copy this file from the primary ASE server machine.

- Primary ASE server—the same name as the primary database server.
- ASE Replicator—the server name of the ASE Replicator.
- Replicate ASE server—the same name as the replicate server.

### Parameters Needed for Sybase Database Replication Setup

Table 2-3 lists the initialization parameters you need to set before you set up the replication. You set these parameters in:

`set_repl_env_sybase.bat` (Windows)

or

`set_repl_env_sybase.sh` (Unix/Linux)

You also need to set SYBASE if it is not yet set in your environment. In addition, you need to set `__REPL_SETUP_TYPE__` depending on what kind of replication setup you choose.

Table 2-3 Sybase Initialization Parameters

Parameter Name | Description | Example
--- | --- | ---
`__PRIMARY_DBSERVER__` | Name of the primary ASE server. | PRISVR
`__PRIMARY_DBNAME__` | Name of the primary policy database in the primary ASE server. | policy
`__SA_PASSWD_PRIMARY__` | Password for sa (DBA) in the primary ASE server. | Pswd000
`__DISTRIBUTION_DBNAME__` | Distribution database name in the primary ASE server. This database is used by the replication process (or Replicator). The database contains the database schema (tables, etc.) used by the replicator. | distrDB
`__ASE_REPLICATOR_NAME__` | Name of the ASE Replicator. This name should be the same as that in the Sybase configuration file. | PRISVR_RPL
`__REPLICATE_DBSERVER__` | Name of the replicate ASE server. | RPLSVR
`__REPLICATE_DBNAME__` | Name of the secondary policy database in the replicate ASE server. | policy
`__SA_PASSWD_REPLICATE__` | Password for sa (DBA) in the replicate ASE server. | Pswd111
`__USER_REPADMIN__` | ASE Replicator system username/login and Maintenance username/login. | repadmin
`__PASSWD_REPADMIN__` | Password for user `__USER_REPADMIN__.` | Pswd222
`__DBUSER_WLES__` | Policy database username/login in both primary and replicate ASE servers. | wlesuser
`__DBUSER_PASSWD_WLES__` | Policy database password in both primary and replicate ASE servers. | Pwd333
`__REPL_SETUP_TYPE__` | Indicates whether to set or clean up both primary and replicate databases. The value is one of these: both, primary, or replicate. | both

You also need to know the values for `__SIZE_IDXCOL__` and`__SIZE_COL__` when you set up a replication manually. The value for these two can be found in the policy database in the primary ASE server using SQL statement:

>     select __SIZE_IDXCOL__ = idx_column_size, __SIZE_COL__ = reg_column_size from __DBUSER_WLES__ column_sizes

Note: `__DBUSER_WLES__` is substituted with the value described.

## Setting Up Sybase Database Replication

Use the following procedures to set up the Sybase database replication using scripts or manually.

- Using Scripts to Set Up Sybase Database Replication
- Setting Up Sybase Database Replication Manually
- Setting up the Primary ASE Server and the Primary Database
- Starting the ASE Replicator
- Adding a Remote Server in Primary ASE Server for the Replicate ASE Server
- Setting Up the Replicate ASE Server and the Primary Database
- Setting up the Sybase Database Replication Process

Warning: The Primary ASE server and database must be set up and ASE Replicator started before you can perform replication setup on a replicate database.

### Using Scripts to Set Up Sybase Database Replication

To use scripts to set up Sybase database replication, perform these steps:

1. Change to the following directory:

>     WLES_HOME/bin

2. Edit the following file to set the environment and input parameters:

`set_repl_env_sybase.bat` (Windows)

or

`set_repl_env_sybase.sh` (Unix/Linux)

Save a copy of this file before editing it. The parameter `__REPL_SETUP_TYPE__` allows you to set up either a primary, replicate database, or both.

3. Run the following script:

`replicate_sybase.bat` (Windows)

or

`replicate_sybase.sh` (Unix/Linux)

4. You are prompted to continue.
5. You are then prompted to restart the primary ASE server. Go to the primary ASE server machine, and stop and start the ASE server. After the server is started, press <Enter> to continue.
6. You are prompted to start the ASE Replicator. Go to the primary ASE server machine and start the ASE Replicator process. After the server is started, press <Enter> to continue.

You are prompted to continue. A message is displayed when the script completes, indicating whether the script was successful or if it failed. The following log file shows the status of the execution:

`WLES_HOME/log/replicate_sybase.log`

7. Edit or delete the file:

`set_repl_env_sybase.bat` (Windows)

or

`set_repl_env_sybase.sh` (Unix/Linux)

8. Close the window after the setup completes.

### Setting Up Sybase Database Replication Manually

To set up Sybase database replication manually, perform these steps:

1. In the `WLES_HOME/data/sybase/` directory, locate and copy the following SQL files:

>     rep_pdb_conf.sql

>     rep_rsvr_rdb.sql

>     rep_rdb_conf.sql

>     rep_replication.sql

2. Edit them by globally replacing the variables with your settings, as instructed in each file.
3. Manually execute the SQL statements step-by-step using the isql tool. The order is described in the following sections. When you are setting up a second replicate database, you need to perform the following tasks:

- Setting up the Primary ASE Server and the Primary Database
- Starting the ASE Replicator

### Setting up the Primary ASE Server and the Primary Database

Login to the primary ASE server as sa (DBA) and execute: `rep_pdb_conf.sql`. You can do this statement-by-statement. You also need to restart the primary ASE server manually, after running this script. This SQL file performs the following tasks.

1. Enables and configures CIS in the primary ASE server.
2. Sets up ASE Replicator system user login and assigning it to replication role.
3. Adds the ASE Replicator system user to the policy database (primary database) and grants its permissions.
4. Defines remote servers in the primary ASE server.
5. Defines the local server name for the primary ASE server.
6. Defines a server named `local` as a remote alias for the primary ASE server.
7. Defines a remote server for the ASE Replicator.
8. Configures the `tempdb` database.
9. Sets up ASE Replicator system user and changes the database option in the distribution database.
10. Adds the ASE Replicator system user to the distribution database.
11. Grants permissions to ASE Replicator system user in the distribution database.
12. Changes the database option in the distribution database.
13. Sets up the ASE Replicator system user in database `sybsystemprocs`.
14. Creates the `sp_helpddb` stored procedure in database `sybsystemprocs`, and grants execution permission to ASE Replicator system user.

### Starting the ASE Replicator

To start the ASE replication, perform these steps:

1. Go to the primary ASE server machine and change to the directory: `RPL-12_5/bin` in the Sybase installation directory.
2. If ASE Replicator is started the first time:

1. Make sure the `RPL-12_5` directory has write permission.
2. Using the proper command options, execute the following command:

`aserep.bat` (Windows)

or

`aserep.sh` (Unix/Linux)

Check the ASE Replicator User's Guide for details.

Note: You can restart the ASE Replicator by running either: `aserep.bat` or `aserep.sh` using the same command options, or by running the `RUN` script that is located under `SYBASE/RPL-12_5/replicatorName` and providing the -u and -p options.

### Adding a Remote Server in Primary ASE Server for the Replicate ASE Server

To add a remote server in the primary ASE server for the replicate ASE server, perform these steps:

1. Login to primary ASE server as sa (DBA).
2. Execute the following script:

`rep_rsvr_rdb.sql`

### Setting Up the Replicate ASE Server and the Primary Database

Login to the replicate ASE server as sa (DBA) and execute: `rep_rdb_conf.sql`. You can do this statement-by-statement. Before starting, make sure the replicate policy database already exists. This SQL file performs the following tasks.

1. Adds the `WLES` user login.
2. Adds the `WLES` user login to the replicate database.
3. Creates the replicate tables and indices in replicate database, according to the logical page size setting of primary database.
4. Adds a Maintenance user login (for example, `repadmin`). This is the same as ASE Replicator system user login.
5. Adds `repadmin` as a user in replicate database.
6. Grants permission to `repadmin`.

### Setting up the Sybase Database Replication Process

Login to primary ASE server as ASE Replicator system user login and execute: `rep_replication.sql`. You can do this statement-by-statement. Before starting, make sure the ASE Replicator is running. This SQL file performs the following tasks:

1. Creates the primary database connection if it does not yet exist.
2. Creates a replicate database connection.
3. Suspends both the replicate and primary database connections.
4. Creates a publication.
5. Adds the articles (replicated objects) to publication.
6. Creates a subscription.
7. Adds the articles (replicated objects) to subscription.
8. Materializes the replication articles (replicated objects).
9. Resumes both replicate and primary database connections to start replication.

## Cleaning Up Sybase Database Replication

Use the following procedures to automate replication cleanup or to do it manually. Replication cleanup also stops the ASE Replicator and drops the distribution database in the primary ASE server. If you experience a failure while using the scripts to clean up replication, you are advised to finish the cleanup manually.

Before attempting cleanup, make sure that there is no database connection for `WLES` user login to the replicate ASE server and for ASE Replicator system user login to both replicate and primary ASE servers. If there are connections, cleanup will fail. You can use `sp_help loginName` to check whether the user still has connections.

- Using Scripts to Clean Up Sybase Database Replication
- Cleaning Up the Sybase Database Replication Manually
- Cleaning Up the Sybase Database Replication Process
- Cleaning Up the Replicate ASE Server and Primary Database
- Removing the Remote Server
- Stopping ASE Replicator
- Cleaning Up the Primary ASE Server and the Primary Sybase Database
- Completing Sybase Database Replication Cleanup

Warning: You must perform the replication clean up for all replicate databases before the primary database can be cleaned up and the ASE Replicator removed.

### Using Scripts to Clean Up Sybase Database Replication

To use scripts to clean up Sybase database replication, perform these steps:

1. Make sure that there is no database connection for `WLES` user login to the replicate ASE server, and for ASE Replicator system user login to both the replicate and primary ASE servers.
2. Change to the following directory:

>     WLES_HOME/bin

Set the environment and input parameters in the following file:

`set_repl_env_sybase.bat` (Windows)

or

`set_repl_env_sybase.sh` (Unix/Linux)

Save a copy of this file before editing it. The parameter`__REPL_SETUP_TYPE__` gives you the option to clean up either a primary database and ASE server, a replicate database and ASE server, or both.

3. Run the following script:

`clean_repl_sybase.bat` (Windows)

or

`clean_repl_sybase.sh` (Unix/Linux)

You are prompted to continue. A message is displayed when the script completes, indicating whether the execution was successful or if it failed. The following log file shows the status of the execution:

`WLES_HOME/log/clean_repl_sybase.log`

4. Edit or delete the following file:

set_repl_env_sybase.bat (Windows)

or

set_repl_env_sybase.sh (Unix/Linux)

5. Close the window after the cleanup completes.
6. To complete replication cleanup, remove the ASE Replicator process by deleting all files from the `RPL-12_5/replicatorName` Sybase installation directory.

### Cleaning Up the Sybase Database Replication Manually

To clean up Sybase database replication manually, perform these steps:

1. In the `WLES_HOME/data/sybase/` directory, locate the following SQL files and save a copy of each one:

`rep_clean_replication.sql`

`rep_clean_rdb.sql`

`rep_clean_rsvr_rdb.sql`

`rep_clean_stop_rpl.sql`

`rep_clean_pdb.sql`

2. Edit each file globally, replacing the variables with your settings, as instructed in each file.
3. Manually execute the SQL statements step-by-step using isql tool. The order is described below. When you are cleaning up a replicate database alone, you need to perform the following tasks:

- Cleaning Up the Replicate ASE Server and Primary Database
- Removing the Remote Server

### Cleaning Up the Sybase Database Replication Process

Login to the primary ASE server as the ASE Replicator system user login and execute: `rep_clean_replication.sql.` You can do this statement-by-statement. This SQL file performs the following tasks:

1. Suspends both the replicate and primary database connections.
2. Drops the articles (replicated object) from subscription.
3. Drops the subscription.
4. Drops the articles (replicated object) from publication.
5. Drops the publication.
6. Drops the replicate database connection.
7. Drops the primary database connection if it is not being used for any other publications; resumes the connection if it is used.

### Cleaning Up the Replicate ASE Server and Primary Database

Login to replicate ASE server as sa (DBA) and execute: `rep_clean_rdb.sql`. You can do this statement-by-statement. This SQL file performs the following tasks:

1. Drops the replicate tables. Indices are dropped automatically.
2. Drops the `WLES` user in replicate database.
3. Deletes the `WLES` user login in replicate ASE server.
4. Drops the Maintenance user in replicate database.
5. Deletes the Maintenance user login in the replicate ASE server.

### Removing the Remote Server

In the Primary ASE Server for the Replicate ASE Server, follow these steps to remove the remote server:

1. Login to the primary ASE server as sa (DBA).
2. Execute the following script:

>     rep_clean_rsvr_rdb.sql

3. In the primary ASE server, remove the remote server for the replicate ASE server.

### Stopping ASE Replicator

To stop the ASE Replicator, perform these steps:

1. Login to the ASE Replicator, using the ASE Replicator system user login.
2. Execute the following script to shut down the ASI Replicator:

`rep_clean_stop_rpl.sql`

Note: Alternatively, shutdown ASE Replicator manually.

### Cleaning Up the Primary ASE Server and the Primary Sybase Database

Login to primary ASE server as sa (DBA) and execute: `rep_clean_pdb.sql`. You can do this statement-by-statement. This SQL file performs the following tasks.

1. Drops the procedure `sp_helpddb` in database `sybsystemprocs`.
2. Drops the ASE Replicator system user in database `sybsystemprocs`.
3. Drops the ASE Replicator system user in primary policy database.
4. Removes remote servers in the primary ASE server.
5. Removes the local server name for the primary ASE server.
6. Removes the server named `local` as a remote alias for the primary ASE server.
7. Removes the remote server for the ASE Replicator.
8. Drops the distribution database.
9. Deletes the ASE Replicator system user login.

### Completing Sybase Database Replication Cleanup

To complete replication cleanup, remove the ASE Replicator process by deleting all of the files under `RPL-12_5/replicatorName` in your Sybase installation directory.