:::: MENU ::::

Posts Categorized / Replication

  • Mar 24 / 2014
  • 2
dbDigger, Replication, SQL Server Error messages

The ALTER TABLE statement conflicted with the FOREIGN KEY constraint (Replication error)

We had configured transnational replication on a QA server. Publisher and subscriber were on same server. While implementing snapshot we were facing following error message as in replication monitor.

Command attempted:
if object_id(N’sys.sp_MSrestoresavedforeignkeys’, ‘P’) < 0 exec sys.sp_MSrestoresavedforeignkeys
(Transaction sequence number: 0x000B0F2B0002BB5101C300000000, Command ID: 1)

Error messages:
The ALTER TABLE statement conflicted with the FOREIGN KEY constraint “FK_ContractID2”. The conflict occurred in database “%”, table “%”, column ‘%’. (Source: MSSQLServer, Error number: 547)
Get help: http://help/547
The ALTER TABLE statement conflicted with the FOREIGN KEY constraint “FK_ContractID2”. The conflict occurred in database “%”, table “%”, column ‘%’. (Source: MSSQLServer, Error number: 547)
Get help: http://help/547

Subscriber database had no constraint that was mentioned in the error message. Even publisher did not have this constraint. It was a mess that we were not able to find the constraint but it was causing failure to snapshot implementation.

Towards Solution

While looking into details i came across following there tables that were being created by replication processes and contain the foreign key data of replication.

  • dbo.MSsavedforeignkeys
  • dbo.MSsavedforeignkeycolumns
  • dbo.MSsavedforeignkeyextendedproperties

I noticed that ghost enteries for our culprit foreign key were there in these tables. I deleted those entries manually and regenerated the snapshot. This time it was successfully generated and implemented.

  • Aug 16 / 2013
  • 0
dbDigger, Monitoring and Analysis, Replication, T-SQL Scripts

Get list of replicated objects in a database

If replication is implemented then it is important to have a list of objects that have been replicated. Replicated objects are known as article in terms of replication setup. So articles may have slightly different concerns in terms of performance, drop or truncate command. Use the following simple script to get the list of replicated objects in a database.

 USE [Ur DB Name Here]  
 GO  
 SELECT NAME AS [Object Name]  
   ,type_desc AS [Object Type]  
   ,is_published AS [Is Data and Schema Published]  
   ,is_schema_published AS [Is Only Schema Published]  
 FROM sys.objects  
 WHERE is_ms_shipped = 0  
 AND (is_published = 1 OR is_schema_published = 1)  

Get list of replicated objects in a database
[Is Data is Schema Published] is for tables. While [Is Only Schema Published] is for other objects like USPs, UDF and Views.

  • Aug 09 / 2008
  • 0
DBA best practices, dbDigger, High Availability, Replication

DBA Best Practices for Replication

Following best practices will help you to configure a successful replication

  1. Replication needs should be clearly defined before creating a replication topology. Successful replication can be difficult and requires much pre-planning.
  2. Ideally publishers, distributors, and subscribers should be on separate physical hardware.
  3. Create, document, and test a backup and restore strategy. Restoring replicated databases can be complex and requires much planning and practice.
  4. Script the replication topology as part of your disaster recovery plan so you can easily recreate your replication topology if needed.
  5. Use default replication settings, unless you can ensure that a non-default setting will actually improve replication performance or other issues. Be sure that you test all changes to ensure that they are as effective as you expect.
  6. Fully understand the implications of adding or dropping articles, changing publication properties, and changing schema on published databases, before making any of these changes.
  7. Periodically, validate data between publishers and subscribers.
  8. Regularly monitor replication processes and jobs to ensure they are working.
  9. Regularly monitor replication performance, and performance tune as necessary.
  10. Add alerts to all replication jobs so you are notified of any job failures.

Chosen from SQL Server DBA best practices By Brad M.mcGehee

Consult us to explore the Databases. Contact us