Warm standby requirements and restrictions

The following restrictions apply to all Replication Server warm standby applications:

You must use a Sybase Adaptive Server that supports warm standby applications. Refer to your release bulletin for more information.

One Replication Server manages both the active and standby databases. Both the active and standby databases must be Adaptive Server databases.

You cannot create a standby database for the RSSD. You can only create a standby database for the master database if the Adaptive Server supports master database replication.

Replication Server does not switch client applications to the standby database. See “Setting up clients to work with the active data server” for more information.
You should run Adaptive Server for the active and standby databases on different machines. Putting the active and standby databases on the same data server or hardware resources undermines the benefits of the warm standby feature.
Although Adaptive Server allows tables that contain duplicate rows, tables in the active and standby databases should have unique values for the primary key columns in each row.
Failover support is not a substitute for warm standby. While warm standby keeps a copy of a database, Failover support accesses the same database from a different machine. Failover support works the same for connections from Replication Server to warm standby databases.

For more detailed information about how Sybase Failover works in Adaptive Server, refer to Using Sybase Failover in a High Availability System, which is part of the Adaptive Server Enterprise version 15.0 documentation set.

For more detailed information about how Failover support works in Replication Server, see “Configuring the replication system to support Sybase Failover” in Chapter 7, “Replication System Recovery”.
The commands and procedures for abstract plans are replicated, except for the following:
- The and set @plan_id clause of create plan is not replicated. For example, this command is not replicated as shown.
```
create plan "select avg(price)
from titles" "(t_scan titles)
into dev_plans and set @plan_id
```
  Rather, it is replicated as:
```
create plan "select avg(price) 
from titles" "(t_scan titles)
into dev_plans
```
- The abstract plan procedures that take a plan ID as an argument (sp_drop_qplan, sp_copy_qplan, sp_set_qplan) are not replicated.
- The set plan command is not replicated.