solving sql server problems for millions of dbas and developers since 2006



SQL Server DBA Tips SQL Server Developer Tips SQL Server Business Intelligence Tips SQL Server Career Tips SQL Server Tip Categories SQL Server Tutorials SQL Server Webcasts SQL Server Whitepapers SQL Server Tools SQL Server Questions and Answers MSSQLTips Authors About MSSQLTips SQL Server User Groups MSSLQTips Giveaways MSSQLTips Advertising Options

MSSQLTips Facebook Page MSSQLTips LinkedIn Page MSSQLTips RSS Feed MSSQLTips Twitter Page MSSQLTips Google+ Page





SQL Product Highlight

Idera - SQL compliance manager

SQL compliance manager is a comprehensive auditing solution that tells you who did what, when and how on your SQL Servers. SQL compliance manager helps you ensure compliance with regulatory and data security requirements.

Learn more!




Options to not replicate SQL Server DELETE commands

By: | Read Comments (10) | Print

Mohammed is a SQL Server DBA with over 6 years experience managing production databases for a few Fortune 500 companies.

Related Tips: More

Problem

I have transactional replication configured in my production environment. The business team has requested that I do not replicate delete operations on certain articles.  In this tip we look at a couple of options to not replicate DELETE commands.

Solution

In some cases older data may be required on the subscriber, but deleted at the publisher. In order to meet this requirement we could use either of the options outlined below. Note, both options assume transactional replication is already configured between two databases.


Option 1: Modifying Replication Settings

In this option we will use SSMS to make the changes, but this could be done using T-SQL commands as well.

In SSMS go to Replication -> Local Publications and right click on your publication and select Properties.  In the Publication Properties window click on 'Articles' and select the relevant article.  Go to "Article Properties" and select "Set Properties of Highlighted Table Article" as shown below.

sql publication properties

In the article properties window, change the "DELETE delivery format" to "Do not replicate DELETE statements".

sql server article properties

After the change click OK and you will see the below prompt.  As the article property has been changed the subscriptions need to be reinitialized. Click "Mark for Reinitialization" which causes the snapshot to be applied to the subscriber.

reinitialize subscriptions

In SSSM, navigate to Replication and right click and select "Launch Replication Monitor" as shown below.  Go to your publication and click View Details as shown below to see the snapshot progress.

sql server replication monitor

After clicking "View Details", you can see the details of the snapshot generation for the subscriber.

sql distributor to subscriber history

As you can see the entire snapshot is getting applied to the subscriber.  This option must be used with caution as there may be cases where your subscriber database is used as an archive and may have more data than your publisher database.  However, this depends on your environment and if your application is fine with getting the entire snapshot you could use this method.  Also, for very large databases you may not want to reinitialize the entire snapshot either, so again use caution.

Once this change has been made and if there is a need to revert to replicating deletes, just perform similar steps as above to allow delete operations by calling the replication delete stored procedure at the subscriber. Call <stored procedure> is the default syntax for DELETE operations for SQL Server transactional replication. Once you select Call <stored procedure>, you will also need to provide the DELETE stored procedure name for this specific article which would be available in the subscriber database.


Option 2 : Modifying the replication stored procedure in the subscriber database

For transactional replication, by default, stored procedures get created in the subscriber database for insert, update and delete operations. These could be viewed as shown in the screenshot below.

sql replication stored procedures

REP_S is the subscriber database and we could see the insert, update and delete stored procedures that were created for each subscribed article.  In option (1), we need to be concerned about the snapshot getting applied when we modify the article property. However, in order to overcome this shortcoming, there were some discussions I came across on the internet to make the replication delete procedure in the subscriber database to just RETURN and not actually do the DELETE. This would ensure that the replication delete procedure in the subscriber database exits unconditionally even though it is called. As per books online, RETURN in T-SQL enables you to "Exit unconditionally from a query or procedure. RETURN is immediate and complete and can be used at any point to exit from a procedure, batch, or statement block. Statements that follow RETURN are not executed." (Source - http://msdn.microsoft.com/en-us/library/ms174998.aspx).

Using this concept, the delete procedure in the subscriber database could be modifed as shown. I have just added the RETURN statement right after the BEGIN, so the stored procedure exits immediately without doing the actual DELETE.  With this approach, we need not worry about the snapshot getting applied again to the subscriber.

--Include RETURN statement in stored procedure and alter the stored procedure in the subscriber database
USE [REP_S]
GO
/****** Object: StoredProcedure [dbo].[sp_MSdel_dboArticle_1] Script Date: 10/14/2011 22:00:43 ******/
SET ANSI_NULLS ON
GO SET QUOTED_IDENTIFIER ON
GO
ALTER procedure [dbo].[sp_MSdel_dboArticle_1] @pkc1 int
as
begin 
RETURN
delete [dbo].[Article_1]
where [Col1] = @pkc1 if @@rowcount = 0
   if @@microsoftversion>0x07320000
       exec sp_MSreplraiserror 20598
end
GO

In order to revert to the older configuration, to allow SQL Server to replicate deletes, you would need to just comment or remove the RETURN statement in the stored procedure.

Summary

Both options could be tested easily with a simple publication of a single article and performing the sequence of steps as shown above.  Also you should use Replication Monitor to see if there are any errors.

Note: the above steps were performed using SQL Server 2008 R2.

Next Steps

  • Consider testing this scenario through a simple transactional replication setup
  • Refer to other related tips on replication to get familiar with the concepts


Related Tips: More | Become a paid author


Last Update: 10/26/2011

Share: Share 






Comments and Feedback:

Wednesday, October 26, 2011 - 8:33:44 AM - Tony Read The Tip

I am new to replication.  Are there any options to not replicate insert or update commands?  I assume select statements are not replicated.


Wednesday, October 26, 2011 - 8:34:44 AM - Tony Read The Tip

BTW - Great article!!!


Wednesday, October 26, 2011 - 11:36:21 PM - Mohammed Moinudheen Read The Tip

Tony,

Thanks for your comments. For not replicating insert or update, you could try the same options as described and select the correct format under the 'statement delivery' section of article properties. Or you could try including the 'return' statement in the relevant stored procedure in the subsriber database.

Thanks,

Mohammed Moinudheen

 

 


Tuesday, November 01, 2011 - 2:44:20 PM - BuntyBoy Read The Tip

Very good article Moinu!!!!!

===========================================
Better try and fail, instead of not trying at all...

Database Best Practices


Friday, November 04, 2011 - 5:51:45 AM - Steve Johnson Read The Tip

Option 2 is completely misleading and will cause data loss on the subscriber when the snapshot is applied - the delete stored proc, is used when replicating transactions post-snapshot application.

The publication option 'Destination Object-->Action if name is in use' - which has a default value of 'Drop existing object and create a new one' will remove the existing data at the subscriber, before the snapshot data is bcp'd, regardless of your suggested stored proc. hack.


Friday, November 04, 2011 - 7:28:56 AM - Mohammed Moinudheen Read The Tip

Steve, Thanks for your comments. I thought option 2 is used if you don't want to apply the snapshot.


Friday, November 04, 2011 - 7:37:51 AM - Jason Bunn Read The Tip

With option #2, you have to be careful, since any schema change, if replicated, causes a regeneration of the stored procedures, and if you are manually editing the delete proc, you run the risk of losing that change.  A safer option may be to use "register custom scripting" to generate custom stored procedures for the delete statements.  That way, you are using a procedure that you develop, rather than manually modifying a system generated procedure, and this will ensure that your functionality will survive a schema change.


Friday, November 04, 2011 - 8:33:42 AM - Mohammed Moinudheen Read The Tip

Jason, Thanks for your comments.


Tuesday, November 08, 2011 - 5:51:22 PM - Ron Read The Tip

We take another route in that all deletes are done via stored procedure calls on the publisher.  We take advantage of that to replicate execution of these delete stored procedures to a target procedure on the subscribers that does nothing.  This has advantages of not requiring a new snapshot, not touching any of the generated code, and continuing to work even if a new snapshot is performed (which would typically wipe out your modifications to the generated procedures).  It does not protect the data from direct deletions, so it only works if you do not allow your users direct access to deleting table data.


Wednesday, November 09, 2011 - 7:58:07 AM - Mohammed Moinudheen Read The Tip

Ron, Thanks for your inputs. Very useful.



Post a Comment or Question

Keep it clean and stay on the subject or we may delete your comment.
Your email address is not published. Required fields are marked with an asterisk (*)

*Name   *Email   Notify for updates
Comments
*Enter Code refresh code


 
Sponsor Information
Find and fix SQL Server problems before they happen - SQL diagnostic manager now with predictive analysis!

SQL Monitor – For database professionals who need results on Day One. Try it online.

Need SQL Server help and not sure where to turn? Reach out to expert consultants for a Health Check.

Free Trial: Get Proactive Insight with Spotlight® for SQL Server Enterprise.

Join the over million SQL Server Professionals who get their issues resolved daily.

Demystify TempDB Performance and Manageability


Copyright (c) 2006-2012 Edgewood Solutions, LLC All rights reserved
privacy | disclaimer | copyright | advertise | about
authors | contribute | feedback | giveaways | user groups
Some names and products listed are the registered trademarks of their respective owners.


Edgewood Solutions LLC | MSSharePointTips.com | MSSQLTips.com