Archive for the ‘Replication Server’ Category

Sybase Community Forum…

August 10th, 2010 No comments

Hi All,

After long time, new posting…:(

Just sharing..may be some folks aware with it…Recently came across the Sybase’s own  community forum, supported by Team Sybase….

Its having very good technical discussion, troubleshooting…tips fo ASE, IQ, Replication and many more…

How to check the Replication Latency manually?

January 23rd, 2010 No comments

Hi Folks,
For the checking latency between Primary and Replicated DBs , we have several methods.

Here, I am posting the manual method for checking the replication latency. If you have any more thoughts, please comment it out.

Rite Now I am travelling to Delhi, my train got late, so I am spending my time with my fav, with new posting in blog.

For calculating the latency, we can make two tables in PDB and RDB with column as defaut datetime, and setup replication between these two tables.

Before excuting the batch of your’s queries, insert the id (only for reference for the point, where we executed the insert statement) and it will update the primary_datetime by default current system date.

After the completing the batch, insert the the next id, automaticaly it will get the finish date in default column.

Now go to RDS and check the diff between primary_datetime and replicate_datetime.

1. IN PDS/PDB Create one table as
create table timer_table(id int, primary_datetime datetime default getdate())

2. In RDS/RDB create same table with one extra coloum
create table timer_table(id int,primary_datetime datetime,replicate_datetime default getdate())

3. Setup the replication between both.

4. Before executing the batch insert the value in table as
insert into timer_table (id) values(100)

5. Execute your batch for queries.

6. After completion, execute the insert statement as
insert into timer_table (id) values(101)

7. Now go in the replicated dataserver(RDS/RDB) and check the diff between primary_datetime and replicate_datetime.
select datediff(ss,min(primary_datetime),max(replicate_datetime)) from timer_table

With the help of id you can check the latency upto that point. Even,You can customize this method for checking the latency.

Source : www & sybooks.
Same Thread @ :

Basic Working of Sybase Replication Server

January 16th, 2010 No comments

Hey Guys,

Its my first post of New Year 2010. I am trying to put the basic understanding of Replication Server and whys it needs more monitoring. Hoping you will enjoy it!

Wishing you great new year 2010 ahead !

Basic Working of Replication Server

PDS : Primary Data Server
PDB : Primary Data Base

RDS : Replicated Data Server
RDB : Replicated Data Base

PRS : Primary Replication Server
RRS : Replicated Replication Server

RSSD : Replication System Database

1. RepAgent reads the record from transation log of the PDB for the tables which are marked for replication.

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

3. Holds Data in inbound queue , untill it recieves commit.

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

i Discards the rans if there is no subscription.
ii Writes the transaction to the out bound queue if there are subscription.

5. Writes commited trans only in outbound queue according to subscription.

6. Sends transactions to their destination, it depends upone two things

i) if Replicated Database is managed by PRS
Apply changes to RDB using the DSI thread our the connection.

ii) If their are two server, RRS is managing RDB
Send commited trans to RRS over route.
RRS apply that changes in RDB

7. If apropriate, uses function string information in RSSD to compose command to submit to replicate database.

Source : sybooks and www.

As you people are seeing, there are lot of movement of trans/record , and for these trans movements Replication Server uses lot of threads(DSI,RSI,SQT,SQM etc).

If any one of thread stops , replication ceases , even it can hamper PDB performance.

Thats why it is little bit difficult to manage, not difficult, we can say, its need better monitoring.

If I am missing any thing , please add in comments.

Same Thread at :

Syncing the Replicated DB with Primary DB in warm standby setup!

November 7th, 2009 No comments
Following steps  we can use for syncing the replicated database  from the primary database in warm standby setup.
PDS – Primary Dataserver
PDB – Primary Database
RDS – Replicated Dataserver
RDB – Replicated Database in RDS
Step #1
Put database  PDB in dbo use only
Clean up all logins besides systems, ( terminate all user processes )
Step #2
Quiese the replication server.
isql -Usa -Ppasswd -SRS
1> admin quiesce_check
2> go
Replication Server RS is Quiesced
Step #3
Stop the rep agent thread of Primary Database.
isql -Usa -Ppasswd -SPDS
use PDB
sp_stop_rep_agent PDB
Step #4
Suspend the connection to Primary database. Login into the Replication Server and issue the following command.
isql -Usa -Ppasswd -SRS
suspend connection to PDS.PDB
Step #5
Ignore the secondary transaction point in Primary Database.
isql -Usa -Ppasswd -SPDS
use PDB
dbcc settrunc(‘ltm’, ‘ignore’)
Step #6
Truncate the tran log and reset the locator value  to zero. Please only execute if the above step was successful.
isql -Usa -Ppasswd -SPDS
dump tran PDB with truncate_only
Issue this command in RSSD database.
rs_zeroltm PDS, PDB
Step #7
Dump the primary database.
isql -Usa -Ppasswd -SPDS
dump database PDB to ‘/dumpfs/PDB.dmp’
Step #8
Transfer the dump to RDS and load the RDB.
isql -Usa -Ppasswd -SRDS
load database RDB from ‘/sybase/RDS/dumpfs/PDB.dmp’
Step #9
Valid the secondary tran point  in PDS.
isql -Usa -Ppasswd -SPDS
use PDB
dbcc settrunc(‘ltm’, ‘valid’)
Step #10
Start the repagent for PDB in PDS.
isql -Usa -Ppasswd -SPDS
use PDB
sp_start_rep_agent PDB
Step #11
Resume the connection from the PDS.PDB in Replication Server.
isql -Usa -Ppasswd -SRS
resume connection to PDS.PDB
Step #12
Remove DBO use only from db.