cancel
Showing results for 
Search instead for 
Did you mean: 

Internal Replication Definitions

Former Member
0 Kudos

Recently, I attempted to implement repdefs in an MSA environment. The tables for which the repdefs were being created contained user defined datatypes and as such the repdef ending up have invalid datatypes. (As a side note, I was using Sybase Central to generate the repdefs and it defaulted to bigdatetime which was invalid for the user defined datatype of daydt (smallint)). Immediately upon adding the repdefs, I started getting the error

ERROR #32058 DIST(116 BAY1.sbnbltran) - /nrm/nrm.c(4850)

The value given for 'BAY1_payment_batches.tran_dt' cannot be translated from datatype 'integer' to the required datatype 'bigdatetime'. Value length is '4'; Maximum target length is '8'; The value is '[0000]2[96]'

In a effort to quickly recover, I modified the rs_columns table to correct the datatypes and then cycled the repserver to reload the cache for rs_objects and rs_columns. This approach had worked in the development environment but failed in the production environment. I then attempted to drop and create the repdefs with the valid datatypes. This did not correct the problem.

I attempted to drop and re-create the database replication definitions. At this point, our target connection would not remain stable. The result was that the target connection started crashing(stack trace) with an infected with a signal 11 which was preceded by a WARNING #5185.

WARNING #5185 DSI EXEC(117(1) SAC1.sbnbltran) - /dsiexec.c(14320)

        Row count mismatch for the command executed on 'SAC1.sbnbltran'. The command impacted 0 rows but it should impact 1 rows.

I. 2015/06/17 07:47:55. The error was caused by output command #1 of the failed transaction on table 'dbo.payment_batches'.

T. 2015/06/17 07:48:05. (331): Thread DSI(117 SAC1.sbnbltran) infected with signal 11.

T. 2015/06/17 07:48:05. (331): Dumping context structure:

T. 2015/06/17 07:48:05. (331): pc = 21d954p

T. 2015/06/17 07:48:05. (331): sp = 7072d891p

T. 2015/06/17 07:48:05. (331): ccr = 0p

T. 2015/06/17 07:48:05. (331): npc = 21d958p

The corrective action that I finally took was to restore from the RSSD backup that was taken prior to adding the repdefs and then rebuilding the queues. This removed all trace of the bad repdefs. I re-created the database repdef to the target database, materialized the target, and we were back.

Prior to restoring the RSSD backup, I took a backup of the bad RSSD and loaded it so that I could use it to compare to the good RSSD. What I found was where this discussion starts.

In the rs_objects, I found rs_drp.. objname entries for the repdefs that I had dropped and tried to create with the correct datatypes (See attached sql output file under rs_objects). According to the Repserver 15.7 Reference Manual these are referred to as "internal replication definitions". There were several entries with one of them showing as active via active_inbound = 0. Since these were dropped repdefs, none of them should have been active.

I then ran rs_helprepversion using the phys_tablename for the active repdef. (See attached sql output file under rs_helprepversion.)

Finally, I ran a select from rs_columns for the 'active" dropped repdef to determine if the columns type and length were from the corrected repdef and they were ( See attached sql output file under rs_columns.).

First, Can someone tell me why these are still in the RSSD even after dropping the repdefs and rebuilding the queues? According to the Reference Manual these are supposed to be "deleted" when the data associated with the repdef is no longer in the replication system. What determines "when the data associated with the repdef is no longer in the replication system"?

Second, Does anyone have the steps necessary to manually remove these entries or to manually remove a repdef?

Version Information.

RSSD ASE: Adaptive Server Enterprise/15.7/EBF 23462 SMP SP131 /P/Sun_svr4/OS 5.10/ase157sp131x/3896/64-bit/FBO/Mon Nov  3 21:04:21 2014

REPSERVER:Replication Server/15.7.1/EBF 20678 ESD#2 rsebf1571/Sun_svr4/OS 5.8/1/OPT64/Thu Nov  8 18:01:15 2012

Primary Dataserver:Adaptive Server Enterprise/15.0.3/EBF 20615 ESD#4.2/P/Sun_svr4/OS 5.8/ase1503/2814/64-bit/FBO/Sat Dec  8 16:16:43 2012

Replicate Dataserver:Adaptive Server Enterprise/15.0.3/EBF 20615 ESD#4.2/P/Sun_svr4/OS 5.8/ase1503/2814/64-bit/FBO/Sat Dec  8 16:16:43 2012

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

I have been able to develop a method for removing these internal repdefs. (This method has not been approved by SAP Sybase. Use at your own risk!)

As a precaution, I backed up the RSSD. If all else fails, you can restore the RSSD and rebuild the queues. This worse case may require running rs_subcmp on databases in question or re-syncing them following the rebuild of the queues.

Here are the basic steps.

1) On source repserver, suspend connection to the affected server.database. Suspend log transfer from the source server.database.

2) Shutdown the repserver

3) On the RSSD, delete rs_drp... columns in rs_columns for the specific rs_drp.. objid. Delete rs_drp... rows in rs_objects

4) On the source dataserver, change to the affected database. Run sp_stop_rep_agent for this database. Issue the dbcc settrunc ('ltm','ignore'). You have now started the process of restarting the replication from the last transaction.

5) On the RSSD, run rs_zeroltm dataserver, database

6) On the dataserver in the affected database, set the truncation point to valid - dbcc settrunc( 'ltm', 'valid') -  followed by restarting the repagent (sp_start_rep_agent).

At this point, you have reset replication to restart fort this database. This has removed any reference in the RSSD to the replication of the rs_drp... (dropped) subscriptions and as such, the repserver no longer crashes.

7) On the repserver, resume log transfer from the server.database and resume the connection to the server.database.


If there have been any transactions in the primary database, it will be necessary to resync the target databases. The rs_subcmp may also be an alternative.

I should note that just re-syncing the downstream targets will not correct the problem as the data in the RSSD is related to the source server.database and will not be cleared until either the RSSD is restored or the repagent is set to restart replication and bypass the bad queued data.

Former Member
0 Kudos

I should add that the internal replication definitions are found in the source repserver for those environments where both source and target repservers exist.

Note: When opening rs_drp.txt, it is best viewed in wordpad.