sql server - sql replication error - record exists on Publisher but it's trying to delete/insert that on Subscriber, so Foreign Key/Primary Key violation -
we have transactional one-way replication running, , today started getting error :
the delete statement conflicted reference constraint "fk_branchdetail_branch". conflict occurred in database "locationdb", table "dbo.branchdetail", column 'branchnumber'. message: row not found @ subscriber when applying replicated command. violation of primary key constraint 'pk_branch'. cannot insert duplicate key in object 'dbo.branch'. duplicate key value (23456) disconnecting subscriber 'sqldb03'
publisher - sqldb02.locationdb
subscriber - sqldb03.locationdb
tables on both servers:
branch (branchnumber primarykey)
branchdetail (branchnumber foreignkey references previous table)
select * sqldb02.locationdb.branch -- contains : 23456,'texas',... select * sqldb03.locationdb.branch -- contains : 23456,'null',...
the problem - branchnumber in question '23456' exists in 4 tables (publisher..branch, publisher..branchdetail, subscriber..branch, subscriber..branchdetail).
yet, when ran trace on subscriber, see repeated commands like:
exec [sp_msdel_dbobranch] 23456 -- throws fk violation exec [sp_msins_dbobranch] 23456,'null',... -- throws pk violation
i'm guessing it's trying update record on subscriber doing delete + insert. it's unable to..
users not have access modify subscriber table. can modify publisher table through ui, , have been doing long time without issue. there job updates publisher table once every night. started getting error around noon today.
our last resort reinitialize subscription off-hours.
ideas have caused , how fix it?
for transactional replication, updating primary key column replicated delete + insert (deferred update). because pk column has fk constraint, delete fail @ subscriber. have couple workarounds prevent happening moving forward:
- disable replicating of fk constraints, not needed one-way replication. why? users not entering data @ subscriber, there no need maintain referential integrity, , transactional replication replicates log txns, order of txns pretty guaranteed, no need worry 1 txn showing before another.
- enable trace flag 8207 on publisher. if single row updated, replicated single update statement. if update affects multiple rows, replicated deferred update.
- somehow block users updating pks
imo, best bet first option.
how fix this? reinit 1 way. if can manaully disable or drop fk constraint on subscriber, easiest solution.
Comments
Post a Comment