'Attempt to insert duplicate key row in object
preetham
Can anyone tell me how to resolve this error in replication.
Message: 2601, State 1, Severity 14 -- 'Attempt to insert duplicate
key row in object 'dsafdf' with unique index 'afdgf'
Luc Van der Veurst
> Message: 2601, State 1, Severity 14 -- 'Attempt to insert duplicate
> key row in object 'dsafdf' with unique index 'afdgf'
There are 2 options :
1) delete the row in sql server and resume the connection
2) resume the connection with the skip transaction option.
first look at the connection by first logging the transaction:
login into the repserver and exeucte :
sysadmin log_first_tran, <dataserver>, <database>
and then by looking at the transaction :
login into the rssd_db in the rssd_server and
execute:
rs_helpexception
find the last Xact ID and execute :
rs_helpexception XactID, v
This will show the statement causing the error, so that you
can select the content in both servers and see what the differences
are and which of the two tuples contains the 'valid' data.
This will also show if other tuples are inserted/deleted/updated in
the same transaction and which you will loose as well when you
skip the transaction.
Do you know why you get this error ? Obviously, some inserts
are happening on both dataservers causing these kind of conflicts.
Can you avoid that this will happen again ?
You need to understand where this error comes from to take
the best action.
Luc.
Mark A. Parsons
======================================
sysadmin dump_first_trans,<RDS>,<RDB>
======================================
This will dump the offending transaction to the RSSD's exceptions log (ie, a handful of tables in the RSSD).
In the RSSD run the following:
======================
rs_helpexception
======================
Find the transaction id for the exception in question and run the following:
======================
rs_helpexception <XACT_ID>,v
======================
This will dump out the contents of the exception to the screeen. The dump will contain a mix of RCL (repserver command
language) strings and T-SQL strings ... ignore the RCL strings in order to get the T-SQL of the offending transaction.
With the T-SQL in hand you can manually issue the statements against the replicate database to see which one is causing
the problem. (NOTE: You may want to issue the transactions inside a transaction so that you can rollback the activity
once you find the offending statement.)
Once you find the offending statement you can use this info to pull up the 'duplicate' record from the replicate database.
At this point you'll need to think about how the duplicate record occurred, eg:
- was the RDB in sync to start with? if not, you'll need to resync the RDB
- was someone performing writes against the RDB instead of the PDB? if so, you'll need to track down *WHY* someone is
writing to the RDB, and then look at resyncing the RDB
- resyncing the database will depend on your topology (eg, if the RDB is a standy db in a WS setup then a dump-and-load
will be necessary, if the RDB is part of a rollup (or distribute-down) database then you'll need to figure out to resync
just the data in question, etc.)
- with the old and new data in hand (for the 'duplicate' record) you may just want to delete the record from the RDB and
restart the DSI connection (ie, let the new transaction come through from the repserver)
Once you track down (and fix) the issue in the RDB you'll need to figure out what to do with the transcations (destined
for the RDB) currently sitting in the repserver. This could include rebuilding the queue (ie, throwing away
transactions, or (re)applying the transactions at the RDB ... it will really depend on your topology.
preetham
This has been resolved.
Thanx all once again.
> preetham wrote:
> > Hi
>
> > Can anyone tell me how to resolve this error in replication.
> > Message: 2601, State 1, Severity 14 -- 'Attempt to insert duplicate
> > key row in object 'dsafdf' with unique index 'afdgf'- Hide quoted text -
>
> - Show quoted text -