ASE Replicator User’s Guide
ISBN : -
Order a printed copy of this book from Amazon --UNAVAILABLE--
Cover Design - ASE Replicator User’s Guide
For your free electronic copy of this book please verify the numbers below.
(We need to do this to make sure you're a person and not a malicious script)
Sample Chapter From ASE Replicator User’s Guide
Copyright © Sybase Inc.
Understanding replication concepts
A transaction replication system maintains consistent, synchronized datain separate databases. It does that mainly by recording the data-changing
operations in one database (called the primary database), and sending
those operations to another database (called the replicate database).
Data-changing operations thus captured and sent are called replicated
transactions.
As shown in Figure 1-1, the primary database publishes replicated
transactions, and the replicate database subscribes to replicated
transactions.
Table replication
Replicated transactions are published by table. When data-changing operationsaffect the contents of a published table in the primary database, they are
recorded for subsequent distribution to a replicate database.
A replicate database can be a subset of a primary database, with some—but not
all—of the tables in the primary database. Therefore, not all of the tables in a
primary database have to be published.
To receive replicated transactions, the replicate database must subscribe to a
published table in the primary database, and it must identify the subscribing
replicate database table. Replicated transactions from the primary database are
distributed to subscribing tables in the replicate database.
Stored procedure replication
In addition to replicating data-changing operations, another way to maintainconsistent, synchronized data is to replicate the invocation of stored procedures
that change data. Replicating a stored procedure invocation can sometimes be
more efficient than replicating the individual data-changing operations that the
procedure produces.
When a stored procedure is published, the replication system must identify the
procedure and record the input parameter values that are specified when the
procedure is invoked. The system must then distribute that procedure
invocation to any subscribing replicate database.
Stored procedure replication places a special requirement on a replication
system. When a published procedure generates a data-changing operation on a
published table, the replication system must be able to recognize the operation
generated by the published procedure, and replicate only the procedure
invocation and not the data-changing operation produced by it.
Transaction replication
Transaction replication ensures database integrity and transactionalconsistency between the databases. All data-changing operations that are
replicated are considered to be “transactions,” even though they might not
correspond to an actual transaction in the primary database.
For example, if an actual transaction changes both published tables and
unpublished tables in the primary database, only the data-changing operations
on published tables are replicated. Operations on unpublished tables are not
replicated, but transactional consistency is maintained if the replicate database
contains only tables that correspond to published tables in the primary
database.
Even though a replicated “transaction” is really just a set of data-changing
operations, those operations are grouped in an atomic collection, and each
collection represents the results of a committed transaction in the primary
database. Only committed transaction operations should be replicated;
transaction operations that are rolled back should not be replicated.
Stored procedure invocations are considered part of a transaction, just like
data-changing operations on a table. The procedure invocations are not
necessarily transactions in themselves.