Skip to Content
0

rs_lastcommit table isn't updated although the replication server is running

Nov 14, 2017 at 12:42 PM

66

avatar image

Dears, kindly help in the following issue:

while we have been used sybase replication server to synchronize data between two sides each of them uses Sybase ASE 15.7

in the past, we had faced a problem which is : all the queues in the replication server became totally full, but no thread was down, this caused after a very huge data and transaction done on the primary database.

in that time, we restart the replication server (sybase service),

then suspended and resumed the connection to the replicated database.

but the queues kept full till next day, they started to move their content.

and I thought the problem solved.

Today, I want to show the data in the rs_last_commit table in the primary database,

I was surprised with the result as the value of dest-commit_time column is the date when the problem mentioned had occurred: 24 Apr 2017

origin	origin_qid	secondary_qid	origin_time	dest_commit_time	conn_id	pad1	pad2	pad3	pad4	pad5	pad6	pad7	pad8
0	000000000000000000000000000000000000000000000000000000000000000000000000	000000000000000000000000000000000000000000000000000000000000000000000000	Jan  1 1900 12:00AM	Apr 24 2017 12:53PM	0	00	00	00	00	00	00	00	00

I check the same table in the replicated database: it has two rows with dates (9 and 14 Nov -2017) newer than one in the primary database(24 Apr 2017) but also prior to Today's date (14 Nov 2017)

origin	origin_qid	secondary_qid	origin_time	dest_commit_time	conn_id	pad1	pad2	pad3	pad4	pad5	pad6	pad7	pad8
0	000000000000000000000000000000000000000000000000000000000000000000000000	000000000000000000000000000000000000000000000000000000000000000000000000	Jan  1 1900 12:00AM	Nov  9 2017  9:54AM	0	00	00	00	00	00	00	00	00
103	000000056cdb15790010d9e100070010bfae003a0000a82b00d3aa040000000000000001	000000000000000000000000000000000000000000000000000000000000000000000000	Nov 14 2017  2:06PM	Nov 14 2017  2:06PM	0	00	00	00	00	00	00	00	00

so, is there any issue with my replication? why this table doesn't updated?

I'm sure that the replication server now is replicating data, I monitor some tables on both sides on daily-basis, they have the same row count, and the stableq queues are empty except one: total seg = 10000 MB, and used seg = 500 MB only

kindly advice me in this issue.

with all thanks

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

1 Answer

Best Answer
Mark A Parsons Nov 14, 2017 at 04:57 PM
1

rs_lastcommit holds a few different types of data ... generic RS/DSI connectivity timestamps, and specific PDB/RDB connectivity timestamps.

The generic timestamps will show origin and/or conn_id columns with a value of zero (0). [Depending on which row you're looking at, these timestamps will correspond to things like ... when the DSI last connected to the PDB/RDB.]

For PDB/RDB connectivity timestamps you want to look for rows where both the origin and conn_id columns are non-zero (>0). The origin/conn_id column values correspond with the dbid/conn_id values of the PDB/RDB, respectively. [You can find a DB's dbid/conn_id value in the rs_databases table, or the RS ID server's rs_idnames table.] [These timestamps are typically updated every time a transaction completes/commits in the RDB.]

---------------

While the rs_lastcommit records where origin or conn_id are equal to zero are of some/minor interest, 99% of the time I'm only interested in the records where both origin and conn_id are greater than 0, ie, I'm typically only interested in timestamps for actual PDB/RDB pairs (eg, monitoring scripts, rs_ticket verification, troubleshooting/verifying specific PDB/RDB pairs, etc).

---------------

As for your sample records from your rs_lastcommit table:

- I wouldn't be too interested in the entries from the PDB, especially if you're not replicating into the PDB

- I don't see any PDB/RDB specific rows from your RDB's rs_lastcommit table (ie, nothing where both origin and conn_id are greater than 0), so can't offer much in terms of comments at this time ...

Share
10 |10000 characters needed characters left characters exceeded