Known Issues for Replication

Recommended interval between data collections is now 5 minutes or more.

The Setting up Statistics Collection help topic recommends setting the interval between scheduled data collections to 60 seconds or more. Disregard this. Sybase now recommends an interval of at least 5 minutes.

When creating alerts for Replication Server paths, Sybase Control Center displays all paths associated with the Replication Server. However, the alerts that are created appear only under the replicate Replication Server.

Workaround: None.

Status is not updated automatically when a latency monitoring process completes.

After a latency monitoring process completes, its status continues to show as “Running” in the Monitor > Paths view.

Workaround: Select the path. Open, then close its Quick Admin pane.

Only the Latency Monitoring collection start and end time is available when populating the Latency Monitoring History chart.

If more than one rs_ticket is collected, only one time, that is, one column, is reported in the chart for both tickets. This appears as a gap in the stacked columns.

Workaround: None.

In the Replication Server Paths view, if a selected path replicates data to a non-Sybase database, the Latency chart displays zero latency.

Sybase Control Center monitors latency in two different ways: by reading the rs_lastcommit table at the replicate database (the default) or, when configured, by reading the rs_ticket_history table at the replicate database. The rs_ticket_history table is used by Latency Monitoring, which provides the ability to configure connectivity information to non-Sybase replicate databases. However, the default latency monitoring using rs_lastcommit does not, thus Sybase Control Center cannot access the rs_lastcommit table in non-Sybase replicate databases. Consequently, the Latency chart displays zero latency. This is also true for the Latency chart in the Path dashboard.

Workaround: To monitor latency to non-Sybase replicate databases, configure and use Latency Monitoring.

Connection arrows in the topology view depend on correctly defined connections.

The direction in which a connection arrow points in the topology depends on how the Replication Server connection is defined. If a primary connection definition is used for a replicate-only connection to a non-Sybase data target, the connection arrow between Replication Server and the non-Sybase data target may point in the wrong direction, from the target instead of to the target.

Workaround: When creating the Replication Server connection definition to the non-Sybase replicate database, omit the with log transfer clause that is used for creating a primary connection definition.

If an Adaptive Server cluster stops responding, the RepAgent thread status shown in replication is “Down.”

An Adaptive Server cluster has several nodes. Each node has its own host and port. You can register an Adaptive Server cluster and one of its nodes. If the registered node stops responding while monitoring replication in the Adaptive Server cluster, the status of the RepAgent thread and of that node appear as “Down” instead of automatically using another working node.

Multiple error messages apppear when a single Replication Server goes down.

When a monitored Replication Server goes down, several error messages are recorded in the agent.log. The correct error message is reported by all monitored Replication Servers, making it appear that the error message may be coming from other Replication Servers.

Workaround: None.

When you configure Replication Agent parameters in the Quick Admin view while in the replicating state, the changes appear when you select “Show changes applied this session” even though they have not been successfully applied.

Workaround: None.

An empty value for the pdb_xlog_device parameter shows as invalid in the Quick Admin view for Replication Agent, even though an empty value is valid.

Workaround: None.

Logical connections do not have any alerts.

The Add Alert wizard shows logical connections beneath the Replication Server resource. When you click the Type page, you see this message at the bottom of the page: All available alert definitions have been created for this resource.

Workaround: None. This message is expected since there are no alerts defined for logical connections.

Collections fail if replication access library stored procedures are removed.

Replication Server data collections fail if the replication access library stored procedures are removed from the Replication Server System Database (RSSD).

Workaround: Unregister and reregister the Replication Server.

The RepAgent thread graph does not appear.

When you open a Path dashboard, the RepAgent thread graph does not appear.

Workaround: Replication Server is case-sensitive. The Adaptive Server name and the connection and route names must match, including case. If the case is different, unregister the Adaptive Server, then reregister it using the correct case.

The “Launch Statistics Chart”option is missing when you right-click an Adaptive Server registered for replication.

Workaround: None.

562600

562598

“Repeat once” and “Repeat indefinitely” options are not supported for Replication Server data collection jobs.

If you select one of these options, the job is created, but SCC does not collect the statistics. Instead, it writes an error message to the SCC console and log file.

Workaround: Change the collection job option to Repeat until so that the job runs a specific number of times.

Replication Server performance statistics collection does not support Replication Server 12.6 and 15.0.

The monitor and counters interface in versions 12.6 and 15.0 is very different from the interface in Replication Server 15.0.1 and later.

Workaround: None.