Scribd
Upload
23 views3 pages

Sybase Replication 1667758633

Uploaded by

sheik.1212121212
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
23 views3 pages

Sybase Replication 1667758633

Uploaded by

sheik.1212121212
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

SYBASE REPLICATION CONCEPTS

Regular replication: – Table level replication from a primary to a replicate database.

Multi-site availability (MSA):- database level replication from a primary to replicate database.

Warm Standby: – database level replication to maintain a standby database, transactions are
captured in the primary database and distributed to the replicate database.

Hot Standby: – transactions are run simultaneously in the primary and replicate database using
distributed transaction management.

Cold Standby: – the primary data is copied to the replicate database on a scheduled basis.

Internal Operations of Sybase replication server: -

1. RepAgent reads the record from Transaction log of the PDB for the tables which are marked for
replication(sp_setreptable).

2. Logs into the PRS and write transactions in inbound queue of the stable device.

3. Holds Data in inbound queue , until it receives commit.

4. Uses subscription information in its RSSD to decide what to do with the each transaction, after
the commit.

-It Discards the trans if there is no subscription.

-Writes the transaction to the out bound queue if there are subscription, Writes committed trans
only in outbound queue according to subscription .

5. DSI THREAD sends transactions to their destination according to their subscription.

-Replication Server uses lot of threads(DSI,RSI,SQT,SQM etc).

If any one of thread stops , replication stops , even it can hamper PDB performance we
need better monitoring for this.
THREADS:

Replication Server runs multiple threads concurrently. The total number of threads depends on
the number of databases that a Replication Server manages and the number of Replication
Servers to which it has direct routes. Each thread performs a specific function such as managing a
user session, receiving messages from a RepAgent, receiving messages from another Replication
Server, or applying transactions to databases.

Replicati
on agent
Thread:

Reads
the
primary
database
transacti
on log to
find
transacti
ons (SQL
stateme
nts or sp
exec )
that
have
occurred
against tables that are marked for replication.

Forwards transactions to the replication server using a proprietary language called Log Transfer
Language (LTL)

Function as a connection manager for the repagents and passes the changes to SQM

Maintains a secondary truncation point in transaction log, which prevents transactions from
being truncated until they are safely stored in the replication server stable device.

Coordinate recovery between the transaction log and replication server

Stable Queue Manager thread

There is one Stable Queue Manager (SQM) thread for each stable queue accessed by the primary
Replication Server, whether inbound or outbound. Each RepAgent user thread works with a
dedicated SQM thread that reclaims stable queue space after a transaction is forwarded to a data
server or to another Replication Server.
Stable Queue Transaction thread

Commands stored in transaction log records and in the inbound queue are ordered according to
the sequence in which they were committed, although they are not necessarily grouped by
transaction. It is the task of the Stable Queue Transaction (SQT) thread to reassemble
transactions and place the transactions in commit order. Transactions must be in commit order
for final application on the destination’s data servers and for materialization processing.
The SQT thread reassembles transactions as it reads commands from its stable inbound queue
and keeps a linked list of transactions. For the outbound queue, the DSI/S thread schedules
transactions, and performs the SQT function of assembling and ordering transactions. When it
reads a commit record, the SQT makes that transaction available to the distributor (DIST) thread
or to the DSI thread, depending on what process required the SQT ordering of the transaction.

Distributor thread and related modules

For each primary database managed by a Replication Server, there is a distributor (DIST) thread,
which in turn uses SQT to read from the inbound queue and SQM threads to write transactions to
the outbound queue. Thus, for example, if there are three primary databases, then there are
three inbound queues, three DIST threads, and three SQT threads.

Replication Server Interface thread

RSI threads are asynchronous interfaces to send messages from one Replication Server to
another. One RSI thread exists for each destination Replication Server to which the source
database has a direct route.
The DIST thread in the primary Replication Server processes transactions, causing those destined
for other Replication Servers to be written to RSI outbound queues. An RSI thread logs in to each
replicate Replication Server and transfers messages from the stable queue to the replicate
Replication Server.

- Replication server adds a table called rs_lascommit to each primary or active database in the
replication system.Rs_lastcommit stores the last committed transaction that is in the stable
device of the database, Replication server uses the origin_qid to ensure that no duplicate
transactions are processed.

Thanks,

Prajwal

You might also like